擦除码计算器 
参考硬件 从 AWS S3 到 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 库存。从总体上看，它将类似于
下一步是按命名空间列出要迁移的每个存储桶及其属性。请注意存储和读取该存储桶中数据的应用程序。根据使用情况，将每个存储桶归类为热、温或冷层数据。
简而言之，它将类似于
此时，您需要做出一些关于数据生命周期管理的决策，并密切关注，因为这是一个节省 AWS 费用的好方法。根据访问对象的频率，将每个存储桶中的对象分类为热、温或冷。**节省费用的一个好方法是将冷层存储桶直接迁移到 S3 Glacier - 没有理由为了再次上传而产生下载的传出费用。**
根据要迁移的数据量，您可以选择几种迁移方法。我们建议您在新的 MinIO 集群上加载和处理新数据，同时随着时间的推移将热数据和温数据复制到新集群。复制对象所需的时间和带宽将取决于要复制的对象数量和大小。
在这里，计算要从 AWS S3 迁移回本地的总数据量将非常有帮助。查看您的清单并计算所有分类为热和温的存储桶的大小。
根据上述总计计算数据传出费用。我使用的是 标价，但您的组织可能有资格获得 AWS 的折扣。我还使用 10 Gbps 作为连接带宽，但您可能拥有更多或更少的带宽。最后，我假设三分之一的 S3 数据将仅转移到 S3 Glacier 深度归档。
不要忘记为今后使用 S3 Glacier 深度归档编制预算。
为简单起见，上述计算不包括每个对象操作的费用（$0.40/100 万）以及 LIST 的成本（$5/100 万）。对于非常大的迁移回本地项目，我们还可以在发送对象之前对其进行压缩，从而节省部分传出费用。
另一种选择是使用 AWS Snowball 传输对象。Snowball 设备每个 80 TB，因此我们事先知道我们的迁移回本地工作需要 20 个这样的设备。每个设备的费用包括 10 天的使用时间，以及 2 天的运输时间。额外的天数每个设备需支付 $30。
AWS 将向您收取标准请求、存储和数据传输费率，以读取和写入 AWS 服务，包括 Amazon S3 和 AWS 密钥管理服务 (KMS)。在使用 Amazon S3 存储类别 时，还需要考虑其他因素。对于 S3 导出作业，从 S3 传输到您的 Snow Family 设备的数据将按标准 S3 费用计费，用于 LIST、GET 等操作。您还将按标准费率支付 Amazon CloudWatch Logs、Amazon CloudWatch Metrics 和 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-bucketS3 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 创建别名，这样您就不必一直键入完整的地址和凭据。例如
好消息是，您只需将现有应用程序指向新的 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 指标。
有了SUBNET，在进行 MinIO 的第 2 天操作时，我们始终为您提供支持。订阅者可以访问内置的自动化故障排除工具，以确保其集群平稳运行。他们还可以通过我们的支持门户实时获得无限的、直接面向工程师的支持。我们还将帮助您通过年度架构审查来保护您的对象存储投资。
迁移并节省成本
毫无疑问，向云提供商无限开支的日子已经一去不复返了。许多企业目前正在评估其云支出，以寻找潜在的节省机会。现在，您拥有了从 AWS S3 迁移到 MinIO 所需的一切，包括具体的技术步骤和财务框架。
如果您对迁移带来的成本节约前景感到兴奋，请通过hello@min.io与我们联系。