地址池管理器简介
使用本指南可配置和管理地址池管理器。
地址池管理器简介
瞻博网络地址池管理器 (APM) 是基于容器的云原生应用,运行在管理网络中 IPv4 地址池的 Kubernetes 群集上。它会在 BNG 耗尽其地址池之前,自动将集中式地址池中的前缀配置到宽带网络网关 (BNG)。BNG 将 APM 中提供的前缀作为新池添加到链接地址池中。链接地址池和池的关联属性(利用率、阈值等)称为 池域。
BNG 根据域的阈值持续监控域的可用地址,如下所示:
-
当域中的可用地址数量达到或低于域的分配阈值时,BNG 会向 APM 发送告警,请求其他地址。
-
APM 分配请求数量的与请求的前缀长度匹配的池前缀,并在告警响应中返回地址。
-
当域中的可用地址数达到或超过域的回收阈值时,BNG 会选择要删除的池前缀。它还向 APM 发出警报,要求回收。
-
APM 通过指示 BNG 在水池上放置一个主动排水管来响应回收警报。一旦池完全排干(没有分配的地址),BNG 就会发出池排干警报。
-
APM 通知 BNG 前缀将返回到域的源分区,并且 BNG 可以安全地从域中删除池前缀。
-
回收的前缀现在可供其他 BNG 请求。
本文档中的术语 BNG 也适用于 BNG CUPS 控制器。
图 1 显示了 APM作的高级视图,用于监控 BNG,并在需要时为其提供所需的地址。

APM 提供地址管理解决方案,帮助网络运营商高效分配 IPv4 地址。典型的地址分配方案非常复杂,效率不达网络运营商的需求。提供商通常会在网络设备上预先配置地址以处理最坏情况下的负载,以防止设备的地址用完。这意味着设备在大部分运行时间都处于过度配置状态。
APM 不会预先配置地址,因为这些地址可能永远不需要,可以在其他地方使用。APM 仅当 BNG 需要前缀时才分配前缀,而不是预置备。可能影响及时有效地址分配的特定网络考虑因素包括:
-
使用地址的网络设备数
-
VPN 的存在
-
系统冗余方案
-
网络元素的地理分布
APM 回收前缀以不断调整前缀的分布并最大限度地利用地址空间。前缀回收发生在 APM 上,而地址回收发生在 BNG 上。当 BNG 有多余的 IP 地址时,会发生前缀回收。BNG 向 APM 发送回收告警,其中包含建议的回收池前缀。APM 对池发起清空请求,以确保在 APM 回收池前缀之前池没有任何地址分配。然后,当这些 BNG 地址即将耗尽并需要更多地址时,APM 可以将前缀重新分配给其托管 BNG 中的其他池。
地址池管理器的好处
-
效率 — 提高地址利用率。APM 集中并自动为网络中的多个 BNG 分配地址。APM 使用实时前缀分配,因此仅当 BNG 需要其他 IP 地址时,它才会预配前缀。
APM 仅根据 BNG 需要提供数量的前缀。将 APM 全局池划分为前缀组后,APM 会进一步细分前缀以匹配 BNG 的请求。此细分使 APM 能够优化其分配的前缀的大小。
-
简单性 — 避免了手动监控和调配单个 BNG 的开销和复杂性。
-
可部署性—在满足要求的任何硬件上安装和运行。
-
可回收性 — 从使用很少 IP 地址的池中回收未使用的前缀到中央池,并将这些前缀重新分配给需要它们的其他池。
寻址术语
您应该对 IP 寻址、无类域间路由 (CIDR)、可变长度子网掩码 (VLSM) 以及如何将 IP 前缀细分为子网(子网)有很好的了解。在设计寻址策略(不在本文档讨论范围之内)或使用手动地址回收时,您可能会发现查看 IP 子网计算器会很有帮助。您可以在网上找到许多这样的计算器。
我们在本文档中使用以下术语:
-
前缀 — 使用 CIDR 表示法表示的 32 位 IPv4 网络地址和前缀长度;例如,198.51.100.0/24。前缀定义 IP 地址的网络部分。前缀表示子网。
-
前缀长度 — 确定前缀长度和 IP 地址网络部分大小的位数。/24 前缀长度表示地址的网络部分长度为 24 位。其余位(共 32 位)表示网络地址的主机部分。对于前缀长度为 /24 的前缀,主机部分为 8 位:32 – 24 = 8。
-
网络规模 — 根据上下文的不同,此术语有时也可用于表示几种不同的含义,这可能会导致歧义。我们描述前缀长度以及它如何与子网中的主机地址数量对应,如下所示:
-
更长的前缀(由更长的前缀长度决定)对应于更多的子网,每个子网要分配的主机地址更少。
-
较短的前缀(由较短的前缀长度决定)对应的子网较少,每个子网要分配的主机地址较多。
-
-
可用地址是可用但尚未分配给订阅者的 IP 地址。
APM 的工作原理
APM 为网络中的一组 BNG 维护一个集中的 IP 前缀集合。APM CLI 将托管的 BNG 称为实体。本文档一般使用术语 BNG,但在某些情况下,本文档会使用术语 实体。
APM 与 BNG 协调池域的创建。每个池域对应于 BNG 上给定路由实例组合的链接地址池。此外,在 BNG CUPS 控制器上,池域对应于给定订阅者组和路由实例组合的链接地址池。由于池域是动态创建的,因此 BNG 和 APM 都会维护包含实例化池域所需的属性的配置文件或模板。APM 配置文件包含分配、回收阈值和自动回收行为等属性。The BNG.配置文件包含前缀大小和丢弃路由安装行为等属性。
APMi 版本 1(兼容 Junos OS 22.1R1 及更高版本)。您可以通过运行 show apm entity 命令来检查 APMi 版本。
阈值和告警
BNG 创建池域并监视池域中的可用地址数。当可用地址的数量超过阈值时,BNG 会向 APM 发送报警消息。BNG 根据以下阈值监控可用地址的数量:
- 分配阈值 — 当可用地址数达到或低于此值时,BNG 将面临地址用完的风险。BNG 向 APM 发送分配告警,请求更多地址。APM 选择一个可用的前缀进行分配,并将该前缀分配给 BNG,BNG 在池域中添加一个或多个前缀作为新池。未能分配前缀(例如,空分区)会导致否定响应。重试时间设置为从收到请求之日起 15 分钟的时间戳。如果 BNG 仍需要域的前缀,它将按提供的时间戳值重试。
- 回收阈值 — 当可用地址数达到或高于此值时,BNG 将出现过剩地址。BNG 向 APM 发送回收告警,其中包含一个建议的池进行清空。根据配置,APM 可能会在池上启动排空。耗尽的池在订阅者使用的池中没有 IP 地址。
在清空期间,BNG 路由器停止分配池中的地址,并等待订阅者注销以释放这些地址。
排空池后,BNG 会将池排空告警发送给 APM。APM 向 BNG 路由器发送一条消息,以从池域中删除池。
注意:在以下情况下,APM 会在池上启动回收过程:
- 为池域启用自动回收。
- 在当前时间段允许开垦。
如果 APM 由于自动回收在窗口外而无法处理回收警报,则 APM 会使用设置为自动回收窗口开始的秒的重试时间进行
ALARM_NACK/NOOP
响应。
您可以在池域配置文件中配置分配阈值和回收阈值。阈值确定 BNG 是否有足够的可用地址,以及 APM 何时应分配或回收前缀。考虑 图 2 中的以下虚构时间线。BNG 在用户登录时为其分配地址,并在用户注销时回收地址。时间轴显示 BNG 在一段时间内跟踪的可用地址数。 表 1 描述了 BNG 和 APM 在可用地址数量超过不同阈值时针对不同场景所采取的作。

