(虚拟化-不适合做虚拟化的应用.docxVIP

不适合虚拟化的10个项目虚拟化毋庸置疑地为企业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一样居住在美国东北部的话，