微信号:infoqchina

介绍:有内容的技术社区媒体

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

2014-07-24 18:35 InfoQ

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

章文嵩博士是阿里集团的高级研究员与副总裁。他也是开放源码及Linux内核的开发者,著名的Linux集群项目LVSLinux Virtual Server)的创始人和主要开发人员。LVS集群代码已在Linux 2.4 2.6的官方内核中,保守估计全世界有几万套LVS集群系统在运行着,创造了近十亿美金的价值。


云计算的挑战与需求

云计算跟淘宝在业务特点上有较大的不同,其中最大的不同就在于:淘宝、天猫是由四千多个小应用去支持的,都是分布式设计,很多情况下即使一两个应用宕机了,也不影响整体的服务,可以按部就班的修复。对于淘宝而言,只有交易量下降了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机制

  • 以多线程事件驱动架构重构TDCChunk Server的实现,做到一个IO请求在物理机上只用一个线程完成所有工作,避免锁和上下文切换


SLBRDSOCS

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


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


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


全链路监控与分析系统

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


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


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


未来工作展望

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


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


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


更多精彩内容,请点击阅读原文。

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 从MVC框架看MVC架构的设计 【技巧】拿来即用!用文件统统不解压 算法、技术及其它 HTTP, HTTP2.0, SPDY, HTTPS | 4种网络协议的渊源与发展 Android逆向之旅---Android应用的安全的攻防之战