构建大型云计算平台分布式技术的实践
作者 章文嵩 发布于 2014年7月23日 |
本文基于章文嵩博士在2014年7月18日的全球架构师峰会ArchSummit上的主题演讲《构建大型云计算平台分布式技术的实践》整理而成。

演讲者简介

章文嵩博士是阿里集团的高级研究员与副总裁，主要负责基础核心软件研发和云计算产品研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本电子商务基础设施。他也是开放源码及Linux内核的开发者，著名的Linux集群项目LVS（Linux Virtual Server）的创始人和主要开发人员。LVS集群代码已在Linux 2.4和 2.6的官方内核中，保守估计全世界有几万套LVS集群系统在运行着，创造了近十亿美金的价值。加入阿里前，他是 TelTel的首席科学家与联合创始人，曾为国防科技大学计算机学院副教授。他在设计和架构大型系统、Linux操作系统、系统软件开发、系统安全和软件开发管理上有着丰富的经验。章文嵩博士在2009年加入阿里之后，先后负责淘宝的核心系统研发与阿里巴巴集团的基础研发，2013年10月开始同时负责阿里云的系统研发与阿里巴巴集团的基础研发工作。

本演讲主要分为五个部分：

1.  云计算的挑战与需求
2.  ECS的分布式存储设计
3.  SLB、RDS与OCS的设计
4.  全链路监控与分析系统
5.  未来工作展望
云计算的挑战与需求

云计算跟淘宝在业务特点上有较大的不同，其中最大的不同就在于：淘宝、天猫是由四千多个小应用去支持的，都是分布式设计，很多情况下即使一两个应用宕机了，也不影响整体的服务，可以按部就班的修复。对于淘宝而言，只有交易量下降了10%以上的情况会算做是P1故障，开始计算全站不可用的时间。

而对于云计算的场景而言，一个云主机宕机了，对这个客户来说就是100%的不可用，而这可能是这个客户的全部“身家性命”。所以，云计算平台对可靠性、稳定性的需求是非常高的。以前我们可能网络遇到问题，但是上层应用设计得好，就把这个问题隐蔽掉了；而对于云平台，要求是更高的可靠性，而且数据不能丢，系统稳定，性能还要好——目前尽量跟用户自己买物理机的性能差不多，另外要能够快速定位问题，最好在用户发现问题之前就先把问题解决了，让用户感知不到。还有就是成本要低，比用户自己买服务器便宜是底线。

ECS的分布式存储设计

ECS是阿里云的云服务器产品线，也是我们销量最大的产品。其背后是分布式文件存储，支持快照制作、快照回滚、自定义镜像、故障迁移、网络组隔离、防攻击、动态升级等功能。ECS的管理基于一个庞大的控制系统，目前一个控制系统可以控制3600台物理机的规模，未来计划要做到5000台到两万台。

这其中，数据可靠性是极为关键的。阿里云以前的做法是数据写入的时候同步写三份到分布式存储上的chunk server上之后才算成功，这种实现的开销大，延时长，造成当时阿里云的用户抱怨性能不好。后来，我们做了2-3异步，即同步写2份确保成功，异步写第三份，IO性能上得到一定的改善。我们现在对这个过程再做优化：读写性能优化的关键在于返回成功的时间，因为吞吐率是时间的倒数，延时缩短性能就会提升。缩短延时的思路之一就是将原本过长的路程截断以进行缩短，同时保证数据的可靠性。其具体思路为：

·         SSD+SATA的混合存储方案，写入的时候在本地的两个SSD上做同步写，第三份异步的同步到后面的chunk server上。这个方案做到的randwrite-4K-128可达5500 IOPS左右
·         cache机制
·         以多线程事件驱动架构重构TDC和Chunk Server的实现，做到一个IO请求在物理机上只用一个线程完成所有工作，避免锁和上下文切换
下面详细介绍一下这几个机制的设计。

IO路径上的各层cache与写IO的几种模式探索

从应用发出请求到数据写入磁盘的路径上有三层cache，依次是应用程序的user cache（如MySQL buffer pool）、操作系统的缓存（如Linux page cache）、以及存储硬件的cache（如磁盘的缓存）。

由此可以引申出如下几种写IO的模式：

