高校里做科研算力管理的人多半都经历过这种场景主校区机房摆着一批GPU服务器利用率长期在40%左右徘徊而分校区实验室的同学提交训练任务要排两三天队。资源不是没有而是被校区之间的物理距离和网络边界切碎了。我参与的这个项目就是把分布在不同校区的GPU集群通过网络和调度手段连成一个整体让用户看到的是一套统一的算力资源提交作业时不关心GPU物理在哪里底层按数据位置、网络延迟、负载情况自动分配节点。这篇内容会完整拆解整个方案的实施逻辑包括网络组网、调度策略、数据同步设计以及运维期间踩过的各种坑适合高校和科研院所的算力管理员、HPC集群运维人员以及正在做多节点算力整合的技术负责人参考。1. 项目背景与整体设计思路1.1 场景还原三个校区四套割裂的算力先说说项目起点。某高校有三个校区主校区和两个分校区每个校区都独立采购了GPU服务器分别搭建了小集群。主校区规模最大有32张加速卡两个分校区分别是16张和8张。三个集群各自使用独立的调度系统账号体系也不互通用户在主校区提交的作业不能到分校区运行反过来也一样。实际运行一段时间后问题就暴露出来了。主校区的GPU利用率常年偏低很多卡在晚上和假期完全空闲但分校区因为课题组多、任务密集排队时间越来越长。更麻烦的是数据管理每个校区都有自己的存储阵列训练数据集散落在不同地方想跨校区跑任务基本靠人工拷贝要么用移动硬盘要么通过文件传输工具慢慢传效率很低。管理部门想统计全校总算力使用情况发现三套系统统计口径都不一样算出来的数字各说各话。这个案例说明了一个普遍现象算力采购是分散进行的但科研任务的需求是整体性的。每个校区都在为各自的峰值需求采购硬件结果就是整体资源利用率不高单个校区又觉得资源不够。要解决这个问题不能靠增加采购而是要把现有资源盘活。1.2 为什么不做物理搬迁而是逻辑整合有人可能第一反应是既然三套集群割裂那把分校区的小集群搬到主校区机房统一管理不就行了这个方案在理论上成立实际操作中却会碰到几个硬约束。第一是数据搬迁成本。很多科研团队的数据集有几十TB甚至上百TB而且数据是持续增长的物理搬迁只能解决一次性问题后续新产生的数据还是要跨校区传输。第二是机房条件限制。分校区机房虽然规模小但供电、制冷、机柜空间都是现成的GPU服务器搬到主校区后这些资源就闲置了主校区机房反而要扩容。第三是使用惯性。分校区的研究生和导师习惯就近使用算力如果所有作业都要提交到主校区出了问题很难现场排查。所以方案从一开始就定了调子做逻辑整合不做物理搬迁。每台GPU服务器留在原校区通过网络把三个集群连接起来在调度层面统一管理。用户感知到的是一个算力池后端跑在哪个校区不重要只要速度够快、数据一致就行。1.3 整体架构的选型逻辑整个系统按照三层来设计每一层解决一类问题。最上层是调度与接入层负责统一接收作业请求决定作业调度到哪台机器。这一层最关键的是要能识别每个GPU节点的校区归属、硬件规格、当前负载和数据位置。第二层是网络传输层负责打通三个校区之间的数据通道让调度指令和训练数据都能顺畅流动。第三层是存储与数据层负责解决数据集和训练结果的跨校区一致性。选型时有一个核心原则尽量沿用现有系统不做过度重构。三个校区原本就在用同一套开源调度器虽然各自独立但版本和配置差异不大这为统一纳管省了不少事。如果把调度器换成商业软件不但采购成本高三个校区所有用户都要重新学习操作方式迁移成本太大。最终方案是在保留原有软件体系的基础上增加一层统一调度视图再通过网络优化和存储同步补齐短板。2. 跨校区网络通路的实现与参数评估2.1 网络拓扑与专线选型网络是整个方案的地基。GPU训练任务对网络的要求很明确带宽要够大延迟要低丢包要少。三个校区之间的链路是租用的专线主校区到A分校区是20Gbps主校区到B分校区是10Gbps两个分校区之间没有直连线路需要经过主校区中转。先做延迟测试。使用ping工具测出的RTT在2到5毫秒之间这个延迟对普通文件传输和分布式训练来说是完全可以接受的。以常用的分布式训练框架为例如果模型同步采用梯度全规约模式每次迭代都需要跨节点通信2到5毫秒的延迟会让通信等待时间稍微变长但比起本地磁盘读取时间还是要快不少。实测下来跨校区跑分布式训练的速度大约是本校区集群的80%到90%如果训练脚本里做好梯度压缩和数据预取优化差距可以进一步缩小。带宽方面有一个简单估算公式可以参考。传输100GB数据的理论最短时间等于数据量乘以8再除以带宽100GB乘以8是800Gbit除以20Gbps带宽等于40秒。但实际传输不可能达到这个速度磁盘读写速度、TCP窗口大小、文件数量都会拖慢进程。实测用20Gbps专线传100GB文件耗时在3到5分钟这个速度对科研场景来说已经够用。2.2 组网方式用大二层隧道打通三个机房组网方式经过了好几轮讨论。最开始考虑过在每个校区路由器上配置静态路由三层互通。这个方案最简单但问题在于三个校区的GPU节点IP地址段规划得不一致有些是10.x网段有些是172.16网段跨段访问要写大量NAT规则后续扩展和维护都很麻烦。最终采用的是在三个校区的核心交换机上各部署一台高性能转发节点用覆盖网络技术把三个机房连成一个逻辑上的大二层网络。具体原理可以这样理解虽然三个校区物理上隔着专线但通过封包和解包机制让每个GPU节点都觉得其他校区的机器和自己在一个局域网里IP地址可以直接互通不需要关心底层跨了多少跳路由。这个方案有三个明显好处。第一调度器访问所有节点时不需要区分网段可以直接用统一规划的私网地址连接。第二新增GPU服务器时只要接入本校区交换机并配置好IP就能自动出现在整体网络中不需要改动路由策略。第三跨校区传输加密可以在封包层统一处理比每个业务都自己做加密要省事。实际操作中有一个MTU问题需要注意。专线链路支持的最大传输单元是9000字节但覆盖网络叠加封装头之后实际可用载荷变小了。如果节点网卡仍按9000字节发送数据包超过路径最大传输限制就会触发分片导致性能严重下降。我们把所有GPU节点的MTU统一调整为1500字节与覆盖网络的标准保持一致实测传输性能稳定。2.3 防火墙与安全策略的放行清单网络打通后紧接着就是安全策略。三个校区都有硬件防火墙默认策略是拒绝跨校区访问只允许本校区的内部流量。我们要做的不是把防火墙关掉而是在防火墙上精确放行必要端口。实际放行的端口清单包括SSH远程管理端口、调度器通信端口、数据传输端口、健康检查探针端口。每个端口都对应明确用途配置规则时逐条写明源地址段和目的地址段。比如调度器通信端口只需要主校区调度节点到各校区计算节点的访问方向不需要开放反向访问。如果所有端口都放行安全审计时解释不清楚流量去向这是运维的大忌。还要注意一点防火墙策略调整后要立即验证不能改完就放着。我们遇到过修改策略后忘了重载导致跨校区调度任务全部失败的情况。排查了半天最后发现是新增的放行规则没有生效重载一次就恢复了正常。这个坑在后面的问题排查章节会详细展开。3. 统一调度与作业路由设计3.1 调度器选型单实例纳管所有节点调度层面我们继续沿用学校原本在用的开源集群调度器但没有按常规方式部署成三个独立实例。方案是在主校区部署一个统一调度节点把三个校区的所有GPU节点都注册到这一个调度实例下面。A分校和B分校的小集群调度器停用本地用户统一通过新调度器提交任务。这样做的好处很明显用户不再需要记住不同校区的登录地址只需提交到一个统一入口账号体系也只需要维护一套。调度器知道每个节点在哪栋楼、属于哪个校区就能在分配任务时考虑网络因素。管理工作量也下降了原来要维护三套调度配置现在只要维护一套。代价是这个统一调度节点变成单点。为了降低风险我们做了主备双机配置备用节点实时同步主节点的任务状态一旦主节点故障备用节点可以切换接管。实际运行中故障很少发生但双机配置让团队睡得安稳些。3.2 关键调度策略本地优先、数据亲和、跨区溢出调度策略是用户最能感知的部分。在具体实现上我们在调度器的节点配置里为每台GPU服务器打了校区标签再通过分区配置划分作业的执行范围。默认情况下新提交的作业先看本校区是否有可用节点如果本校区排队满再判断能否调度到其他校区。优先级顺序设置得很细致。第一步优先调度到提交用户所在校区的空闲节点。第二步如果本校区繁忙调度器检查当前待处理数据放在哪个校区的存储上优先选择数据所在校区的节点这样数据预加载速度最快。第三步数据所在校区也繁忙时把作业调度到其他校区节点同时触发数据同步任务把所需数据复制过去。这套策略看起来不复杂但非常有效因为大部分科研作业的数据集是固定的数据亲和调度能减少大量无谓的网络传输。还有一个细节是混部策略。如果主校区节点很多可以接受分校区作业溢入但不允许主校区低优先级作业挤占分校区高优先级作业的节点。操作上就是给每个节点设置不同的最大作业数和优先级权重超过阈值后调度器自动排队。配置示例大致如下# 节点分区与标签配置示例 NodeNamegpu-a01 CPUs64 FeatureGPU_32G,data-main NodeNamegpu-b01 CPUs64 FeatureGPU_24G,data-lab-a PartitionNamemain Nodesgpu-a[01-08] DefaultYES PartitionNameoverflow Nodesgpu-a[01-08],gpu-b[01-04] DefaultNO分区main是默认分区只包含主校区的8台节点用户在提交作业时如果不指定分区就进入main。如果管理员希望某些用户可以跨校区溢入就把用户加入overflow分区的访问列表这样就能在main队列满时自动调度到分校区节点。3.3 数据感知调度与作业回传机制调度器根据数据位置分配节点这个听上去很合理实现时却有不少细节。我们采用的做法是维护一个数据位置表记录每个数据集和checkpoint文件存放在哪个校区的存储路径上。用户在提交作业时可以通过作业参数声明所需数据路径调度器解析这些路径在节点分配时匹配对应校区的节点。如果匹配不到本校区节点调度器不会拒绝任务而是把作业标记为需要远程数据拉取转交给数据传输组件处理。数据传输组件会在目标节点平台上挂载远端存储或者先把数据同步到目标校区的缓存目录再启动训练作业。训练结束后还有一个回传问题。作业输出结果如果生成在分校区节点上用户可能期望在主校区看到这些文件或者从登录节点直接下载。我们在作业提交脚本里嵌入了结果回传命令作业退出前自动把输出文件传回提交校区的工作目录。回传过程是异步的不会阻塞训练进程。如果结果文件特别大比如超过50GB会先做压缩再传输节省带宽。4. 存储与数据同步的关键实现4.1 全局命名空间的三种路径对比数据是跨校区共享算力最容易翻车的环节。如果用户在主校区提交作业但训练数据在分校区调度到分校区节点后却看不到数据那再怎么优化调度都没有意义。存储方案主要有三种常见路径我们逐一做了评估。第一种是部署一套分布式并行文件系统三个校区都挂载同一个文件系统命名空间所有数据一个副本视角。这个方案一致性最好但需要采购商业授权或自建开源集群还要配置专门的元数据服务硬件投入和维护成本都不低。第二种是用对象存储做统一存储层各个校区的计算节点通过访问协议读写对象。这个方案适合海量小文件场景但深度学习的框架对POSIX接口依赖较高很多训练脚本直接操作本地路径迁移对象存储后兼容性要花很多精力调整。第三种是保留各校区本地文件系统在本地文件系统之间做异步数据同步。考虑到项目预算和维护团队规模我们最终选择了第三种方案。每个校区的存储仍然是本地的但在存储系统前面加了一层全局命名映射服务用户看到的路径是统一的实际数据可能分散在各校区存储里。访问本地数据时走本地文件系统访问远端数据时通过同步机制预先拉取到本地。4.2 数据同步方案双写加异步复制数据同步采用的是双写加异步复制策略。训练作业运行时输入数据如果已经在本校区直接读取如果不在先由同步组件从其他校区复制过来。输出结果和checkpoint文件先写到本校区存储同时后台同步进程把新增文件复制到主校区的统一归档目录保证主校区的管理节点始终能看到各校区最新数据。同步工具选择了rsync加文件系统事件监控组合。文件系统事件监控负责捕获新增和修改事件触发增量同步任务。rsync负责真正传输使用增量算法只传新增或修改过的文件块不会重复传输整个文件。同步任务在配置文件里设定了带宽上限避免数据同步占用太多专线带宽影响在线训练。一个实际配置例子是这样的rsync -avz --bwlimit204800 --timeout3600 \ /data/checkpoints/userA/ job-syncsync-host:/archive/checkpoints/userA/带宽限制设置为每秒200MB折合1.6Gbps相比20Gbps专线只占8%训练数据回传和同步复制同时进行时网络也不会打满。同步任务每天凌晨自动执行一次全量校验用checksum比对文件是否完整如果发现不一致会重新同步。这样做既能保证实时性又把网络压力控制在安全范围内。4.3 暂存盘与数据预取设计跨校区训练最大的瓶颈不是带宽而是训练迭代过程中反复读取远端文件造成的延迟。如果每次迭代都要访问其他校区的存储网络往返时间会拖慢整个训练流程。为了规避这个问题每个校区节点都配置了一块独立的NVMe高速暂存盘专门用于存放从远端拉取的数据。训练作业启动前调度器会检查所需的输入数据是否已在本校区的暂存盘上。如果已存在且校验值一致直接使用如果不存在先从远端存储复制到本地暂存盘再启动训练进程。这个复制过程是一次性的训练过程中所有数据读取都走本地NVMe速度能达到每秒6GB以上和本地数据中心没有任何区别。暂存盘的容量规划需要结合数据集大小做估算。我们的数据集平均大小在20GB左右最大的一组训练数据接近80GB所以每台节点配备了2TB NVMe盘粗算下来可以同时缓存20多个数据集。如果暂存盘满了数据同步组件会按最近最少使用策略清理不常用的数据把空间留给新任务。数据预取和清理都是后台自动完成的用户无感知但运维监控面板上能清楚看到每台节点的缓存命中率。5. 常见问题与排查技巧实录5.1 跨校区调度失败的经典场景对照表整个系统上线后我们遇到过不少奇奇怪怪的问题。这里整理一张高频问题对照表把现象、原因和解决办法都列出来遇到类似情况可以直接对照排查。问题现象可能原因排查思路与解决办法作业提交后长时间Pending不运行分区配置未更新或节点健康检查失败查看调度器日志确认节点状态运行节点健康检测脚本手动触发一次确认节点心跳正常跨校区作业启动报Cannot open file数据同步还没完成作业进程先启动了在作业脚本里增加文件存在性等待循环确认同步任务结束后再启动训练训练速度只有本地的一半数据没有走暂存盘进程直连远端存储检查作业脚本是否引用了本地缓存路径调整数据挂载顺序同步完成后另一校区看不到文件同步任务失败或校验失败检查同步任务日志确认进程没有被kill重新执行校验比对节点状态显示down但机器健康调度器健康检查端口被防火墙拦截查看节点日志确认健康检查端口放行重载防火墙策略5.2 监控与巡检注意事项统一管理三个校区的资源不能依赖人工巡检必须有自动化监控体系。我们做了三件关键事情监控面板上把所有校区的节点放在同一个视图里用不同颜色标识本校区和远端节点一眼就能看出哪个校区的资源比较空闲每个校区的存储同步队列长度单独做成指标一旦队列积压就告警因为这说明网络带宽或同步进程出了问题每周定时跑一次模拟作业测试跨校区调度链路是否正常包括数据同步、作业启动、结果回传整个完整流程。硬件层面主要盯四个指标GPU利用率和显存占用看算力是否真正被用上节点温度和环境湿度看机房空调是否正常工作GPU设备很敏感温度一高频率就会自动下调专线流量利用率看带宽是否打满如果持续超过70%就要考虑优化数据同步策略跨校区网络延迟和丢包率看链路质量延迟超过10毫秒或者丢包超过1%就要报修。5.3 实战中踩过的三个特殊坑有一些问题不常见但一旦碰到非常折腾人这里单独拎出来说。第一个是时钟同步问题。跨校区节点的时间如果不一致调度器记录的作业起止时间会混乱同步组件的文件时间戳也会对不上导致增量同步判断错误总是重复传送文件。最开始我们没注意分校区节点的NTP配置后来发现A校区节点时间比主校区慢了约两分钟数据同步效率一度很低。解决方法是统一三校区的NTP服务器配置把主校区的时间服务器作为标准源其他校区的节点全部指向它。第二个是GPU驱动版本不一致。三个校区的GPU型号不完全相同驱动版本也不同有些节点支持的特性在其他节点上不兼容作业调度到不匹配的节点后直接启动失败。后来我们在调度器配置里为每台节点标记了支持的驱动和计算框架版本调度作业时做兼容性过滤不让不兼容的作业跑到对应节点上。第三个是DNS解析顺序问题。分校区节点尝试访问主校区存储时有时候走的是存储服务的备用域名解析出来的IP不对导致连接超时。排查后修改了分校区节点的DNS搜索顺序把内网域名解析放在最前面并在主校区存储服务上配置了多个访问域名冗余。解决之后跨校区访问再也没有出现过解析超时。6. 个人实操体会与后续扩展方向6.1 再谈两句关于网络和存储的取舍这个项目做完下来我最大的体会是跨校区算力平台的核心并不是算力本身而是网络和存储的配套是否跟得上。调度器把所有节点统管起来只是第一步真正决定用户体验的是数据能不能快速到达计算位置结果能不能及时回到提交位置。有些方案把网络和存储搞得很复杂最终效果反而不如层次清晰、适度冗余的设计。我的建议是不要一开始就追求所有数据全局实时可见先做到作业能跨区跑起来再逐步优化数据同步的时效性。我们后续还在考虑引入云厂商的公有GPU资源作为弹性溢出池。平时任务量低本地校区算力足够高峰期可以临时把作业溢出到云端节点按需付费。这样既能减轻排队问题又不用盲目增加硬件采购。6.2 给后来者的几项实用建议如果你们也在做类似的事情有几条建议可以提前考虑。第一先选一个校区做小范围试点把调度、同步、回传的完整链路跑通跑稳再推广到其他校区。不要一上来就三个校区全面铺开出了问题排查范围太大。第二跨校区资源共享一定会有资源归属和计费的问题建议提前设计好计量维度比如按GPU卡时数统计每个课题组的用量便于后续做成本核算。第三权限治理要跟上跨校区调度不等于跨账号访问数据用户能使用其他校区的算力但不能直接读取其他课题组的数据目录这个边界一定要清晰。我在实际运维中体会最深的一点是跨校区算力平台是典型的边用边完善的系统。上线第一个月总会冒出各种预期之外的问题但只要监控体系到位、排查流程清晰稳定运行一两周后整体状态就会慢慢走向正轨。训练任务能从排队几天变成几分钟内分配完成用户满意的反馈就是最好的回报。 
长河君 · 2026/10/20 6:07:26 · 阅读 1.2k 跨校区GPU算力池化：统一调度与数据同步实践
高校里做科研算力管理的人多半都经历过这种场景主校区机房摆着一批GPU服务器利用率长期在40%左右徘徊而分校区实验室的同学提交训练任务要排两三天队。资源不是没有而是被校区之间的物理距离和网络边界切碎了。我参与的这个项目就是把分布在不同校区的GPU集群通过网络和调度手段连成一个整体让用户看到的是一套统一的算力资源提交作业时不关心GPU物理在哪里底层按数据位置、网络延迟、负载情况自动分配节点。这篇内容会完整拆解整个方案的实施逻辑包括网络组网、调度策略、数据同步设计以及运维期间踩过的各种坑适合高校和科研院所的算力管理员、HPC集群运维人员以及正在做多节点算力整合的技术负责人参考。1. 项目背景与整体设计思路1.1 场景还原三个校区四套割裂的算力先说说项目起点。某高校有三个校区主校区和两个分校区每个校区都独立采购了GPU服务器分别搭建了小集群。主校区规模最大有32张加速卡两个分校区分别是16张和8张。三个集群各自使用独立的调度系统账号体系也不互通用户在主校区提交的作业不能到分校区运行反过来也一样。实际运行一段时间后问题就暴露出来了。主校区的GPU利用率常年偏低很多卡在晚上和假期完全空闲但分校区因为课题组多、任务密集排队时间越来越长。更麻烦的是数据管理每个校区都有自己的存储阵列训练数据集散落在不同地方想跨校区跑任务基本靠人工拷贝要么用移动硬盘要么通过文件传输工具慢慢传效率很低。管理部门想统计全校总算力使用情况发现三套系统统计口径都不一样算出来的数字各说各话。这个案例说明了一个普遍现象算力采购是分散进行的但科研任务的需求是整体性的。每个校区都在为各自的峰值需求采购硬件结果就是整体资源利用率不高单个校区又觉得资源不够。要解决这个问题不能靠增加采购而是要把现有资源盘活。1.2 为什么不做物理搬迁而是逻辑整合有人可能第一反应是既然三套集群割裂那把分校区的小集群搬到主校区机房统一管理不就行了这个方案在理论上成立实际操作中却会碰到几个硬约束。第一是数据搬迁成本。很多科研团队的数据集有几十TB甚至上百TB而且数据是持续增长的物理搬迁只能解决一次性问题后续新产生的数据还是要跨校区传输。第二是机房条件限制。分校区机房虽然规模小但供电、制冷、机柜空间都是现成的GPU服务器搬到主校区后这些资源就闲置了主校区机房反而要扩容。第三是使用惯性。分校区的研究生和导师习惯就近使用算力如果所有作业都要提交到主校区出了问题很难现场排查。所以方案从一开始就定了调子做逻辑整合不做物理搬迁。每台GPU服务器留在原校区通过网络把三个集群连接起来在调度层面统一管理。用户感知到的是一个算力池后端跑在哪个校区不重要只要速度够快、数据一致就行。1.3 整体架构的选型逻辑整个系统按照三层来设计每一层解决一类问题。最上层是调度与接入层负责统一接收作业请求决定作业调度到哪台机器。这一层最关键的是要能识别每个GPU节点的校区归属、硬件规格、当前负载和数据位置。第二层是网络传输层负责打通三个校区之间的数据通道让调度指令和训练数据都能顺畅流动。第三层是存储与数据层负责解决数据集和训练结果的跨校区一致性。选型时有一个核心原则尽量沿用现有系统不做过度重构。三个校区原本就在用同一套开源调度器虽然各自独立但版本和配置差异不大这为统一纳管省了不少事。如果把调度器换成商业软件不但采购成本高三个校区所有用户都要重新学习操作方式迁移成本太大。最终方案是在保留原有软件体系的基础上增加一层统一调度视图再通过网络优化和存储同步补齐短板。2. 跨校区网络通路的实现与参数评估2.1 网络拓扑与专线选型网络是整个方案的地基。GPU训练任务对网络的要求很明确带宽要够大延迟要低丢包要少。三个校区之间的链路是租用的专线主校区到A分校区是20Gbps主校区到B分校区是10Gbps两个分校区之间没有直连线路需要经过主校区中转。先做延迟测试。使用ping工具测出的RTT在2到5毫秒之间这个延迟对普通文件传输和分布式训练来说是完全可以接受的。以常用的分布式训练框架为例如果模型同步采用梯度全规约模式每次迭代都需要跨节点通信2到5毫秒的延迟会让通信等待时间稍微变长但比起本地磁盘读取时间还是要快不少。实测下来跨校区跑分布式训练的速度大约是本校区集群的80%到90%如果训练脚本里做好梯度压缩和数据预取优化差距可以进一步缩小。带宽方面有一个简单估算公式可以参考。传输100GB数据的理论最短时间等于数据量乘以8再除以带宽100GB乘以8是800Gbit除以20Gbps带宽等于40秒。但实际传输不可能达到这个速度磁盘读写速度、TCP窗口大小、文件数量都会拖慢进程。实测用20Gbps专线传100GB文件耗时在3到5分钟这个速度对科研场景来说已经够用。2.2 组网方式用大二层隧道打通三个机房组网方式经过了好几轮讨论。最开始考虑过在每个校区路由器上配置静态路由三层互通。这个方案最简单但问题在于三个校区的GPU节点IP地址段规划得不一致有些是10.x网段有些是172.16网段跨段访问要写大量NAT规则后续扩展和维护都很麻烦。最终采用的是在三个校区的核心交换机上各部署一台高性能转发节点用覆盖网络技术把三个机房连成一个逻辑上的大二层网络。具体原理可以这样理解虽然三个校区物理上隔着专线但通过封包和解包机制让每个GPU节点都觉得其他校区的机器和自己在一个局域网里IP地址可以直接互通不需要关心底层跨了多少跳路由。这个方案有三个明显好处。第一调度器访问所有节点时不需要区分网段可以直接用统一规划的私网地址连接。第二新增GPU服务器时只要接入本校区交换机并配置好IP就能自动出现在整体网络中不需要改动路由策略。第三跨校区传输加密可以在封包层统一处理比每个业务都自己做加密要省事。实际操作中有一个MTU问题需要注意。专线链路支持的最大传输单元是9000字节但覆盖网络叠加封装头之后实际可用载荷变小了。如果节点网卡仍按9000字节发送数据包超过路径最大传输限制就会触发分片导致性能严重下降。我们把所有GPU节点的MTU统一调整为1500字节与覆盖网络的标准保持一致实测传输性能稳定。2.3 防火墙与安全策略的放行清单网络打通后紧接着就是安全策略。三个校区都有硬件防火墙默认策略是拒绝跨校区访问只允许本校区的内部流量。我们要做的不是把防火墙关掉而是在防火墙上精确放行必要端口。实际放行的端口清单包括SSH远程管理端口、调度器通信端口、数据传输端口、健康检查探针端口。每个端口都对应明确用途配置规则时逐条写明源地址段和目的地址段。比如调度器通信端口只需要主校区调度节点到各校区计算节点的访问方向不需要开放反向访问。如果所有端口都放行安全审计时解释不清楚流量去向这是运维的大忌。还要注意一点防火墙策略调整后要立即验证不能改完就放着。我们遇到过修改策略后忘了重载导致跨校区调度任务全部失败的情况。排查了半天最后发现是新增的放行规则没有生效重载一次就恢复了正常。这个坑在后面的问题排查章节会详细展开。3. 统一调度与作业路由设计3.1 调度器选型单实例纳管所有节点调度层面我们继续沿用学校原本在用的开源集群调度器但没有按常规方式部署成三个独立实例。方案是在主校区部署一个统一调度节点把三个校区的所有GPU节点都注册到这一个调度实例下面。A分校和B分校的小集群调度器停用本地用户统一通过新调度器提交任务。这样做的好处很明显用户不再需要记住不同校区的登录地址只需提交到一个统一入口账号体系也只需要维护一套。调度器知道每个节点在哪栋楼、属于哪个校区就能在分配任务时考虑网络因素。管理工作量也下降了原来要维护三套调度配置现在只要维护一套。代价是这个统一调度节点变成单点。为了降低风险我们做了主备双机配置备用节点实时同步主节点的任务状态一旦主节点故障备用节点可以切换接管。实际运行中故障很少发生但双机配置让团队睡得安稳些。3.2 关键调度策略本地优先、数据亲和、跨区溢出调度策略是用户最能感知的部分。在具体实现上我们在调度器的节点配置里为每台GPU服务器打了校区标签再通过分区配置划分作业的执行范围。默认情况下新提交的作业先看本校区是否有可用节点如果本校区排队满再判断能否调度到其他校区。优先级顺序设置得很细致。第一步优先调度到提交用户所在校区的空闲节点。第二步如果本校区繁忙调度器检查当前待处理数据放在哪个校区的存储上优先选择数据所在校区的节点这样数据预加载速度最快。第三步数据所在校区也繁忙时把作业调度到其他校区节点同时触发数据同步任务把所需数据复制过去。这套策略看起来不复杂但非常有效因为大部分科研作业的数据集是固定的数据亲和调度能减少大量无谓的网络传输。还有一个细节是混部策略。如果主校区节点很多可以接受分校区作业溢入但不允许主校区低优先级作业挤占分校区高优先级作业的节点。操作上就是给每个节点设置不同的最大作业数和优先级权重超过阈值后调度器自动排队。配置示例大致如下# 节点分区与标签配置示例 NodeNamegpu-a01 CPUs64 FeatureGPU_32G,data-main NodeNamegpu-b01 CPUs64 FeatureGPU_24G,data-lab-a PartitionNamemain Nodesgpu-a[01-08] DefaultYES PartitionNameoverflow Nodesgpu-a[01-08],gpu-b[01-04] DefaultNO分区main是默认分区只包含主校区的8台节点用户在提交作业时如果不指定分区就进入main。如果管理员希望某些用户可以跨校区溢入就把用户加入overflow分区的访问列表这样就能在main队列满时自动调度到分校区节点。3.3 数据感知调度与作业回传机制调度器根据数据位置分配节点这个听上去很合理实现时却有不少细节。我们采用的做法是维护一个数据位置表记录每个数据集和checkpoint文件存放在哪个校区的存储路径上。用户在提交作业时可以通过作业参数声明所需数据路径调度器解析这些路径在节点分配时匹配对应校区的节点。如果匹配不到本校区节点调度器不会拒绝任务而是把作业标记为需要远程数据拉取转交给数据传输组件处理。数据传输组件会在目标节点平台上挂载远端存储或者先把数据同步到目标校区的缓存目录再启动训练作业。训练结束后还有一个回传问题。作业输出结果如果生成在分校区节点上用户可能期望在主校区看到这些文件或者从登录节点直接下载。我们在作业提交脚本里嵌入了结果回传命令作业退出前自动把输出文件传回提交校区的工作目录。回传过程是异步的不会阻塞训练进程。如果结果文件特别大比如超过50GB会先做压缩再传输节省带宽。4. 存储与数据同步的关键实现4.1 全局命名空间的三种路径对比数据是跨校区共享算力最容易翻车的环节。如果用户在主校区提交作业但训练数据在分校区调度到分校区节点后却看不到数据那再怎么优化调度都没有意义。存储方案主要有三种常见路径我们逐一做了评估。第一种是部署一套分布式并行文件系统三个校区都挂载同一个文件系统命名空间所有数据一个副本视角。这个方案一致性最好但需要采购商业授权或自建开源集群还要配置专门的元数据服务硬件投入和维护成本都不低。第二种是用对象存储做统一存储层各个校区的计算节点通过访问协议读写对象。这个方案适合海量小文件场景但深度学习的框架对POSIX接口依赖较高很多训练脚本直接操作本地路径迁移对象存储后兼容性要花很多精力调整。第三种是保留各校区本地文件系统在本地文件系统之间做异步数据同步。考虑到项目预算和维护团队规模我们最终选择了第三种方案。每个校区的存储仍然是本地的但在存储系统前面加了一层全局命名映射服务用户看到的路径是统一的实际数据可能分散在各校区存储里。访问本地数据时走本地文件系统访问远端数据时通过同步机制预先拉取到本地。4.2 数据同步方案双写加异步复制数据同步采用的是双写加异步复制策略。训练作业运行时输入数据如果已经在本校区直接读取如果不在先由同步组件从其他校区复制过来。输出结果和checkpoint文件先写到本校区存储同时后台同步进程把新增文件复制到主校区的统一归档目录保证主校区的管理节点始终能看到各校区最新数据。同步工具选择了rsync加文件系统事件监控组合。文件系统事件监控负责捕获新增和修改事件触发增量同步任务。rsync负责真正传输使用增量算法只传新增或修改过的文件块不会重复传输整个文件。同步任务在配置文件里设定了带宽上限避免数据同步占用太多专线带宽影响在线训练。一个实际配置例子是这样的rsync -avz --bwlimit204800 --timeout3600 \ /data/checkpoints/userA/ job-syncsync-host:/archive/checkpoints/userA/带宽限制设置为每秒200MB折合1.6Gbps相比20Gbps专线只占8%训练数据回传和同步复制同时进行时网络也不会打满。同步任务每天凌晨自动执行一次全量校验用checksum比对文件是否完整如果发现不一致会重新同步。这样做既能保证实时性又把网络压力控制在安全范围内。4.3 暂存盘与数据预取设计跨校区训练最大的瓶颈不是带宽而是训练迭代过程中反复读取远端文件造成的延迟。如果每次迭代都要访问其他校区的存储网络往返时间会拖慢整个训练流程。为了规避这个问题每个校区节点都配置了一块独立的NVMe高速暂存盘专门用于存放从远端拉取的数据。训练作业启动前调度器会检查所需的输入数据是否已在本校区的暂存盘上。如果已存在且校验值一致直接使用如果不存在先从远端存储复制到本地暂存盘再启动训练进程。这个复制过程是一次性的训练过程中所有数据读取都走本地NVMe速度能达到每秒6GB以上和本地数据中心没有任何区别。暂存盘的容量规划需要结合数据集大小做估算。我们的数据集平均大小在20GB左右最大的一组训练数据接近80GB所以每台节点配备了2TB NVMe盘粗算下来可以同时缓存20多个数据集。如果暂存盘满了数据同步组件会按最近最少使用策略清理不常用的数据把空间留给新任务。数据预取和清理都是后台自动完成的用户无感知但运维监控面板上能清楚看到每台节点的缓存命中率。5. 常见问题与排查技巧实录5.1 跨校区调度失败的经典场景对照表整个系统上线后我们遇到过不少奇奇怪怪的问题。这里整理一张高频问题对照表把现象、原因和解决办法都列出来遇到类似情况可以直接对照排查。问题现象可能原因排查思路与解决办法作业提交后长时间Pending不运行分区配置未更新或节点健康检查失败查看调度器日志确认节点状态运行节点健康检测脚本手动触发一次确认节点心跳正常跨校区作业启动报Cannot open file数据同步还没完成作业进程先启动了在作业脚本里增加文件存在性等待循环确认同步任务结束后再启动训练训练速度只有本地的一半数据没有走暂存盘进程直连远端存储检查作业脚本是否引用了本地缓存路径调整数据挂载顺序同步完成后另一校区看不到文件同步任务失败或校验失败检查同步任务日志确认进程没有被kill重新执行校验比对节点状态显示down但机器健康调度器健康检查端口被防火墙拦截查看节点日志确认健康检查端口放行重载防火墙策略5.2 监控与巡检注意事项统一管理三个校区的资源不能依赖人工巡检必须有自动化监控体系。我们做了三件关键事情监控面板上把所有校区的节点放在同一个视图里用不同颜色标识本校区和远端节点一眼就能看出哪个校区的资源比较空闲每个校区的存储同步队列长度单独做成指标一旦队列积压就告警因为这说明网络带宽或同步进程出了问题每周定时跑一次模拟作业测试跨校区调度链路是否正常包括数据同步、作业启动、结果回传整个完整流程。硬件层面主要盯四个指标GPU利用率和显存占用看算力是否真正被用上节点温度和环境湿度看机房空调是否正常工作GPU设备很敏感温度一高频率就会自动下调专线流量利用率看带宽是否打满如果持续超过70%就要考虑优化数据同步策略跨校区网络延迟和丢包率看链路质量延迟超过10毫秒或者丢包超过1%就要报修。5.3 实战中踩过的三个特殊坑有一些问题不常见但一旦碰到非常折腾人这里单独拎出来说。第一个是时钟同步问题。跨校区节点的时间如果不一致调度器记录的作业起止时间会混乱同步组件的文件时间戳也会对不上导致增量同步判断错误总是重复传送文件。最开始我们没注意分校区节点的NTP配置后来发现A校区节点时间比主校区慢了约两分钟数据同步效率一度很低。解决方法是统一三校区的NTP服务器配置把主校区的时间服务器作为标准源其他校区的节点全部指向它。第二个是GPU驱动版本不一致。三个校区的GPU型号不完全相同驱动版本也不同有些节点支持的特性在其他节点上不兼容作业调度到不匹配的节点后直接启动失败。后来我们在调度器配置里为每台节点标记了支持的驱动和计算框架版本调度作业时做兼容性过滤不让不兼容的作业跑到对应节点上。第三个是DNS解析顺序问题。分校区节点尝试访问主校区存储时有时候走的是存储服务的备用域名解析出来的IP不对导致连接超时。排查后修改了分校区节点的DNS搜索顺序把内网域名解析放在最前面并在主校区存储服务上配置了多个访问域名冗余。解决之后跨校区访问再也没有出现过解析超时。6. 个人实操体会与后续扩展方向6.1 再谈两句关于网络和存储的取舍这个项目做完下来我最大的体会是跨校区算力平台的核心并不是算力本身而是网络和存储的配套是否跟得上。调度器把所有节点统管起来只是第一步真正决定用户体验的是数据能不能快速到达计算位置结果能不能及时回到提交位置。有些方案把网络和存储搞得很复杂最终效果反而不如层次清晰、适度冗余的设计。我的建议是不要一开始就追求所有数据全局实时可见先做到作业能跨区跑起来再逐步优化数据同步的时效性。我们后续还在考虑引入云厂商的公有GPU资源作为弹性溢出池。平时任务量低本地校区算力足够高峰期可以临时把作业溢出到云端节点按需付费。这样既能减轻排队问题又不用盲目增加硬件采购。6.2 给后来者的几项实用建议如果你们也在做类似的事情有几条建议可以提前考虑。第一先选一个校区做小范围试点把调度、同步、回传的完整链路跑通跑稳再推广到其他校区。不要一上来就三个校区全面铺开出了问题排查范围太大。第二跨校区资源共享一定会有资源归属和计费的问题建议提前设计好计量维度比如按GPU卡时数统计每个课题组的用量便于后续做成本核算。第三权限治理要跟上跨校区调度不等于跨账号访问数据用户能使用其他校区的算力但不能直接读取其他课题组的数据目录这个边界一定要清晰。我在实际运维中体会最深的一点是跨校区算力平台是典型的边用边完善的系统。上线第一个月总会冒出各种预期之外的问题但只要监控体系到位、排查流程清晰稳定运行一两周后整体状态就会慢慢走向正轨。训练任务能从排队几天变成几分钟内分配完成用户满意的反馈就是最好的回报。