愛奇藝混合雲內網DNS實踐

　　愛奇藝早期業務多數以私有云方式部署，隨時間推移，私有云模式在成本、彈性及區域覆蓋等方面開始顯現不足，而公有云在近年的發展中成熟度不斷提高，逐步滿足愛奇藝業務需求，愛奇藝開始有計劃的使用公有云資源，逐漸形成私有云與多家公有云結合的業務部署模式，即混合雲模式。混合雲模式下，私有云和公有云分屬不同的 DNS 體系，如何實現域名統一管理，高效、安全地完成雲間通訊，成為一個巨大的挑戰，本文即介紹愛奇藝內網 DNS 架構的演進以及混合雲場景下的內網 DNS 實踐。

　　 01 愛奇藝內網 DNS 演進

　　DNS 作為網路基礎服務，不僅在公網環境中體現至關重要的價值，在內網環境中也具有重要的服務與資源定位作用。在愛奇藝生產環境中，服務多樣、複雜，通訊效率要求高，各業務普遍使用內網 DNS 進行服務定位，故對內網 DNS 提出高效能、高穩定、低延遲等要求。為滿足業務需求，愛奇藝 DNS 架構不斷演進，形成了融合 Anycast 的多層 DNS 架構，下文將詳細介紹。

　　1.1 私有云環境下內網 DNS 架構

　　愛奇藝內網 DNS 採用分層架構，支援多級快取、容錯、均衡負載、就近訪問等，該架構依據分層原則主要分為四層：主機 DNS、快取 DNS、權威 DNS 及遞迴 DNS。　　

　　簡要介紹各層 DNS 的角色及作用：

　　主機 DNS：主機 DNS 主要部署在主機上，為物理機、虛擬機器和容器等提供高效 DNS 服務，具備 90% 以上的 DNS 快取能力；當域名資訊未命中主機 DNS 快取時，主機 DNS 會轉發該 DNS 查詢請求至後端的快取 DNS。

　　快取 DNS：接收並響應來自主機 DNS 轉發的域名解析請求，若未命中本地快取，則將帶有主機 DNS 子網資訊的 DNS 請求轉發至後端的權威 DNS，接收到權威 DNS 返回結果後將其回傳給請求者，同時在本地進行快取；因主機 DNS 部署在業務主機上，數量龐大，為增強內網配置可管理性，愛奇藝採用 Anycast 方案使每組快取 DNS 都繫結相同 Anycast IP，所有的主機 DNS 配置統一，大幅提升維護效率。

　　權威 DNS：權威 DNS 存放所有內網權威域名的地址資訊，當快取 DNS 轉發的請求域名為內網權威域名時，會根據主機 DNS 子網資訊優先返回其所屬區域的地址資訊，如果請求域名為非內網權威域名，則會將該 DNS 請求進一步轉發至遞迴 DNS 處理。

　　遞迴 DNS：遞迴 DNS 主要用來對非內網權威域名進行遞迴解析，將解析結果返回給權威 DNS、快取 DNS 直至主機 DNS。

　　上述內網 DNS 分層架構具備以下優點：

　　多級分層 DNS 快取架構，使訪問壓力層層遞減，大幅提升內網 DNS 域名解析能力，並降低響應延遲；

　　主機 DNS 直接部署在主機上，本地快取命中率超過 90%，極大降低對後端 DNS 的訪問壓力，降低主機 DNS 訪問的延遲，減小網路故障對主機 DNS 影響；

　　基於網路 Anycast 架構的快取 DNS，使全網主機 DNS 地址配置保持一致，降低主機側維護成本，可彈性擴容，節點故障及上下線對主機解析無影響，提供高效、安全、就近的 DNS 服務；

　　權威 DNS 統一管理 DNS 資料及業務策略，提供優秀的業務排程能力。

　　1.2 愛奇藝內網 DNS 架構演化

　　上述愛奇藝內網 DNS 架構並非一蹴而就，是在實踐中逐步演化而來，下圖展示了該演進過程：　　

