Translated message

A translation of this page exists in English.

RHEL 高可用性集群的设计指南 - VMware 虚拟机作为集群成员

已更新 -

内容

概述

适用的环境

  • 带有高可用性附加组件的 Red Hat Enterprise Linux (RHEL) 7、8
  • 使用 VMware 平台进行虚拟机托管
  • 注意：本指南可能侧重于适用于这些产品的最新版本的功能。

有用的参考和指南

简介

本指南向管理员介绍了红帽的建议、参考和注意事项，这些在设计在 VMware 虚拟机上运行的红帽高可用性集群时可能很有用。

虚拟化/主机管理

虚拟化管理建议：使用 vSphere + vCenter 服务器

原因 ：

  • 提供多个功能来提高主机集群和虚拟机集群的可靠性 - 请参考下面的其他功能建议。
  • 与使用 vSphere Hypervisor 手动管理主机相比，对失败条件的反应可能更为简单和快速 - 在新主机上快速恢复虚拟机，检测失败的主机。
  • 红帽侧重于 RHEL 高可用性开发和测试中的 vCenter Server 配置和功能。

虚拟化管理替代战略：手动管理 vSphere Hypervisor (ESXi)

注意事项 ：

  • fence_vmware_soap STONITH 方法仅像每个主机一样可靠 - 当主机不可用或无响应时，其他虚拟机将无法使用这个方法来隔离其缺少的对等虚拟机，集群操作将被阻止。
  • VM 集群可以配置为使用主机的电源供应来作为辅助 STONITH 方法 - 当主机变得无响应时，可以通过其主机的方式隔离缺少的对等主机。
  • 如果没有 vCenter 服务器，手动恢复失败的虚拟机可能会较慢，使 VM 集群处于降级成员资格时间更长。 设计具有足够容量的虚拟机集群，以便在主机失败后使用足够的成员进行操作。

虚拟化管理替代战略：vRealize Suite

注意事项 ：

  • 红帽没有评估 vRealize Suite 管理虚拟机的 RHEL 高可用性集群的适用性，作为 vCenter Server 或 vSphere Hypervisor 手动管理的替代方法。
  • RHEL 高可用性不提供任何针对 vRealize Suite 的特殊功能或 STONITH 方法 - 环境必须与典型的 RHEL HA 的以 VMware 为目标的功能兼容，如 STONITH 的 fence_vmware_soap 或 fence_scsi 。

使用 vCenter Server 的建议：高可用性 vCenter 服务器

其它详情 ：

  • 为 vCenter 服务器提供高可用性。 请参阅：kb.vmware.com - 支持的 vCenter 服务器高可用性选项。
  • 为获得最大可靠性，在多站点 RHEL 高可用性集群中提供多站点高可用性 vCenter 服务器和虚拟机。请参阅下面：RHEL 高可用性配置 部分中的多站点注意事项。

原因 ：

  • 高可用性 vCenter 服务器提供了更好的 fence_vmware_soap STONITH 方法的可靠性
  • 高可用性 vCenter 维护管理员在故障后对主机和虚拟机管理的访问权限。 在这些情况下，这个访问对于恢复或管理受该故障影响的 RHEL 高可用性机器可能至关重要。

使用 vCenter 服务器的建议：vSphere HA

其它详情 ：

  • 启用主机监控

原因 ：

  • 带有主机监控的 vSphere HA 提高了 fence_vmware_soap STONITH 方法的可靠性
  • 带有主机监控的 DRS 和 vSphere HA 提供快速恢复虚拟机，以防止 VM-cluster 在失败后保持在降级状态。

使用 vCenter Server 的建议：创建 vSphere DRS 集群

其它详情 ：

  • DRS 自动化级别 ：使用 Manual 或 Partially Automated - 不使用 Fully Automated。

原因 ：

  • 为要在 + DRS VM-host 关联性上运行的虚拟机提供多个主机允许在主机失败后快速将虚拟机恢复到一个新位置，而不是将虚拟机集群保持在降级成员资格状态。

虚拟化主机注意事项：主机数量

建议 ：为每个集群虚拟机提供单独的主机，并为故障转移/维护活动提供多个主机

  • 单个主机故障应该只对虚拟机集群有最小的影响
  • 额外的故障转移主机允许在主机失败后快速恢复虚拟机，同时仍不必在主机上加倍虚拟机，即使主机停机时间延长。

