标签：资源 参数 模块化 audit 避免 任务 alt 例子 无数据
2013年，云梯1实现空间优化与跨机房集群扩展，云梯2单集群规模从1500台升级到5000台，同时跨集群扩展的5K项目顺利取得阶段性成果，阿里成为第一个独立研发拥有这类大规模通用计算平台的公司。当时，云梯1、云梯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的主要功能有以下几点。
虽然syslog也做了一系列分析，但由于它散布在各个机器上，查找和定位非常不方便，而通过SLS可以像单机一样查找集群中的问题：
通过SLS的各项指标和Log分析，对集群的整体性能、QPS和流量等是否符合预期、作业 / 文件 / Slave上的存储单元的生命周期是怎样的，这些宏观状态和微观细节都有完整的把握, 进而帮助我们全面掌握分布式系统的情况。这项简单日志服务SLS不久前已通过阿里云对外公测，每个用户可以免费创建1个项目，并能使用不超过10M / s的写入流量。
不断完善的AliMonitor监控系统
面对上万台机器，好几十个模块，几十万个监控项，想要了解哪些机器监控项缺少、哪些机器监控项异常、今天有哪些监控项报警、报警了多少次、团队中每个人每天收到多少报警、哪些是可以系统自动处理不报警的等，都需要从监控数据入手，真正对整个平台的监控有直观而全面的了解，并在数据的指导下持续完善监控系统。
大规模的互联网公司都极其详细地定制化监控需求，阿里也不例外，我们基于多年的运维经验自主开发了一套监控系统AliMonitor，并且根据业务需求不断进行优化和完善。Alimonitor是一套统一的分布式监控平台，支持系统监控、网络监控、客户端监控、容量监控、趋势监控等，能自动添加基本监控，对服务器、虚拟机、应用VIP、网络设备、Java应用等能提供准实时预警、报警，从数据采集到发出报警仅需要5秒钟，让运维人员第一时间掌握服务的健康状况。同时，它还具备多种故障预测及发现方式、丰富的数据图表展示、容量规划和报警，以及视图的定制等功能。
和传统的业务系统相比，分布式系统规模大和复杂性高，需要开发和运维更加紧密地合作。从运维人员的角度来看，运维就是对线上生产系统负责，是线上系统的Owner，要全面且深入地了解产品。从开发人员的角度来说，如果对运维工作一无所知，那么也很难开发出可靠的产品。因此，如果开发人员和运维人员之间存在壁垒，显然会大大影响产品的稳定性。需要注意的是，这不是要模糊开发人员和运维人员的职责，双方仍然要保持明确的分工，但在技术技能上，双方应该更加靠近。例如，在飞天5K项目中，运维人员和开发人员紧密合作，用最短的时间开发完成了自有的大规模部署系统（大禹）和异常故障自动化处理系统（华佗）。而且在共同工作中，双方都收获甚丰。
对于阿里这种规模的互联网公司而言，随着体量越来越大，用户数量和基础设施投入都在快速膨胀，数据也在呈几何倍数增长。因此，在运维工作上已很难找到其他企业的成功经验来借鉴，但又不能凭空揣测解决方案，因为一旦判断失误，就会给公司造成巨大的损失。在这种情况下，我们深刻感受到只有一条通路：通过对真实数据进行分析和预测，将判断失误的概率降到最低。我们相信，只要数据真实并且挖掘得足够深入，一定能找到最优的解决方案。例如，在日常运维中，我们已可以收集到不同通道的数据，如服务器温度、负载、磁盘、应用状况等，而且数据种类和数量都在不断增加。如果能够找到其中的联系并快速分析，将会给我们的工作带来更大变化。而基于技术分析优化运维水平，将是一个值得持续探究的课题，也是我们团队一个比较大的挑战。
阿里云数加大数据计算服务MaxCompute产品地址：https://www.aliyun.com/product/odps
标签：资源 参数 模块化 audit 避免 任务 alt 例子 无数据
原文地址：http://www.cnblogs.com/libo66/p/6560879.html
