可靠性是众多企业日常运行所关注的重点。毫无疑问，对关键应用程序的干扰将对用户、客户以及业务伙伴的生产和收入造成重大损失。企业必须实施高可用性计划以减少由软件、服务器、网络甚至外部运营商带来无法预料问题所造成的影响。

　　高可用性（HA）技术可以充分利用虚拟化所提供的灵活性，但是虚拟化本身并不是一个解决方案。更强大的可用性综合了虚拟化的工具和更传统的方法，其中包括仔细的规划、设计以及对你的虚拟环境的连续监控。一旦你对虚拟数据中心中高可用性的基本概念有了了解，那么你的下一步就是要想方设法熟悉和实施高可用性方法了。

　　针对高可用性的基础设施规划

　　在一个虚拟环境中建立高可用性通常需要对基础设施进行充分的设计和管理。从项目一开始，正确的设计就是非常重要的，因为必须针对关键应用程序部署冗余硬件。例如，一个交易数据库可能需要配备两个以上的服务器以及对LAN和SAN的冗余访问。其目的就是要消除应用程序及其用户之间的故障点。

　　总之，最好是从一开始就规划和部署高可用性基础设施，并为每一个物理主机分配一个冗余虚拟机（VM）。否则，你就有可能要在之后某个时间对生产环境进行架构变更，而这将带来稳定性和性能方面的风险。

　　“除非你真的喜欢定期重建整个基础设施，否则你最好在一开始就用正确的方法做好正确的事，”Kroll Factual Data（一家总部位于科罗拉多州Loveland的商业信息供应商）的核心技术架构师、微软MVP Christopher M. Steffen说。但是，对于那些不太重要的应用程序来说，在虚拟机发生故障之后在同一台物理服务器上重启一个虚拟机则是可以接受的。对于众多运行日常业务的应用程序来说，虚拟化所提供的重启和实施迁移的灵活性是对可用性性能的一个显著提升。一台虚拟机可以在发生故障后的数分钟内重启，而一台非虚拟机则可能会经历一个较长的停机时间了。

　　管理工具和程序变化

　　虽然虚拟化几乎没有因为高可用性而改变（当然如果真的有的话）基础设施的设计考虑，但是从顶层出发考虑用于管理高可用性虚拟基础设施的软件和工具的改变则是很重要的。

　　“你的管理工具套件对于你弹性需求是极为重要的，”Steffen说，他以微软公司系统套件这类可扩展工具的重要性为例，该工具主要用于实现简单配置、故障转移以及迁移。在高可用性中的一个显著发展趋势就是出现了容错（FT）工具，这类工具非常适合于虚拟化。两个例子包括Marathon科技公司的EverRun系列软件产品和VMware公司vSphere的容错功能产品。

　　专家警告说，虚拟化中的容错功能只应根据需要使用。“有人认为那就是高可用性的未来，一切都将是容错的，我会告诉他们，他们错了，”Burton集团公司（一家总部位于犹他州Midvale的IT研究咨询公司）的高级分析师Chris Wolf说。Wolf认为，如果没有一个令人信服的业务需求，那么公司根本不会为无处不在的容错或冗余物理服务器的普及而买单。

　　网络连接也产生了新的弹性问题。本地服务器和存储设备的冗余是现成的，也是易于实现的，但是糟糕的网络连接性往往会让最积极的故障转移或集群策略也显得一无是处。

　　“我们的网络连接是每天都在接受着压力测试的，”Steffen说，他解释道，物理服务器是易于更换的。“但是如果我们失去了与我们所有主要供应商的网络连接，我们就完了，我们根本无法正常地完成任何业务。”Steffen建议管理员应对冗余网络连接和持续测试故障转移/故障恢复机制做好规划。

　　也许，虚拟化高可用性中最重要的但也是最不受欢迎的改变是重点的改变。高可用性在很大程度上是与技术相关的，但是其重点却正转向正确而合适的程序。
　　
　　通过正确而合适的程序是可以轻松实现虚拟环境中的可用性的。我们根本无需担心在可移除式驱动器上的文档副本与PC硬盘驱动器上的副本是否一致。同样，管理员也不再需要担心虚拟机副本是否是一个完整的机器映像。

