累積:技海拾貝

累積：技海拾貝|

C

UMULATION

淺談通過GTM進行DNS的智能解析

文：東軟信息技術服務有限公司馬新元

什么是DNS的智能解析

目前中國的網絡南北割據，電信、網通等不同線路的互訪頗為困難，而智能解析是針

DNS

對目前國內電信、聯通以及移動等線路互聯互通提供的一種解決方案。具備智能解析能力的

DNSDNS

除了具備一般的基本解析功能外，還可以自動識別請求發送者的來源，并

DNS

IPIDCIP

以根據其將域名智能的解析到雙線路機器的網通或電信的或位于不同中機器的，

便瀏覽者就近訪問你的網站而不會因為線路不同而導致訪問慢。

,

DNS智能解析的原理

DNS智能解析的基本原理是識別用戶的來路，并且根據用戶的來路，通過獨有的算法，

把用戶分配到網站離用戶最近的服務器上。例如我們將域名托管在可進行免費DNS智

能查詢的DNSPod，則DNSPod可根據用戶的來源，讓網通線路的用戶訪問到網站的

網通IP或者讓沈陽的用戶訪問到位于沈陽IDC機房中的服務器（這一切對用戶而言是

無感知的），而不需要像早年間很多網站為了保證不同線路的訪問質量，建立一個網站

的若干鏡像站，讓用戶手動去選擇自己要訪問的站點。

智能DNS的實現方式有軟件和硬件，軟件中有久負盛名的bind，而硬件中有F5 的

GTM 。同時也有提供DNS服務的DNSPod等。

利用F5GTM進行DNS的智能解析

F5 GTM全稱為Global Traffic Management即全局傳輸管理，它是一種廣域網負載

均衡設備，以DNS解析為主要工作，可處理多個數據中心的流量分配。與它相對應的

還有LTM 全稱為Local Traffic Management即本地傳輸管理，是一種局域網負載均

衡設備，以TCP/UDP流量分發處理、優化為主要工作，主要處理在一個數據中心內的

1 / 5

流量分配，可以處理到流量的七層內容。在本文中我們主要討論如何利用GTM進行域

名的智能解析。

在現實的生產環境中，一個有DNS智能解析需求的網站，其服務器往往分布在不同的

IDC機房中，這些IDC使用不同的線路對外提供服務；或者其服務器位于同一個IDC

機房中，但該IDC機房為該服務器提供了不同線路的出口。對應這種情況，在GTM中

將使用某一線路的數據中心抽象為一個概念Datacenter。在一個Datacenter中包含

了大量的服務器，GTM中將其抽象為一個概念Server。每個服務器可以配置一個或多

個IP，對應具體的這些IP以及相關的端口，GTM將其抽象為一個概念Virtual Server。

Datacenter、Server、Virtual Server ，GTM通過以上三個概念完成了對IDC機房

中物理網絡的描述。

那么具體的Datacenter、Server、Virtual Server在GTM中擔任何種角色呢？

? Virtual Server：GTM中的最小object，是Server和Pool的邏輯成員，其

IP即為GTM最終提供解析的結果。

? Server：用來代表一個服務器實體，類似于LTM中的node，有bigip rver，

non-bigip rver 兩類，隸屬于Datacenter中，同一rver不應同時存在

于兩個Datacenter中。

? Datacenter：組織Server的容器，表示一個具體的數據中心。

在完成對物理的網絡的標示以后，即涉及到如何將不同用戶所請求的域名地址正確的映

射到具體的IP上。這里就涉及到GTM的智能解析方式。GTM通過wide IP和pool 來

實現這一功能。

那么Wide IP和Pool又是何方神圣？

? Pool:是一個資源池，用來組織Virtual Server，是Wide IP的配置要素，同

一Virtual Server可以同時屬于多個Pool。

? Wide IP：對外呈現GTM所負載的智能域名，其下包含一個或多個Pool。

說完了這些比較枯燥的概念，我們用一個具體的例子來說明GTM智能解析的工作模式。

假設情景：我們有一個網站，該網站在北京和上海分

別放置了一臺鏡像服務器對外提供服務。北京的服務器IP為202.96.1.2是一個網通

地址，上海的服務器IP為116.238.1.2是一個電信地址。現在我們希望使用網通線路

的用戶在訪問這個網站時，實際訪問到的是北京服務器的IP地址202.96.1.2，電信

線路的用戶在訪問這個網站時實際訪問到的是上海服務器的IP地址116.238.1.2。（以

上域名及IP均為虛構，特此說明）

2 / 5

GTM如何來完成這個需求呢：

大體上分為兩個階段：第一階段，描述物理資源；第二階段，制定智能解析策略。以下

為具體步驟：

第一步：建立電信和網通線路的Datacenter

首先我們需要在從我們的網絡運營商那里獲得網通和電信線路的地址池，并在GTM中

建立對應的地址池CNC-Address、CT-Address。其次，我們將分別建立對應網通和

電信線路的Datacenter： DC_CNC，DC_CT。最后我們將網通地址池CNC-Address

與網通Datacenter相對應 ，電信地址池CT-Address與電信Datacenter相對應，

這樣就基本完成了Datacenter的建立。

第二步：建立電信和網通線路的Server

我們在GTM中創建一個Server來表示網通線路的服務器，命名為rver_cnc，將

其加入到網通Datacenter DC_CNC中，表明該服務器是屬于網通Datacenter的，

