虚拟化基础设施运维杂谈

现如今，以虚拟化技术来架构企事业单位的核心IT系统已经越来越普遍，对虚拟化技术的运用也从怀疑走向信任，从陌生走向熟悉。伴随着虚拟化技术的不断演进，虚拟化技术本身已经不再是用户担心的首要问题，取而代之的是如何更好地规划虚拟化架构，如何让虚拟化技术更好地服务IT服务，以及与运维场景相关联的个性化技术细节。

本文以vSphere为例，从虚拟化基础设施运维所涉及的各个方面出发，探讨运维的问题及合理性。

从服务器说起

无论虚拟化如何水平或垂直构建资源池，物理服务器始终是所有计算资源的承载单元，其整个x86架构的制造工艺和设计水平都真真切切影响着整个虚拟化架构的稳定和高效。以一个常见的比喻来说，物理服务器就是装鸡蛋的篮子，虽然是个“篮子”都可以拿来放鸡蛋，但“篮子”是否结实耐用、孔洞大小是否便于排列鸡蛋等细节，则决定了鸡蛋的命运。因此，一个多路处理器、大内存的服务器，并不能简单地像DIY一样拼装高配的零件就可以成为好的“篮子”，还需要兼顾虚拟化可以发挥优势的一些特征，比如机箱的物理散热和双电源，支持SD卡来安装Hypervisor，磁盘的数量和型号满足vSAN的部署条件，是选用光口还是电口的网卡、网卡的数量、网卡是否支持FCoE、交换机上千兆和万兆接口剩余的数量，选择FCSAN的存储以及IPSAN如何接入等，缺少这些考量的服务器，则难免在未来部署或使用中面临各种扩展性或性能的问题。

在CPU和内存的容量配比上值得注意的是，物理内存若配置得较大，比如128GB，甚至256GB，则CPU也应考虑选择同档次里较高的一款，因为消耗CPU的虚机和大量不消耗CPU却占用内存的虚机都需要物理的CPU去调度和处理，我们既不希望看见CPU负载75%，内存负载85%的场景，也不希望CPU负载仅10%，内存负载就90%的不均衡。针对这个矛盾，可以考虑初期配置较高的CPU和适量的内存，后期根据运行情况对内存进行扩容，因为内存的扩充较为便宜和方便。

ESXi是安装在物理服务器上的底层操作系统，该系统可以说也是“篮子”的一部分，从操作系统的角度来说，ESXi已经是较为极致的，可以安装在机架服务器1G的SD卡存储器，也可以通过USB来引导运行，还可以通过网络自动部署服务加载到内存，只要装好了ESXi，后期的运维几乎都不用再进机房面对服务器裸机（有远程管理或KVM例外）。对于具备HBA卡虚拟化特性的服务器，则建议以boot from san的方式安装ESXi，因为当单个计算节点故障时，可以直接关联虚拟HBA卡及其相关硬件信息到备用的计算节点，实现快速而完整的故障恢复，即缩短RTO，也便于技术人员维修或更换。此外，还有HP、Cisco、Fujitsu、Hitachi等几个厂商的服务器，ESXi都封装了OEM定制版，定制版无疑在驱动的支持上要优于通用版介质，使用这些厂商设备时也应尽可能使用OEM版介质。

对旧服务器，只要支持VT-x或AMD-v，内存大于等于4GB，也是可以考虑部署为ESXi底层的，因为它即使只能装一个虚机，也可以让这个虚机具备可迁移的能力，当故障来临或业务重要性提升时，可以从容地迁移到其他服务器。

配置虚拟机

承接前文的比喻，虚拟机就是装在“篮子”中的一只只“鸡蛋”，鸡蛋的数量在更多的场景中取决于内存的大小，强烈建议在重要生产环境中，同一物理机分配给虚机内存总和不宜超过物理内存大小，虽然虚拟化环境具备内存精简算法，能够对相同的操作系统共同的内存部分采用共享的方式来节约内存使用，但既然是算法，就会消耗CPU调度，就会带来一定的延迟，这些损耗在稍旧的服务器上表现更为明显。反之，对于计算资源拮据的环境，或对运行效率没有较高要求的环境，还是可以利用此技术优势来节约经费投入的。

