硬件部署注意事项

查找在使用受支持的虚拟机管理程序的虚拟机上部署 Zoom Node ZPLS 模块的说明

本页概述了在受支持的虚拟机监控程序上，在虚拟机中部署 Zoom Node ZPLS 模块的过程。它提供了针对不同硬件能力量身定制的详细配置选项，确保满足各种运行需求时的最佳性能。

受支持的虚拟机监控程序

客户必须在运行于受支持的虚拟机监控程序上的虚拟机中安装 Zoom Node 软件

作为 Zoom Node 工作负载，ZPLS 模块必须安装在运行 Zoom Node 平台的虚拟机上，位于一个 受支持的虚拟机监控程序。有关 Zoom Node 作为产品的更多信息，请参阅 附录.

客户可以根据硬件能力选择两种配置选项之一

ZPLS 模块支持两种配置，具体取决于虚拟机的硬件能力。如下所示：

	配置选项 1	配置选项 2
硬件规格	8 个 CPU 16 GB 内存 80 GB 硬盘	16 个 CPU 16 GB 内存 80 GB 硬盘
总注册数	2000	5000
最大并发呼叫数	240	480
每秒呼叫数	2	4
每秒注册数	60	400

如果启用了生存能力的站点内的终端数量超过该站点的部署能力，ZPLS 模块将按照先到先得的原则处理注册。建议客户添加额外模块，或使用 Zoom Phone Policy 设置 本地生存模式 以优先确定哪些用户支持生存故障切换。

模块扩展与弹性

ZPLS 模块支持集群，以实现额外的扩展和/或弹性

客户可将 ZPLS 模块分组，每个站点最多 20 个模块（或每个账户总计 100 台 Node 设备），以获得额外的冗余或扩展能力。

此功能目前处于 Beta 版，需要通过技术支持工单来启用。

扩展会提高站点受支持的设备容量

增加 ZPLS 模块数量会按线性方式增强每个站点的能力，每增加一个模块都会提升一次。例如，如果一个模块总共支持 5,000 个注册，那么部署五个模块将把支持量提升到 25,000 个注册。

冗余会增加额外模块以提高弹性，但不会扩展站点的设备容量

当 ZPLS 模块用于冗余目的时，冗余模块不计入受支持分机总数。相反，这些模块处于“热备用”状态，仅在主模块故障时接管。例如，一个主模块和一个冗余模块总共支持 5,000 个注册，因此如果主模块故障，冗余模块不会因超出其支持上限而被过度分配设备。

带有扩展和冗余的 ZPLS 部署示例

为方便起见，以下示例演示了带有额外扩展和冗余的部署。

示例:

某医院需要为生存能力支持最多 10,000 个已注册分机。为实现这一点，该医院正在部署四个 ZPLS 模块。

前两个模块各自可支持 5,000 个注册，总容量最多可达 10,000 个注册。不过，考虑到弹性的重要性，该医院还部署了两个额外模块，作为主模块的冗余备份。

在此场景中，该医院现在已部署主用和备用生存硬件。此时，如果某个主模块发生故障，冗余模块将接管以维持不中断的服务，同时继续支持最多 10,000 台已注册设备。

站点设计注意事项

站点按位置将 Zoom Phone 用户分组，以应用通用的电话通讯设置和策略

一个 站点 是 Zoom Phone 中使用的一个特定术语，用于将具有共享特征的用户——例如通用访问代码、地址、SIP 区域、部门或策略——归为 Zoom Web门户中的一个可管理组。对于某些客户而言，一个站点可能代表其企业中的所有用户，并且可能跨越园区或位置中的多栋建筑；而对于其他客户，则可能需要多个站点，具体取决于其业务需求。有关站点或站点管理的更多信息，请 请参阅 Zoom 的支持中心.

Zoom Phone 支持单站点和多站点设计

在一个账户中配置 Zoom Phone 站点主要有两种设计：

1. 单站点：在单个 Zoom Phone 站点内表示账户中的所有用户，可能跨越多栋建筑或多个位置。

2. 多站点：将用户按位置、建筑、部门或职能分别表示，每个都有各自的站点。

当前 Zoom 客户的账户管理员可以通过 公司信息 页面查看当前的站点设计，该页面可在 电话系统管理 Web 门户的菜单中找到。

每个 ZPLS 模块一次只能关联一个站点

如前所述，ZPLS 模块是 第三优先级注册器 ，用于受支持的设备，排在主和备用 SIP 区域之后。由于设备在启动过程中会收到其 SRV 列表，而这些列表与其站点设置相关联， 每个 ZPLS 模块一次只能关联一个站点.