并為其創建IP地址為202.96.1.2的Virtual Server用來作為GTM最終提供解析的

結果。

同理，我們創建電信線路的rver,命名為rver_ct，并將其加入電信Datacenter

DC_CT中，并為其創建IP地址為116.238.1.2的Virtual Server用來作為GTM最

終提供解析的結果。

通過以上兩步，我們完成了對物理資源的描述，在以下的步驟中，我們將進行智能解析

策略的制定。

第三步：創建資源池Pool

我們在GTM創建一個資源池Pool_ , 并將剛才建立的

Virtual Server：rver_cnc、rver_ct加入到這個池中。在這個新建立的資源池

中我們將為這些Virtual Server創建規則，以確定當DNS請求被本資源池響應時，具

體將哪個Virtual Server的IP作為解析結果返回給用戶。

在本例中，我們將按照Topology的方式來決定具體將哪個Virtual Server的IP提供

給用戶。

所謂Topology的方式，即按照發起DNS解析請求者的IP的歸屬來確定使用哪些

Virtual Server來進行響應。GTM中所定義的Topology可以在

Continent/Country/IP Subnet/ISP四個層次進行傳入IP的分類。本例中我們創建

了網通線路和電信線路的地址池，那么用戶發起的DNS解析請求就將按照用戶的IP

屬于哪一個地址池，來確定是將電信服務器還是網通服務器的IP返回給用戶。

3 / 5

第四步：建立域名到資源池的映射。

最后我們創建一個Wide IP ：，表明：對外該GTM接受所

有對該域名的查詢請求，并將第三步建立的資源池Pool_添

加到該Wide IP中。表明所有對這個域名的解析都將由資源

池Pool_進行。

至此，一個最簡化版本的智能解析就完成了。

此時一個網通線路的用戶在瀏覽器中輸入網站網址，

用戶的所配置的網通DNS將向我們的GTM發起該域名的查詢請求。我們的GTM在接

收到該查詢請求后，將使用資源池Pool_對該域名進行解析，

由于該域名查詢請求的發起者IP地址包含在網通地址池中，GTM就將網通線路服務器

的IP地址返回給發起查詢的網通DNS，網通DNS進一步將該IP地址作為查詢結果返

回給該用戶。這樣用戶事實上最終訪問到的服務器即為該網站的網通線路服務器，但整

個過程對于用戶而言是無感知的。

單純從以上的DNS智能解析方式來說，GTM的智能解析方式與一般的bind服務器通

過訪問控制列表結合視圖來進行智能解析的方式差別并不大。但在實際的應用中，GTM

提供了幾種比較有特點的功能以提高其智能解析能力。由于篇幅所限，本文將就比較有

代表性的功能Health Monitors 以及iRule進行一下說明。其他的系統特性，可以在

網站上獲取到最新的資料。

首先介紹一下Health Monitor

Health Monitor一般譯為健康檢查，在 GTM中將會在Pool，以及Server中加入對

Virtual Server的健康檢查，以確定該服務器是否可以正常的對外提供服務。例如在

Pool中使用了健康檢查后，如通過健康檢查，某Virtual Server的服務處于不可用狀

態，Pool將會利用已定義的負載平衡策略將其他可用的IP返回給用戶，以保證在部分

服務器宕機的情況下，用戶仍可以獲得所需服務，從而保證用戶的使用體驗。

GTM系統中默認創建了幾種健康檢查的腳本，但是我們也可以根據需要進行自定義健

康檢查腳本的編寫，自定義的健康檢查腳本可以根據檢測內容的不同，定義檢測的類型、

時間周期、超時標準，服務端口等信息，滿足用戶的檢測需求。

下面簡單介紹一下iRule

通過使用F5由事件驅動的iRule，可以定制全局流量的動態分配。GTM可以深入查看

DNS消息，向期望的數據中心、池或虛擬服務器分配應用流量。這一功能可以減少延

遲，加強針對惡意攻擊的保護，并改進應用性能。在GTM中iRules主要使用在Wide

IP模塊中，當我們定義了多個資源池的時候，可以設定iRule，讓符合特定條件的流量

4 / 5

連接到特定的資源池進行處理。這里所指的特定條件可以是DNS查詢請求發起者的IP

地址，也可以是URI這樣的通用資源標識符。iRule規則使用的語法為TCL，目前GTM

可以支持TCL8.4版本的語法。

以下使用一個小例子來說明iRules的用法：

下面是一個簡單的iRule

when DNS_REQUEST {

if { [IP::addr [IP::client_addr] equals 10.10.10.10] } {

pool my_pool

}

}

當我們為一個Wide IP添加了這樣的iRule以后，每當這個Wide IP監聽到DNS請

求發送者的IP地址是10.10.10.10，就會將這個請求包傳遞給my_pool來進行處理。

可見，使用iRule我們將可以更加靈活的定制智能解析策略。

使用智能解析時面臨的問題

GTM是通過用戶的來源IP來返回不同的解釋IP，而實際上，并不是實際用戶直接訪

問我們的 DNS，而是用戶所使用的DNS（比如說沈陽ADSL用戶的默認DNS）負責

訪問我們的DNS，如果用戶自行修改了DNS，比如說電信的用戶硬要用網通的DNS，

或者網通的用戶使用國外的DNS（比如opendns之類的），就會導致判斷失誤。對于

這種問題，目前尚無較好的解決方法。

5 / 5