在虚机的vCPU方面，应尽量采用单插槽多内核的方式，因为设定多个插槽的vCPU在运行中，会跨物理CPU插槽运行，这将增加CPU调度的损耗，而单个虚拟插槽的vCPU配置，则会在同一颗物理CPU内来虚拟，使得虚机在使用CPU资源时调度效率更高，这一细节对运算量较大的虚机还是较为重要的。

虚机的磁盘主要是vmdk文件，该文件是虚机的本源，假设虚机其他文件都遭到破坏或丢失，但只要vmdk完好，就能够恢复虚机运行。众所周知，vmdk采用厚置备可以获得更好的磁盘效率，采用精简置备方式可以在划分时超出物理LUN的大小上限，但在重要的生产环境中，本文则建议按需分配，首先对于虚机磁盘的使用比率，可以在周期性巡检维护中获知，利用操作系统的扩盘特性，如Windows的跨区卷、Linux的lvm等，待空间不足时新增vmdk来扩充是较为合理的。其次，对于vmdk容量总和超出物理LUN大小，一旦某个虚机因未知的事件快速填充过多预留的vmdk空间，容易使整个物理LUN在管理员无防备的情况下被写满，此时，该物理LUN上的所有虚机都会因物理LUN的磁盘满而停机，后果是可想而知的。vmdk经过配置，也可以作为虚拟的共享磁盘为两个或多个虚机所共用，利用这一特性也可以搭建出Oracle rac之类的集群环境，并且效率并不差，所需注意的是共享的vmdk不要进行存储位置的迁移，否则会在迁移中被当作每个虚机私有的磁盘复制为多个，进而破坏了共享的集群配置。

与vmdk相关联的一个实用功能是快照，它可以保持vmdk在某一个时间点的状态，后继运行对磁盘产生的变化则用差分的vmdk去记录，对存在风险的虚机调试特别方便，但也常常被错误地当作备份工具去使用。首先快照产生的差异vmdk存在于生产的LUN，过多的创建快照浪费昂贵的LUN空间。其次，快照数量过多潜在影响虚机运行效率，因为很可能存在连续读取的I/O分布在多个快照vmdk中，而查询多个vmdk文件内在关联性是需要消耗资源的；再次，较多的快照文件在vmdk迁移时，更容易出现失败。

有不少管理员认为，既然是虚拟的，每个虚机分配的计算资源可以多一些，反正用不到的部分是可以被其他虚机使用的。诚然，单台物理服务器的CPU资源是按照已开机虚机分配的vCPU数量去平均的，但还有内存和磁盘I/O的优先级呢？本文依然建议，每个虚机尽可能按需分配，这个需应是平峰负载所需的计算资源。若将分配虚拟硬件的资源当作预留计算资源，则是对虚拟化管理的误区。

比如某个虚机偶尔占满资源，但因为程序不好而不释放资源，比如新建虚机数量较多，则整个硬件资源池，可能是CPU也可能是内存也会较快达到饱和，此时再从已分配的虚机里去挤资源就较难了，即使新采购硬件也可能时间周期长或经费不足。我们可以按照不同应用划分资源池，由资源池预留这些应用在负载高峰期所需的计算能力，包括CPU资源、物理内存占用的优先级、vmdk对I/O的优先级，从而使资源池的虚拟硬件分配和占用更趋合理。

虚机模版是许多管理员喜爱的工具，最显著的优势就是快速批量部署虚机，但使用此功能一定不能偷懒，尤其对于Windows模版要配置好封装工具，以使SID在每次快速部署中得到更换，否则很容易埋下SID相同带来的隐患问题。

如果说vmdk是虚机存活在vmfs中的唯一形式，那么ovf则是虚机跨越文件系统和虚机格式的一个开放形态，将虚机导出为ovf/ova格式，ovf文件完整的封装当前虚机的所有文件和虚拟硬件配置，使虚机以文件的形式保存在常见的文件系统中，进而可以再导入其他虚拟化平台，实现更灵活的可迁移能力。与ovf静态转换相对应的是Converter工具，它能够将在线状态的物理机转换为虚机，将较早前版本的虚机转换为新的虚机版本，将不同vCenter中虚机进行复制传送，并在转换过程中实现磁盘格式在精简与厚置备之间的转换，利用此灵活性，有文件反复写入的虚机也可以在转换中将vmdk文件按顺序重新生成，换言之相当于对vmdk做了磁盘碎片整理，从而提高vmdk的读写效率。

