作者：潘晓东
企业IT部潘晓东专注于云计算技术，在虚拟化、云计算、服务运维领域有超过十年的工作经验。本文是将其在OpenStack Days China的分享进行整理，内容上从稳定、可控、可运营三个方面，将其在大规模运算环境Tstack运维过程中所积累的经验进行总结分享。
1腾讯私有云Tstack现状
纸上得来终觉浅，绝知此事要躬行。说到云计算运维实践，必须有要实践的来源。腾讯私有云Tstack，目前运行了10000+ OS,可以算是国内最大的私有云平台之一。目前部署在深圳，天津，上海，成都四个区域，共拥有14个集群。在容灾架构上，采用两地三中心架构。与此同时，能够支持公有云私有云的统一管理，提供混合云的解决方案。更加难能可贵的是，Tstack上线5年时间里，可用率高达99.99%。下面将从三个方面介绍Tstack的运维使用经验。
2稳定重于泰山
稳定性对于一个线上服务平台来说，是非常重要的，脱离了稳定性谈服务运维就变得苍白无力。腾讯私有云主要从以下几个方面进行稳定性建设：
稳定性建设的第一要素，就是要从服务架构的层面去保证服务的高可用性，这样即使底层硬件发生故障时，层面能够自动容错。Tstack的管理节点，就是采用了高可用的架构设计。服务代理层、基础服务层、数据库、消息队列，都采用了相应的高可用架构，服务代理层采用HAProxy+Keepalive的模式，通过VRRP协议来保证服务高可用。基础服务层则是采用多实例模式，单一节点故障并不会影响整个服务。同样，MySQL采用Galera集群实现主主高可用模式，消息队列采用RabbitMQ的镜像集群模式。任何一个节点失效，都不会影响服务，从架构层面消除了单点。
我们知道，OpenStack对虚拟机调度是根据CPU、内存、磁盘等情况进行综合决策的，但是并没有考虑虚拟机业务的情况。在实际生产中，我们经常要搭建MySQL高可用集群，比如主备模式，在没有进行虚拟化之前，主备模式需要2台物理机，任何一台物理机宕机都不会影响服务。但是在云计算环境中，OpenStack就有可能将做了高可用的两台MySQL虚拟机调度到同一台物理主机上，这样此物理机故障或者维护，将影响业务，业务层的高可用就失效了。TStack根据自己的使用经验， 对业务进行了高可用调度考虑，避免了此问题的出现，保证了业务层高可用的有效性。与此同时，TStack虚拟机的资源使用模型，会有个综合的评估，会将CPU密集型、内存密集型、磁盘密集型分散调度，避免资源争抢，力求利用最大化。即使在虚拟机分配调度是不能准确预估资源的使用情况下，或者是在运行的过程中，虚拟机的使用情况发生了变化，Tstack也会更加历史运行数据，迁移虚拟机，力求动态均衡资源分布。
在云计算环境中，网络情况是复杂的，一般包括：管理网、业务网、存储网和带外网。单纯从某个网络或者某个节点去检查虚拟机的运行情况，可能都是不可靠的。TStack从计算节点的多个网络进行心跳发送，避免监控的不准确性，通过控制中心对主机的网络状况进行综合判断，当处理故障时，自动迁移，无需人工干预。
提升业务稳定性的方法，远不止以上三点，我们在运维的过程中，不断发现问题，不断改进和优化，才能确保服务的稳定运行。
3尽在掌控之中
要实现服务的安全运维，可控也是服务的关键指标。只有对每个服务的特点、性能了然于胸，才能真正保证服务的稳定运行。
性能是服务运行的关键指标，只有服务的性能是优化的，才能够更好的保障服务的稳定运行，才能在更大的流量爆发时扛住压力。采用计算机体系结构的方法论，TStack主要从三个方面进行性能优化：
1.并行计算：在云计算控制节点中，为实现高可用，同时提高性能，采用的是多实例模式，通过多实例，提高服务的性能和吞吐率。在程序内部，例如nova、neutron中，采用多线程和协程的技术，提高服务性能。比较值得一提的是预处理技术，在虚拟机迁移中，提供提前分发流表，迁移完成以后，网络立刻可用，使虚拟机在OpenStack上迁移的停机时间从数秒降低到100s一下。
2.缓存技术：在Ceph对象存储中，对象的元数据索引存放在硬盘上，不利于对象的list等从操作，通过将对象的元数据缓存在Redis中，可以很好的提升对象浏览的速度，提高吞吐率。同时在块存储中，通过开启RBD缓存，提升块存储的效率。同时，通过适当的提升Token的缓存时间，提升Keystone的效率。
- 压缩技术：压缩技术也是常用的一种优化技术。虚拟机迁移常常基于一种precopy算法，这是一种循环拷贝算法，主要原理是迭代拷贝虚拟机内存，每次都拷贝上次拷贝过程中修改过的内存，如果内存修改速度大于网络传输速度，这个拷贝就失效，那么虚拟机迁移的停机时间就很长。在迁移过程中，启用压缩传输，能够有效提高虚拟机传输的带宽，降低虚拟机迁移的停机时间。在对存储的优化中，压缩和去重是两种常有的技术。在Ceph中，TStack植入压缩存储引擎，支持lzo, snappy等快速压缩算法，对Ceph的块进行压缩。不过最近社区也开始支持此功能了。
服务可用是做服务的最低诉求，在任何时刻，都要保证服务的可用性，即使在是恶劣的环境下，也不能完全中断服务，至少核心业务的服务是不能中断的。TStack主要从三个方面来保证服务的柔性可用。
- 资源预留： 每个计算节点给宿主机预留1/16的内存，来保证libvirt、nova、ovs等服务的正常运行，同时采用CPU绑定技术，给宿主机预留2-4核作为nova等基础服务的资源使用。如果是超融合架构，则每个ceph osd预留一个核为其提供计算能力。在网络方面，采用管理网，业务网，存储网分离的模式，确保每个网络不相互干扰。
2.速度限制： 在云计算环境中，虚拟机与虚拟机之间虽然采用了KVM做了隔离，但是他们不可以避免的出现资源争抢，只是程度不同而已。比如，超融合架构下，TStack采用Cgroup进行了资源限制。另外也可采用cpulimit对CPU运行进行灵活限制，采用TC对网络进行限流。
3.过载保护： 服务运维常见的一个问题就是，当服务压力过大时，必须能够保证关键业务的运行，保障生命级业务的正常运行，因此，服务分级是必须的，在压力过大时，必须能够区分关键业务和非关键业务，确保正确疏散关键业务的压力。另外，在服务发布时，需要做的柔和发布，通俗的说，就是一台一台启动或者重启，不能一股脑全部启动或者重启，避免雪崩现象发生；与此同时，需要做好限速，在流量高峰期能够对业务进行可控限制。
灰度发布也是可用运营的一个重要部分，做好灰度发布，能够保证产品发布时对业务的影响降到最小。当我们的新版本开发完成，我们首先会到测试环境下进行测试，测试通过以后，会到一个灰度环境进行小流量试运营，因为测试环境下，无论怎么模拟，和线上环境还是会有差异，到灰度环境下，进一步发现问题，进行修复。根据版本功能改动的大小，决定灰度的时间的长短，可用是一天，一星期，或者一个月。在线上环境，可用先部署一部分机器，观察服务正常以后，再进行全部发布，做好回滚方案，一旦有问题，快速回滚。
4运营任重道远
可运营是一个云计算环境的重要保障。就拿车来举例子，不管是什么样的车，无论性能多好，加速多快，关键是要有方法去驾驶它，否则这辆车就会失去方向。云计算环境也一样，无论我们提供硬件有多好，功能有多强大，对于运维人员来说，可运营是最关键的。TStack从以下几个方面去保障服务的稳定运营：
监控是对服务运行情况感知的基础设施。可用说，监控就是运维人员的眼睛，通过监控能够发现服务各种运行细节，了解服务的运行状况。监控主要从以下几个方面去考虑：
-
覆盖度：覆盖度永远无法到100%，每次出现问题，最后发现监控都可用优化，TStack汲取腾讯18年的运维经验，从硬件、软件、服务、监控本身等方面，尽量提高云计算环境的监控覆盖度。
- 实时性： 为了提高实时性，可以加快采集频率，这样监控就可用做到秒级，但是频率太快，监控的压力非常大。为了在实时性和数据量上进行均衡，TStack选择的是最小频率为1分钟。
- 报警收敛：运营环境中的情况非常复杂，一个网络抖动，可用可能产生大量报警，如果没有很好的报警收敛策略，就可能导致短信网关堵住，影响后面的报警发出。同时需要做好报警分级，避免运营人员淹没在海量的报警中，而真正重要的报警却被忽略了。
- 精准性： 大多数监控因为数据太多，对历史数据都有平滑处理，TStack因为采用了强大的数据库后端，可用保证1年内不对数据进行平滑处理，方便历史数据的查看。
- 报表体系： 由于监控的采集了大量的数据，如果不进行筛选处理，运维人员就会淹没的海量监控数据中，只要服务不报警，运维人员对运维的运行状况毫无感知。事实上，服务的压力已经越来越大，这就需要对关键监控指标进行提取，做成报表，每天推送，让运维人员感知业务发生的变化。
标准化也是云计算环境运维的一个关键要素。俗话说，没有规矩，不成方圆。云计算运维环境的标准化尤其重要，运维环境、运维操作、服务扩容等都需要有完善的标准化流程，才能为业务保驾护航。
- 运维环境标准化： 首先，要有操作人员的权限控制，开发人员、测试人员、运维人员需要有不同的权限，比如开发测试人员只能有只读权限，运维人员才能有可用写可执行权限；其次， 服务配置需要规范起来，参数前面写好注视，相同配置采用拷贝方式等，目的是让配置统一起来，方便后面的排错；再次，程序目录需要统一规范起来，要么全部部署在/home下面，要么全部部署在/opt下面，这个看各个公司的习惯，最忌讳随心所欲，当出现故障时，还找不到目录，这是不应该出现的事情；最后，建议采用统一的启动关闭方式，因为每个程序启动的方式不尽相同，会给运维人员带来很多麻烦，最好程序有都有一个start.sh和stop.sh的脚本，让人一看就知道是怎么启动和关闭。
- 运维操作标准化： 首先，必须采用工单管理的方式，先把操作单发出来，经过审批，才能执行。工单必须写清楚具体的操作步骤和操作命令，写的模糊的工单，会让人有多种理解方式，很容易出错；其次，按单操作也很重要，最忌讳运维人员看到单子以后，发现单子与自己理解的意思不一样，按照自己的方式操作了，那就事情了工单的意义。即使工单有错误，需要和发单人员核实以后，重新审批才能操作；再次，操作需要采用双人或者多人的方式，一人操作，一人旁边观察，出现问题随时打断，提高操作准确性；最后，回滚备份是必不可少的，我们很难保证操作完成以后，一定不出问题，因此，随时都要做好备份，方便回滚。
- 服务扩容标准化： 服务扩容是经常发生的事情，在云计算环境，服务扩容也是有标准的。首先，需要对服务的计算模型进行评估，得出最佳的计算、存储、网络的比例，做成Set模型。在服务扩容的时候，按照Set模型，一个Set一个Set添加，这样能够保证服务的最优配比，规范运维环境，提高资源利用率。
俗话说：常在河边走，哪有不湿鞋。在云计算环境中，人工操作太多，总有可能出现故障。提高服务的自动化程度，能够大大减少运维故障。比如在添加计算节点的时候，我们尽量采取自动化添加，避免了手动操作的随意性。同时，采用自动化操作，即便出错，所以的错误也会一致。相比手动操作，更加容易排错。TStack运维中，采用了大量的自动化操作，通过蓝鲸平台，进行代码发布，线上部署，能够有效的减少运维故障，提高运维效率。
总结：云计算环境离不开运维的存在，可用说，好的运维是云计算服务稳定的可靠保障。首先,需要从服务架构上去保证服务的高可用性；其次，需要采用一些稳定可用的方式去管理服务，如高性能、柔性可用、灰度发布等；最后，需要从监控、标准化、自动化等三个方面保证服务的可运营性。其实，关于云计算的运维方法远不止这些，以上只是TStack运营过程中的一点经验总结。
