推动企业转向云原生对象存储平台的关键需求之一，是在多数据中心设置中使用存储的能力。多个数据中心提供弹性、高可用性存储集群，能够承受一个或多个数据中心的完全故障。多数据中心支持使私有云和混合云基础设施更接近于公共云提供商构建其服务的架构方式，以实现高水平的弹性。

这传统上一直是企业 SAN 和 NAS 供应商（如 NetApp SnapMirror 和 MetroCluster）的领域。

虽然对象存储在许多方面优于这些传统技术，但它一直无法在两个数据中心位置之间提供主动-主动复制。我们相信 MinIO 是唯一一家提供此功能的公司。

MinIO 实际上提供了两种实现此目的的不同方法 - 一种是使用服务器端存储桶复制，另一种是使用客户端 mc 镜像。虽然两种方法都有效，“企业级”解决方案是服务器端复制，因此我们将在这篇文章中重点介绍它。

了解场景

让我们首先看一下这种功能在哪些不同的部署场景中会有价值。至少有四种

• 同数据中心复制
• 跨数据中心复制
• 同区域复制
• 跨区域复制
  
  

特别值得注意的是最后三种。在每种情况下，复制都必须尽可能地接近严格一致性（考虑到带宽考虑因素和变化率）。

基本架构注意事项

在最基本的层面上，任何设计都需要考虑基础设施、带宽、延迟、弹性和规模。让我们依次来看一下

基础设施：MinIO 建议在复制端点两侧使用相同的硬件。虽然类似的硬件可能会执行，但引入异构硬件配置文件会导致复杂性并减缓问题识别。西南航空公司只购买 737 飞机，以消除运营复杂性。请效仿他们的做法。

带宽：适当带宽的确定发生在多个级别（站点之间、客户端与服务器与复制目标之间）。关键是要了解变化率以及已更改数据的数量。清晰地了解这些组件将决定带宽需求。我们建议留出缓冲。例如，如果 10% 的数据发生更改，我们建议使用 20% 的更改率。因此，对于 100 TB 数据，如果更改率为 10%，则建议使用 10 TB，但为了考虑到突发性，我们建议您分配 20 TB 的带宽。不用说，每个组织对此都会有自己的看法。

延迟：在设计主动-主动模型时，延迟是带宽之后最重要的考虑因素。它表示两个 MinIO 集群之间的往返时间 (RTT)。目标应该是将延迟降低到预算约束在带宽方面允许的尽可能小的数字。延迟越低，在发生双边中断时数据丢失的风险就越低。我们建议 RTT 阈值最高为 20 毫秒 - 理想情况下更低。此外，以太网链路和网络的丢包率不应超过 0.01%。在投入生产之前，应彻底测试丢包率和延迟，因为它们会直接影响吞吐量。

架构：目前，MinIO 只建议跨两个数据中心进行复制。可以在多个数据中心之间进行复制，但是，所涉及的复杂性和所需的权衡使得这相当困难。

规模考虑因素：虽然 MinIO 可以支持每个数据中心的非常大的部署，无论对于源还是目标，上述考虑因素都将决定规模。MinIO 在任一位置的扩展方式没有任何变化（即无缝扩展，无需通过区域进行重新平衡）。

服务器端复制

多站点复制从配置需要复制的存储桶开始。需要注意的是，MinIO 不会复制在策略生效之前存在的对象。这意味着您可以配置存储桶进行复制，但如果存在早于该操作的对象，则这些对象将不可用于复制。

要将存储桶中的对象复制到目标站点上的目标存储桶（位于同一集群或不同集群上），首先在源和目标存储桶上创建启用版本控制的存储桶。接下来，需要在 MinIO 服务器上通过设置以下内容来配置目标站点和目标存储桶

mc admin bucket remote add myminio/srcbucket https://accessKey:secretKey@replica-endpoint:9000/destbucket --service “replication” --region “us-east-1”

MinIO 可以复制

• 对象及其元数据（与 MinIO 中的对象原子性写入）。这些对象可以是加密的也可以是未加密的。这受上述关于旧对象的约束。所有者需要相应的权限。
• 对象版本。
• 对象标签（如果有）。
• S3 对象锁定保留信息（如果有）。需要注意的是，源的保留信息将覆盖复制端的任何信息。如果没有保留信息，对象将采用目标存储桶上的保留期。有关对象锁定的更多信息，请查看 这篇博文 或文档。
  

这种实现令人兴奋的是它让以规模提供弹性变得多么容易。我们在这方面实施的一些关键功能包括

• 源存储桶和目标存储桶可以具有相同的名称。这对于应用程序在不造成任何中断的情况下透明地故障转移到远程站点尤其重要。负载均衡器或 DNS 只是将应用程序流量引导到新站点。如果远程存储桶的名称不同，则无法建立透明故障转移功能。这是 Splunk 或 Veeam 等企业应用程序的关键可用性要求。
  
