在虚拟化架构的核心部分，高可用性需求是其不可或缺的组成。很多地方都无可避免地存在高可用性方面的担忧。

　　首先，在物理架构中存在着物理服务器、网络和存储硬件层面的高可用性担忧；其次，当10个、20个或更多的虚拟机运行于同一个物理服务器或刀片上时，增大了用于承载虚拟机的物理架构的高可用性风险；最后一点，还要考虑运行于虚拟机内部子OS上服务的可用性。

　　在一定程度上讲，这样的高可用性需求时刻存在着，客户总是担心如果他们的服务器死机或者是服务无法启动时，企业将会面临的巨大损失。正是这些担忧使多数企业引入了虚拟化。而实际上，过去10年虚拟化已经获得极大认可，而同时它也引入了各种新的担忧。

　　急速提升的系统整合度

　　衡量虚拟化效率的核心部分就是服务器的整合度，包括现在流行的如何在更少的主机上集成尽可能多的虚拟桌面。单个主机可以支持的数量越多，每个虚拟机的均摊成本也随之降低。

　　虚拟化带来的不只是系统整合，虽然部分企业总是追求更高的整合度，但是他们同时也在环境中加入高可用性技术，以防护所选择的平台可能会发生的故障情况。

　　整合度年年都在提升，但是高可用技术的进步却没能保持同步。两者之间的差距也在一年年增大。高可用技术已经远远不只是增加物理资源（CPU/内存）以及让管理程序可以支持更多的地址空间来管理增加的物理资源容量。

　　当提到高可用时，企业的固定思路是通过简单购买某种技术来解决他们的问题。但是尽管厂家再三提示产品不是万能药，客户依然习惯沿着这个方向寻找。

　　经常被忽视的问题是，由于可用性被破坏而引起的系统故障原因中，人为错误和硬件故障的概率是相当的。因此，当我们建设高可用方案时，必须同时考虑到可能引起系统故障的硬件问题和软流程方面的操作不当。更为糟糕的是，在企业花费了大量的金钱用于购买软件或硬件高可用解决方案后，却无法在关键时刻发挥作用。这样，会导致灾难性后果。

　　注意力过于集中在高可用性技术本身，可能会导致从一开始用户就选择了错误的技术来解决自身问题。在作出正确的决定之前，企业应该更多考虑如何采用最好的办法来解决问题，而不是纠缠于无休止的POC测试中。

　　虽然有些乏味，但是在一开始应该进行的是正确评估过程而不是某个产品的安装和配置方法。只有经历了合理的评估，才不会发生用错误的技术去解决问题的情况。

　　我经常可以看到客户通过调整某种技术，努力使其可以解决某些非典型问题，然后反过来抱怨这项技术并不好用，这就好比一个不称职的工人一边抱怨他的工具不趁手，一边用螺丝刀去钉钉子用锤子去松螺母一样。

　　高可用问题的正确解决方法

　　问题不是发生在技术本身，而是使用技术的人身上。坦率的讲，当IT人员（包括ISV、零售商、分销商和顾问）错误地混淆了高可用技术和灾难恢复技术时，往往很难走出困境。另外，通常还要面对来自商业因素上的压力，受迫于用户节省费用的要求而选择用产品A去解决问题Z。但，抛开这些客观因素不谈，当缺少正确的初始化评估过程时，焦头烂额的情况会经常出现。

　　我曾经见过客户试图通过VMware的HA技术来创建扩展集群系统。市面上并不缺乏存储厂商的成熟产品可以销售给客户实现该功能。

　　例如NetApp的MetroCluster和EMC vPlex这样强大的产品。VMware HA的设计出发点是用来解决单一站点内的物理服务器失效问题，它从未计划用于横跨远距离多个站点的高可用解决方案中。

　　然而，几乎每周我都被问到相同的问题：它是否可行？这个问题本身的答案是：可以，通过调整和改变是可以使它这样工作的，但是最大的问题在于这么做的成本如何？

