如何藉助Anycast技術拯救運維工程師的睡眠？

半夜十二點，小王正在酣睡。

忽然一陣清脆的手機鈴聲響起，把小王從睡夢中拉扯回現實。

「喂，誰啊？」

「王工，我是監控中心的，公司的xxx服務器掛了，你趕忙看一下吧。」

小王揉了揉眼睛，起身打開筆記本電腦，開始了一宿的不眠夜。

做爲一名運維工程師，以上橋段常常發生在你們身邊。白天繁重的工做已經讓人筋疲力盡，而夜間做爲電話值班工程師，仍不得不面對時刻突發的網絡或系統故障。生活黑白顛倒，日夜不分。

 

試問，拿什麼來拯救運維工程上的睡眠？

 

再給你們說一個故事。

 

我有一個朋友，他是Cloudflare的網絡工程師，咱姑且叫他「錢哥」。

我和錢哥閒聊之餘，問了問他們的夜間電話值班任務是否繁重辛苦。他淡淡的回答以下：

 

「咱們全世界範圍內若是有某個站點（PoP）掛了，徹底不擔憂也不用着急。工程師該睡覺睡覺，該休息休息。」

我十分不解，你要知道Cloudflare是一家全球CDN服務提供商，聽說全世界10%的互聯網流量都運行在他們家網絡上。

常識性來講，擁有如此體量的公司，其中某一個區域性站點down掉是一件極其嚴重的事情。而錢哥的回答卻讓我百思不得其解，徹底顛覆了個人認知。

 

都是工程師，差距如此之大，別人夜晚睡覺，咱們機房乾耗！

 

在個人一番追問以後，總算明白他們其中的奧祕，原來一切都歸功於他們使用了Anycast這技術。

 

那咱們是否也能像錢哥同樣，藉助於Anycast技術，還工程師們一個寧靜的睡眠之夜？

 

科普科普，什麼是Anycast技術？

在IP地址的世界裏，你們熟知的IP地址類型大體有以下幾種：

Unicast IP

單播IP，IP地址和主機是一一對應關係。

 

以下圖，紅色爲數據包發送端，而綠色節點爲數據包接收端。

當數據包發送給某一個特定IP地址時，全局下僅有一個數據包接收主機。此爲Unicast。

 

 

Multicast IP

組播IP，組播IP擁有特定的IP地址段，當數據包發送給此組播IP地址後，組內成員都能收到此數據包的一份拷貝。

 

以下圖，紅色爲數據包發送端，而綠色節點爲數據包接收端。

當數據包發送給某一個特定組播IP地址時，同時存在多個數據包接收端。

Broadcast IP

廣播IP，任意Unicast單播網段中最後一個IP地址。數據包發送給此地址會擴散給全廣播域的成員。

 

以下圖，紅色爲數據包發送端，而綠色節點爲數據包接收端。

當數據包發送給廣播IP地址時，全部成員均爲數據包接收端。

 

 

而Anycast IP，則是集Multicast和Unicast特性於一身的特殊IP地址類型

Anycast中文稱爲任意播。

從宏觀上來講，Anycast相似於Multicast，同一種類型的數據流同時存在多個接收者。

而從微觀上來講，Anycast又有着Unicast的惟一性。每個單獨的IP會話都可以找到惟一的源主機和目標主機。

 

咋看之下很矛盾，其實否則.

 

以DNS請求爲例，假設全國人民同一時間發送1百萬個DNS請求，他們都是發送給1.1.1.1的Anycast  DNS服務器地址。

 

宏觀上來講，全部數據包都送達給了分佈在全國各地的DNS服務器。處於各地的DNS服務器分別接收到了必定數量的DNS請求，並做出回覆。這體現了Multicast的特性。

 

微觀上，某一個特定的DNS請求數據包，必定是發送給了某一臺DNS主機，而不是同時又多臺DNS主機接收到了此數據包。此爲Unicast特性。

 

以下圖，紅色爲數據包發送端，而綠色節點爲數據包接收端。

 

在Anycast 環境下，總的來講，同時存在多個有效的數據包接收端，可是就某一個特定IP數據包而言，僅有一個接收端主機收到了此數據包。

 

 

 

Anycast 到底牛掰在哪裏？