• MinIO 还支持在源存储桶和目标存储桶之间本地开箱即用地自动对象锁定/保留复制。这与其他实现形成鲜明对比，其他实现使得管理非常困难。
  
• MinIO 不需要为 AccessControlTranslation、Metrics 和 SourceSelectionCriteria 配置/权限，从而显着简化操作并减少出错的机会。
  
• MinIO 使用近同步复制，在存储桶发生任何变异后立即更新对象。其他供应商可能需要长达 15 分钟才能更新远程存储桶。 MinIO 在数据中心内遵循严格一致性，在数据中心之间遵循最终一致性，以保护数据。复制性能取决于 WAN 连接的带宽和变异率。只要有足够的带宽，更改就会在提交后立即传播。版本控制功能使 MinIO 能够像不可变数据存储一样工作，以轻松地合并主动-主动配置中的更改。在完全数据中心故障的情况下，能够无延迟地推送更改对于保护企业数据至关重要。
  
• MinIO 还扩展了通知功能，以推送复制故障事件。应用程序可以订阅这些事件并提醒运维团队。有关这方面的文档，请参见 此处。
  

正如我们提到的，MinIO 的 mc 镜像功能也可以提供类似的功能。那么，为什么我们还要投入时间和精力来做得更多呢？

性能和简易性。将复制功能移至服务器端使复制能够跟踪源处的更改并直接将对象推送到远程存储桶。相比之下，mc 镜像必须订阅 lambda 事件通知以获取更改并下载对象以推送。最终，服务器端更快、更高效。此外，服务器端方法更易于设置和管理，无需额外的容器或服务器。不需要额外的工具或服务。

因此，我们建议今后使用服务器端复制。

操作方法

本节说明如何将所有上传到sourceAlias 上的srcbucket 存储桶的上传复制到destAlias 别名标识的端点 https://replica-endpoint:9000 上目标 MinIO 集群上的destbucket 存储桶。这里，源集群和目标集群都需要以擦除或分布式模式运行 MinIO。作为设置复制的先决条件，请确保源存储桶和目标存储桶已启用版本控制，使用 `mc version enable` 命令。

源存储桶需要使用以下最小策略进行配置

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Action": [
    "s3:GetReplicationConfiguration",
    "s3:ListBucket",
    "s3:GetBucketLocation",
    "s3:GetBucketVersioning"
   ],
   "Resource": [
    "arn:aws:s3:::srcbucket"
   ]
  }
}

在目标端，创建一个复制用户 `repluser`，并在destbucket 上为该用户设置用户策略，该策略具有对该策略中列出的操作的权限，作为复制的最低要求

$ mc admin user add destAlias repluser repluserpwd
$ cat > replicationPolicy.json << EOF
{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Action": [
    "s3:GetBucketVersioning"
   ],
   "Resource": [
    "arn:aws:s3:::destbucket"
   ]
  },
  {
   "Effect": "Allow",
   "Action": [
    "s3:ReplicateTags",
    "s3:GetObject",
    "s3:GetObjectVersion",
    "s3:GetObjectVersionTagging",
    "s3:PutObject",
    "s3:ReplicateObject"
   ],
   "Resource": [
    "arn:aws:s3:::destbucket/*"
   ]
  }
 ]
}

EOF

$ mc admin policy add destAlias replpolicy ./replicationPolicy.json
$ mc admin policy set dest replpolicy user=repluser

在源集群上为上面创建的复制用户创建一个复制目标

$ mc admin bucket remote add myminio/srcbucket https:/repluser:repluserpwd@replica-endpoint:9000/destbucket --service “replication” --region “us-west-1”
Replication ARN = 'arn:minio:replication:us-west-1:28285312-2dec-4982-b14d-c24e99d472e6:destbucket'

请注意，运行此命令的管理员除了对srcbucket指定的权限外，还需要在源集群上拥有s3:PutReplicationConfiguration权限。成功创建并授权后，服务器会生成一个复制目标 ARN。以下命令列出了所有当前已授权的复制目标

$ mc admin bucket remote ls srcAlias/srcbucket --service replication

使用此 ReplicationARN，您可以启用存储桶，以将服务器端复制到目标destbucket存储桶。

使用上面生成的复制 ARN，在srcAlias上的srcbucket添加一个复制规则

$ mc replicate add srcAlias/srcbucket --remote-bucket destbucket --priority 1 --arn arn:minio:replication:us-west-1:28285312-2dec-4982-b14d-c24e99d472e6:destbucket

可以使用以上命令设置多个规则，并使用可选的前缀和标签过滤器，以选择性地对存储桶中的对象子集执行复制。如果有多个重叠规则，则使用优先级最高的匹配规则。

