RustFS 滚动升级节点期间如何处理 503 降级响应【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs在对 erasure-coded纠删码多节点 RustFS 集群做滚动升级或逐台重启时先启动的节点很可能在集群还没凑齐仲裁quorum前就进入降级模式进程不会退出但 S3 请求会收到503 Service Unavailable。这篇文章说明这种 503 是什么、如何判断节点在等什么依赖、以及滚动升级期间应该怎么做才能让集群平稳恢复。依据的文档是 rolling-restart.md 和 readiness-matrix.md。升级前先理解 503 降级的来源纠删码会把每个对象包括.rustfs.sys下的 IAM 用户、组、策略等内部元数据分片写入一个 set 内多块磁盘。读回对象需要读仲裁数量的分片在线。当一个 set 的磁盘分布在多个节点上时单个节点永远无法满足读仲裁——这是纠删码的属性不是故障。因此集群要等到足够多的节点上线后才可读这也是升级期间出现 503 的根本原因。在混合版本的滚动升级窗口内还有一个硬性约束所有会让旧版本二进制无法读取新格式的功能开关必须全程保持关闭状态。文档列出的版本下限version floor包括功能开关激活条件激活后的后果Local SSE wrapped-DEK JSON envelope新版本默认启用 JSON envelope旧节点无法读取用 JSON envelope 写入的对象需冻结所有对象写入客户端写入、lifecycle、replication升级完全部节点后再恢复流量新加密对象写入后不支持回滚Data-movement part checksums sidecarRUSTFS_DATA_MOVEMENT_PART_CHECKSUMS_WRITEtrue且RUSTFS_DATA_MOVEMENT_PART_CHECKSUMS_FLEET_CONFIRMEDtrue只有全部节点支持该 sidecar 且以该版本作为回滚下限后才能启用启用后若已迁移过带 legacy 校验和的 multipart 对象则不支持回滚Pool metadata version 2RUSTFS_POOL_META_V2_WRITEtrue且RUSTFS_POOL_META_V2_FLEET_CONFIRMEDtrue节点一旦观察到或写入 version 2 就不再降级pool.bin旧版本无法读取Pool metadata version 3RUSTFS_POOL_META_V3_WRITEtrue且RUSTFS_POOL_META_V3_FLEET_CONFIRMEDtrue提交后 V1/V2-only 二进制无法重新加入集群前三个开关在未显式开启时均为非激活状态。在滚动升级期间保持它们非激活可以避免中途某台旧节点无法读取新节点写入的数据。滚动升级主路径一次只动一台对每台节点顺序任意按以下三步执行重启该节点如果是升级先替换二进制或容器镜像再重启。替换可执行文件并重启不会在启动时运行任何迁移步骤也不改变磁盘数据格式——除非某个显式启用的功能文档声明了版本下限。等待该节点报告 ready。ready 的节点在/health/ready上返回200JSON 响应体中包含ready: truecurl -fsS http://node:9000/health/ready确认当前节点 ready 之后再处理下一台节点。其中node替换为你要检查的节点地址。只要一台节点处于重启状态其余节点仍保持仲裁并继续处理全部流量在第一台节点 ready 之前把第二台也停掉会让部分 erasure set 失去写仲裁甚至读仲裁——这是滚动升级中要避免的状态。遇到 503 时读懂响应体和头部当集群或几台节点整体下线后逐台拉起时先起来的节点会进入降级模式进程保持存活S3 请求收到503 Service Unavailable并携带以下特征Retry-After: 5响应头x-rustfs-readiness-pending响应头响应体指明阻塞的依赖项。S3 数据面在FullReady之前统一由 readiness gate 返回503 Service Unavailable带Retry-After: 5而/health/ready等健康探针路径、admin/console、节点间 RPC 会绕过该 gate因此探针可用不代表存储已就绪。阻塞依赖含义storage_quorum正在等待足够多的节点/磁盘满足纠删读仲裁iam存储已就绪IAM 缓存仍在加载startup_finalization最后的启动步骤正在发布判断下一步主要看两处日志。IAM 恢复循环会带退避重试并记录eventiam_bootstrap_retry_failed其中带有可操作的hint字段例如 storage read quorum not met yet; waiting for enough cluster nodes/disks to come online。重试反复失败时日志级别会从 WARN 升到 ERROR但这不会终止进程。readiness 明细。在等待期间用以下命令查看各依赖的独立状态/minio/health/ready等价curl -s http://node:9000/health/ready | jq/health/ready会把storage/poolMetadata/iam/lock的 readiness 分开报告storage.ready是写仲裁加元数据写门控的汇总storage.readQuorum与storage.writeQuorum分别展示两种仲裁的观察值。注意健康的poolMetadata.ready并不隐含存储仲裁已满足。degradedReasons会列出机器可读的原因例如storage_quorum_unavailable、storage_and_lock_unavailable、pool_metadata_check_timeout。探针范围与采样限制可参考 readiness-matrix.md 的 Storage Detail Contract 一节。处理原则不要重启循环恢复是自动的文档给出的明确结论不要对处于 pending 状态的节点做重启循环。存储读仲裁一旦满足pending 节点会在下一次重试时完成 IAM bootstrap恢复是自动的重启这些节点不会加快恢复。继续把剩余的节点拉起来。节点凑齐后/health/ready在存储写仲裁、元数据写门控、IAM 和 lock readiness 都满足时返回200。启动等待完整就绪的时间由RUSTFS_STARTUP_READINESS_MAX_WAIT_SECS控制默认120秒对应常量DEFAULT_STARTUP_READINESS_MAX_WAIT_SECS定义在crates/config/src/constants/health.rs。调大会让真正缓慢的启动期间 listener 延迟暴露调小会更早进入降级模式。无论该限制是否到期后台恢复重试都会继续进行。不属于正常现象的两种情况启动期间节点进程因 IAM/lock 致命错误而退出。这条致命路径在 v1.0.0-beta.5 之后已被移除rustfs/rustfs#4304如果还看到该现象应升级二进制。整个集群都已恢复后仍有节点卡在降级状态。按文档顺序排查节点间网络可达性peer RPC 端口、各节点时钟然后检查degradedReasons和 IAM 重试日志中的hint字段。另外控制台显示节点离线且无任何日志输出的情况被单独跟踪rustfs/backlog#888。相关文档rolling-restart.md多节点滚动重启与顺序冷启动的完整操作文档readiness-matrix.md各请求面在FullReady前后的行为矩阵与探针语义compat-cleanup-register.mdsse-local-dek-json-v1等兼容性清理项pool-metadata-recovery.mdpool metadata v2/v3 的兼容矩阵与磁盘替换顺序【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考