在企業網絡環境中，Anycast不太常見，其主要應用於大範圍的DNS部署，CDN數據緩存，數據中心等。

 

天然而然，不少作企業網絡維護的朋友會有疑問。怎麼能讓互聯網的多個主機用同一個IP，這豈不是IP地址衝突了？

 

回答：

首先，每個服務器主機處在不一樣的地理位置，他們之間不在同一個廣播域內。因此把全部主機配置成相同的IP地址並不會引發咱們平常所見的IP地址衝突。

其次，光靠配置相同的IP地址時不夠的，咱們還須要藉助強大的BGP幫忙。

 

經過BGP，各個站點向Internet宣告相同的Anycast IP地址。

 

天然而然，Internet 就會接收到不一樣目標路徑，可是具備相同IP地址段的prefix。那數據包是如何在這種環境下路由的呢？

 

別急，往下看。

 

爲了讓你們有更深入的理解和認識，下面將詳細描述Anycast的主要優點和用途

：

用途一：Load-balancing 負載均衡以及系統冗餘性

 

不講理論了，直接上例子，方便理解。

 

爲了闡明使用Anycast和負載均衡，以及冗餘性的關係，特舉例以下：

假設咱們如今有三個DNS服務器站點，地點分別在北京，上海，廣州。他們服務了全國的DNS解析服務。

 

按照通常的解決方案，爲了實現三個DNS服務器負載均衡，可能有人會考慮到使用硬件負載均衡設備，例如常見的F5負載均衡設備等。

 

但若使用硬件負載均衡，隨之帶來的問題有：

1.    網絡流量瓶頸，全部有流量都須要先經過負載均衡設備，而硬件設備自己的吞吐量決定了整個網絡環境的吞吐量。

 

2.    高昂的硬件成本，爲了實現全國的流量負載均衡，試想須要多大吞吐量的硬件設備。硬件吞吐量越大，購買成本就越高。

 

而經過Anycast技術，無須要藉助任何第三方負載均衡器，就能夠輕鬆達到負載均衡的效果，同時還提供了冗餘和高可靠性。

 

實施方案以下：

 

經過配置三個DNS站點的服務器IP爲相同IP，例如1.1.1.1/32。而後經過各個站點的BGP對互聯網宣告1.1.1.0/24的網段。

 

（注：爲何要宣告/24，而不是/32? 。由於在Internet裏面，爲了減少全球Internet路由表尺寸，默認狀況下運營商只接受小於等於/8，而大於等於/24的網段宣告進入互聯網。）

 

以上步驟完成之後，互聯網路由錶針對1.1.1.1/24會有三個不一樣的出口路由器，分別是北京，上海，廣州。

 

重點來了，由於全部用戶都使用1.1.1.1做爲他們的DNS服務器。

以東北的用戶來講，哪一臺DNS服務器會給東北的用戶提供解析呢？

 

答案就是：就近原則！

 

 

讓咱們來看看數據包在網絡中的路由細節：

 

當用戶的DNS請求到達運營商的寬帶路由器之後，運營商的路由器會根據BGP的選路原則選擇到達1.1.1.1的最優路徑。

 

例如，在用戶寬帶運營商和DNS服務器Internet運營商相同的狀況下，最終會以IGP metric爲關鍵因素來決定哪一個DNS服務器給用戶提供服務。

而IGP的 Metric某種程度上就是物理距離的表明。

如上圖，四川的寬帶路由器經過查看BGP路由，發現1.1.1.1出口最優路由是在廣州。那麼四川用戶的DNS數據包將被髮送給廣州的DNS服務器。

 

同理，東北的用戶DNS解析將會被髮往北京的DNS服務器，而江南一帶的則是上海DNS服務器負責。

 

萬一出現故障怎麼辦？

 

若是三臺DNS服務器中某一臺出現故障，例如廣東DNS服務宕機。BGP協議會當即中止通告此1.1.1.0/24的網段。Internet 路由表將會只有北京和上海的DNS可供選擇。

 

此時原廣東DNS服務的用戶將再次根據「就近原則」選擇其餘DNS服務器，例如上海DNS。

從而達到業務的平滑遷移和服務的高可用性。

 

基於以上的分析，咱們很容易就得出以下結論：