·         buffer write，写入目标是guest OS的page cache，通过writeback刷到硬盘的缓存，然后再通过自动刷或者sync命令触发的方式刷到持久化存储介质上。这种写方案的速度很快，缺点是数据完整性无法得到严密保证（取决于回写的策略），而且回写有可能引起阻塞而影响服务质量
·         direct write，从应用直接写到硬件上的缓存，绕过操作系统的page cache。比如MySQL引擎自己有缓存机制，就可以使用direct write写到硬盘缓存然后再通过sync命令刷到下面的存储介质。绕过page cache的好处是避开了回写的影响，但数据仍然不是绝对可靠，sync完毕之前数据仍然是不安全的
·         write+sync，写入page cache的同时即调用sync/fsync直接写到存储介质，sync返回算成功。此方式的好处是数据足够安全，缺点是慢，具体等待时间随着操作系统内存使用情况的不同而不同
·         O_SYNC，加了此标签的写入操作会在数据写入硬盘缓存时同步刷到碟片上
以上就是系统提供的几种机制。以本地SAS盘作为参考，在虚拟机中以4k的块大小做dd的写入速度，buffer write平均在212MB/s，direct write平均在68MB/s，而direct+sync则平均在257kB/s。实际应用中可以根据不同情况、不同应用选择不同的方式，一般来说 buffer write和direct write是主流，两者加起来占据了97%的写操作。

云计算环境中的IO

以上分析的是本地的情况，写入的目标是本地的硬盘缓存与存储介质。那么在云计算环境中，我们不仅可以选择本地，还可以有分布式存储。分布式存储相当于本地的存储介质，我们目前的思路是在其上加一层分布式缓存系统作为本地硬盘缓存的替代。相当于整个写IO路径在云计算环境中变成了：

VM SYNC->PV前端FLUSH->后端->host->cache系统->分布式存储系统

为了确保数据完整性，我们的语义全部符合POSIX，将语义由以上路径从VM透传IO全链路。

cache系统的效果

我们用以下指令对ECS的写性能进行测试：

 ./fio -direct=1 -iodepth=1 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G
在iodepth=1的状态，纯SATA分布式存储只有200左右的iops，平均延时在8ms，抖动幅度（标准方差）达到7ms。

加入SSD cache系统之后，iops提升到600左右，平均延时降低到3ms，抖动幅度降低至2ms左右。

 ./fio -direct=1 -iodepth=8 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G
增加iodepth到8的状态，纯SATA分布式存储的iops提升至2100左右，平均延时在7ms，抖动幅度依然是7ms左右。

加入SSD cache之后，iops提升到2900左右，平均延时在5ms左右，抖动幅度约为1ms。

以上是cache方案的两点好处：

1.  加速写请求。未来我们也会加入对读请求的加速
2.  降低分布式存储系统的抖动对上层应用的影响。这种抖动在高并发的情况对延时的影响相当大，Google的Jeff Dean于2013年2月发表于CACM上的The Tail at Scale一文详细描述了这个影响：“如果有1%的概率请求延迟超过1S，并发100个请求，然后等待所有请求返回，延时超过1S的概率为63%”
ECS不同的存储选择

目前在ECS上可以有几种实例选择：背后是纯SATA存储集群的实例，适合大部分应用；对于IO性能要求更高的应用可以选择混合存储集群；我们未来还会推出性能更高的纯SSD集群，预计将在11月/12月推出，目前的测试数据是物理机chunk server可以做到最高18万的iops，虚机上可以把万兆跑满，iops在9万左右，目前的问题就是跑满的状态需要消耗6颗HT CPU，这一部分还有待优化。

另外，对于Hadoop、HBase、MongoDB这样本身已经考虑了3副本的系统，阿里云还提供了SATA本地磁盘和SSD本地磁盘的ECS，减少不必要的冗余以降低成本。

以上就是我们对云服务器产品ECS的一些优化工作。云服务器理论上可以用来跑任何东西，但是通用的方案不适合做所有的事情。因此，阿里云同时提供了一些细分产品，在特定应用场景下将取舍做到极致——

SLB、RDS与OCS