　　在完成了艰苦改造工程后，这项技术能满足您在RPO和RTO上的要求吗？RPO和RTO两个概念用于衡量灾难发生后进行恢复时您希望得以保留的数据状态，以及恢复到该数据状态所要花费的时间长短。

　　永远不要用做灾难恢复

　　还有另一种极端情况，我常听到某些用户说他们使用扩展的VMware HA集群作为灾难恢复方案的一部分。当他们这么说的时候，常常会忽略VMware HA从未作为DR解决方案的一部分去进行开发的现实问题。

　　为了让VMware HA工作，从它的技术需求看，需要使两个站点在同一个网络环境下——这种方式被称为“扩展的VLAN”——，而且要共享存储支持。而扩展的VMware HA集群正常工作的前提之一还要求两个站点之间的物理距离不能太远，这样的条件会使得容灾站点的真正功能大打折扣。因为如果容灾站点之间的距离不够远，它们可能会在同一次灾难中一起毁灭。

　　最后一点，可能我们还会发现这样的配置方法跟VMware的DR产品Site Recovery Manager之间会存在冲突。当调整和改变某项技术的基本设计后，可能同时我们会不知不觉地带来很多如何跟来自该厂商的其它技术相兼容的问题。

　　某些客户说过他们并不需要VMware SRM这样的DR解决方案，因为现有的虚拟机在灾难发生时可以实现在线迁移（vMotion）。如果我们深入研究这种方案不难发现，两个站点之间相隔很近，而第二个站点由于距离原因永远无法被认证为真正的容灾中心。

　　另外，他们选择性地忘记了尽管这种方式被称为远距离迁移，但是需要事先规划停机时间来实现，这对于真正的灾难来说是不现实的。

　　我们经常可以听到企业宣称用户的数据库服务需要达到零停机时间，也就是说在任何情况下都要保证不会有数据丢失。当然作为一种未经过分析的个别需求，这样的说法还是很常见的。而真正的高可用需求和这种理想环境相比还是有一定差距的。

也因此，在某些不切实际的用户那里，关于高可用性的讨论经常变得和要求100%安全性问题有些类似。尽管大家都承认没有这样的安全级别，还是会为一些功能去买单。同样的情况也发生在高可用性问题上，用户经常提出一些超出实际情况的需求，同时也带来了不必要的投入。

　　当我在面对这些不合逻辑的“零停机时间”需求时，会首先询问客户他们之前使用的系统以及曾经遇到的停机事件。当他们描述完停机带来的影响以及如何去尝试重新启动服务的过程后，我会进一步询问以了解这些事件对前端业务带来的实际影响，包括在事件发生时及后续的影响。

　　多数案例中，最后我都可以劝说客户认识到他们并不需要完全零停机的高可用方式。相应的，去选择建设更加合理的“几个9”（5个9等同于99.999%）的高可用体系。这指的是在正确的地方使用了正确的技术后，可以达到99.999%的有效运行时间。

　　对于虚拟数据中心工作人员来说，需要了解100%可用的系统多数情况下是一个不值得追求的目标。在实际中，稍低级别的可用性就足够了，因为用于完成系统维护和补丁升级等工作的计划停机窗口在数据中心里是不可避免的。底线是，如果您不能在一开始对提供的服务希望达到的价值水平进行很好定义的话，就无法去衡量某个应用或服务是否已经达到正确的高可用级别。

　　从服务可用性衡量，很明显VMware的SRM、HA、FT这样的解决方案是不能满足需求的。原因就在于这些技术都不是基于服务水平考虑的。设计的初衷是为了给虚拟机提供可用性保障，或保护主机和站点不受停机影响。

　　虚拟化厂商一般都不会提供对上层子操作系统及服务级别的高可用性保障，这并不是在批评谁，而是一种共识。为了保持独立性，多数虚拟化供应商对提供操作系统内服务的高可用性方面持保留态度。事实上，他们认为可以保持跟操作系统的独立性是一种优势，从而可以避免在虚拟机层面跟某个操作系统绑定或是排斥。如果尝试要单独通过虚拟化工具提供5个9的可用性，就成为又一个错误应用的案例。

