如之前InfoQ中文站所报道,AWS在11月6日推出新的实例类型C5,其中采用了新的虚拟化引擎——一款AWS自家定制的KVM。这可能意味着AWS从2006年启动时就开始使用并持续优化至今的Xen技术栈,将逐渐淡出这一体量庞大的云计算平台。
Xen最早是剑桥大学的一个研究项目。该项目在2003年以开源协议发布后,先后经历了XenSource公司、Citrix公司、Linux基金会等组织的领导,其技术阵营包含了Citrix、IBM、Intel、HP、Novel、红帽、Sun、Oracle、Amazon、AMD、Bromium、CA Technologies、Calxeda、Cisco、Google、三星、以及Verizon等业界巨头。
KVM(Kernel-based Virtual Machine,直译为“基于内核的虚拟机”),最早是以色列初创企业Qumranet发布的开源项目。该项目在2007年被合并入Linux内核代码——这对KVM而言是非常重要的一个节点,该公司则在2008年被红帽收购。KVM技术差不多到2010年之后进入成熟阶段,该技术阵营目前包括红帽、SUSE、Linaro(ARM)、IBM、Intel、Google、Oracle等业界巨头,国内的华为、阿里巴巴、腾讯等也均有参与。
在AWS启动的2006年,Xen还是当时最成熟的虚拟化引擎技术(对于Linux操作系统而言),而KVM项目还没有出现在大家的视野中。因此,AWS在早期技术选型当中采用了Xen,成为其弹性计算的底层基础。(此外,2009年启动的阿里云也因为当时KVM还不成熟的原因采用了Xen,不过两家一直未停止过对KVM的关注与投入,阿里云更是在数年前就已经推出了基于KVM的主机。另外,2011年启动的Google Cloud从一开始就采用了KVM引擎。)
首先,AWS的用户现在已经可以将自己跑在C4实例上的主机切换到C5,前提是:
Reddit网站上已经有用户在分享自己的切换过程,感兴趣的读者可以前往查看或提问。Jeff Barr也会在那里回复一些问题。
C5实例可以选择的实例尺寸见下表:
Instance Name | vCPUs | RAM | EBS Bandwidth | Network Bandwidth |
c5.large | 2 | 4 GiB | Up to 2.25 Gbps | Up to 10 Gbps |
c5.xlarge | 4 | 8 GiB | Up to 2.25 Gbps | Up to 10 Gbps |
c5.2xlarge | 8 | 16 GiB | Up to 2.25 Gbps | Up to 10 Gbps |
c5.4xlarge | 16 | 32 GiB | 2.25 Gbps | Up to 10 Gbps |
c5.9xlarge | 36 | 72 GiB | 4.5 Gbps | 10 Gbps |
c5.18xlarge | 72 | 144 GiB | 9 Gbps | 25 Gbps |
其次,如果你已经用上了C5,想用它跑一些机器学习的推断(inferencing)任务或者类似的计算任务,可以看一下这个Intel Math Kernel Library。C5的处理器用的是3.0 GHz Intel Xeon Platinum 8000系列,这款专为EC2做过优化的处理器配合上面那个数学库可能会有很好的性能。
此外,C5还增加了每个vCPU的内存。对于兼容AVX-512指令集的代码而言,矢量操作和浮点操作的性能甚至可以翻倍。
切换到C5之后,由于运行在新虚拟化引擎上的实例是通过NVMe接口从EBS卷上启动的,而运行在Xen上的实例是从一个模拟IDE硬盘上启动、再切换到Xen的半虚拟块存储驱动上的,所以虽然操作系统(OS)能够识别自己正运行在哪个虚拟化引擎上,但如果软件本身假设底层的虚拟化引擎是Xen并依赖于该假设,则可能会引发一些问题。
但总体来说,AWS表示只要OS层面能够支持ENA网络和NVMe存储,则大部分软件都能正常工作。AWS还表示,其他的EC2功能并不会受到影响。
如果你是AWS EC2 API的重度用户,担心这次虚拟化引擎的变更会对API造成什么变化,则不用担心了:AWS在其FAQs页面中表示其对外公开的API完全不会因为引入新的虚拟化引擎而有任何改变。
作为计算资源服务的提供方,提升性能、降低成本是永恒的话题。
Xen最初设计时,x86架构尚未引入虚拟化扩展功能,所以Xen为了实现Linux系统的虚拟化,就把Linux内核给改了——这就相当于在之后的十几年里,Xen一直维护着一套自己的Linux内核版本,所以上游Linux内核社区的很多新的好东西,它要费一番功夫才能移植进来,这就造成了很大的维护成本。
而另一方面,因为KVM项目是合并在Linux内核代码中的,维护起来就非常容易。Linux内核上游社区的研发势能是非常大的,在这种情况下,KVM的发展速度迅猛,在稳定性、性能方面的提升很快赶超了Xen,受到很多技术人与企业的青睐。
EC2是AWS的基石,虚拟化引擎又是EC2的基石。由于AWS是一套构建多年的、庞大而复杂的系统,很多功能会对Xen有所依赖,要让这套系统同时稳定的支持Xen与KVM,是一项非常复杂的工作。所以C5的推出,意味着AWS这套系统已经脱离了对Xen的完全依赖。
对AWS而言,基于KVM的系统要比基于Xen的系统的维护成本更低,这是一方面。
另一方面,可能也与性能有关。按AWS首席布道师Jeff Barr在博客中所说,C5在性价比方面相比C4提升了25%,针对有些任务甚至可以达到50%——这是针对用户而言。要知道对于AWS今天这样的体量,哪怕是1%的节省都是巨大的;如果有25%这样比例的性价比提升,则绝对是势在必行,无论花费多大代价也要上。当然这其中的性能提升有多少是来自新的硬件,有多少是来自KVM,这就不一定了。
此外,AWS首先在“计算密集型实例”(compute-intensive)上正式采用KVM,而不是从通用型、内存密集型等其他类型上开始,可能是因为考虑到计算密集型业务的I/O操作较少,比较独立,耦合性比较小,因此更容易替换的原因。
从市场占有率的角度来看,就是Xen的最后一个大体量的用户对Xen说,以后我不再需要你了。
如果说以前还有业界传言说AWS在Xen上投入太过巨大、依赖太重,所以AWS将一直支持Xen的话,那么现在这个传言已经宣告终结。毕竟,如果连AWS都以实际行动表示切换到KVM的收益大于成本了,那么那些体量更小的Xen用户还能对Xen有什么更多的期待呢?
所以对于未来的市场而言,这次改变也许象征着Xen的使命已经结束了。对于过去的市场而言,Xen的使命就是让那些仍然跑在Xen上的业务们能够继续平稳运行。不过这里面还有一个变数就是Unikernel,那就是另一个话题了。
从上游社区的角度,影响可能不大,因为Amazon一直不是个活跃的开源社区参与者。即使作为最大的Xen用户那么多年,Amazon对Xen上游社区的代码贡献数量却是屈指可数。所以对于KVM项目,可能我们未来也不大会看到很多来自Amazon的代码贡献。
从技术发展的角度,这是个大趋势下技术更新换代的必然——也许从KVM被合并到Linux内核代码的那时起就已经种下了种子吧。
关于AWS此次拥抱KVM的C5发布,目前公开的信息就总结到此。11月27日到12月1日期间的AWS re:Invent 2017,InfoQ中文站记者会在前线报道,敬请期待!
本文地址:http://www.linuxprobe.com/aws-kvm-what-to-know.html