多主機 VM/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 物理網卡緩衝區
網路路由器
對於主機 2 上的 VM-2，鏡像的堆棧幾乎相同
假設該文件很大，那麼與 seccomp/apparmor、路由和防火牆相關的步驟將被記憶體/省略以用於已經打開和傳輸的文件。
但是如果虛擬機之間頻繁通信，消息小到可以放入 1-2 個 tcp 數據包，我們就會遇到問題
每個呼叫和邏輯處理都需要數百個 CPU 滴答，並且所描述的 overstack 會給 CPU 帶來很大的負載並在延遲中發揮作用。
- 根據測試 Docker 多主機網路性能$$ August, 2016 $$性能至少為-13%。
- 在VMware vSphere® 5 上的 Network I/O Latency “我們發現在空閒系統上，每個 VM 的往返延遲成本約為 15-20 微秒。隨著 vSphere 上資源爭用的增加，這個數字會增加，這是意料之中的。抖動只要係統沒有過度使用，它就非常低。”
- 此外，Meltdown 和 Spectre Intel 修復將導致更多的性能下降。
問題
- 虛擬機之間預先打開的通信套接字會省略描述列表中的任何步驟嗎？
- SDN是否以某種方式緩解了此類問題，還是為數據包添加了更多的覆蓋和額外的標頭？
- 我真的需要描述的過程來在 VM-1 和 VM-2 之間進行通信，還是有一個特殊的 linux “更少安全更多性能使用你自己的風險”建構？
- 我必須堅持使用linux嗎？任何支持 docker 的更快的類似 *BSD 的系統？
- 有哪些最佳實踐可以緩解這一瓶頸，從而在同一主機上安裝更多帶有微服務的虛擬機？
- 像Project Calico這樣的解決方案是否有幫助，或者它更多的是關於較低級別的？
虛擬機之間預先打開的通信套接字會省略描述列表中的任何步驟嗎？
由於 TCP 握手成本，VM/容器之間預先打開的套接字會起到作用；甚至更多，如果有 TLS。
儘管握手成本可以忽略不計是公認的，但是當我們談到頻繁的通信時，它開始發揮重要作用。
在類似網格的容器網路的情況下，擁有 M x N 開放連接的邊界狀態並不是很明智。基於您自己的容器通信統計的帶有 TTL 的簡單保活解決方案會更好。
請記住，保持 TCP 連接處於活動狀態的執行緒過多會導致另一個成本，因此請確保使用 epoll。
SDN 是否以某種方式緩解了此類問題，還是為數據包添加了更多的覆蓋和額外的標頭？
它確實添加了更多的覆蓋，許多是供應商鎖定的，但至少有一個下面描述的與 Docker 環境有關的管道 SDN相關解決方案。
我真的需要描述的過程來在 VM-1 和 VM-2 之間進行通信，還是有一個特殊的 linux “更少安全更多性能使用你自己的風險”建構？
我沒有找到具有足夠信任社區和更新支持的“特殊” linux 建構，但是慢速 linux TCP 堆棧的問題並不新鮮，並且有很多核心繞過選項。Cloudflare 就是這樣做的。
從我發現的文章中，緩慢的 linux TCP 堆棧是眾所周知的，並且沒有選擇插入 linux 伺服器並獲勝：您必須每次微調 Torvald 的孩子以這種或那種方式解決您自己的問題。
*我必須堅持使用linux嗎？任何支持 docker 的更快的類似 BSD 的系統？
沒有發現任何證據表明 Windows、MacOS 或 *BSD 類系統比最新的 linux 具有更好的網路，其慢速 TCP 堆棧和應用了核心繞過。
有哪些最佳實踐可以緩解這一瓶頸，從而在同一主機上安裝更多帶有微服務的虛擬機？
所以，有兩個瓶頸：guest linux和host linux。
對於主機 linux，如果它不僅用於容器託管，還有一種核心繞過策略，其中有多種選項，來自Cloudflare 部落格和“為什麼我們使用 Linux 核心的 TCP 堆棧？”中的描述。文章來編寫您自己的以應用程序為中心的 TCP 堆棧。
對於來賓 linux ，Macvlan可用於繞過第 3 層並將 docker 容器直接連接到具有自己 MAC 地址的 NIC。它比 bridge 好得多，因為它緩解了很多來賓和主機 linux 網路瓶頸，但請確保您已準備好用另外數百或數千條記錄來擴展您的路由器 mac 地址表 - 很可能您將不得不對您的網路。
此外，根據虛擬交換技術和 Linux 橋介紹，還有一個 SR-IOV 選項，它比 Macvlan 更好。它可用於 docker 1.9+ 的 Mellanox 乙太網適配器作為外掛，作為pipework SDN中的一種模式，具有來自 Clear Containers 的專用SRIOV 外掛- 足以開始探勘以應用程序為中心的解決方案。
像 Project Calico 這樣的解決方案是否有幫助，或者它更多的是關於較低級別的？
它完全是另一個層次，與 SRIOV 和 Macvlan 相比不會產生重大影響，但它們有助於簡化網路管理，在您選擇的旁路解決方案之上幾乎沒有成本。
是的…
密切監視您的 Docker，因為它可能會做意想不到的事情。例如它 modprobes
nf_nat和xt_conntrack，在沒有理由打開 Macvlan 的情況下，它會導致額外的 CPU 滴答消耗。