　　只要有一个稳定的虚拟机副本，它就可以在主机上重启而无需担心配置或应用程序测试等问题。不再需要花费大量的时间精力来让机器正常运行。与之相反，采取正确的程序就可以快速而高效地恢复虚拟机。

　　操作人员的人为错误将会破坏可用性

　　高可用性中最常见的问题主要是人为错误，疏忽和自以为了解基础设施设计的错误假设。例如，一个公司可能需要24/7的全天候互联网访问，但是其冗余连接及流量负载能力从未经过测试，因为管理员担心这类测试有可能导致对现有用户的干扰。他们只是假设冗余访问是正常运行的。

　　“现在当灾难来临时，管理员必须启用该冗余连接，结果却发现其配置不正确或者其容量未经扩展无法满足正常运行的需求，”Steffen说。“由于人为错误或错误假设所造成的故障要远比我们估计的故障高得多。”

　　网络架构师经常会在他们的设计中忽视简便性的重要性，从而造成测试的复杂化以及在安装、配置、连接等等环节出现越来越多的问题。在一个高可用性网络结构中应考虑一个冗余的LAN交换机。现在，每个端点都有两个可能的交通路径，而故障的关键点也被移除。如果使用了第三台冗余的LAN交换机（每个端点将拥有三条潜在的交通路径），那么网络将变得复杂而难以布线，他们需要绞尽脑汁增加第三台交换机，事实上额外的复杂性将累及系统的弹性。

　　部署虚拟机则是另一个主要的人为错误。虚拟化允许在物理服务器之间进行虚拟机迁移而无需过多的直接管理控制。但当两台冗余虚拟机位于同一台主机服务器时，这可能就是一个问题。在这种情况下，共同的主机服务器将成为一个潜在的单点故障。

　　“我需要确保虚拟基础设施是了解虚拟机是如何分布的，从而就能够避免那些虚拟机在同一时间位于同一台主机上，”Wolf说。

　　从32位平台迁移至64位平台将进一步造成基础设施升级工作的复杂化。例如，Steffen报告，在他的组织中从32位微软虚拟软件到64位Hyper-V的迁移工作进行得很顺利。但是，灾难恢复站点所采用的32位硬件将直接使公司陷入不设防的窘境；64位虚拟机将无法在旧版的32位数据恢复服务器上正常运行。

　　“他们不必是完全相同的，但至少你的平台必须是比较一致的，”Steffen说。“这是我们始料未及的状况之一。”总之，尽早规划高效的灾难恢复是非常重要的。企业经常创建大型虚拟机，然后在虚拟机上运行操作系统和应用程序而让它们不堪重负。这一切都是能够正常运行的，但问题往往出现在拍快照的时候，或者更糟糕的是在站点之间复制虚拟机的时候。

　　“你可能会认为GB或TB级无用复制数据是毫无必要的，”Wolf说，“我建议最好是创建精益虚拟机，并最好现在就为复制做好规划，即便复制并不属于数据保护的范畴。

　　高可用性是否能够正常工作？测试高可用性

　　实现虚拟化并不是说可以不需要对可用性进行测试。实际上，可用性问题很少涉及硬件或虚拟化平台。通常，问题更多地是发生在安装、配置以及源于糟糕的策略制定或程序。
　　
　　虽然可以安装自动故障转移，但缺少一个简单的路由表。在另一种情况下，一个技术人员可能在某个基础设施处做出了一个看似无害的修改，同时又未能正确记录该修改。如果这一修改导致了问题的产生，那么就有可能没有办法撤销产生问题的修改操作。

　　Steffen叙述了一个近期发生的事件，在事件中他就无法切换至冗余的WAN供应商。“我想，这可能是一个特别的程序问题，”他说。“但是，事实证明是他们（WAN供应商）修改了IP地址，从而造成他们被挡在防火墙外。”

　　诸如此类的错误都会破坏可用性，这也进一步凸显了明确安装和变更管理步骤的重要性。“一个”人是潜在的单点故障，因此应当避免只安排一名高级技术人员来管理基础设施。任何初级技术人员都应该能够完成诸如安装、配置以及恢复这样的任务。