BNG 发送的时间报警 | 描述 | |
---|---|---|
T0 | — | 时间线的开头有一个填充的池域。 |
T1 | 分摊报警 | 订阅者登录时,BNG 上的可用地址数量将低于分配阈值。BNG 发送分摊告警。APM 接收分摊告警,并将前缀分配给池域。BNG 从池域的池前缀分配地址。 |
T2 | 分摊报警 | APM 收到分摊告警,但分区没有可用的前缀。警报已设置 NACKed,重试时间戳设置为 15 分钟后。除非 BNG 不再需要地址,否则 BNG 会在此时间戳重试分配告警。 |
T3系列 | 分摊报警 | 在重试时间戳处,BNG 会重新发送 apportion 告警,因为可用地址数仍低于 apportion 阈值。 |
T4系列 | 回收警报 | 订阅者继续注销,直到可用地址数量超过回收阈值。BNG 发送回收告警,其中包含建议的回收池。APM 在建议的池上放置一个排水管,BNG 在池上启动排水过程。 |
T5系列 | 池排空报警器 | 当地址池的订阅者为零时,池中没有分配的地址。BNG 向 APM 发送池排空告警。APM 通过删除请求响应池耗尽警报。BNG 将从池域的池列表中移除池。APM 将相应的前缀移回分区进行重新分配。 删除池后,可用地址的数量会下降。 |
T6系列 | 回收警报 | APM 接收回收告警,但未采取任何作,因为警报发生在回收窗口之外。APM 返回警报 NACK,其中重试时间戳设置为回收窗口开始的时间。如果仍有多余的可用地址,BNG 此时会重试回收警报。 |
APM的一般作
以下步骤解释了APM的一般作:
- BNG 和 APM 使用 APMi(瞻博网络定义的基于 gRPC 的协议)进行通信。Google RPC (gRPC) 是用于构建可扩展和可互作通信协议的通用框架。初始连接时,BNG 会启动池域同步。池域同步过程同步处于活动状态的池域集。APM 将活动池域列表与 BNG 的池域列表对齐。池域同步后,BNG 将为每个池域运行池同步(发现)。APM 将每个域的池列表与 BNG 的列表对齐。如果 APM 保留了任何其他池(不在 BNG 的域池列表中),则池前缀将释放到分区。如果 APM 缺少池,APM 会尝试分配池。
-
APM 监控 BNG 发送的报警消息。
-
APM 评估告警并对其采取行动。例如,如果 BNG 的地址用完,则 BNG 会向 APM 发送分摊告警。APM 从域的源分区分配请求数量的前缀,并在报警响应中返回它们。BNG 将这些池前缀添加到池域中。
图 1 显示了单个 APM 实例的各种功能组件之间关系的更详细视图。每个管理器块都显示它使用的数据库表。