　　一代 DNS 架構：早期內網 DNS 架構相對簡單，只有權威 DNS，採用 master/slave 模式；隨業務發展，內網 DNS 訪問壓力與日俱增，單層 DNS 架構已無法滿足業務訪問要求，所以衍生二代 DNS 架構；

　　二代 DNS 架構：主機上增加主機 DNS 承載大部分訪問壓力，中間層增加快取 DNS，進一步降低權威 DNS 負載；隨主機規模不斷增大，中間層快取 DNS 的節點數量不斷擴增，而每次 DNS 節點擴增或調整，都需要修改主機 DNS 上的配置項，維護複雜，DNS 服務高可靠性缺乏保障，因此愛奇藝內網 DNS 架構再次升級，演進為第三代 DNS 架構；

　　三代 DNS 架構：藉助於 Anycast 的網路架構，使 DNS 架構具備了彈性伸縮的能力，同時統一併簡化了主機 DNS 配置，降低了故障率與維護成本。

　　1.3 融合 Anycast 的內網 DNS 架構

　　愛奇藝 DNS 架構經過迭代，發展為高效穩定的 Anycast 架構，下圖以 Anycast IP 10.10.10.10 為例，介紹愛奇藝融合 Anycast 技術的內網 DNS 架構：　　

　　Anycast 技術，將一個單播地址分配到網路中多個不同物理位置的主機上，傳送到這個地址的報文被網路轉發到“最近”的目標主機，從而達到負載均衡及就近訪問的目的。愛奇藝 DNS Anycast 將路由協議部署到 DNS 主機上，和網路裝置進行聯動，透過動態路由控制 Anycast IP 浮動，出現故障時，將 Anycast IP 在故障主機上摘除，業務請求即可自動轉發到其他 Anycast 主機。

　　為了提高 Anycast 快速部署以及故障快速切換能力，愛奇藝將 DNS 進行平臺化管理，平臺具備以下功能：

　　平臺管理所有 DNS 主機，透過平臺快速進行主機 DNS 服務部署、路由模組部署等；

　　平臺提供一鍵上下線的功能，可透過平臺直接操作或者介面呼叫；

　　故障自主檢測，一旦檢測到故障即觸發故障主機摘除，其他 DNS 主機自動接管服務。

　　小結

　　融合 Anycast 的 DNS 架構，實現了 DNS 服務地址的統一,全網主機都可配置同一個 DNS 地址，大大降低了維護成本；平臺化管理，實現 DNS 配置標準化，支援故障主機自動摘除切換，使用者端無感知。新的架構和管理模式充分保障了 DNS 服務持續穩定、安全、可靠、高效地執行。

　　 02 混合雲時代的愛奇藝內網 DNS 架構

　　為實現業務高效靈活部署，愛奇藝與國內外多家主流雲廠商進行合作，將部分業務部署到公有云，同時保留核心的私有云基礎設施，形成自建私有云和公有云結合的混合雲模式。混合雲模式要求愛奇藝基礎服務平臺在公有云環境下提供和私有云一致的底層技術支撐，而 DNS 作為一項重要的基礎服務，在混合雲場景下如何為業務提供統一、穩定、高效、安全的域名解析成為一個棘手問題，為此愛奇藝技術團隊經過總結實踐，在原 DNS 架構上進一步設計了混合雲的 DNS 架構，實現標準化配置，統一化管理，全域性化服務的混合雲 DNS 服務的目標。

　　標準化配置：所有業務主機使用統一的 Anycast IP 作為唯一服務地址；

　　統一化管理：所有 DNS 伺服器均平臺化管理、自動化配置，做到 DNS 服務一鍵部署、一鍵上下線；

　　全域性化服務：私有云和公有云使用統一的 DNS 服務地址，既能解析私有云域名，又可解析公有云域名，同時可實現跨公有云解析。

　　2.1 混合雲場景下的 DNS 問題

