主题：【原创】云里雾里的云计算 [1] -- 邓侃
家园 【原创】云里雾里的云计算 [7] 【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。这样，既高效地使用硬件资源，又保证井水不犯河水。
Xen提供了实现这一目标的技术解决方案，所以借着云计算的东风，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似乎能够提供用户更可靠的稳定性和售后服务。
关键词(Tags): #硅谷评论，家园 VMWare的内存不安全 找到一个证据，说明VMware目前的版本内存不够安全。host在内存里写上些什么，guest是可以看到的。参见下图：
外链图片需谨慎，可能会被源头改不知道这是VMware的bug还是技术限制。如果是技术限制，那就不符合大部分安全规范了，而follow这些安全规范的公司也就没法用VMware了。
家园 这可是个大问题 这可是个大问题，不过我个人觉得，这个问题VMWare不太难解决。
家园 VMWare问题很多啊 不用WMWare不知道，一用吓一跳。
那个bug是一个超级的多，要是出现一个问题，解决起来是难上加难，也不知道是应用程序问题，硬件问题还是VMWare问题。
反正公司次要业务用用WMWare还行，要是主要业务要用，那就是找死。
家园 虚拟化是个好东西，可以挖个大坑。 家园 【转】一篇好文：虚拟化的四大价值 虚拟化的四大价值
作为一项诞生于40多年前的技术，实践证明虚拟化能够给企业带来诸多好处。在服务器领域，虚拟化可以带来更高的部件及系统级利用率，带来具有透明负载均衡、动态迁移、故障自动隔离、系统 自动重构的高可靠服务器应用环境，以及更为简洁、统一的 服务器资源分配管理模式。
整合遏制服务器蔓延
不论是企业的规模大小，一般情况下，IT机构通常会将其70~80%的预算用做现有系统和应用管理开支。过去，IT机构总是倾向于使用一台服务器运行一个应用。尤其是在x86服务 器的使用方面，这往往被看作是一种经济、高效的战略，因为一台服务器运行一个应用的方法，不仅可以简化服务器的部 署工作，而且还可以减少潜在的软件冲突。在国内，这种状况 尤其普遍。
但是，随着企业IT应用环境日益复杂，运行在服务器平台 上的应用数量不断增加，这种单机运行单一平台的做法，带来了严重的后果--全球范围内的服务器数量在过去十年间增 加了150倍，过多的服务器带来了处理器应用率低下、维护困 难（服务器的升级、补丁，防 病毒等）、维护成本高等多方面问 题，而且，管理这些系统的相关成本也急剧增长。
与此同时发生的另一个现象是，服务器的平均性能在明 显提高，例如，在运行不同类型应用时，双核平台较单核平台 性能有从30%~10 0%不等的提升，而四核平台又比双核平台 有平均60%的性能提升。
这两个现象碰撞的结果，在IT技术供应商端促进了可以帮助用户整合物理服务器和应用的技术创新，而在用户端， 则促进了通过将应用和 操作系统整合到单一平台上的需求梦 想。在这种技术创新和需求梦想的碰撞、交织和沟通中，虚拟 化技术被证明是一个可以帮助用户整合服务器、整合多个应 用、整合多个操作系统的理想工具。
一方面，多核平台带来了性能提升、可靠性提高以及全新物理机虚拟机的应用模式，另一方面英特尔硬件级别的虚拟化技术能够支持效率更高、性能更优化的本机虚拟化能力。多核，多虚拟 环境通过与海量存储系统的整合，就可以实现数据中心的灵活整合。
破解利用率谜局
虚拟化技术还可以明显地改善另一个困扰许多用户的问题。即使在今天，多数用户的服务器系统利用率只有10%~30%，大量服务器处于严重的利用率低下状态。导致 服务器利用率低下的原因有许多，例如每种工作负载都需要使用单独的服务器、企业中的各个部门拥有“自己的”服务
服务器（其中一部分也许处于闲置状态，但是其他部门的工作负载无法共享这些资源）、容量规划不科学（因为担心复杂、麻 烦、花费时间的系统迁移，大部分时候预计的容量要比实际 高，甚至高很多）等等。
传统的整合方式，就是在单个操作系统副本上运行多 个应用，导致了许多技术障碍，如：文件系统命名空间冲突、网络端口冲突、进程间通信冲突、不一致的内核调整或补丁 级别等等。而虚拟化可以使系统轻松拥有在单一平台上运行多个应用的能力，从而提高系统资源的利用率，有效打破资源利用率瓶颈。很多采用了虚拟化技术的用户都已经尝到了提升系统资源利用率的好处。
让数据中心更可靠
虚拟化可通过以下几个主要方式，提高数据中心的可靠性，保障业务连续性：
故障隔离—大多数应用故障均由软件故障引发。虚拟 化可提供虚拟分区之间的逻辑隔离，这样一个分区中的软件故障便不可能影响到另一个分区中的应用。逻辑隔离还能帮助遏制数字攻击，从而可有效增强整合环境中的安全性。故障切换灵活性—虚拟机通过配置可为一个或多个应 用提供自动故障切换。鉴于基于英特尔至强处理器的服务
服务器平台能够提供高度可用性，通过在相同平台上提供故障切换分区作为主要应用，通常可满足服务等级要求。如果要求更高 的可用性，可将故障切换分区托管到单独的服务器平台上。
不同的安全设置— 每台虚拟机可以应用不同的安全设置，这样IT部门就能够保持对最终用户和管理员特权的高度控制。例如，基于虚拟机的灾备系统，就是一个 低成本的 高数据中心高可靠性保障方案。传统的容灾系统成本昂贵， 硬件配置的一致性要求高，异构平台实现容灾的可能性很 小，用户几乎不敢尝试，同时，配置及迁移的复杂性高，且维 护复杂。而基于英特尔虚拟化 技术支持的虚拟机的灾备技术，可以实现 虚拟机到虚拟机、虚拟机到物理机、 一对一、一对多等多种形式的灵活的应用模式，能够帮助用户降低成本，而VMotion等迁移与配置技术可以 帮助用户方便地进行系统管理。
有效减少TCO
服务器虚拟化软件领域执牛耳的厂商VMware证实，通过虚拟化 和整合，用户可以在服务器总拥有成本（TCO）方面有明显的节省：硬件成本减低：28%~53% 运营成本降低：72%~79% 总体成本降低：29%~64% VMWare还证实，虚拟化可以在软件授权上再节省20%的成本。
虽然较好，但观察的角度不同，仍然会有不同意见。还请各位各抒己见～～
家园 【讨论】虚拟化的价值很大，但我也有疑问 1. 单点故障
现在似乎所有的virtualization的方案都是在硬件层上建一个SuperVisor，然后上面再跑Domain0（虚拟机的管理系统）或者guest OS。那么这个Supervisor不就是单点故障源吗？SV或者Domain0一旦crash了，上面跑的任何东西都跟着完蛋。如何能保证它不出问题？
2. 代价
下面的讨论有说用虚拟机可以解决LoadBalance的问题。但问题是代价多大。
还是用邓大的例子：
后台有两个功能，F1，F2。假如现在各自有个machine farms。MF1的每台机器只运行F1，而MF2的机器只运行F2。Virtualization。在同一台机器的硬件上，跑两套OSes，OS1里面只跑F1，OS2里面只跑F2。F1的bug，导致OS1崩溃，但是不会影响F2/OS2。
比如，F1的后台是Oracle，数T的数据，F2的后台是DB2，也是数T的数据。
那么虚拟化之后，要多powerful的机器才能够同时跑F1和F2呢？这个机器的价格，再加上虚拟化软件的费用，相比F1，F2独立放在两台机器上的费用恐怕只高不低。只为了一个loadbalance，合算吗？
家园 关于virtualization 1. SuperVisor和Domain0会不会成为single point of failure？
理论上任何软件都会有bug，SuperVisor和Domain0也不例外。
但是Xen也好，VMWare也好，他们谋生靠的就是SuperVisor和Domain0的可靠性。实践证明，Xen和VMWare的可靠性相当不错。
2. Xen的overhead值不值？
Xen的overhead是3%-7%。
如果F1是Oracle，F2是DB2等等之类heavy duty applications，当然给它们分配dedicated machines最合适。
但是如果F1和F2不是那么heavy duty，而且负载分布交错，也就是你忙我不忙的情况经常发生，那么把F1和F2放置在同一台机器上，用Virtualization技术相互隔离，以保证互不干扰，就有价值了。
3. Loadbalancer
即便把F1和F2放置在同一台机器上，用Virtualization技术相互隔离，LoadBalancer也是有用的。
如果有M台机器，每台机器上既可以跑F1，也可以跑F2。如果发现t1时刻有几台机器很忙，而其它机器不忙，那么t2时刻来的用户请求，该让哪一台机器去处理呢？当然应当把t2时刻来的任务分发给那些不忙的机器。
分发任务的工作，可以让LoadBalancer来做。
换而言之，Virtualization的意义，不在于省掉购买Load Balancer的钱，而是减少machine farm的规模，也就是减少M。
家园 继续抛砖引玉 1.
实践证明，Xen和VMWare的可靠性相当不错。不清楚VMware是什么构架就不评论了。Xen是基于Linux的。如果Xen能做到本身不崩溃，上面跑的某个程序（guest OS)崩溃也不会影响其他程序，那么Linux也应该能做到。那还要Xen干什么呢？
2.
heavy duty如果MF不heavy duty，那就几乎用不到load balance和云。只要在MF1满（超）负载的情况下，才需要MF2帮忙。邓大也说过，
heavy duty applications，当然给它们分配dedicated machines最合适。那与其花重金买机器同时装F1和F2，岂不是不如给F1，F2单独买机器了？当然，单独给F1,F2买机器会在闲时浪费资源。不过买superpowerful机器做virtualization也是一样。你在sizing的时候，是按照F1满载，F2空载（vice versa，或者两者都50%）算呢，还是按照F1，F2同时满载算呢？如果前者，显然偶尔F1,F2都忙的时候就overload了，不符合做virtualization的初衷；而后者的代价可就不是一般的大了
3.
Virtualization的意义，不在于省掉购买Load Balancer的钱，而是减少machine farm的规模，也就是减少MM的数目减少了，但单个的每个M更费钱了。再加上virtualization软件成本和维护成本，migration的风险，从TCO角度来说，不见得合算。当然，或许环保主义者会开心一些
关键词(Tags): #virtualization，#TCO，- 复 继续抛砖引玉
家园 说说俺们现实中的应用 我在国内,跟你们在海外摸爬滚打的兄弟们没什么共同点,与朋友开得一个小公司,人员不过10多个人,但是服务器上面跑的东西却不是很少,现在罗列一下:
1.lmMail Server (作为企业内部管理用)
2.Project Server (安装 Project Server 2007 吃硬件的大家伙)
3.File Server(文档共享）
4.Test Server（测试专用）
5.App Server（应用程序服务器,运行CRM和OA）
6.Domain (域控制器）
7.DBServer (数据库服务器 SQL 2008）
8.SVN Server (版本控制+SQL Server2000）
9.Backup Server(Acronis 企业版,严重推荐的好东东,多次救吾于水火）
现在采用VMware 2.0 进行管理,硬件配置:Intel 6500双核,4G内存.1.5T硬盘,ASUS家用主板 的一个普通PC(现在折算下来价格不会超过5000 人民币).现在基本跑的不错,虽然上面罗列出得各种东东不少,但是应该还有合并的余地.
假设1: 每个应用都购买一个PC的话,我需要付出9台PC的成本,对于大公司当然是毛毛雨,对于我们小公司,那就是割肉呀!而且电费还要付出9倍.
假设2:如果把这些东西一股脑儿塞到一个OS里的话,我只能每天早晚各祈求一次上帝,我明天的Server千万不要崩溃,否则血本无归(虽然数据可能都在,但是这么多东西,光安装+配置一遍都需要3个人日,俺们付不起这么大的时间成本).
为了避免假设2的出现,特意搭建了一个Backup Server,而且经过一年的检验,各种情况都能够在尽可能的减少数据丢失的前提下,给我节省了大量的成本.
这就是我的实际情况,如果随着公司的发展,现有的硬件满足不了需求,没关系,我再花费1W元采购一个PC Server ,把部分虚拟机迁移(实际上就是复制)到新的服务器上即可,我的迁移成本和时间消耗也会很少.
虽然没有解决你的疑问,但是虚拟技术的确给我带来了很大的好处.
(BTW:公司规模较小,出了Open Source 的,剩下的都是从互联网上打劫回来的,各大厂商千万不要找我来要 License ,公司发展了,自然会转向正版的.就像以前的黑社会发展壮大后都会成为某某集团一样,我们也需要漂白 :P )
家园 其实我们公司也是虚拟化的受益者 虚拟化我们已经关注了很久了，而且我们采购的是8核的intel xeon机器，呵呵。linux的虚拟化我们采用virtualbox和xen，windows虚拟化采用viztuzzo container，vmware很少用了。不过据我在ibm的同学说他们推荐客户使用vmware的产品。
- 复 继续抛砖引玉
家园 问题很深刻，态度很礼貌，meokey是好榜样 1.
如果Xen能做到本身不崩溃，上面跑的某个程序（guest OS)崩溃也不会影响其他程序，那么Linux也应该能做到。那还要Xen干什么呢？问题出在“上面跑的某个程序（guest OS)崩溃也不会影响其他程序”这一句话。某个程序的崩溃搞不好会使整个系统崩溃，从而殃及其它程序。
想举个例子，说明什么样的程序会导致整个OS崩溃。但是刚起床，没完全清醒。谁能帮个忙？
2.
如果MF不heavy duty，那就几乎用不到load balance和云。只要在MF1满（超）负载的情况下，才需要MF2帮忙。。。那与其花重金买机器同时装F1和F2，岂不是不如给F1，F2单独买机器了？这段话隐含了一个判断，“只有在F1是heavy duty的情况下，MF1才会满负载”。这个断语是有问题的。满负载和application本身是否heavy duty没有必然联系。
例如F1程序本身并不那么heavy duty，但是如果并发用户量很大，就需要提高server的吞吐量。如何提高吞吐量？通常的办法是征用最大数量的threads，每个thread跑一个F1 instance。这样造成F1所在机器的满负载。
推而广之，如果并发用户量很大，就会造成MF1里面所有机器满负载。
3.
不过买superpowerful机器做virtualization也是一样。。。M的数目减少了，但单个的每个M更费钱了。Virtualization不需要superpowerful machine，现在4x4GHz CPU，10G RAM的机器不过USD1500左右。硬件很便宜。
4.
你在sizing的时候，是按照F1满载，F2空载（vice versa，或者两者都50%）算呢，还是按照F1，F2同时满载算呢？如果前者，显然偶尔F1,F2都忙的时候就overload了，不符合做 virtualization的初衷；而后者的代价可就不是一般的大了。是用IDC架构，还是用virtualization，的确是需要预先核算一下。不是说virtualization在任何情况下都比IDC方案好。
家园 的确是这样 就拿我们公司的后台架构来说，
1. 后台的入口是web server。
2. 后台支持多种功能，目前的做法是各个功能拥有几台服务器。
3. Web server解析用户请求，根据不同请求，把任务发放到各个功能服务器上。Web server收到反馈后，整合这些反馈，然后回复给用户。
这样的做法，各个功能相当于拥有各自的领地，相互隔绝。各个领地的工作负担不同，而且高峰时间也不同。有时候有的领地忙不开，而其它领地很空闲。造成的结果是计算资源负荷不均。
解决思路是把各个分封的领地统一，提高资源使用率。但是如何实现这个思路，就需要用到虚拟化的技术。