如之前InfoQ中文站所报道，，其中采用了新的虚拟化引擎——一款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，前提是：
- 现在已经推出C5的区域有US East (Northern Virginia)、US West (Oregon)、EU (Ireland) Regions，目前要用C5的话只能在这三个区，其他区还得等等。
- AMI镜像的操作系统必须包含ENA和NVMe的驱动，因为C5的网络和存储功能是在硬件层面实施的。AWS平台上提供的最新版AMI镜像，包括Amazon Linux、Microsoft Windows (Windows Server 2012 R2 以及 Windows Server 2016)、Ubuntu、RHEL、CentOS、SLES、Debian、FreeBSD，现在都支持。同理，如果你制作自己的AMI，也是一样的要求。
上已经有用户在分享自己的切换过程，感兴趣的读者可以前往查看或提问。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）任务或者类似的计算任务，可以看一下这个。C5的处理器用的是，这款专为EC2做过优化的处理器配合上面那个数学库可能会有很好的性能。
此外，C5还增加了每个vCPU的内存。对于兼容AVX-512指令集的代码而言，矢量操作和浮点操作的性能甚至可以翻倍。
切换到C5之后，由于运行在新虚拟化引擎上的实例是通过NVMe接口从EBS卷上启动的，而运行在Xen上的实例是从一个模拟IDE硬盘上启动、再切换到Xen的半虚拟块存储驱动上的，所以虽然操作系统（OS）能够识别自己正运行在哪个虚拟化引擎上，但如果软件本身假设底层的虚拟化引擎是Xen并依赖于该假设，则可能会引发一些问题。
但总体来说，AWS表示只要OS层面能够支持ENA网络和NVMe存储，则大部分软件都能正常工作。AWS还表示，其他的EC2功能并不会受到影响。
如果你是AWS EC2 API的重度用户，担心这次虚拟化引擎的变更会对API造成什么变化，则不用担心了：其对外公开的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上的业务们能够继续平稳运行。不过这里面还有一个变数就是，那就是另一个话题了。
从上游社区的角度，影响可能不大，因为Amazon一直不是个活跃的开源社区参与者。即使作为最大的Xen用户那么多年，Amazon对Xen上游社区的代码贡献数量却是屈指可数。所以对于KVM项目，可能我们未来也不大会看到很多来自Amazon的代码贡献。
从技术发展的角度，这是个大趋势下技术更新换代的必然——也许从KVM被合并到Linux内核代码的那时起就已经种下了种子吧。
关于AWS此次拥抱KVM的C5发布，目前公开的信息就总结到此。11月27日到12月1日期间的AWS re:Invent 2017，InfoQ中文站记者会在前线报道，敬请期待！
原文来自：
本文地址：//q13zd.cn/aws-kvm-what-to-know.html编辑：逄增宝，审核员：刘遄
本文原创地址：//q13zd.cn/aws-kvm-what-to-know.html编辑：逄增宝，审核员：暂无