围绕vCenter去架构

虚拟化基础设施的中央控制单元vCenter是运维必不可少的利器，它自身由单点登录组件、数据库、清单组件以及vCenter服务等多个部分构成，许多部署环境也将这些组件分别安装在多个虚机里，以支撑较大规模的部署。但现实中，什么样的规模可以称之为大呢？以清单组件安装时提供的选项可以作为一个参考，即100主机、1000虚机以内，都可以作为小规模，以此为标准，我们身边大部分的虚拟化环境都是小规模。

界定这一标准，我们大可不必逐项给每个组件新建Windows虚机，取而代之的是用 vCenter的 Appliance，该Appliance以SUSE12为基础，整合了 vCenter Server、SSO、Inventory Service、Database、Web Client、Log Browser、ESXi Dump Collector、Syslog Collector、Auto Deploy等几乎全套的组件，较高的整合度带来了完整的功能。此外，相对于多个Windows来搭建，仅一个Linux系统也能给vCenter带来更多的稳定性和安全性，官方预置的环境相对不熟练的管理员，也能避免自行配置中一知半解的不恰当配置，在硬件资源紧缺的环境中，Appliance能够带来集中且可靠的中央控制服务。同时，Appliance可以直接升级打补丁，这比分散搭建环境进行升级要容易许多。

提到升级，不得不说Update Manager这个组件，它能够方便地对集群中的ESXxi打补丁或跨版本升级，可以对虚机的vmtools进行批量更新，强烈建议在每个vCenter中都部署它，因为安全问题无小事，每一个ESXi都承载了太多的虚机，存在安全或健壮性短板的ESXi无疑给上层运行的虚机带来了太多意料之外的可能性。并且，通过它对ESXi进行跨版本升级也能保留原有ESXi上关于网络和其他插件的配置，极大简化跨版本升级时瞻前顾后的各种考虑。目前的UM没有OVA版，需要自行安装Windows环境去搭建。作为vCenter插件，难免在vCenter做了调整后遇到UM被禁用的情况，此时可以使用UM安装路径下的VMwareUpdate ManagerUtility.exe工具，重新注册到vCenter以解决问题。

伴随着虚机数量的增加，Operations Manager（以下简称 vcops）和 Data Protection（以下简称vdp）是两个不可或缺的常见工具。

vcops收集从服务器到虚机的性能指标，通过算法将各个层面的性能状态转化为可视化的图表值。通常，需要连续采集2个月的运行状态，才能较为准确地反映出CPU、内存负载、网络和磁盘吞吐率等情况的健康度，管理员依靠此工具，可以关注每个虚机和虚拟化整体的健康度，因为健康值是根据一长段时间的积累分析计算出来的，并不是单纯地从当前和上一个时间段的负载去简单比较，尤其对于磁盘I/O的负载，从SAN的管理端也只能看到哪个LUN的I/O较高，在vcops中能够准确地知道是哪个虚机造成了较大的I/O。

与开源的Cacti或Nagios监控工具相比，第三方监控是对具体对象的监控，每一个物理机、虚机的CPU、磁盘、网络都可看到，是针对点的状态反映，而vcops则将所有的对象关联起来进行监控和分析，得到的是针对面的状态反映，这更有利于管理员掌握虚拟化基础设施的综合运行情况。

vdp是虚机的备份和恢复工具，备份的主要对象就是vmdk，与快照类似，利用差异化的vmdk文件实现增量备份，但却独立在生产LUN之外，能够更好地管理vmdk，可以根据备份的策略实现不同粒度的备份需求，重复数据删除也有效节省实际所需的备份空间消耗。在vdp虚机启动过程中，可以观察到许多avamar字样，可以想象，vdp与avamar有着不浅的联系，但与avamar相比，它们都是作为插件集成，vdp与vCenter结合的紧密度更高，avamar作为第三方插件，功能比vdp更为全面，收费也不低，而vdp总的备份空间限定在2TB之内，可以免费使用。

