规划
每个集群可以支持特定数量的隧道客户端和隧道设备。网关系列、型号以及集群节点数决定了每个集群的容量。在规划集群时,主要考虑的是满足基础客户端、设备和隧道容量需求所需的网关数量,以及为了冗余所需的网关数量。
总集群容量考虑了基础和冗余需求。
集群容量
集群的容量是每个集群可以服务的最大隧道客户端和隧道设备数量。这包括每个建立隧道到集群的AP和UBT交换机/堆叠,以及每个通过有线或无线连接到集群的客户端设备。
对于每个网关系列,HPE Aruba Networking发布每个网关和每个集群支持的最大客户端和设备数量。每个网关系列可部署的最大集群节点数也会提供。此信息以及诸如上行链路类型和带宽等其他考虑因素,将用于选择网关型号和满足基础容量需求所需的集群节点数。
一旦满足了基础容量需求,你还可以确定需要多少额外节点以提供冗余容量,以应对维护事件和故障。为冗余而添加的额外节点在正常运行期间不会处于休眠状态,并且会承载用户流量。根据需要,可以添加额外节点,直到平台支持的最大集群规模。
7000 / 9000 系列 - 网关扩展
扩展 | 7005 | 7008 | 7010 | 7024 | 7030 | 9004 | 9012 |
---|---|---|---|---|---|---|---|
最大用户数 / 网关 | 1,024 | 1,024 | 2,048 | 2,048 | 4,096 | 2,048 | 2,048 |
最大用户数 / 集群 | 4,096 | 4,096 | 8,192 | 8,192 | 16,384 | 8,192 | 8,192 |
最大设备数 / 网关 | 64 | 64 | 128 | 128 | 256 | 128 | 512 |
最大设备数 / 集群 | 256 | 256 | 512 | 512 | 1,024 | 512 | 1,024 |
最大隧道 / 网关 | 5,120 | 5,120 | 5,120 | 5,120 | 10,240 | 5,120 | 5,120 |
最大集群规模 | 4 频段 | 4 频段 | 4 频段 | 4 频段 | 4 频段 | 4 频段 | 4 频段 |
7200 系列 – 网关扩展
扩展 | 7205 | 7210 | 7220 | 7240XM | 7280 |
---|---|---|---|---|---|
最大用户数 / 网关 | 8,192 | 16,384 | 24,576 | 32,768 | 32,768 |
最大用户数 / 频段 | 98,304 | 98,304 | 98,304 | 98,304 | 98,304 |
最大设备数 / 网关 | 1,024 | 2,048 | 4,096 | 8,192 | 8,192 |
最大设备数 / 频段 | 2,048 | 4,096 | 8,192 | 16,384 | 16,384 |
最大隧道 / 网关 | 12,288 | 24,576 | 49,152 | 98,304 | 98,304 |
最大集群大小 | 12 频段 | 12 频段 | 12 频段 | 12 频段 | 12 频段 |
9100 / 9200 系列 – 网关扩展
扩展 | 9114 | 9240 基础 | 9240 银牌 | 9240 金牌 |
---|---|---|---|---|
最大客户端 / 网关 | 10,000 | 32,000 | 48,000 | 64,000 |
最大用户数 / 频段 | 60,000 | 128,000 | 192,000 | 256,000 |
最大设备数 / 网关 | 4,000 | 4,000 | 8,000 | 16,000 |
最大设备数 / 集群 | 8,000 | 8,000 | 16,000 | 32,000 |
最大隧道 / 网关 | 40,000 | 40,000 | 80,000 | 160,000 |
最大集群规模 | 6 节点 | 6 节点 | 6 节点 | 6 节点 |
最大集群容量
每个集群支持的最大客户端和设备数量不能被超过。达到集群最大客户端或设备容量所需的集群节点数会根据网关系列和型号而变化。在某些情况下,集群的最大客户端和设备数量只能通过忽略任何高可用性要求并不使用冗余来实现。
网关系列 | 网关型号 | 最大集群客户端容量 |
---|---|---|
7000 | 全部 | 4 个节点 |
9000 | 全部 | 4个节点 |
7200 | 7205 | 12 节点 |
7210 | 6 个节点 | |
7220 | 4 个节点 | |
7240XM / 7280 | 3 个节点 | |
9100 | 全部 | 6 个节点 |
9200 | 全部 | 4 节点 |
网关系列 | 网关型号 | 最大集群设备容量 |
---|---|---|
7000 | 全部 | 4 个节点 |
9000 | 全部 | 4个节点 |
7200 | 全部 | 2 节点 |
9100 | 全部 | 2 节点 |
9200 | 全部 | 2个节点 |
当集群的客户端或设备最大容量已达上限时,添加更多的集群节点将不会提供额外的客户端或设备容量。集群不能支持超过Gateway系列或型号声明的最大客户端或设备数。一旦集群达到最大客户端或设备容量,每个额外的节点将为客户端流量提供转发和上行链路容量,此外还会提供故障转移的客户端和设备容量。
什么会消耗容量
每个隧道客户端和隧道设备在集群中消耗资源。每个Gateway型号支持的客户端和设备数量与每个平台的可用处理能力、内存资源和转发容量直接相关。HPE Aruba Networking在大规模测试和验证每个平台,以确定这些限制。
随着AOS 10的推出,Gateway的扩展容量已不同于AOS 8时的设置。在评估用于AOS 10部署的Gateway型号或系列时,应考虑这些新的容量。由于AP管理和控制不再由Gateway提供,支持的设备和隧道数量已增加。
客户端容量
每个隧道客户端设备(唯一MAC)在集群中消耗一个客户端资源,并计入集群公布的客户端容量。对于每个Gateway系列和型号,HPE Aruba Networking提供每个Gateway和同质集群支持的最大客户端数。每个Gateway型号和集群不能支持超过声明的最大客户端数。
在确定集群的客户端容量需求时,应考虑所有连接到园区AP、微型分支AP和UBT交换机的隧道客户端。每个隧道客户端在集群中消耗一个客户端资源。需要考虑的客户端包括:
- 连接到园区AP的WLAN客户端。
- 连接到实现集中式2层(CL2)转发的微型分支接入点的WLAN客户端。
- 有线客户端连接到 AP 上的隧道下行端口。
- 连接到 UBT 端口的有线客户端。
{:.note } 仅需要考虑终止于集群中的隧道客户端。连接到园区 AP、微型分支 AP 或由设备桥接的 UBT 端口的 WLAN 和有线客户端被排除在外。连接到实现分布式第 3 层(DL3)转发的微型分支 AP 的 WLAN 和有线客户端也可能被排除。
每个 AP 和活动的 UBT 端口与每个集群节点建立 GRE 隧道。由集群领导发布的桶映射决定每个隧道客户端的 UDG 和 S-UDG 分配。客户端的 UDG 分配决定 AP 或 UBT 交换机使用哪个 GRE 隧道转发客户端的流量。如果客户端的 UDG 失败,客户端的流量将切换到与客户端分配的 S-UDG 相关联的 GRE 隧道。
隧道客户端的数量不影响 AP 或 UBT 交换机与集群节点建立的 GRE 隧道数量。每个 AP 和活动的 UBT 端口将与每个集群节点建立一个 GRE 隧道,无论 WLAN 或 UBT 端口服务的隧道客户端设备数量如何。WLAN 和有线端口配置文件的数量也不影响 GRE 隧道的数量。所有终止于集群内的配置文件共享这些 GRE 隧道。
下图展示了支持 60K 隧道客户端的 4 节点 7240XM 集群的客户端资源消耗情况。一个四节点的 7240XM 集群最多支持 98K 客户端,每个节点最多支持 32K 客户端。在此示例中,每个客户端使用为集群发布的桶映射分配 UDG 和 S-UDG,该映射在四个集群节点之间分布。在正常运行期间,每个集群节点被分配 15K UDG 会话和 15K S-UDG 会话。
一个示例,展示了支持 60K 隧道客户端的四节点 7240XM 网关集群如何消耗集群中每个节点的可用客户端容量。
设备容量
每个隧道设备在集群中消耗一个设备资源,并计入集群发布的设备容量。对于每个网关系列和型号,HPE Aruba Networking 提供每个网关和同质集群支持的最大设备数。每个网关型号和集群不能支持超过声明的最大设备数。
在确定集群的设备容量时,需要考虑所有将客户端流量隧道到集群的设备。每个将客户端流量隧道到集群的设备都消耗集群内的一个设备资源。需要考虑的设备包括:
- 园区 APs
- 微型分支 APs
- UBT 交换机
每个将客户端流量隧道传输到集群的 AP 和 UBT 交换机都建立了 IPsec 隧道,用于信令、消息传递和桶映射分发。集群领导者根据每个集群节点的容量和负载,确定每个 AP 的 DDG 和 S-DDG 分配,这些分配是负载均衡的。对于 UBT 交换机,管理员配置决定每个 UBT 交换机的 SDG 分配,而集群领导者则决定 S-SDG 分配。UBT 交换机实现了一个 PAPI 控制通道,用于信令、消息传递和桶映射分发到 SDG 节点。
下图展示了支持 8K AP 的 4 节点 7240XM 集群的设备资源消耗情况。一个四节点的 7240XM 集群最多支持 16K 设备,每个节点最多支持 8K 设备。在此示例中,每个 AP 被集群领导者分配了 DDG 和 S-DDG,这些分配在四个集群节点之间分布。在正常运行期间,每个集群节点被分配 2K 的 DDG 会话和 2K 的 S-DDG 会话。
一个示例,展示了支持 8K AP 的四节点 7240XM 网关集群将如何消耗集群内每个节点的可用设备容量。
隧道容量
AP 和 UBT 交换机与每个集群节点建立 IPsec 和/或 GRE 隧道。只有在配置了混合或隧道转发的 WLAN 或有线端口配置文件,并且选择了作为主集群或备用集群时,AP 才会与集群建立隧道。UBT 交换机只会与配置为主 IP 或备用 IP 的集群建立隧道,这是交换机配置的一部分。
将建立以下类型的隧道:
- 园区 APs – IPsec 和 GRE 隧道
- 微型分支 AP(CL2) – IPsec 和 GRE 隧道。GRE 隧道封装在 IPsec 中。
- UBT 交换机 – GRE 隧道
园区 AP 和微型分支 AP 的隧道由 Central 编排,而 UBT 交换机的 GRE 隧道则根据管理员配置发起。每个 AP 或 UBT 交换机的隧道在集群内的每个 Gateway 上都消耗隧道资源。与按集群评估的客户端和设备容量不同,隧道容量是按 Gateway 评估的。
设备与每个集群中的每个 Gateway 建立的隧道数量会有所不同。在正常操作中,AP 将为 DDG 会话在每个 Gateway 上建立 2 个 IPsec 隧道(SPI-in 和 SPI-out),为 UDG 会话在每个 Gateway 上建立 1 个 GRE 隧道。IPsec 隧道的数量在重新密钥期间会周期性增加到每个 Gateway 4 个 IPsec 隧道(共 5 个)。配置用于 CL2 转发的微型分支 AP 消耗的隧道数量与园区 AP 相同,主要区别在于每个 GRE 隧道都封装在 IPsec 隧道中。
园区 AP 的隧道消耗情况如下图所示。在此示例中,AP 已在每个集群中的 Gateway 上建立了 2 个 IPsec 隧道和 1 个 GRE 隧道。为重新密钥而周期性建立的额外 2 个 IPsec 隧道也被显示出来。在最坏情况下,每个 AP 在重新密钥期间将向每个集群中的 Gateway 建立总共 5 个隧道。
AP 可能会对每个集群节点拥有五个独立的隧道,AP 将相应地预留隧道容量。
对于仅 WLAN 部署,不需要计算每个 Gateway 的隧道消耗,因为支持的最大设备数已考虑每个 AP 最多 5 个隧道的最坏情况。由于每个 Gateway 的最大设备数是硬限制,AP 不会建立超过 Gateway 支持能力的隧道数。
每个 UBT 交换机或堆叠到每个集群节点的 GRE 隧道数量取决于 UBT 版本和 UBT 端口数。对于两个 UBT 版本,每个 UBT 端口到集群中的每个 Gateway 建立 1 个 GRE 隧道,用于 UDG 会话。因此,UBT 端口总数将影响到每个集群节点建立的 GRE 隧道总数。
当部署 UBT 版本 1.0 时,每个 UBT 交换机或堆叠还会从其 SDG/S-SDG 集群节点建立两个额外的 GRE 隧道。这些额外的 GRE 隧道用于转发广播和多播流量,类似于 AP 上的 DDG 隧道。每个配置为 UBT 版本 1.0 的 UBT 交换机或堆叠将因此在每个集群中消耗两个额外的 GRE 隧道。
下图显示了具有两个活动 UBT 端口的 UBT 交换机的隧道消耗情况。在此示例中,UBT 交换机配置为 UBT 版本 1.0,并已建立 1 个 GRE 隧道连接到其 SDG/S-SDG 网关,用于广播/多播流量。每个活动的 UBT 端口还会为 UDG 会话与每个 Gateway 建立 1 个 GRE 隧道。如果所有 48 个端口都处于活动状态,则每个 Gateway 将建立总共 49 个 GRE 隧道。请注意,每个 UBT 端口的客户端数量不会影响 GRE 隧道数,但会影响集群的客户端容量。
当配置支持 UBT 时,交换机到 Gateway 的 GRE 隧道构建示意图。
由于 UBT 部署的隧道消耗是可变的,因此,了解将要部署的 UBT 版本、UBT 交换机或堆叠的总数以及 UBT 端口的总数非常重要。对于 UBT 版本 1.0,每个交换机/堆叠将在每个集群中消耗 2 个 GRE 隧道,每个 UBT 端口在集群中的每个 Gateway 上为 UDG 会话消耗 1 个 GRE 隧道。对于 UBT 版本 2.0,每个 UBT 端口在集群中的每个 Gateway 上为 UDG 会话消耗 1 个 GRE 隧道。
对于混合 WLAN 和 UBT 交换机部署,AP 和 UBT 交换机可能会消耗超过 Gateway 隧道容量的隧道数。因此,计算支持部署所需的总隧道数非常重要,因为集群中的每个 Gateway 都会终止来自 AP 和 UBT 交换机的隧道。
确定容量
要成功确定集群的基础容量需求,需要对环境有充分的了解。每个 Gateway 型号设计支持特定数量的客户端、设备和隧道,并能转发一定量的加密和未加密流量。你在集群中部署的节点数量将决定在正常操作和维护或故障事件期间支持的客户端和设备的总数。
基础容量
成功的集群设计始于收集需求,这些需求将影响 Gateway 型号和部署的集群节点数量。一旦确定了基础容量,可以在此基础上添加额外节点作为冗余容量。
要确定集群的基础容量需求,需要收集以下信息:
- 总隧道客户端数 – 将被隧道传输到集群的客户端设备总数,包括无线客户端、连接到有线 AP 端口的客户端以及连接到 UBT 端口的有线客户端。每个唯一的客户端 MAC 地址算作一个客户端。
- 总隧道设备 – 正在与集群建立隧道的设备总数。这将包括园区AP、微型分支AP和UBT交换机。每个AP、UBT交换机/堆叠都算作一个设备。
- 总UBT端口数 – 如果部署了UBT,则必须知道所有交换机和堆叠中的UBT端口总数。
- UBT 版本 – UBT 版本决定是否从每个 UBT 交换机或堆叠建立额外的 GRE 隧道,以传输面向客户端的广播/多播流量。如果 UBT 交换机或堆叠的总数较多,这可能具有重要意义。
- 流量转发 – 集群需要转发的用户流量的最小总量。这将有助于网关模型的选择。
- 上行端口 – 连接每个网关到其各自的交换层所需的以太网端口类型以及需要实现的上行端口数量。
确定集群需要支持的客户端和设备数量是一个简单的过程。每个隧道客户端(有线和无线)将在集群中消耗一个客户端资源。每个AP和UBT交换机或堆叠将客户端流量隧道传输到集群中时,也会在该集群中消耗一个设备资源。然后可以选择一个网关型号和节点数量,以满足客户端和设备容量需求。主要目标是部署满足基础客户端和设备容量需求的最少集群节点数。
在评估客户端和设备容量以选择网关时,最佳实践是使用已发布的网关和集群扩展数的80%,以确保您的基础集群设计将包括20%的额外容量,以适应未来的扩展。不建议以100%的规模设计集群,因为在初始部署后将没有额外的容量支持更多的客户端或设备。
为了帮助选择网关模型并确定满足容量需求的集群节点数量,这里提供了一个基于网页的计算器:AOS 10 集群规模计算器。该工具允许你指定客户端和设备的数量,并选择网关模型和节点数。工具会直观显示所选的网关模型和节点数是否能满足你的基础容量需求。
用于选择网关模型和确定满足基础容量需求的最小节点数的总体思路,始于参考下表。这些表格提供了每个网关和每个集群支持的最大客户端和设备数量,并可以帮助缩小选择范围到特定系列或型号。
例如,如果你的基础集群需要支持50,000个客户端和5,000个AP,7000系列和9000系列的网关可以被快速排除,7205和7210系列的网关也可以排除。剩余的网关选项缩小到7220、7240XM、7280和9240基础型号。
使用80%的缩放比例,可以计算并评估每个网关模型满足客户端和设备容量需求的最小节点数。每个模型支持的最大客户端和设备数量都被记录,并确定80%的数值。然后可以计算出满足每个平台客户端和设备需求所需的节点数。满足容量需求的最小节点数可能会不同。例如,某个特定型号的网关可能需要2个节点以满足客户端容量需求,1个节点以满足设备容量需求。
如下所示,展示了每个网关模型的80%客户端和设备容量,并在每节点下列出。将此值乘以,便可得出满足50,000客户端和5,000 AP需求所需的节点数。以7220为例,满足客户端容量需求至少需要3个节点(19,660 x 3 = 58,980),而满足设备容量需求至少需要2个节点(3,277 x 2 = 6,554)。
其他网关模型满足上述客户端和设备容量需求至少需要1或2个节点。因此,7220可以被排除在考虑之外,因为它需要3个节点以满足容量需求,而其他型号只需2个节点。
模型 | 每节点80%客户端容量 | 最小节点数 | 集群 | 每节点80%设备容量 | 最小节点数 | 集群 |
---|---|---|---|---|---|---|
7220 | 19,660 | 3 | 58,980 | 3,277 | 2 | 6,554 |
7240XM | 26,214 | 2 | 52,428 | 6,554 | 1 | 6,554 |
7280 | 26,214 | 2 | 52,428 | 6,554 | 1 | 6,554 |
9240 Base | 25,600 | 2 | 51,200 | 3,200 | 2 | 6,400 |
下一步是评估连接网关到其各自核心/汇聚层交换机所需的上行端口数量和端口类型。作为最佳实践,每个网关应使用最少两个端口通过LACP配置连接到冗余的交换层。每个网关型号提供支持不同速度的不同以太网端口配置。网关型号提供铜缆、SFP、SFP+、SFP28+ 和 QSFP+ 接口,详细信息请参见数据手册。
在上述示例中,7240XM、7280 和 9240 基础型号都支持至少四个SFP+端口,如果需要10Gbps的上行链路,可以选择其中任何一个。如果需要更高速率的上行链路,如25Gbps或40Gbps,则可以排除7240XM。
同时,还需要考虑每个网关型号的转发性能。每个网关型号最大可转发的流量在发布的数据手册中提供。每个网关型号可以转发特定数量的用户流量,集群中的节点数决定了集群的总吞吐量。例如,9240基础网关可以提供最高20Gbps的转发能力。一个2节点的9240基础集群将提供总转发能力为40Gbps(2 x 20Gbps)。
如果需要更大的总转发能力,可以选择不同的网关型号和上行链路类型。例如,连接使用QSFP+接口的7280系列网关每个可以提供高达80Gbps的转发能力。一个2节点的7280集群将提供总转发能力为160Gbps(2 x 80Gbps)。
在上述示例中,9240基础和7280系列网关都满足2节点集群的基础容量需求。最终选择使用哪个网关型号,可能主要取决于上行端口偏好,依据交换层上的端口类型和总吞吐量需求。如果需要更多的上行链路和总转发能力,可以在基础集群设计中添加额外节点。
上述示例描述了用于选择网关型号和确定无线局域网部署的最小集群规模的方法,但未评估隧道容量。由于网关支持的AP数量不能超过其最大设备容量,因此无线局域网部署中,网关的隧道容量不能被超出。
当部署UBT时,客户端和设备的数量将影响基础集群的客户端和设备容量需求,而UBT版本和UBT端口总数将影响隧道容量需求。由于UBT交换机或堆叠的总数和UBT端口是可变的,因此需要额外验证以确保所选网关型号的隧道容量不被超出:
- UBT 版本 1.0 – 每个UBT交换机或堆叠将消耗2个GRE隧道,用于广播/多播流量传递到集群中的客户端。此外,每个UBT端口也会消耗1个GRE隧道到集群中的每个网关。
- UBT 版本 2.0 – 每个 UBT 端口将消耗 1 个 GRE 隧道连接到集群中的每个网关。
在前面的例子基础上,假设基础集群需要支持 50,000 个客户端、4,500 个接入点、512 个 UBT 交换机/堆叠以及 12,288 个 UBT 端口,并将实现 UBT 版本 2.0。客户端和设备的总数保持不变,但我们现在引入了额外的 GRE 隧道以支持 UBT 端口。
我们已经确定,使用 7240XM、7280 或 9240 基础系列网关的 2 节点集群可以满足基础的客户端和设备容量需求。下一步是计算隧道消耗。每个接入点将建立 5 个隧道,每个 UBT 端口将建立 1 个隧道。通过简单的乘法和加法,我们可以轻松确定所需的隧道总数:
- 接入点信道 / 网关: 5 x 4500 = 22,500
- UBT 端口隧道 / 网关: 12,288
在此示例中,每个网关需要总共 34,788 个隧道。我们可以确定每个网关型号的最大隧道容量,并计算出80%的隧道扩展数。然后,从中减去所需的隧道数量,以确定每个型号剩余的隧道数。
这在下表中得到了演示,显示我们的隧道容量需求可以由 7240XM 和 7280 系列网关满足,但不能由 9240 基础系列网关满足。除非部署单独的集群,否则 9240 基础网关不适合用于这种混合无线局域网 / UBT 部署。
型号 | 容量(80%) | 需求 | 剩余 |
---|---|---|---|
7240XM | 76,800 | 34,788 | 42,012 |
7280 | 76,800 | 34,788 | 42,012 |
9240 基础 | 32,000 | 34,788 | -2,788 |
如果在上述示例中部署了 UBT 版本 1.0,则每个 UBT 交换机或堆叠到集群的连接将额外消耗两个 GRE 隧道。在此示例中,基于 SDG/S-SDG 分配,将从 512 个 UBT 交换机到集群内不同网关建立 1,024 个额外的 GRE 隧道。要计算 UBT 版本 1.0 的每个网关的额外隧道容量,总隧道数除以基础集群节点数。对于一个 2 节点的基础集群,每个网关将消耗 512 个额外隧道。
冗余容量
一旦确定了基础集群设计,可以添加额外节点以提供冗余容量。每个添加到基础集群的额外节点将提供额外的转发容量、上行链路容量以及冗余的客户端和设备容量,以应对维护和故障事件。需要注意的是,添加到基础集群的每个额外节点在正常运行期间并非处于休眠状态,它们将支持客户端和设备会话并提供转发功能。
你为冗余容量而添加到基础集群的额外节点数量,将受到你对在不影响客户端或设备容量的情况下可以丢失多少集群节点的容忍度的影响。你的集群设计可能包括与网关系列支持的最大集群规模相匹配的冗余节点数。
最小冗余由向基础集群添加一个冗余节点提供。这被称为 N+1 冗余,其中集群可以在不影响客户端或设备的情况下,承受单个节点的丢失。N+1 冗余模型通常用于由单个节点组成的基础集群,但也可以用于多节点基础集群的冗余。以下是一个 N+1 冗余模型的示例,其中每个基础集群添加一个额外节点:
集群中的 N+1 冗余通过向集群添加一个网关实现,允许在单节点故障时不中断。
你为基础集群添加的冗余节点最大数量通常不超过基础集群中的节点数。唯一的限制是网关系列支持的最大集群节点数。
当冗余节点数等于基础集群节点数时,提供最大冗余。这被称为 2N 冗余(也称为 N+N 冗余),集群可以在不影响客户端或设备的情况下,承受一半节点的丢失。2N 冗余通常用于对连续运行要求极高的关键任务环境。集群节点可以位于同一数据中心,也可以在带宽和延迟允许的情况下分布在不同的数据中心。下图展示了在三节点基础集群设计中添加三个冗余节点的 2N 冗余模型:
2N 冗余
除非需要额外的转发、上行链路或防火墙容量,否则大多数集群设计不会包含多于基础集群的冗余节点。你的集群设计可以包括单个节点以实现 N+1 冗余、两个节点以实现 2N 冗余,或介于两者之间的配置。
多区域
AOS 10 的一个主要架构变化是,AP 配置组中的 WLAN 和有线端口配置文件可以终止在不同的集群上。这一能力被称为多区域(MultiZone),由支持配置为混合或隧道转发的配置文件的 Campus AP 和配置为集中式 2层(CL2)转发的 Microbranch AP 支持。
多区域在企业网络中具有多种应用。最常见的用途是分段,将不同类别的流量隧道到网络中的不同点。例如,来自员工 WLAN 的受信任流量被隧道到数据中心中的集群,而来自访客/访客 WLAN 的不受信任流量被隧道到防火墙后面的 DMZ 中的集群。其他常见用途包括部门访问和多租户。
在规划多区域部署的容量时,需要考虑以下因素:
- 每个 AP 在其隧道客户端流量的每个集群上将消耗一个设备资源。
- 每个接入点(AP)将为其转发客户端流量的每个集群建立到每个集群节点的 IPsec 和 GRE 隧道。
- 每个隧道客户端将在其隧道到的集群上消耗一个客户端资源。
- 每个AP在所有集群中最多可以建立十二个网关的隧道。
当配置为混合模式或隧道转发的WLAN或有线端口配置文件在Central实例内的不同集群中终止时,即启用__MultiZone__。启用后,AP将与每个集群中的每个节点建立IPsec和GRE隧道。与单一集群实现类似,AP在正常操作期间将与每个集群节点建立3个隧道,在重新密钥时建立5个隧道。
每个集群由其集群领导者分配DDG和S-DDG会话,并发布其各自集群的桶映射。每个隧道客户端根据其所属集群的桶映射,在其集群中分配有UDG和S-UDG会话。
多Zone AP部署的隧道消耗情况如下图所示。在此示例中,一台AP配置了三个WLAN配置文件,其中两个WLAN配置文件终止在员工集群上,另一个WLAN配置文件终止在访客集群上。AP与每个集群建立IPsec和GRE隧道,并在每个集群中分配DDG会话,接收每个集群的桶映射。连接到WLAN A或WLAN B的客户端在员工集群中分配UDG会话,而连接到WLAN C的客户端在访客集群中分配UDG会话。
多Zone容量
多Zone部署的容量规划遵循前述章节中描述的方法,每个集群的基础容量设计以支持在每个集群终止的最大隧道设备数和隧道客户端数。然后添加额外节点以实现冗余容量。
由于混合和隧道WLAN及有线端口配置文件可以在Central中分布在多个配置组之间,因此需要充分了解分配到每个集群终止配置文件的AP总数。如果所有AP和配置组之间的配置文件是通用的,设备容量和隧道消耗可能在集群间相等;如果为每个配置组中的AP分配了不同的配置文件,则可能不相等。
例如,如图所示,配置组A中的WLAN A、WLAN B和WLAN C分配给1000个AP,配置组B中的WLAN A和WLAN B也分配给1000个AP,则员工集群将消耗2000个设备资源,而访客集群将消耗1000个设备资源。隧道消耗在员工集群的网关上为10,000,在访客集群的网关上为5,000。
还需要了解每个集群中所有WLAN的最大隧道客户端数,这通常在不同集群之间会有所不同。例如,员工集群可能设计支持最多10,000个员工设备,而访客集群可能设计支持最多2,000个访客或访客设备。在这种情况下,WLAN A和WLAN B将在员工集群中消耗10,000个客户端资源,而WLAN C将在访客集群中消耗2,000个客户端资源。
最后修改时间:2025年2月25日(0269ea6)