ThingWorx 高可用性
ThingWorx 高可用性概述
要缩短关键物联网 (IoT) 系统的停机时间，可以将 ThingWorx 配置为在高可用性 (HA) 环境中运行。本指南介绍了 ThingWorx 系统以及 ThingWorx HA 部署的构成组件所需的 HA 注意事项。
与仅用于满足功能和规模要求的部署相比，所有 HA 部署都需要额外的资源。这些额外资源分为硬件资源 (如服务器、磁盘、负载平衡器等) 和软件资源 (如同步服务和负载平衡器)。然后，配置其他资源，以确保 HA 部署内没有单点故障。
所有 HA 部署都应基于 SLA (服务级别协议)，用户可在其中分析应用程序部署的运行时间需求。例如，系统每月离线多少小时？能否满足系统故障停机或应用程序升级停机，或者能否同时满足这两种停机？HA 系统所需的额外资源数量取决于其要实现的 SLA。通常情况下，随着 SLA 的增长，用于满足 SLA 的资源需求也在增长。
定义
• 高可用性
一种系统或组件，能够在期望的长时间内连续运行。
• 主动/主动
同一应用程序中可同时运行的多个实例。
• 主动/被动
一次可运行一个的应用程序实例。其他实例可用并且能够根据需要接管服务。
• 主导节点或主节点
主动/被动 HA 配置中用于传送全部流量的活动服务器。
• 备用节点
主动/被动 HA 配置中在当前主导节点发生故障的情况下等待接管服务的服务器。
• 虚拟 IP 地址
表示应用程序的 IP 地址。使用虚拟 IP 的客户端通常会路由到负载平衡器，然后将该请求定向到运行该应用程序的服务器。
• 负载平衡器
一种设备，用于接收网络流量并将其分发给准备接受网络流量的应用程序。对于主动/被动 HA 配置，负载平衡器会将流量定向到当前主导节点。对于主动/主动 HA 配置，负载平衡器会将流量定向到多个应用程序之一。
• 故障转移
一种备份运行模式，当主要组件因故障或计划停机时间而不可用时，辅助系统组件将承担系统组件 (如处理器、服务器、网络或数据库) 的功能。
可实现高可用性的 ThingWorx 参考体系结构
高可用性配置中的 ThingWorx 如下图所示。
以下是此配置中的组件及其在 HA 部署中的角色：
• 用户和设备 - 在 HA 功能中没有角色。从这些角度来看，没有任何变化。即使主 ThingWorx 服务器发生变化，它们也会始终使用相同的 URL 和 IP 地址。
• 防火墙 - 无 HA 功能，可将其视为可选项。防火墙通常用于实现安全要求。
• 负载平衡器 - 负载平衡器用于管理其所支持应用程序的虚拟 IP 地址。传送到该虚拟 IP 地址的所有流量都将定向到可接收这些流量的活动应用程序。
• ThingWorx Connection Server - 接收来自资产的 Web 套接字流量并将其传送到 ThingWorx Platform。此类连接服务器可以在主动/主动配置中运行。将资产定向至特定连接服务器后，应始终使用同一连接服务器。如果该服务器离线，则应将资产重定向到另一个可用的连接服务器。
• ThingWorx Foundation - 接收所有用户和资产流量。ThingWorx Foundation 在具有一台主导节点服务器和一台或多台备用节点服务器的主动/被动配置中运行。主导节点服务器处于在线状态，并且将接收流量。当应用程序运行时，备用节点服务器将在预热状态下运行，但与数据库之间没有任何活动连接，并且不会接收流量。负载平衡器会将所有流量传送到主导节点。如果主导节点处于离线状态，则备用节点将升级为主导节点，然后将流量传送到该主导节点。
• ThingWorx 存储库 - 这些存储库为必需的存储位置，如 ThingworxPlatform、ThingworxStorage 和 ThingworxBackupStorage，以及为支持实现而添加的任何其他存储位置。对于 HA 环境，ThingWorx 存储库必须处于公用存储位置，在此，所有 ThingWorx 服务器 (主导节点和备用节点) 都可以对其进行访问。
• Apache ZooKeeper - ZooKeeper 是 ThingWorx 使用的一种集中式协调服务，可在任意给定时间选择其中一台 ThingWorx 服务器作为主导节点服务器。在每台 ThingWorx 服务器中嵌入一个 ZooKeeper 客户端，以维持检测信号并对配置中的更改 (例如当前 ThingWorx 主导节点发生故障) 作出响应。
• PostgreSQL - 对于 HA 配置，PostgreSQL 将通过热备用节点配置中的两个或多个服务器节点进行操作。其中一个节点可接收所有写入流量，而其他节点可接收所有读取流量。在所有节点之间激活流式复制，从而保持每个节点处于最新状态。
• Pgpool-II - 仅在 PostgreSQL HA 配置中使用。Pgpool-II 节点会接收 ThingWorx 请求 (读取和写入)，并将其定向到相应的 PostgreSQL 节点。Pgpool-II 还会监控每个 PostgreSQL 节点的健康状况，并可在其中一个节点处于离线状态时启动故障转移并对任务进行重定向。
• Microsoft SQL Server (未显示) - 使用 Microsoft 故障转移以确保至少一台 MS SQL Server 处于在线状态且可用。
• DataStax Enterprise (DSE) - ThingWorx HA 配置不需要 DSE 实现。如果需要满足实现的提取要求，请确保已对 HA 进行了配置。典型的 DSE 实现符合最高 HA 要求。它具有多个 Cassandra 节点 (用于收集内容) 和至少两个 Solr 节点。DSE 设计会将所有内容复制到至少一个其他节点。
安装前要求
注解和警告：
• 对于具备 HA 配置 (PostgreSQL、Microsoft SQL Server 和 DataStax Enterprise) 中关系数据库相关经验的数据库管理员 (DBA)，他们应使用此 HA 过程涉及的步骤。所需的知识包括安装、优化和高可用性群集。
• 此处提供的指南适用于部署 HA 环境。可能需要在生产环境中执行其他性能调整，但此处并未提供相关内容。
• 详细步骤示例可供参考，不过仅适用于 QA 或沙盒环境。安装程序可能需要在生产环境中编辑命令和设置，才能获得最佳性能。
• 在用于生产中之前，必须对所有故障转移配置进行全面测试和验证。
• 此过程中的步骤并未涉及故障恢复情景，在这种情景下会更正发生故障的主导节点，然后返回到主导节点位置。假定已修复故障组件并将其作为非主导节点组件返回到服务。
支持的操作系统
常规 HA 要求
虚拟 IP 地址
• 连接服务器的用户和资产 (如使用连接服务器)
• 连接到 ThingWorx Foundation 的连接服务器
• ThingWorx Foundation 到 PostgreSQL HA (如使用 PostgreSQL)
• ThingWorx Foundation 到 Microsoft SQL Server HA (如使用 Microsoft SQL Server)
硬件要求
此处提供的步骤假定 ThingWorx HA 配置中使用了完整硬件冗余。
• 应用程序的每个实例都应在单独的硬件上运行，以避免发生硬件级别的单点故障。例如，对于 ThingWorx 服务器，无论是物理、虚拟还是基于云的服务器，都不应在同一物理硬件上运行。
• ThingWorx HA 配置中的所有应用程序 (ThingWorx、PostgreSQL、DataStax Enterprise、ZooKeeper 等) 均需要遵守此要求，以减少硬件故障的风险。
• 此处提供的过程假定使用了冗余路由器、交换机、电源等。
HA 配置中的 ThingWorx 属性
应将 ThingWorx 属性设置为持久化，以防止在故障转移时丢失数据。如果属性并非持久化，则从主服务器到辅助服务器的故障转移将会清除内存值。
PostgreSQL 要求
• 在 RHEL 或 Ubuntu 环境下安装了 Pgpool-II 和 PostgreSQL 数据库。
• 至少有两个运行受支持的 PostgreSQL 版本的数据库主机服务器。建议使用三个。
• 典型部署为两个运行 Pgpool-II 3.7.<最新> 且配置了监视程序的服务器。这是此处给出的示例，但也可以选择其他不使用 Pgpool-II 的 HA 配置。
Microsoft SQL Server 要求
• 至少有两个运行受支持的 Microsoft SQL Server 版本的数据库主机服务器。
• Microsoft SQL Server 配置为通过下列其中一种 Microsoft HA 方法运行：
◦ AlwaysOn 故障转移群集实例
◦ AlwaysOn 可用性组
DataStax Enterprise 要求
• 最少五个 DataStax Enterprise 群集节点：
◦ 三个 Cassandra 节点
◦ 两个 Solr 节点
◦ (可选) 一个用于管理工作的 DSE OpsCenter 节点，因为 OpsCenter 对于操作而言不重要，并且不需要高可用性配置。
InfluxDB 要求
• 最少两个元节点；对于大多数用例，建议使用三个元节点
• 最少两个数据节点，建议使用偶数个数据节点
• 典型的部署应具有三个元节点，以及偶数个数据节点