　　实际上，需要三方面的协作实现：

• 操作系统内的服务提供商将会有自己的高可用解决方案。这种情况并不普遍，但是某些ISV可以支持他们的客户在容量和可用性两方面进行应用扩展。
• 操作系统供应商提供了免费的高可用工具。
• 通过购买独立系统安装到子系统中实现比前两种方案更高的可用性。这三种方式往往伴随着额外软件的购买、附加的配置以及一定程度的多厂商合作。某些时候，客户考虑到节省成本和降低系统复杂度的原因会不愿意选择这种方案。

　　每当虚拟化厂商发布新的软件时，虚拟化委员会都要问同样的问题：是否新的功能扼杀了应用集群的可能性？提供对可用性的支持限制了某些服务必须被同时引入，而一些虚拟化厂商并不情愿去涉及跟子操作系统相关的内容，看起来这一领域的“圣杯”不太可能被找到。

　　这种状况和近年来备份领域内的迅猛发展形成鲜明对比。现在虚拟化层上完成的备份技术已经发展的跟安装到子操作系统内的备份代理功能相仿。

　　高可用领域内的第三方公司

　　充其量，更加可能的情况是虚拟化供应商在虚拟机内提供API接口，从而使得第三方公司产品可以跟虚拟化层更好地集成，共同完成对子操作系统承载服务的高可用性支持。一个很好的例子就是最新发布的VMware vSphere 4.1,在VMware HA中存在一个称为“应用程序监控”的选项。它可以支持诸如DoubleTake和NeverFail等第三方公司的高可用产品去调用VMware HA功能。

　　虚拟机的高可用工具最近也获得了足够多的关注，因为大量的虚拟机开始应用于核心生产业务领域。多数虚拟化供应商现在都可提供某种类型的集群解决方案，支持运行关键业务的主机发生故障时在其它物理节点上重启虚拟机。

　　例如，VMware的High Availability方案，Microsoft改进了其Clustering Service来支持虚拟机的重启，Citrix拥有其独有的Citrix XenServer HA集群方案。通常，这些技术失效的原因是由于最低要求没有达到而引起的，而且在部署后没有正确地测试过。我们可以把这些需求分解为如下的简短清单：

• 虚拟机存储于共享存储设备上——VMware 的VMFS/NFS卷，Microsoft Clustered Shared Volume或Citrix HA。
• 虚拟机故障切换发生在同一网络内。
• 虚拟机网络和用于支持高可用服务的心跳网络都是冗余的
  用户经常无法达到这些简单的基本需求。由此而导致发生错误的切换（在不应该切换的时候却启动了），通常这种现象称为“split brain”。

　　相反的，在故障真实发生时，某一个或更多的虚拟机故障切换却失败了，由于某一组人员把虚拟机存放在了本地存储上，或者是在虚拟机将要启动的新主机上网络系统不存在。看起来这是由于无视最佳实践和变更管理流程的存在而导致的。例如，完成日常的访问时需要执行多个步骤完成新虚拟机的创建过程，很多时候采用的最便捷的变更管理方式。因为对于业务单元来讲，全部参照流程的做法显得很官僚化。

　　为了避免这些问题，需要尽量减少人为因素以及在用户获得自己的虚拟机之前需要进行手工设置的内容。这也就意味着跟上一代虚拟化相比需要引入更多的自动化和流程化作业。

　　对于任何高可用解决方案的评估，我一直主张在应用于生产系统前先进行插入式测试，而在安装的时候可以采取分段进行。很多子系统中提供的高可用服务使得我们可以在不影响生产的情况下进行测试，这降低了测试的风险和减少所需的停机时间。而且，很多虚拟化厂商的HA系统已经开发出对应的软测试方案，可以让用户了解到在最坏的情况发生时现有的配置是否可以正常工作。