资讯动态

RustFS站点复制跨集群容灾实战:多站点可写异步同步要踩哪些坑

发布时间:2026/9/28 11:48:12 来源:尧图企业网站定制
生产在城市 A容灾在城市 B两边各跑一套对象存储集群。平时各写各的真要切换才发现 B 的数据比 A 旧了半天还得手工补。站点复制Site Replication要解决的正是这件事把多套独立部署组成一套异步多站点复制关系让桶、对象版本和 IAM 自动对齐不用自己写同步脚本。但要先把一件事说在前面否则容易被误读成两套都能随便写、写完了自动合并站点复制支持多站点接受业务写入并不等于它替你做了冲突处理。官方确认的三条事实是每个参与站点都必须支持桶版本控制同步清单里含对象版本包括删除标记而复制是异步的。也就是说同一个对象 key 在两地被先后覆盖时两边各自产生新版本再各自向对端复制最后各留一份历史版本官方没有说明这类冲突该按什么规则合并也没有提供业务层的冲突消解。同一 bucket 的同名 key 尽量不要跨站并发写入这条要写进应用的写入约束而不是指望存储层兜底。它和桶复制不是一回事。桶复制是单个桶上的定向规则源桶 → 目标桶站点复制是在整套部署之间建立更广泛的关系。更要紧的区别在写入方向桶复制是单向的想让两个桶互相复制得在反方向再配一套目标和规则站点复制面向的场景是多个站点都要接受业务写入同时保持存储和身份配置一致。也就是说两个站点都能写写入哪边都会异步同步到其余站点从站点不是只读镜像。把它理解成主写从备的异步主从拓扑是这个功能最容易踩的第一个预期差后面切流量、判冲突、算 RPO 都得按多站点可写的前提来设计。站点复制同步什么官方文档列得很清楚站点复制在关联站点之间同步这几类资源桶与对象版本包括删除标记delete marker。桶元数据站点复制工作流所需的桶级配置。IAM用户、组、策略、策略映射、服务账号。也就是说在一边新建的桶、传的对象、建的 IAM 用户都会出现在另一边。注意同步的是资源定义和对象数据不是站点互相接管流量。对象锁这一块要单独拎出来说容灾场景里它比桶和 IAM 更容易翻车。官方在链接站点前的盘点清单里明确要求排查存储桶名称、对象锁定设置、IAM 身份和策略对象锁定本身也是官方建议的启用前检查项之一。对象锁定文档里有两条更具体的说明值得抄进你的容灾手册复制对象会在目标端创建新的目标版本目标保留策略独立应用不是把原版本的保留设置连带搬过去另外锁定对象的复制目标必须支持兼容的对象锁定行为。还有一条硬约束COMPLIANCE 保留在到期日之前既不能绕过也不能缩短跨站点链路两端的时钟不同步会让两边的保留判定对不上。桶元数据这一项官方写的是站点复制工作流程所需的存储桶元数据范围是被限定过的不是所有桶级配置。官方公开的同步清单里没有列生命周期规则和桶策略这两类配置别默认会自动对齐到对端切换前逐桶核一遍。有一条硬前提参与复制的每个站点都必须开启桶版本控制否则链接会失败。链接之前先满足这些条件官方要求的清单不长但每条都会在出问题时被人想起两个或更多独立的部署且版本提供站点复制 Admin API。每个部署有一个唯一且稳定的 S3 API 端点端口通常 9000。各站点端点之间 S3 API 端口双向网络连通。生产端点使用受信 TLS 证书私有 CA 的话先把 CA 装进管理主机的信任存储。一台安全的运维机上装好 rc 客户端。每个站点都有根管理员凭证且都开启了桶版本控制。还有一条容易踩作为出站请求的安全控制默认拒绝环回loopback复制目标。服务器选项RUSTFS_REPLICATION_ALLOW_LOOPBACK_TARGETtrue官方明说只用于单主机开发和自动化测试生产别开。上一节的要求清单里有一条看起来像顺手加的、其实最该当真链接已有站点前要盘点两边的桶名、对象锁定设置、IAM 身份与策略目的是发现冲突。这里要说清一个官方口径的边界官方文档只提了发现冲突没有说明冲突真的发生时是报错终止、覆盖还是跳过这一块要按你自己的目标数据情况去验证别照着官方说会报错的想象去做演练。真要上现有数据先用两个空测试站点把整条链路跑通再拿一个非生产副本做一次带冲突的预演。双站点链路实操先在 rc 里给两个站点各配一个别名确认都通rcaliassetsite1 https://site1.example.com:9000access-key-1secret-key-1\--regionus-east-1 --bucket-lookup path rcaliassetsite2 https://site2.example.com:9000access-key-2secret-key-2\--regionus-east-1 --bucket-lookup path rc ready site1rc ready site2 rc admin info cluster site1 rc admin info cluster site2确认无误后一条命令把两个站点链接起来。所有参与的别名一次性写进同一条命令执行add命令的第一个站点是这套复制拓扑的管理控制点rc admin replicateaddsite1 site2 rc admin replicate info site1 rc admin replicate info site2 rc admin replicate status site1两个要点超过两个站点时把所有别名一次性写进同一条add命令官方明确说不要用两两配对的方式去拼同一个多站点关系状态检查从单个站点看到的只是该站点对关系的视图不能替代对其他站点的检查。这个管理控制点落到操作上就是一条硬约束后续info、status、resync start、remove这些管理类命令都要向第一个别名所在的那个站点发起而不是随便挑一个站点。修复不可用站点后按部署 ID 启动重新同步rc admin replicate resync start site1--sitedeployment-id--yes这里有一个官方专门加粗提醒的坑重新同步状态不是实时进度。服务端返回的是最近一次启动或取消请求的持久化结果它不检查活跃工作线程生命周期状态报为未知启动操作可能重叠取消操作不幂等网络超时还可能让执行结果变成未知。拿到不明确的结果后先查replicate info、replicate status和目标数据再决定要不要发下一个变更命令。另外官方也直说了删除站点不会提供应用切换也不能证明所有排队对象都已到达remove之后数据缺没缺得自己验。边界与验证站点复制有几个必须心里有数的边界官方文档自己就放在页面开头它是异步的一个站点写成功不代表另一个站点已经拿到副本别当强一致用它不提供 DNS 故障转移、流量路由、应用恢复编排这些都要自己规划站点复制负责数据和对齐不负责切换。带宽这一块有个反直觉的地方值得提前知道官方给限速旋钮的是桶复制rc bucket replication add --bandwidth以及控制台里的 Bandwidth Limit 字段站点复制那套rc admin replicate命令里没有对应的限速参数。跨城链路的带宽要按业务写入速率自己估没有官方旋钮可以事后回调。官方给的判据不是拍脑袋的阈值而是一条实测要求应用写入速度可能超过异步复制别从单个状态样本推断恢复点目标要在实际工作负载下测延迟并针对持续积压发告警也就是说监控应该盯积压是否在持续扩大而不是看某一刻落后了多少。验证时别只信一条status。官方的验证路径是在一个站点建测试桶和对象去另一个站点轮询再比对内容rc bucket create site1/my-bucketprintfhello rustfs\nhello.txt rc object copy hello.txt site1/my-bucket/hello.txt rc objectstatsite2/my-bucket/hello.txt rc object copy site2/my-bucket/hello.txt ./hello-from-site2.txtcmphello.txt hello-from-site2.txtIAM 也建议走一遍完整闭环一个站点建临时用户、挂策略另一个站点查用户和策略映射验证完删掉临时身份rc admin useraddsite1 replication-testtemporary-secret-keyrc admin policy attach site1readonly--userreplication-test rc admin user info site2 replication-test rc admin policy entities site2--userreplication-test rc admin userrmsite1 replication-test真要切换的时候站点复制给不了你什么容灾演练写进 runbook 之前先把三件官方没答的事摆到台面上否则演练会变成碰运气。站点宕机期间其他站点不会自动补上那段写入。异步复制的语义决定了它不承诺这一点官方给的动作只有一条修复可用站点后启动resync。至于 resync 跑的是全量还是增量同步、要跑多久官方文档没有给出明确口径。所以真实可用的做法只有一条在自己的环境里实测一遍断网 → 恢复 → resync的完整链路量出追平耗时再把这个数写进 RTORPO 同理别拍脑袋用实测出来的落后时长去定。演练里任何恢复即追平的假设在没量出这个数之前都不成立。把从站点提为新主不在站点复制的命令集里。官方把 DNS 故障转移、流量路由、应用恢复编排明确划在站点复制之外。replicate edit能改的是站点名称、端点和 TLS 信任设置切流量得靠你自己的 DNS 或负载均衡去完成站点复制只保证数据最终到位。官方还有一句容易被略过提示删除站点不提供应用切换也不能证明所有排队对象都到了。容灾前该做的准备官方给了一份现成清单。对象锁定文档里那句启用保护前请在非生产存储桶中测试策略并验证时间同步、权限、生命周期规则、复制和备份流程正好是站点复制场景下最该跑一遍的演练项尤其是时钟COMPLIANCE 保留在到期前无法绕过也无法缩短两端时钟漂移会让删除保护在两地的判定结果不一致。rc admin replicate add把多套独立部署连成异步同步关系桶、对象版本、IAM 自动对齐跨城容灾少写一堆同步代码。代价同样明确故障转移和应用切换要自己补——它同步数据不接管流量。先用两个空站点把 add、info、status、对象与 IAM 验证完整跑一遍再挂生产数据把复制延迟和跨站点流量成本纳入监控突发写入会临时落后官方的建议是针对持续积压发告警而不是看单次采样。RustFS 已于 2026 年 9 月 16 日发布 1.0.0 正式版站点复制的命令与边界均出自官方文档代码在 GitHub 的 rustfs/rustfs 仓库rc 客户端记得保持与服务器版本一致。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