全國用戶最終會根據距離DNS服務器的遠近來判斷使用哪一個DNS服務器作域名解析。

 

從DNS角度來講，正由於不一樣的地理位置用戶會根據就近路由判斷，從而選擇不一樣的DNS服務器，最終會使三臺DNS服務器達到負載均衡的效果。

 

若其中某一個節點出現故障之後，業務會當即遷移到其餘可用的節點上，從而避免網路服務故障。徹底不須要人工干預。

 

以上就是Anycast在負載均衡中的用途說明。

 

 

用途二：防範DDOS***

 

相信不少在運營商工做的朋友都很是討厭DDOS***。

當DDOS發生時，10G或100Gbps的流量忽然蜂擁而來，佔用運營商核心MPLS網路帶寬不說，這種洪泛***會給客戶網絡形成短期的癱瘓。形成的損失極大。

 

在闡述Anycast防範DDOS***細節以前，讓咱們先來看看DDOS是如何產生的。

 

以NTP協議爲例，NTP協議是client-server模式，客戶發起NTP時間查詢申請，服務器響應NTP查詢。看似正常的NTP數據流量有時候及其容易被玩壞。

 

假設某個***控制了成千上萬的殭屍主機，這些殭屍主機紛紛僞造以下數據包併發送給全球NTP服務器：

 

源地址：1.2.3.4 （僞造源地址爲 被***者的IP地址）

目標地址：全球各個NTP服務器地址。（越多越好）

當全世界各地的NTP服務器收到此查詢之後，它會把查詢結果發送回給真正的受害者1.2.3.4。

這時IP地址爲1.2.3.4 的受害者收到全世界的NTP服務器發過來的數據包時，其有限的帶寬鏈路就很容易產生擁塞並形成服務中斷。

 

假設這些殭屍不僅是發送一次虛假數據包，而是上萬次。

那麼受害者接收到的NTP回覆數據包量將以下：

 

虛假數據包發送數量 x 全世界NTP服務器的數量= 最終DDOS***的流量。

 

Anycast如何防範DDOS***？

 

好了，鋪墊完成之後，回到正題。Anycast如何防範DDOS***？

 

DDOS***最關鍵一點，是須要把全部地理位置分散的小流量最終聚集到一個點。從而造成濤濤洪水。

正所謂以彼之道，還施彼身。

在Anycast環境下，因爲多個地理位置不一樣的主機同時使用同一個IP地址。正由於如此，DDOS流量在穿越運營商路由器時，路由器會根據地理位置遠近把數據包路由到距離源地址最近的受害者主機站點。從而分散掉整個DDOS流量。

 

仍是以上述NTP協議DDOS爲例。

假設IP爲1.2.3.4的受害者恰巧佈局了Anycast協議。其服務器分佈在全國各地。

 

當DDOS來臨時，不一樣的NTP服務器根據路由選擇，把流量發送到距離NTP服務器最近的受害者服務器上。

最終，本來10Gbps-100Gbps的彙總流量被各個目標服務器以1Gbps不足的DDOS***消化掉。

如上圖所示，DDOS流量最終被每個Anycast 主機分散掉了。

 

大型企業使用案例

 

既然Anycast好處多多，有多少企業部署了呢？

據我瞭解，包括Microsoft，Cloudflare，LinkedIn以及其餘企業都在全球範圍內使用了Anycast技術。

 

下面我就以Cloudflare和LinkedIn爲例給你們簡單介紹下，他們是如何部署的。

 

Cloudflare

 

Cloudflare做爲CDN網絡佼佼者，其主要採用了Anycast技術爲用戶提供距離用戶最近的Cache服務器。從而大大提升了用戶的服務體驗滿意度。

 

Cloudflare全球建設了118個數據中心，憑藉於Anycast的高冗餘性，正如本文開頭提到的，任何一個數據中心出現網絡、系統故障。均不會影響客戶體驗度，全部當地的客戶流量會自動路由到其餘就近的數據中心。

 

 

上圖爲Cloudflare的全球數據中心分佈圖

 

藉助於Anycast的優點，相比傳統企業網絡面對網絡節點故障的脆弱性，Cloudflare這方便就顯得很是遊刃有餘了。

 

下面這張圖爲Cloudflare的部分數據中心Pop節點，請重點關注紅框部分。

