对我们之前帖子的回应， ，这很了不起——我们接到了数十个企业的电话，要求我们提供遣返建议。我们已将这些回复汇总到这篇新文章中，在其中我们更深入地探讨了与遣返相关的成本和节省，以便您更轻松地进行自己的分析。数据迁移对许多人来说是一项艰巨的任务。实际上，他们的目标是将新数据转移到 MinIO，并花大量时间将旧数据从云中迁移出来，或者将其留在原地，不增长。 如何从 AWS S3 迁移到 MinIO 遣返概述 要从 AWS S3 遣返数据，您需要遵循以下一般准则： 确定需要从 AWS S3 遣返的特定存储桶和对象。确保您了解每个存储桶的业务需求和合规性要求。 审查数据要求： 您已经决定将数据遣返到 MinIO，现在您可以选择在本地数据中心或其他云提供商或主机托管设施中运行 MinIO。使用 #1 中的要求，您将选择硬件或实例来满足预测的存储、传输和可用性需求。 确定遣返目的地： 规划并执行从 AWS S3 到 MinIO 的数据传输。只需使用 MinIO 内置的批量复制或使用 MinIO 客户端进行镜像即可（请参阅 了解详情）。您还可以使用其他几种方法进行数据传输，例如使用 AWS DataSync、AWS Snowball 或 或者直接使用 AWS API。 数据传输： 如何从 AWS S3 迁移到 MinIO TD SYNNEX 数据迁移 确保为每个存储桶设置适当的访问控制和权限，包括用于管理用户访问、身份验证和授权的 IAM 和存储桶策略，以确保数据的安全。 数据访问和权限： 在迁移后保留对象锁定和合法保留策略至关重要。目标对象存储必须以与 Amazon S3 相同的方式解释规则。如果您不确定，请询问 在目标对象存储实现上。 对象锁定： Cohasset Associates 合规性评估 为遣返数据定义并实施数据生命周期管理策略。这包括定义保留策略、备份和恢复程序以及基于每个存储桶的数据归档实践。 数据生命周期管理： 验证传输的数据以确保其完整性和完整性。执行必要的检查和测试，以确保数据已成功传输且没有任何损坏或丢失。传输后，源和目标之间的对象名称、ETag 和元数据、校验和以及对象数量均匹配。 数据验证： 好消息是，如果您遵循云原生原则来构建应用程序，那么您所要做的就是为新的 MinIO 端点重新配置它们。但是，如果您的应用程序和工作流程设计为与 AWS 生态系统配合使用，请进行必要的更新以适应遣返数据。这可能涉及更新配置、重新配置集成或在某些情况下修改代码。 更新应用程序和工作流程： 持续监控和优化遣返数据环境，以确保最佳性能、成本效益并遵守数据管理最佳实践。 监控和优化： 遣返步骤 在制定云遣返预算和计划时，需要考虑许多因素。幸运的是，我们的工程师已经与许多客户一起完成了这项工作，并且我们为您制定了详细的计划。我们的客户已经遣返了从少量工作负载到数百 PB 的所有内容。 最大的规划任务是仔细考虑网络、租用带宽、服务器硬件、未选择遣返的数据的归档成本以及管理和维护您自己的云基础设施的人力成本。估算这些成本并制定计划。云遣返成本将包括将数据从云中移回数据中心的数据传出费用。这些费用故意定得足够高，以迫使云锁定。请注意这些高额的传出费用 - 它们证实了离开公共云的经济理由，因为随着您管理的数据量的增长，传出费用也会增加。因此，如果您要遣返，尽早采取行动是值得的。 我们将重点关注必须移动的数据和元数据——这是遣返所需工作的 80%。元数据包括存储桶属性和策略（基于访问/密钥的访问管理、生命周期管理、加密、匿名公共访问、对象锁定和版本控制）。 现在让我们关注数据（对象）。对于要迁移的每个命名空间，盘点要移动的存储桶和对象。您的 DevOps 团队可能已经知道哪些存储桶包含重要的当前数据。您还可以使用 从高层次来看，这看起来像这样： Amazon S3 库存 命名空间 总桶数 总对象数 总对象大小 (GB) 每日总上传量 (TB) 每日总下载量 (TB) ns-001 166 47,751,258 980,014.48 50.04 14.80 ns-002 四十四 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 在此处复制并粘贴 JSON Spark、Iceberg、Dremio 热的 乙 在此处复制并粘贴 JSON 松紧带 温暖的 C 在此处复制并粘贴 JSON 弹性（快照） 寒冷的 此时您需要对数据生命周期管理做出一些决定，并密切关注，因为这是节省 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 的总数据 = 767,048.337 GB S3 至 S3 Glacier 的转移费用（$0.05/1000 个对象）= $3,773.11 S3 Glacier Deep Archive 每月存储费用 = 760 美元 不要忘记为今后的 S3 Glacier Deep Archive 使用做好预算。 要传输的总数据 = 1,534,096.7 GB 前 10 TB 价格为 0.09 美元/GB = 900 美元 接下来的 40 TB，价格为 0.085 美元/GB = 3,400 美元 接下来的 100 TB，价格为 0.07 美元/GB = 70,000 美元 超过 150 TB 的额外费用为 0.05 美元/GB = 69,205 美元 总出口费用 = 143,504 美元 为简单起见，上述计算既不包括每个对象操作的费用（0.40 美元/100 万），也不包括 LISTing 的费用（5 美元/100 万）。对于非常大的遣返项目，我们还可以在通过网络发送对象之前对其进行压缩，从而为您节省部分出口费用。 另一种选择是使用 AWS Snowball 传输对象。每台 Snowball 设备容量为 80TB，因此我们事先知道我们需要 20 台设备用于遣返工作。每台设备的费用包括 10 天的使用费和 2 天的运输费。每台设备可额外支付 30 美元。 20 台 Snowball 设备服务费（每台 300 美元）= 6,000 美元 R/T 运费（3-5 天，每台设备 400 美元）= 8,000 美元 S3 数据输出（0.02 美元/GB）= 30,682 美元 总雪球费用 = 38,981.93 美元 AWS 将向您收取标准请求、存储和数据传输费率以读取和写入 AWS 服务，包括 和 . 使用时还需进一步考虑 。对于 S3 导出任务，从 S3 传输到您的 Snow 系列设备的数据将按照标准 S3 费用对 LIST、GET 等操作进行计费。您还需要按照标准费率支付 Amazon CloudWatch Logs、Amazon CloudWatch Metrics 和 Amazon CloudWatch Events 的费用。 亚马逊 S3 AWS 密钥管理服务 (KMS) Amazon S3 存储类别 现在我们知道了迁移如此大量的数据需要多长时间以及成本。根据时间和费用的组合，做出业务决策，确定哪种方法符合您的需求。 此时，我们还知道在本地或托管设施中运行 MinIO 所需的硬件要求。以上述 1.5PB 存储要求为例，估算数据增长，并咨询我们的 页面和 。 推荐的硬件和配置 为你的 MinIO 部署选择最佳硬件 第一步是在 MinIO 中重新创建 S3 存储桶。无论您选择如何迁移对象，都必须执行此操作。虽然 S3 和 MinIO 都使用服务器端加密存储对象，但您不必担心迁移加密密钥。您可以使用以下方式连接到您选择的 KMS 这样，当在 MinIO 中创建加密租户和存储桶时，将自动为您生成新密钥。 MinIO KES 管理加密密钥 您有多种复制对象的选项：批量复制和 。我之前的博客文章， 包括两种方法的详细说明。您可以将对象直接从 S3 复制到本地 MinIO，或者使用在 EC2 上运行的临时 MinIO 集群来查询 S3，然后镜像到本地 MinIO。 mc mirror 如何从 AWS S3 迁移到 MinIO 通常，客户使用我们编写的工具结合 AWS Snowball 或 TD SYNNEX 的数据迁移硬件和服务来移动更大量的数据（超过 1 PB）。 MinIO 最近与 Western Digital 和 TD SYNNEX 合作推出了 Snowball 替代方案。客户可以安排窗口来接收 Western Digital 硬件，并在租赁期间支付所需的费用。更重要的是，该服务不与特定云绑定 - 这意味着企业可以使用该服务将数据移入、移出和跨云 - 所有这些都使用无处不在的 S3 协议。有关该服务的更多详细信息，请访问 TD SYNNEX 网站上的页面。 数据迁移服务 可以使用 读取存储桶元数据，包括策略和存储桶属性 然后在 MinIO 中进行设置。当您注册 MinIO SUBNET 时，我们的工程师将与您合作从 AWS S3 迁移这些设置：基于访问密钥/密钥的访问管理、生命周期管理策略、加密、匿名公共访问、不变性和版本控制。关于版本控制的一点说明，迁移数据时通常不会保留 AWS 版本 ID，因为每个版本 ID 都是内部 UUID。这对客户来说基本上不是问题，因为对象通常是按名称调用的。但是，如果需要 AWS 版本 ID，那么我们有一个扩展可以将其保留在 MinIO 中，我们将帮助您启用它。 get-bucket S3 API 调用 特别注意 。S3 不会成为您留下的唯一 AWS 基础设施部分。您将拥有许多服务账户，供应用程序在访问 S3 存储桶时使用。这将是列出和审核所有服务账户的好时机。然后，您可以决定是否在身份提供商中重新创建它们。如果您选择自动化，则使用 Amazon Cognito 与外部 OpenID Connect IDP 和 AD/LDAP 共享 IAM 信息。 IAM 和存储桶策略 特别注意数据生命周期管理，例如对象保留、对象锁定和存档/分层。在每个存储桶上运行 以获取人性化可读的生命周期规则 JSON 列表。您可以使用 MinIO 控制台或 MinIO 客户端 (mc) 轻松重新创建 AWS S3 设置。使用 和 等命令来精确定位需要特殊安全和治理处理的对象。 get-bucket-lifecycle-configuration get-object-legal-hold get-object-lock-configuration 既然我们讨论的是生命周期，那么我们先来谈谈备份和灾难恢复。您是否想要一个额外的 MinIO 集群进行复制，以进行备份和灾难恢复？ 将对象从 AWS S3 复制到 MinIO 后，验证数据完整性非常重要。最简单的方法是使用 MinIO 客户端对 S3 中的旧存储桶和 MinIO 上的新存储桶运行 。这将计算存储桶之间的差异并返回仅包含缺失或不同的对象的列表。此命令接受源存储桶和目标存储桶的参数。为方便起见，您可能需要创建 适用于 S3 和 MinIO，这样您就不必一直输入完整的地址和凭据。例如： mc diff 别名 mc diff s3/bucket1 minio/bucket1 好消息是，您所要做的就是将现有应用程序指向新的 MinIO 端点。可以在一段时间内逐个应用程序重写配置。在对象存储中迁移数据的破坏性比文件系统小，只需将 URL 更改为从新集群进行读/写即可。请注意，如果您以前依赖 AWS 服务来支持您的应用程序，那么这些服务将不会出现在您的数据中心中，因此您必须用其开源等效服务替换它们并重写一些代码。例如，Athena 可以替换为 Spark SQL、Apache Hive 和 Presto、Kinesis 替换为 Apache Kafka，AWS Glue 替换为 Apache Airflow。 如果你的 S3 迁移是将整个应用程序迁移到本地的更大努力的一部分，那么你很可能会使用 当新数据到达时调用下游服务。如果是这种情况，那么不要担心 - MinIO 支持 以及。这里最直接的迁移是实现自定义 webhook 来接收通知。但是，如果您需要更持久和更具弹性的目标，请使用 Kafka 或 RabbitMQ 等消息服务。我们还支持将事件发送到 PostgreSQL 和 MySQL 等数据库。 S3 事件通知 事件通知 现在您已经完成遣返，是时候将注意力转向存储操作、监控和优化了。好消息是 MinIO 不需要优化——我们已经将优化内置到软件中，因此您知道您的硬件获得了最佳性能。您需要开始监控新的 MinIO 集群，以持续评估资源利用率和性能。MinIO 公开 通过 Prometheus 端点，您可以在 有关监控的更多信息，请参阅 和 。 指标 首选监控和警报平台 使用 Prometheus 和 Grafana 进行多云监控和警报 使用 OpenTelemetry、Flask 和 Prometheus 对 MinIO 进行度量 和 ，我们会支持你 使用 MinIO。订阅者可以使用内置的自动故障排除工具来保持集群平稳运行。他们还可以通过我们的支持门户获得无限的、直接面向工程师的实时支持。我们还通过年度架构审查帮助您确保对象存储投资的未来发展。 子网 第二天的运营 迁移并保存 向云提供商开空头支票的日子已经一去不复返，这早已不是什么秘密了。许多企业目前正在评估其云支出，以寻找潜在的节省空间。现在，您已经拥有从 AWS S3 迁移到 MinIO 所需的一切，包括具体的技术步骤和财务框架。 如果您对节省遣返成本的前景感到兴奋，请联系我们 。 你好@min.io 也出现 。 在这里

該音頻是用故事的原始語言製作的！

太長; 讀書

Developers: Build Less. Deliver More. [Learn how]	

从 AWS S3 迁移到 MinIO 所需了解的一切

太長; 讀書

People Mentioned

MinIO

About Author

標籤

Languages

这篇文章刊登在...

从 AWS S3 迁移到 MinIO 所需了解的一切

太長; 讀書

People Mentioned

MinIO

About Author

標籤

Languages

这篇文章刊登在...

相關故事