　　混合雲場景下，不同的雲廠商都有獨立的 DNS 服務，並且只能解析自己相關的域名，無法解析私有云域名，更無法跨公有云進行域名解析。為實現混合雲時代 DNS 服務可標準化配置、統一化管理、全域性化服務的目標，愛奇藝技術團隊選擇 Anycast DNS+ 定向轉發的方案思路，同時將公有云 DNS 納入原 DNS 管理平臺實現統一化管理。

　　明確目標及解決方案後，愛奇藝開始在公有云環境下進行測試，因為公有云特殊的架構以及雲廠商之間的差異，需要公有云上解決以下問題：

　　公有云 VPC 內地址統一規劃，如何將 Anycast IP 部署到雲上實現 DNS 地址統一；

　　公有云底層網路對愛奇藝不可見，Anycast 和網路深度繫結，如何實現 DNS Anycast 在公有云上的部署；

　　不同公有云 DNS 地址可能獨立規劃，如何實現愛奇藝權威 DNS 和公有云 DNS 互通；

　　公有云廠商有獨立的地址規劃，如何實現 DNS 的正確解析以及雲上雲下服務互通；

　　特殊場景下如何實現公有云 DNS 對愛奇藝內網域名的解析。

　　針對上述問題，愛奇藝結合私有云 DNS 部署經驗以及各公有云網路實際情況，逐一解決並完成混合雲 DNS 架構設計。

　　2.2 混合雲場景下的內網 DNS 架構

　　網路架構：愛奇藝 DNS 和網路團隊設計的混合雲內網 DNS 架構如下圖所示，原私有云透過專線連線多個 IDC，公有云節點類似於愛奇藝自有 IDC，透過專線連線到愛奇藝核心 PoP 點，公有云節點可以橫向擴充套件，雲下 IDC 仍採用物理機和網路裝置實現 DNS Anycast，雲上採用 LB+ 虛機的部署方式。混合雲內網 DNS 充分考慮各雲廠商的網路狀況，解決上一章節提出的問題。

　　針對 Anycast IP 部署，目前主流公有云均支援 VPC 內的輔助地址，可透過輔助地址將 Anycast IP 部署到雲上；

　　針對雲上 DNS Anycast，透過公有云 LB 實現，在 LB 後端掛載 DNS 伺服器實現負載均衡；

　　針對不同雲廠商 DNS 地址互通問題，目前多家公有云均支援 VPC 內地址作為 DNS 地址，不支援的廠商將介紹其他替代方案；

　　針對公有云業務地址和雲下互通以及 DNS 解析問題，目前多數廠商均支援 VPC 內網段作為業務地址，不支援的廠商將介紹其他替代方案；

　　特殊場景下公有云 DNS 可透過 DNS 轉發器將愛奇藝內網域名解析請求轉發到愛奇藝 DNS 進行解析，目前主流公有云均支援，並配合愛奇藝技術團隊持續完善中。　　

　　DNS 架構：為了更清晰地展示各級 DNS 之間邏輯關係，可參考以下 DNS 服務邏輯架構圖，主機 DNS、快取 DNS、權威 DNS、遞迴 DNS，雲下透過傳統網路實現 Anycast，雲上透過 LB 實現，雲下權威伺服器和雲上權威伺服器網路互通，並透過統一平臺進行管理。　　

　　2.3 混合雲場景下的 DNS 實踐及分析

　　前文提出了混合雲環境下實現 DNS 統一部署的問題，並且結合網路環境給出瞭解決問題思路，下文詳細介紹愛奇藝內網 DNS 在公有云的部署實踐。

　　2.3.1 Anycast 地址下沉部署

　　在公有云環境要實現 Anycast 地址釋出，首先 VPC 內需存在該地址段，但是 VPC 在建立時便對各公有云網路進行了規劃，並確定了地址段，因此需要在現有 VPC 內新增加輔助地址段，如下圖示識1，並且建立 Anycast 地址專用的子網如下圖示識②，即可實現 Anycast IP 在公有云的部署。　　

　　2.3.2 DNS 服務下沉到公有云