每个站点最多可同时支持 20 个 ZPLS 模块

尽管每个 ZPLS 模块一次只能关联一个站点，但一个站点可以在一个组中支持最多 20 个 ZPLS 模块，从而增强每个站点的生存能力。

此功能目前处于 Beta 版，需要通过技术支持工单来启用。

如果这些模块连接到同一网络，ZPLS 模块支持跨站点呼叫

来自不同站点的 ZPLS 模块在生存事件期间支持跨站点呼叫，只要设备在本地网络内可被发现即可。例如，如果某个企业园区有三栋建筑，每栋建筑都有各自的电话站点，那么每个站点的 ZPLS 模块可以在整个园区区域网络内连接站点到站点呼叫。

此功能目前处于 Beta 版，需要通过技术支持工单来启用。

在部署 ZPLS 之前，账户应了解哪种站点配置最适合其需求

由于每个 ZPLS 模块一次只能关联一个站点，因此站点设计是在账户内部署 ZPLS 服务时最重要的因素之一。出于这个原因，客户应了解哪种站点配置最适合满足其实际业务和生存需求，因为每启用一个支持生存能力的额外站点，都至少需要再增加一个 ZPLS 模块。

单站点设计更易于管理，并可通过单个 ZPLS 模块提供生存能力，但在用户设置和策略方面的灵活性较低

单站点设计通过将账户中的所有用户整合到一个统一组下，帮助简化 Zoom Phone 设置和策略的管理。这个单一用户组为企业提供直接明了的管理和更低的复杂度，从而简化管理流程。此外，只要该站点的用户不超过单模块的 能力.

不过，单站点设计的简单性也天然包含局限性。具体而言，单站点设计由于其“一刀切”的特性而灵活性较低，可能不适用于跨多个需求各异的部门的所有部署场景。此外，如果 本地网络故障.

多站点设计在用户设置和策略方面提供了更大的灵活性，但每个启用了生存能力的站点都需要一个 ZPLS 模块，而且管理起来更复杂

多站点设计通过将用户拆分到多个具有细粒度设置控制的组中，为企业在用户设置和策略方面提供了额外的灵活性。该设计使组织能够细致调整通信配置，以满足不同站点的特定要求，从而为各种部门、场景或需求带来更精细、更适应性的用户体验。此外，多站点部署还可以支持 跨站点通信 ，前提是这些站点通过同一网络连接。

不过，管理多站点设计需要仔细关注每个站点独特需求的复杂性，这可能需要更高层级的管理工作。此外，由于每个 ZPLS 模块一次只能分配给一个站点，因此每个启用了生存能力的站点都将需要一个 ZPLS 模块和许可证，这可能会导致设置对资源的需求更高。

在多站点设计中，客户可以灵活选择哪些站点将配置为生存能力。站点 没有 ZPLS 模块将无法拨打或接听电话，直到标准连接恢复。

网络故障

如果站点的本地网络故障，生存能力可能会受到影响

尽管 ZPLS 模块旨在在影响服务的事件期间提供本地电话生存能力，但如果站点的本地网络故障，生存能力仍可能受到影响。以下两个部分概述了这些场景。

单站点本地网络故障

在单站点设计中，一栋或多栋建筑通过本地或园区网络连接，并在 Zoom Phone 中由一个单独的站点表示。此配置假定同一位置内所有用户和建筑之间存在一个公共网络，不依赖外部网络（例如互联网）进行跨楼宇通信。

采用这种站点设计时，企业只需一个 ZPLS 模块，就能为单个站点或位置内的所有用户提供本地生存能力；不过，如果影响跨楼宇通信的本地或园区网络中断，该设计就会变得脆弱。以下示例描述了本地网络故障如何影响单站点部署。

示例：

某公司正在为一个单个 Zoom Phone 站点部署 ZPLS 模块，该站点由 A、B 和 C 三栋建筑组成，这些建筑通过园区网络连接。ZPLS 模块运行在 A 楼，并且 未 连接到 SBC 以便通过 PSTN 进行外部呼叫。

在外部互联网服务故障或影响服务的事件发生时，站点内的任何用户都可以呼叫该 同一 站点内的另一位用户，只要两位用户都通过园区网络保持与 ZPLS 模块的连接。

然而，如果园区网络中断，B 楼和 C 楼中的用户将无法拨打电话，因为 A 楼中的 ZPLS 模块无法访问。因此，B 楼和 C 楼中的用户必须等到园区网络恢复后才能进行生存呼叫。

下表展示了多栋建筑的单站点设计中的 Zoom Phone 生存能力：

