☰

多主機虛擬機器/Docker 網路通訊速度很慢，有什麼最佳實務嗎？

tag-icon • tag-icon linux networking virtual-machines docker latency
多主機虛擬機器/Docker 網路通訊速度很慢，有什麼最佳實務嗎？ 
VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2

如果我理解正確，如果檔案從 VM-1 上的應用程式傳輸到 VM-2 上的相同應用程序，則資料將經歷以下過程：

  • VM-1應用程式檔案讀到記憶體緩衝區
    • 程式語言相關調用
    • 作業系統級調用
    • seccomp/apparmor 邏輯
    • 檔案系統權限邏輯
    • 作業系統檔案處理和緩衝區
  • VM-1 應用程式資料傳送至網路套接字緩衝區
    • 作業系統調用
    • seccomp/apparmor 邏輯
  • VM-1作業系統網路堆疊
    • 路由表
    • 防火牆邏輯
  • Host-1 虛擬機器管理程式虛擬網路堆疊
    • 虛擬交換機
    • 路由表
  • Host-1 作業系統網路堆疊
    • 路由表
    • 防火牆邏輯
  • Host-1實體網路卡緩衝區
  • 網路路由器
  • host-2 上的 VM-2 鏡像的幾乎相同堆疊

假設該文件很大，那麼對於已經開啟和傳輸的文件，與 seccomp/apparmor、路由和防火牆相關的步驟將被快取/省略。

但是，如果虛擬機器之間頻繁通訊且訊息小到足以容納 1-2 個 TCP 封包，我們就會遇到問題

每次呼叫和邏輯處理都需要數百個 CPU 時脈週期，而所述的堆疊溢位會給 CPU 帶來巨大的負載並導致延遲。

問題

  1. 虛擬機器之間預先開啟的通訊套接字是否會省略所描述清單中的任何步驟？
  2. 做軟體定義網路以某種方式緩解此類問題，還是為資料包添加更多的覆蓋層和額外的標頭？
  3. 我是否真的需要所描述的流程來在 VM-1 和 VM-2 之間進行通信，或者有一個特殊的 Linux「安全性較低、性能較高、使用風險自負」版本？
  4. 我必須堅持使用 Linux 嗎？有沒有更快且支援 docker 的類似 *BSD 的系統？
  5. 有哪些最佳實踐可以緩解該瓶頸，從而在同一台主機上安裝更多具有微服務的虛擬機器？
  6. 解決方案像印花布計劃幫助還是更多關於較低級別？

答案1

虛擬機器之間預先開啟的通訊套接字是否會省略所描述清單中的任何步驟？

由於 TCP 握手開銷，虛擬機器/容器之間預先開啟的套接字會發揮作用；如果有 TLS，甚至更多。

儘管人們普遍認為握手開銷很小，可以忽略不計，但當我們談到頻繁溝通時，它就開始發揮重要作用。

在網狀容器網路的情況下，擁有 M x N 個開放連接的邊界狀態並不是很明智。基於您自己的容器通信統計數據的帶有 TTL 的簡單保持活動解決方案會更好。

請記住，太多執行緒保持 TCP 連線處於活動狀態將導致其他開銷，因此請確保使用 epoll。

SDN 是否能以某種方式緩解此類問題，或者是否會為資料包添加更多覆蓋層和額外標頭？

它確實添加了更多覆蓋層，其中許多是供應商鎖定的，但至少有一個管道SDN下面介紹的相關解決方案是關於Docker環境的。

我是否真的需要所描述的流程來在 VM-1 和 VM-2 之間進行通信，或者有一個特殊的 Linux「安全性較低、性能較高、使用風險自負」版本？

我沒有找到具有足夠信任的社區和更新支援的“特殊”Linux 構建，但 Linux TCP 堆疊緩慢的問題並不新鮮，並且有很多內核繞過選項。Cloudflare 就是這樣做的。

從我找到的文章，緩慢的 Linux TCP 堆疊是眾所周知的，並且沒有選擇插入 Linux 伺服器並獲勝：你必須每次都以這樣或那樣的方式微調 Torvald 的孩子來解決你自己的問題。

我必須堅持使用 Linux 嗎？有沒有更快且支援 docker 的類似 *BSD 的系統？

沒有發現任何證據表明 Windows、MacOS 或類似 *BSD 的系統比最新的 Linux 具有更好的網路功能，因為其 TCP 堆疊速度較慢且應用了核心旁路。

有哪些最佳實踐可以緩解該瓶頸，從而在同一台主機上安裝更多具有微服務的虛擬機器？

因此，存在兩個瓶頸：來賓linux和主機linux。

對於主機 Linux，如果它不僅用於容器託管，則有一個核心繞過策略，其中描述了多種選項Cloudflare 部落格和“我們為什麼要使用 Linux 核心的 TCP 堆疊？”文章編寫您自己的以應用程式為中心的 TCP 堆疊。

對於訪客 Linux麥克夫蘭可用於繞過第 3 層並使用自己的 MAC 位址將 docker 容器直接連接到 NIC。這是比橋好多了，因為它減輕了許多來賓和主機 Linux 網路瓶頸，但請確保您準備好用另外數百或數千筆記錄來擴展您的路由器 MAC 位址表 - 很可能您將不得不對您的網路進行分段。

還根據虛擬交換技術與Linux橋接器演示有一個 SR-IOV 選項，它比 Macvlan 更好。這是適用於 Mellanox 乙太網路轉接器的 docker 1.9+作為插件，作為一種模式包含在管道SDN, 已專門Clear Containers 的 SRIOV 插件- 足以開始挖掘以應用程式為中心的解決方案。

像 Project Calico 這樣的解決方案是否有幫助，或者它更多地涉及較低級別？

它完全是另一個級別，與 SRIOV 和 Macvlan 相比不會產生重大影響，但它們有助於簡化網路管理，並且在您選擇的旁路解決方案之上幾乎沒有任何開銷。

是的...

密切監視您的 Docker，因為它可能會做意想不到的事情。例如，它 modprobesnf_nat和xt_conntrack，在沒有理由打開 Macvlan 的情況下，會導致額外的 CPU 滴答消耗。

相關內容