ThingWorx 群集规模定制考虑因素
ThingWorx Foundation 节点规模定制
在群集操作中，单个 ThingWorx Foundation 节点的规模几乎没有变化。每个群集节点必须有足够的内存来加载整个事物模型。因此，每个群集节点的大小必须与单个服务器节点的大小相匹配。例如，中等大小的单个服务器为 16 vCPU 和 32 GiB RAM。同样，对于双节点群集，每个群集节点均为 16 vCPU 和 32 GiB RAM。
如果单独部署 Apache Ignite，则 Foundation 服务器内存消耗可能会略微减少，因为属性状态信息已传输到 Ignite 节点。
CPU 使用率会因为系统执行后台群集同步任务而增加。另外，由于共享缓存延迟增加，因此群集配置中的各个操作也可能会稍慢一些。这可通过跨多个节点并行运行更多操作 (业务逻辑和/或用户请求) 来抵消。
对于高可用性，一旦确定了单个节点的适当大小，建议您至少再额外部署一个 ThingWorx Foundation 节点，以处理应用程序的峰值负载。这也可使得群集在出现单节点故障时继续满足用户对性能的期望。
连接服务器节点规模定制
在群集操作中，需要使用连接服务器以在群集内分布设备载荷，或在节点失败时重新分布设备载荷。
与 Foundation 节点一样，建议在预期设备计数基础上至少再额外部署一个连接服务器。这可使得连接服务器能够在单个连接服务器节点出现故障时保持与所有设备连通。
有关各连接服务器选项的系统要求，请参阅 ThingWorx 连接服务帮助中心。
Apache Zookeeper 节点规模定制
Apache ZooKeeper 是用于分布式应用程序同步的开源解决方案。它会为 ThingWorx 节点提供监控和主导节点选择服务。
建议使用三节点设置，每个节点使用 2 个 vCPU 和 2 个 GiB RAM。要保持仲裁，需要使用奇数个实例。
有关详细信息，请查看 Apache Zookeeper 系统要求：https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_systemReq
数据库节点规模定制
除高可用性外，ThingWorx 群集配置中的数据库负载也会增加。为说明这一点，已使用 Microsoft Azure 虚拟机对五个不同中型部署执行了相同的负载测试：
|
单节点与群集性能比较 (仅限 PostgreSQL)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
无
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
|
InfluxDB
|
无
|
无
|
无
|
无
|
无
|
|
每个节点的结果数 (平均值)
|
26,000 WPS
19 HTTP Ops
|
12,000 WPS
10 HTTP Ops
|
10,000 WPS
6 HTTP Ops
|
7,000 WPS
6 HTTP Ops
|
6,000 WPS
2 HTTP Ops
|
|
结果总计
|
24,000 WPS
19 HTTP Ops
|
30,000 WPS
24 HTTP Ops
|
28,000 WPS
22 HTTP Ops
|
30,000 WPS
12 HTTP Ops
|
|
|
提示：此规模定制指南中所提供的建议旨在通过初始基线来定制 ThingWorx 实现的规模。个别结果将会因为边缘配置、应用程序加载的不同而有所不同。
|
|||||
尽管以上测试结果显示数据获取方面有小幅改善，但由于数据库资源不足，HTTP 请求性能并未提高。
为解决此问题，可通过使用更大的 RDBMS 实例和/或 InfluxDB 来改进可扩展性，如下所示。
|
单节点和群集性能比较 (PostgreSQL + InfluxDB)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
无
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
InfluxDB
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
每个节点的结果数 (平均值)
|
90,000 WPS
120 HTTP Ops
|
53,000 WPS
187 HTTP Ops
|
39,000 WPS
148 HTTP Ops
|
31,500 WPS
127 HTTP Ops
|
27,000 WPS
108 HTTP Ops
|
|
结果总计
|
106,000 WPS
375 HTTP Ops
|
118,000 WPS
445 HTTP Ops
|
126,000 WPS
508 HTTP Ops
|
135,000 WPS
540 HTTP Ops
|
|
|
提示：此规模定制指南中所提供的建议旨在通过初始基线来定制 ThingWorx 实现的规模。个别结果将会因为边缘配置、应用程序加载的不同而有所不同。
|
|||||
 |
InfluxDB 开源用于进行上述测试，不提供高可用性。建议将 InfluxDB Enterprise 用于生产 ThingWorx 群集实施。对于 InfluxDB Enterprise 大小设定，考虑使用两个 InfluxDB "Data" 节点，外加三个 "Meta" 节点，通常每个节点具有 1-2 个 vCPU 和 0.5-1GiB RAM 。有关 InfluxDB 规模定制的详细指导，请参阅 https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/。
|
Apache Ignite 节点规模定制
在 ThingWorx 群集中，Apache Ignite 用于为属性值和其他数据 (如文件传输作业) 提供共享缓存。
Ignite 可以嵌入在 ThingWorx Foundation 程序中，而无需单独安装。而对于较大型负载分布，Ignite 也可以作为单独的群集进行部署。
此外，Ignite 可选择以下两种运行模式之一：
• PARTITIONED 模式 - 数据均匀分割为分区，并在参与节点之间平均分割。可提供最佳缓存-写入性能。
• REPLICATED 模式 - 各个 Ignite 实例都有每个数据点的副本。可提供最佳缓存-读取性能。
有关详细信息，请参阅缓存模式的 Apache Ignite 文档：https://apacheignite.readme.io/docs/cache-modes
Ignite 的主要负载是每个 ThingWorx Foundation 和 Ignite 实例之间的网络吞吐量。尽管 CPU、磁盘或内存需求可能会指示云提供工具的虚拟机大小比较小，但监控网络吞吐量的限制或阻止很重要。
如果遇到吞吐量问题，可通过移动到网络容量更大的系统或通过额外增加用于分配负载的 Ignite 节点 (使用 PARTITONED 模式) 予以解决。
作为粗略的起始点，使内存大小等于 ThingWorx Foundation 节点大小将是安全的保守估计。
要更精确地计算共享缓存的内存需求量：
1. 计算 ThingWorx 属性缓存的 VTQ (值、时间戳和质量) 内存需求量。
a. 针对每种事物类型确定内存中的数据类型大小。例如，如果属性是 50 个字符的字符串，每个字符需要 2 个字节，则该字符串需要 100 字节的内存。
b. 加上 8 个字节。(4 个字节用于该值的日期/时间，4 个字节用于该值的质量)。
c. 乘以 2。ThingWorx 会缓存每个属性的当前值和上一个值。
d. 乘以该类型事物的数量。
e. 将每种事物类型的结果相加。
2. 增加 30% 作为 Ignite 的内存中值索引。
3. 乘以 Ignite 群集中所需的数据副本数。例如，如果您想要对数据进行一次备份，以在单个 Ignite 节点失败时不会丢失任何数据，则乘以 2。
4. 除以计划部署的 Ignite 群集节点数。
5. 每个 Ignite 节点大约需要额外增加 300 MB 以支持其自身运行。
有关其他详细信息，请参阅 Apache Ignite 文档：https://apacheignite.readme.io/docs/capacity-planning