SpeedyCloud李孟：CDN系統中的DNS設計與開發
阿新 • • 發佈：2019-02-03
作者簡介
李孟
現任SpeedyCloud研發總監，目前主要負責資源排程系統的設計與研發工作，為迅達雲一站式雲服務平臺提供技術支撐。
李孟曾在藍汛就職7年，專注於CDN、GSLB及其衍生領域研發與實踐，是藍汛自主研發CDN、DNS的第一人，在研發與運營分析過程中積累了豐富的行業經驗。
導讀
隨著 CDN 的普及，人們對CDN與DNS的認識越來越深入，但是始終有兩大問題一直困擾著人們，即效能與排程 。具體來說主要表現為以下兩類問題：
1.如何評估各種業務場景下需要什麼指標水平的 CDN 與 DNS？
2.CDN與DNS如何表達流量排程？
李孟試圖通過本次演講來解決人們的這些疑問，並從以下4個方面來做全面的分析：
業務形式
CDN 服務的過程如上圖所示，在客戶選擇使用 CDN 之後，客戶可以將自己的域名通過CNAME方式指向 CDN 提供的域名上來，這樣可保證客戶域名和 CDN域名的彼此獨立性，這個過程是通過 DNS 來完成的。
CDN、DNS的支援協議標準
RFC 1035 是87年的協議，最後是ECS。一個月前ECS出了04版，大家會發現04版和03版之間有少量的修飾語變化，意味著不久以後ECS將成為一個真正的DNS協議，現在做CDN如果不支援ECS就落伍了。BIND是全球使用最廣的DNS服務，一年前它的開發版已支援ECS。
權威DNS通訊特點
如上圖所示的典型報文特徵，絕大多數是單包請求響應。如果不是自身報文過大，一般是2個9的訪問，基本上由單包完成，一來一回是小包，如果你域名是如a.cn一樣簡短，甚至比64個位元組還要小，則需要往後補充一個空白位到64。
DNS在訪問權威時，要求每次訪問的埠號不一樣。其業務特徵是，延遲敏感和分散式部署
系統消耗特徵
DNS 屬於IO密集型和CPU密集型雙高的業務，因為DNS協議從特徵上類似UDP或SMTP，從處理上，是一些像處理HTTP和字串壓縮，兩者結合後，就變成了 CPU 密集型的情況。
2. 域名解析過程
終端與Local DNS互動特徵
CDN 中 DNS 排程是基於使用者所使用的 LocalDNS 的，符合實際應用的場景。本地終端使用者群和Local DNS終端使用者群兩者並不重合，會導致排程時，你在Web伺服器或統計時的訪問和在LocalDNS定位上存在偏差。
Local DNS 與CDN的 DNS 互動特徵
目前在大陸環境裡，LocalDNS 是運營商佔了絕對的大頭，可以說在一個城市裡，往往只有幾組 DNS 決定了區域絕大部分的流量，剩下的可能是大型廠商自己的 DNS 組成的。
從CDN的DNS視角，它稀釋了熱點，可以說少量的請求決定了絕大部分的流量，大量請求的流量是微乎其微的。
LocalDNS與智慧DNS叢集互動特徵
在流量排程和CDN設計時，需要非常細緻地考慮這個環節。LocalDNS內部有一定的演算法，大家可以看一下BIND或OpenDNS，這兩個演算法類似。
LocalDNS擇優選擇
擇優選擇是依靠IPT。當LocalDNS發出一個請求，給一個叢集裡的某臺裝置，然後在解析中記錄IPT時間，根據IPT概率性的選擇，而不是100%。離我最近的會以最高的概率使用，低的會以較低的概率使用。
流量排程
每個DNS獲得的訪問是不對等的。北京的LocalDNS訪問叢集時偏向北京，天津的裝置會傾向於訪問北方，廣州的裝置傾向於訪問南方，上海的裝置則南北都有。
叢集擇優例項
試驗做法是架構標準的BIND。你可以關注某廠商或關注自身的DNS，通過抓包分析往返時間。當LocalDNS開始啟動時，因為不知道哪臺機器好，每個機器試一遍，順序是被打亂的，試完後發現IP1裝置是最好的，然後以大概率的形式使用這臺DNS。你會發現NS發生了一個小失誤，它的解析高了一點點，就被別人搶了。這個地方也是高了一些，解析就被別人搶去了……說明它對解析的速度是高度敏感的。
高延遲情形下的懲罰例項
我的客戶隔了一個LocalDNS,然後訪問到我的權威，如果我的權威訪問慢，有一個客戶倒黴，訪問是200毫秒，當後續的使用者過來，對LocalDNS就有排斥心理，這是大家都理解的概念。但是LocalDNS有一個擇優行為，當你此次訪問代價被客戶端稀釋，下一次訪問時你最優的裝置就被替換掉，你需要長時間訪問這個次優的裝置。
解析延遲敏感。最小的解析兩三毫秒的裝置，中間發生了一次失誤。裝置轉入次優平臺，次優經過一段時間的磨合，當你的域名有效期是1小時的話，1小時工作1次的話，時間就過去了。
持續地為次優的裝置服務，而次優裝置與其它裝置之間的差距較小，未來解析會比以前解析提高很多。
3. 效能要求
高品質DNS軟體的效能特徵
只有一個標準：跟本裝置上的ping值保持一致。
我做調研和工作時，就是選用一臺裝置的ping值和DNS返回時間的差距，來判斷伺服器的質量情況。
效能評估
經過LocalDNS的cache快取後，即使大型網際網路網站，到權威上的解析量也非常少（1000QPS一下），主流DNS是10萬左右的量級，甚至可以到50萬的量級，可以支撐一個相當大的業務。但另一方面DDoS基本10G以上的，其業務規模和攻擊防護的數量級的差別非常大。
設計DNS系統時，你應考慮面向什麼樣的開發訴求？比如是設計一個高靈活性低速DNS搭配第三方安全產品，還是設計特殊架構超高效能DNS。
評價效能時，線上的速率與你測試的速率經常容易出偏差。舉個例子，假設公司有一個域名，它的TTL是1個小時，也就是LocalDNS它會緩衝1小時，一個小時內不會再訪問該權威；另外CDNDNS會結合LDNS的特徵，根據LDNS和域名兩個條件找到對應的資料。這使對應資料至少需要相隔1小時才會被再次使用。另外權威是一個集群系統，LDNS不一定會訪問同一臺裝置。
我們知道計算機體系架構中包括儲存、CPU和軟體，會普遍存在根據使用狀況的將資料把它從下面慢速的裝置上提上來各級cache架構，相反的不使用的資料會逐漸從cache中淘汰下去。實際上我們做測試時，標準的linux和標準的BIND，沒有采取任何特別的優化，做測試時，也會差距70%或50%。建議設計開發的DNS服務達到什麼量級時，需要預留足有效能空間。有條件建議採取線網真實回量的方式，而且時間需要足夠得長，通過回量的方式測試效能。對於DNS使用的演算法、儲存等，需要額外考慮隨機提取的效率情況。
效能測試
效能測試的工具
前兩個是DNS軟體，第一個是BIND自帶的工具，可以進行全速測試，第二個可進行定量測試，第三個是tcpreplay回放的方式測試效能。
效能評價的誤區
評價權威DNS主要效能指標是QPS，不是併發。對於併發也與WEB、DB等有顯著區別。
我們測過BIND高壓時的情況，基本上是攻擊一撤服務就恢復。成熟的DNS往往是快速把超量的服務請求丟棄掉，避免堆積併發。
我也跟蹤去年.cn受到攻擊時，最嚴重時發現解析成功率只剩下1%左右，即使這樣的狀況，少量的成功解析延遲只有幾毫秒。對於WEB處理大併發處理時，拖一秒或許沒問題，但DNS必須實時應答，終端對LDNS容忍只有1秒，LDNS對權威DNS容忍只有0.8秒。還有就是CDN的DNS是CPU密集型的業務，一旦出現超量的訪問，會受限於CPU處理能力越堆越多。這種情形應果斷丟棄掉，避免高壓後導致一系列的問題，量力而行保持低延遲處理。
使用前2個工具來做效能評價，當然研發時可以做版本之間的效能比較，但用來預期線上效能指標達能達到什麼程度，這個就不太合適了。
LocalDNS的變化
大陸環境，一個大型的活躍LocalDNS在數千個左右，還有一個很長的長尾，加起來有十幾萬的規模。它的變化使用這種測試很難達到。一些安全原由，LDNS訪問權威DNS的埠是隨機變化的，也就是LDNS訪問五元組完全不重複。而前兩個工具，啟動時用的哪個埠就一直用這個埠，這種無法真實體現裝置網路底層的消耗。
工具配合節奏
前兩個工具預設並行十個請求，等你應答了，再發出下一個請求，每一個執行緒是溫和的配合DNS節奏打壓測試。但網際網路不是這樣，出現發出一萬QBS就是一萬QBS，即使你應答跟不上，它並不會減少。
另外DNS裡存在人為的波動，包括週期性的探測、網頁爬取及搜尋引擎爬取，平均值和瞬間峰值有相當大差距。
網路選型IO
網路選型I/0的點，IO大致的數量集。
值得一提的是DNS絕大部分訪問時沒有連線狀態，你發出一個請求，我給你一個應答請求，從底層看裸包和DNS報文之間的差距只是多了這一截，即使失去協議棧開發DNS服務難度也是可控的。
新近出現的DNS儲存
新近出現的DNS儲存叫LMDB，是OpenLdap的基礎儲存，它對讀資料進行高度優化。所列DNS軟體可以達到70萬QPS水準
負載均衡的選擇
很多負載均衡則面向有連線的狀態，UDP請求過來後，因為不知道什麼時候結束，需要維持一段時間連線直至超時。但DNS是小包單包通訊（類似ping），維持連線意義不大，無謂的消耗負載均衡資源。
處理高效能DNS場景裡，建議採用交換機和路由器作為負載均衡裝置，對DNS裝置構造『等價路由』 均分流量，它的速度就是交換機和路由器的三層的吞吐指標。
4.智慧CDN與DNS流量排程
例項分析
優化前，左側圖例是3個IP一個一個給的效果，DNS排程時給A一次，給B一次，給C一次，就像發撲克牌一樣看起很均衡，但看到圖中流量抖動達到60%。為什麼會發生抖動？跟前面提到的LocalDNS的規模差距非常大，這個例子在廣州，大型LDNS就是十幾個，分IP時易出現偏差，看細節時會發現這是此消彼漲的。DNS表達流量排程時，會直接影響後期的排程，探測到什麼樣的值，會調配多少流量。
排程參照2個指標：精度和準度。
當你設計排程模式時，需要注意排程的精度和準度。精度和準度特徵會導致你後期排程系統的風格不一。但精度高不一定準度高，DNS裡面的配置數值與你的排程流量是有偏差的，比如你在DNS裡的配置是1：1，但你表現出的流量是5：1。
準度好的排程表達方式，容易規劃預測流量，DNS表達50%流量就會是50%，後面提及準度好大部分演算法以犧牲精度為代價的。
排程的判斷依據
DNS排程時，慎重使用DNS統計資料作為流量排程依據，使用它們試圖達成流量排程，效果是不可預期的。
延遲特徵
整體上還有規律可遵循，但不適合把資料都彙總到一起，如果依賴中央資料互動與DNS低延遲特徵衝突，無法做到高效的快速應答。
常常採用固有屬性作為排程參考，比如一個IP屬於哪個城市？一個IP屬於哪個網路？無論Local DNS選擇哪個權威DNS都會相同結果，排程精度保證的。
採取無狀態的屬性達到其流量排程的目的，比如採取IP的Hash值，如果hash值是“0”分配策略A，Hash值為“1”分配策略B。還有隨機值，其效果是無狀態的，這像投擲硬幣的反正面，無論用誰的手100枚硬幣高概率平均起來是50%和50%，雖然這個數值會有些抖動
一個值得一提是排程表達特徵是被繼承的，有時很隱蔽。
一個常見場景是某客戶會選擇2個CDN廠商，他也有自建CDN系統，它做的是分流角色，將流量均分，一半域名解析給CDN
A，一半域名解析給CDNB，從客戶到達均分目的效果不錯（1000枚硬幣的反正面基本可以穩定500上下個）。但CDN廠商在其內部將排程細化到省，市時，比如深圳市，使用者上游分時就把深圳市的LocalDNS分成了兩個不斷漂移的兩半（10枚硬幣的反正面很難穩定在5：5））分給了CDN廠商，這就讓廠商繼承的是這種不穩定因素。
如果雲廠商遇到上面常見場景，這種大幅波動會干擾雲平臺的服務效果，需要安排額外冗餘資源，對於雲客戶常見就意味購買更高配置應對波動。