高可用性虚拟化的部署

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

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

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

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

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

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

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

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

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友