Ray 节点级容错机制工作节点、Head 节点与 Raylet 故障的影响范围与恢复原理【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray一篇理解 Ray 集群坏节点行为的指南。Ray 集群由带 raylet 等系统进程的工作节点和承载 GCS 的 Head 节点组成本文以官方容错文档nodes.rst为主线讲清楚三类节点故障工作节点、Head 节点、单个 raylet分别会导致哪些 task、actor、object 受损Ray 会如何自动恢复以及你可以通过哪些配置让 Head 节点故障不再是全集群灾难。读完后你可以判断自己集群的容错缺口在哪、如何启用 GCS 持久化后端、并能在源码层面验证节点死亡检测与善后逻辑。Ray 集群的节点结构与角色分工按官方文档 节点容错 的定义一个 Ray 集群由一个或多个工作节点worker node组成每个工作节点内包含用户 worker 进程和系统进程如 raylet其中一个工作节点被指定为head 节点额外运行 GCSGlobal Control Service等集群级进程。这三个角色决定了故障域的基本划分工作节点跑 task / actor / object 值的地方故障影响的是该节点上的计算与数据副本Head 节点承载 GCSGCS 保存集群级元数据节点表、actor 表、placement group 表等故障默认影响整个集群raylet每个节点上的本地调度与资源管理进程一个节点一个故障等价于该节点故障。理解节点级容错本质上就是回答某个角色挂了之后哪些东西会失败、哪些数据会丢失、系统会不会自动恢复、恢复的前提条件是什么。工作节点故障任务、Actor 全部失败对象副本丢失官方文档对工作节点故障的结论很直接当一个工作节点失败时其上所有正在运行的 task 和 actor 都会失败且该节点上 worker 进程所拥有的所有 object 都会丢失。此时 task、actor、object 的容错机制会介入尝试使用其他工作节点恢复这些故障。这句话对应到仓库中的三条恢复链路下面逐一展开。1. 任务重试task 级恢复worker 进程崩溃或机器宕机导致 task 执行失败时Ray 会自动在其他节点重新执行该 task直到成功或超过最大重试次数。关键参数详见 任务容错ray.remote(max_retries...)单任务重试次数默认3次-1表示无限重试0表示禁用环境变量RAY_TASK_MAX_RETRIES覆盖所有任务的默认重试次数可通过 driver 脚本或 runtime environment 注入retry_exceptions默认False即应用层异常不重试设为True可重试任意异常也可传入可重试异常类型列表。节点故障属于系统级失败即使retry_exceptionsFalse也会触发重试——这正是机器挂了 Ray 能自愈的核心机制。2. 血缘重建object 级恢复节点故障会同时丢失 object store 中该节点上的对象副本。Ray 通过**血缘重建lineage reconstruction**恢复先在其他节点上寻找该 object 的其他副本找不到则重新执行当初创建该 object 的 task其参数再递归地按同样机制重建。前提与限制详见 对象容错object 及其全部传递依赖必须由 task 生成——ray.put创建的 object不可恢复task 默认被假定为确定性、幂等因此actor task 的结果默认不可重建需设置 actor 的max_task_retries为非零值才允许重执行受max_retries/max_task_retries上限约束object 的owner 必须仍然存活owner 是创建原始ObjectRef的 worker 进程注意它通常与产生 object 值的 worker 不是同一进程。可用环境变量调节行为RAY_max_lineage_bytes默认 1GB限制 driver 保留的血缘描述大小超出则驱逐RAY_TASK_MAX_RETRIES0彻底关闭血缘重建此时若无副本存活ray.get将抛出ObjectLostError。3. Actor 重建actor 级恢复节点上存活的 actor 会随节点一起失败。开启max_restarts的 actor 会被调度到其他存活节点重建重建后的 actor 会丢失故障前的内存状态。Actor 侧的完整机制max_restarts、max_task_retries、owner 失败等见 Actor 容错这里不展开。源码印证节点死亡如何被传播与善后从源码结构看节点死亡的信息流是raylet/GCS 检测到节点失联 → GCS 将节点状态更新为 DEAD 并广播 → 各订阅方actor 管理器、资源管理器、autoscaler 等据此清理与重调度。可对照的证据节点死亡信息用NodeDeathInfo消息承载包含死因与描述定义于 common.proto并在 GCS 服务中随节点数据下发gcs.protoGCS 的 actor 管理器在节点死亡回调中处理 actor 善后见 gcs_actor_manager.cc 的 OnNodeDead它决定哪些 actor 需要标记死亡或触发重建GCS 节点管理器 gcs_node_manager.cc 负责节点表的增删改测试中可见RemoveNode(node_id, death_info, rpc::GcsNodeInfo::DEAD, ...)的调用形态gcs_actor_scheduler_test.cc正常退场如 autoscaler 缩容同样走这套通道raylet 侧会以EXPECTED_TERMINATION原因构造NodeDeathInfo并优雅退出见 node_manager.cc。Head 节点故障默认导致全集群失败除非 GCS 容错开启官方文档对此的表述只有两句话但分量最重当 head 节点失败时整个 Ray 集群失败。要容忍 head 节点故障必须让GCS 具备容错能力这样启动新的 head 节点后仍保有全部集群级数据。原因在于 GCS 管理集群级元数据节点注册、actor 表、placement group、资源管理等默认情况下 GCS 把全部数据存在内存里进程一死数据即失。启用 GCS 容错的两种后端按 GCS 容错文档让 GCS 把状态持久化到外部存储即可在重启后重载恢复Ray 提供两种后端External RedisEmbedded RocksDBalpha额外要运维的进程需要HA Redis不需要状态存放位置外部 Redis 实例持久卷上的本地 RocksDBHead 节点/Pod 丢失后能否存活能若 Redis 存活能若持久卷存活并可重新挂到新 head平台支持全平台仅 Linux成熟度官方支持Ray Serve 场景需配合 KubeRayAlphaRedis 后端的启用方式ray start场景设置环境变量RAY_REDIS_ADDRESSredis_ip:port并给ray start传入--redis-password PASSWORD --redis-password ...例如RAY_REDIS_ADDRESSredis_ip:port ray start --head --redis-password PASSWORD --redis-username defaultray up场景修改集群配置中的head_start_ray_commands把RAY_REDIS_ADDRESS与--redis-password加进 head 的ray start命令。RocksDB 后端alpha则无需外部存储设置两个环境变量后启动 headRAY_gcs_storagerocksdb RAY_gcs_storage_path/mnt/ray-gcs ray start --head注意两点RAY_gcs_storage_path必填且必须指向可跨重启存活、可重新挂载到新 head 的持久存储如 K8sPersistentVolumeRocksDB 库内嵌于 GCS 进程且是单写者同一集群每次重启必须指向同一路径且不同集群之间不能共享路径。官方文档还给出两个进阶调优变量默认值即可满足 GCS 元数据负载RAY_gcs_rocksdb_io_pool_size默认4RocksDB I/O 卸载线程池大小WAL fsync 等高延迟 I/O 在独立线程池执行不阻塞 GCS 事件循环RAY_gcs_rocksdb_strand_buckets默认64按 key 排序的桶数单 key 操作哈希到桶内串行不同桶并发执行。GCS 恢复期间哪些功能会短暂不可用无论哪种后端恢复模型一致GCS 重启后从后端存储读回全部状态并恢复服务期间各 raylet 会尝试重连。官方文档明确列出恢复期间不可用的功能actor 的创建、删除与重建placement group 的创建、删除与重建资源管理worker 节点注册worker 进程创建。同时文档强调恢复期间正在运行的 task 和 actor 仍然存活已有 object 保持可用——也就是说 GCS 恢复是控制面短暂不可写/不可注册而非数据面中断。raylet 重连 GCS 的超时阈值由环境变量RAY_gcs_rpc_server_reconnect_timeout_s控制超过 60 秒默认仍连不上 GCSraylet 退出、对应节点判为失败。该默认值可在 ray_config_def.h 中确认RAY_CONFIG(uint32_t, gcs_rpc_server_reconnect_timeout_s, 60)。另外文档提醒若 GCS 重启后 IP 可能变化应使用域名并把域名传给所有 raylet各 raylet 自行解析连接并必须保证任一时刻只有一台 GCS 存活单写者约束与 RocksDB 后端一致。关于支持边界官方文档有两个明确的 note外部 Redis 后端仅在配合 KubeRay 做 Ray Serve 容错时属于官方支持范围其他场景需自行实现 GCS/head 故障检测与重启机制而 KubeRay 用户可直接参考其 GCS 容错文档。Raylet 故障被当作节点失败且复活后是一个新节点官方文档对 raylet 故障的定义同样简洁但包含一个容易被忽略的细节当 raylet 进程失败时对应节点会被标记为 dead并按节点故障同等处理。每个 raylet 关联一个唯一 ID因此即使 raylet 在同一台物理机上重启对 Ray 集群而言它也是一个全新的 raylet/节点。这意味着故障等价性raylet 挂掉 → 节点标记 DEAD → 该节点上的 task/actor/object 处置与工作节点宕机完全一致走前述任务重试 血缘重建 actor 重建三条恢复链路。无状态继承即使机器没换、IP 没变raylet 进程重启后拿到的是新的 raylet ID集群视其为新节点重新注册——原节点上的资源表、租约、对象位置信息都不沿用。从源码结构看节点存活的判定依赖持续的心跳机制raylet 默认每 60 秒向 GCS 发送一次自身存活检查raylet_liveness_self_check_interval_ms见 ray_config_def.hGCS 侧由健康检查管理器gcs_health_check_manager.cc负责跟踪各节点的存活状态超时未确认的节点会被判死并触发OnNodeDead善后流程。因此排查节点莫名消失时raylet 到 GCS 的网络连通性与心跳超时是首要怀疑方向而节点被判死后 raylet 的重连行为则受上一节提到的RAY_gcs_rpc_server_reconnect_timeout_s默认 60 秒约束。小结一张故障—恢复对照表故障对象默认后果自动恢复机制恢复前提 / 关键配置工作节点其上 task、actor 失败该节点 worker 拥有的 object 丢失task 重试、血缘重建、actor 重建max_retries默认 3、RAY_TASK_MAX_RETRIES、max_restartsray.put对象与 owner 死亡不可恢复Head 节点默认全集群失败新 head 启动后 GCS 从持久后端重载元数据RAY_REDIS_ADDRESS--redis-passwordRedis或RAY_gcs_storagerocksdbRAY_gcs_storage_pathRocksDBalpharaylet 重连超时RAY_gcs_rpc_server_reconnect_timeout_s默认 60sraylet 进程节点标记 DEAD按节点故障处理同工作节点故障重启后的 raylet 视为新节点存活判定基于约 60s 周期的心跳自检排查建议节点故障后先用 State API 的ray list tasks需要ray[default]安装查看各 task 尝试的NODE_ID、ERROR_TYPE如WORKER_DIED结合 GCS 中节点的NodeDeathInfo死因预期终止还是异常死亡即可快速区分节点真挂了与raylet 进程异常两类场景。【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
