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）。

測試成功，以最低的代價實現了一個異地容災方案，并得到了用戶的好評。