从公有云对象存储迁移到回私有化 MinIO需要了解的所有信息

我们上一篇文章《如何从 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 清单。在较高级别上，这将如下所示：

Namespace（命名空间）	总桶数	对象总数	对象总大小（GB）	每日总上传量（TB）	每日总下载量（TB）
NS-001型	166	47,751,258	980,014.48	50.04	14.80
NS-001型	44	24,320,810	615,033.35	23.84	675.81
NS-002型	648	88,207,041	601,298.91	328.25	620.93
NS-001型	240	68,394,231	128,042.16	62.48	12.45

下一步是按命名空间列出每个存储桶及其要迁移的每个存储桶的属性。请注意在该存储桶中存储和读取数据的应用程序。根据使用情况，将每个存储桶分类为热层、暖层或冷层数据。

在删节版中，这看起来像

存储桶名称	性能	应用	热/温/冷层
A	Copy and paste JSON here	Spark, Iceberg, Dremio	热
B	Copy and paste JSON here	Elastic	温
C	Copy and paste JSON here	Elastic 弹性的快照	冷

此时，您需要做出一些关于数据生命周期管理的决定，请密切关注，因为这是节省 AWS 费用的好方法。根据访问频率将每个存储桶中的对象分类为热、暖或冷。一个省钱的好地方是将冷层存储桶直接迁移到 S3 Glacier – 没有理由为了再次上传而产生下载出口费用。

根据要遣返的数据量，您可以通过几个选项来选择迁移方式。我们建议您在新的 MinIO 集群上加载和处理新数据，同时随着时间的推移将热数据和温数据复制到新集群。当然，复制对象所需的时间和带宽将取决于要复制的对象的数量和大小。

在这里，计算要从 AWS S3 传回的总数据将非常有帮助。查看您的库存，并计算所有分类为热桶和暖桶的总大小。

说明
热层和暖层数据总数 = 1,534,096.7 GB
可用带宽 = 10 Gbps
所需的最短传输时间（总对象大小/可用带宽）= 14.2 天

根据上述总额计算数据出口费用。我使用的是标价，但您的组织可能有资格享受 AWS 的折扣。我也使用 10 Gbps 作为连接带宽，但您可能或多或少可以使用。最后，我的假设是，三分之一的 S3 数据将仅转移到 S3 Glacier Deep Archive。

说明
分层到 S3 Glacier 的总数据 = 767048.337GB
S3 到 S3 Glacier 的传输费用（0.05 USD/1000 个对象）= 3773.11USD
S3 Glacier Deep Archive 月度存储费 = 760 USD

不要忘记为 S3 Glacier Deep Archive 的使用量制定预算。

说明
要传输的总数据 = 1,534,096.7 GB
前 10 TB，0.09 USD/GB = 900 USD
接下来的 100 TB，0.07 USD/GB = 70000 USD
超过 150 TB 的额外容量，0.05 USD/GB = 69205 USD
接下来的 40 TB，价格为 0.085 USD/GB = 3400 USD
出口总费用 = 143,504 USD

为简单起见，上述计算既不包括每个对象操作的费用（0.40 美元/1 百万美元），也不包括 LISTing 的成本（5 美元/1 百万美元）。对于非常大的遣返项目，我们还可以在通过网络发送对象之前对其进行压缩，从而为您节省一些出口费用。

另一种选择是使用 AWS Snowball 传输对象。每个 Snowball 设备都是 80TB，因此我们事先知道需要 20 个设备来进行遣返工作。每台设备的费用包括 10 天的使用时间，外加 2 天的运输费用。额外天数为每台设备 30 美元。

说明
20 Snowball 设备服务费（$300 ea） = $6,000
R/T 运费（3-5 天，每台 400 美元）= 8,000 美元
S3 数据输出（0.02 USD/GB）= 30682 USD
Snowball 总费用 = 38981.93 USD

AWS 将向您收取标准请求、存储和数据传输费率，以读取和写入 AWS 服务，包括 Amazon S3 和 AWS Key Management Service （KMS）。使用 Amazon S3 存储类时，还有其他注意事项。对于 S3 导出作业，从 S3 传输到 Snow Family 设备的数据按 LIST、GET 等操作的标准 S3 费用计费。您还需要为 Amazon CloudWatch Logs、Amazon CloudWatch 指标和 Amazon CloudWatch Events 支付标准费率。

现在我们知道迁移如此庞大的数据量需要多长时间以及成本。根据时间和费用的组合，就哪种方法满足您的需求做出业务决策。

在这一点上，我们还知道在本地或托管设施中运行 MinIO 所需的硬件要求。根据上述 1.5PB 存储要求，估计数据增长，并查阅我们的推荐硬件和配置页面和为您的 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 S3 API 调用读取存储桶元数据（包括策略和存储桶属性），然后在 MinIO 中进行设置。当您注册 MinIO SUBNET 时，我们的工程师将与您一起从 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-hold get-object-lock-configuration 等命令来查明需要特殊安全和治理处理的对象。

当我们讨论生命周期时，让我们先谈谈备份和灾难恢复。是否希望复制到其他 MinIO 集群以进行备份和灾难恢复？

将对象从 AWS S3 复制到 MinIO 后，验证数据完整性非常重要。执行此操作的最简单方法是使用 MinIO 客户端对 S3 中的旧存储桶和 MinIO 上的新存储桶运行 mc diff 。这将计算存储桶之间的差异，并仅返回缺少或不同的对象的列表。此命令采用源存储桶和目标存储桶的参数。为方便起见，您可能希望为 S3 和 MinIO 创建别名，这样您就不必不断键入完整的地址和凭证。例如：

mc diff s3/bucket1 minio/bucket1

好消息是，您所要做的就是将现有应用程序指向新的 MinIO 端点。可以在一段时间内逐个应用重写配置。在对象存储中迁移数据比文件系统对数据的干扰要小，只需将 URL 更改为从新集群读/写即可。请注意，如果您以前依赖 AWS 服务来支持您的应用程序，那么这些服务将不会出现在您的数据中心中，因此您必须将它们替换为它们的开源等效项并重写一些代码。例如，Athena 可以替换为 Spark SQL、Apache Hive 和 Presto、Kinesis 和 Apache Kafka 以及 AWS Glue 和 Apache Airflow。

如果您的 S3 迁移是将整个应用程序移动到本地的更大工作的一部分，那么您很可能使用 S3 事件通知在新数据到达时调用下游服务。如果是这种情况，请不要害怕 - MinIO 也支持事件通知。此处最直接的迁移是实现自定义 Webhook 来接收通知。但是，如果您需要更持久和更具弹性的目标，请使用 Kafka 或 RabbitMQ 等消息传递服务。我们还支持将事件发送到 PostgreSQL 和 MySQL 等数据库。

现在您已经完成了遣返，是时候将注意力转向存储操作、监控和优化了。好消息是，MinIO 不需要优化——我们已经在软件中内置了优化功能，因此您知道您的硬件获得了最佳性能。您需要开始监视新的 MinIO 集群，以持续评估资源利用率和性能。MinIO 通过 Prometheus 端点公开指标，您可以在选择的监控和警报平台中使用该端点。有关监控的更多信息，请参阅使用 Prometheus 和 Grafana 进行多云监控和警报，以及使用 OpenTelemetry、Flask 和 Prometheus 使用 MinIO 的指标。