了解 Junos Space 群集内的逻辑群集

Apache 负载平衡器群集

Apache HTTP 服务器启用mod_proxy负载平衡器模块，在任何给定时间在群集中的两个节点上运行。这些服务器组成一个主动备用逻辑群集。它们都在 TCP 端口 443 上侦听来自 GUI 和 NBI 客户端的 HTTP 请求。所有客户端都使用群集的虚拟 IP （VIP） 地址来访问其服务。任何时候，VIP 地址仅由群集中的一个节点所有。因此，拥有 VIP 地址的节点上的 Apache HTTP 服务器将从 GUI 和 NBI 客户端接收所有 HTTP 请求，并充当主动负载平衡器服务器，而其他服务器则充当备用服务器。轮询负载平衡算法用于将请求分发到群集中所有节点上运行的 JBoss 服务器。负载平衡器还采用会话粘性来确保来自用户会话的所有 HTTP 请求都发送至群集中的同一节点。为此，服务器设置了一个名为 JSESSIONID 的 Cookie。此 Cookie 的值用于标识群集中为属于此用户会话的请求提供服务的特定节点。所有其他请求都包含此 Cookie，而负载平衡器会将请求转发到在此 Cookie 识别的节点上运行的 JBoss 服务器。

如果节点上的 Apache HTTP 服务器出现故障，该节点上的看门服务会自动重新启动该服务器。如果此节点拥有 VIP 地址，则在重新启动 Apache HTTP 服务器之前，GUI 和 NBI 客户端可能会经历短暂的服务中断。但是，这种中断只会持续几秒钟（通常为两秒），客户端很少注意到这种中断。另一方面，如果 Apache HTTP 服务器在当前不拥有 VIP 地址的节点上出现故障，则任何客户端或任何其他组件不会注意到任何副作用。看门狗服务重新启动服务器，服务器大约在两秒后恢复运行。

JBoss 群集

JBoss 应用服务器在所有节点上运行，Junos Space 群集中的专用数据库节点除外。这些节点组成一个全活动逻辑群集，而负载平衡器服务器（如前所述）将负载分布到所有节点。即使群集中的一个或多个 JBoss 服务器发生故障，仍可从幸存的节点继续访问应用程序逻辑。所有节点上的 JBoss 服务器均使用相同的配置启动，并使用 UDP 组播相互检测并形成单个群集。JBoss 还使用 UDP 组播来跨所有节点执行会话复制和缓存服务。

注意：

JBoss 服务器不在故障监控和性能监控 （FMPM） 节点和托管虚拟机上运行。

当某个节点上的 JBoss 服务器出现故障时，JBoss 群集中的其他节点会检测到此更改，并自动自行重新配置，以便从群集中移除出现故障的节点。其他群集成员检测故障 JBoss 服务器所需的时间取决于 JBoss 服务器进程是异常崩溃还是无响应。在前一种情况下，群集成员会立即检测到故障（约两秒），因为其与崩溃的 JBoss 服务器的 TCP 连接被操作系统关闭。在后一种情况下，群集成员大约在 52 秒内检测到故障。如果 JBoss 服务器崩溃，则节点上运行的看门服务 （jmp-watchdog） 会自动重新启动 JBoss 服务器。当 JBoss 服务器备份时，JBoss 服务器会自动被其他成员发现并添加到群集中。然后，JBoss 服务器会从群集中的其他节点同步其缓存。JBoss 服务器通常重新启动时间是 2 到 5 分钟，但可能需要更多时间，具体取决于已安装的应用程序数量、要管理的设备数量、已安装的 DMI 方案版本数等。

群集中的一个 JBoss 服务器始终充当群集的主服务器。主要指定的主要用途是托管部署为群集范围单一实例（HA 单例）的服务，例如，任何时候只必须在群集中的一个服务器上部署的服务。Junos Space 使用此类型的多项服务，包括提供单一计时器的作业轮询器服务（用于跨群集调度作业），以及用于监控和管理群集中节点的分布式资源管理器 （DRM） 服务。这些服务仅部署在指定为主的 JBoss 服务器上。

注意：

这并不意味着主服务不托管其他服务。非群集单一实例服务也托管在主服务器上。在配置 Junos Space 后，群集中出现的第一个 JBoss 服务器将成为主服务器。如果主服务器发生故障，JBoss 群集中的其他成员会检测到这种情况，并选择一个新的主服务器。

MySQL 群集

MySQL 服务器在任何给定时间在 Junos Space 群集中的两个节点上运行。这些节点组成一个逻辑主动-备用群集，两个节点都在 TCP 端口 3306 上侦听来自 JBoss 服务器的数据库请求。默认情况下，JBoss 服务器配置为使用群集的虚拟 IP （VIP） 地址来访问数据库服务。任何时候，VIP 地址仅由群集中的一个节点所有。因此，拥有 VIP 地址的节点上的 MySQL 服务器会接收来自 JBoss 服务器的所有数据库请求，而 JBoss 服务器充当活动虚拟服务器，而其他服务器则充当备用服务器。

