TDengine容器化部署的最佳实践

随着容器化的流行,越来越多的项目采取了容器化方案来设计架构、实施部署。

作为时序数据引擎核心的TDengine Database,在部署时一般建议采用FQDN(Fully Qualified Domain Name,完全限定域名)来进行节点之间的通信。很多客户在进行容器化架构设计时,通信方式均采用IP地址寻址,而且由于这些容器的IP、容器名(也就是hostname)会随着容器的生命周期变化而变化,这就给TDengine采用hostname作为FQDN寻址进行通信带来了困难。

本文将结合实际,尝试给出一最佳实践建议,以实现以下两个需求:

  • TDengine集群节点采用IP地址寻址
  • 应用端无需配置集群节点IP/FQDN地址,而仅采用LoadBalancer域名作为firstEP实现集群寻址

假设TDengine集群由两个节点组成,IP分别为172.16.31.1和172.16.31.2。

在深入之前,希望读者先对TDengine的整体架构有所了解,可以参考:https://tdengine.com/docs/cn/v2.0/architecture#cluster

我们再来强调TDengine Database中的几个概念:

  • 物理节点(pnode): pnode是一独立运行、拥有自己的计算、存储和网络能力的计算机,可以是安装有OS的物理机、虚拟机或Docker容器。物理节点由其配置的 FQDN来标识。
  • 数据节点(dnode): dnode 是 TDengine 服务器侧执行代码 taosd 在物理节点上的一个运行实例,一个工作的系统必须有至少一个数据节点。dnode包含零到多个逻辑的虚拟节点(VNODE),零或者至多一个逻辑的管理节点(mnode)。dnode在系统中的唯一标识由实例的End Point (EP )决定。EP是dnode所在物理节点的FQDN和系统所配置的网络端口号(Port)的组合。
  • 管理节点(mnode): 一个虚拟的逻辑单元,负责所有数据节点运行状态的监控和维护,以及节点之间的负载均衡。同时,管理节点也负责元数据(包括用户、数据库、表、静态标签等)的存储和管理。

客户端初始化的基本流程是:应用通过taosc原生接口访问TDengine,需要通过firstEP找到集群,获取到集群的元数据(meta-data),也就是集群所有节点列表(FQDN 或 IP列表)。客户端驱动一旦获得列表后,即可按列表与集群对应的节点进行通信了。默认的通信方式是:15K以下的数据走UDP协议,15K以上的走TCP协议。

理解了以上流程,我们就可以利用负载均衡器LoadBalancer的相关特点帮助我们实现去hostname的容器化部署了。当然,本方案也同样可以用在非容器化部署,但希望采用IP地址部署TDengine的场景。

TDengine容器化部署的最佳实践 - TDengine Database 时序数据库

在这个方案里,firstEP指向LoadBalancer的域名及对应的端口(默认为6030)。我们假设LoadBalancer的域名是lb.taosdata.com。TDengine集群节点寻址采用IP地址作为FQDN:172.16.31.1/172.16.31.2。

应用通过客户端驱动去连接firstEP:lb.taosdata.com:6030。LoadBalancer收到请求后,根据预先设定好的负载均衡策略,将请求转发给预设的TDengine节点——172.16.31.1:6030 或 172.16.31.2:6030,收到该消息的节点将meta-data消息原路返回给请求者(如当前节点不是mnode主节点,会触发重定向,后续流程类似),最终应用/客户端应用驱动刷新获得了meta-data列表。

之后,应用需要建立与集群任一节点的通信时,无需通过LoadBalancer,将直接通过已获得的IP列表发起连接,实现通信。

TDengine容器化部署的最佳实践 - TDengine Database 时序数据库

最后一点,也是最重要的一点:如果完成以上步骤不能成功通信,那么有可能是您的LB不支持UDP,或UDP丢包率过高导致。解决方法很简单,打开所有节点(包括所有客户端和服务端)的rpcForceTCP开关,将所有发起的通信转为TCP通信而不再采用UDP通信,确保穿透LoadBalancer的通信均走TCP实现。