您可以在网络中的多个不同集群上同时运行多个 APM 实例。这些 APM 实例是独立的,彼此不知道。实例不共享状态或配置。
每个 APM 实例都包含以下微服务作为应用的功能组件:
-
实体管理器 —编排所管理的 BNG 的池管理活动。这些活动包括处理警报以及分配和回收池前缀。
-
地址管理器 - 将中央地址池组织到分区中,并管理每个分区中配置的根前缀的分配。它将根前缀细分为较小的前缀,并根据 BNG 的配置条件分配前缀。
-
配置管理器 — 与 BNG 连接,用于配置池域及其关联的地址池。配置管理器可确保域和关联的分配池前缀在 APM 和 BNG 之间保持同步。
APM 调配管理器使用 APMi 与受管 BNG 通信。置备管理器发送 gRPC 消息,以直接置备和取消置备 BNG 上的前缀,以响应 BNG 发起的域告警。
- MGMT 微服务提供基于文本的配置架构和 CLI,以便您可以配置全局前缀池、托管 BNG 及其关联的池域属性。您可以使用 CLI 显示各种功能组件的统计信息和状态。输出提供有关系统负载、效率、利用率以及错误或异常情况的信息。
-
宽带边缘 (BBE) 事件收集和可视化(基于云的集中式实用程序) — 提供了一种捕获跨 APM 微服务生命周期的 APM 日志的方法。该实用程序跨 APM 微服务的实例收集和存储日志。
-
数据库实例 (DB) — 提供对 APM 的每个功能组件使用的数据库表的共享访问。该数据库包括地址表、BNG 表和池域信息表。该数据库为配置信息和作状态提供持久存储。
APM 使用一个数据库,其中包含有关实体、池域、池、前缀、分配、配置等的状态信息。两个数据库实例(一个主数据库实例和一个备用数据库实例)以热备用模式部署。数据库实例由数据库哨兵服务监视,该服务检测主数据库中的故障。主数据库发生故障后,辅助数据库将承担主数据库的角色,同时还原新的备用数据库。
注意:除主节点外,冗余还需要至少三个工作节点。工作节点必须全部位于不同的物理服务器上。但是,节点可以是物理机,也可以是虚拟机。
APM的功能组件
CLI 和配置管理
用户界面 (MGMT) 是 Junos OS 管理过程的容器化版本。借助此接口,您可以使用与 Junos OS 相同的 CLI 结构进行配置和监控。MGMT 还提供了一个允许您远程管理 APM 的接口。
APM 执行以下任务:
-
在其他 APM 组件进入其运行时状态之前,将初始 APM 配置从 MGMT 服务加载到数据库中。
-
将命令和配置转换为 APM 微服务可理解的作和参数。
-
记录数据库中的初始配置和后续更改,以实现持久性。它会将任何更改通知 APM 组件。
实体管理器
实体管理器协调影响实体状态的其他功能组件的作。
对于管理的每个 BNG,实体管理器会跟踪以下信息:
-
BNG 地址,即托管托管池的 BNG 的传输地址。
-
正在管理的池域的列表。
池域表示 BNG 上的链接地址池。对于每个池域,实体管理器会跟踪以下信息:
-
池域名 - 用户定义的字符串,用于标识 BNG 的托管池。对于该 BNG,每个池域名必须是唯一的。这意味着池域名实际上充当了密钥;它有时称为池域密钥。由实体构造的用户定义字符串。对于 BNG,字符串由与路由实例名称链接的域配置文件名称组成。对于 BNG CUPS 控制器,字符串由与订阅者组名称和路由实例名称链接的域配置文件名称组成。
-
APM 使用 -sequence-number 格式pool-domain-name来命名它创建的池。至少sequence-number为 4 位数字;如果该值小于 1,000,则序列号用前导 0 填充。所以 0001、0999、1000 213339 是有效的序列号。例如,如果池域的名称是 test-pd,则 APM 会命名第一个池 test-pd。它将后续池命名为 test-pd-0000、test-pd-0001 等。
-
前缀 - 组成池域的前缀的有序列表。
实体管理器为池域上的各种作(上次发现、上次分配、上次回收等)收集大量易失统计信息。统计信息包括警报计数、池数、其关联的前缀和时间戳。您可以使用 APM show
命令显示这些统计信息,例如 show apm entity
。
当配置管理器将分摊警报从 BNG 中继到实体管理器时,实体管理器会从地址管理器请求池域的新前缀。
前缀请求包含以下信息:
-
地址族 - 目前支持 IPv4
-
分配密钥 — 托管 BNG 的 IP 地址和池域
-
请求的前缀长度 - 要从分区分配给池域的前缀的大小。
随后,实体管理器会尝试将分配的前缀预配到 BNG 的地址池中。
当置备管理器通知实体管理器可访问 BNG 时,实体管理器将开始发现和协调管理下的 BNG 池域 (Sync) 的过程。每当可访问性状态发生更改时,预配管理器都会向实体管理器发送可访问性报告。实体管理器请求发现为该 BNG 管理的所有池域。
发现过程使用预配接口查找 BNG 已知的池域和关联池信息。在发现过程结束时,APM 和 BNG 具有相同的池域和分配的池前缀。
如果发现的信息与现有信息不匹配,则 APM 使用池域的分区信息更新其数据库(以匹配 BNG)。如果 APM 在更新期间发现冲突,它会在日志中将冲突标记为警告。
地址管理器
地址管理器使用 VLSM 算法将地址池分区中的根前缀细分为更小的子前缀,直至 max-prefix-len
达到您为每个根前缀配置的值。在分配期间,地址管理器会将适当大小的前缀请求与分区和根前缀进行匹配。APM 从根前缀分配一个空闲的子前缀来满足分配事件。
如果分区中的可用地址百分比低于阈值, free-prefix-utilization
地址管理器将记录警告消息。超过该阈值表示分区有地址用完的危险,因为它分配了太多地址。
配置 APM 时,会将根前缀分配给分区。地址管理器仅从任何域的单个分区中分配前缀。每个分区表示一个分配上下文。地址管理器使用您为域配置的偏差来选择分区,从中细分前缀以分配给域。
向分区添加根前缀时,请确保它符合该分区指定的最小和最大前缀长度限制:
-
该
min-prefix-len
值是最短的有效根前缀。 -
该
max-prefix-len
值是最长的有效根前缀。
因此, min-prefix-len
<= 根前缀长度 <= max-prefix-len
。
例如,如果 min-prefix-len
为 20 且 max-prefix-len
为 24,则可以添加前缀长度为 /20、/21、/22、/23 或 /24 的根前缀。
前缀长度越小,子网中可用的单个主机地址就越多。前缀长度越大,子网中可用的单个主机地址就越少。例如:
-
前缀长度 /20 可提供 4,094 个可用的主机地址。
-
前缀长度 /24 提供 254 个可用的主机地址。
如果配置的根前缀超出指定限制,则 APM 不会将其添加到分区中。
前缀细分
前缀细分的目标是使 APM 能够在多个域之间共享一个根前缀,并允许域以较小的增量增长。地址管理器在配置期间使用 VLSM 算法对分区中的根前缀进行细分。每个细分都是一个子网(子网)。
您可以通过指定允许的最大前缀长度来控制地址管理器细分根前缀的深度。的 max-prefix-length
值是子网允许的最长前缀。因此,此配置决定了分配的前缀必须提供的最小主机地址数。
前缀分配
地址管理器只能将任何特定前缀分配给一个域。前缀分配取决于域的偏差信息和请求的前缀大小。
地址管理器在分配前缀时会尽最大努力匹配请求的前缀大小 (preferred-prefix-len
)。分区可能没有剩余任何与请求的长度匹配的前缀。例如,当地址管理器为池分配上级前缀时,它还会将其所有从属前缀分配给池。
VLSM
VLSM 从根前缀创建子网层次结构。它通过将位添加到前缀长度来细分根前缀。添加到前缀长度的每个位都会创建另一个具有以下属性的子网从属级别:
-
每个级别的子网数是下一个更高级别的两倍。
-
每个级别每个子网的主机地址数仅为下一个更高级别的一半。
每个根前缀及其关联的子网层次结构构成一个前缀树。因此,分区由前缀树的集合组成。地址管理器只能分配适合这些前缀树之一中的某个位置的前缀。
前缀可能处于以下状态之一:
-
可用 - 前缀可用于分配给域。
-
已分配 - 前缀已分配给域和实体。
-
Reserved - 前缀随
reserved-prefix
语句一起在管理上保留。APM 无法将前缀分配给与请求域不匹配的域。
VLSM 示例
图 4 显示了 test-1 分区中根前缀 192.0.2.0/24 的层次结构。您可以看到,前缀长度每增加一个位,子网数就会增加一倍,从 /24 的一个子网到 /27 的八个子网。每增加一个前缀长度位,每个子网的可用地址数就会减半,从 /24 的 254 个地址减半到 /27 的 30 个地址。
图中的每个前缀块都显示 可用 地址:
可用地址 = 地址总数 - 2排除的两个地址分别对应最低地址(网络地址)和最高地址(组播地址)。