紅框部分是美國-費城的一個數據中心節點，尾隨其後有一個關鍵字「Re-routed」。

其含義爲，此數據中心由於故障或者其餘緣由不能正常工做，全部費城的Cloudflare用戶流量將會被自動路由到離費城最近的數據中心，無需人工干預。

  

 

看到這裏，有些老鳥就禁不住想問。

Anycast是挺不錯，可是看起來都是例如DNS，或者CDN在使用。

並且，不管是DNS服務提供商仍是CDN服務提供商，他們最大的特色在於：每一個Pop站點的服務器內容徹底同樣，因此客戶不管訪問站點A或者站點B，均能獲取到相同的內容。

 

那讓咱們來看一個不同的例子，以下。

 

LinkedIn

 

LinkedIn你們最熟悉不過了，找工做攀人脈LinkedIn是常常去的地方。

可是你可知道LinkedIn一樣使用了Anycast技術。但是LinkedIn是純粹的網頁內容服務提供商。他與CDN，DNS提供商等性質不太相同。

 

並且你們須要注意的是，LinkedIn的流量可全是HTTPS，TCP流量。並不是通常你們部署的DNS UDP流量。

 

那爲何LinkedIn也對Anycast如此感興趣呢？

 

故事要從幾年前提及。

話說當LinkedIn業務急速擴展之後，出現了用戶體驗度差的問題，緣由在於「時延」兩個字。

由於數據中心地理位置固定，而用戶位置多是全世界各地。很天然，地理位置遙遠的用戶訪問LinkedIn時會產生高時延問題。加上HTTP，HTTPS協議採用了話癆型的TCP協議。

 

這TCP幾回握手來回之後，加上後續HTTP數據流。原本時延就高的連接加上TCP信令數據包一來二去。用戶體驗度很是糟糕。

 

爲了解決以上問題，LinkedIn引入小型數據中心站點(Pops)。在全世界有業務的地方構架小型DC。同時小型DC與美國總部的數據中心之間長期維持着穩定的TCP會話連接。

 

當遠端用戶訪問LinkedIn後，TCP連接實際上是發送給了當地的小型DC，小型DC再經過已有的TCP連接訪問總部DC。從而大大減小了中間TCP信令會話的數量，變相下降了訪問延時，提升了用戶體驗度。

上圖爲，在沒有小型數據中心的狀況下，人機交互的流程以及時延。

 

下圖爲在用戶所在地部署小型數據中心之後，時延的變化。

 

 

哎哎哎，別扯遠了，這和Anycast有半點關係麼？

當LinkedIn在全世界範圍內大批量部署小型DC之後，擺在他們面前的問題是，如何讓用戶可以就近訪問當地的小型DC，而不是選擇遠端的數據中心總部？

 

這不就是Anycast擅長的麼？

 

對，LinkedIn也是這麼想的，因而乎他們把整個美國的小型DC的IP地址修改成相同的IP，並經過BGP發佈到Internet。

 

當用戶訪問LinkedIn時，DNS解析會返回此小型DC 的IP，而後用戶運營商會根據就近原則路由用戶數據到最近的小型DC。從而達到了上面所述的優化延遲的目的。

 

以下圖所示，經過使用Anycast技術之後，LinkedIn小型DC訪問命中率大大提升。

 

總結

今天咱們一塊兒研究了什麼是Anycast，以及Anycast的妙用。

正如開頭所說，Anycast並非一個新技術，可謂是舊瓶裝新酒。

可是經過結合BGP協議，變相提升了Anycast的使用廣度和深度。

 

最後，針對Anycast 作以下總結：

優勢：

• Anycast能夠零成本實現負載均衡，無視流量大小。

• Anycast是自然的DDOS防護措施，體現了大事化小，小事化了的解決方法。

• 部署Anycast能夠得到設備的高冗餘性和可用性。

• Anycast適用於無鏈接的UDP，以及有鏈接的TCP協議。

 

缺點：

• Anycast嚴重依賴於BGP的選路原則，在整個Internet網絡拓撲復雜的狀況下，會致使次優路由選擇。

固然，就篇幅有限，不可能把全部內容一一介紹，你們有興趣的話，能夠繼續深刻研究Anycast的其餘妙用。

 

謝謝你們。