10个不宜放置于虚拟化环境中的项目

ZDNET至顶网CIO与应用频道 08月19日 专栏：虚拟化毋庸置疑地为企业IT带来了举不胜举的好处——成本节约、系统整合、资源利用效率提升、管理能力改善——但是要记住重要的一点，支持业务需求才是IT部门存最重要的工作。在不进行详细分析与考量的情况下，就对所有的系统进行虚拟化，并不是一个好策略。

任何虚拟化战略的第一步，都应该包括如何处理预想中的灾难恢复——如果CIO把所有内容都放在一个处于开放环境下的容器里。那就想象一下如果整个环境宕机的话需要怎么做——网络设备、动态目录域控制器、邮件服务器等等。假如管理员已经设置了将会把自己锁定在系统管理权限之外的循环依存项的话，会发生什么？再例如，如果配置VMware vCenter管理服务器依赖于动态目录进行身份验证的话，只要有一个可用的域控制器它就可以正常工作下去。但是，如果虚拟化域控制器出现故障，问题就来了。当然，也可以为vCenter设置一个本地登录帐户，或者在虚拟系统和物理系统之间分割域控制器，但是上述情况是一个很好的例子说明如何有可能会让CIO自己陷入困境当中。

以IT自由撰稿人Scott Matteson的经验，很多东西并不那么适合于虚拟化环境，以下是其罗列出应该保留在物理环境中的10项内容：

1、 任何带有或要求带有加密锁的物理硬件

这一点毫无疑问，而且被无数次地重复，但这就像是消防安全提示一样，只因为它就是一个口号而显得并不那么重要。不管你相信与否，现在仍然有一些项目仍然要求有附加的硬件（例如加密锁）。某些项目许可要求有这种硬件才能正常工作（为了防止盗版）。

举个具体例子：一个客户的HVAC系统运行在一个很老的台式机上。加热和冷却的程序要求使用一个串行连接的加密锁以监控温度和风扇等。我们尝试在VMware ESXi 4.0环境中虚拟化这套系统，使用串行端口实现直通，甚至是使用USB适配卡，但不管用。（听说这种功能在ESXi 5中是起效的）讽刺的是，使用VMware工作站而不是ESX环境（允许直通功能）的时候，这种方法起到了很好的作用。但是在PC上托管虚拟机时候作用不大，因此需要对物理系统重新做了迁移。

这条规则也适用于像防火墙这种使用ASIC（应用专用集成电路）以及使用GBIC（千兆接口转换器）这样的网络设备。目前还没有找到关于这些如何切换到虚拟环境的相关信息。即使能找到到些东西可以让它工作起来的话，冒着宕机的风险和管理难题、做这种一次性的设置真的就值得吗？

2、 要求极高性能的系统

占用RAM、磁盘I/O以及CPU（或者要求有多个CPU）的计算机或者应用，也许并不是虚拟化的理想选择。这种例子包括，视频流、备份、数据库和事务处理系统。因为这个原因，在日常工作中都应将其视为物理设备。但是一个运行在主机系统一个层中的虚拟程序或者虚拟机，总会因为所涉及的开销而在某种程度上牺牲性能，而且在物理环境下这种牺牲很可能被均衡了。

CIO也许会尝试使用一台只运行一个程序的主机或者服务器专门解决这个问题，但是这就折损了虚拟化允许你在一个专用物理服务器上运行做个图像的优势。

3、 不允许进行虚拟化的带有许可或支持协议的应用及操作系统

这一点是不言自明的。在进行虚拟化之前，CIO应检查一下许可和支持协议，然后可能会发现只根据这个协议是无法做到虚拟化的，或者假如继续下去的话，当遇到需要电话支持的时候就会出现一些问题。

如果这是一个例如打印铭牌这样的小程序的话，支持协议不包括（或者未提及）虚拟化版本，CIO就需要权衡风险再决定是否继续进行。如果是任务关键型应用的话，那么还是保留在物理环境中吧。

4、 任何没有经过测试的关键任务

如果没有在虚拟平台上做过测试的话，就不要急于迁向虚拟化。即使需要花费时间，也要先测试了再说。对源进行拷贝，然后制定测试计划，确保所有程序或者服务器如预期的运转。如果需要的话，在下班时间进行这一切。毕竟，在晚上11点发现问题总比在早上9点强。将原始源代码保持离线（仅仅是关掉，但不要断开/删除/卸载），直到确保如预期那样朝着新目标进发。

5、物理环境所依赖的东西

对于任何虚拟机来说，有两个故障点——虚拟机本身和它的主机。如果有软件运行在这样一种虚拟机上：在一套读取器上刷卡之后可以解锁办公室的门，那么只有当虚拟机和母系统都是处于正常运准的情况下才能允许操作。

想像一下星期一早上8点，办公室外面站着一大群人，“门禁卡不管用了！”CIO会推测是系统中的某一环出现了问题。现在怎么办？管理者会希望主密钥不是放在了数据中心的密码箱里，否则就会打电话给安全软件供应商了。

