如何彻底搞懂TDengine的fqdn概念?这一篇文章就够了

·  阅读 499
如何彻底搞懂TDengine的fqdn概念?这一篇文章就够了

**小T导读:**很多新用户在配置TDengine的时候,偶尔会因为没有配置好FQDN,导致出现“unable to resolve FQDN”问题。所以大家会因为这个问题向TDengine的研发团队求助。本文会讲解FQDN的相关设计和配置,希望能帮助用户避免类似问题。

关于TDengine的FQDN机制,很多用户都表示:为什么TDengine要使用它,直接用IP不好吗?

其实是这样,早在2.0之前的版本TDengine 确实是使用IP的。但是考虑到很多生产环境下IP都是会变动的,所以自2.0版本后,我们就引入了FQDN机制。

首先,为了避免混淆,我们要澄清两个概念,避免混淆,一个是TDengine的“fqdn参数”,一个是作为网络服务的FQDN概念本身。当作为一个概念的时候,FQDN又和域名、hostname这些概念有关,因此我们需要仔细理解。

所以,为了让大家理清这个逻辑,在文章中我们会用“fqdn参数”和“FQDN”来分别指代参数和FQDN概念本身。

FQDN的全称是Fully Qualified Domain Name。与域名相对,我们暂且翻译成全域名比较好理解一点。

FQDN分为两部分组成:

1.Hostname:主机名,一般来说Linux当中运行hostname命令就可以获取,例如TDengine1;

2.Domain:域名,如taosdata.com

所以一个全域名可以简单理解为一个带着主机名的域名。

因此,上述情况下一个完整的FQDN就应该是TDengine1.taosdata.com。但是为了方便快速体验,TDengine在安装后会直接默认取本机的hostname——TDengine1作为fqdn参数的值。

概念和背景介绍完之后,接下来我们进入配置阶段:

首先我们要明确的一件事就是——只要你需要从客户端远程连接TDengine,那么服务端的fqdn参数强烈建议要手动配置而不是默认值。而且在配置的时候,不论是ip形式还是FQDN形式都是可以提供给客户端用于连接的,配置方式如下:

在修改fqdn参数之后,我们要在/etc/hosts文件中(或DNS服务)添加上TD1和对外的ip地址。

最后,修改/var/lib/taos/dnode/dnodeEPs.json里面的fqdn信息,数据库服务就可以正常启动了。(如果初次安装数据库,服务仍未启动,则不会生成这些文件,可以忽略本步骤)

了解了服务端配置的正确配置方法后,接下来,我们才要开始分析客户端的连接问题。

其实,不论在服务端fqdn参数中指定的值是不是IP,客户端都是可以直接用IP来与服务端建立连接的。

如下图所示,分别是Linux和Windows客户端的连接界面:

所以,这套机制的核心不在于taos -h的参数是IP还是fqdn参数值。而是在于从服务端取回的fqdn参数值能否被解析成正确的IP,它才是关乎于你能否顺利操作数据的关键。

接下来,我要给大家举两个反例,也是大家经常遇到的两个场景。

已知,服务端的IP地址为192.168.56.161,fqdn参数设置为TD1。

出现场景1的原因是——在这个客户端的hosts文件(或者DNS服务)中,没有写TD1。上图中,客户端用taos -h 192.168.56.161连接到TDengine服务端,取回TD1作为通讯地址。当执行查询的时候,TDengine试图把TD1解析成ip却发现TD1并不在其中——这就是Unable to resolve FQDN。

场景2:

已知,服务端的IP地址为192.168.56.161,fqdn参数设置为TD1。

当查询数据的时候,TDengine试图把TD1在hosts文件(或DNS服务)中解析成IP。但是由于IP地址写错了。因此客户端解析出来的IP地址并不可用,从而无法建立连接——也就出现了“Unable to establish connection”的问题。

针对以上这两个常见问题,我们只要把服务端的fqdn参数值和IP,正确地写入到客户端的hosts(或DNS服务)文件中就好了。

那么,前面提到过的“如果需要客户端远程连接TDengine,我们就一定要手动修改服务端的fqdn参数值”又是为什么呢?