当然，vCenter可用的组件不仅限于上述，还有用于vSphere整体安全的vCNS，用于容灾的SRM等，在近些年的快速发展中，一些组件逐渐消失，一些组件不断得到加强而成为新的产品，这也正是虚拟化技术对IT持续散发的魅力所在。

将被变革的存储

在服务器虚拟化发展的上一阶段，CPU和内存一直是池化的主要对象，存储还只是拿来就用的设备，与普通服务器系统相比，最大的区别就是将磁盘格式化为vmfs这个文件系统，这个文件系统与vmdk文件是相辅相成的，比如精简置备、虚拟机集群等特性都是基于vmfs实现的。值得注意的是，vmfs也是有版本的，我们很可能会将vSphere环境跨版本升级到一个新的版本号，却遗忘了检查和升级vmfs的版本。一方面，vmfs版本升级可以修复一定的漏洞，另一方面，低版本的vmfs运行在高版本的虚机上，很容易引发虚机内I/O问题。

当前，存储的池化成了本阶段新的发展重点，vSAN就是利用服务器直连磁盘而创建的高可用存储，它组网要求至少一块万兆网卡，拥有SATA/SAS HBA或直通模式下使用的RAID控制器，用于存储容量的磁盘至少有1块SSD和1块 HDD（SATA/SAS），SSD与HDD裸盘容量的比例不少于1:10，每个主机可以创建不超过5个磁盘组，每个磁盘组的HDD不超过6块，至少3台满足上述条件的主机组成集群。

符合上述要求的vSAN举例来说，SSD的70%用于读加速，30%用于写加速，HDD是主要的容量供给，若单台服务器可装6块3TB的HDD和2块240GB的SSD，3台服务器可获取近50TB存储空间，每台400GB的磁盘缓存对于提升IOPS也能较好应用在大多应用场景，即减少了存储的购置经费，也在一套技术体系内真正统管并池化了所有计算资源，减轻了存储系统维护复杂度。

不过，vSAN更大的优势还在故障冗余，每个运行在vSAN集群中的虚机，可以设置为允许多个故障数，即设置虚机文件的冗余份数，在这样一个3节点环境中，假设故障数设置为2，则可达到2台服务同时坏掉，这一虚机仍可存活在仅有一台服务器上，因为它在每个服务器的存储上都具有了副本，这在以FCSAN/IPSAN为存储的架构里则是难以达到的。当然，高可用的特性，也是以损耗总的存储空间为代价的，但反过来，用代价不菲的存储双活技术所投入的经费和消耗的存储空间会更多。从这个视角来看，vSAN就是颠覆传统存储的神器。

展望下一阶段，新的vVOL技术将架起联系vmdk与存储LUN的桥梁，打破LUN不知道 有 vmdk，vmdk不 知 vmfs下是什么存储的割裂局面，虚机成为存储管理和存储策略的基本对象。我们可以假想这样的场景：给一个新建的虚机定义了高可用的策略，存储就给该虚机创建多个互为克隆的vVOL，从而保证了虚拟机的可用性，甚至这多个vVOL放置在不同的存储设备上，且互为镜像，保证了无论是存储设备还是服务器挂掉都无法阻止虚拟机的运行。

行进中的网络虚拟化

原本一台服务器接入几个网络就用几块网卡是件简单明了的事情，而自虚拟化使用以来，一个物理服务器承载数十甚至上百的虚机也不是难事，于是，物理的网卡由单一的网络接口一下子提升到承载上百端口，多个VLAN，甚至不同的个性化端口策略的需求上，俨然担当了一个交换机的功能。再将视线扩展到多个服务器组成的虚拟化集群，服务器的网卡顺理成章地成为了上连交换机的级联口，其下对应着数以百计虚拟的网卡，于是，分布式虚拟交换机就这么诞生了，它将联网的范围从单个ESXi的标准虚拟交换机扩展到了整个vCenter的范围，提供集中化的管理端口以及高级特性。