6、任何虚拟环境所依赖的东西

就如开篇部分所提到的，一旦发生不可避免的宕机情况，循环依赖（如虚拟域控制器被要求登录到虚拟环境中）就会将系统置于极大的风险之中——就算处在集群和冗余环境中，这一天也会到来的。在这里，电力是一个很大的影响因素。如果像Scott Matteson一样居住在美国东北部的话，就一定也同样经历了过去五年中次数不断增多的停电事故。

把这一条从前一条中单独拿出来，是因为这需要不同的思考方式。有鉴于CIO需要构想出物理环境的布局，以保持摄像机的正常运行，这需要设计出个性化的虚拟环境，包括主系统、虚拟映像、认证、网络、存储甚至电气连接。将每一个条目从这个集合中拿出来，随后设想一下会产生什么样的影响。设置冗余物理环境（例如另一个域控制器）来保护基础设施。

7、任何必须要保证安全的内容

这条与第5条有些许不同。如果对任何含有管理者不想让其他员工接触到的安全信息的系统进行虚拟化，也许就会构成一定安全风险。管理者可以在虚拟机器上设置访问许可，防止其他人能够进行控制，但是如果那些员工有能力控制主机系统，那么这种控制手段也许就被规避了。他们也许依然能够在任何地方复制VMware文件，进行关闭服务器等操作。

这一点并不是说CIO应该怀疑自己的IT员工，但是应该制定指导准则或规则制度，禁止除IT团队之外的任何人涉及对相关程序/数据/操作系统的控制权限。

8、任何对同步有时间点要求的东西

在虚拟环境中进行时间同步——例如，VMware可以通过VMware工具应用同步虚拟机器与主ESX Server的时间，当然操作系统自身也可以进行时间同步配置。但是如果操作系统出现遗漏，或主ESX Server的时间是错误的会发生什么呢？曾经，一组虚拟镜像必须要有GMT（格林威治标准时间），其处理软件才能运行，但是EXS主机时间是错误的，这着实引发了一阵令人沮丧的折腾，以及试图分析出虚拟系统时间错误原因的工作。

通过确保所有物理主机使用NTP将时钟标准化，这个问题可以得到控制，但是错误依然会发生，重启后设置会丢失或遗忘。在其他场合，这个问题已经在数个VMware EXS领域中发生，例如在安装补丁之后。如果系统必须绝对得到正确的时间，将其置于虚拟化环境之外也许是个更好的选择。

9、正常运行的桌面机

在推进VDI（虚拟桌面基础架构）的过程中，一些公司可能会有些头脑发热地将“应该虚拟化的东西”理解为“任何东西都可以虚拟化”。如果办公室里有不少用了两三年的个人电脑，就不要浪费时间将它们转变为VDI系统，并用瘦客户端来替代他们了。这种作法不会产生任何收益或节省开支，事实上这是对虚拟化的无效滥用。

10、任何已经混乱无序或过于陈旧的东西

很多人将物理设备转变为虚拟机，随之它就可以被复制或存储了。在某些情况下，这种做法是有用的，但是在其他特殊情况下，这种做法实际上只是让一些杂乱无序的旧操作系统维持了更长的使用时间而已，它们早已超过了应有的使用期限。例如，一个已经使用了几年的Windows XP电脑被转换成了虚拟镜像。照这种情况来说，该系统已经历了无数次的软件升级、删除内容等操作。又有几年过去后（以及伴随着更多的系统变更），无疑的是，现在这个XP系统将表现出严重的CPU过载及反应时间过慢等问题。其实，更好的决策是从头创造一个全新的映像，并以有序方式安装必要软件，而不是让这个千疮百孔的操作系统转为一个虚拟系统重新上线。

这同样适用于那些称之为“令人伤感”的东西。公司服务器上的标签打印软件是不是已有15年的时间没换过了？将它丢掉然后说再见吧。不要受潮流诱惑将其转为虚拟机器以防万一（突然发现“以防万一”算得上IT界同时最有用也最有害的三个词之一了），除非它根本不可能被其他软件替换掉。但是，如果是这种情况，请不要忘记回去查看本文第3条。

物理机托管虚拟系统

加入这条是为了提醒CIO们，必须做好购买物理硬件的准备，并要了解服务器的规格、性能、存储需求、网络连接性能，以及其他能让服务器——随之是虚拟系统——保持在巅峰状态的细节问题。CIO要确保明白主机所需求的东西和映像所求的东西之间的差异和分歧，并持续关注虚拟化服务商所提供的最新升级。

结论

随着岁月变迁，这些规则也会发生变化。对于计划在物理和虚拟计算中取得最佳平衡的问题来说，好的说明性资料、训练和对环境的深入了解是至关重要的。虚拟化是个好东西。但是如果物理主机出现宕机，其影响会是致命的——这甚至可能会让人渴望回到“每项功能一个物理服务器”的时代，仔细分析一下怎样做会对公司和用户有用，并决定用何种最佳的方式解决可能会出现的突发问题吧。