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

传统上，这是企业SAN和NAS供应商的领域，例如NetApp SnapMirror和MetroCluster。

尽管对象存储在许多方面都优于这些传统技术，但到目前为止，它无法跨两个数据中心位置提供Active Active Replication。我们认为MinIO是唯一提供此功能的公司。

MinIO实际上提供了两种不同的方法来实现这一目标-一种是通过服务器端存储桶复制，另一种是通过客户端mc镜像。两者都可以使用时，“企业级”解决方案是服务器端复制，因此，本文将重点介绍这种解决方案。

了解方案

让我们首先看一下该功能将很有价值的不同部署方案。至少有四个：

• 相同DC复制

• 跨DC复制

• 同区域复制

• 跨区域复制
  
  

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

基本架构考量

在最基本的水平上，任何设计都需要考虑基础架构，带宽，延迟，弹性和规模。让我们按顺序进行：

基础架构： MinIO建议在复制端点的两侧使用相同的硬件。尽管可能会执行类似的硬件，但引入异构硬件配置文件会引入复杂性并减慢问题识别的速度。西南航空仅购买737飞机是为了消除操作的复杂性。跟随他们的领导。

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

延迟：在带宽之后，延迟是设计双活模型时最重要的考虑因素。它表示两个MinIO群集之间的往返时间（RTT）。目标应该是在带宽施加的预算限制内将延迟降低到最小的可能值。延迟越短，在双面中断的情况下丢失任何数据的风险就越低。我们建议高端的RTT阈值为20ms-理想情况下应更短。此外，对于以太网链路和网络，数据包丢失均不应超过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 mirror必须订阅lambda事件通知以进行更改并下载要推送的对象。最终，服务器端更快，更高效。此外，服务器端方法更易于设置和管理，而无需其他容器或服务器。不需要额外的工具或服务。

因此，我们建议继续进行服务器端复制。

如何

本节将展示如何将所有上传到斗srcbucket上sourceAlias可以复制到destbucket终点处的目标MinIO集群上斗  https：//开头副本端点：9000鉴定别名destAlias。在这里，源群集和目标群集都需要以擦除或分布式模式运行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/*"
   ]
  }
 ]
}

紧急行动

$ 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

可以使用上述命令以及可选的前缀和标记过滤器设置多个规则，以选择性地对存储桶中的一部分对象进行复制。如果有多个重叠规则，则使用具有最高优先级的匹配规则。

可以使用命令“ mcplicat 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工具和自动化来管理服务器端存储桶复制功能。

从源存储桶中删除对象后，除非启用了删除标记复制功能，否则不会删除副本。即将发布的功能可以通过将删除标记和版本删除操作复制到目标来实现完全主动-主动复制，如果“ mcplicate 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：

复制目标出现故障时会发生什么？

如果目标关闭，则源将缓存更改并在复制目标恢复后开始同步。达到完全同步的时间可能会有所延迟，具体取决于时间长度，更改次数，带宽和延迟。

如果搜寻器掉线或被禁用，会发生什么？

我们计划将其删除。这是由于希捷的坚持而添加的环境变量。可以将其删除。

不变性有哪些参数？

不变性是一项非常有价值的功能，MinIO很高兴支持这一功能。我们建议您熟悉自己的概念和我们如何在这个实现他们后。应当注意，在双活复制模式下，只有在对对象进行版本控制的情况下，才能保证不变性。无法在源上禁用版本控制。如果目标上的版本控制被挂起，则MinIO将开始复制失败。不变性要求版本控制…

如果版本控制被暂停或不匹配，还有什么其他含义？

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

如果双方都未启用对象锁定，该如何处理？

如果没有在两端配置对象锁定设置，则可能会导致不一致。在这种情况下，MinIO将无声地失败。必须在源和目标上都启用对象锁定。有一个极端的情况。如果在设置存储桶复制后，可以删除目标存储桶，并在未启用对象锁定的情况下创建（A NEW ONE？），则复制失败。

如果凭据更改，会发生什么？

如果目标的凭据发生更改，则所有操作都会失败。如果存储在源上的目标凭据发生更改，则复制将失败，因为访问凭据已更改。所有凭证都需要在源上更新/最新，以使复制继续起作用。

结论

在本文中，我们演示了如何有效设计一个主动-主动两个数据中心MinIO部署，以确保可复原且可扩展的系统能够承受DC故障，而最终客户无需停机。这种架构已被我们的客户和用户证明并已经在野外部署，并为现代企业构建大型存储系统提供了一种简单而有效的机制。

与往常一样，我们鼓励您今天下载MinIO，亲自尝试一下。如果您有任何疑问，请查看我们的文档和令人惊叹的Slack频道。要了解获得MinIO商业许可证需要多少费用，请查看定价页面。