请考虑此根前缀树的以下方案:
-
地址管理器收到首选前缀长度为 25 的分配请求。
-
地址管理器查找包含该地址的 /25 前缀。192.0.2.0/25 匹配并被选中(如果可用)。
如果 192.0.2.0/25 不可用,会发生什么情况?这意味着 192.0.2.0/24 也不可用。地址管理器将查找另一个 /25 前缀。
地址管理器选择 192.0.2.128/25(如果可用)。如果该前缀不可用,则地址管理器会尝试从不同的根前缀分配 /25 前缀。
Provisioning Manager
Provisioning Manager 由管理以下 Provisioning作的工作进程组成:
-
发现 — 在 APM 和 BNG 之间同步池域和关联的池信息。在发现过程结束时,APM 和 BNG 就池域列表和分配的池前缀达成一致。
APM 行为 — APM 将其池域与 BNG 的列表进行协调,以便 APM 列表与 BNG 的列表匹配。在协调期间删除的域的池前缀会将其关联的池前缀返回到其原始分区。
每当 APM 与受管 BNG 建立连接(包括连接失败后重新建立的连接)时,Provisioning Manager 都会执行发现。连接断开时,管理员可以更改 BNG 上的配置。如果 APM 在后续发现过程中检测到更改,则会进行相应调整。
-
配置 — 在托管 BNG 上配置和取消配置前缀。地址管理器管理前缀分配的同时,置备管理器与 BNG 通信以置备地址池。
恢复连接后,置备管理器会通知实体管理器 BNG 是可访问的。实体管理器请求置备管理器启动同步过程。
前缀回收的工作原理
BNG 上的地址回收从设备地址池中恢复未充分利用的预配前缀,并将前缀返回到 APM 的集中式池中。然后,APM 可以根据需要将这些前缀重新分配给地址即将耗尽的其他池。这意味着前缀的分布会不断调整,以最大限度地提高地址空间利用率和效率。
回收是当 BNG 有多余的可用地址时,从 BNG 的池域中回收池前缀的过程。您可以在池域配置文件配置中设置回收阈值。然后,在 APM 上的实体配置中引用池域配置文件。
BNG 监视其每个池域的可用地址计数。当可用地址计数达到回收阈值时,将视为 BNG 有多余的地址。BNG 向 APM 发送回收告警,其中包含标识要回收的建议池的信息。回收告警驱动自动回收过程。或者,您也可以启动手动回收过程。
回收包括排空池,然后从池中恢复前缀,如下所述:
-
当 APM 启动清空时,它会向设备发送一条消息,开始主动清空池。这意味着不会从此池中分配任何新订阅者。对于基于连接的接入模式订阅者(例如 PPP),活动清空会触发立即注销并重新连接。对于基于租约的订户,主动流失会导致租约续订被拒绝。对于这两种模型,最终结果是订阅者重新连接,但从域中的另一个池中分配了一个地址。
-
当池中没有订阅者使用池中的地址时,池将完全耗尽。该池中的所有地址都是免费的。BNG 向 APM 发送池耗尽报警消息。
APM 可通过以下任一方法执行地址回收:
-
自动 — 可将回收配置为当 APM 收到回收或池清空告警时发生的全自动过程。您可以将该过程指定为立即开始,或仅在特定时间窗口内进行,或者等待一段时间后再对警报采取行动。
-
手动 - 使用
show
命令显示 BNG 上各个池的告警。然后发出request apm
命令以清空池中的地址,取消预配已清空的池,然后恢复其地址。
自动回收前缀
您可以启用 APM 以自动处理回收任务。您可以按照语句中的配置entity-match
,在分配给实体的 pool-domain-profile
IP 中配置自动回收。
启用自动回收后,将执行以下作:
-
APM 响应实体发送的域回收警报。回收警报包含要回收的建议池名称。
-
APM 通过指示实体在水池上放置一个主动排水管来响应回收警报。当池完全耗尽(池中没有未完成的地址分配)时,实体会发出域池耗尽警报。
-
APM 通过指示实体删除池来响应池耗尽警报;APM 将池前缀返回到分配它的分区。
-
将前缀返回到分区后,其他实体就可以使用它来引发域分配警报。
自动回收允许您限制实体上维护的未使用地址数。由于自动回收过程涉及可能影响主动清空的服务,因此您可以将 APM 配置为仅在配置的维护时段内启动自动回收。
释放为实体分配的前缀
如果网络实体发生故障并且无法与 APM 重新连接以允许将任何已分配的池前缀回收到其源分区,您可以使用命令 request apm release entity system-id
。此命令解除分配与网络实体关联的所有池前缀和池域。 request apm release entity system-id
如果实体的 APMi 状态为 reachable
。
使用以下步骤从无法访问的实体释放前缀。
使用命令可显示实体的可访问性状态及其池域所持有的池前缀。 输出显示该实体是可访问的,并且已分配 3 个池前缀。show apm entity system id
root@jnpr-apm-mgmt> show apm entity id yarmouth pool-domain iroh-default Entity Statistics: Entity ID: yarmouth APMi Ver : 1 Name : yarmouth Status : reachable Pool Domain Statistics: Pool Domain : iroh-default Source Partition: westford Free Addresses : 253 Pools : 3 Thresholds: Apportion : 200 Reclamation: 457 Events: Last Discovery : 2023-09-22T12:55:08Z Last Allocation : 2023-09-22T12:55:15Z Last Reclamation: - Allocations : 3 Reclamations : 0 Alarms: Apportion : 3 Reclamation : 0 Pool-drained: 0 Abatement : 0 Pool Prefix Total Addrs Used Addrs iroh-default 192.168.0.0/24 255 255 iroh-default-0000 192.168.1.0/24 255 255 iroh-default-0001 192.168.2.0/24 255 2
-
当实体可访问时,
request apm release entity system id
命令将失败。root@jnpr-apm-mgmt> request apm release entity yarmouth Response error: Entity yarmouth is still connected..release request is ignored
-
输入以
show apm entity
查看实体是否无法访问。root@jnpr-apm-mgmt> sshow apm entity Entity ID APMi Ver Name Status Pool Domains yarmouth 1 yarmouth unreachable 1
- 由于步骤 3 中的实体无法访问,因此可以输入
命令开始回收。APM 取消预配池,并将地址返回到源分区进行重新分配。将释放步骤 1 中报告的所有池前缀。request apm release entity system-id
root@jnpr-apm-mgmt> request apm release entity yarmouth Released Prefix Destination Partition 192.168.0.0/24 westford 192.168.1.0/24 westford 192.168.2.0/24 westford
手动回收地址
手动回收为您提供细粒度控制。手动回收需要您密切监控托管 BNG 上的池域和地址池。
show apm alarms
使用命令显示从 BNG 接收到的所有挂起告警。输出将显示具有reclaim
警报状态的池的名称。root@jnpr-apm-mgmt> show apm alarms Entity Pool Domain Alarm Info Age 10.4.4.108 vks009-default reclaim vks009-default-0005 2:33:15 10.2.1.1 alpha-drop reclaim alpha-drop-0000 3 days, 15:20:01 10.3.23.10 feeder-default apportion - 0:0:10 152.13.5.5 azimuth-ri2 pool-drained azimuth-ri2-0007 0:0:21
reclaim
告警表示池域有多余的地址。该Info
字段包含 BNG 建议回收的池的名称。回收警报并不意味着池具有活动的排水装置。如果池上没有排水管,池仍然可以分配地址。- 发出
request apm drain
命令开始清空池。root@jnpr-apm-mgmt> request apm drain entity 10.2.1.1 pool-domain alpha-drop pool alpha-drop-0000
注意:您可以通过发出
request apm activate
命令来移除已启动的排水管。 show apm alarms
使用命令查看池是否已排空。报警状态显示状态pool-drained
。- 发出
request apm reclaim
命令开始回收。APM 取消预配池,并将地址返回到源分区进行重新分配。root@jnpr-apm-mgmt> request apm reclaim entity 10.2.1.1 pool-domain pool alpha-drop-0000
选择手动回收时,请谨慎选择要回收的池。以下是选择要回收的池的一些注意事项。
-
清空池时,必须容纳使用池域中其他池中的这些地址的订阅者。其他池(域中)必须有足够的可用地址来吸收这些订阅者。因此,池域中的可用地址数必须大于清空的池中的已用地址数:
(池域可用地址) –(排空池可用地址) >(排空池使用的地址)
-
当您清空池时,您一定不能让池域立即面临可用地址耗尽的危险。如果域中的可用地址计数低于 apportion 阈值,则会触发 apportion 警报,导致 APM 为池预配更多地址。换句话说,除非以下不等式成立,否则尽量不要在池上启动排水:
(池域可用地址) - (排空池总地址数) > (分配阈值)
时间 戳
您可以使用命令 show apm entity
监控 APM 的回收作。当您显示路由器或特定池域的统计信息时,命令输出会显示上次发现、上次分配和上次回收事件的时间戳。时间戳采用 ISO-8601 格式,时钟为 24 小时制:
YYYY-MM-DDThh:mm:ssZ
-
T 是日期和时间之间的分隔符。
-
Z 表示时间在 UTC 时区。如果路由器时间使用不同的时区,则格式会显示与 UTC 的偏移量,以标识时区。
-
UTC 以西的时区有一个负偏移量,由 –hh:mm 表示。
-
UTC 以东的时区有一个正偏移量,由 +hh:mm 表示。
例如,假设标准时间,以下时间戳都显示相同的时间:
-
2020–03–20T15:10:25Z(伦敦)
-
2020–03–20T10:10:25-05:00(纽约)
-
2020–03–20T16:10:25+01:00(巴黎)
-
2020–03–20T23:10:25+08:00(北京)
APM 和 Kubernetes
APM 在 Kubernetes 群集环境中运行。APM 是一个容器化应用,其中 Kubernetes 是容器的编排器。它将容器分组到逻辑单元 (Pod) 中,从而简化管理。APM 命令和 CLI 简化了与 Kubernetes 的交互。
借助 Kubernetes,您可以自动重启 APM 微服务。由于 Kubernetes 将微服务部署为副本集,因此可以确保在 Pod 发生故障时,包含微服务的 Pod 会重新启动。在初始部署和重新启动时,服务容器会检查配置是否已完成加载。服务 Pod 还会验证它是否可以连接到数据库和消息代理。成功确认后,APM 服务将启动。
Kubernetes 为 APM 功能提供冗余,因为它在由多个节点计算机组成的集群中分发和管理应用容器。每个节点在群集中可以扮演一个或多个角色。
-
控制平面 (etcd) 节点 — 控制平面节点负责跨可用节点调度应用工作负载 (Pod)。控制平面节点支持辅助角色、与工作负载相关的存档状态、监控节点可用性和工作负载状态。控制平面节点可确保应用程序在群集上的持续运行。
-
工作节点 - 工作节点是应用程序工作负载的计划目标。
如果选择使用虚拟机构建群集节点,则这些虚拟机必须位于不同的物理节点上。使用不同的物理节点可确保群集节点的最大可用性。如果工作节点发生故障,Kubernetes 控制平面会检测到故障。它会尝试将在故障节点上运行的工作负载重新调度到群集中的其他工作节点。
h
APM 使用的数据库服务至少需要三个物理工作节点才能为应用程序提供高可用性。
复制提供数据库冗余。主数据库实例复制到一个副本数据库实例。每个实例都是一个单独的 Pod。奇数个数据库哨兵实例监视主数据库实例和副本数据库实例。当哨兵检测到主实例的故障时,大多数哨兵必须同意。然后,大多数哨兵必须选择副本实例来提升为主要角色。如果前一个主实例恢复,它将承担副本实例的角色。
APM 置备的 Kubernetes 对象
APM 在启动或推出期间创建以下 Kubernetes 对象。APM 在其整个生命周期中都使用这些对象。这些对象在 apm stop
上被移除。
-
命名空间 - 运行 APM 的节点计算机的虚拟群集。所有 APM 对象在 jnpr-apm 中都是隔离的。
-
外部服务 (External-Services) - 在设置时创建对象,以获取集群的负载均衡器(入口控制器)分配的外部 IP 地址。群集外部的外部服务使用这些外部 IP 地址发起与 APM 的通信。如果集群不支持网络负载均衡器,集群将使用主节点作为外部 IP 地址。
-
ConfigMap - 存储数据库服务器的配置文件 (redis.conf) 和 MGMT 的初始配置文件 (juniper.conf)。
-
PersistentVolumeClaims - 适用于具有动态数据存储要求的容器。此对象包括 MGMT 和数据库部署。
-
机密 — 存储保护 APMi 所需的密钥和证书。
自动存档 APM 配置
APM 在首次启动和推出时会使用初始配置文件。配置文件可以是出厂默认配置文件,也可以是您在安装过程中提供的配置文件。此初始配置文件存储在跳转主机的群集存储库中。将更改提交到配置后,可以在执行 APM save-config
实用程序脚本命令时更新启动和推出期间使用的初始配置文件。
使用自动存档功能,可以将 APM 设置为自动将已提交配置的副本存档到外部文件服务器。每次更改和提交配置时,APM 都会将提交的配置文件的副本传输到外部文件服务器。
您可以通过 setup
命令配置配置文件的自动存档。这与最初设置 APM 时使用的命令相同 setup
。
如果在设置过程中未先配置自动存档,并且希望将配置更改自动保存到外部配置文件,请执行以下作:
setup
运行命令(有关详细信息,请参阅地址池管理器安装指南)。在设置过程中,配置以下内容:Config Archival copy rollback configs — 输入可 True 归档回滚配置文件。
Config Archival retain source filename — 输入 True 以使用存储在 管理 微服务文件系统中的文件名(例如 juniper.conf.gz)复制配置文件。如果输入 False,则存档的配置文件名前置前缀 apm_<date-stamp>_<time-stamp>_。
Config Archival secret — 在包含 SSH 私钥数据的 APM 命名空间中输入 Kubernetes Secret 的名称。
如果未提供机密,系统将提示您输入 SSH 密钥文件:
Config Archival ssh-key — 输入 SSH 私钥文件的名称。
配置存档 SCP URL — 输入将存档配置文件的服务器的安全复制协议 (SCP) URL。URL 的格式
scp://user-login@server-fqdn:server-port/absolute-file-path
必须为 。注意:服务器端口号 (
server-port
) 是可选的。
如果APM已经运行,请执行
rollout
命令更新 管理 微服务。
使用具有多个地理冗余的 APM
APM 可以设置为在多地理位置、多集群环境中运行。多地理位置、多群集设置提高了 APM 的可用性。在这种类型的设置中,如果数据中心出现完全故障,APM 可以保留其状态并恢复运行。
Kubernetes 提高了解决方案的可扩展性、运维效率和可靠性。Kubernetes 云的模块化使群集架构具有无与伦比的冗余性。即使是最冗余的群集架构也容易受到自然灾害或网络攻击等事件的影响,这些事件可能针对特定位置或地理位置。多地理位置、多群集设置可以缓解这些影响。
图 5 显示了多地理位置、多集群设置的示例。