替代配置 ：提供足够的主机，以便没有主机有 50% 或更多集群虚拟机

  • 如果 50% 的虚拟机共享一个主机，则单个主机失败可能导致大部分集群瘫痪

替代配置 ：仅提供两个主机或允许 50%+ 虚拟机共享一个主机

  • 仅对不太关键的工作负载依赖此配置，其中手动干预，以恢复/恢复集群是可以接受的。
  • 在带有 lms 算法的 RHEL HA 集群配置中使用 qdevice，使集群在 50% 或较少的活跃成员资格中存活下来 - 详情请查看以下集群设计部分。

不建议 ：单主机设计 - 仅用于测试/开发目的。

虚拟化主机建议：主机基础设施冗余

其它详情 ：

  • 设计由单独的基础设施支持的主机 - 电源、服务器机架交换机等。
  • 为实现额外的可靠性，请将主机分散到不同的设备或站点
    • 使用跨站点分布主机时，请查看以下部分中的 RHEL HA 集群多站点设计和注意事项

原因 ：

  • 主机共享电源或网络硬件会导致单点故障，这会中断所有 RHEL HA 成员，导致受管应用程序中断。

主机环境设计建议：网络冗余

其它详情 ：

  • 对于每个群集成员互连网络，应用程序网络，以及用于访问 vCenter 服务器/ vSphere Hypervisor 的网络（使用 fence_vmware_soap）：对 vSwitch 提供冗余的 uplink 端口。
  • 对于群集成员互连网络，可以提供替代的辅助网络，并与 RHEL HA 的 RRP 功能（冗余环协议）结合使用。

原因 ：

  • 集群成员资格互连链接中的冗余对于避免成员资格中断或分割非常重要，这可触发应用程序中断和恢复。
  • 使用 fence_vmware_soap STONITH 方法时，必须维护对 vCenter 服务器或 vSphere Hypervisor 的访问，以便在成员不可用时不会阻止恢复。
  • 应用程序/客户端访问网络的丢失可使其用户无法访问集群的服务。

虚拟化主机配置注意事项：集群传输协议

注意事项 ：

  • 不同的 RHEL HA 传输协议有不同的网络需求。 选择哪个最适合您的集群，并考虑其主机网络配置。 请参阅：探索功能 - 传输协议 和 设计指导 - 选择一个传输协议。
  • 如果使用 udp 传输 - 需要网络上的多播功能 - 考虑 VMware 多播过滤模式。 请参阅：docs.vmware.com - 多播过滤模式
    • 基本多播：如果物理网络有正确的多播转发功能，这应该对高可用性集群也适用。
    • 多播窥探：ESXi 主机之间的物理交换机应该启用了 IGMP 窥探。确保 vSphere 的查询时间间隔被设置为小于物理交换机上的任何路由表超时。

虚拟机配置

VM 分布建议：将虚拟机分布在尽可能多的主机上

其它详情 ：

  • 使用 vCenter 服务器：使用 DRS VM-host 关联性在主机之间分布虚拟机，并提供故障转移后仍尝试保持虚拟机的辅助优先级主机。
  • 使用其他管理策略：在主机间分布虚拟机，并在发生主机或虚拟机失败时有一个通知计划和一个如何/在哪里恢复虚拟机的计划

原因 ：

  • 在同一主机上运行虚拟机会使集群面临因单个主机故障而丢失多个成员的风险。
  • 在主机间分布虚拟机使集群避免因单个故障而导致大规模中断。

虚拟机管理要求：防止虚拟机在集群中处于活跃状态时进行实时迁移

其它详情 ：

  • 请参阅：支持策略 - 虚拟化集群成员的一般条件
  • 如果使用 DRS 虚拟机-主机关联性（如上面建议中所述），则会阻止实时迁移。
  • 如果手动管理跨主机的虚拟机分布，或者不使用 DRS 虚拟机-主机关联性 - 确保策略和实践在虚拟机处于活动状态时防止任何实时迁移。 在迁移任何虚拟机之前，始终停止 RHEL HA 集群服务(pcs cluster stop)。

