飞天5K实战经验：大规模分布式系统运维实践

2013年，云梯1实现空间优化与跨机房集群扩展，云梯2单集群规模从1500台升级到5000台，同时跨集群扩展的5K项目顺利取得阶段性成果，阿里成为第一个独立研发拥有这类大规模通用计算平台的公司。当时，云梯1、云梯2，再加上已上线的生产集群，阿里整体集群规模已超过万台。迄今为止，全球范围内，只有少数几家公司拥有如此规模的自主知识产权的集群。我们非常幸运，能够运维和管理如此大规模的生产集群。但短时间大规模快速膨胀的现状，确实也为运维工作带来了巨大的挑战。面对这些挑战，我们不仅迅速实现了自动化运维，还进行了数据化管理的转型。

服务器数量激增，要求提升全局掌控能力

传统的运维人员通常只面对几十或者上百台的服务器，规模不会太大，而且相对应用来说，每台机器都是一个独立节点。但在大规模分布式集群中，工作任务明显不同：首先，运维人员面临的服务器动辄就是三五千台甚至上万台，量级大幅提升；其次，分布式 操作系统提供存储、CPU调度能力、内存使用、网络等功能，是基本资源的包装整合，从逻辑上看，相当于一台计算机；最后，基于分布式系统开发的应用相当于一个分布式数据仓库，用户可以在上面做ETL处理、SQL查询、数据导入导出等基本操作，以及实现一些MATLAB、统计 软件等功能。因此，与传统运维相比，大数据运维人员要有更强大的整体把控能力，包括对机房网络、带宽、硬件、服务器的性能进行优化，熟悉飞天和Hadoop的上层应用，实现数据分析等，做到对各个方面的情况了如指掌。

以飞天5K项目为例，由于单集群的服务器规模是5000台，基本已独占1个机房，所以需要对整体机房的状况（包括网络、空调、维修和现场应急状态响应等），服务器，操作系统和上层应用进行全面的掌握。为了实现这个目标，我们先是做了多次演练来验证集群的稳定性，包括部分网络设备关机，整机架服务器断电，Master服务器随机挑选一台断电等。准备充分后，又做了一次“史无前例”的Failover测试——整体机房断电。演习当天，飞天及ODPS的恢复过程大概历时3个小时，整个演习过程中无数据丢失。经过这次压力测试，我们全面了解了系统的稳定性情况，锻炼了运维团队在最短时间内恢复整个集群的协作能力，积累了更好地保障用户稳定运行的宝贵经验。

实现系统的自我保护和自动化修复

在做5K项目测试时，一个测试作业由于用户使用不当导致盘古存储服务器文件数突增3000万个，造成存储Master服务器繁忙，整体系统处理能力大幅降低，对系统造成了不小的冲击。虽然我们发现这一问题后立刻做了相应的限制处理，但此类问题还是引发了我们的思考。一般来说，出现如此问题时，开发人员和设计人员会将原因归结为用户不会使用或使用不当。言下之意就是，产品层面很难避免，也无法彻底解决。但站在运维角度来看，应该有更好的解决方案，一方面不能因为用户的一个作业失常而停止服务；另一方面，也不能总是依靠“人肉”救火。系统应该具备自我保护能力，这也是产品要努力的方向之一。

此外，大规模分布式系统选用的都是低成本服务器，设备损坏很常见。要实现对整个系统（包括飞天、ODPS、Linux、硬件和网络等）的运维，就需要做好“软硬件故障成为常态”的准备，一旦发生异常情况，能立即实现自动闭环处理，无需人工干预。为此，阿里的运维和开发团队合作研发了一套异常故障自动化处理系统——华佗。目前华佗系统已具备自动处理基本硬件和服务异常等常见问题的闭环处理能力，并且还在持续完善当中（具体可参阅《走近华佗，解析自动化故障处理系统背后的秘密》一文）。

大规模与精细化的平衡

当运维的服务器达到数千台甚至上万台时会遇到诸多挑战，如硬件配置的差异化、用户数和任务数的急剧膨胀、大压力下的边界效应、小概率事件被触发等。在这个前提下，我们依然成功满足了诸如快速部署、自动化运维、监控报警、Log分析和精细化计量等运维要求，主要从以下三点着手。