构建大型云计算平台分布式技术的实践

构建大型云计算平台分布式技术的实践 做者 章文嵩 发布于 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计算服务等。