　　私有云環境中，DNS 以物理機方式部署在 IDC 內部，並和交換機聯動透過路由協議實現 DNS Anycast，公有云環境中，物理網路對雲上不可見，要實現 DNS 服務下沉並部署 Anycast 需要透過 LB+ 虛擬機器，虛擬機器部署 DNS 快取服務，LB 繫結 Anycast IP，實現 DNS 服務的 Anycast 化。

　　在 DNS 服務下沉方案中，可以根據業務需求及公有云規模等情況，選擇只下沉 DNS 快取或者下沉快取及權威，下圖中選擇了下沉快取和權威，圖中標識步驟為業務伺服器 DNS 解析過程，業務主機配置 DNS 的 Anycast IP，解析請求透過 LB 轉發到後端快取 DNS 並向權威 DNS 請求解析，愛奇藝域名直接給出解析結果，雲上域名則轉發到公有云 DNS 進行解析。　　

　　在 DNS 服務下沉中，LB 服務承擔重要角色，轉發過程如下：

　　業務主機 DNS 請求 LB 上的 Anycast IP，經三層轉發到 LB；

　　LB 接受請求後做 DNAT，保持原地址不變，更改目的地址為 LB 後端掛載的 DNS 快取伺服器的真實地址，根據 hash 演算法轉發到相應的 DNS 快取伺服器；

　　DNS 快取伺服器接受請求後，根據業務主機地址判斷所屬區域，如命中快取直接返回解析結果，如未命中則請求權威進行解析後返回結果；

　　DNS 快取伺服器回包到 VSW 根據轉發表項到LB，LB更改源地址為Anycast地址後三層轉發到業務伺服器。

　　LB轉發有兩個特殊場景：

　　場景一：DNS快取伺服器和業務伺服器在同一網段。

　　傳統網路在二層環境下根據mac地址進行轉發，當DNS快取伺服器和業務伺服器在同一網段時，直接二層互通就繞過了LB，無法實現設計要求，但在雲網路環境下，同一網段伺服器 arp 請求均採用閘道器代答，閘道器響應 arp 請求，如下圖，可以看到主機上同網段地址解析為同一 mac 地址，將二層轉發變為三層轉發，再根據轉發表項到 LB，解決 DNS 快取伺服器和業務主機在同一網路的解析問題。　　

　　場景二：下沉 DNS 快取服務配置 Anycast IP。

　　下沉的 DNS 快取伺服器其 DNS 地址不能配置成 Anycast IP，因為存在 LB 轉發的 RS 為自己、無法回包給 LB 的情況，此場景還在尋找更好的解決方案。

　　2.3.3 私有云伺服器解析公有云域名

　　私有云伺服器解析公有云域名的本質是雲下權威伺服器能正常轉發到公有云 DNS 伺服器進行公有云域名解析。愛奇藝混合雲場景下要求所有主機均配置統一 DNS 地址，當私有云主機需要解析公有云域名時，請求轉發到雲下的權威伺服器，權威伺服器轉發到相應的公有云 DNS，解析過程如圖所示。當前公有云上 DNS 服務地址主要有兩種情況，主流公有云廠商支援自動使用 VPC 內網段 IP 地址作為 DNS 地址，如新建交換機時所關聯的網段第一個和第二個為 DNS 地址，部分公有云廠商採用自定義的固定 DNS 地址，比如使用 100.x.x.x 段做 DNS 地址。前者使用 VPC 內地址保證和雲下 DNS 權威互通，後者因使用獨立地址因此無法和雲下直接互通，當解析雲上域名時，權威 DNS 無法轉發請求到雲上，因此需要解決雲上 DNS 地址和雲下互通的問題，針對此種情況有三種解決方案，參考下圖步驟 4/5：

　　方案一：直接將雲上 DNS 地址段路由釋出到雲下，此方案可能存在地址衝突問題；

　　方案二：透過雲上配置 NAT 閘道器，經 NAT 轉換實現雲下 DNS 權威伺服器和雲上 DNS 伺服器互通，此方案需額外增加 NAT 伺服器，增加維護成本；

