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

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

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

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

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

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

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

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

    每一个企业都为计划、部署和管理可用性开发了自己的最佳实践和过程。在创建过程时，确保覆盖了以下五点，保证保持正确的方向。

    1、一种方法并不适用所有人。为应用匹配可用性等级，或者更为特殊的是，为正在保护的虚拟机匹配可用性等级。将决策和业务需求和目标保持一致。为每一个应用匹配完全相同等级的可用性是不对的，这样会过度保护非核心应用，而且浪费资金。

    2、确保冗余虚拟机分离。虚拟化允许任何VM在几乎所有服务器上运行；然而你应该在相同的物理服务器上阻止多种虚拟机非故意迁移或者失败。迁移工具的配置阻止了单点失败。

    3、监控和负载平衡服务器性能。用监控工具密切关注每一个物理服务器的性能。平缓且长期的计算资源短缺可能预示着服务器使用的增长，应该通过升级解决。突发性资源短缺可能预示着非期望的动态迁移本身会失败。

    4、定期测试可用性战略。当你没有计划好时，问题通常会突然出现。任何可用性实现都应该定期测试，拉拉插头或者断开有线网络或者服务器断电，确保工作负载能故障处理或者冗余虚拟机持续工作。

    5、为灾难恢复安置虚拟机。并非用非必须的附属条件创建标准的VM,创建更小的VM,也就是说对于支持各自的应用足够大就行。这样能够让故障恢复、重启、快照和同步发生的更快，而且不需要任何多余的存储空间。[page]
    高可用性是否能够正常工作？测试高可用性

    实现虚拟化并不是说可以不需要对可用性进行测试。实际上，可用性问题很少涉及硬件或虚拟化平台。通常，问题更多地是发生在安装、配置以及源于糟糕的策略制定或程序。

    虽然可以安装自动故障转移，但缺少一个简单的路由表。在另一种情况下，一个技术人员可能在某个基础设施处做出了一个看似无害的修改，同时又未能正确记录该修改。如果这一修改导致了问题的产生，那么就有可能没有办法撤销产生问题的修改操作。

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

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

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

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

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

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

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

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

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

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

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

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

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。