　　实际的测试方法也是多种多样的。目前还没有一个测试高可用性基础设施的公认方法。虽然如此，还是有一些指导原则可以有助于提高你的测试质量。从审查故障转移、迁移以及容错开始，通常需要采取一定量的物理交互，例如开关服务器或不间断电源（UPS），或断开服务器网络控制器的LAN电缆。

　　无容错的虚拟机在发生故障后应当在一个可接受的时间段内转移至另一台服务器。如果采用了集群或容错部署，应用程序可用性就应当能够实现无间断运行。

　　Wolf建议进一步测试网络流量负载下的迁移性能，即尽可能模拟正常应用程序（用户）的流量场景。

　　该测试可为管理员提供测试期间和测试后应用程序可用性的最准确结果。例如，如果在有三台服务器的集群中有一个节点发生故障，那么剩余的两个节点必须仍然满足应用程序正常运行的服务等级需求。

　　同样，了解决定虚拟机故障转移位置的标准也是很重要的。在某些情况下，可使用虚拟化管理工具提前规划故障转移位置。其他情况下，可根据CPU或内存使用水平等因素自动选择故障转移位置。

　　请确保，当你部署虚拟机时，你还同时考虑了应用程序的所有计算需求。例如，Citrix XenServer考虑了I/O使用率。如果迁移一个I/O密集型应用程序而不考虑目标服务器上的可用I/O资源，那么虚拟机的性能就有可能变糟或虚拟机性能可能变得不稳定。

　　“如果虚拟机被部署在错误的服务器上，”Wolf说。“一开始我并不会知道发生了问题，直到虚拟机不在那里，虚拟机无法满足其服务等级需求。这样就必须安排一名管理员重新分配虚拟机，“可用性测试必须重点关注虚拟化分布以及重启虚拟机的方法。一些环境可能会按照一个简单的次序重启：节点1、节点2、节点3等等。但是实际的重启次序可能对应用程序可用性有着举足轻重的重要性。

　　假设，某个业务使用了一个依赖后端数据库的应用程序。在应用程序使用数据库之前，数据库必须处于运行状态。如果应用程序首先重启，而数据库还不可用，那么应用程序就可能会发生故障或导致中断。

　　对于测试协议的情况，还没有公认的可用性测试的频度标准，它取决于基础设施和你的业务需求。但是，更为常见的是采用交错测试以便于使关键系统（核心应用程序、开关、备用发电机）能够比非关键系统更频繁地被测试（或任何部署变更和更新的时间）。

　　Steffen在应用防火墙补丁时经历了这一情况。“它破坏了防火墙的高可用性。我们立即就察觉了，并密切地监控防火墙，“他说，同时指出其后果可能是灾难性的。“你必须测试关键的东西。”

　　不断改进中的高可用性

　　随着虚拟化部署的不断深入普及，次重要应用程序的可用性将得到相应的改善。目前，在服务器发生故障期间，受延长停机时间影响的非关键应用程序也将以虚拟机形式出现。由于虚拟机可以实现故障转移并在另一台服务器上重启，长达数小时的停机时间将显著地减少至数分钟。

　　硬件成本也随之大幅降低，这也使得企业能够对更多的应用程序部署高可用性技术，而在之前由于费用问题是无法做到这一点的。例如，一个公司可能会以超过两台服务器的价格购买两台服务器搭建一个以上的集群来提高最重要应用程序的可用性。

　　管理员必须将服务器硬件置于掌控中，并管理好其虚拟机的故障转移行为。未来成功的可用性取决于所采用的管理工具以及管理服务器的方法。工具总是能够提升特性、功能以及与其它虚拟化平台的互操作性。

　　Wolf预测，工具将不再是简单监控虚拟机和服务器运行状况的“黑盒子”，它们将更深入地监测应用程序的运行状态。毕竟来说，企业还是更多地关心应用程序和它们的数据，而不是底层的硬件。管理工具的改进同样也会促进服务器的改进，例如高速缓存和内部芯片组功能。