在多地理位置、多群集设置中,管理群集维护一个单独的上下文,用于运行多个群集调度和监控功能,并连接到两个工作负载群集。多集群上下文由策略引擎驱动,该引擎通知调度程序如何在工作负载集群之间分配应用程序。使用多集群设置实现多地理冗余的应用程序具有将状态复制中涉及的应用程序微服务分发到两个工作负载集群的策略规则。其他应用微服务分布到一个被选为主工作负载群集的工作负载群集。
工作负载群集通过 Kubernetes REST API 接受来自管理群集的工作。工作负载群集是标准 Kubernetes 群集。工作负载群集之间会保留一条安全的 L3 隧道。该隧道有助于两个工作负载群集之间交换应用程序状态和常规通信。作为标准 Kubernetes 集群,工作负载集群监控 Pod 和部署,并为集群中的工作节点执行调度任务,从而维护已部署的应用组件。工作负载群集不需要管理群集的存在来维护其应用程序工作负载。部署应用程序时,工作负载群集负责维护应用程序部署。
如果管理集群检测到工作负载集群出现故障,或者无法在工作负载集群上令人满意地安排应用的微服务,则管理集群将启动切换事件。切换作由为应用程序定义的策略控制。在切换事件中,仅存在于故障工作负载群集上的任何应用微服务将被重新部署到另一个工作负载群集。
APM 可以部署在多地理位置、多集群环境中。APM 的 Helm 图表包括传播策略规则,这些规则指示管理集群的多集群上下文在两个工作负载集群上部署 dbSync 微服务的实例。这两个 dbSync 实例通过安全隧道进行通信,以镜像存储在两个地理位置之间的数据库中的分区状态。数据库微服务和 dbSync 微服务将部署到两个工作负载集群。dbSync 微服务确保数据库在两个地理位置之间同步。APM 的大部分工作负载和微服务在一个工作负载集群上运行,必要时会切换到另一个工作负载集群。
图 6 显示了多地理位置、多群集设置中的 APM。