是这样的:因为TDengine会默认读取本机的hostname作为fqdn参数的值,所以很多新安装的数据库服务的fqdn参数都是“localhost”,或是“ubuntu”之类的名字。这时候如果你的客户端hostname恰好也是localhost或者ubuntu,解析后,客户端就会直接连到127.0.0.1(自己)——unable to establish connection发生了。

这个问题是新用户遇到频率超高的典型问题,所以最好的办法还是自己写一个新的fqdn值。

上述只是针对单节点数据库的连接情况,在集群中情况稍有不同,但原理始终一致。

如下图所示:A, B, C三台机器上分别部署TDengine形成集群。每个节点都是通过自身的hosts(DNS服务)文件解析FQDN后,寻址到IP后通过网络层互相通讯。

比如:当TD-A节点发送消息给TD-B的时候,需要在TD-A自身,找到TD-B对应的IP。因此我们需要在节点A的hosts(DNS服务)中添加节点B。

同理,当TD-B节点在主动给TD-A发送消息时,也需要在TD-B自身当中,找到TD-A对应的IP。因此我们需要在节点B的hosts(DNS服务)中添加节点A。

TD-C同上。

因此,如果节点之间互相通讯时出现Unable to resolved FQDN,一定是某一方的hosts文件(DNS服务)里,找不到对应的FQDN。

接下来我们加入客户端:

(这里我们要提一下TDengine的架构,其实在每一个安装包中都是自带客户端的,所以上面提到的情况中客户端已经在参与了,本段提及的客户端特指客户端与服务端分离的情况)

客户端和集群之间的通讯,通常是我们出错的重灾区。因为TDengine点对点的设计,容易让用户忽略掉除连接目标以外的集群服务器的网络问题。

一个正常的客户端远程连接集群的架构图应该如下图所示——TD-A,TD-B,TD-C都需要存在于客户端的hosts(DNS服务)当中。

在以上整个使用FQDN的链路当中,有任何1个不通都会出问题,但是这类错误通常都具有隐蔽性:我们知道TDengine是一款分布式的大数据处理引擎,所以它的数据不只存在于一个节点上,也不是只有一份。这时候如果你的客户端没有完全添加所有的fqdn到hosts(DNS服务)中,就可能会出现下面这种现象:

前几天你搭建了集群,show dnodes看到节点都是ready,随便查询了几张表都OK,写入几个表也没问题——测试过了,万事大吉。

但是未来的某一天,你突然发现在写入某张表的时候TDengine报错了,但是写入一些其他表就没问题——这是怎么回事呢?难道是bug?

并不是那样。

首先,集群中的数据库一般都是多副本的,这意味着一个虚拟数据节点(vnode)有多个副本,以Master-slave形式存在。而TDengine的查询操作可以在任意(Master或者Slave)节点进行,但是写入操作只能在 Master 节点上进行。所以,如果当你写入的那个表的Master节点恰巧就在你无法通过fqdn连接到的节点上时,这个写入操作就会报错。

事实上,集群连接的报错逻辑和单机版是类似的:如果客户端服务器没有在hosts(DNS服务)文件中配置正确的FQDN名字,就会报——unable to resolve FQDN。如果配置了FQDN名字但是ip配错了,就会报——unable to establish connection或者database not ready。

所以,这部分问题一般都是配置疏漏导致,官方文档原文如下:

“客户端也需要配置,确保它可以正确解析每个节点的fqdn配置,不管是通过DNS服务,还是 hosts 文件。”

因此,最简单的确认配置方法就是去查看所有节点的hosts(DNS服务)内容,看看他们关于集群节点的配置信息是否一模一样就可以了。

能看到这里并仔细思考过的读者们,我相信你一定已经扫清了关于FQDN的障碍了。而且,因为一些特定场景下出现的FQDN问题会结合着TDengine的典型的产品特性,所以借助这个问题你可以更加深入地理解TDengine的体系架构,为自己未来的使用做好更多的铺垫。

最后偷偷告诉大家,未来TDengine会在错误提示方面做出更多优化——以FQDN为例,将会告诉大家是从哪个节点到哪个节点 "unable to resolve FQDN",这样我们在遇到相关问题后,处理起来就会更加得心应手了。

分类:
开发工具