网管员世界2009超值精华本
上QQ阅读APP看本书，新人免费读10天
设备和账号都新为新人
上一章目录下一章

DNS自动切换解决异地容灾问题

福建 林梁冬

DNS解析自动切换原理

异地容灾系统是构建在广域网上，跨越较长距离（20～100公里）的两个端点的业务备份系统，通常一端称为主结点，另一端称为备份结点，当主结点完全死机或被彻底损毁的时候，业务将自动切换到备份结点，以提供持续的对外服务。大中型企业一般会花大价钱，购置一些专用设备来实现完全相同的两个结点设施。

异地容灾之关键

异地容灾系统一般由集群系统和数据镜像系统两部分组成，集群系统包括线路冗余、网络设备高可用性配置、操作系统集群、应用集群和数据库集群，以及在广域网（或Internet）上能实现DNS切换的相关DNS设备等几个部分组成，目的是实现系统部件之间的切换和资源的自动接管。数据镜像系统则是让两个结点之间的数据和系统状态实现同步，以保证切换后的数据与状态的一致性。

DNS解析原理

很多人认DNS的A记录可以实现自动切换，即我们希望用一对二的方法，比如：

      www.test.com→IP1
      www.test.com→IP2

用它来达到如果IP1结点主机发生故障，域名解析自动使用第2条的目的。但实验发现，DNS无法自动感知IP1结点发生故障，DNS是按照均衡负载的方式处理A记录的，而并非按容错的方式工作的，即上一次解析为IP1，下一次则为IP2，再下一次又为IP1，循还反复。这样，DNS客户端仍然会有一半的几率解析到已发生故障的IP1，从而仍然无法正常访问到备份结点（IP2）。

那么能否用动态路由方式来自动切换呢？原则上是可以的。此时，IP1、IP2两结点必须通过远程线路连接在同一个LAN中，且必须IP1、IP2及它们的群集IP（Virtual IP）同在一个网段，且这一网段必须参与Internet路由（都是公网IP）才可以（如图1所示）。

图1 动态路由自动切换网络结构

此时DNS中的A记录将指向Virtual IP，但这显然也不太符合很多企业都使用NAT（网络地址转换）或PAT（端口地址转换）的实际情况。

实现DNS自动切换

那么如何实现DNS的自动切换呢？原来，一对多的不是A记录，而是NS记录（NS：域名服务器记录，用于指明负责域名解析的DNS服务器）。因为NS记录，DNS客户端或迭代查询DNS是会测试NS连通性的（用UDP 53而非ping），连不上一个NS就自动切换到另一个NS，这样两端NS各写一个容灾切换结点的A记录就可以了。不需要专门的设备，只要用普通的操作系统DNS服务器组件就可以验证这一原理。

DNS解析自动切换实验

DNS解析自动切换实验拓扑结构图如图2所示。实验中一共有4 个结点，其中PubDNS、GTM1、GTM2 分别是3台DNS服务器，Client是用于测试的DNS客户端，用于测试切换的关键业务系统域名是www.test.com。

图2 网络实验结构

试验策划

（1）配置PubDNS实现test.com域的两条NS记录，也就是说test.com将由两台DNS（GTM1、GTM2）负责解析，DNS解析将在GTM1和GTM2之间实现自动切换。

（2）配置GTM1、GTM2实现异地容灾的两个远程结点的DNS服务器。GTM1和GTM2相当于异地容灾的两个相隔较远的结点（相距20～100公里），各自部署的DNS服务器负责本地DNS的解析，上面各有一个A记录指向本地关键业务系统www.test.com的解析条目。

（3）使用一台DNS客户端Client进行解析切换的测试。当GTM1发生故障时，看能否由GTM2接管www.test.com解析。反过来，如果GTM2发生故障，再进行测试，验证可以在两个结点间自由切换。

操作步骤

1.PubDNS

模拟Internet上一台普通的公共DNS服务器，操作系统为Windows 2003，IP地址为192.168.11.230。DDNS（分布式DNS）是Windows平台下的DNS组件名称，在这台服务器上将建立一个“存根区域”，并增加test.com（RR：是“资源记录”的简写）的2个NS记录和2个NS对应的A记录，用于指明test.com的权威DNS服务器的IP地址，即：

NS记录：

      test.com→gtm1.test.com
      test.com→gtm2.test.com

A记录：

      gtm1.test.com→192.168.11.226
      gtm2.test.com→192.168.11.227

建立过程如图3所示。

图3 建立一个“存根区域”

建立为“主要区域”类型是不行的（已测过），这是因为主要区域一般表明这台DNS是test.com的权威DNS，这样就不会将解析转发给NS指向的那2台DNS服务器了。

添加2个NS的IP（A记录），“存根区域”类型的RR（资源记录）是不可写的（其RR同步自第一个NS服务器，所以NS也必须允许区域复制到这台服务器）。

可以从上一步看到，RR并未包括第二个NS的记录，而由于在图形界面下不可以修改RR，所以必须手动修改区域文件：

      D:\windows\system32\dns\test.com.dns

在其中添加2条记录（如图4所示）：

图4 添加2条记录

      NS记录：test.com→gtm2.test.com
      A记录：gtm2.test.com→192.168.11.227

刷新一下，我们就可以看到正确的2组NS解析了。

2.GTM1

模拟容灾主结点端的一台普通的DNS服务器，它负责解析主结点本端的域名解析，GTM1的操作系统为Linux，IP地址是192.168.11.226。

在本例中，GTM1中只有一条A记录：

      www.test.com→202.101.1.100

