Chapter
1
云计算与 x86 虚拟化技术
从云计算近年来为什么如此热门开始，让您了解所谓的云计算最少必须具 备五项技术特征、四个布署模型、三种服务模式，这样的服务才能称得上是云计 算。 让您不再人云亦云。 同时相信许多读者已经被全虚拟化技术、 半虚拟化技术、 硬件辅助虚拟化技术等技术名词搞得混乱， 在本章当中也有详细的说明让您彻底 了解 x86 虚拟化技术。此外目前市场上充斥着多种虚拟化技术解决方案，在本 章中也提出了由知名市调机构 Gartner 的调查结果， 让您不用害怕所学习的虚拟 化技术跟不上市场趋势。本章最后列举了打造高可用性环境（如机房、制冷降温 能力、机柜、结构化布线等）的数据中心基础设施注意事项供您参考。11 云计算
「云计算（Cloud Computing）」这个名词近年来对于许多 IT 人员来说应该不陌生才对（或 者听到烦了吧!!） 。有人觉得云计算只不过是一些厂商联合起来利用旧瓶装新酒的概念再度炒作 一次，有人则觉得云计算改变了整个 IT 基础结构及应用方式，当然若您是一般的使用者则更会 觉得要不要云计算跟我有什么关系（只要厂商提供的服务运行正常就好!!）。 不过相信您应该是跟云计算有关系的 IT 人员（否则您应该也不会对这本书有兴趣吧？）， 因此笔者也不免俗地来概略谈谈什么是云计算，当然每个人对于云计算的认知各有不同，因此 请允许笔者说明个人所粗浅认知的云计算。 云计算，基本上来说就是采用互联网的计算方式。因为在网络架构图中通常对于「互联网 （Internet）」这个充满未知的环境我们会使用「云」来形容它，而正因为云深不可知，因此通 过这种计算方式并且将计算资源及相关信息，提供给需要的计算机、设备或载体时就称之为云 计算（Cloud Computing） （见图 11） 。通常云计算服务的供应厂商为了方便使用者能够随时存 取云资源，提供以浏览器（Browser）或其他网页服务的方式，使得使用者能够以最方便的方式 进行云资料的存取作业。 图 11 云计算概念图区云： l 公有云（Public Cloud）：通常搭建于「互联网」上的云，使用者可以通过互联网进行存 取及应用，例如 Amazon AWS、Microsoft Azure。 l 私有云（Private Cloud）：通常搭建于「企业内部」上的云，仅提供企业内部存取使用， 不开放外部存取。 l 混合云（Hybrid Cloud）：结合了公有云及私有云。 l 社区云（Community Cloud）：基于几个组织中所共同关心议题而搭建的云，可能交由第 三方托管或者搭建于公有云或私有云之间。 图 12 云计算—云的种类
111 云计算服务模式
目前市场上具有代表性的云计算厂商有 Amazon EC2/S3、Google App Engine、Windows Azure、Yahoo Hadoop 等，而云计算如果根据服务来分的话又可以分为三种服务模式，分别是 软件即服务（Software as a Service，SaaS）、平台即服务（Platform as a Service，PaaS）、架构即 服务（Infrastructure as a Service，IaaS），如图 13 所示。事实上若要细分的话还有许许多多的云 服务如雨后春笋般涌出，目前热门的有云存储服务（Storage as a Service，StaaS）、云监控服务 （Monitoring as a Service，MaaS）等服务，基本上可以统称为「一切即服务（Everything as a Service，XaaS）」。
1．软件即服务 SaaS
软件即服务 SaaS（Software as a Service），为通过互联网（Internet）的方式提供软件模式， 由使用者向供应厂商租用基于网页形式的软件，以便管理企业营运项目，并且不需要对运行软 件进行任何维护操作，全权由服务提供商自行管理和维护即可。知名的厂商如 Salesforce 公司
通过互联网所提供的 CRM 云客户关系管理系统便是个相当知名的应用服务。 图 13 云计算–服务模式 Salesforce 公司将 CRM 应用软件布署在该公司的互联网服务器上， 使用者可以根据公司内 部的客户管理需求向 Salesforce 公司购买相关的软件应用服务，接着使用者再按所购买的软件 服务多少、时间长短、网络流量等进行费用支付的操作。使用者只需要通过互联网即可获得 Salesforce 所提供的 CRM 软件服务， 因此对于许多中小企业来说公司不必为了搭建 CRM 客户 关系管理服务而购置机房、空调、电力、硬件服务器、CRM 网络服务带宽等以及维护 CRM 应 用软件等，可有效降低企业的初期搭建及后续运维管理成本。 根据知名市调机构 Gartner Group 评估， 软件即服务 SaaS 在 2010 年市场规模已经达到 100 亿美元，并在 2011 年达到 121 亿美元（上升 20.7%），并且预估在 2015 年时将会超过 2010 年 时的两倍，也就是预计将会达到 213 亿美元。 2．平台即服务 PaaS 平台即服务 PaaS（Platform as a Service），提供各种程序开发平台给开发人员以协助构建或 测试及部署定制应用程序，因此企业中的开发人员不用自行搭建主机、安装操作系统、准备程 序语言环境，企业若导入 PaaS 服务便可以减少在 IT 服务器设备数量以及不同操作系统平台上 的搭建成本。市场上知名的厂商有 Google App Engine、Amazon S3、Microsoft Azure、VMware Micro Cloud Foundry、Red Hat OpenShift 等。
以 VMware Micro Cloud Foundry 服务为例来说便可以打造出各种开放源代码的开发框架 （Framework）及中间件（Middleware），例如可以打造出支持 Java on Spring、Ruby on Rails/Sinatra、Node.js 的程序语言环境以及 MySQL、MongoDB、Redis 数据库系统。而 RedHat OpenShift 服务也可以支持多种程序语言，如 Ruby、Python、Perl、PHP、Java，以及相关的开
Codelgniter、 EE6、 CDI/Weld、 Spring、 Seam 等， 数据库方面则是支持 MySQL、 SQLite、 MongoDB、 Membase，如图 14 所示。由此可知使用这些 PaaS 服务可以大大节省开发人员为了搭建程序源 码测试环境所花费的时间，并且缩短整体开发时间。 图片来源：RedHat 网站Cloud Computing Solutions（http://goo.gl/W3g0e） 图 14 OpenShift EnterprisePaaS by RedHat Cloud 3．架构即服务 IaaS 架构即服务 IaaS（Infrastructure as a Service），其实可以说它是整个云计算的基础架构。通 常 IaaS 厂商利用大量的物理主机并且通过服务器虚拟化技术， 将大量物理服务器的硬件资源整 合搭建成一个庞大的计算资源池，而使用者仅需要通过浏览器选择他们所需要的硬件规格，例 如几颗 CPU Socket、几个计算核心 CPU Cores、多少内存 Memory、多少硬盘空间 Hard Disk Size 等，选择完毕后便可以轻松搭建好使用者所选择硬件规格的虚拟机并且开始运行，因此对 于新创立或小型公司若采用 IaaS 服务，可以减少公司在初创期间对于 IT 基础服务的搭建及管 理成本。IaaS 服务供应厂商有 Hinet HiCloud、Amazon Web Services（AWS）EC2、IBM Blue Cloud、HP Flexible Computing Services 等。
以 Amazon EC2 为例，该公司采用 Xen 虚拟化技术将许多物理主机搭建成一个庞大的计算 资源池，因此使用者只要登入 Amazon Web Services（AWS）首页后，就可以选择要将搭建的 VM 虚拟机布署在 Amazon 位于全球的哪一座机房中运行。目前 Amazon 全球共有四座主要机 房，分别是美洲（美东维吉尼亚州、美西北加州）、亚洲（新加坡）、欧洲（爱尔兰） 。并且可
以搭建各种操作系统，如 Windows、类 UNIX（Linux、FreeBSD 等），之后于该操作系统上执 行程序语言（如 PHP、Perl、Python、Ruby、JSP 等） ，进而使用它来架设商业网站（Business Web Site）、博客（Blog）、论坛社区（Web Forum）、虚拟专用网络（VPN）等企业服务。 读者若有兴趣的话，目前 Amazon Web Services（AWS）有提供「一年免费试用」方案 Free Usage Tier（http://goo.gl/V5ghV），不过可想而知既然是免费试用当然有相关限制（下列所整理 的相关小时以及流量数据是以「每个月为限」 ，超过的部分必须要支付费用!!） ： l 750 小时 Amazon EC2 Linux Micro Instance（支持 32/64 位架构、内存 613 MB） l 750 小时 Amazon EC2 Microsoft Windows Server Micro Instance（支持 32/64 位架构、内 存 613 MB）
l 750 小时 Amazon ELB（Elastic Load Balancer）流量弹性负载平衡（15 GB 的网络资料 处理）
l 30 GB 容量 Amazon EBS （Elastic Block Storage） 存储空间 （2 百万次 I/O 读写） 及 1 GB 快照空间 l 5 GB 容量 Amazon S3（S3 Standard Storage）存储空间（2 万次读取、2 千次存储） l 100 MB 容量 Amazon DynamoDB 存储空间（5 个写入单位、10 个读取单位） l 15 GB 的网络传输流量 l 10 次告警、100 万次 API 请求服务等 此外 Windows Azure 目前也提供「90 天免费试用」方案（http://goo.gl/bghSG），不过可想 而知既然是免费试用当然也有相关限制（下列整理的相关小时及流量数据是以「每个月为限」 ， 超过则必须支付费用!!） 。图 15 所示为 Windows Azure 运行示意图。 图 15 Windows Azure 运行示意图 l 750 小时的小型计算小时
l 10 个移动设备网站 l 1 个 SQL 数据库 l 100 小时 SQL Reporting 服务 l 35 GB 及 50,000,000 个文件限制 l 25 GB Output 网络带宽（Input 无限制） l 20 GB Output 及 500,000 个数量 l 128 MB 内存 l 1,500 个中继小时及 500,000 条消息 从图 16 中，我们可以看到传统 IT 架构以及云计算的三种服务模式 IaaS、PaaS、SaaS 互相 比较之下 IT 管理人员所需要费心处理的部分，传统 IT 架构虽然拥有最大的弹性但需要处理的 部分最多（灰色部分） ，而随着使用 IaaS、PaaS、SaaS 云计算服务模式后 IT，管理人员需要介 入的部分便越来越少。 图 16 传统 IT 架构及云计算服务模式
112 云计算五四三
您是否觉得经过上述对于云计算的简单介绍后还是会感到有点困惑或混乱？其实现在市场 上有许多厂商所提供的服务并未真正达到云计算等级，但是只要牵扯到使用互联网存取时厂商 便会美其名地冠上云计算的称号以便在市场中占据份额，那么到底怎么样的服务才能称之为云 计算呢？美国国家标准局（National Institute of Standards and Technology，NIST）对于云计算做 出了适当的解释，也就是常常听到的「云计算五四三」。根 据 美 国 国 家 标 准 局 （ NIST ） 在 「 The NIST Definition of Cloud Computing 」 （http://goo.gl/eBGBk）文件当中提到，若要达到云计算等级必须具备「五项技术特征、四个布
署模型、三种服务模式」 ，如图 17 所示。 五项技术特征 l 按需自助服务（Ondemand selfservice） l 随时随地地使用任何网络设备存取（Broad network access） l 共享式资源池（Resource pooling） l 快速且弹性的布署机制（Rapid elasticity） l 监控与计费服务（Measured service） 四个布署模型 l 公有云（Public cloud） l 私有云（Private cloud） l 混合云（Hybrid cloud） l 社区云（Community cloud） 三种服务模式 l 软件即服务（Software as a Service，SaaS） l 平台即服务（Platform as a Service，PaaS） l 架构即服务（Infrastructure as a Service，IaaS） 图 17 美国国家标准局（NIST）定义云计算
12 x86 虚拟化技术
在说明 x86 虚拟化技术以前，笔者认为应该先从 x86 架构 CPU 特权模式 （CPU Privileged Mode）开始谈起，由于 x86 架构一开始设计时是以「个人计算机」为定位，因此要做到将物理运行架构上共有四个特权等级，从 Ring 0～Ring 3，其中权限最高为 Ring 0。通常只有操作系 统可以与内核（Kernel）进行沟通，并且直接控制物理主机硬件资源的使用，如 CPU、Memory、 Device I/O，而 Ring 1 / Ring 2 则通常为外围设备的驱动程序，很少使用到，最后则是使用者接 触到的应用程序，处于 Ring 3 特权模式。 图 18 Privilege rings for the x86 available in protected mode 物理主机进行虚拟化之后的虚拟层（Virtualization Layer）将允许多个操作系统（Operating System）同时运行于一台 x86 物理主机上，并且可以动态分享物理主机的 CPU 计算能力、存 储设备（Storage）、内存（Memory）、网络功能（Networking）、硬盘 I/O（Disk I/O）、外围设备 （Device）等各项物理主机硬件资源，如图 19 所示。 图 19 x86 Virtualization Layer
由于近几年来 x86 服务器计算能力与日俱增（几乎为几何式成长!!），服务器虚拟化技术也 到了成熟稳定的阶段，因此很适合用来简化软件开发及测试作业，并且也可以将企业营运用的 主机及服务迁移至虚拟化平台上，以达到集成服务器的目的 （服务器集缩， Server Consolidation） 并提高数据中心整体弹性、可用性及连续性。 虚拟化技术可以将操作系统由硬件服务器当中抽离并且封装成单一文件后运行于虚拟化环 境之上，因此使得操作系统可以不用在意服务器的硬件是什么，例如操作系统可以在高可用性 及具有备份容错功能的虚拟化环境上持续运行 365 天（7×24 小时）都不需要停机（Down Time），即使物理服务器需要进行硬件维修，也只需要将运行于其上的 VM 虚拟机迁移至其他 台物理服务器继续运行即可。
对于标准的 x86 架构系统来说，虚拟化方法可以使用 Hosted 或 Hypervisor 架构。Hosted 架构必须先安装操作系统然后再安装 Virtualization Layer 于应用程序上，这样的架构支持最广 泛的硬件设备，相比之下 Hypervisor（BareMetal）架构则是直接安装 Virtualization Layer 在一 个干净的 x86 硬件上，由于它可以「直接存取（Direct Access）」硬件资源而不是另外通过操作 系统，因此可以提供给运行于其上 VM 虚拟机更好的运行效能。
x86 CPU 架构虚拟化技术目前可大致区分为三种：
l 全虚拟化技术（Full Virtualization）：使用二进制编译（Binary Translation）技术完成。
l 半虚拟化技术（Para Virtualization）：修改操作系统内核及配合 Hypercall 技术完成。
l 硬件辅助虚拟化（Hardware Assisted Virtualization）：直接由 CPU 支持虚拟化技术 完成。
121 全虚拟化技术
x86 CPU 原先的设计架构下操作系统会完全掌控主机硬件资源，x86 架构提供了四个特权 等级 （Privilege Level） 即 Ring 0～Ring 3 （特权大～小） 给操作系统及应用程序以直接存取 （Direct Execution）方式来存取物理主机硬件资源。使用者等级的应用程序（User Apps）通常运行在 Ring 3 特权等级上，而操作系统（OS）因为需要直接存取硬件资源（例如 CPU、内存等）因 此运行在 Ring 0 特权等级上。 x86 虚拟化架构则是将 Virtualization Layer （VMM） 放置于跟操作系统同样特权等级的 Ring 0，以便完全掌控硬件资源进而提供给运行于其上的 VM 虚拟机。但是当 Ring 0 特权等级已经 被 Virtualization Layer 占用的情况之下，运行于 VMM 上的 VM 虚拟机其操作系统（Guest OS） 特权等级就退一级变成 Ring 1。Guest OS 在存取硬件资源的某些情况下，若没有身处在 Ring 0 特权等级中有些命令是无法顺利执行的，而且那些执行操作的命令也无法被虚拟化成在 Ring 1 特权等级上可以执行（Nonvirtualizable OS Instructions），因此一开始 x86 虚拟化架构看来是无 法运行的一项技术，如图 110 所示。
图 110 x86 CPU 特权模式（未虚拟化之前）
然而 x86 架构的虚拟化难题在 1998 年时被 VMware 挑战成功!! VMware 开发出名为「二 进制编译技术（Binary Translation Techniques）」的全虚拟化技术（Full Virtualization），该技术可 以使 VMM 运行在 Ring 0 特权等级之上而 VM 虚拟机 （Guest OS） 虽然处于 Ring 1 特权模式， 但是当需要存取硬件资源时会通过二进制转译的方式，将无法在 Ring 1 模式执行的核心代码 （Kernel Code）进行转译进而顺利执行命令并存取硬件资源，而使用者等级的应用程序则仍通 过直接存取的方式来存取硬件资源，每一个 VM 虚拟机都会有一个 VMM 来负责虚拟机与物理 主机之间硬件资源存取的需求，并提供虚拟硬件给虚拟机使用，包括 BIOS、Memory、外围设 备等。 整合了二进制编译（Binary Translation）及直接存取（Direct Execution）的全虚拟化技术， 其 Virtualization Layer 可以支持运行任何操作系统的 VM 虚拟机，因此虚拟机可以完全跟物理 主机的硬件脱离， 如图 111 所示。此外运行于虚拟机上的操作系统完全不需要进行任何修改 （因 为它不知道自已被虚拟化了），所以全虚拟化技术并不需要硬件支持，也不需要修改操作系统即 可完成支持无法被虚拟化的特权命令的目的。 图 111 通过二进制转译（Binary Translation）完成 x86 架构虚拟化
122 半虚拟化技术
「Para」原本是源自于希腊语，如果使用英语来翻译的话则有「旁边」的意思（所以 Para Virtualization 若翻译成旁虚拟化技术也无不可） 。半虚拟化技术主要是通过修改操作系统内核（OS Kernel），将那些无法被虚拟化的命令（nonvirtualizable instructions）也就是无法在 Ring 1 特权模式执行的命令，以 Hypercalls 来取代它们，使得操作系统不用因为虚拟化而将 CPU 特权 等级降到 Ring 1 （保持在 Ring 0），并且通过 Hypercalls 界面来与 Virtualization Layer Hypervisor 进行沟通，以及管理物理主机上的内存及 CPU 内核中断处理（Critical Kernel Operations）等操 作，以减少物理主机硬件资源耗损从而提高 VM 虚拟机性能表现，如图 112 所示。 图 112 通过修改操作系统内核以 Hypercalls 来完成 x86 虚拟化 由此可知半虚拟化与全虚拟化是完全不同的两种技术，半虚拟化的主要优势是降低因为虚 拟化所带来的硬件资源耗损，但是缺点是必须修改操作系统的内核为前提，因此未经过修改的 操作系统内核便无法运行于半虚拟化技术平台上。在开放源代码中的 Xen 计划，就是半虚拟化 技术的最好例子，它可以使用修改过的 Linux 内核在半虚拟化平台上运行得很好。
123 CPU 硬件辅助虚拟化
由于目前 x86 架构的服务器性能与日俱增， 硬件厂商知道 x86 虚拟化架构的需求在未来势 必大增，因此 CPU 大厂 Intel 及 AMD 决定重新设计 x86 CPU 架构以简化虚拟化技术的导入 门槛。两家 CPU 大厂分别在 2006 年推出了第一代虚拟化技术的 x86 CPU，Intel 公司推出 Virtualization Technology（VTx）技术而 AMD 公司则推出了 AMDV 技术，第一代虚拟化技术 可以定制一个新的 CPU 执行特权模式，使 VMM 可以运行在低于 Ring 0 的环境。Intel VTx 虚拟化技术是将虚拟机状态存储于「虚拟机控制结构，Virtual Machine Control Structures」当中，而 AMDV 虚拟化技术则是将虚拟机状态存储于「虚拟机控制模式，Virtual Machine Control Blocks」当中，虽然两种虚拟化技术有些许不同，不过简单来说硬件辅助虚拟 化技术是将原先的 x86 CPU 特权等级 Ring 0～Ring 3 重新规划为 NonRoot Mode 特权等级， 同时新增一个 「Root Mode」 特权等级供 Hypervisor （VMM） 使用，也常常有人把 Root Mode 称 之为「Ring 1」 。
因此 Hypervisor（VMM）便可以直接使用 Root Mode（Ring 1）特权等级运行，而操作系 统也维持在原来的 Ring 0 特权等级。通过 CPU 硬件辅助虚拟化之后半虚拟化技术不再需要修 改操作系统内核来符合虚拟化运行架构，而全虚拟化技术也不用再做二进制编译的操作进而耗
便不再需要修改 Linux 内核即可轻松搭建一个虚拟化环境，如图 113 所示。
图 113 通过 CPU 硬件辅助虚拟化技术完成 x86 虚拟化
将 CPU 虚拟化之后 Memory 虚拟化将是下一个关键，因为这涉及到物理主机内存如何分配 给虚拟机并进行动态调整，VM 虚拟机内存虚拟化跟目前虚拟内存支持操作系统的方式非常类 似，因此 Intel 及 AMD 又发展出第二代的硬件辅助虚拟化技术 MMU（Memory Management Unit）， 可以有效降低虚拟化所造成的内存资源损耗。 以 Intel 技术来说称之为 Intel EPT （Extended Page Tables），而 AMD 技术则称为 AMD NPT（Nested Page Tables）或 AMD RVI（Rapid Virtualization Indexing），此内存虚拟化技术会在 x86 CPU 中包含一个内存管理单元（MMU）以 及前瞻转换缓冲区（Translation Lookaside Buffer，TLB）来优化虚拟内存的使用性能。
MMU 虚拟化技术的运行原理为当应用程序看到一个连续的地址空间（Address Space）时， 并不一定依赖于底层物理主机内存进行占用， 而是操作系统保留对应虚拟页面号码 （Virtual Page Numbers）后与物理页面号码存在页面表格（Page Tables）中。每台运行中的 VM 虚拟机其虚拟 内存不断对应到物理内存但无法直接存取物理机器的内存，此时便可以通过内存管理单元 （MMU）来支持虚拟机进行对应的操作。VMM 使用阴影分页技术（Shadow Page Tables）负 责把虚拟机的物理内存对应到物理机器的内存， 如图114 中所示 VMM 使用 TLB 机制 （虚线）， 把虚拟内存直接对应到物理机器内存以避免每次存取时都要进行层层转换作业，当虚拟机改变 虚拟内存的对应关系时 VMM 便会更新阴影分页内容以便快速找到相关的对应地址。
图 114 MMU 内存虚拟化运行示意图
克服了 CPU 以及 Memory 虚拟化难题后则是将外围设备 I/O 也进行虚拟化，因为这涉及 到虚拟设备和物理设备之间的 I/O 请求以及软件方式的 I/O 虚拟化设备管理，但是相对于物理
设备来说虚拟化设备完成了丰富功能以及简化管理的需求，例如虚拟化平台搭建虚拟交换机并 将多台 VM 虚拟机接于其中，通过虚拟网卡连接互相进行流量传输，但是实际上却不会给物理 网络中造成任何的网络流量传输，是更具弹性的网络架构。
网卡群组（NIC Teaming）功能则带给物理网卡故障转移及负载平衡的功能并且不会影响到 VM 虚拟机的网络流量，而 VM 虚拟机也可以使用迁移功能后在不同的虚拟化平台上使用相同 的网卡地址（MAC Address），因此 I/O 虚拟化的关键是要确保这样的机制对于物理主机中 CPU 负载程度是最低的，这些虚拟设备都能有效地虚拟出 VM 虚拟机所会使用到的外围设备，因此 不管 VM 虚拟机的操作系统是什么， 都不用担心物理机器外围设备 I/O 的问题， 如图 115 所示。 图片来源：VMware 文件Understanding Full Virtualization， Paravirtualization and Hardware Assist（http://goo.gl/0vnW） 图 115 外围设备 I/O 虚拟化
124 x86 虚拟化技术比较
介绍了目前市场上三种主流的 x86 架构虚拟化技术之后，我们将三种虚拟化技术针对各项 需求进行相关的比较，列于表 11 中。 表 11 半虚拟化 全虚拟化 硬件辅助虚拟化 实现技术 Hypercalls Binary Translation Root ModeVM 虚拟机兼容性 必须修改操作系统内核 才可以被支持 可运行绝大多数操作系 统类型的虚拟机 可运行绝大多数操作系 统类型的虚拟机 运行效率 较好 普通 中等 代表厂商 Xen、Microsoft VMware、Microsoft、 Parallels VMware、Microsoft、 Parallels、Xen
13 虚拟化技术风靡全球
虚拟化技术始于 1960 年代，在 IBM Mainframe System z Platform 大型主机上，首次开发用 于分割大型主机硬件资源以提高大型主机的硬件资源使用效率，当时 IBM 公司所采用的虚拟 化技术为将大型主机从逻辑观念上分割为数个虚拟机，并且这些逻辑分割区中的虚拟机能进行 「多工运行」，即能同时执行多个执行程序（Process）及应用程序（Application），因此在当时 虽然大型物理主机搭建费用巨大，却也能通过这样的逻辑分割技术达到投资效益平衡（详情参 考 IBM 网站信息 http://goo.gl/PXXOU） ，如图 116 和图 117 所示。 图片来源：维基百科IBM 7090（http://goo.gl/5Z3zK） 图 116 IBM 7090 Mainframe computer 图 117 IBM Mainframe Virtualization 运行示意图 但是在 1980～1990 年时，由于 x86 架构具有使用简单且费用便宜的特性（与大型主机相比 之下），广泛地应用于 PC 主机、WorkStation 工作站、服务器等，加上 Windows 及 Linux 操作系统不断更新升级，x86 架构主机便逐渐成为业界标准，因此与大型主机的高搭建成本形成鲜 明对比，从而其虚拟化技术当然也就乏人问津。 然而 x86 架构演变至今，也逐渐面临如同 1960 年代时大型主机所遭遇到的架构变通与硬 件资源利用率低落问题。根据市场调查机构 IDC（International Data Corporation）调查指出，企 业中 x86 服务器的硬件资源平均利用率通常只占该主机资源的 10%～15%。 图 118 所示为虚拟 化技术演变历史。 图片来源：IDC 分析师观点Virtualization!虚拟化应用无所不在（http://goo.gl/DCaCW） 图 118 虚拟化技术演变历史 举例来说，企业 IT 人员通常不会在一台 x86 服务器上安装多个应用程序及服务，以便提 高服务器运行服务的回应效率，同时确保问题发生时在问题排错上不会有服务互相干扰的情况 发生。例如在正常情况下 IT 人员并不会将企业营运用的 Exchange 邮件服务与 MS SQL 数据库 服务安装在同一台 x86 服务器上。 根据市场调查机构 IDC 的研究报告指出，2012 年时全球企业用于虚拟化服务器的运行和 管理方面的支出接近 1,000 亿美元，而全球的虚拟化服务器安装数量将从 2005 年的 2,690 万 台，预估成长到 2013 年的 8,200 万台。并且由于虚拟化技术的风行，企业会将许多物理服务 器进行整合（Server Consolidation）的结果，企业对于共享存储空间的需求量也将大幅增加。 根据 IDC 的研究数据显示，2009 年全球存储设备空间出货量已经达到 10,420 PB（Peta Byte， 1PB = 1,024 TB）并且预估 2014 年将成长至 79,796 PB，如图 119 所示。最新由 EMC 委托 IDC 调查的数字世界研究报告更指出，在 2020 年时全球的数字资料量将会达到 40 ZB（Zetta
图片来源：EMC 网站Digital Universe Consumers and the Digital Universe（http://goo.gl/oGJEh） 图 119 数字世界资料量成长示意图 图片来源：EMC 网站The Digital Universe and the Cloud 2020（http://goo.gl/m14EH） 图 120 2020 年数字世界与云计算
131 Microsoft HyperV 虚拟化技术
于 2008 年 6 月所发行的 Windows Server 2008 操作系统当中， 便含有 Microsoft HyperV 1.0 虚拟化技术。紧接着在 2009 年 10 月发行的 Windows Server 2008 R2 操作系统中，则将其升级 为 Microsoft HyperV 2.0 虚拟化技术，最新于 2012 年 9 月所发行的 Windows Server 2012 云操 作系统则升级为 Microsoft HyperV 3.0 虚拟化技术。HyperV 虚拟化平台运行架构主要分为三层， 分别是 「Hypervisor、Root Partition （或称 Parent Partition）、Child Partition」，当然其中又有其他的模块来分别协同运行，如图 121 所示。当我 们在看 HyperV 运行架构图时便会看到一些技术名词的缩写，以下为相关功能说明： u Hypervisor：负责掌管最后物理主机的硬件资源存取以及硬件资源的调度使用。 l Hypercall：先前有提到半虚拟化技术为采用 Hypercall 对硬件资源进行存取作业。 l MSR：Memory Service Routine。 l APIC（Advanced Programmable Interrupt Controller）：硬件设备的中断作业控制。 图片来源：MSDN LibraryHyperV Architecture（http://goo.gl/9x5H9） 图 121 HyperV 运行模块架构示意图
u Root/Parent Partition：简单来说就是 Host OS 执行虚拟化堆栈的任务，将 Child Partition 传 送过来的存取硬件设备需求传递给 Hypervisor 进行硬件资源的存取。
l WMI（Windows Management Instrumentation）：Root Partition 通过 VMI API 去管理及控 制在 Child Partition 中运行的 Guest OS。
l VMMS （Virtual Machine Management Service）：负责管理 Child Partition 也就是 Guest OS 的运行状况。
l VMWP（Virtual Machine Worker Process）：通过 Virtual Machine Management 管理服务 来管理 Child Partition 中的 Guest OS（每管理一台 Guest OS 就会搭建一个服务来专门 负责管理）。
l VID（Virtualization Infrastructure Driver）：提供 Partition 的管理服务，负责管理 Virtual Processor、Memory 的运行事宜。
l VMBus：为 Root Partition 与 Child Partition 之间沟通的渠道。
l I/O stack：硬件资源中的 Input / Output 堆栈。
l WinHv（Windows Hypervisor Interface Library）：为 Partition 中操作系统驱动程序及 Hypervisor 之间的沟通桥梁。
u Child Partition：简单来说就是 Guest OS，也就是运行于虚拟化平台上的 VM 虚拟机，当需 要存取硬件资源时将通过 VMBus 把存取需求传递给 Root Partition。
l VMBus：为 Root Partition 与 Child Partition 之间沟通的渠道，若 Child Partition 之中的 Guest OS 未安装「集成服务（Integration Services）」，便不会有 VMBus 与 Root Partition 进行硬件资源的存取及沟通，因此便会造成运行性能低落。
l IC （Integration component） ： 允许 Child Partition 能够与其他 Partition 以及 Hypervisor 进 行沟通作业。
l I/O stack：硬件资源中的 Input / Output 堆栈。
l VSC（Virtualization Service Client）：存在于 Child Partition 中，当 Guest OS 需要存取硬 件资源时，会把存取需求经由 VMBus 传送给 Root Partition 的 VSP。
l WinHv（Windows Hypervisor Interface Library）：为 Partition 中操作系统驱动程序及 Hypervisor 之间的沟通桥梁，Guest OS 必须要安装「集成服务（Integration Services）」 才会有此模块。若是 HyperV 3.0 Enlightenment OS（Windows 8、Windows Server 2012） ， 则预先已经拥有此模块。
l LinuxHv（Linux Hypervisor Interface Library）：为 Partition 中操作系统驱动程序及 Hypervisor 之间的沟通桥梁，Guest OS 必须要安装「集成服务（Integration Services）」 才会有此模块（集成服务目前最新版本为 Linux Integration Services Version 3.4 for HyperV）。
132 服务器虚拟化技术市场趋势
由全球知名市场调查研究机构 Gartner 于 2010 年 5 月所发表 「x86 服务器虚拟化基础设施 魔术象限（2010 Magic Quadrant for x86 Server Virtualization Infrastructure）」研究报告当中，我 们可以发现在 2010 年，唯一居于「领导者（Leaders）」象限中的厂商只有 VMware 一家，而其 他如 Microsoft、Citrix、RedHat、Oracle、Parallels、Novell 则分属于其他象限中继续追赶，如 图 122 所示。 于 2011 年 6 月 Gartner 研究机构所发表的「x86 服务器虚拟化基础设施魔术象限」研究报 告中，我们可以发现 Microsoft 等领导厂商已经了解到虚拟化技术对于全球 IT 来说为势在必行 的技术，因此经过相当的努力之后也纷纷挤身至「领导者（Leaders）」象限当中，至于 RedHat、 Oracle、Parallels 仍在其他象限中继续追赶，如图 123 所示。图片来源：Gartner 2010 Magic Quadrant for x86 Server 图片来源：Gartner 2011 Magic Quadrant for x86 Server Virtualization Infrastructure（http://goo.gl/Dy3wn） Virtualization Infrastructure（http://goo.gl/ZRYaJ） 图 122 Gartner 研究报告 2010 年 x86 图 123 Gartner 研究报告 2011 年 x86 服务器虚拟化基础设施魔术象限 服务器虚拟化基础设施魔术象限 2012 年 6 月最新一期的 Gartner 研究机构的「x86 服务器虚拟化基础设施魔术象限」研究 报告中，处于「领导者（Leaders）」象限中的仍然只有「VMware、Microsoft、Citrix」等三家厂 商，而 RedHat、Oracle、Parallels 同样保持在其他象限中继续追赶，如图 124 所示。 图片来源：Gartner 2012 Magic Quadrant for x86 Server Virtualization Infrastructure（http://goo.gl/6UGoJ） 图 124 Gartner 研究报告 2012 年 x86 服务器虚拟化基础设施魔术象限
商推出更好的解决方案之外，使用者也有更多选择以及比较的机会（避免一家厂商独大），因此 可知虚拟化技术演变至今已经是相当得成熟， 虽然国内 IT 在虚拟化技术引入进度方面相较于国 外确实晚了些，但经过本章相关的说明后相信可以消除大多数人心中对于虚拟化技术的疑问。 因此若对于虚拟化技术还停留在只是用于测试软件的话，那实在就太小看了虚拟化技术的功能 及用途了!!
14 群集服务
在目前竞争激烈的商业环境当中，能够提供给顾客一个高稳定性及反应快速的服务一直是 企业营运环境所追求的目标，然而随着时代的进步大多数企业都纷纷将作业环境转移至计算机 上，因此小至个人计算大至科学计算无一不跟计算机牵连在一起。 为了完成提供给顾客高稳定性及反应快速的服务的目标， 企业的 IT 部门通常会开始着手搭 建故障转移群集（Failover Cluster）机制，一般来说故障转移群集技术又可划分为三种类型，分 别是 High Availability、Load Balancing 和 Grid Computing。l 高可用性（High Availability）：也就是我们常听到的 HA 机制（例如 Active/Standby、 Active/Active），此类型的群集通常在于维持服务使服务随时处于高稳定的状况中。例如 企业营运环境中常常将数据库服务器导入此运行机制， 将两台数据库服务器设置为 High Availability Failover Cluster，只要其中一台数据库服务器因为不可抗拒或其他因素发生 故障损坏时，另外一台数据库服务器可以在很短时间内自动将服务接手过来，使用者完 全感觉不到发生过任何服务中断的情况（顶多是数据库服务回应时间上有点卡卡的）。 l 负载平衡（Load Balancing）：此类型的群集通常能够同时服务为数众多的服务请求。 例如在企业营运环境中前端的 AP 应用程序服务器常常是这样的角色，也就是在前端 布署多台 AP 服务器来同时服务为数众多的客户端所送出的大量服务请求，将使用者 的服务请求进行处理再与后端的数据库服务器进行沟通后将数据写入或取出供客户 端查询。 l 网格计算（Grid Computing）：此类型的群集较少使用于企业营运环境上，通常都运用于 科学研究上。例如将多台计算机的计算能力串连起来后，利用其强大的计算能力进行计 算找出人类基因密码、或者对抗癌症的方法、或分析外星人信息等，1999 年风靡一时 的 SETI@Home 项目（Search Extraterrestrial Intelligence at Home），就是号召在计算机 闲置时有意提供计算能力的人安装其应用程序后共同参与分析外星文明传递过来的微 弱信息，如图 125 所示。
图片来源：维基百科SETI@home（http://goo.gl/jHXjJ） 图 125 Grid Computing SETI@Home
141 高可用性
高可用性 （High Availability）运行机制为故障转移群集技术（Failover Cluster） 的其中一项， 也就是常常听到的 HA 机制 （例如 Active / Standby） 。此类型的群集技术通常用于维持服务的高 可用性并使服务随时处于高稳定的运行状态。例如将企业营运环境中的 UTM 设备搭建为 High Availability Cluster 运行机制后，只要其中一台 UTM 设备因为不可抗拒或其他因素损坏时，另 外一台 UTM 设备便在很短时间内将在线服务完全接手过来继续服务客户及使用者，因此不论 是企业内部员工或外部互联网使用者将完全感觉不到有任何服务停止运行的情况发生过。 而谈到了高可用性便会从「服务层级协议 SLA（Service Level Agreement）」方面说起，服 务层级协议 SLA 一般指的便是服务提供者与使用者之间依服务性质、时间、质量、水平、性 能等方面共同完成协议或订定契约，而在服务可用性方面通常会采用数字 9 及百分比来表示， 依据不同的 SLA 等级通常大略可区分为 1～6 个 9。图 126 便是依据可用性不同等级百分比来 定制出每年、每月、每周的可允许服务中断时间（Downtime） 。 事实上 SLA 服务层级协议并非仅仅上述说明的可允许服务中断时间而已， 还有许多因素需 要考虑，例如必须要了解该服务供应商以及自身企业中所允许的「停机定义」才行。例如 A 企 业可能认为所谓的停机就是服务器故障损坏导致服务停止运行， 而 B 企业却可能认为只要在线 运行的服务中断或离线（服务器未故障损坏）就视为发生停机事件，因此实际上还要结合许多 企业营运状况后进行通盘考虑，才能避免灾难事件发生时双方在责任上扯皮的问题发生。 以企业放置营运环境服务器的数据中心（机房）为例，就有美国国家标准协会（ANSI）、组织标准可供遵循。以定制出一套标准来进行数据中心的可用性评估为例，从数据中心空间规 划（分布区域）、电力供应、冷气空调（冷/热通道）、机房环境干湿度到网络/光纤线材等皆在评 估标准内， 如图 127 和图 128 所示。 此外还有 3 大关键性 RAS 指标， 分别是 「可靠性 （Reliability）、 可维护性（Serviceability）、可用性（Availability）」。 图片来源：MySQL 网站High Availability and Scalability（http://goo.gl/EVfOh） 图 126 SLA 服务层级协议（成本、复杂性、可用性） 图片来源：TIA942 Data Center Standards Overview（http://goo.gl/33lsh） 图 127 数据中心分布区域规划示意图
图片来源：TIA942 Data Center Standards Overview（http://goo.gl/33lsh） 图 128 数据中心冷热通道示意图 许多人认为单纯的「机柜」也是机房搭建的一大重点，例如笔者常看到许多企业机房中的 机柜其前后门皆采用透明的玻璃门便是造成散热问题 的常见原凶。试想服务器通常会采用前方进气后方排 热的架构设计，但是服务器前方吸收冷气的管道已经 被机柜的玻璃门所阻隔，而服务器后方排放热气的管 道也被玻璃门所阻隔（或者被线材瀑布所阻隔!!），所 以除了服务器因为散热不良容易导致相关电子模块损 坏机率提升以外，连带对于机房制冷降温效果也不佳 （根据统计 IT 每年有 1/3 的电费是花费在服务器供电 上、另外 1/3 电费则是花费在制冷降温能力上）。因此 现在新兴的机柜设计更发展出烟囱式机柜，统一将服 务器所排放出的热能直接导离机房提升制冷降温效 果，如图 129 和图 130 所示。 除此之外在搭建机房过程中还有许多需要注意的 事项，例如布线标准 EIA/TIA 568、空间标准 EIA/TIA 569、接地及连接需求 EIA/TIA 607、布线标示管理标 准 EIA/TIA 606 等。接上例继续说明，如果所采购的 机柜没有「整线/理线」机制，那么久而久之便会产生 线材瀑布的壮观情况。 此外网络线材也不应该自行 DIY（您真的能确认 图片来源：Great Lakes Case and Cabinet – Solutions Cooling（http://goo.gl/CCLbK） 图 129 烟囱式机柜冷热空气示意图
络交换机是大牌，但是所使用的网络线材却是令人啼笑皆非的情况，如图 131 所示，所以搭建 时就应该要考量到整体进行结构化布线（并非只是单纯的整线），不但可以有效提升系统的可靠 度、 日后维护弹性、 管理方便性等， 对于机房的制冷降温能力也同样有帮助， 如图 132 和图 133 所示。 图片来源：42U.com 网站 Hot Aisle Containment（http://goo.gl/8GHrH） 图 130 烟囱式机柜冷热通道示意图 图 131 自行 DIY 制作的网络线材传输效率令人担心 近年来国内各大 ISP 如中国电信、中国联通、中国移动所打造的数据中心（绿色云机房） ， 便是纷纷采用 TIA942 或 UPTIME Institute 评估数据中心可靠性标准进行搭建 ， 也就是通过 「平 均故障间隔时间 MTBF（Mean Time Between Failures）」及「平均修复时间 MTTR（Mean Time to Repair）」，并且配合 3 大关键性 RAS 指标所规划出四种不同等级（Tier 1～Tier 4）的可用 性评估标准进行搭建。表 12 所示为 Tier 1～Tier 4 的可用性及中断时间。
表 12
可用性等级 可用性% 中断时间（年）
Tier 1 Basic 99.671% 28.8 小时 Tier 2 Redundant Components 99.741% 22.7 小时 Tier 3 Concurrently Maintainable 99.982% 1.6 小时 Tier 4 Fault Tolerant 99.995% 26.3 分钟 图片来源：统振游戏服务器机房结构化布线 图片来源：统振游戏服务器机房结构化布线 图 132 采用结构化布线后管理方便、 图 133 采用结构化布线后管理方便、 整齐美观、传输效率高 整齐美观、传输效率高 图片来源：UPTIME InstituteAchieving 99% Free Cooling and Tier 3 Certification in a Modular Enterprise Data Center（http://goo.gl/PzMzK） 图 134 数据中心对于各种季节时温湿度也应进行相对调整（夏天时温湿度建议值）
场上最优秀的云机房服务供应商之一的 Amazon 也偶尔会发生严重当机事件。 举例来说， Amazon EC2（Elastic Compute Cloud）云服务对于该服务使用者号称具备「99.95%（年）」的可用性（也 就是一年当中的中断时间仅有 4.38 小时） ，如图 136 所示。 图片来源：UPTIME InstituteAchieving 99% Free Cooling and Tier 3 Certification in a Modular Enterprise Data Center（http://goo.gl/PzMzK） 图 135 数据中心对于各种季节时温湿度也应进行相对调整（冬天时温湿度建议值） 图片来源：Amazon 网站Amazon EC2 Service Level Agreement（http://goo.gl/SuKq） 图 136 Amazon EC2 网站 SLA 内容中说明提供 99.95%的可用性 但是 Amazon EC2（Elastic Compute Cloud）服务于 2011 年 4 月 21 日时就发生过因为维护 人员操作上的人为疏失（弄错一项网络设置）加上过度自动化机制的盲点所产生的连锁效应， 导致整个 Amazon EC2、Amazon RDS、AWS Elastic Beanstalk 等相关服务中断了足足「3 天」才 完全复原，因此连带影响到存放于该机房中运行的上千个网站停止服务，如图 137 所示。
图片来源：Amazon 网站 Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region（http://goo.gl/FhgCJ）
图 137 Amazon EC2 服务当机事件处理经过及道歉声明
在 2012 年 12 月 24 日平安夜又因为 Amazon ELB（Elastic Load Balancing）服务资料被误 删，造成专门提供串流影片的 Netflix 服务中断了「20 小时」才恢复正常，其他网站则因为此次 的资料误删事件而出现严重性能不佳的情形，如图 138 所示。 图片来源：Amazon 网站 Summary of the December 24, 2012 Amazon ELB Service Event in the US East Region（http://goo.gl/PlM8X） 图 138 Amazon ELB 服务当机事件处理经过及道歉声明 所以对于企业永久经营服务不中断的理念来说， 除了对于服务供应商所提供的 SLA 服务层 级协议及相关罚则之外，对于企业服务的异地备份也应该考虑进去，以便发生相关灾难事件时 得以在最短时间内应变。