如果工作负载群集发生故障,管理群集会在另一个工作负载群集上重新调度 APM。当 APM 在第二个工作负载集群上初始化时,它会从由 configserver 微服务维护的复制配置缓存中恢复其配置。APM 还会从本地数据库实例中恢复其分区状态,就像在任何微服务重启时一样。由于本地数据库从上一个工作负载群集接收了复制状态信息,因此将恢复所有分区状态。其他状态(如池域和池状态)在实体重新连接并循环执行其正常同步过程时直接从实体恢复。
APM 还会在管理群集上部署称为观察者的微服务。观察者在管理群集的常规上下文中运行,并在多群集上下文(与管理群集关联)中监视 APM 调度事件。在两个工作负载群集中可能暂时存在 APM 的切换情况下,观察器允许 APM 解决应运行哪个 APM 的任何歧义。
例如,如果管理群集无法再访问或监视工作负载群集,则管理群集会声明工作负载群集发生故障。管理群集启动工作负载从发生故障的工作负载群集到另一个工作负载群集的切换。
如果发生故障的工作负载群集可运行,但无法从管理群集访问,则会导致部署不明确。两个工作负载群集上都存在多个应用程序工作负载实例。由于管理群集是工作负载在多群集部署中运行位置的最终仲裁者,因此需要一种机制来强制工作负载群集上被认为未能进入非活动或休眠状态的重复工作负载,以尊重其切换的对应工作负载。
如前所述,观察者微服务在管理群集上运行。观察者会监视应用程序工作负载的调度事件。每次在工作负载群集上安排应用程序工作负载时,观察者都会为该工作负载分配一个唯一的代号。当同一工作负载切换到另一个工作负载群集时,代数会递增。当应用程序工作负载初始化时,它们会向观察者请求其代号。代号在工作负载群集之间传递。发生故障的工作负载群集上的应用程序工作负载请注意,同一工作负载在其他工作负载群集上的代数更高,并将工作负载群集转换为休眠状态(所有连接都将被丢弃,不会生成或使用任何状态)。
代号有助于更正由于管理群集无法查看故障工作负载群集的真实状态而导致的不明确部署。将可访问性还原到故障工作负载群集时,管理群集将删除休眠的应用程序工作负载。