原因 ：

  • 实时迁移在虚拟机处理过程中引入了一个暂停，这可能会中断高可用性成员资格（通常在真实生产环境中观察到）。 这个暂停是无法预测的，配置 HA 来完全避免它是很困难的。
  • vMotion 的实时迁移采取特殊措施来在其新主机上更新虚拟机多播组注册。 红帽还没有对这个问题进行评估，来确定 RHEL 高可用性的 udp（多播）传输协议是否与这些措施兼容。
  • 实时迁移可能会导致集群中的任何静态 STONITH 配置主机 <-> VM 映射不正确。 即使有计划在迁移前或之后更新 STONITH 配置，在迁移的前端或后端都会有一段时间 STONITH 设置不正确，如果虚拟机变得无响应，STONITH 设置可能会失败 - 这可能会阻塞集群操作。

VM 资源配置注意事项：存储设备

注意事项 ：

VM 系统资源配置注意事项

请参阅 ：设计指南 - 成员资格布局和成员系统规范

RHEL 高可用性集群配置

一般成员资格布局注意事项

请参阅 ：设计指南 - 成员资格布局和成员系统规范

STONITH 建议： fence_vmware_soap 或 fence_vmware_rest 作为主要方法

其它详情 ：

原因 ：

  • 在无需管理员手动干预的情况下将集群恢复回其完全成员资格时，电源隔离比存储隔离（如 fence_scsi）更可靠。
  • fence_vmware_soap 与高可用性 vCenter 服务器结合可以允许隔离成功，即使主 vCenter 服务器失败了。

STONITH 建议：fence_scsi 作为辅助方法

其它详情 ：

原因 ：

STONITH 注意事项：虚拟化主机电源作为辅助方法

其它详情 ：

  • 将 VM 集群配置为使用控制主机电源 - fence_ipmilan,fence_apc_snmp,fence_cisco_ucs,fence_ilo4...等的回退 STONITH 方法。
  • 重要信息：一定有一个永久的 VM 主机关联性或虚拟机到主机的一致的手动分布 - 因此 STONITH 可以配置为为给定的虚拟机正确关闭正确的主机。 无法使虚拟机分布与 STONITH 配置保持一致，可能导致数据损坏或其他冲突。
  • 请注意，这让虚拟机集群能够关闭主机，而其上可能还有其它虚拟机在运行。
  • 通常只建议用于没有 vCenter 服务器的部署 - 这里 fence_vmware_soap 不太可靠，因此有一个备份方法非常有用。

仲裁建议：使用 qdevice

其它详情 ：

原因 ：

  • 在出现成员故障或链接中断的场景下，提高了集群的可靠性
  • qdevice 允许集群在比典型的"大多数获胜"配置更多的成员失败后存活下来
  • 在成员资格分割中，qdevice 为仍具有外部连接性的成员授权，因此可以为客户端或外部用户提供服务。

多站点设计注意事项

注意事项 ：

  • 如果针对 跨越多个站点的单个成员资格 - 请注意，在 VMware 环境中，可靠的跨站点集群 STONITH 是一项挑战。

    • fence_vmware_soap 和 fence_vmware_rest 依赖于到 vCenter 服务器或 vSphere Hypervisor 的网络连接性，因此站点间链接中断可能会阻止跨站点 VM 集群成员的隔离。
    • fence_scsi / fence_mpath 可能会受到缺少针对多站点部署的存储复制产品的 SCSI-PR 功能的限制。 咨询存储厂商指导，以了解 SCSI 持久保留是否可以与其产品一起合理地处理。
    • 红帽建议使用 具有 booth 票据管理器协调多站点故障转移集群 来尝试修改用例，以便在主动-被动系统中工作。
    • 如果使用 跨多个站点的单个成员资格，如果 fence_vmware_soap 无法到达其目标，请计划让管理员进行可能的手动干预来恢复集群。
    • 高可用性 vCenter 服务器配置可能有助于 STONITH 可靠性。
    • 强烈建议使用 qdevice 来允许集群智能解决拆分成员资格。

  • 使用 具有booth 票据管理器设计协调多站点故障转移集群 可以实现多站点故障转移，而无需跨站点隔离。 这些可能更适合于 VMware 多站点部署。

    • booth 配置针对主动-被动应用程序。
    • 需要在多个站点中同时处于活跃状态的主动-主动应用程序需要一个跨站点的成员资格，需要一个可靠的隔离方法来在站点间工作。
    • 在这些协调集群中，qdevice 也很有用，用来获得更高的可靠性，而无需切换到另一个站点。

Comments