數據中心丟包分析及解決方案

上周對數據中心tcp數據傳輸的超時重傳時間進行了探究，是的，我們可以縮短重傳超時時間，但為什么在數據中心內部也會出現丟包呢？下面會對這個問題進行探討。

下面幾種丟包情形是大家所熟悉的：
1?數據中心內網的某個端口的帶寬跑滿
2?四層，如lvs狀態表溢出，新建連接時無法分配狀態，所以放棄新連接
3?七層，包括web服務器的監聽隊列backlog滿，丟棄新建的連接請求

接下來分析一個跟應用部署架構相關的丟包場景，如下圖：


多個發送者向一個接受者發送數據，這樣接受方上連的交換機端口，在任何一時刻只能發送一個數據包，而與此同時會收到多個待發送的數據包，交換機有兩種辦法來應對這樣的傳輸場景：
1?發送數據的速度，比發送者發送的數據的速度快。比如，接受方上連的端口是萬兆，而所有發送者都是千兆上連。
2?每個端口有一個ouput buffer，該端口的外發數據包，暫存在這個obuf中

交換機端口的output buffer滿時，再往這個端口發送數據包時，新來的包就會被交換機丟棄，這就是網絡層丟包的原因之一。

理論上講，發送方增加一倍機器，對output buffer需求增加一倍，同樣，發送方的發送數據的速度增加一倍，對output buffer的需求也會培加一倍。而交換機的buffer是有限的，這樣丟包的機率跟發送方的數量和發送的速度正相關。

在數據中心內部有哪些地方，存在多方向一方發數據，而丟包呢，接著看下圖：

如下圖，丟包的情況如下：
1?多臺七層設備，如haproxy，向四層lvs回數據包
2?多臺real server，向七層如haproxy回數據包
3?服務器訪問多臺mc或redis，這樣多臺mc向服務器回數據包
4?服務器訪問內部的服務，多臺服務器向內部的lvs機器發送數據包；多臺服務器訪問同一個內部資源，如redis也是類似的場景

而同城多個idc之間，還存在一個丟包場景，如下圖：

上面兩個數據中心，通過內部專線連通，左邊的數據中心多臺服務器，發送數據到右邊的數據中心的服務器上，左邊的數據中心跟專線相連的交換機端口，存在交換機buffer不夠，而丟包的情形。

上面分析了丟包的場景，接下來分析可能的解決方案，如下圖：


1?減少發送方的數量。這個需要修改部署架構。
2?降低數據傳送的rto時間，這樣在buffer剛滿丟包時，發送方就能發現丟包，而快速降低發送速度，避免事態擴大。
3? 更換大buffer交換機，這個治標不治本。另外的方式是交換機支持ECN(Explict Congestion Notification)，在output buffer達到某個閾值時，在發出去的包的ip頭上增加ecn標志，接受方收到數據后，回傳的數據包或ack包會帶上ecn標志，發送方收到數據或 ack后，就能發現鏈路中資源吃緊，快速響應降低發送速度，重而避免出現buffer滿。
4、接受方降低tcp的recv space，減少發送方的速度。

在跨idc丟包的場景中，依賴于所有項目都能協調一致進行調整，不然，一個項目做合法公民，與事無補，呵呵。

歡迎拍磚和提供更多的丟包場景。呵呵。

來自：http://weibo.com/p/1001603826393342443230