云里雾里云计算 【8】云中说禅
云计算是一个大买卖，各大公司不会眼睁睁看着Google吃独食。IBM，Yahoo，Amazon，Microsoft等等相继跟进，都在宣传自己的云计算方案。
Google致力于云计算研究与实践，已经有十年了，技术积累厚实，说话底气足。其它公司嚷嚷归嚷嚷，总得拿出点真材实料，否则靠什么争取客户？从头开始 研究开发当然是来不及了，于是IBM也好，Yahoo也好，Amazon也好，纷纷借Open Source的Hadoop，作为自己切入云计算市场的基石。
看一看IBM的Blue Cloud方案，以及Amazon的EC2方案，除了Hadoop以外，它们还用到了另一个开源软件，Xen。Xen是Zen的异体词，Zen的意思是禅。
计算机技术和禅有什么关系？
看看Lucent公司的Logo。第一次见到这个logo的时候，不解。请教老美，老美很吃惊，说，“这是禅啊，你们东方的东西。”
这个用毛笔画出来的圆圈，英文名字叫Enso。这个符号来自日本，通常被当作禅的标记。凭心而论，日本在世界范围内弘扬东方文化，是做了很大贡献的。譬如西方人对禅的了解，主要来自于日本的推介。
Lucent Logo
Courtesy http://www.techshout.com/images/lucent-logo.jpg
1974年，美国出版了一本名字很古怪的书，“禅与摩托车维护的艺术：对价值的探求（Zen and the Art of Motorcycle Maintenance：An Inquiry into Value）”。这本书的主线是一伙人骑摩托，17天环游美国的游记，其中穿插了大量的哲学讨论。此书出版后，受到极大欢迎。
2003年，剑桥大学计算技术实验室的几个人在合写一篇论文，文章写得差不多了，但是还缺一个标题。其中一位开玩笑地建议到，“要么就叫Zen and the Art of CPU Cycle Maintenance吧”。众人大悦。
最后论文定名为“Xen and the Art of Virtualization”。同时，把整个项目定名为Xen。
Xen是做什么的？
用一句话来概括，Xen的目标，是如何在一台计算机的硬件上，同时运行多个OS。什么情况下需要在同一台计算机上同时运行多个OS？
举个例子，现在电脑病毒日益猖獗。纵然有卡巴斯基等等解药，但是道高一尺魔高一丈，病毒屡禁不止，而且毒性越来越烈，常常危及整个OS。
有人出了一个主意，在同一台电脑的硬件上，同时运行多个OS，把一些基本的应用放在一个OS上，其它的应用留在其它OS上。用户切换OS的方式，犹如切换窗口一样。如果一些应用染上了病毒，最多把该应用所在的OS重装，而不至于影响其它OS，尤其是不必担心硬盘上重要的文件遭到破坏。
为什么Xen与云计算有关？
在云计算平台上运行的程序，来自不同的客户。不能保证这些客户程序没有bugs，也不能杜绝恶意的破坏性程序。如何保证一个客户的程序，不至于破坏其它客 户的程序运行，不至于损坏其它客户的文件？
最简单的办法是给不同的客户分配不同的机器，井水不犯河水。但是这样的做法不能高效率地使用资源。美国客户的高峰时段，恰巧是中国客户的夜间休息时段。如 果分别给美国中国客户分配不同机器，美国高峰时段，美国客户的机器忙不过来，而中国客户的机器却在闲置。
所以最理想的做法，是让不同客户共享计算机硬件，但是各自拥有各自的OS。这样，既高效地使用硬件资源，又保证井水不犯河水。
举个例子，假设后台有两个功能，F1，F2。如果现在各自有个machine farms，MF1和MF2。MF1的每台机器只运行F1，而MF2的机器只运行F2。即便在系统里装了LoadBalancer，F1的请求只能发到 MF1的某一台机器上去。但是如果MF1里面所有机器都忙不开了呢？在这种情况下，LoadBalancer也没办法。
怎么办？把MF1和MF2合并，每台机器上即运行F1，也运行F2。
但是如果F1有bugs，导致死机，会不会影响到F2？当然会。怎么办？
用virtualization技术，在同一台机器的硬件上，同时运行两套OSes，OS1里面只跑F1，OS2里面只跑F2。F1的bug，导致OS1 崩溃，但是不会影响OS2里的F2。
Xen提供了实现这一目标的技术解决方案。当然，在一台计算机上支持多个OS，是有代价的。Xen消耗了一部份CPU时间，但是这个额外代价只有3%到7 %。
如果F1是Oracle，F2是DB2等等之类heavy duty applications，当然给它们分配专用机器最合适。但是如果F1和F2不是那么heavy duty，而且负载分布交错，也就是你忙我不忙的情况经常发生，那么把F1和F2放置在同一台机器上，用virtualization技术相互隔离，以保 证互不干扰，就有价值了。
Virtualization的价值在于减少服务器的数量。在前面的例子中，如果F1和F2各自有自己的machine farms，两个farms里面的机器数量分别是MF1和MF2，那么合并起来以后，统一的machine farm里的机器数量比MF1+MF2少。
所以，借着云计算的东风，Xen大热。
The structure of a machine running the Xen, hosting a number of different guest OSes.
Courtesy http://www.freesoftwaremagazine.com/files/www.freesoftwaremagazine.com/nodes/1159/slide2.jpg
上图描述的是Xen的体系结构。最底层的是计算机硬件，包括CPU，RAM，硬盘接口，网卡，外设数据总线等等。
硬件层之上，是Xen hypervisor层，包括总控界面（Xen Control Interface），虚拟CPU，虚拟RAM，虚拟硬盘，虚拟网卡等等。
在Xen层之上，是各个OS实例（OS instances）。其中最左边的OS实例很特别。在启动Xen的时候，最左边的OS实例，Domain0 on XenoLinux，自动被启动。Domain0里运行着Xen Control Software，这个软件控制着各个OS实例的启动，终止，以及监控其运行情况。
Domain0对于其它OS实例的控制，是通过Xen层中Xen Control Interface来实现的。而这个Xen Control Interface只对Domain0开放。其它OS实例只有被管理的义务，而没有管理其它实例的权力。
每个OS实例都被分配一套虚拟的CPU，RAM，硬盘和网卡。每个OS实例使用这些虚拟的设备，与通常的OS并无不同。
多个OS实例共享CPU的实现，是通过两套机制来完成。当多个OS实例请求使用CPU，这些请求被放置在hypercall队列里。Xen hypervisor根据预先设定的优先级政策，在hypercall队列里挑选出下一个被执行的请求。请求被处理完了以后，Xen通过异步的事件响应机 制（async event-callback handler），把结果反馈给相应的OS实例。所谓虚拟CPU，说白了就是这两套机制的interface APIs。
在启动一个新的OS实例的时候，Domain0会给它分配一部份RAM。如果实际运行中，需要更多的RAM，Domain0会增加这个OS实例的配额，直 至最高上限。各个OS实例都有自己的RAM区域，彼此不相互干扰。从每个OS实例的眼中看，似乎自己的RAM区域在物理上位于相邻区域。但是事实上不是这 样。这种善意的欺骗归功于虚拟RAM。虚拟RAM不仅记录着物理RAM的分配和使用，而且负责地址的翻译等等工作。
至于Disk IO和Network IO的读写请求，被放置在一个环状队列中，通过Consumer-Producer锁机制进行异步操作。
每个OS实例配备着一个虚拟硬盘，这个虚拟硬盘记录着每个OS实例所占用的物理硬盘的空间。每个OS实例只能看到分配给自己的硬盘空间，而不能看到其它 OS实例的硬盘里的文件。而Domain0是例外，它能够看到整个硬盘系统中所有文件。
Xen的详细描述和分析，可以读前面提到的那篇论文，“Xen and the Art of Virtualization”，http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf。
Xen开源软件的下载，可以去Xen网站寻找。http://www.xen.org/
VMWare infrastructure
Courtesy http://www.topgreat.com.tw/WebMaster/uploads/images/1_images/l_070508152747.jpg
Xen并不是横空出世的新创意。计算机界往往出现工业界领先于学术界的局面，Virtualization技术就是这样一个例子。早在1998年，硅谷 Palo Alto出现了一家公司，最早实现了多个OS共享一台计算机的设想。这家公司的名字叫VMWare，现在卖给了EMC。 http://www.vmware.com
Xen与VMWare在技术上有很大相似之处。从Xen的论文看，Xen的技术似乎比VMWare有更多优势。但是从产品系列的完整，以及多年来的实际运 行经验来看，VMWare似乎能够提供用户更可靠的稳定性和售后服务。