　　方案三：公有云上部署代理打通雲上雲下 DNS 服務，此方案同樣增加了資源和維護成本。

　　上述三種方案均為臨時性方案，都存在相應的弊端，目前愛奇藝主要採用第二種方案，並且持續推動所有公有云廠商都支援 VPC 內網段 IP 地址作為 DNS 服務地址。　　

　　2.3.4 私有云服務和公有云服務互通問題

　　公有云和私有云服務互通，必須保障 DNS 域名正常解析和雲上雲下業務地址互通。目前公有云 VPC 均實現和私有云互通，且大部分服務都可使用 VPC 規劃的地址，保證和雲下網路互通，但是部分公共服務一些雲廠商仍獨立規劃地址段，如使用 100.x.x.x 段地址，導致雲下使用者無法訪問雲上相應資源。此問題主要有三個解決方案，如下圖的步驟 5/6，需要根據公有云實際情況進行選擇：

　　方案一：直接將公有云地址段路由釋出到雲下，雲上 DNS 正常進行地址解析，雲下伺服器也能訪問雲上資源，此方案可能存在地址衝突問題；

　　方案二：在公有云服務前部署 LB，LB 後掛載公有云服務，並且調整 DNS 解析到 LB，此方案增加了 LB 資源和維護成本；

　　方案三：在公有云服務前部署代理，透過代理連通公有云和私有云，並且調整 DNS 解析到代理伺服器，此方案增加了代理伺服器資源和維護成本。

　　上述三個互通方案同樣均存在弊端，目前愛奇藝主要採用方案三解決此問題，同時持續推動公有云廠商配合標準化服務，實現基於 VPC 內 IP 地址提供所有服務。　　

　　2.3.5 公有云服務解析私有云域名

　　公有云廠商提供的部分服務為公共服務，預設使用公有云 DNS，如果這些服務需要和私有云部署的業務互通，公有云 DNS 是無法解析私有云域名的，此種場景下需要將私有云域名轉發到權威 DNS 進行解析，如下圖步驟，透過在公有云上配置 DNS 轉發，將私有云域名轉發到私有云權威 DNS，如果權威 DNS 伺服器部署在雲下，則保障公有云 DNS 和雲下權威 DNS 互通，互通方案可參考前述章節。　　

　　小結

　　當業務不斷髮展壯大，需要越來越多的服務資源時，對私有云資料中心進行擴容往往需要歷經選址、佈線、裝置上架、除錯等諸多環節，而公有云在成本、區域覆蓋、響應時間上提供了更高效的方式，因此愛奇藝開始接觸多家公有云並瞭解其網路架構，形成了統一的公有云網路接入方案，並結合自有 IDC 形成多 Region、多 AZ 的業務部署模式，實現業務快速部署上線。在此背景下，愛奇藝技術團隊希望公有云和私有云架構統一，實現全球一網的基礎網路服務，因此設計了新的 DNS 架構，在混合雲場景下實現了 DNS 標準化配置、統一化管理、全域性化服務三大目標。如前文所述在部署實踐中因不同廠商存在差異，當前採取了一些替代方案，並持續與各公有云廠商共同完善網路架構，滿足不同場景的需求。

　　 03 總結

　　愛奇藝內網 DNS 的發展歷程：從早期的雙主多從模式，到多層 DNS 叢集，再到融合 Anycast 的多層 DNS，最後到混合雲環境 DNS 架構，每個階段都是基於當時網路狀況，在總結上一階段架構經驗的基礎上，不斷迭代演化而成。當前的混合雲內網 DNS 方案（愛奇藝第四代內網 DNS 方案），是基於第三代 DNS 技術方案，在充分理解愛奇藝業務需求及公有云網路架構的基礎上，快速創新、持續演進、充分驗證後最終形成的，在全球範圍內為愛奇藝各類業務提供透明、安全、穩定、高效且彈性的域名解析服務，為愛奇藝全面適配混合雲架構打下堅實的基礎。