大规模分布式系统运维实践

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

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

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

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

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

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

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

大规模与精细化的平衡

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

提高系统化的基础环境管理能力

这个问题看起来很简单，就是要保证线上几万台机器的环境一致或是能实现咱们想要的配置。但若是不提供底层的应用（如BIOS、FW等），仅是操做系统层面（如网卡驱动版本、系统参数的配置、基础软件的版本等），众多品类就很难统一，尤为是当硬件基础发生变化的时候。举个简单的例子，假如一台机器的某块硬盘坏掉了，系统应用须要可以自动将损坏的硬盘下线。后台的监控程序会进行轮询，直到发现这块坏盘，并将这块盘从系统里下线，进行修复处理后，再尝试可否加回集群。若是不能，就说明这个盘可能完全坏了没法修复，系统就会自动提交报修工单，整个过程无需人为干预。现场工做人员接到报修工单后，能够从容安排时间，统一更换坏盘。新的硬盘装好后，系统会自动识别并添加到服务中。若是故障的是系统盘，只要完成更换，系统就会自动触发安装和部署。同时要保证全部的驱动版本、FW、系统参数和软件版本等作到同步一致地去Push。可见，在这个故障的整个处理过程当中，只有更换硬盘这个动做须要人工介入。若是有服务器重装的需求，咱们会每周或每个月按期整理，启动自动化的部署触发，对整台机器进行初始化处理，让系统处于应用部署状态，机器就会找到本身的兄弟节点去作一次克隆，恢复成跟线上的“兄弟姐妹”如出一辙的状态，而后再上线。这个过程也是全自动完成的，惟一的人工介入就是点击触发命令。

大规模集群快速自动化部署

你们知道在运维工做中有很大一部分是部署升级。而对于大规模集群来讲部署升级这部分工做尤为重要。在飞天5K项目中，集群机器数量短时间内由1000多台直接扩展到5000台。这时，发现老的部署方式基本没法自动完成5000台服务器部署。同时按老的方式作一次冷升级须要4~5个小时，这是应用没法接受的。因而，咱们在分布式部署工具大禹上也作了许多工做，提升了飞天部署效率，支持运维人员定制本身的部署流程，管理集群的基本信息，同时还提供了丰富的工具集，包括文件分发工具、远程执行工具、集群信息管理工具和集群缩容扩容等。咱们从新定义了应用binaryconf的目录结构，同时分离配置和binary部署，为配置中心统筹全部配置留出接口；分离应用binary和数据结构，在确保版本快速切换同时，保证了应用数据连贯性提供快速回滚的方案；轻量化对数据库的依赖，角色资源信息采用读取本地缓存方式；模块化部署，同时支持交互式与非交互式部署。并且最主要的是，在部署时，咱们对应用binany分包传输方式作了调整，新开发了一套多点分布并发传输工具，由之前单点传输速度越快越好，转变为多点精确控制流量下按预期传输。最终在整个5K项目结项时，整个集群冷部署升级时可以将服务中止时间控制在20~30分钟。

自研的简单日志服务SLS

咱们如今面对的大规模分布式系统比以往任何系统都要复杂，系统自己有很是多的组件，每一个组件又有各自的Log数据，而不少Log之间又相互关联，量大且目标多。在飞天5000台服务器的环境下，大约有5000多个并发做业须要实时计算并发度、运行状态、使用Quota等指标。从输入的源数据来看，整个集群须要实时分析的性能数据产出速度大约为65MB / s，日志数据的量更会提高一个数量级。须要同时汇聚的种类和维度不少，大到机器，小到做业和文件都须要有不一样的视角能切入探索，定位细节根源。并且这些Log都是分布在每台Slave机器上的，须要统一地汇总收集进行分析。为此，咱们使用了阿里云自研的简单日志服务（SLS）来知足这些复杂的需求。SLS的主要功能有如下几点。

