本报道对2015年QCon北京大会云计算高可用架构设计与实践专场的内容进行概述。本专场的四位分享者均来自阿里云,分别是阿里云虚拟化技术总监张献涛(旭卿),阿里巴巴数据库专家傅翠云,阿里巴巴ODPS和iDST产品经理韦啸,以及阿里云金融行业资深架构师刘刚。本专场的分享可视为了解阿里云技术现状的渠道。
张献涛(旭卿)的分享内容是阿里云在2015年3月对Xen高危漏洞进行热补丁修复的经验。旭卿毕业于武汉大学,信息安全博士,2014年加入阿里云,任资深专家及虚拟化技术总监。之前曾供职于英特尔开源技术中心,是Xen、KVM等多个开源虚拟化项目的主要贡献者。目前正在主持阿里云弹性计算虚拟化架构的设计和研发工作。
2015年3月10日,Xen社区安全团队公开披露了高危漏洞XSA-123,该漏洞可能导致一台Guest VM读取到其他Guest VM的敏感数据。由于此漏洞对公有云服务的影响重大,各个公有云厂商分别对此漏洞进行了重启修复或热补丁修复,其中,阿里云就是使用了热补丁修复的方式,在没有造成用户主机下线的情况下完成了整个系统的修复。
Xen发布十多年以来总共公开发布了125个漏洞报告,其中影响最大的可以说是两个:一个是去年的XSA-108,一个可能导致hypervisor内存泄露的漏洞;另一个就是今年3月10日公布的XSA-123这个漏洞,可能导致客户机提权访问到其他客户机的数据。
阿里云从Xen安全团队接到XSA-123的漏洞通报是在2月28日,是个星期六,按照惯例该漏洞会在10日之后公开,因此阿里云有10天的时间修复此漏洞。第二天也就是3月1日开始分析这个漏洞,在3月2日确定该漏洞为高危并提出两个修复的方向,打冷补丁重启生效,或者热补丁不重启生效。
内核热补丁并不是新技术,hotfix有很多成熟的方案,比如Oracle的Ksplice,SUSE的Kgraft,红帽的Kpatch,阿里的AliHotfix,另外在Linux 4.0内核开始,对hotfix已经有原生支持,所以已经是很成熟的一个技术。但是虚拟机的热补丁修复要比单纯的内核修复更加复杂。为什么呢?内核hotfix的基本原理是基于函数动态替换技术,补丁(即新函数)会以模块内函数的形式链接入内核,旧函数的第一个指令改成强制跳转指令指向新函数。这个替换的过程需要暂停所有CPU,切到一个内核线程并关闭本地中断,然后刷新指令缓存,重新让CPU恢复执行。这个过程的特点是内核有pre-defined接口,hotfix过程有权访问内核内存并插入内核Module进行函数级别的替换,而且因为是由CPU执行指令,要修复函数的位置是比较容易确定的。但是,Xen作为Type I hypervisor,其内存是被严格隔离的,管理员可访问的区域只有Dom0,而不能直接访问Xen Hypervisor的区域;而且Xen Hypervisor被装载的地址是动态的。Xen Hypervisor也不支持module插入,无法进行函数级别的替换。而且对于在线运行的云服务而言,如阿里云是2009年就上线运行,那时候并没有预留hotfix的接口。
3月2日下午,阿里云团队确认了hotfix的基本思路,就是利用硬盘设备读文件的DMA请求,截获这个请求,把补丁信息传入,修改DMA目的地址,以将补丁信息写入Xen Hypervisor的内存。3月5日晚,第一版hotfix开始测试,测试发现有万分之三的宕机率,于是继续优化。3月6日晚发布的第二版hotfix方案测试结果很好,完全没有宕机,就灰度发布到部分线上机器上,在3月7日、8日观察了两日,没有检测到问题。于是3月9日阿里云给用户发布公告,同时开始给线上机器批量应用补丁,到3月10日发布完毕,同日漏洞公开。
张献涛从整个修复过程总结了一个经验,就是云计算是系统工程,并不是开发大牛就能够解决一切问题的,而是需要开发、运维、测试、安全多个团队紧密合作,这很重要。
傅翠云(延瑛)分享的话题是阿里巴巴的异地双活数据中心DRC。傅翠云在2008年加入Oracle,曾任Berkeley DB的高级软件工程师,从事Berkeley DB数据库和高可用内核开发。2013年加入阿里巴巴数据库技术团队,任数据库专家,目前负责数据流产品DRC,参与了2014年阿里巴巴双十一交易异地双活数据同步和订阅、RDS迁移上云服务、七网隔离跨域同步、性能分析和优化、数据校验、链路优化等。
所谓异地双活主要关注两件事,一个数据同步,一个数据分发。阿里异地双活数据架构基础设施DRC目前已经正式上线在RDS产品,现在RDS官网已经有了数据迁移的功能,另外也在公测更多服务。
到底怎样的应用会需要异地的双活?比较常见的场景有三个。
所谓DRC,就是Data Replication Center的缩写,数据复制中心。这种复制是同步的,支持异构的,高可用的(有严格容灾系统,实时性好),支持订阅分发的。
以前在一个城市做双机房主备,两个机房是数据对等的,写入是随机分布,然后通过主备HA进行数据同步。这样机房对等的思路会导致业务增长、数据增长只能通过两个机房不停堆机器来解决。另一方面,如果整个城市断电,那么双活就成了双死。下一个思路是做跨城市,早期常用的做法是一个城市写,另一个城市冷备,就是晚上做同步,但这就意味着白天如果发生了什么事儿,这一天的数据就比较危险。另一个思路是两个城市多写,数据落两边,这样的问题是应用调用次数频繁的话,如果调用异地数据多来那么一两次,整个应用的延时就很长。这个思路再进一步发展,就是做单元内封闭以减少异地调用,这就涉及到业务上的改造。
顺着这个思路,阿里的异地双活重点做了几件事。一个是热插拔,可以做到在业务高峰时增加节点,高峰过了把增加的节点关闭。做到这个的一个关键是流量实时切换,DRC可以在20秒以内把一个单元(region)的流量迁移到另一个单元。另一个是数据实时恢复,就是通过一定的冗余设计,一旦一个单元挂掉了,可以在另一个单元做全量恢复。
2014年双十一,这套异地双活系统处理的规模是,抓取了约100TB的实时数据量,给17000多个实时下游提供了最高每秒30GB的数据量。2014年期间DRC已经覆盖了超过50%的新增RDS实例。
韦啸分享的主题是他们在ODPS上做的一些平台服务性质的事情。韦啸(龙场),阿里巴巴ODPS和iDST产品经理,中国科学技术大学量子通信硕士,普渡大学计算物理硕士,密西根大学信息学硕士。阿里巴巴ODPS和iDST产品经理。曾任职微软Windows、Surface、Bing产品经理,获微软GoldStar奖和Hackday Winnner等。
韦啸是几个月前加入的ODPS,最近迁移到新团队iDST,即数据科学研究院,该团队跟ODPS团队协作一个叫做阿里PAI的产品,以期用更加友好的方式帮助阿里云客户运用自己的数据。
ODPS目前处理的数据量已经到EB级别,数据增长越快意味着成本越高。目前ODPS已经可以做到单集群15000台服务器的规模,在这个规模下保持20%以下的性能损耗。而单个ODPS的部署则可以多集群部署100万台以上的规模,当然这会有更大的性能损耗,对网络和灾备环境有更多依赖。支持异地。
使用上有几个特点:
ODPS现在支持的计算引擎大致如下:
SQL和MapReduce,编程模型简单,适合流水线作业。离线SQL的性能优于HIVE,准实时SQL中间数据不落盘性能优于TEZ。
图计算引擎,使用上类似Pregel,对于PageRank或者标签传播这种场景是很高效的算法。计算规模支持最大41亿顶点数,300亿边数,120万迭代次数,6千亿发送消息量。
R,适合处理GB级别的小数据。
MPI(message passing interface),科研界流行的引擎。支持数据切片,子进程计算,上传超步。MPI是内存计算,适合迭代多的算法。
Parameter Server参数服务器计算框架,这个是今年在开发的,支持超大模型,不仅对数据分片,也对模型分片,以应对模型数量超过机器内存的场景。
以上是ODPS的硬能力。为了将这些能力如何更好的开放,iDST团队在上层做了阿里PAI算法平台,预计将在今年5月为天池算法大赛的选手们提供支持。
最后一场,刘刚分享的话题是余额宝、三马保险等IT转型案例。刘刚(法华),阿里云金融行业资深架构师,阿里金融云创始团队成员,是“三马保险”、“余额宝”等相关金融机构上云的主要负责人和架构师。目前致力于打造中国金融行业基础设施,推动互联网金融生态的发展。
金融公司、保险公司与互联网结合,是极大的发展机会,面临的问题也很多,首先要安全合规,其次是交易处理能力要跟上(每秒万级并发),然后是数据分析处理能力,最后还有高可靠、高可用、敏捷开发和运维的能力。刘刚介绍了传统系统改造上阿里云的架构调整过程,涉及到系统和数据的拆分,数据分库分表,应用系统的无状态化,核心业务和复杂业务的分级处理等。
本专场的现场视频会于近期发布在InfoQ中文站视频演讲专区,感兴趣的朋友们可以多关注!