对象存储介绍之:Bucket replication
s3 bucket replication功能介绍
bucket replication实现了两个bucket中的object的数据复制,包括对象的元数据的复制。这两个bucket可以位于在一个不同的region,也可以在同一个region的不同AZ里。
bucket replication的应用场景:
- 灾备:传统的两地三中心的数据容灾模式,本地两个AZ实现数据的同步复制,本地和异地(不同的Region)实现异步数据复制实现数据灾备。
- 本地访问:重要或者热点数据复制在不同的Region中,客户可以实现数据的就近访问。
- 法规遵从:数据安全和数据的本地访问等其它法律规定。
Bucket使用条件
- 源端和目标端的必须有访问和复制权限
- bucket的配置要求:source和destination buckets必须 开启多版本 ;source和destination buckets的 S3 Object Lock 配置必须相同。
Replication的内容
- bucket中的对象
- 非加密的对象
- 通过SSE-C,SSE-S3,SSE-KMS加密的对象
- 对象的metadata
- 对象的ACL
- Object TAG
- S3 Object Lock
bucket replication不会复制的内容
- bucket中的对象没有访问权限
- Updates to bucket-level subresources:例如生命周期的规则,这样可以使源端和目标端的bucket有不同的生命周期规则
- Actions performed by lifecycle configuration:由生命周期规则触发的操作
删除操作如何应对?
由于bucket replication中的bucket必须开启多版本,所以删除操作有两种:
- Delete Marker操作:最新的版本中Delete Marker操作不会复制;如果需要复制,可以在复制规则中选项中开启。如果删除操作是由Lifecycle规则触发,则不会删除。
- 如果是删除指定版本的object,该操作不会复制。也就是目标端不会删除该版本的对象。这样设计的目的可以防止源端恶意删除。
Minio Bucket replication介绍
minio的bucket replication有两种实现方式:server-side replication和client-side replication。本文主要介绍bucket replication的实现。
server-side bucket replication可以实现同一个minio cluster集群中的两个bucket之间的数据同步,或者不同的minio cluster之间两个bucket之间的数据同步。minio通过在bucket层面设置一些规则,minio在server端应用这些规则来实现bucket数据的同步:这些数据包括object,object meta,object lock等。
client-side bucket replication是在mc管理进程中实现的数据同步的功能。它可以实现任何两个实现了s3-compatible接口的对象存储集群,这个功能就可以使数据同步扩展到其他公有云的存储中。
minio bucket replication实现了类似Amazon S3 bucket replication,但是增加了一些特性:
- Source and destination bucket names can match, supporting site-to-site use cases such as Splunk or Veeam BC/DR.
- Simplified implementation than S3 bucket replication configuration, removing the need to configure settings like AccessControlTranslation, Metrics, and SourceSelectionCriteria.
- Active-Active (Two-Way) replication of objects between source and destination buckets.
- Multi-Site replication of objects between three or more MinIO deployments
Replication of Delete Operations
minio支持删除操作的复制:包括Delete Version Object和Delete Marker Object两种。Delete Operation Replication操作其他复制流程是一样的。minio默认并不开启着两个操作的复制,需要显示的开启version delete和Delete marker两种replication。
对于version delete操作,mino的实现通过
X-Minio-Replication-Delete-Status
元数据来跟踪其复制的状态。minio先删除remote端的对象,然后删除本地的对象。
Minio只复制来自客户端发起的删除对象的请求。对于基于生命周期规则的删除操作,不会产生复制请求到remote端。Minio希望local和remote端的bucket的生命周期规则应该一致,避免产生不一致的操作结果。
Replication of Existing Objects
在默认情况下,minio不支持已经存在的对象的复制。也就是说对象在replication规则配置前或者replication规则disable时上传的对象并不会产生复制。从版本 mc RELEASE.2021-06-13T17-48-22Z and minio RELEASE.2021-06-07T21-40-51Z 版本开始支持。其原理都是全量扫描bucket中的对象。
整个全量同步完成的时间取决于几个因素:集群的工作负载, 复制任务的负载, 对象的数量。
One-Way and Two Way replication
Minio支持active-passive和active-active两种模式的复制。这两种模式实现没有本质区别。active-active就创建两条复制规则:一个从源端到目标端,一个从目标端到源端的复制规则。
Synchronous vs Asynchronous Replication
Minio支持同步和异步两种复制模式。默认为异步复制模式。
所谓的异步复制就是:客户端的putObject的操作只在本地minio cluster中完成,并把该replication请求添加到本地的replication queue中就返回客户端操作成功。由于这个replication queue是在minio server的内存中请求队列。如果minio server发送了crash问题,就会导致复制请求丢失,local和remote集群中的对象不一致的问题。同步的复制指replication操作在remote端成功完成后才向客户端返回,这当然会产生严重的性能损耗的问题。
Resynchronization (Disaster Recovery)
当本地minio cluster全部或者部分数据丢失,就需要保存在remote target的数据来恢复本地的数据。minio通过命令来实现本地数据的全量的同步。
具体实现
Minio内部实现了replication queuing system,就是minio server内部内存队列,并没有实现持久化存储。通过多个工作worker不断的实现复制任务。
每个对象会有一个元数据字段X-Amz-Replication-Status,用于保存复制的状态,其状态有如下几种:
- PENDING:等待复制
- COMPLETED:复制完成
- FAILED:复制失败
- REPLICA:本身是副本
从版本 RELEASE.2022-08-11T04-37-28Z 开始,对应处于 Failed or pending状态,minio会在list 或者GET,HEAD操作时自动检测状态,并重新添加到replication queue中。
参考资料: