虚拟化极大地提升了服务器硬件的利用率，而且为工作负载的部署、迁移带来了更大的灵活性，但虚拟化也存在潜在的缺陷。目前一台服务器上可能运行了10台、15台甚至更多的虚拟机，如果服务器硬件出现故障或者遭到破坏，大量工作负载将会受到影响。因此服务器硬件、hypervisor和虚拟机的容错性与可靠性变得更加重要。让我们来看看与虚拟机高可用性有关的一些常见问题。
虚拟机集群选项
集群的概念是在两台或多台服务器上复制工作负载，并确保副本之间的同步。如果主集群服务器（节点）发生故障，受影响的服务器将被隔离在集群之外，第二个实例能够无缝接管。源服务器恢复后，能够重新加入集群并与其它实例重新进行同步。在这个故障转移的例子中，集群发生故障切换后只有一个实例处理所有的流量而其他实例处于备用状态。
另一种集群方式是负载均衡。集群中的所有服务器都处于活动状态，负载的每个副本仅处理部分流量。节点发生故障后同样会从集群中隔离，其他实例会重新分担流量以处理负载。这两类传统的集群概念都可以直接应用于虚拟环境，现有的集群软件比如Windows Server Failover集群同样支持hypervisor和虚拟机。验证虚拟化的支持程度、升级集群软件感知虚拟环境同样很有必要。
传统的服务器集群软件还有其他选择。例如，Stratus Technologies公司的everRun MX以及Vision Solutions公司的Double-Take Availability 7.0。这些工具独立运行，为虚拟化平台比如微软Hyper-V或VMware vSphere上的虚拟机提供复制及同步功能。
考虑虚拟机的容错性时有两个重要的问题。首先明智并审慎地使用集群。请记住虚拟机架构的灵活性会增加代价，关键业务才值得这么去处理。其他重要性较差的工作负载通常可以使用非集群技术比如快照进行保护。第二，了解容错性主要是为了应对硬件故障，因此避免虚拟机的多个实例运行在同一个物理服务器上至关重要。因此，容错性工作负载可能会和自动迁移或者负载均衡工具发生冲突。可能有必要设置迁移规则以明确指定副本能够迁移到哪些主机、不能迁移到哪些主机。
使用虚拟机快照
集群和快照是两个不同的概念，某些用于保护工作负载的第三方工具有时会混淆这两个概念。容错技术（比如集群以及虚拟机复制）用于保持工作负载的可用性。如果虚拟机的一个实例出错，另一台服务器上的副本实例会立刻接管，用户甚至不知道集群节点已经发生了故障。对不能容忍服务坏掉的应用程序***采用集群模式。
和集群不同，快照捕获并保存工作负载在特定时间点的状态。这意味着肯定存在RPO。虚拟机从快照中恢复出来同样需要时间，因此也存在RTO。虽然能够频繁地执行快照并进行快速恢复——存在较短的RPO和RTO——但在恢复快照时工作负载仍处于不可用状态。
由于非关键业务虚拟机能够容忍短暂的宕机，通常将快照作为数据保护的解决方案。通常，快照一般集中存放在本地SAN中，但如果需要额外的数据保护层（比如避免自然灾害或战争等对当地设施造成毁灭性危害），可能会将快照复制到远程SAN中。
***，要在集群和快照之间做出选择必须考虑个别的工作负载及其对业务的重要性。
通过硬件提高虚拟机的可用性
提高虚拟机可用性的一个重要战略就是关注底层硬件的容错性。如果服务器不发生故障，其上的负载也就不会发生故障。组织更新硬件时可以考虑服务器提供的容错功能。
例如，Inel***的至强处理器现在提供了内部数据总线检查机制，能够增强处理器内部数据的完整性，还能够检测并更正处理器内部的一些bit错误。新处理器检测特性能够利用管理软件工具产生报告记录软错误并用于后期评估，因此管理员能够做出更明智的决策，在问题真正出现之前对系统进行修复或者更换。
在系统层面考虑硬件冗余。例如，冗余电源一直是企业级服务器的标准配置。拥有10、12乃至更多核心的处理器为工作负载提供了额外的计算资源（如果其中一个核心发生故障，负载将在同一服务器上的其他核心上重新启动）。
内存的热备份特性能够在空闲的内存模块上重建故障内存模块中的内容。相比之下，内存镜像在备用的内存模块上复制内存内容——如果一个模块出错，内存镜像会进行接管（这和RAID 1很像）。
其他服务器组件应该包括冗余元素。例如，网络接口卡可能包括三个或者四个网口。不仅提供了额外的带宽以支持多个带宽密集型负载，还允许将某些负载故障转移到其他端口。
可用性是企业级工作负载的一个重要属性，但是组织应该采用最适合工作负载性质的技术，而不是过度保护太重要的工作负载或者对关键业务采用常规的保护方式。无论采用哪种虚拟机高可用性策略，一定要对其进行测试以验证确实达到了预期效果。不要等到灾难真正发生时才发现系统可用性存在意料之外或者无法接受的缺陷。