SLB是阿里云的负载均衡产品，提供了4层的（基于LVS）和7层的（基于Tengine），支持等价路由和Anycast跨机房容灾，同时具备防攻击的特性。一台12物理核机器的SLB的正常转发性能在1200万左右的pps，心跳可以做几千台；而同等配置的ECS（千兆网络）的转发性能只有70万左右的pps，心跳也只能做两台。

RDS是阿里云的数据库服务，跑在物理机上（而非虚拟机）。RDS数据通道采用标准的三层架构，每层都做到机房和部件冗余，无状态设计；中间层提供了安全防护、流量调度和桥接的功能，管理通道以元数据库（MySQL）为中心，消息驱动，各组件异步通信，无状态支持热升级，一个控制系统下可以管理数万个 MySQL实例。RDS依赖于很多其他团队开发的组件，包括用SLB做负载均衡，接ODPS做过滤分析，SLS做日志收集，OSS做备份，OAS做冷数据的备份，用精卫做分表，以及全链路的控制系统和组件监控。同等配置下，RDS的tps要比ECS高两、三倍。

OCS是阿里云的缓存服务，基于Tair搭建，前面的Proxy负责了安全访问控制、QoS、流控的工作。OCS目前是一个集群都在一个机房，可随时扩容，对用户提供了全面的监控数据和图形展示。性能方面，OCS上目前99%的请求都做到了2ms以内响应，去年双十一，整个OCS集群的能力做到了一秒内可处理一亿个请求。同等配置下，OCS的成本要比ECS上自建Memcached便宜一半。

全链路监控与分析系统

监控分析系统目前在RDS上用的比较重。坦白讲去年RDS遇到很多问题，很大一部分问题就是闪断：背后的机器故障时，MySQL实例会迁移，这时候如果客户端的应用做得好，应用会自动发起重连的请求，保持原先的连接，但很多应用做的时候并没有考虑这个问题。那时候很多游戏厂商遇到这个问题，让他们改程序也很困难，不可能一个一个帮助他们优化，所以就需要后端帮他们的实例做保持连接和重连的工作。

所以我们建立起全链路的监控，收集所有的SQL日志、网络行为和用户行为，注入到一个Kafka集群，然后用JStorm和Spark做实时分析，ODPS做离线分析。目前每天的SQL日志语句的量级在几十个T，可以在秒级发现问题，比如发现请求慢了，则会给用户提醒是否没有建索引，而网络异常、连接中断的情况则会及时报警。

目前这套系统先用在RDS上，未来各个云产品需要将自己的异常分析都抽象出来注入到这个系统当中，完成全产品线的全链路监控。

未来工作展望

首先，ECS上全路径IO还需要持续优化，力求在全国、全球做到最好的性能。这涉及到Cache策略的优化，带SSD的读写缓存，存储与计算分离，万兆纯 SSD集群，动态热点迁移技术，GPU支持，LXC/cgroups支持等。比如纯SSD的集群，iops已经挖掘的很高的情况，如何降低CPU消耗？Cache现在为了快速，往下刷的频率是比较高的，这方面的策略能否优化，做批量刷？以前部署的SATA集群，是否都加上SSD缓存？如果本地缓存的命中率在90%以上，是否可以做计算节点和存储节点分离，这样可以让计算和存储按自己的需求发展。未来实现动态的热点迁移，可以在云计算上要实现更高的超配，当一台物理机发生比较忙的情况下，系统能自动将一些实例迁移到比较闲的机器上。目前淘宝的聚石塔、阿里小贷都已经在阿里云，未来会将淘宝无缝迁移到云平台上并降低成本，这些都是ECS上未来需要做的工作。

RDS方面，目前支持MySQL和SQL Server，计划加入PostgreSQL以方便Oracle用户往这边迁移。容灾方面，目前是双机房容灾，成本还比较高，是否可以通过非常高速的非易失性网络存储来存储redo log，容量不需要大，数据存储在分布式文件系统，做一个低成本的RDS方案，只是用户需要容忍几十秒的MySQL实例宕机重启的时间？这需要架构师做取舍，看我们要放弃一些什么以得到一些东西。

另外，全链路的监控与分析系统，我们也需要进一步应用到全线云产品之上。未来还会推出更多的云产品，包括无线网络加速、 AliBench服务质量监测（目前在内部使用）、OCR识别服务、深度学习的CNN/DNN计算服务等。