DNS故障对TDW影响评估及改进方案探索
目前，TDW 集群的所有slaves机器都需要通过 DNS 域名解析方式连接 master，也就是在所有 slaves 机器上配置 master 的域名，而非直接的 IP 地址；用户需要使用 client 客户端来上传数据，client 和 master 互联也是采用 DNS 域名解析方式。此外，使用 DNS 域名解析的方式，可以使我们的平台具有更大的可扩展性。如果 master 主机宕机，我们可以直接修改 DNS 服务器 master 的域名指向， slaves 机器就会连接到新的 master 上。 Client 客户端的连接也是同样的道理。
可见， TDW 对 DNS 域名解析有一定的依赖。为了减少 DNS 故障带来的损失，我们进行了 DNS 故障对 TDW 影响评估。
一. TDW 各模块利用到 DNS 的情况分析
1. 存储引擎（ HDFS ）
- 文件系统名称（ fs.default.name ）：它用一个 URI 定义文件系统的协议、主机、端口等信息， URI 的主机采用域名加端口的形式。
- 文件系统的 Http 地址（ dfs.http.address ）： http 地址也是采用域名加端口的形式。
- Zookeeper 客户端：它的组成为主机域名加端口号
- 客户端（ DFSClient ）对文件系统的访问也是通过域名加端口进行访问，如果 DNS 出现故障，也会使其对 HDFS 进行访问造成影响。
2. 计算引擎（ MapReduce ）
- mapred.job.tracker：它的组成为主机域名加端口号
- mapred.job.tracker.http.address：它的组成为主机域名加端口号
- Zookeeper 客户端：它的组成为主机域名加端口号
- 在 Job 提交上，JobSubmitter 需要将 Job.jar 和配置文件上传到 HDFS， JobSubmitter 与 HDFS 通讯是通过域名进行。
- 在 Job 运行时，有一个步骤需要从 HDFS 中下载文件到本地，它访问 HDFS 是通过域名进行访问。
3. 查询引擎（ Hive ）
对于 Hive，它的数据存储在 HDFS ，当 HDFS 受到 DNS 故障影响， hive 也会间接受到影响。另外， Hive 的元数据保存各个数据表的路径，这些路径是由域名和域名的相对路径组成。
目前， Hive 的容灾方式是采用 DNS 方式，提供多点服务，它消除单点和负载不均衡问题。 DNS 具备负载均衡功能，接收到客户端的请求后， DNSserver 负责轮询域名对应的多个 HIVE 机器 IP ，并返回给客户端，达到负载均衡。DNS 负载均衡的实现直接依赖于 DNS 。
4. 客户端（ PLClient和DFSClient ）
对于客户端，它访问 Hive 直接通过域名进行。
二. DNS 解析顺序
DNS 解析顺序有两种，从上往下进行依次查询，如果查询到马上返回，如果最后一个也没有查询到则返回无法解析域名错误。
第一种
本地 DNS 缓存 本地 HOSTS 文件 DNS 服务器
第二种
本地 DNS 缓存 DNS 服务器 本地 HOSTS文 件
DNS 服务器和本地的 hosts 文件的顺序可以由/etc/nsswitch.conf中的hosts: files dns 表示第一种。决定，例如上面是先检查 hosts 文件，如果存在则返回该ip，如果不存在，则再连接DNS服务器。
三. DNS 故障模拟方法及评估步骤
1. 模拟方法
我们利用 iptables 命令按需在某节点上添加目的地址为 DNS 服务器 IP 的 OUTPUT 链，屏蔽所有发送到 DNS 服务器的包，这种情况下 DNS 客户端因不能与 DNS 服务器进行通讯而造成域名解析失败。
TDW 的架构图
绿线表示需要利用DNS解析，在下面的评估步骤依次断开对应节点的绿线，也就是对应节点不能访问DNS服务器来模拟DNS故障。
2. 评估步骤
先对 TDW 各个模块单独进行 DNS 故障模拟并评估，然后对整个 TDW 进行 DNS 故障模拟并评估。具体 DNS 故障模拟情况如下：（详细内容略去）
- Datanode 出现单点 DNS 故障。
- Namenode 节点出现 DNS 故障。
- Secondary Namenode 出现 DNS 故障。
- 整个 HDFS 集群出现 DNS 故障。
- JobTracker 出现单点 DNS 故障。
- TaskTracker 出现单点 DNS 故障。
- 整个计算引擎出现 DNS 故障。
- Hive 服务器出现 DNS 故障。
- PLClient 出现 DNS 故障。
- DFSClient 出现 DNS 故障。
- 整个 TDW 出现 DNS 故障、也就是存储引擎、查询引擎、计算引擎都出现 DNS 故障。
四.评估结论
过评估发现 Tasktracker、Hive、Datanode、Secondary Namenode 和客户端五类节点对 DNS 的依赖比较大。对于 Namenode 和 JobTracker 在启动时对 DNS 依赖较大，但是再启动后即使出现 DNS 故障，也不会影响它的正常工作和任务调度。DNS 故障对各节点的影响程度如下：
节点 | 依赖操作 | DNS故障的影响程度 |
|---|---|---|
Namenode | 启动 | 没重启前能正常工作 |
Secondary Namenode | 启动、创建检查点 | 出现 DNS 故障后完全不能工作 |
JobTracker | 启动 | 没重启前能正常工作 |
Datanode | 启动、目录和文件的读写删 | 没重启前能正常工作;重启时会启动失败；如果 Datanode 出现 DNS 故障个数大于块的副本个数时可能会出现文件读取是吧。 |
Tasktracker | 启动、task 的执行 | 出现 DNS 故障后完全不能工作 |
Hive | 通过 MR 进行的查询、数据插入 | 没重启前因为存在 DNS 缓存，数据库和数据表的增加、删除能正常工作，但是插入数据和查询（通过走 MR 查询）不能正常工作； Hive 重启后所有操作都不能正常工作； |
Client | 所有 | 客户端是通过域名连接 Hive，出现故障后完全不能工作。 |
五. DNS 方案的改进探索
随着 TDW 功能不断迭代及接入系统的增多，DNS 已经成为了 TDW 核心的一环。如何提高 DNS 的可用行已经很重要。
目前，我们通过添加 DNS 备用服务器的方法来提高 DNS 的可用性。我们目前拥有4个 DNS 服务器，它们的配置相同，其中一个作为主 DNS 服务器，其3个作为从 DNS 服务器。这样可以大大提高 DNS 的可用性。
另外，根据 DNS 故障影响的情况，我们提出了以下的 DNS 改进方案
1.常规情况是使用 DNS 服务器进行解析；
2.当 DNS 服务器出现故障，使用 hosts 文件进行解析。可以预先将所有的 ip 和域名对应地写进一个 hosts 文件，同时在某一个节点上开启一个线程监控 DNS 服务器是否正常，如果出现 DNS 故障，马上将 hosts 文件修改，同时将 hosts 文件同步到其它节点。这样能临时解决突发的 DNS 故障。当 DNS 服务恢复后，可以手工批量恢复各节点的 hosts 文件。