我們的上一篇文章“如何從 AWS S3 遣返到 Minio”的反響非常好 — 我們收到了數十個來自組織的請求，要求提供遣返建議。 我們在這篇新文章中彙總了這些回覆，其中我們更深入地研究了與遣返相關的成本和節省，以便您更輕鬆地進行自己的分析。 對於許多人來說，資料遷移是一項艱鉅的任務。 在實踐中，他們的目標是將新資料引入Minio，並利用他們的甜蜜時間從雲中遷移舊資料，或者將其保留在原地而不增長。
要從 AWS S3 發回資料，您將遵循以下一般準則：
檢視資料要求：確定需要從 AWS S3 返回的特定儲存桶和物件。 確保您逐個桶了解您的業務需求和合規性要求。
確定您的遣返目的地：現在您已經決定遣返到 Minio，現在您可以選擇在本地資料中心或其他雲提供商或託管設施中執行 Minio。 根據第 1 中的要求，您可以選擇硬體或例項來滿足您的儲存、傳輸和可用性需求。
資料傳輸：計畫並執行從 AWS S3 到 Minio 的資料傳輸。 只需使用 Minio 的內建批量複製或使用 Minio 客戶端進行映象（有關更多資訊，請參閱如何從 AWS S3 遣返到 Minio）。 您還可以使用其他幾種方法進行資料傳輸，例如使用 AWS DataSync、AWS Snowball 或 TD Synnex 資料遷移，或直接使用 AWS API。
資料訪問和許可權：確保為每個儲存桶的返回資料設定適當的訪問控制和許可權。 這包括用於管理使用者訪問、身份驗證和授權的 IAM 和儲存桶策略，以確保資料的安全性。
物件鎖定：遷移後保留物件鎖定保留和法律保留策略至關重要。 目標物件儲存必須以與 Amazon S3 相同的方式解釋規則。 如果您不確定，請請求對目標物件儲存實施進行 Cohasset Associates 合規性評估。
資料生命週期管理：為返回的資料定義和實施資料生命週期管理策略。 這包括定義保留策略、備份和恢復過程以及每個儲存桶的資料歸檔做法。
資料驗證：驗證傳輸的資料，確保其完整性和完整性。 執行必要的檢查和測試，以確保資料已成功傳輸，沒有任何損壞或丟失。 傳輸後，源和目標之間的物件名稱、etag 和元資料、校驗和以及物件數將匹配。
更新應用程式和工作流：好訊息是，如果您按照雲原生原則構建應用程式，您所要做的就是為新的 Minio 端點重新配置它們。 但是，如果您的應用程式和工作流旨在與 AWS 生態系統配合使用，請進行必要的更新以適應返回的資料。 在某些情況下，這可能涉及更新配置、重新配置整合或修改**。
監視和優化：持續監視和優化遣返的資料環境，以確保最佳效能、成本效益並遵守資料管理最佳實踐。
在制定雲遣返預算和規劃時，需要考慮許多因素。 幸運的是，我們的工程師與許多客戶合作過，我們為您制定了詳細的計畫。 我們的客戶已經遣返了從少量工作負載到數百 PB 的所有內容。
最大的規劃任務是考慮有關網路、租用頻寬、伺服器硬體、未選擇用於遣返的資料的存檔成本以及管理和維護自己的雲基礎架構的人工成本等選項。 估算這些成本並為其制定計畫。 雲遣返成本將包括將資料從雲移回資料中心的資料出口費用。 這些費用故意高到足以強制雲鎖定。 請注意這些高昂的出口費用 - 它們證實了離開公有雲的經濟論點，因為出口費用會隨著您管理的資料量的增長而增加。 因此，如果您要被遣返，盡早採取行動是值得的。
我們將重點關注必須移動的資料和元資料，這是遣返所需工作的 80%。 元資料包括儲存桶屬性和策略（基於訪問私鑰的訪問管理、生命週期管理、加密、匿名公有訪問、物件鎖定和版本控制）。
現在讓我們關注資料（物件）。 對於要遷移的每個命名空間，清點要移動的儲存桶和物件。 您的 DevOps 團隊可能已經知道哪些儲存桶包含重要的當前資料。 您還可以使用 Amazon S3 清單。 在較高階別上，這將如下所示：
下一步是按命名空間列出每個儲存桶及其要遷移的每個儲存桶的屬性。 請注意在該儲存桶中儲存和讀取資料的應用程式。 根據使用情況將每個儲存桶分類為熱層、暖層或冷層資料。
在刪節版中，這看起來像。
此時，您需要對資料生命週期管理做出一些決策，並密切關注它，因為這是在 AWS 上節省資金的好方法。 根據訪問頻率將每個儲存桶中的物件分類為熱、溫或冷。 省錢的乙個好地方是將冷層儲存桶直接遷移到 S3 Glacier，沒有理由僅僅為了再次上傳而產生出口費用。
根據要返回的資料量，您可以通過幾個選項來選擇遷移方式。 我們建議您在新的 minio 集群上載入和處理新資料，同時隨著時間的推移將熱資料和溫資料複製到新集群。 當然，複製物件所需的時間和頻寬將取決於要複製的物件的數量和大小。
在這裡，計算要從 AWS S3 傳回的總資料將非常有幫助。 檢視您的庫存並計算所有歸類為熱桶和熱桶的總尺寸。
資料匯出費用是根據上述總額計算的。 我使用的是標價，但您的組織可能有資格享受 AWS 折扣。 我也使用 10 Gbps 作為連線頻寬，但您可能或多或少可用。 最後，我的假設是，三分之一的 S3 資料將僅傳輸到 S3 Glacier Deep Archive。
不要忘記為 S3 Glacier Deep Archive 的使用量制定預算。
為簡單起見，上述計算不包括每個物件操作的成本 （0.）。40 美元換 100 萬美元），不包括上市成本（100 萬美元 5 美元）。對於非常大的遣返專案，我們還可以在通過網路傳送之前對物件進行壓縮，從而為您節省一些出口費用。
另一種選擇是使用 AWS Snowball 傳輸物件。 每個 Snowball 裝置都是 80TB，因此我們事先知道需要 20 臺裝置才能進行遣返工作。 每台裝置的費用包括 10 天的使用時間，外加 2 天的運輸費用。 額外天數為每台裝置 30 美元。
AWS 將向您收取讀取和寫入 AWS 服務（包括 Amazon S3 和 AWS Key Management Service （KMS））的標準請求、儲存和資料傳輸費率。 使用 Amazon S3 儲存類時，還有其他注意事項。 對於 S3 匯出作業，從 S3 傳輸到 Snow Family 裝置的資料按標準 S3 費用計費，用於 list、get 等操作。 您還需要支付 Amazon CloudWatch Logs、Amazon CloudWatch 指標和 Amazon CloudWatch Events 的標準費率。
現在我們知道遷移如此龐大的資料需要多長時間以及需要多少成本。 根據時間和費用的組合，就哪種方法滿足您的需求做出業務決策。
在這一點上，我們也知道在本地或託管設施中執行minio所需的硬體要求。 根據 15PB 儲存需求，估計資料增長，並檢視我們推薦的硬體和配置頁面，為您的 minio 部署選擇最佳硬體。
第一步是在 Minio 中重新建立 S3 儲存桶。 無論您選擇如何遷移物件，都必須這樣做。 雖然 S3 和 Minio 都使用伺服器端加密來儲存物件，但您不必擔心遷移加密金鑰。 您可以使用 Minio KES 連線到您選擇的 KMS 以管理加密金鑰。 這樣，當您在 Minio 中建立加密的租戶和儲存桶時，將自動為您生成乙個新金鑰。
複製物件有幾個選項：批量複製和mc mirror。我之前的部落格文章《如何從 AWS S3 遣返到 Minio》包含這兩種方法的詳細說明。 您可以將物件直接從 S3 複製到本地 minio，或者使用在 EC2 上執行的臨時 minio 集群查詢 S3，然後將其映象到本地 minio。
通常，客戶使用我們與 AWS Snowball 或 TD Synnex 資料遷移硬體和服務結合使用的工具來移動大量資料（超過 1 PB）。
Minio 最近與 Western Digital 和 TD Synnex 合作推出了 Snowball 替代品。 客戶可以安排乙個視窗來接收 Western Digital 硬體，並在租賃期間支付他們需要的東西。 更重要的是，該服務與雲無關，這意味著企業可以使用該服務將資料移入、移出和跨雲移動，所有這些都使用無處不在的 S3 協議。 有關該服務的其他詳細資訊，請訪問TD Synnex**的資料遷移服務頁面。
可以使用get-bucket s3API 呼叫讀取儲存桶元資料，包括策略和儲存桶屬性，然後在 Minio 中設定。 當您註冊 Minio 子網時，我們的工程師將與您一起從 AWS S3 遷移以下設定：基於訪問金鑰、私有金鑰的訪問管理、生命週期管理策略、加密、匿名公有訪問、不可變性和版本控制。 關於版本控制的一件事是，遷移資料時通常不會保留 AWS 版本 ID，因為每個版本 ID 都是乙個內部 UUID。 這對客戶來說很大程度上不是問題，因為物件通常是按名稱呼叫的。 但是，如果您需要 AWS 版本 ID，那麼我們有乙個擴充套件可以將其儲存在 Minio 中並幫助您啟用它。
請特別注意 IAM 和儲存桶策略。 S3 不會是您留下的 AWS 基礎設施的唯一部分。 訪問 S3 儲存桶時，您將有大量服務賬戶**用於該計畫。 這將是列出和審核所有服務帳戶的好時機。 然後，您可以決定是否在身份提供程式中重新建立它們。 如果您選擇自動化，請使用 Amazon Cognito 與外部 OpenID Connect IDP 和 AD LDAP 共享 IAM 資訊。
特別注意資料生命週期管理，例如物件保留、物件鎖定和歸檔分層。 在每個儲存桶上執行乙個get-bucket-lifecycle-configuration獲取人類可讀的生命週期規則 JSON 列表。 您可以使用 Minio 控制台或 Minio 客戶端 （MC） 輕鬆重新建立 AWS S3 設定。 使用 和get-object-legal-holdget-object-lock-configuration以及其他命令，用於查明需要特殊安全和治理處理的物件。
說到生命週期，先說一下備份和容災。 是否要複製到其他 minio 集群進行備份和災難恢復？
將物件從 AWS S3 複製到 Minio 後，驗證資料完整性非常重要。 執行此操作的最簡單方法是使用 minio 客戶端在 S3 中的舊儲存桶上執行 mc diff，並在 minio 上執行新儲存桶。 這將計算儲存桶之間的差值，並僅返回缺少或不同物件的列表。 此命令採用源儲存桶和目標儲存桶的引數。 為方便起見，您可能需要為 S3 和 Minio 建立別名，這樣您就不必經常鍵入完整的位址和憑證。 例如：
mc diff s3/bucket1 minio/bucket1
如果您的 S3 遷移是將整個應用程式遷移到本地的更大工作的一部分，則您可能會在新資料到達時使用 S3 事件通知來呼叫下游服務。 如果是這樣的話，不要害怕 - minio 也支援事件通知。 這裡最直接的遷移是實現自定義 Webhook 來接收通知。 但是，如果您需要更持久和更具彈性的目標，請使用 Kafka 或 RabbitMQ 等訊息傳遞服務。 我們還支援將事件傳送到 PostgreSQL 和 MySQL 等資料庫。
現在，您已經完成了遣返，是時候將注意力轉向儲存操作、監視和優化了。 好訊息是 minio 不需要優化——我們已經在軟體中內建了優化功能，因此您知道您正在從硬體中獲得最佳效能。 您需要開始監控新的 minio 集群，以持續評估資源利用率和效能。 Minio 通過 Prometheus 端點公開指標，您可以在所選的監控和警報平台中使用該端點。 有關監視的更多資訊，請參閱使用 Prometheus 和 Grafana 進行多雲監視和警報，以及使用 OpenTelemetry、Flask 和 Prometheus 使用 Minio 進行指標。
向雲提供商開空白支票的日子已經一去不復返了，這已經不是什麼秘密了。 許多企業目前正在評估他們的雲支出，以尋找潛在的節省。 現在，您擁有開始從 AWS S3 遷移到 Minio 所需的一切，包括特定的技術步驟和財務框架。