DNS集群架构和优化

本篇文章介绍了DNS现状和开源软件Bind的相关内容。

回顾上篇文章:

Elasticsearch 原理分析

DNS 现状以及面临的问题

在现如今的公司内部,我们可能需要解析成千上万个内部域名以及内部机器名,而通过在机器上写死 host IP 对应关系来解决解析问题,在域名与机器数量如此多的情况下,维护机器的 host 文件是一个成本很高的事情,因此在内部提供了 DNS 解析服务,用于提供各个机房的特殊解析服务,是一件很重要的事情。

但是随着公司的发展越来越快,所需要提供解析也从几千发展到上万,我们可能会遇到一下这些问题:

1)修改记录后生效时间慢,紧急故障切换时产生等待时间。

2)无法高效的记录 DNS 请求日志,回查、统计不方便。

3)每台 DNS 都管理自身的 Zone 文件,维护成本大。

4)Bind 性能差,无法充分利用宿主机性能。

在这种情况下,缩短记录生效时间,减少维护成本,提升 Bind 性能的工作就被提上了日程。

本文在 DNS 解析器的选择上,使用了 ISC 的开源软件–Bind。

新版 Bind

1

什么是 Bind

要说 Bind,就要说什么是 DNS,DNS 是域名系统 (Domain Name System) 的缩写,它是由解析器和域名服务器组成的。

域名服务器是指保存有该网络中所有主机的域名和对应 IP 地址,并具有将域名转换为 IP 地址功能的服务器。其中域名必须对应一个 IP 地址,而 IP 地址不一定有域名。域名系统采用类似目录树的等级结构。

域名服务器为客户机 / 服务器模式中的服务器方,它主要有两种形式:主服务器和转发服务器。将域名映射为 IP 地址的过程就称为 “域名解析”。而 Bind 就是一款开源的实现 DNS 域名解析的软件,它由域名解析器、域名授权服务器和工具组成。

2

DNS 域名的解析过程

客户端向发起一个 DNS 请求,如果该请求被本机缓存,则直接返回,否则将会到达本地 DNS 服务器,本地 DNS 服务器首先会去查询自身的区域文件,如果匹配成功,返回结果,如果请求的解析不在自身的区域文件中,则将请求转发出去,此时该 DNS 请求会根据根提示,逐步查找顶级域名,直到查到结果。

3

Bind 特性

随着技术的革新,现在的机器的性能越来越高,但如果不修改 Bind 的一些配置限制,会导致 Bind 无法充分利用机器的性能,因此这里谈一下可以提升 Bind 性能的几个点

1. ISC_SOCKET_MAXEVENTS

Bind 默认会开启最多 64 个和内核的通信事件数,你可以通过修改源码来达到增加通信事件数,代码路径为

bind-x.x.xx/lib/isc/unix/socket.c

2. ISC_SOCKET_MAXSOCKETS

Bind 默认使用的最大的套接字数目为 4096,你可以通过 named –S 来增加套接字数,注意套接字只能调高无法调低,你也可以在编译前,在 bind-x.x.xx/lib/isc/unix/socket.c中修改该参数,注意1和2的调节会增加named对内存的使用量。

3. RCVBUFSIZE

Bind 的默认RCVBUFSIZE为32K,如果你想使用更大的接收队列,可以在编译前修改define RCVBUFSIZE,代码路径为

bind-x.x.xx/lib/isc/unix/socket.c

4. RESOLVER_NTASKS

这个一个很重要的参数,Bind 之所以存在一个性能瓶颈而不是随着机器的 cpu 的提升而提升,很重要的一点就是因为 Bind 的域名解析过程是带锁的 (具体解析过程请参考bind-x.x.xx/bin\named\server.c),因此增加 Bind 的解析器任务的个数是非常重要的,增加解析器任务的数量能减少锁的争用并提高吞吐量,但这也很大的增加了 named 进程使用的内存,你可以在bind-x.x.xx/bin\named\server.c和bind-x.x.xx/bin\named\client.c中修改它。

4

性能测试

测试目标

PPS 峰值

丢包率与时延

测试环境

机器系统版本:Centos 7.3

机器内核版本:3.18

机器 CPU 型号:Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

机器 CPU 个数:2

机器内存:128G

机器网卡:万兆网卡

测试步骤与方法

测试工具:queryperf

测试方法:在压力测试机上使用 queryperf 工具对 Bind 机器模拟请求,请求的总次数为 200W。测试命令为:

逐渐提高 X,来模拟并发,q 的测试值为 20,30,40,50,60,70,80(-q 表示一次发送的请求数默认为 20)。

测试结果

1) 当 q 逐渐变大,QPS 逐渐升高。QPS 峰值为 21W 左右。

