Apache IoTDB 分布式架构三部曲（一）集群概念
Apache IoTDB 在 1.0 版本推出了全新的原生分布式架构。数据分区存储，具有高可扩展性；多副本存储，无单点故障，具备高可用性；搭配多种一致性协议，可适配不同场景。那么：
IoTDB 分布式架构是什么样的？
我们该如何高效的运用 IoTDB 的分布式能力？
跟随我们一起用三篇文章来解密 IoTDB 分布式相关的细节！
本篇文章将主要介绍 IoTDB 的分布式架构特点，该如何根据需要运维 IoTDB 集群。
01 IoTDB 分布式架构
那么什么是分布式？分布式系统是一组独立的计算机，通过网络进行通信，对外表现为一个统一的整体。
具体到 IoTDB 中，IoTDB 的原生分布式架构将服务分为了两个部分：
ConfigNode（简称 C、CN）：管理节点，管理分区表和节点信息等，负责整个集群的负载均衡等功能。
DataNode（简称 D、DN）：数据节点，大致上可以分为五个主要模块：
查询引擎：负责查询语句的解析，分布式查询算子的计算，调度等；
存储引擎：负责面向数据场景特殊优化的类 LSM 引擎时序数据高速写入；
元数据引擎：负责管理元数据，包括内存中的元数据及其持久化；
共识引擎：负责管理多个副本之间的可用性和一致性等；
流处理引擎：负责对实时数据进行高效的抽取，处理和预警等。
该架构图就是常用来举例的 3C3D 集群，即集群中有 3 个 CN，3 个 DN。
在实际使用过程中：
CN 一般配置 1 个或者 3 个，CN 只向 DN 提供服务。
DN 可以依据业务情况配置至少 1 个（目前 IoTDB 最高有配置 3C100D 的线上环境哦）。
Client 可以连接任意一个或多个已经启动的 DN。并且无论是连一个还是多个，都能够读取集群全部的数据，也能够完成任意数据的写入。Client 对于 CN 是无感知的。当 Client 配置连接多个 DN 的时候，连接的部分节点宕机时会完成 Client 无感知的连接切换，不影响写入及查询，实现高可用。
02 集群运维
在了解了 IoTDB 的分布式架构后，让我们以一个 3C3D 集群为例，结合分布式的相关知识，来讲讲该如何高效的运维它。
（1）部署
DN 管理数据需要大量的资源，因此一般推荐多个 DN 部署在不同的节点上。
CN 管理集群内的 CN 和 DN 节点，需要的资源较少，因此可以部署在与 DN 相同的节点上，也可以单独部署在节点上。
以 3C3D 集群为例，一般会部署在 3 台物理机上，每一台机器上部署 1C1D。
修改 hosts 文件，首先需要修改 3 台物理机的 hosts 文件，在 3 台机器上执行：
（2）启动
由于 CN 管理集群内的 CN 和 DN 节点，所以需要先于 DN 启动。
所有的 CN 和 DN 初次启动的时候，都需要向已经启动的 CN 注册信息，即配置 cn_seed_config_node 和 dn_seed_config_node。特殊的，对于第一次启动的第一个 CN，将 cn_seed_config_node 设置成自身即可。
因此一定要保证第一个 CN 启动成功后，再启动其余的 CN 和 DN。
修改配置文件，配置文件在 /data/iotdb/conf 目录下。按照下表修改相应的配置文件：
启动第一个节点，登录 cn_seed_config_node 节点即 iotdb-1(192.168.132.10) ，执行如下命令：
注意：
a. 要保证第一个节点启动成功后，再启动其他节点。确切的说，要先保证第一个 CN 服务启动成功，即 cn_seed_config_node 配置的节点。
b. 如果启动失败，需要参照下文，执行清理集群后，再次启动。
启动剩下两个节点的 CN ，在节点 iotdb-2(192.168.132.11) 和 iotdb-3(192.168.132.12) 两个节点上分别执行：
启动三个节点的 DN，在三个节点上分别执行：
校验集群状态，使用 Cli 连接任意节点，执行如下操作：
（3）停止
由于 DN 负责和客户端（Client）连接，CN 负责管理 CN 和 DN。
因此应该遵从 Client->DN->CN 的关闭顺序。
停止所有的读写业务，即停止客户端连接。
停止所有的 DN，在 3 个节点上，执行如下操作：
停止所有的 CN，在 3 个节点上，执行如下操作：
（4）升级
当进行集群升级时，不同版本之间的数据，日志等信息是可以兼容。但是由于新增功能，修复 bug 等原因，相关的 lib 库会更新，同时有时也会更新相应的脚本，因此需要更换 lib 目录和 sbin 目录。
参照上文先执行集群停止操作。
在每一个节点删除 IoTDB 根目录下旧版本的 lib 目录及 sbin 目录：
将新版本的 lib 目录和 sbin 目录移动至 IoTDB 根目录下。
参照上文执行集群启动操作。
（5）扩容
当提到集群扩容时，我们一般指的是要为了提升 IoTDB 整体的性能，此时一般横向扩展更多的节点并在上面部署 DN。
扩容方式与上方启动其他节点相同。也就是，在要添加的节点上，下载 IoTDB 的安装包，解压，修改配置，然后启动。这里要添加节点的 IP 为 192.168.132.13。
注意：
扩展节点必须是无数据的空节点，即其 data 目录中不能包含任何数据。
iotdb-common.properties 中的 cluster_name 的配置必须和已有集群一致。
cn_seed_config_node 和 dn_seed_config_node 的配置必须和现有集群保持一致。
已有数据不会自动迁移到新节点，新的元数据和数据会分配到新节点上。
修改配置，在原节点上新增一行 hosts：
在该节点设置 hosts：
按照下表修改相应的配置文件：
扩容，在新增节点 iotdb-4(192.168.132.13) 上，执行：
验证扩容的结果，在 Cli 执行 show cluster，结果如下：
同样的，参考上文的集群启动修改相关配置，用 start-confignode.sh 脚本启动 CN 也能实现 CN 的扩容（一般情况下 CN 的个数达到 3 就能实现高可用，不用扩容到个数大于三个）。
（6）缩容
当提到集群缩容时，也一般指的是减少 DN 的数量，可以移除集群中已启动的 DN：
在 Cli 执行 show cluster 验证结果：
当然也可以通过 remove-confignode.sh 脚本移除集群中已启动的 CN 来实现缩容集群。
（7）清理
当您想修改某些启动后无法更改的参数，或者启动过程中步骤出错，导致启动失败，或者一些其他原因，想要获取一个“崭新”的 IoTDB 时，您需要清理集群，主要是清理 data 目录。
参照上文执行集群停止操作。
清理数据，具体的可以通过在每一个节点上执行：
当然也可以通过如下命令：
参照上文重新集群启动操作。
这样再次重新启动后您就获得了一个“崭新”的 IoTDB。
03 总结
本篇文章是 Apache IoTDB 分布式架构三部曲中的第一篇，主要是介绍 IoTDB 原生分布式架构，以及如何基于此架构来高效运维集群。
想知道 IoTDB 是如何在这套分布式架构下，实现在 3 节点的场景下支持 2 副本的上亿时间序列的高可用高性能的运行和维护么？后续我们将解密 IoTDB 分布式中的两个核心设计：
数据分片与负载均衡
副本、共识协议与高可用
希望读者可以通过这个系列文章，理解 IoTDB 的分布式设计，高效的使用 IoTDB 集群。
更多内容推荐：
• 了解如何使用 IoTDB 企业版
• 了解更多 IoTDB 应用案例
还未添加个人签名 2021-12-30 加入
海量时序数据管理的解决方案，一款高吞吐、高压缩、高可用、物联网原生的开源时序数据库。
评论