WindowsServerHyper-V高可用与灾难恢复技术解析

### Windows Server Hyper-V 高可用与灾难恢复技术解析 #### 1. Windows Server 2012 R2 集群仲裁模型 在 Windows Server 2012 R2 中，集群仲裁模型有了显著变化。它摒弃了以往基于投票分配方式和仲裁资源类型的不同模型。在该版本中，每个节点都拥有一票，并且始终会配置见证资源，但见证资源仅在需要时才会发挥作用。 Windows Server 2012 引入了动态仲裁机制，这一机制有助于确保在节点因不可用而失去投票权时，集群能够尽可能长时间地保持运行。而 Windows Server 2012 R2 在此基础上增加了动态见证功能，它可以根据集群中节点数量的奇偶性来改变见证资源的投票权。 | 特性 | 描述 | | --- | --- | | 动态仲裁 | 节点不可用时，保证集群持续运行 | | 动态见证 | 根据节点奇偶性调整见证资源投票权 | #### 2. Hyper - V 的迁移类型 Hyper - V 的迁移主要关注虚拟机在不同 Hyper - V 主机之间的移动能力。在集群环境中，由于所有节点都可以访问相同的存储，虚拟机可以在任意节点之间高效地进行实时迁移，只需复制节点之间的内存和状态信息。 Windows Server 2012 引入了无停机迁移虚拟机存储的功能，结合实时迁移技术，实现了“无共享实时迁移”能力。这意味着虚拟机可以在任意两个 Hyper - V 主机之间迁移，无需共享存储或集群，且不会造成虚拟机停机。 无共享实时迁移虽然不能替代故障转移集群，但它提供了最大的灵活性，允许虚拟机在独立主机之间、集群之间以及独立主机与集群之间进行迁移。 以下是 Hyper - V 迁移类型的总结： - 集群内实时迁移：高效复制内存和状态 - 无共享实时迁移：无需共享存储和集群，无停机迁移 #### 3. 集群补丁更新策略 为了在最小化对工作负载影响的前提下对集群进行补丁更新，需要采取合适的策略。由于集群中的所有虚拟机都可以在任何成员节点上运行，因此在对节点进行补丁安装和重启之前，应使用实时迁移将所有虚拟机迁移到其他节点，这样可以避免对虚拟机可用性产生影响。 Windows Server 2012 的故障转移集群提供了“集群感知更新”功能，只需一键操作，即可在不影响虚拟机可用性的情况下对整个集群进行补丁更新。对于 Windows Server 2012 之前的集群，SCVMM 2012 也提供了自动化的补丁更新能力。 操作步骤如下： 1. 确定需要更新的节点。 2. 使用实时迁移将该节点上的虚拟机迁移到其他节点。 3. 对于 Windows Server 2012 集群，使用集群感知更新进行补丁安装；对于之前的集群，使用 SCVMM 2012 进行自动化更新。 4. 完成更新后，将虚拟机迁移回原节点或其他合适的节点。 #### 4. 灾难恢复的必要性及基础概念 现代组织拥有各种内部、合作伙伴和客户使用的应用程序。这些应用程序从“锦上添花”但并非业务必需的类型，到一旦不可用就会导致公司运营停滞的关键业务应用程序不等。即使是关键业务应用程序的短暂停机，也可能在多个方面给组织带来损害，具体如下： - **财务损失**：无法执行正常业务功能导致收入减少。 - **声誉受损**：公开可见的停机事件会削弱外部各方对组织的信心。 - **合规风险**：可能违反监管要求。 为了确保关键业务应用程序的持续可用性，不仅需要在主数据中心通过高可用性技术保障，还需要在备用位置通过灾难恢复技术提供支持。灾难恢复需要将应用程序相关的数据复制到备用位置，并提供运行应用程序和连接的计算与网络资源。 在规划灾难恢复时，首先要明确哪些应用程序对组织至关重要，这需要业务部门的参与。确定关键业务应用程序后，还需要了解其依赖的应用程序和服务，因为在系统停机或灾难发生时，如果只保护关键业务应用程序而不保护其依赖项，解决方案将无法正常运行。 例如，一个典型的业务线应用程序可能运行在一个或多个应用服务器上，它可能依赖于在单独基础设施上运行的 SQL 数据库，通过面向互联网的企业反向代理发布服务，并需要 Active Directory 进行身份验证。为了使该业务线应用程序正常运行，所有这些依赖服务都必须可用。因此，在规划高可用性和灾难恢复时，需要以相同或更高的保护级别保护目标应用程序所依赖的应用程序和服务。 以下是灾难恢复规划的关键步骤： 1. 与业务部门合作，确定关键业务应用程序。 2. 识别关键业务应用程序的依赖项。 3. 制定保护关键业务应用程序及其依赖项的策略。 #### 5. 异步与同步复制 灾难恢复需要确保应用程序数据在灾难恢复位置可用。这可以通过将数据存储在两个位置都可访问的地方（如公共云），或者更常见的是，在两个位置都存储数据，并使用复制技术使副本数据与主（实时）数据保持同步。 复制模式分为异步和同步两种： - **异步模式**：允许事务在主数据源上提交，而无需等待事务发送到副本或得到确认。具体的异步复制机制可能有所不同，但关键在于主数据源可以独立于副本接收和确认数据而继续工作。这种模式在主副本上提供了最佳性能，但在故障情况下存在一定的数据丢失风险，因为数据在主数据源上提交后才会在副本上提交，甚至可能尚未发送到副本。 - **同步模式**：确保在主数据源上的事务得到副本的确认后才会提交。这种模式可以保证没有数据丢失风险，但由于需要等待副本的确认，会产生额外的延迟，从而对性能产生一定影响。主数据源与副本之间的延迟越高，