GTM1的DNS服务器采用Linux下的Bind软件实现，Bind中/etc/named.conf的内容为：

      options{
      directory"/var/named"；
      pid-file"/var/run/named/named.pid"；
      }；
      zone"test.com"{
      type master；
      file"named.test.com"；
      }；

第一组{}中指明了Bind服务的区域配置文件位置，以及Bind使用的PID文件。

第二组{}中指明了建立一个主要区域test.com，其区域配置文件名为named.test.com，绝对路径为/var/named/named. test.com，文件内容为：

      $TTL 600
      @IN SOA gtm1.test.com.  root.gtm1.test.com.（
      2006100302
      28800
      14400
      720000
      86400）
      @IN NS gtm1.test.com.
      gtm1 IN A 192.168.11.226
      www 60 IN A 202.101.1.100

其中gtm1有一条NS记录和一条A记录，而www 60 IN A 202.101.1.100中的“60”，表示这条记录的TTL值为60秒，如果不设置将取默认的86400秒（即1天，这就是为什么在Internet上改动域名解析，在全球需要至少1天时间才能全部更新的原因，TTL值是RR记录在DNS客户端和迭代DNS服务器中缓冲的时长），减少RR的TTL值是减少容灾切换时间必不可少的设置步骤。

3.GTM2

模拟容灾备份结点端的一台普通的DNS服务器，它负责解析备份结点本端的域名解析，GTM2的操作系统为Linux，IP地址是192.168.11.227。

在本例中，GTM2中只有一条A记录：

      www.test.com→61.1.1.100

GTM2的DNS服务器也采用Linux下的Bind软件实现，Bind中/etc/named.conf的内容与GTM1相同，/var/named/named.test.com文件的内容如下：

      $TTL 600
      @IN SOA gtm2.test.com.  root.gtm2.test.com.（
      2006100302
      28800
      14400
      720000
      86400）
      @IN NS gtm2.test.com.
      gtm2 IN A 192.168.11.227
      www  60 IN A 61.1.1.100

4.Client

模拟Internet上的一台DNS客户端，操作系统为Linux，IP地址为192.168.11.225。

DNS切换测试过程

（1）先用PubDNS充当DNS客户端，得到自GTM1主结点的解析项202.101.1.100。

（2）在Windows中输入ipconfig/displaydns，查看到记录缓冲的TTL从60秒已减少到44秒（如图5所示），如果减到0，则从DNS客户端中自动清除该缓冲。

图5 TTL从60秒已减少到44秒

（3）手动停掉GTM1的网卡，模拟主结点故障。运行的命令为：

ifconfig eth0 down

（4）在清除DNS客户端缓冲和迭代查询DNS服务器（PubDNS）缓冲后，再用ping命令，可以看到解析已自动转向GTM2，得到61.1.1.100的解析项，测试成功（如图6所示）。

图6 TTL自动过期方式测试成功

（5）按TTL自动过期方式测试，测试成功。

（6）用Client结点充当DNS客户端，可以看到TTL是在一分钟之后自动过期的（这期间要分别停掉GTM1或GTM2的网卡来模拟异地容灾结点的故障情况），切换测试成功。

配置DNS解析自动切换应用案例

以往异地容灾系统被认为是大中型企业的一种“奢侈品”，各种系统和设备组件都需要采用专用软硬件来实现，构建成本高昂，使小型企业望而却步。如果能采用操作系统、数据库自带的功能，或者一部分开源软件实现集群或数据镜像功能，加上这里介绍的关键一环：广域网DNS自动切换的配置，异地容灾系统的构建和实施成本将大大降低，从而使更多企业的业务核心也能经受住灾难的考验。

下面是为我公司贸易洽谈会进行异地容灾部署的一个例子（如图7所示）。作为对外贸易的一个重要窗口，该系统要求能够7×24 小时保障外商的登录和修改、更新自己的产品资料，能实现在主结点发生故障的情况下自动切换到备份结点，且两边结点的数据要能保证实时一致。以前采用块级数据镜像软件，发现无法感知数据库运行状态，从而当主结点发生数据库出错时，将出错状态同步到了备份结点，结果两个结点数据库均无法工作，全部瘫痪。现改用微软MS SQL数据库自带的数据复制功能实现数据的实时同步，可以避免这一问题。部署过程如下：

图7 异地容灾网络结构

（1）在公网域名提供商的DNS维护页面，加入网站所在域名abc.com的NS记录：NS1和NS2，分别指向处在两个地点的主、备结点的公网路由器的IP地址。

（2）在两端公网路由器上利用PAT（端口地址映射），将公网路由器的IP的端口80、53（UDP）、1433（MSSQL）分别镜像到内网主机上，使外网可以访问到××贸易洽谈会的网站（内网主机80端口）。

（3）在主结点和备份结点上分别安装和配置WWW、DNS、MSSQL服务器，DNS中www.abc.com的记录均指向本地公网路由器IP，即主结点的www.abc.com指向202.101.100.5，备用结点的www.abc.com指向61.12.213.9，并将A记录缓存时间调小至1分钟过期，再通过第2步设置的PAT就能访问到网站了。

（4）在主结点和备份结点上配置MS SQL的数据复制功能，采用合并发布功能同步两边的数据，并进行数据实时更新的测试。

（5）测试主结点死机后，是否能在1分钟左右将www. abc.com切换到备份结点（61.12.213.9）。

测试成功，以最低的代价实现了一个异地容灾方案，并得到了用户的好评。

上一章目录下一章