来自建筑	在外部互联网故障期间可以呼叫到这些位置	在园区网络故障期间可以呼叫到这些位置
A 楼（ZPLS 主机）	☑️ A、B 和 C 楼	☑️ 仅 A 楼 仅
B 楼	☑️ A、B 和 C 楼	✖️
C 楼	☑️ A、B 和 C 楼	✖️

无 SBC 的多站点本地网络故障

在多站点设计中，每栋建筑或位置（例如楼层、分支办公室等）都在 Zoom Phone 中由一个独特的站点独立表示。此配置假定每个站点都有一个 ZPLS 模块，并且这些站点通过同一个园区网络连接。

在这种站点设计下，每个站点都支持各自的 ZPLS 模块，使同一建筑内的用户在启用生存模式时可以互相呼叫。此外，当带有 ZPLS 模块的多个站点通过同一网络连接时，只要本地网络保持运行，用户就可以呼叫其他站点的用户。然而，如果园区网络中断，影响跨楼宇通信，该设计就会变得脆弱。以下示例描述了园区网络故障如何影响多站点部署。

示例：

某公司正在其多栋建筑园区内部署 ZPLS 模块，该园区由 A、B 和 C 三栋建筑组成。每栋建筑在 Zoom Phone 中都是一个独立的站点，并维护一个特定站点的 ZPLS 模块。园区内所有建筑都通过园区网络连接，而该网络进行跨楼宇通信时不依赖外部互联网服务。

在此示例中，当外部互联网服务故障、园区网络中断或发生影响服务的事件时，位于某站点内的任何用户都可以呼叫同一站点内的另一位用户。不过，由于每栋建筑都是独立的站点，且用户会注册到其特定站点的模块，如果园区网络故障，ZPLS 模块就无法传输跨站点呼叫。相反，用户将只能呼叫其本地站点中的其他用户。

下表展示了上述示例在具有互联园区网络的多站点设计中的 Zoom Phone 生存能力：

来自建筑	在外部互联网故障期间可以呼叫到这些位置	在园区网络故障期间可以呼叫到这些位置
A 楼（ZPLS 主机）	☑️ A、B 和 C 楼	☑️ 仅 A 楼
B 楼（ZPLS 主机）	☑️ A、B 和 C 楼	☑️ B 楼
C 楼（ZPLS 主机）	☑️ A、B 和 C 楼	☑️ C 楼

如果本地网络故障，只要每个站点都连接到 SBC 并启用了呼叫转移，也支持通过 PSTN 进行跨站点呼叫

在本地网络故障的情况下，对于将 ZPLS 模块与 SBC 及每个站点的 PSTN 连接集成的多站点设计，客户可以启用站点到站点呼叫，如果 启用了呼叫转移。配置后，在生存模式下拨打的电话将从用户客户端路由到 PSTN，再到第二个站点的 SBC 和 ZPLS 模块，最后到达被叫方设备。下图概述了此配置：

此配置 需要 在所配置的 SBC 上进行 E.164 电话号码处理。

下表还展示了具有独立 SBC 的多站点设计中的 Zoom Phone 生存能力：

来自建筑	在外部互联网故障期间可以呼叫到这些位置	在园区网络故障期间可以呼叫到这些位置
A 楼（ZPLS 主机）	☑️ A、B 和 C 楼	☑️ A、B 和 C 楼
B 楼（ZPLS 主机）	☑️ A、B 和 C 楼	☑️ A、B 和 C 楼
C 楼（ZPLS 主机）	☑️ A、B 和 C 楼	☑️ A、B 和 C 楼

流动用户始终注册到与其主站点关联的 ZPLS 模块

当用户或设备添加到 Zoom Phone 时，系统会静态地将一个“主”站点关联到该用户或设备，直到账户管理员进行更新为止。这意味着，如果用户移动到其关联主站点之外的物理位置，例如与另一个站点相关联的办公楼，Zoom 不会动态调整绑定到该用户的站点。因此，如果用户失去与 Zoom Phone 数据中心的连接，即使他们身处其他位置，用户仍会尝试注册到与其主站点关联的 ZPLS 模块。

示例：

多站点园区中的一位用户常驻于 A 楼（站点 A），并在开会时暂时移动到 B 楼（站点 B）。当他们在 B 楼时，发生了影响服务的事件，并启用了生存模式。尽管该用户位于 B 楼，但由于站点 A 是其主站点，用户客户端将尝试连接到部署在 A 楼中其主站点的 ZPLS 模块。

在此场景中，用户的生存状态取决于用户设备通过园区网络注册到其主站点内 ZPLS 模块的能力。如果用户离开主站点时园区网络中断，则该用户无法受益于生存模块。