经过多年的发展，目前能用到的分布式虚拟交换仍然只有厂商提供的Virtual Distribution Switch（以 下简称VDS）和Cisco Nexus 1000V（以下简称N1K）两个选择。VDS原生在vSphere内部，具有图形界面，部署配置更为简便易用；N1K与VDS一样首先是具备分布式虚拟交换的功能，其次，它具备Cisco网络所具备的交换管理特性，能够像对待直连交换机的服务器一般配置端口策略和访问控制，并且这些配置在网络迁移时也会随之移动。同时，也使网络管理能够跨越vSphere层面回归到传统的管理习惯上，命令行的管理界面也更贴近网络管理员的亲切感。

伴随着技术演进，各大网络设备厂商陆续推出了与虚拟化环境相融合的新设备或新协议，以期适应以虚拟化为基础的数据中心网络管理。作为VDS的提升，NSX是新发布的网络虚拟化平台，它通过编程方式提供分布式路由、分布式防火墙等服务，在现有物理网络上创建一个覆盖现有IP网络的灵活逻辑层，在满足东西向和南北向通信的同时，租户之间也保持相互隔离，在虚拟网络内提供全面的流量管理、监控和故障排除的工具，如端口镜像、NetFlow/IPFIX、配置备份和还原、网络运行状况检查、QoS和LACP等。简单来说，基于服务器自身，NSX就构建了完整的数据中心网络。

场景决定高可用程度

虚拟化的诞生，将每个操作系统所依赖的物理硬件特征全部虚化成了标准的虚拟硬件，那么，只要虚机文件还在，任何物理故障都不能阻挡服务快速恢复，因为标准的虚拟硬件可以不重装系统就运行到另一个物理载体上，这也是虚拟化环境具备高可用性的重要基础。虚拟化集群环境的这一资源切换技术由vMotion来实现。vMotion在线将CPU和内存的状态从一个物理机复制到另一个，保持业务连续的同时，也改变了虚机的计算载体，这是多么不可思议的能力。

但这项能力也存在制约因素——CPU的指令集。集群中的服务器并不会是一成不变的一次性采购，而不同年份购置的服务器，其VPUu也会或多或少有指令集的更新，新增的指令集也就决定了虚机不能从新服务器漂移到旧服务器。为了应对集群内CPU之间存在的差异，我们可以启用EVC功能，该功能需要指定集群内CPU系列的兼容度，也就是指定所有虚机都只在这一款CPU型号的指令集基础上运行，从而满足最大的兼容性，实现虚机从低配置CPU到高配置CPU的漂移。这样一来，拥有更多指令集的CPU特性就不会在任何虚机上体现，其实质是放弃了部分高性能能力。本文是觉得特别可惜的，因此，是否启用EVC也应由应用场景决定，或者放弃由新CPU向旧CPU漂移的能力，或者放弃新指令集的性能特征，亦或者将新旧CPU物理机编组到不同的集群。

有了vMotion做基础，HA不间断地检测群集中所有的ESXi主机，监控群集中是否有足够的可用资源，以便在检测到ESXi故障时能自动在其他ESXi上重启虚机，当检测到ESXi主机负载达到阈值，DRS将vMotion和HA融合在一起，根据ESXi主机的CPU或内存资源负载，动态地迁移虚机至较负载较轻的ESXi主机上。在此基础上，DPM更进一步侦测集群负载，在整体负载较低时选择ESXi主机并迁移其上的虚机到其他ESXi，继而关闭空闲的ESXi主机达到节能降耗的效果，当集群负载升高，DPM利用iLO、IPMI或LAN唤醒来增加ESXi节点。

除了上述主机和虚机层面的高可用，虚机之上的应用层也可通过FT来实现，Fault Tolerance会创建一个虚机完全相同的副本，主虚机和辅虚机执行相同顺序的x86指令，任一虚机发生故障则进行透明的故障切换，从而最大限度地延长该虚机应用的正常运行时间。不过，FT在实际使用中并不像想象中那么完美，实现FT的虚机只能有一个单核vCPU，承载两个虚机的物理机也必须一模一样，不能有虚拟光驱等设备，限制条件较多，而且多次FT切换之后，可能出现辅助虚机不能自动启动，有时重做FT提示配置跟FT不兼容等细节问题，实际使用时应多做测试验证以适应场景需求。