ThingWorx 高可用性 > 发生故障时的预期行为
发生故障时的预期行为
本主题将介绍发生在 ThingWorx 群集配置中,对一个或多个组件故障作出响应的操作。
负载平衡器故障
操作和结果将取决于已部署的负载平衡器 HA 解决方案。如果负载平衡器具有在所有负载平衡器节点之间共享会话内容这一功能,则不应中断活动会话。
HAProxy 服务器故障
如果只有一个 HAProxy 节点发生故障或所有 HAProxy 节点均发生故障,则会出现以下情况:
ThingWorx 主导节点仍可通过其 IP 地址 (而非通过 HAProxy IP 地址) 进行访问。
通过 HAProxy 访问 ThingWorx 的请求将无法传送到 ThingWorx。
如果多个 HAProxy 节点中有一个节点发生故障,则会出现以下情况:
备用 HAProxy 成为新的主节点后,即会在 ThingWorx Composer 中识别现有用户会话。用户不必再次登录。
在备用 HAProxy 成为主节点之前,系统不会加载任何混搭。
在备用 HAProxy 成为主节点之前,系统不会加载 Composer 中的浏览实体。
在备用 HAProxy 成为主节点之前,请求不会传送到 ThingWorx。
ThingWorx 服务器故障
当 ThingWorx 服务器失败时,将发生以下情况:
会将服务器从负载均衡器中移除,因为健康检查 ping 将失败。其移除时间取决于检查频率。
ZooKeeper 将会检测到服务器已失败,将其从内部服务发现中移除并通知观察程序,如 Connection Server。
如果服务器是单例服务器,则 ZooKeeper 将通知其他服务器,并选择一个新的单例服务器。
连接到服务器的客户端在切换时可能会收到错误,但随后将重新连接到新服务器。
在服务器失败或服务器被终止的情况下,可能会丢失数据。在这些情况下,批处理队列中的数据将会丢失。如果服务器已关闭而不是失败,则取消注册服务器并从批处理队列中清除时将会出现数据丢失的情况。
ThingWorx Platform 节点关闭
只要有不少于一个 Platform 实例处于正常状态,便可在不影响系统的情况下重新启动其他节点。但是,如果所有 Platform 节点均已关闭或处于非正常状态,则存储在 ignite 中的状态将失去一致性。此时需要在重新启动前停止所有 Platform 和 ignite 节点。
1. 停止所有 Platform 节点。
2. 停止所有 ignite 节点。
3. 重新启动所有 ignite 节点。
4. 重新启动所有 Platform 节点。
如果未重新启动 ignite,则存储在 ignite 中的绑定映射和其他数据将失准,从而日积月累导致异常行为。
ZooKeeper 故障
节点故障
如果 ZooKeeper 节点中有一个节点故障,则会出现以下情况:
其他 ZooKeeper 节点会检测到要响应的故障。
如果发生故障的节点是当前主导节点,则系统会选择新的 ZooKeeper 主导节点。
多个节点故障
如果多个节点失败且 ZooKeeper 失去其仲裁,则系统会将其设为只读模式,并拒绝更改请求。
无法选择 ZooKeeper 主导节点,因为原始的三节点 ZooKeeper 设置预期在两台服务器可用时才可进行选择。允许的最大故障数 = ceil(N/2) - 1
其余的 ZooKeeper 实例既不是主导节点实例也不是备用节点实例。
所有客户端都将接收到 SUSPENDED,且最终会变为 LOST 状态。
ThingWorx 服务器
SUSPENDED 状态下,将取消分配单例角色。在此期间,不会运行任何计时器或计划程序。
LOST 状态下,所有节点都将关闭。
如果 ZooKeeper 在系统超时之前恢复,则会选择新的单一实例并继续处理。
连接服务器
如果 Connection Server 从 ZooKeeper 获取到 LOST 状态,则它将会关闭,因为 ThingWorx 服务器的状况未知。
Ignite
行为由其实施定义。有关详细信息,请参阅 https://apacheignite.readme.io/docs/zookeeper-discovery
假定 ZooKeeper 群集对群集中的所有节点始终可见。如果节点断开与 ZooKeeper 的连接,则该节点将会关闭,且其他节点会将其视为失败或断开连接。
Ignite 故障
Ignite 故障的影响取决于数据复制级别。应始终将 Ignite 配置为至少将数据存储在群集中的两个节点上。因此,如果任何一个节点丢失,都不会对系统产生任何影响。
而多个节点丢失时,可能会造成数据丢失,这也可能会将系统置于不一致状态。如果发生此类情况,建议您完全关闭 Ignite 和 ThingWorx。然后,可以依次重新启动 Ignite 和 ThingWorx。Ignite 是应用程序内存,如果丢失,则处理行为可能会非常不一致。
如果 Ignite 彻底失败,其中 ThingWorx 无法连接到任何 Ignite 节点,则 ThingWorx 将会关闭。
有关数据备份的信息,请参阅以下网站:
PostgreSQL 故障
此处针对 PostgreSQL 故障的讨论基于以下配置:
三个 PostgreSQL 节点 (写入器、读取器和备用节点)
在 PostgreSQL 节点之间使用流式复制
两个 Pgpool-II 节点,用于管理客户端对 PostgreSQL 节点的访问并管理 PostgreSQL 恢复过程
如果 PostgreSQL 服务器发生故障,则活动的 Pgpool-II 节点会检测到该故障并停止向该服务器传送请求。如果在发生故障之前未提交信息并将其复制到其他节点,则在发生故障时保存的用户或设备数据可能会丢失。
当主 PostgreSQL 节点发生故障 (假定同步节点和潜在节点已启动且正在运行) 时,会出现以下情况:
通过 Pgpool-II 对同步节点进行故障转移。此时,潜在节点将成为新主节点的同步节点。但仍可写入数据库 (例如创建新实体和将数据写入 BDWS)。
如果原始主节点重新启动,则需手动清理环境并将其配置为使用原始主节点。
当两个备用节点均发生故障时 (假定主节点仍处于开启状态且正在运行),会出现以下情况:
不会发生故障转移,且主节点应不存在可用于复制的节点。
Composer 仍可供访问。实体将会被加载,且可供查看,但无法保存。可以查看日志。
需要写入数据库的操作 (例如,创建和保存实体、将值设置为持久化属性以及添加流条目) 将不会成功,这是因为 PostgreSQL 必须将数据复制到备用节点。
当主节点和同步备用节点发生故障时,会出现以下情况:
会对潜在节点进行故障转移。现在,潜在节点即为不带可供复制的节点的主节点。
Composer 将可供访问。实体将会被加载,且可供查看,但无法保存。可以查看日志。
需要写入数据库的操作 (例如,创建和保存实体、将值设置为持久化属性以及添加流条目) 将不会成功,这是因为写入会挂起并最终失败。
当所有三个节点均发生故障时,会出现以下情况:
由于没有可用节点,因此不会发生故障转移。
Composer 没有访问数据库的权限。因此,不应加载实体,大多数服务将无法正常工作 (诸如平台子系统之类的子系统服务可能仍会工作),并且系统功能会受限 (日志、系统监控和混搭可能会起作用)。
将无法写入数据库或从中读取数据。
ThingWorx 和 PostgreSQL 故障
当 ThingWorx 主导节点和 PostgreSQL 主节点发生故障时,会出现以下情况:
ThingWorx 主导节点发生故障后,备用 ThingWorx 实例会成为主导节点,而 PostgreSQL 数据库的同步节点将成为 PostgreSQL 主节点。
PostgreSQL 数据库的潜在节点将成为新的同步节点。
ThingWorx Composer 可用,且可对 PostgreSQL 数据库执行写入操作 (可以创建、编辑和删除实体,也可以添加数据)。
如果原始 PostgreSQL 主节点必须重置为主节点,则必须手动清理 PostgreSQL 节点和 Pgpool-II。
Pgpool-II 节点故障
活动 Pgpool-II 节点故障
如果活动的 Pgpool-II 节点发生故障,则备用节点会检测到该故障,并对传送至 PostgreSQL 服务器的所有请求进行处理。登录到活动 ThingWorx 服务器的用户可能会在其应用程序中延迟,并且在 Pgpool-II 节点发生故障时,可能会丢失正在保存的用户或设备数据。
所有 Pgpool-II 节点故障
当所有 Pgpool-II 实例均发生故障时,ThingWorx 会失去对 PostgreSQL 内容的访问权限,而大部分功能将会失败。某些受限的功能可能会在以下区域中提供:
日志记录 - 应用程序日志可能仍会有错误消息更新。
系统监控 (如 MonitoringPlatformStats 混搭)
混搭 - 不依赖于数据库中的服务或数据的小组件可能仍有效。
非持久化属性的属性值
与数据库无关的服务。
ThingWorx 和 Pgpool-II 故障
当 ThingWorx 主导节点和 Pgpool-II 主节点实例同时发生故障时,会出现以下情况:
ThingWorx 主导节点将失去主导权,因此其中一个备用节点会成为主导节点。
Pgpool-II 主节点虚拟 IP 地址丢失。其中一个 Pgpool-II 备用节点将成为主节点,且虚拟 IP 地址将被重新分配给该主节点。
ThingWorx 备用服务器将尝试完全连接到数据库,且新的 Pgpool 主节点建立之后,连接即会成功。
将应用 ThingWorx 主导节点故障下所列出的步骤和行为。
Pgpool-II 和 PostgreSQL 故障
当 PostgreSQL 和 Pgpool-II 发生故障时,会出现以下情况:
PostgreSQL 备用节点将成为主节点。
Pgpool-II 备用节点将成为主节点,且虚拟 IP 地址将转至该主节点。
服务在故障转移期间暂时不可用。
这对您有帮助吗?