请使用本文中的内容来规划 Webex 混合服务部署的连接器容量，并了解相关的扩展性建议。 对于专用和共存连接器部署，您可以找到连接器集群支持的最大用户数量、决定受支持用户上限的因素，以及如何使用 Control Hub 来评估是否需要添加更多 Expressway。
 |
Call Connector 体系结构上的混合呼叫服务已终止服务 (EOL)，因此不再正式支持该服务。 未来对于混合服务的 Expressway 容量规划不应考虑 Call Connector。 |
 |
本文不涉及混合日历服务 Cisco TMS 与 Office 365 集成以及 Cisco TMS 与 Google Calendar 集成的容量规划。 有关容量信息，请参阅 Cisco Webex 混合日历服务部署指南。 |
本文旨在解决容量规划问题并说明我们是如何计算用户容量的。 要对场景进行建模，请尝试使用混合服务容量计算器。
规划注意事项
为混合服务用户群规划 Expressway 容量时，请考虑以下问题：
您需要哪些混合服务？
Expressway 可以托管混合呼叫服务、混合日历服务和混合消息服务的连接器。
每项服务有多少用户？
每项服务的用户量越多，将 Expressway 集群专用于该服务的可能性就越大。 如果用户群较小，在共享集群（共存）上运行多个连接器是一种有效的选择。
您的需求会改变吗？
您可能希望从小用户群开始，使用 1 个 Expressway 集群为组织中的一群早期采用者提供服务，同时对未来逐步推广后的需求增长进行规划。 您可以从共享模型迁移到专用模型，或者扩展现有集群，以满足不断变化的需求。
主要影响因素
我们根据以下变量定义集群的容量：
节点大小 — 每个 Expressway 虚拟机都有相应的“VM 大小”，该值由安装时分配给 VM 的资源决定。 《Expressway 安装指南》中对这些要求进行了说明。 如果已经有快速通道，则可以在快速通道界面的页面上看到 VM 大小。
节点数量 — Expressway 集群可以有 1 到 6 个节点。 这些节点的大小必须相同，且运行的软件版本也应相同。
服务连续性策略 — 服务使用策略来确保为用户提供持续的服务。 日历服务和消息服务使用故障转移策略。
专用集群的服务连续性策略和容量表中详尽介绍了各种策略。
共存 — 当多个连接器共享 1 个 Expressway 集群时，与使用专用集群相比，每个服务可用的资源会显著减少。
您的连接器主机上可能还有其他基于 Expressway 的服务，例如企业对企业的呼叫 (B2B) 或移动和远程访问 (MRA)。 只有有限的场景支持这种共存，本文记录的容量数仅限于我们已经测试过的场景。 除了本文所描述的场景外，连接器主机 Expressway 集群不得与其他服务共享，因为这不受支持。
服务特定限制 - 例如，日历连接器主要面向 Microsoft Exchange 用户并且支持有限的 Office 365 用户。
专用 Expressway 集群的计算
根据我们在测试和试用中收集的证据，我们对单个专用 Expressway（“1 个节点的集群”）可管理的服务用户数量设置了硬性限制。
| Expressway 节点大小 | 混合日历服务容量 | 混合消息服务容量 |
|---|---|---|
| 1. 小 | 5000 | 5000 |
| 2. 中 | 10000 | 6500 |
| 3. 大 | 15000 | 15000 |
我们使用服务连续性算法将单节点数量推算到多节点集群，具体如下表所述。 如果要获取结果而不了解相关说明，请参阅：
比较 |
混合日历服务 |
混合消息服务 |
|---|---|---|
1. 型号 |
故障转移模式 |
故障转移模式 |
2. 描述 |
我们将每个用户分配到集群中的 1 个节点。 这样就可以将用户分散到所有节点。 如果 1 个节点出现故障，我们会在其他节点上重新创建该节点的用户分配。 节点恢复后，将重新平衡所有活动节点上的用户分配。 |
我们将每个用户分配到集群中的 1 个节点。 这样就可以将用户分散到所有节点。 如果 1 个节点出现故障，我们会在其他节点上重新创建该节点的用户分配。 节点恢复后，将重新平衡所有活动节点上的用户分配。 |
3. 公式 |
UcalN= (N-1) * Ucal1 |
UmsgN= (N-1) * Umsg1 |
4. 定义 |
位置： UcalN 是日历服务用户的 N 集群容量 N 是节点数量 Ucal1 是日历服务用户的单节点容量 |
位置： UmsgN 是消息服务用户的 N 集群容量 N 是节点数量 Umsg1 是消息服务用户的单节点容量 |
5. 说明 |
如果 N = 1，则不存在故障转移。 如果 N>1，则故障转移自动执行且是强制的。 如果 N = 2，此时的容量与 N = 1 时相同，但服务的连续性更佳。 N>=3 或使用更大的节点有助于扩展规模。 |
如果 N = 1，则不存在故障转移。 如果 N>1，则故障转移自动执行且是强制的。 如果 N = 2，此时的容量与 N = 1 时相同，但服务的连续性更佳。 N>=3 或使用更大的节点有助于扩展规模。 |
共享 Expressway 集群的计算
我们使用的算法假定共存连接器按比例共享单个节点的资源。 该算法可以保守地设置节点上每种类型用户的限制。
例如，下表显示了单个中型 Expressway 上所有专用情境和共存情境下的最大用户数。
| Expressway 用途 | 日历服务用户 | 消息服务用户 |
|---|---|---|
| 专用于日历服务 | 10,000 |
— |
专用于消息服务 |
— |
6,500 |
日历服务和消息服务共享 |
4,000 |
4,000 |
日历、呼叫和消息服务共享 |
2,300 |
2,300 |
本文并未针对所有集群大小详尽列出所有的共存状况。 您可以监控现有混合服务部署的容量，也可以使用计算器来规划新的部署。
|
您可以利用计算器来选择连接器、节点大小和节点数量，从而对部署进行建模。 本节下面的内容介绍如何通过模型计算用户数量。 |
与在专用 Expressway 中的做法相同，我们通过推断共享 Expressway 的算法来确定多个节点的用户数。 与专用情境不同的是，我们应用了相关的服务连续性计算来得出集群上特定服务的用户容量。 我们无法计算集群的用户容量，因为集群托管了基于用户的竞争性服务连续性策略。
集群用途 |
1、2 和 3 个节点的混合消息服务用户 |
||
|---|---|---|---|
专用于消息服务 |
6,500 |
6,500 |
13,000 |
其他主要影响因素
对集群资源的需求可能是相互竞争的，这会降低用户容量。 以下是已知示例：
日历服务 — 连接器主机可能也服务于 O365 用户。 本文中显示的数字和计算假定只有本地部署 Exchange 基础架构提供日历服务。 有关“混合”日历服务的更多信息，请参阅本文日历服务部分中的一些数字和图表。
呼叫处理 — 连接器主机可能也会处理呼叫信号和媒体。 这实际上是您的组织与 Webex 云之间的“企业对企业”整合。 正如与其他快速通道解决方案并存中所述，这一举措降低了容量。
您可以使用 Control Hub 查看每个混合服务 Expressway 资源的当前用户容量的百分比值。 指示容量是否在可接受范围内的颜色条。 此视图可以让您评估混合服务部署的健康状况，并指导您何时需要更多 Expressway。
绿色 — Expressway 在可接受的容量范围内。 (1%–60%)
琥珀色 — 有足够的 Expressway，但快要达到容量限制。 (61%-90%)
红色 — Expressway 不足，必须添加更多 Expressway。（91% 及以上）
如果 Expressway 在资源组中，则资源组中的集群的过滤视图下将显示容量指示器。
对于不使用资源组的部署（缺省）：
在 https://admin.webex.com 的客户视图中，转至，然后滚动到混合服务卡，从而查看每项服务在 Expressway 资源上已使用容量的百分比。
对于使用资源组的部署：
如果容量值为 N/A，则通过过滤以查看资源组和容量选择资源组。
该值会不断更新以显示该资源组中的集群已用容量的百分比，并使用颜色编码来指示运行状况。
注意事项
取决于节点大小、Expressway 集群中的节点数量、集群上运行的服务数量以及高可用性或故障转移策略，集群容量会有所不同。 有关更多信息，请参阅相应的日历和消息容量部分。
共驻内存会降低现有服务的用户容量；容量算法假定每个用户都使用所有服务。
在尝试使用多种服务时，或者部署规模较小时，我们建议您使用共驻内存。 对于生产模式下的服务，或者在大规模部署的情况下，我们建议您在专用 Expressway 集群上运行不同的混合服务。
下一步
要为混合服务添加更多 Expressway，请使用部署指南中的步骤将连接器主机注册到云端，并将它们添加至现有的集群：
混合日历服务用户的容量主要取决于集群内的节点的大小、数量以及服务连续性策略。 下表显示随单个专用集群上节点数（或节点 OVA 大小）的增加，集群可以处理的最大用户容量。
|
在具有 Office 365 用户的混合 Exchange 环境中，每个集群有 1000 个 Office 365 用户的限制，与集群的节点数量或大小无关。 基于云的服务是处理 Office 365 用户的首选方法。 我们强烈建议您仅在快速通道上临时托管 Office 365 用户。 此限制源自与 Microsoft 云服务的交互，而不是源自本地快速通道部署的规模。 例如，如果您只有一个小型快速通道节点，那么容量限制为 1000 个 Office 365 用户和 4000 个 Microsoft Exchange 用户。 例如，如果您有一个包含 6 个小型节点的集群，那么容量限制为 1000 个 Office 365 用户和 24000 个 Microsoft Exchange 用户。 |
Expressway 节点大小 |
1 个或 2 个节点* |
3 个节点 |
4 个节点 |
5 个节点 |
6 个节点 |
|---|---|---|---|---|---|
1. 小 |
5000 |
1 万 |
1.5 万 |
2 万 |
2.5 万 |
2. 中 |
1 万 |
2 万 |
3 万 |
4 万 |
5 万 |
3. 大 |
1.5 万 |
3 万 |
4.5 万 |
6 万 |
7.5 万 |
* 请注意，无论是 1 个节点的集群还是 2 个节点的集群，它们的用户容量都是相同的。 这是因为日历服务使用故障转移来提高服务连续性。 当集群中有 2 个节点时，所有用户都会被分配给 1 个节点；剩下的那个节点用于冗余备份。 有关详细说明，请参阅规划 Expressway 集群的混合服务用户容量。
跨主机和集群的用户分配
默认情况下，混合日历服务自动跨集群中的所有日历连接器分配和分布用户。 分配是动态的并以可用性为基础，且管理员无法控制单个用户分配到哪个特定节点。
在组织有多个集群的情况下，用户分布基于多种因素，包括集群可用性、当前分配情况（减少故障恢复期间出现翻动）和基于最高集群首选项的排序顺序。 管理员还可以将用户或用户组分配到资源组。 资源组是特定于集群的，因此它们允许管理员对向特定集群分配特定用户组予以限制。
通过这种对用户分配的基本了解以及快速通道日历连接器的前提条件，管理员可以针对其组织部署相应的容量。 让我们了解一下一个由 126000 位用户组成的组织的例子，考虑到以下参数，将启用混合日历服务：
使用大型 OVA 模板的包含 6 个节点的快速通道集群（每个节点限制为 15000 个用户）
无需资源组
单个集群的容量公式 UcalN= (N-1) * Ucal1，其中 N=6，Ucal1=15000（使用大型 OVA 模板）可生成最多 75000 个用户。 在日历服务部署中，用户总数为 126000，需要多个日历连接器主机集群。 用户将按下图所示同等分布：
混合日历服务先将用户添加到集群 A，直到集群达到 75000 个用户的容量，然后将其余用户分配到集群 B。用户随机且平均地分布在集群内的所有节点上。 下例显示了各数据中心 RTP 和 PDX 之间日历连接器主机节点（两个集群内）的分布情况。 每个节点使用相同的 OVA 模板，且符合快捷通道高可用性指导原则。 日历连接器在 5+1 冗余模型中使用快捷通道集群逻辑，以实现高可用性方案。
对于分配给日历连接器的所有用户，现在让我们来检查一下当集群发生故障时会发生什么情况。 下图显示了单节点故障。 被分配至故障节点（集群 A 中的 5A）的用户现出现故障，现在被移动至该集群内的剩余节点中。 单节点容量最多允许 15000 名用户，将在集群 A 中剩余的每个节点中添加 2500 名原本被分配到节点 5A 上的用户。 集群 B 或被分配至集群 B 上的用户不会被更改，也不会受到影响。
集群 A 仍处于最大容量状态，集群中每个运行中的节点现在已达到最大容量，即 15000 个用户/节点。 因此，如果集群 A 中的另一节点不可用，例如下图中的节点 4A，集群 B 现在将负担其他用户负载。 节点 4A 中的 15000 个用户现在被重新分配到集群 B，并平均分布于集群 B 中的所有节点。
当节点 4A 和 5A 恢复时，集群 A 上的用户将被重新分布至集群中的节点。 在恢复阶段中，因故障而被分配至集群 B 的用户仍然保留在集群 B 中，以免在集群之间分配不必要的用户，如下图所示。
在规划大规模混合日历服务部署时，一个关键事项就是要了解如果在部署过程中发生故障会造成的影响。 如果您使用相同的 126000 个用户部署，但整个数据中心丢失，那么可能不会将用户分配到日历连接器节点。 为避免在此类情境中出现服务中断，客户需要具备第三个集群，以重新分布和处理受到影响的用户。
快速通道集群服务于混合消息服务用户的容量取决于构成快速通道的节点的大小、集群中的节点数量以及服务连续性策略。
下表显示了用于混合消息服务的单个快速通道上的最大用户数。
小型 Expressway |
中型 Expressway |
大型 Expressway |
|---|---|---|
5,000 个用户 |
6,500 个用户 |
15,000 个用户 |
|
无论是 1 个节点的集群还是 2 个节点的集群，它们的用户数量都是相同的。 这是因为消息服务使用故障转移来提高服务连续性。 用户均匀地分布在集群中的多个节点： 如果 1 个节点发生故障，该节点的用户会被分配给其他节点。 |
此主题是关于在多个混合服务（包括日历服务和消息服务）的连接器之间共享连接器主机 Expressway 的。 连接器主机不与其他基于 Expressway 的解决方案共享，例如 MRA 和 B2B。
连接器主机集群的容量取决于构成 Expressway 的节点的大小、节点数量、集群上运行的连接器以及服务连续性策略。 有关这些因素的详细说明，请参阅规划 Expressway 集群的混合服务用户容量。
此外，您还可以使用计算器为不同的连接器主机集群建模，以了解您建议的集群针对每种服务可支持的用户数。
一般来说，我们只建议在较小规模的部署（最多两个节点）中使用共存。 如果您的部署超出一对节点的容量，则应该将连接器移动到专门适用于每个特定混合服务的快捷通道集群。
例如： 三个共存连机器的连接器主机容量
下表显示容量和共存的示例。 表中针对不同规格的连接器主机集群，给出了每种服务的每集群用户最大数量。 混合日历服务（使用本地交换）、混合呼叫服务以及混合消息服务共享集群。
服务 |
两个小型节点 |
两个中型节点 |
两个大型节点 |
|---|---|---|---|
日历服务用户 |
1,300 |
2,300 |
3,000 |
消息服务用户 |
1,300 |
2,300 |
3,000 |
介绍
本主题是关于与其他基于 Expressway 的解决方案共享连接器主机 Expressway。 当选择在用于其他用途的 Expressway 上托管连接器时，需要注意以下几点：
我们无法支持适用于专用连接器主机 Expressway 的可扩展性模式。 当连接器主机与其他 Expressway 服务共享时，阅读本文中的其他主题或使用计算器得出的用户数量不适用。
只有本文所描述的基于 Expressway 的服务与混合服务连机器的组合以及相关用户数量是受支持的相关场景。 我们并未针对其他场景开展测试，因此这些场景在您的环境中是否受支持是无法预期的。
基于 Expressway 的日历服务（使用 Call Connector 和呼叫服务遍历）
在此场景中，由一个双节点 Expressway 集群托管混合日历服务连接器。 该集群还对其他 Cisco 呼叫解决方案（SIP 信令和媒体）执行呼叫遍历。
下表显示了可以使用基于 Expressway 的连接器的不同日历环境。 有两个以上节点的集群不支持使用基于 Expressway 的 Calendar Connector。 使用基于云的连接器可以提高 Office 365 的容量（见日历服务规模）。
服务 |
两个小型节点集群 |
两个中型节点集群 |
两个大型节点集群 |
|
|---|---|---|---|---|
Calendar Service |
本地部署 Exchange |
500 个用户 |
1,000 个用户 |
1,000 个用户 |
Office 365† |
500 个用户 |
1,000 个用户 |
1,000 个用户 |
|
本地部署 Exchange 和 Office 365（混合 Exchange 部署） |
二者最大用户数量均为 500 个 |
二者最大用户数量均为 1,000 个 |
二者最大用户数量均为 1,000 个 |
|
呼叫穿越 |
200 个音频会话 100 个视频会话 |
200 个音频会话 100 个视频会话 |
1,000 个音频会话 500 个视频会话 |
|
† 为避免这种容量限制，我们建议您使用基于云的日历服务，而不是本地部署的连接器。 对于基于快速通道的混合日历服务，Office 365 用户容量限制为每集群 1000 个用户，这与集群的节点大小或数量无关；此限制源自与 Microsoft 云服务的交互，而不是源自本地部署快速通道的部署规模。
日历（具有移动和远程访问功能）
在此场景中，由 1 个或 2 个小型 Expressway VM 组成的 MRA 集群托管 Calendar Connector。 此场景假设集群只用于 MRA 和两个连接器。 集群限制为 1 个或 2 个小型节点。
Expressway 用途 |
一个小型 Expressway-C 的集群 |
二个小型 Expressway-C 的集群 |
|---|---|---|
日历服务用户（Exchange 的本地部署连接器） |
500 个用户 |
500 个用户 |
移动和远程访问用户 |
100 |
100 |
