XenServer® 企业参考架构
概述
本参考架构定义了一种推荐的方法，用于设计、部署和操作 XenServer 以支持企业级工作负载。它为托管 Citrix Virtual Apps and Desktops™ (CVAD) 环境以及通用服务器虚拟化提供了经过验证的基础，重点关注可伸缩性、弹性以及操作简便性。
该架构围绕 XenServer 资源池作为扩展和管理的核心单元这一概念构建。每个资源池都设计为在单个数据中心（或一组紧密连接的数据中心）内运行，并支持可预测的高性能工作负载执行。通过添加额外的资源池，可以横向扩展部署，以满足不断增长的容量和组织需求。
设计原则
以下原则总结了设计方法：
- 资源池作为扩展单元： 在定义良好的资源池中部署和管理工作负载，并通过添加额外的池进行横向扩展
- 按设计实现工作负载隔离： 将资源池与特定的工作负载类型对齐，以确保一致的性能和操作行为
- N+1 容量模型： 保持足够的容量以容忍单个主机故障，而不会影响工作负载可用性
- 关注点分离： 明确分离管理、虚拟机和存储流量，以确保性能、弹性与安全性
- 明确的弹性策略： 将数据中心内部弹性与数据中心间灾难恢复视为不同的架构关注点
- 操作简便性： 仅在提供明确价值时才引入可选功能，避免不必要的复杂性
总之，这些原则为设计可伸缩、弹性强且易于操作的 XenServer 环境提供了一个一致的框架，同时能够适应不断演变的工作负载和组织需求。
该架构假定使用远程块存储、通过 Active Directory 进行集成身份管理以及通过 TLS 进行安全管理。可选功能，例如工作负载平衡 (WLB)、高可用性 (HA) 和灾难恢复 (DR)，可以根据工作负载要求进行整合，但每个功能都会引入额外的操作考量，必须明确规划。 本参考架构适用于需要可预测性能和强大操作控制的企业环境。它并未针对特殊场景进行优化，例如超大型单个虚拟机磁盘（>2 TB）或 GPU 密集型工作负载，这些场景可能需要替代设计或调整。
总之，本文档既是设计指南，也是操作框架，使组织能够以一致、可支持的方式部署 XenServer，同时保留随着时间推移扩展和发展平台的灵活性。
假设和范围
该架构基于对规模、基础设施和操作实践的一系列基本假设。
-
所有使用的硬件必须列在 XenServer 硬件兼容性列表 (HCL)中
- 每个资源池预计支持多达 1,000 个虚拟机，整体部署通过增加额外的池而不是无限期地扩展单个池来扩展，最多可达 200 个池。池中的所有主机都假定在紧密耦合的网络边界内运行，以确保对共享存储的一致和可靠访问
- 主机必须有足够的 RAM 来支持所需的工作负载和控制域以及任何性能缓存要求（请参阅 调整资源池大小），最大可达 6 TB
- 主机必须具有用于 XenServer 操作系统的本地存储（最小 46 GB，理想 70 GB），或从 SAN 启动的能力
-
存储假定通过远程基于块的系统提供，XenServer 使用基于 LVM 的存储库。效率和弹性主要由底层存储平台提供，包括精简配置（以在使用时启用主动分配）和多路径等功能。持续可靠的存储连接是关键要求。
-
网络遵循管理、虚拟机和存储流量之间严格分离的模型。为此，主机必须至少配备 2 个网卡和 2 个光纤通道连接，或 4 个网卡。这种分离与绑定的网络接口相结合，以提供弹性和吞吐量，同时避免引入不必要的依赖或性能限制的配置。
-
安全性和身份被视为设计的组成部分。管理通信使用 TLS 进行保护，并假定与 Active Directory 集成以进行身份验证和基于角色的访问控制。管理访问预计将遵循标准的企业安全实践，限制使用本地帐户并控制管理接口的暴露。
- 在操作上，资源池围绕 N+1 容量模型设计，允许工作负载在主机维护期间或单个主机发生故障时继续运行。更新和升级预计会定期应用，以保持可支持性和安全性。在需要灾难恢复的情况下，它被实现为协调的操作过程，而不是无缝或完全自动化的故障转移功能。
可选功能可在需要时集成，但默认不假定。这些包括：
- 工作负载平衡 (WLB)
- 工作负载高可用性 (HA)
- 跨数据中心的灾难恢复 (DR)
这些功能中的每一个都会引入额外的操作复杂性，应根据明确的工作负载和业务需求进行采用。
范围之外
此参考架构并非为所有场景设计，不应被视为通用解决方案。特别是，它不直接解决以下问题：
- 需要大于 2 TB 的单个虚拟磁盘的工作负载
- GPU 加速或依赖 GPU 的工作负载
- 需要跨地理分散数据中心实现无缝、主动-主动工作负载移动的架构
在这些情况下，此设计中的元素可能仍然适用，但需要额外的架构考量和调整。
定义
支持阅读和理解此参考架构的术语和定义。
| 术语 | 定义 |
|---|---|
| 数据中心 | 一组紧密部署并可访问远程存储的网络计算资源。所有连接都应具有低延迟、高带宽和高可靠性。特别是，XenServer 主机不得失去与存储的连接。计算资源可以配置为在数据中心内具有故障恢复能力，并且可以作为其他数据中心灾难恢复解决方案的一部分，但在正常运行期间应作为独立部署运行。这意味着不期望将工作负载定期迁移到数据中心之外以形成更广泛的弹性覆盖。部署在数据中心内的任何资源之间的网络互连应具有 <2 毫秒的延迟和 >=10 Gbps 的网络吞吐量。 |
| 近距离数据中心 | 多个数据中心，具有低延迟、高带宽和高可靠性的互连，预期它们将作为一个单一的逻辑数据中心运行。部署在这些数据中心之间的任何资源之间的网络互连应具有 <5 毫秒的延迟和 >=10 Gbps 的网络吞吐量。 |
| 地理分散数据中心 | 彼此之间距离较远的数据中心。此类数据中心应作为独立实体运行，每个实体都有自己的网络和存储。 |
| 升级 | 主要产品版本更改（例如从 XenServer 8.4 升级到 9） |
| 更新 | 在 XenServer 的特定单一版本中安装软件包，提供附加功能、错误修复和安全修复。 |
| 资源池（通常缩写为池） | 将主机分组并提供单一管理点以管理一组主机上的存储和网络的管理单元。有关更多详细信息，请参阅资源池 |
架构蓝图
对资源池的期望如下：
- 每个资源池设计用于运行多达 1000 个虚拟机。
- 每个资源池完全位于单个数据中心内或跨邻近数据中心。
- 每个资源池都提供一个特定的用例，其中所有工作负载在可用性和性能方面具有相似的特征。对于小型部署，混合用例是可能的，但在考虑资源池的负载平衡和故障模式时必须谨慎。
单一用例的示例包括：
- 用于 CVAD 部署的虚拟桌面
- 用于 CVAD 部署的应用程序服务器
- CVAD 基础设施
- 通用服务器虚拟化工作负载
每个资源池将具有以下属性
- 所有远程块存储均使用 LVM 协议。不建议使用 GFS2 协议。
- 池协调器管理的高可用性
- 所有管理通信均使用 TLS 1.2
- 可选： 用于工作负载虚拟机的工作负载平衡 (WLB)
- 可选： 工作负载虚拟机的高可用性 (HA)
- 可选： 灾难恢复 (DR)
- 可选： 已安装 XenServer Conversion Manager
注意：
通过在数据中心内部或跨数据中心创建多个资源池，可以扩展此设计，从而在需要的地方提供工作负载。
按照以下部分中的定义构建每个资源池。
核心资源池配置
在构建新的资源池时，最佳实践是根据需要配置具有网络和存储的独立主机，然后将其他主机添加到此池中。当其他主机添加到资源池时，它们将获得相同的配置。
配置基于角色的访问控制
将所有资源池连接到受信任的 Active Directory 域，以便轻松管理和审计 AD 用户和组，并控制对 XenServer 资源池的访问和权限。
注意：
除无法通过 AD 凭据进行身份验证的紧急情况（例如 AD 域控制器故障）外，请勿使用默认（root）帐户进行管理。
为主机预配证书
所有资源池中的所有主机都应具有预配的 TLS 证书，以用于管理网络。对于 CVAD 工作负载，主机需要通过其在 DNS 中的 FQDN 进行解析。
所有主机都必须预配证书；这可以是共享的通配符证书，也可以是每个主机的独立证书。
注意：
某些使用 XenServer API 的应用程序（例如某些旧版本的 Citrix Apps and Desktops）要求每个主机使用单独的证书，并且不允许使用通配符证书。有关更多详细信息，请参阅相关文档：
任何第三方连接到资源池都应使用 TLS 和 FQDN 来寻址资源池中的主机。
保护与资源池的通信
- 禁用端口 80
- 将 SSH 设置为 自动 模式，以便在管理工具堆栈失败时，SSH 能够自动启用
资源池网络配置
以下网络需要进行分离：
- 管理网络
- VM 网络
- 存储网络（如果使用基于网络的存储）
这种分离可以通过独立的网卡提供，也可以通过使用相同网卡的 VLAN 来实现。如果使用基于网络的存储，强烈建议出于性能原因使用独立的网卡。
管理网络和 VM 网络
管理网络和 VM 网络应在绑定网卡上运行，以提供弹性和吞吐量。
在可能的情况下，应将绑定配置为 LACP 绑定，以确保在连接丢失时获得最佳响应，同时最大限度地提高带宽可用性。这将要求交换机配置为匹配的配置。如果交换机无法配置为支持 LACP，则主动-主动模式对 VM 网络有利。管理网络可以使用主动-被动模式而不会产生任何影响。有关更多信息，请参阅 绑定类型。
在可能的情况下，交换机应与网卡交叉连接，以确保网络传输中没有单点故障，并且它们应使用独立的电源或冗余电源。有关完整详细信息，请参阅 网络最佳实践。
池中的所有主机在管理网络上都必须具有固定的 IP 地址；XenServer 不支持 DHCP 分配的主机 IP 地址发生变化的情况。如果使用固定的 DHCP 地址，则应确保 DHCP 环境可靠可用（例如，作为网络基础设施的一部分），并且不应由运行在依赖该 DHCP 服务器的主机上的 VM 提供。建议对基础设施使用静态寻址。
所有主机管理网络都需要允许连接到同步的 NTP 服务器，以确保其时钟保持一致；这应与为基于角色的访问控制提供计算机和用户帐户的 Active Directory 所使用的时间源相同，以确保不会发生时钟漂移并中断通信路径。这还将确保所有系统日志都具有一致的时间戳。
启用环境运行所需的完整连接要求列于 此处。
存储网络
当使用基于网络的存储时，最佳实践是使用存储的多路径支持，这需要独立的网络（即不同的子网）。这通常意味着使用单个网卡而不是绑定，并在每个网卡上配置适当的子网。请咨询您的存储提供商以获取进一步的建议。
资源池存储配置
应启用多路径。这必须在所有主机上单独设置，并且所有存储资源应至少有2条可用路径。这些路径应在网络/光纤通道基础设施中多样化。
LVM 是厚置备存储，因此 XenServer 将需要为创建的 VM 磁盘提供全部所需的存储量。这意味着即使只使用了这些磁盘的一小部分，每个磁盘和模板也将占用全部可用容量。
建议使用提供自身精简置备功能的 SAN，以确保高效利用存储。SAN 精简置备通过在数据写入虚拟磁盘时将磁盘存储空间分配给 VDI，而不是预先分配 VDI 的全部虚拟大小，从而更好地利用可用存储。管理员应使用 SAN 供应商提供的工具仔细监控存储使用量。
如果在 SAN 上使用精简置备，监控存储利用率非常重要；如果 SAN 容量耗尽导致无法进行进一步写入，这可能导致 VM 故障和/或数据损坏。
如果使用 MCS 为 Citrix® 环境置备工作负载，建议为此使用少量大型 LUN，因为黄金映像需要复制到所有 LUN 上，这可能会很慢，并使映像置备花费大量时间，从而延迟更新映像的推出。
弹性策略
XenServer 资源池及其存储资源在单个数据中心（或一组邻近数据中心）内运行。
这些资源池可以配置为能够抵御数据中心内的本地服务器、存储和网络故障。此外，资源池可以组合使用，以在数据中心发生故障并导致整个资源池丢失时提供灾难恢复功能。
这些将在下面单独考虑。
数据中心内的弹性
虽然数据中心内的工作负载可以通过下面描述的完整 DR 配置进行保护，但每个资源池内都有弹性机制，以确保资源的高可用性。这些机制旨在自动化并更频繁地使用，以防范更常见和局部性的问题。以下设施可用：
- 管理高可用性（通过在计划外中断期间自动协调器选举）
- 工作负载计算高可用性（通过在计划外中断时自动重启 VM）
- 存储弹性（通过存储多路径）
- 网络弹性（通过网络绑定和交换机配置）
为实现此目标，资源池预计至少以 N+1 个主机运行，其中 N 是运行工作负载所需的主机数量。这使得资源池能够在一台主机不可用的情况下仍以满负荷运行。
注意：
N+1 主机容量支持在不中断工作负载的情况下更新和升级资源池，从而方便地应用安全更新和功能增强。
这些功能将提供高度弹性的部署，该部署完全在数据中心内部或跨近距离数据中心运行。它不支持跨地理分散数据中心的弹性。支持此功能的唯一方法是通过下面描述的灾难恢复 (DR) 功能（请参阅 跨数据中心的弹性）。
可选功能
工作负载平衡 (WLB)
- 适用场景： 虚拟机工作负载在运行时具有显著不同且随时间变化的利用率模式，并且您希望通过自动建议和/或重新平衡来维持性能。
- 不适用场景： 工作负载高度统一（例如，许多类似的非持久性 VDI 虚拟机），其中初始放置和正常的生命周期操作已提供足够的平衡，或者迁移在操作上是不可取的。
- 操作影响： 增加了一个额外的设备用于操作和监控；包括一个每日维护窗口，在此期间 WLB 处理不可用。
WLB 可用于在工作负载使用情况随时间变化时保持最佳主机利用率和性能。
将设备导入资源池，并使用管理网络进行连接。工作负载平衡 (WLB) 设备可从 XenServer 下载页面 下载。
应使用设备的默认大小配置（2 GB 内存、30 GB 磁盘和 2 个虚拟 CPU）。
工作负载适用性
仅当虚拟机在其运行生命周期内工作负载需求动态变化时，才需要 WLB。如果使用 WLB，每次虚拟机停止并再次启动时，它都会立即为当前工作负载进行最佳放置，因此虚拟机只需在主机利用率变化时才需要移动。当用例提供了许多执行类似任务的相似虚拟机时，使用 WLB 的价值不大，您可以依靠初始虚拟机放置来提供工作负载平衡。
调整数据库维护窗口
WLB 设备每天执行例行维护。默认情况下，时间为 UTC 00:05。应将其配置为在资源池活动量低时发生，因为在此过程中，WLB 处理将中断长达 30 分钟。这不影响正常运行，仅影响放置优化决策；WLB 将在其维护完成后立即完成操作。
WLB 参数配置
许多配置设置可以保留为默认值。这将把 WLB 功能设置为向管理员提供建议，管理员将不得不应用这些操作。
此蓝图的默认和预期配置仅要求调整“临界阈值”和权重，以使资源池以最佳性能运行。这些可以通过使用进行优化，但一些建议的起始值如下：
-
CPU 利用率： 默认值为 90% 的临界阈值和最大权重。这将确保一旦主机 CPU 在过去 1.5 分钟内达到 90% 的平均负载，WLB 服务将评估虚拟机运行的备用位置。
- 如果您的虚拟机在较低的 CPU 利用率下性能受到影响，您可以调整此临界阈值，旨在尽可能地在所有主机上保持较低的平均 CPU 使用率。
- 建议的初始临界阈值：90%
- 建议的初始指标权重值：最重要
-
空闲内存： 在主机上保留空闲内存并不能获得特定的性能提升，因此迁移机器以保持内存空闲是不必要的开销。
- 建议的初始临界阈值：0
- 建议的初始指标权重值：最不重要
-
网络读写： 默认值为 25 MB/s。这意味着如果任何主机在读写方面利用了更多带宽，它将被考虑重新定位。除非您有一些虚拟机运行繁重的网络工作负载，并且避免对其他虚拟机造成影响是相关的，否则此参数不相关。
- 对于许多应用程序来说，这不是一个相关因素，权重应设置为最不重要的设置。
- 对于许多现代网络来说，这是一个非常低的值，如果此设置相关，我们建议将其设置为允许充分利用此带宽，然后再考虑迁移到另一个主机。
- 建议的初始临界阈值：可用带宽的 90%
- 建议的初始指标权重值：中等重要性
-
磁盘读写： 默认值为 25 MB/s。这意味着如果任何主机在读写方面使用了更多带宽，它将被考虑重新定位。除非您有一些虚拟机正在运行繁重的磁盘工作负载并且避免对其他虚拟机造成影响是相关的，否则此参数不相关。如果使用远程存储，那么除非网络带宽是瓶颈，否则这没有价值，因为对远程存储的任何影响都会影响所有使用该存储的虚拟机性能，无论它在哪台主机上运行。
- 对于大多数现代存储和网络，这是一个较低的值，如果此设置相关，应将其设置为更高的值，以允许充分利用带宽。此值应设置得足够高，以确保在不需要时，虚拟机在非工作时间的常规维护不会导致大规模迁移。
- 建议的初始临界阈值：可用带宽的 90%
- 建议的初始指标权重值：中等重要性
资源池的高可用性 (HA)
完整的 HA 文档可在此处(/zh-cn/xenserver/8/high-availability)获取
对于 XenServer 的高可用性，需要考虑两个要素
- 管理 HA：当资源池中的协调器主机意外中断时，自动维护管理操作的能力
- 虚拟机 HA：当资源池中的主机意外中断时，维护工作负载操作的能力
这两个方面都需要特定的存储和网络配置。这将在以下部分中介绍。
可用的存储 LUN 之一将被选作 XenServer 心跳 SR（有关此要求的完整说明，请参阅可用性心跳）。如果有一个以上的 LUN 可用，选择哪个并不重要。将从此 LUN 分配少量空间（<5 GB）以提供 HA 功能。
此参考架构旨在支持在单个主机意外丢失的限制内维护工作负载。“容忍故障数”设置应为 1。
注意：
使用 HA 时，请务必注意以下特点
- 资源池必须至少有 3 个主机
- 隔离是指强制隔离被视为故障或不安全的主机的机制，确保在虚拟机在其他位置重新启动之前，该主机无法访问共享资源（尤其是共享存储）。资源池越大，主机隔离的影响就越大，并且由于通信路径要求，发生隔离的可能性也越大。在这方面，对于主机数量超过 >16 的资源池应予以仔细考虑。
- 在进行主机/资源池维护操作期间，应禁用 HA，以降低在执行这些维护活动时发生意外中断的风险。
- 使用 HA 时，必须注意确保与 HA 状态文件 SR 的存储连接和网络连接不中断。这些连接的中断可能导致主机意外隔离，以保护资源池的操作。这意味着在对基础设施进行维护时，必须仔细考虑以确保连接不会丢失。
管理 HA 的替代方法
如果您正在使用 HA 来提供可靠、高可用的管理连接，那么还应考虑以下方法，以避免上述限制。
实施主机监控
将 XenServer 主机与第三方监控解决方案集成，以检测主机何时无响应。
手动恢复管理连接
如果无法联系到的主机是协调器且管理操作不可用，则资源池中的所有其他主机将进入紧急模式，并允许与其建立远程连接，以选举其中一个作为新的池协调器。这可以使用远程语言绑定来执行。下面提供了 xe CLI 和 PowerShell 的示例。
xe CLI：
xe -s <server_IP> -u <username> -pw <password> host-is-in-emergency-mode -> Confirm election possibility
xe -s <server_IP> -u <username> -pw <password> pool-emergency-transition-to-master -> Designate current host as new master
xe -s <server_IP> -u <username> -pw <password> pool-recover-slaves -> Reconfigure member servers to new coordinator
<!--NeedCopy-->
PowerShell：
Invoke-XenPool -XenAction EmergencyTransitionToMaster -> Designate current host as new master
Invoke-XenPool -XenAction RecoverSlaves -> Reconfigure member servers to new coordinator
<!--NeedCopy-->
VM 高可用性
工作负载平衡 (WLB) VM
此VM的重启优先级应设置为重启，以确保在意外中断后不会丢失任何WLB功能。它应该在第一个启动组0中。
其他VM
根据XenServer的具体使用情况，可能会配置额外的VM来使用VM HA。以下是一些用例的建议。
决策指南 (VM HA)：对于在意外主机中断后自动重启能显著提高服务连续性，并且池大小为N+1以吸收中断的工作负载，请使用VM HA。对于外部代理/编排已提供重启或横向扩展行为（例如，许多非持久性CVAD工作负载），或者重启顺序和依赖关系难以控制的工作负载，请避免使用VM HA。
注意：
在配置HA后添加到资源池的VM将默认为“不重启”。如果需要，在将VM添加到环境后，需要重新配置HA。
-
PVS和非持久性MCS VM： 不要为这些VM配置任何HA。确保这些VM设置为
Do Not Restart。其他VM应可用于为最终用户提供即时服务，并且Citrix Virtual Apps and Desktops将提供电源管理功能，以支持在最终用户需要时或通过自动扩展功能来支持预期需求时重启这些VM，请参阅AutoScale。这将为组合的Citrix环境提供更优化的结果。 -
MCS持久性VM： 这些应设置为“重启”。所设计的配置应确保在有1台主机停止服务（用于更新、维护或中断）时，池中有足够的RAM和CPU来运行所有VM，这样才能实现此配置。
-
通用服务器虚拟化工作负载（任何不用于运行Citrix VDA的工作负载）： 这些应设置为“重启”。所设计的配置应确保在有1台主机停止服务（用于更新、维护或中断）时，池中有足够的RAM和CPU来运行所有VM，这样才能实现此配置。VM可以配置为根据需要使用启动组和延迟，以确保工作负载按需重启。这可用于优先处理其他服务所依赖的工作负载，例如Active Directory、DHCP和DNS服务提供商。
跨数据中心的弹性
可选：
跨数据中心的灾难恢复 (DR)。如果需要，此参考架构可以支持DR，但需要额外的设计和操作考虑。
DR的决策指南
- 使用时机： 当您有明确的站点弹性业务需求、具备复制能力的存储平台以及需要辅助站点VM恢复的已商定恢复过程（RPO/RTO）时。
- 避免在以下情况： 您需要在站点之间频繁移动工作负载，或者您没有足够的运营能力来测试和执行故障转移/故障恢复流程。对于 CVAD，请勿假设虚拟机管理程序连接和证书可以在没有协调的 CVAD 灾难恢复设计的情况下无缝故障转移。
- 运营影响： 灾难恢复并非完全自动化；故障转移/故障恢复需要计划好的运行手册、对存储复制控制的访问以及定期测试。
此处描述的 XenServer 灾难恢复 (DR) 配置是一种弹性模式，预计将不常用于支持极端和计划外的基础设施中断。此操作并非自动化，恢复需要仔细规划和操作。灾难恢复模型允许在临时位置运行工作负载，该位置可能不是最佳部署位置，但将在中断期间支持关键业务运营。
XenServer 灾难恢复模型是一个复杂的解决方案，还有其他方法可以提供站点故障保护。例如，对于使用非持久性虚拟机提供服务的 Citrix 工作负载，可以将额外的虚拟机预配到恢复站点以提供临时服务。在使用 XenServer 灾难恢复功能之前需要考虑这些选项，因为它们可能更容易实施。
建议避免将灾难恢复用于 Citrix VDI 工作负载，除非您有适用于 CVAD 的合适灾难恢复解决方案。假设相同的虚拟机管理程序连接可以故障转移到 XenServer 灾难恢复站点是不安全的，因为网络和证书映射可能会使其不可靠。
为了降低数据中心故障和工作负载（或工作负载的关键部分）丢失的风险，可以使用辅助数据中心位置来提供灾难恢复功能。更多文档可在此处(/zh-cn/xenserver/8/dr.html)获取。
灾难恢复站点中的一个或多个资源池除了作为工作负载的恢复位置外，还可以用于其他工作负载，但您必须保持所需的备用容量，以便在需要时运行额外的这些工作负载。
当发生故障事件时，没有要求在灾难恢复站点中运行全部工作负载。可以恢复部分工作负载，直到主站点恢复完全运行，但是要求工作负载必须从 1 个资源池恢复到单个恢复资源池。工作负载不能分布到多个恢复池。
重要提示：
将主站点中 LUN 的数据镜像到灾难恢复站点的存储复制过程必须在 XenServer 工具集之外进行配置，并且负责故障转移的管理员必须能够重新配置此过程，因为他们需要中断和重置镜像作为与此过程相关的操作的一部分（有关详细信息，请参阅操作部分）。
构建此部署时：
- 用于虚拟机虚拟磁盘的所有存储都必须从主环境复制到备份环境
- 用于池元数据的所有存储都必须从主环境复制到备份环境
- 您的灾难恢复站点的硬件基础设施不必与主站点匹配，但必须使用相同的处理器供应商。备用资源池中必须配置足够的内存、CPU 和网络容量，以允许重新创建和启动所有必需的故障转移虚拟机。
- 恢复站点中的 XenServer 资源池必须与主站点处于相同或更新的版本和补丁级别（有关如何实现此目的的详细信息，请参阅跨部署的 XenServer 版本管理）。
操作模型
跨部署的 XenServer 版本管理
XenServer 部署由一个或多个资源池构建，跨一个或多个数据中心，以提供可扩展、健壮且安全的部署，能够大规模交付高性能工作负载。
这些部署可以提供测试和生产环境，并且可以构建一个工作流，以通过这些环境推出更改。
可选：
主机测试和工作负载测试阶段是可选的。参考架构支持有或没有这些阶段的操作。
主机测试和工作负载测试阶段不必是独立的阶段；它们可以合并。这可能是有利的，因为它减少了将更改推向生产所需的时间。XenServer 更新流是健壮且经过充分测试的，允许持续部署。为了保持安全性、健壮性和性能，最大程度地缩短更新到达生产环境所需的时间非常重要。
每个阶段的预期如下：
- 早期发布测试： 此阶段旨在提前了解更新并验证功能。此阶段中的主机配置为使用早期发布通道，该通道通常比普通通道提前 2 周提供对新版本的访问。此阶段中的主机必须具有到 Internet 的出站连接（直接连接或通过代理服务器），才能访问 XenServer 内容分发网络 (CDN)。
- 主机测试： 此阶段的目的是测试 XenServer 软件发布更新过程。版本可通过 Internet 从 XenServer CDN 获取，或通过离线通道交付机制获取。
- 工作负载测试/UAT： 此阶段允许使用类似生产环境的工作负载测试 XenServer 主机，以验证规模和弹性。版本可通过 Internet 从 XenServer CDN 获取，或通过离线通道交付机制获取。
- 生产部署： 运行生产工作负载的主机可以在完成之前的测试阶段后进行更新（直接更新或通过离线交付机制更新）。
注意：
离线更新可用于确保将预期版本的 XenServer 部署到 UAT 和生产环境。可以直接从另一个资源池同步更新，但是，如果存在已同步但尚未应用于源池的更新，则这些更新可能会应用于目标池，从而导致目标池上的补丁版本更高。
为了保持受支持状态，所有资源池都需要定期更新，并且更新时间不得超过 6 个月。
监控资源池
当资源池中任何主机或虚拟机发生警报时，这些警报会在 XenCenter® 的“警报”部分中显示。
这些警报也可以通过 SNMP 集成或电子邮件 SMTP 集成在外部监控工具中提供。
需要考虑两种类型的监控。
- 监控利用率，以确保快速识别并处理任何意外的容量问题。
- 监控系统事件，以确保基础设施正常运行且没有发生意外更改。
下面将详细介绍这些内容，以便在集成设计中加以考虑。
可以通过 此处 描述的 SNMP 功能与第三方监控产品集成，并提供集成到这些第三方工具中的警报。
注意：
将新主机添加到池中时，必须重新配置 SNMP 设置，以确保新主机包含在任何 SNMP 集成中（有关详细信息，请参阅 限制）。
监控使用情况
可以配置警报来检测 CPU 使用率过高等情况，有关详细信息，请参阅 性能警报。
以下是针对这些事件触发的 SNMP 陷阱中提供的数据示例。
2026-02-19 09:44:35 <UNKNOWN> [UDP: [10.71.64.14]:53876->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196826250) 22 days, 18:44:22.50 iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1 iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add" iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:eea63153-f96c-25f5-17b9-08ce49e7ccf4" iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "83a9c805-a172-f1b2-55d4-081ec180893b" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALARM" iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3 iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "VM" iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "681e4064-16cb-4d0c-9c2c-887623bc623f" iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:45:55Z" iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "The memory required by the control domain on \"Control domain on host: pm-demolab-3\" is about 5.7% of its allocated memory. Occasional performance degradation can be expected when memory swapping is forced to happen.
This alarm is set to be triggered when the memory required by the control domain is above 5.0% of its allocated memory."
<!--NeedCopy-->
监控系统事件
系统警报在此处描述(/zh-cn/xenserver/8/monitor-performance/alerts.html#system-alerts)
以下是针对这些事件触发的 SNMP 陷阱中提供的数据示例。
2026-02-19 09:43:39 <UNKNOWN> [UDP: [10.71.64.14]:46982->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196820650) 22 days, 18:43:26.50 iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1 iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add" iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:ca95e2da-06b7-9aa5-fa4b-ddf007a50c59" iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "525e459c-51bc-c71c-9c52-dcd747e9a84f" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALL_RUNNING_VMS_IN_ANTI_AFFINITY_GRP_ON_SINGLE_HOST" iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "Pool" iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "419d6735-5d11-56b1-8cdc-2853ce709a27" iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:44:59Z" iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "<body><message>Breach on VM anti-affinity rules</message><VM_group>3224f9d9-9492-06f7-3c92-da610cde33a8</VM_group><host>ce2a3c26-6bbc-4d23-8626-fba28d3dc651</host></body>"
<!--NeedCopy-->
远程日志记录
这主要用于支持协作。为确保在问题解决期间此数据的可用性，可以配置 syslog 转发。这样，在无法直接从主机检索日志，或者有任何理由怀疑主机上的日志可能已被篡改时，可以检索日志。
如果配置了此项，则必须在池中的所有主机上配置此项。
此数据会占用大量空间。此功能和数据的使用和保留由您根据内部安全策略自行决定。
容量规划模型
资源池大小调整
每个资源池应包含足够的资源，以便在 1 台主机出现故障时，资源池仍能运行全部工作负载。这将实现：
- 每次在 1 台主机上按需进行计划内停机
- 在不中断工作负载的情况下进行资源池更新
- 确保在 1 台主机意外故障时工作负载中断最小化
为实现此目标，预期资源池中的所有主机都具有相同的工作负载支持能力（即相同的配置、RAM、CPU）。这可能导致在停机期间 CPU 超额分配程度更高，但预计这种情况是短暂的，直到停机状况解决。
如果资源池中丢失了多于 1 台主机，将无法再维持所有工作负载，并且可能会出现工作负载中断，直到主机恢复。
注意：
如果主机在硬件更新/刷新等活动期间，在一段时间内不具备相同的容量，则应考虑具有最大内存的主机发生故障的情况
资源池容量计算
在此参考架构中，我们假设每个资源池都有特定的用途。因此，下面的计算假设资源池中的所有虚拟机都具有相同的规格。
Dom0 的大小为 32 GB RAM。但是，如果正在使用 PVS 加速器，则需要为每个 vdisk 增加至少 5 GB 以支持加速，并且必须在这些计算中考虑这一点。
输入
| 术语 | 定义 |
|---|---|
host_ram |
每台主机的总 RAM (GB) |
vm_ram |
每台虚拟机的 RAM 要求 (GB) |
host_cpus |
主机中可用的 vCPU 数量（这些是逻辑 CPU，因此包括线程） |
vm_cpus |
每台虚拟机所需的 vCPU 数量 |
hosts_total |
池中的主机数量 |
vm_disks |
连接到每个虚拟机的磁盘数量 |
vm_snapshots |
每个虚拟机预期的快照数量 |
dom0_ram |
为 Dom0 保留的内存（本参考架构为 32 GB） |
dom0_vcpus |
为 Dom0 保留的 vCPU 数量（本参考架构为 16 个） |
wlb_ram |
WLB 设备所需的内存（本参考架构为 2GB） |
wlb_vcpus |
WLB 设备所需的 vCPU 数量（本参考架构为 2 个） |
输出
| 术语 | 定义 | 公式 |
|---|---|---|
vm_host_max |
池中每个主机上运行的最大虚拟机数量 | (host_ram - dom0_ram - wlb_ram) / vm_ram |
vm_pool_max |
池中可运行的最大虚拟机数量 | vm_host_max * (hosts_total - 1) |
srs_total |
托管虚拟机所需的存储库数量 | vm_pool_max * (vm_disks + vm_snapshots) / 1000 |
vm_host |
主机上实际运行的虚拟机数量 |
vm_pool_max / hosts_total (参见注释) |
host_cpu_overcommit |
主机中运行所需工作负载所需的vCPU数量（这些是逻辑CPU，因此包括线程） | ((vm_host * vm_cpus) + dom0_vcpus + wlb_vcpus) / host_cpus |
注意：
在主机故障、维护或更新操作期间
vm_host = vm_pool_max / (hosts_total - 1)
示例
| 术语 | 值 |
|---|---|
host_ram |
1000 吉字节 (1 太字节) |
vm_ram |
16 GB |
host_cpus |
2个插槽，每个有32个线程核心 = 2 * 32 * 2 = 128 |
vm_cpus |
4 |
hosts_total |
8 |
vm_disks |
MCS 虚拟机 = 1 个 ID 磁盘，1 个操作系统磁盘，1 个 MCSIO 磁盘 = 3 |
vm_snapshots |
0 |
dom0_ram |
32 |
dom0_vcpus |
16 |
wlb_ram |
2 |
wlb_vcpus |
2 |
vm_host_max = (1000 - 32 - 2) / 16 = 60 max VMs per Hostvm_pool_max = 60 * (8 - 1) = 420 max VMs per poolsrs_total = 420 * (3 + 0) / 1000 = 1.26 SRs (>1 so need 2 SRs spread over 2 LUNS)-
正常运行：
vm_host = 420 / 8 = 52.5 VMs per host (round down to 52)host_cpu_overcommit = ((52 * 4) + 16 + 2) / 128 = 1.77 vCPU per pCPU
-
在单个主机中断或更新/维护操作期间：
vm_host = 420 / 7 = 60 VMs per hosthost_cpu_overcommit = ((60 * 4) + 16 + 2) / 128 = 2.01 vCPU per pCPU
注意：
不使用动态内存控制 (DMC) 来提供 RAM 超额分配。XenServer 在正常运行期间不支持此功能。这仅预期在计划的受控维护的短时间内使用，当没有其他选项可用于保持所需工作负载运行时。
如果超额分配过高，则需要减少池中的虚拟机数量，直到达到可接受的水平。