2) Bind 服务器和压力测试机的网卡吞吐和 CPU 均未满。Cpu.busy 值在 20% 左右。

Bind 架构

1

架构介绍

为了解决同步生效时间慢,减少维护成本等问题,我们现在的 Bind 架构为 DNS Master/Slave。

如上图所示,A,B 两个机房都有 Master DNS 与 Slave DNS,Slave DNS 通过宣告 VIP 的方式来提供集群服务,避免当单台 DNS 宕机时,影响整个 DNS 集群,这样能有效的提高 DNS 集群的的鲁棒性。

2

配置文件详解

上文提到由于现在使用了 M/S 架构,所以 Master 和 Slave 上的配置文件也是不同的,下面我们就来扯一扯两类机器配置的问题。先说 Master 的配置:

接下来我们就来解释一下上述配置文件

Controls 中记录的是使用 RNDC 相关配置

inet 127.0.0.1 port 953 定义通信 IP 和端口

Keys:定义允许操作的 Key

Allow:来限制允许操作的 IP

Logging 中定义 DNS 的日志信息

Channel:后跟通道名,这个一个任意但是唯一的名字,用于将类别与通道定义相关连。

File:用于定义文件存放的路径

Versions:用于保存文件的数量

Size:用于限制单个文件的日志大小,默认单位为bytes,你也可以使用 K,M,G 等单位

Category:用于控制各种已经定义或者默认的 Channel name 类别,默认可以采用以下值。

Options 中保存着 named 的配置文件

Directory:表示 named 存储的 Zone 文件路径

pid-file:表示运行 named 时,pid 文件的路径

allow-query:表示允许来查询的 IP 列表,其内容可以是 IP, 可以是网段,

forwarders:表示当本机没有对应解析时,DNS 会将请求递归下一跳机器。

Notify:用于表示是否发送 Notify 请求。可选参数为 notify yes | no | explicit;

Zone 中保存解析的详细内容

Type:表示该 Zone 的类型,

File:表示该 Zone 解析文件存放的路径

also-notify:表示当 Zone 文件修改时,Master DNS 会向哪些 Slave DNS 下发 Notify 请求。

最后是 Key ,Key 中保存着这台 DNS 持有的 TSIG 密钥。

algorithm:表示该密钥的加密方式,默认为 hmac-md5。

secret:表示该密钥的密文,

接下来说一下 Slave DNS 的配置文件

Slave DNS 的配置文件与 Master DNS 的配置文件基本相同,主要的差距在于 Zone 中的 Type 为 Slave,且在 Zone 中还包含了 masters 字段,其作用是记录这个 Zone 文件会向哪台 Master 同步数据。

那些年我们错过的注意事项与建议

1

match-clients

首先要说的是 match-clients, match-clients 只能在 view 中使用,其目的是让 view 被目标客户端匹配,match-clients 的配置参数如下:

当客户端的其中一条情况满足 match-clients 时,match-clients 就会将你的 Query 捕获进 View,一般来说,区域化解析和智能 DNS,都离不开这个参数。要注意当有一条情况满足 match-clients 的条件时,这个 Query 就会被这个 View 处理。当你的一个 query 中带有 TSIG 与 IP 时,match-clients,容易将这个 query 的 tsig 与 IP 当成两个条件或处理,最后导致你的 Query 命中了错误的 View。

2

对 Zone 文件的监控

要对 Zone 文件进行监控,我们首先来讲一下 SOA,SOA 全称为 Start Of Authority,它存放在 Zone 文件的第一行,每个 Zone 文件只能有一个 SOA,SOA 记录了这个 Zone 负责的 name server,version number 等信息。

对 Zone 文件的监控主要有两点:

1)该文件是否有错误

引起错误的原因有很多,比如错误的 SOA 内容,一个域名同时存在 A 记录解析和 CNAME 记录解析等,当该文件错误时,Bind 就无法正常加载该 Zone文件,而它的报错日常会记录在我上述所说的 logging 中

2)该文件是否实时生效

当你的 DNS 架构为 M/S 时,且确定 Master 上已经成功加载了对应的 Zone 文件,但是你如何知道 Slave 上已经生效了?有两个方法 1)通过查看 Slave上的 Xfer-in 日志,来确定你的记录是否下发,2) 通过查看 Slave DNS 上 Zone 文件的 SOA 中的 serial number 与 Master 上的是否相同,来确定 Slave DNS 的记录是否已经生效。

总结

本文介绍了 DNS 的相关知识,以及我们对开源软件 Bind 的一些理解,以及我们对 Bind 的部署方式,以及优化方法,希望对大家有帮助。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180731G1FVJM00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券