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

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

这个问题看起来很简单，就是要保证线上几万台机器的环境一致或是能实现我们想要的配置。但如果不提供底层的应用（如 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可以像单机一样查找集群中的问题：