阿里云技术动态:Xen 漏洞热补丁修复、异地双活、ODPS 新功能与金融互联网

  • 杨赛

2015 年 4 月 26 日

话题:QCon架构DevOps大数据语言 & 开发阿里云AI

本报道对2015 年 QCon 北京大会云计算高可用架构设计与实践专场的内容进行概述。本专场的四位分享者均来自阿里云,分别是阿里云虚拟化技术总监张献涛(旭卿),阿里巴巴数据库专家傅翠云,阿里巴巴 ODPS 和 iDST 产品经理韦啸,以及阿里云金融行业资深架构师刘刚。本专场的分享可视为了解阿里云技术现状的渠道。

解析阿里云 Xen Hypervisor Hotfix 技术

张献涛(旭卿)的分享内容是阿里云在 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

傅翠云(延瑛)分享的话题是阿里巴巴的异地双活数据中心 DRC。傅翠云在 2008 年加入 Oracle,曾任 Berkeley DB 的高级软件工程师,从事 Berkeley DB 数据库和高可用内核开发。2013 年加入阿里巴巴数据库技术团队,任数据库专家,目前负责数据流产品 DRC,参与了 2014 年阿里巴巴双十一交易异地双活数据同步和订阅、RDS 迁移上云服务、七网隔离跨域同步、性能分析和优化、数据校验、链路优化等。

所谓异地双活主要关注两件事,一个数据同步,一个数据分发。阿里异地双活数据架构基础设施 DRC 目前已经正式上线在 RDS 产品,现在 RDS 官网已经有了数据迁移的功能,另外也在公测更多服务。

到底怎样的应用会需要异地的双活?比较常见的场景有三个。

  1. 两个地域或多个地域都有大量用户的场景,比如在中国的用户希望他们用杭州的 RDS 服务,在美国的用户用美国 RDS 服务,这就需要数据在异地同步。很多游戏、金融、传媒、电商业务都有这种需求。满足这个需求的难点主要在于跨地域的网络,比如网络延时长,丢包多,而且数据在公网传输会有数据泄漏风险。
  2. 数据来源较多,需要接入各种异构数据的场景。比如一个应用需要从 ODPS、RDS、OTS、OceanBase、PostgreSQL 这几个服务接入数据,它们的数据结构和接口都不同 ,这种接入的成本会比较高。因此另一个可用的方法是数据写入的时候就一份多写为不同数据结构。
  3. 下游订阅很多的情况,比如一份数据,备份系统、通知系统、大数据分析系统、索引系统等等都要来取,如果用上面一份数据多写的方案是可以应对的,但这里还有其他难点,就是数据一致性、可扩展性、跨网同步稳定性、以及同步的实时性。

所谓 DRC,就是 Data Replication Center 的缩写,数据复制中心。这种复制是同步的,支持异构的,高可用的(有严格容灾系统,实时性好),支持订阅分发的。

以前在一个城市做双机房主备,两个机房是数据对等的,写入是随机分布,然后通过主备 HA 进行数据同步。这样机房对等的思路会导致业务增长、数据增长只能通过两个机房不停堆机器来解决。另一方面,如果整个城市断电,那么双活就成了双死。下一个思路是做跨城市,早期常用的做法是一个城市写,另一个城市冷备,就是晚上做同步,但这就意味着白天如果发生了什么事儿,这一天的数据就比较危险。另一个思路是两个城市多写,数据落两边,这样的问题是应用调用次数频繁的话,如果调用异地数据多来那么一两次,整个应用的延时就很长。这个思路再进一步发展,就是做单元内封闭以减少异地调用,这就涉及到业务上的改造。

顺着这个思路,阿里的异地双活重点做了几件事。一个是热插拔,可以做到在业务高峰时增加节点,高峰过了把增加的节点关闭。做到这个的一个关键是流量实时切换,DRC 可以在 20 秒以内把一个单元(region)的流量迁移到另一个单元。另一个是数据实时恢复,就是通过一定的冗余设计,一旦一个单元挂掉了,可以在另一个单元做全量恢复。

2014 年双十一,这套异地双活系统处理的规模是,抓取了约 100TB 的实时数据量,给 17000 多个实时下游提供了最高每秒 30GB 的数据量。2014 年期间 DRC 已经覆盖了超过 50% 的新增 RDS 实例。

云端 PB 数据引擎 ODPS

韦啸分享的主题是他们在 ODPS 上做的一些平台服务性质的事情。韦啸(龙场),阿里巴巴 ODPS 和 iDST 产品经理,中国科学技术大学量子通信硕士,普渡大学计算物理硕士,密西根大学信息学硕士。阿里巴巴 ODPS 和 iDST 产品经理。曾任职微软 Windows、Surface、Bing 产品经理,获微软 GoldStar 奖和 Hackday Winnner 等。

韦啸是几个月前加入的 ODPS,最近迁移到新团队 iDST,即数据科学研究院,该团队跟 ODPS 团队协作一个叫做阿里 PAI 的产品,以期用更加友好的方式帮助阿里云客户运用自己的数据。

ODPS 目前处理的数据量已经到 EB 级别,数据增长越快意味着成本越高。目前 ODPS 已经可以做到单集群 15000 台服务器的规模,在这个规模下保持 20% 以下的性能损耗。而单个 ODPS 的部署则可以多集群部署 100 万台以上的规模,当然这会有更大的性能损耗,对网络和灾备环境有更多依赖。支持异地。

使用上有几个特点:

  • 多租户复用同一个物理集群,可以设定不同的分配策略,比如按照比例分配,或者按照申请次序分配,或者按照优先级排队
  • 所有计算任务都在沙箱,数据不外流
  • 支持存储计算压缩,支持各种通用压缩格式,RAID 导出可以直接做到 1:1.5 的比例
  • 支持行存储和列存储,可以高效执行列优先的 SQL

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 架构转型解密

最后一场,刘刚分享的话题是余额宝、三马保险等 IT 转型案例。刘刚(法华),阿里云金融行业资深架构师,阿里金融云创始团队成员,是“三马保险”、“余额宝”等相关金融机构上云的主要负责人和架构师。目前致力于打造中国金融行业基础设施,推动互联网金融生态的发展。

金融公司、保险公司与互联网结合,是极大的发展机会,面临的问题也很多,首先要安全合规,其次是交易处理能力要跟上(每秒万级并发),然后是数据分析处理能力,最后还有高可靠、高可用、敏捷开发和运维的能力。刘刚介绍了传统系统改造上阿里云的架构调整过程,涉及到系统和数据的拆分,数据分库分表,应用系统的无状态化,核心业务和复杂业务的分级处理等。

本专场的现场视频会于近期发布在 InfoQ 中文站视频演讲专区,感兴趣的朋友们可以多关注!

QCon架构DevOps大数据语言 & 开发阿里云AI