• 实时收集AuditLog，监控全部操做的QPS和执行结果。
• 监控每种操做的等待延时与执行延时。
• 监控每一个文件、请求和Session客户端执行生命周期。
• 经过FileID、文件名和操做类型进行实时分析，对整个文件的操做生命周期监控。

虽然syslog也作了一系列分析，但因为它散布在各个机器上，查找和定位很是不方便，而经过SLS能够像单机同样查找集群中的问题：

• 整个集群是否有特定错误；
• 天天针对segfault、oom和cgroup进行离线统计，根据具体segfault事件定位具体的内容和机器，如图1所示。

经过SLS的各项指标和Log分析，对集群的总体性能、QPS和流量等是否符合预期、做业 / 文件 / Slave上的存储单元的生命周期是怎样的，这些宏观状态和微观细节都有完整的把握, 进而帮助咱们全面掌握分布式系统的状况。这项简单日志服务SLS不久前已经过阿里云对外公测，每一个用户能够免费建立1个项目，并能使用不超过10M / s的写入流量。

不断完善的AliMonitor监控系统

面对上万台机器，好几十个模块，几十万个监控项，想要了解哪些机器监控项缺乏、哪些机器监控项异常、今天有哪些监控项报警、报警了多少次、团队中每一个人天天收到多少报警、哪些是能够系统自动处理不报警的等，都须要从监控数据入手，真正对整个平台的监控有直观而全面的了解，并在数据的指导下持续完善监控系统。

大规模的互联网公司都极其详细地定制化监控需求，阿里也不例外，咱们基于多年的运维经验自主开发了一套监控系统AliMonitor，而且根据业务需求不断进行优化和完善。Alimonitor是一套统一的分布式监控平台，支持系统监控、网络监控、客户端监控、容量监控、趋势监控等，能自动添加基本监控，对服务器、虚拟机、应用VIP、网络设备、Java应用等能提供准实时预警、报警，从数据采集到发出报警仅须要5秒钟，让运维人员第一时间掌握服务的健康情况。同时，它还具有多种故障预测及发现方式、丰富的数据图表展现、容量规划和报警，以及视图的定制等功能。

开发和运维须要更加紧密合做

和传统的业务系统相比，分布式系统规模大和复杂性高，须要开发和运维更加紧密地合做。从运维人员的角度来看，运维就是对线上生产系统负责，是线上系统的Owner，要全面且深刻地了解产品。从开发人员的角度来讲，若是对运维工做一无所知，那么也很难开发出可靠的产品。所以，若是开发人员和运维人员之间存在壁垒，显然会大大影响产品的稳定性。须要注意的是，这不是要模糊开发人员和运维人员的职责，双方仍然要保持明确的分工，但在技术技能上，双方应该更加靠近。例如，在飞天5K项目中，运维人员和开发人员紧密合做，用最短的时间开发完成了自有的大规模部署系统（大禹）和异常故障自动化处理系统（华佗）。并且在共同工做中，双方都收获甚丰。

结语

对于阿里这种规模的互联网公司而言，随着体量愈来愈大，用户数量和基础设施投入都在快速膨胀，数据也在呈几何倍数增加。所以，在运维工做上已很难找到其余企业的成功经验来借鉴，但又不能凭空揣测解决方案，由于一旦判断失误，就会给公司形成巨大的损失。在这种状况下，咱们深入感觉到只有一条通路：经过对真实数据进行分析和预测，将判断失误的几率降到最低。咱们相信，只要数据真实而且挖掘得足够深刻，必定能找到最优的解决方案。例如，在平常运维中，咱们已能够收集到不一样通道的数据，如服务器温度、负载、磁盘、应用情况等，并且数据种类和数量都在不断增长。若是可以找到其中的联系并快速分析，将会给咱们的工做带来更大变化。而基于技术分析优化运维水平，将是一个值得持续探究的课题，也是咱们团队一个比较大的挑战。