如果您希望提高 Junos Space 网络管理平台和 Junos Space 应用程序的性能，可以添加两个 Junos Space 节点作为专用数据库节点运行。将任意两个 Junos Space 节点添加为主和辅助数据库节点时，MySQL 服务器将移动到两个专用数据库节点，并在 Junos Space 群集的前两个节点上处于禁用状态。这将释放 Junos Space 主动 VIP 节点上的系统资源，从而提高节点的性能。

JBoss 服务器使用单独的数据库虚拟 IP （VIP） 地址来访问专用数据库节点上的数据库服务。将节点作为专用数据库节点添加到 Junos Space 群集时，请为数据库指定 VIP 地址。此 VIP 地址由指定主数据库节点的节点所有。主数据库节点上的 MySQL 服务器充当活动数据库服务器，辅助数据库节点上的服务器用作备用数据库。 图 2 显示了在 Junos Space 群集中具有专用数据库节点作为 Junos Space 群集的一部分时，在 Junos Space 群集内形成的逻辑群集（Apache 负载平衡器群集、JBoss 群集和 MySQL 群集）。

每个节点上的 MySQL 服务器都配置了唯一的服务器 ID。此外，还会在节点上对称配置主/备份关系，以便第一个节点上的服务器配置为第二个节点为主节点：第二个节点上的服务器配置为主节点因此，这两个节点都能够充当另一个节点的备份，而运行在拥有 VIP 地址的节点上的服务器随时充当主节点，从而确保主备份关系交换机能够动态地作为 VIP 所有权交换机从一个节点切换到另一个节点。通过 MySQL 提供的异步复制解决方案 [2]（基于二进制日志记录机制），在主动（主）服务器上提交的所有事务都会近乎实时地复制到备用（备份）服务器。作为主操作的 MySQL 服务器（数据库更改的来源）将更新和变更作为“事件”写入二进制日志。根据记录的数据库更改，二进制日志中的信息会以不同的日志记录格式存储。备份服务器配置为从主数据库读取二进制日志，并在备份的本地数据库中执行二进制日志中的所有事件。

如果节点上的 MySQL 服务器出现故障，该节点上的看门服务会自动重新启动服务器。重新启动后，MySQL 服务器应该在 20 到 60 秒内启动。如果此节点拥有 VIP 地址，则 JBoss 可能会在 20 到 60 秒的这段时间内短暂遇到数据库中断问题。在此期间，需要数据库访问的任何请求均会失败。另一方面，如果 MySQL 服务器在当前不拥有 VIP 地址的节点上出现故障，JBoss 不会注意到副作用。看门狗服务重新启动服务器，服务器在不到一分钟后恢复运行。服务器备份后，会与后台的主服务器重新同步，而重新同步时间取决于中断期间发生的更改数。

Cassandra 群集

从 15.2R2 版开始，Cassandra 群集是可选逻辑群集，可包含在 Junos Space 群集中。当 Junos Space 交换矩阵内有两个或多个专用 Cassandra 节点，或者两个或多个 JBoss 节点且运行 Cassandra 服务，或者两者兼有时，将形成 Cassandra 群集。您可以选择在交换矩阵中除专用数据库节点和 FMPM 节点以外的任何或所有节点上运行 Cassandra 服务。在 Junos Space 节点上运行的 Cassandra 服务提供一个分布式文件系统，用于存储 Junos Space 应用程序（如 Service Now 生成的瞻博网络消息包 [JMB] 和 Network Director 生成的 RRD 文件）中的设备图像和文件。如果交换矩阵中没有 Cassandra 节点，设备映像文件和 Junos Space 应用程序文件将存储在 MySQL 数据库中。 图 3 显示了在 Junos Space 群集中将 Cassandra 节点作为 Junos Space 群集的一部分时形成的逻辑群集（Apache 负载平衡器群集、JBoss 群集、MySQL 群集和 Cassandra 群集）。

Cassandra 服务在采用主动-主动配置的所有 Cassandra 节点上运行，并实时复制 Cassandra 数据库。上传到 Cassandra 数据库的所有文件都会复制到 Cassandra 群集中的所有节点。JBoss 服务器以轮询方式向 Cassandra 群集中的 Cassandra 节点发送请求，并使用相应 Cassandra 节点的 IP 地址（eth0 接口的 IP 地址）访问节点。

如果任何 Cassandra 节点发生故障，Junos Space Platform 将无法将文件上传至 Cassandra 数据库或从 Cassandra 数据库中删除文件，直到已关闭的节点从交换矩阵中删除。如果删除所有现有 Cassandra 节点，则存储在 Cassandra 数据库中的文件将丢失。