目前，TDW 叢集的所有slaves機器都需要通過 DNS 域名解析方式連接配接 master，也就是在所有 slaves 機器上配置 master 的域名，而非直接的 IP 位址；使用者需要使用 client 用戶端來上傳資料，client 和 master 互聯也是采用 DNS 域名解析方式。此外，使用 DNS 域名解析的方式，可以使我們的平台具有更大的可擴充性。如果 master 主機當機，我們可以直接修改 DNS 伺服器 master 的域名指向， slaves 機器就會連接配接到新的 master 上。 Client 用戶端的連接配接也是同樣的道理。
可見， TDW 對 DNS 域名解析有一定的依賴。為了減少 DNS 故障帶來的損失，我們進行了 DNS 故障對 TDW 影響評估。
檔案系統名稱（ fs.default.name ）：它用一個 URI 定義檔案系統的協定、主機、端口等資訊， URI 的主機采用域名加端口的形式。
檔案系統的 Http 位址（ dfs.http.address ）： http 位址也是采用域名加端口的形式。
Zookeeper 用戶端：它的組成為主機域名加端口号
用戶端（ DFSClient ）對檔案系統的通路也是通過域名加端口進行通路，如果 DNS 出現故障，也會使其對 HDFS 進行通路造成影響。
mapred.job.tracker：它的組成為主機域名加端口号
mapred.job.tracker.http.address：它的組成為主機域名加端口号
在 Job 送出上，JobSubmitter 需要将 Job.jar 和配置檔案上傳到 HDFS， JobSubmitter 與 HDFS 通訊是通過域名進行。
在 Job 運作時，有一個步驟需要從 HDFS 中下載下傳檔案到本地，它通路 HDFS 是通過域名進行通路。
對于 Hive，它的資料存儲在 HDFS ，當 HDFS 受到 DNS 故障影響， hive 也會間接受到影響。另外， Hive 的中繼資料儲存各個資料表的路徑，這些路徑是由域名和域名的相對路徑組成。
目前， Hive 的容災方式是采用 DNS 方式，提供多點服務，它消除單點和負載不均衡問題。 DNS 具備負載均衡功能，接收到用戶端的請求後， DNSserver 負責輪詢域名對應的多個 HIVE 機器 IP ，并傳回給用戶端，達到負載均衡。DNS 負載均衡的實作直接依賴于 DNS 。
對于用戶端，它通路 Hive 直接通過域名進行。
DNS 解析順序有兩種，從上往下進行依次查詢，如果查詢到馬上傳回，如果最後一個也沒有查詢到則傳回無法解析域名錯誤。
第一種
本地 DNS 緩存
本地 HOSTS 檔案
DNS 伺服器
第二種
本地 HOSTS文 件
DNS 伺服器和本地的 hosts 檔案的順序可以由<code>/etc/nsswitch.conf</code>中的<code>hosts: files dns</code> 表示第一種。決定，例如上面是先檢查 hosts 檔案，如果存在則傳回該ip，如果不存在，則再連接配接DNS伺服器。
我們利用 iptables 指令按需在某節點上添加目的位址為 DNS 伺服器 IP 的 OUTPUT 鍊，屏蔽所有發送到 DNS 伺服器的包，這種情況下 DNS 用戶端因不能與 DNS 伺服器進行通訊而造成域名解析失敗。
綠線表示需要利用DNS解析，在下面的評估步驟依次斷開對應節點的綠線，也就是對應節點不能通路DNS伺服器來模拟DNS故障。
先對 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 的執行
Hive
通過 MR 進行的查詢、資料插入
沒重新開機前因為存在 DNS 緩存，資料庫和資料表的增加、删除能正常工作，但是插入資料和查詢（通過走 MR 查詢）不能正常工作； Hive 重新開機後所有操作都不能正常工作；
Client
所有
用戶端是通過域名連接配接 Hive，出現故障後完全不能工作。
随着 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 檔案。