可以使用命令`mc replicate export`查看创建的复制策略

{
  "Role" : "arn:minio:replication:us-west-1:28285312-2dec-4982-b14d-c24e99d472e6:destbucket",
  "Rules": [
    {
      "Status": "Enabled",
      "Priority": 1,
      "DeleteMarkerReplication": { "Status": "Disabled" },
      "Filter" : { "Prefix": ""},
      "Destination": {
        "Bucket": "arn:aws:s3:::destbucket",
        "StorageClass": "STANDARD"
      }
    }
  ]
}

MinIO 的存储桶复制 API 和 JSON 复制策略文档与 Amazon S3 的规范兼容。MinIO 在此处使用角色 ARN 来支持复制到另一个 MinIO 目标。任何上传到源存储桶并满足复制条件的对象现在将由 MinIO 服务器自动复制到远程目标存储桶。可以通过禁用配置中的特定规则或完全删除复制配置来随时禁用复制。MinIO 客户端实用程序 (mc) 提供管理服务器端存储桶复制功能所需的所有命令，便于 DevOps 工具和自动化。

从源存储桶中删除对象时，副本不会被删除，除非启用了删除标记复制。即将推出的功能允许通过将删除标记和版本化删除复制到目标来实现完全的主动-主动复制，前提是`mc replicate add`命令指定带有“delete-marker”或“delete”选项（或两者）的`--replicate`标志。

在将对象锁定与复制结合使用时，源存储桶和目标存储桶都需要启用对象锁定。类似地，在服务器端使用 SSE-S3 加密的对象将在目标也支持加密的情况下进行复制。

可以使用`mc stat`命令查看源对象和目标对象元数据中的复制状态。在源端，复制尝试成功或失败后，X-Amz-Replication-Status 将从 PENDING 变为 COMPLETE 或 FAILED。在目标端，REPLICA 的 X-Amz-Replication-Status 状态表明对象已成功复制。 任何失败的对象复制操作将在稍后定期重新尝试。MinIO 的存储桶复制功能能够抵御网络和远程数据中心中断。

详细信息

如我们所述，我们相信我们是第一个提供对象存储的主动-主动复制的公司。这意味着我们有一些细节需要说明，以确保您的成功。我们将以问题的形式来阐述这些细节。如果您想添加更多问题，请随时发送邮件到 hello@min.io

复制目标宕机时会发生什么？

如果目标宕机，源将缓存更改并在复制目标恢复后开始同步。根据宕机时间、更改次数、带宽和延迟，可能需要一些时间才能完成完全同步。

如果爬虫宕机或被禁用会发生什么？

我们计划将其删除。它是一个环境变量，由于 Seagate 的坚持而添加。可以将其删除。

不变性的参数是什么？

不变性是一个非常有价值的功能，MinIO 很高兴支持它。我们建议您熟悉这些概念以及我们在本 帖子 中是如何实现它们的。需要注意的是，在主动-主动复制模式下，只有在对对象进行版本化的情况下才能保证不变性。源不能禁用版本化。如果目标上的版本化被挂起，MinIO 将开始失败复制。不变性需要版本化…

如果版本化被挂起或存在不匹配，其他影响是什么？

在这些情况下，复制可能会失败。例如，如果您尝试在源存储桶上禁用版本化，则会返回错误。您必须先删除复制配置，然后才能在源存储桶上禁用版本化。此外，如果您在目标存储桶上禁用版本化，复制也会失败。源对象将返回复制状态 Failed。

如果对象锁定未在两端启用，如何处理？

如果两端都没有配置对象锁定设置，则可能会出现不一致的情况。MinIO 会在此情况下静默失败。必须在源和目标上都启用对象锁定。有一个特殊情况。如果在设置存储桶复制后，可以删除目标存储桶，然后（新建一个？）创建一个未启用对象锁定的存储桶——复制可能会失败。

如果凭证更改会发生什么？

如果目标的凭证更改，所有操作都会失败。如果存储在源上的目标凭证更改，复制将失败，因为访问凭证已更改。所有凭证都需要在源上更新/保持最新，才能继续进行复制。

结论

在这篇文章中，我们演示了如何有效地设计一个主动-主动的双数据中心 MinIO 部署，以确保一个弹性和可扩展的系统，能够在不影响最终用户的情况下承受数据中心故障。这种架构经过验证，并且已经在我们的客户和用户中得到了广泛的部署，为现代企业提供了一种简单而有效的机制来构建大型存储系统。

我们始终鼓励您通过 下载 MinIO 亲身体验。如果您有任何问题，请查看 我们的文档 和我们很棒的 Slack 频道。要了解获得 MinIO 商业许可证的费用，请查看 定价页面。