☰

Die Multi-Host-VM/Docker-Netzwerkkommunikation ist LANGSAM, gibt es eine bewährte Methode?

tag-icon • tag-icon linux networking virtual-machines docker latency
Die Multi-Host-VM/Docker-Netzwerkkommunikation ist LANGSAM, gibt es eine bewährte Methode? 
VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2

Wenn ich das richtig verstehe, durchlaufen die Daten beim Dateitransfer von einer Anwendung auf VM-1 zu derselben Anwendung auf VM-2 folgenden Weg:

  • VM-1-Anwendungsdatei in den Speicherpuffer lesen
    • Programmiersprachenbezogene Aufrufe
    • Aufrufe auf Betriebssystemebene
    • Seccomp/Apparmor-Logik
    • Dateisystem-Berechtigungslogik
    • Dateiverwaltung und Pufferung des Betriebssystems
  • VM-1-Anwendungsdaten an Netzwerk-Socket-Puffer gesendet
    • Betriebssystemaufrufe
    • Seccomp/Apparmor-Logik
  • VM-1-Betriebssystem-Netzwerkstapel
    • Routingtabellen
    • Firewall-Logik
  • Virtueller Netzwerkstapel des Host-1-Hypervisors
    • virtueller Switch
    • Routingtabellen
  • Host-1-Betriebssystem-Netzwerkstapel
    • Routingtabellen
    • Firewall-Logik
  • Physischer Netzwerkkartenpuffer von Host-1
  • Netzwerkrouter
  • Fast der gleiche Stapel gespiegelter Dinge wird hier für VM-2 auf Host-2 angezeigt

Unter der Annahme, dass die Datei groß sein wird, werden die mit Seccomp/Apparmor, Routing und Firewall verbundenen Schritte für bereits geöffnete und übertragene Dateien zwischengespeichert/ausgelassen.

Aber bei häufiger Kommunikation zwischen virtuellen Maschinen mit Nachrichten, die klein genug sind, um in 1-2 TCP-Pakete zu passen, haben wir ein Problem

Jeder Anruf und jede logische Verarbeitung benötigt mehrere hundert CPU-Ticks, und der beschriebene Überstapel führt zu einer erheblichen Belastung der CPU und trägt zur Latenz bei.

  • GemäßTesten der Docker-Multihost-Netzwerkleistung [August 2016]es ist mindestens -13 % in der Leistung.
  • InNetzwerk-E/A-Latenz auf VMware vSphere® 5„Wir haben festgestellt, dass auf einem inaktiven System die Roundtrip-Latenz pro VM etwa 15 bis 20 Mikrosekunden beträgt. Diese Zahl steigt, wenn die Ressourcenkonkurrenz auf vSphere zunimmt, was zu erwarten ist. Der Jitter war sehr gering, solange das System nicht überlastet war.“
  • Darüber hinaus führen die Intel-Fixes für Meltdown und Spectre zu noch größeren Leistungseinbußen.

Fragen

  1. Werden bei vorab geöffneten Kommunikations-Sockets zwischen VMs irgendwelche Schritte in der beschriebenen Liste ausgelassen?
  2. TutSDNGibt es eine Möglichkeit, derartige Probleme irgendwie zu mildern, oder werden den Paketen dadurch noch mehr Overlays und zusätzliche Header hinzugefügt?
  3. Benötige ich wirklich den beschriebenen Prozess zur Kommunikation zwischen VM-1 und VM-2 oder gibt es einen speziellen Linux-Build „weniger sicher, mehr Leistung, Verwendung auf eigenes Risiko“?
  4. Muss ich überhaupt bei Linux bleiben? Gibt es schnellere *BSD-ähnliche Systeme mit Docker-Unterstützung?
  5. Welche Best Practices gibt es, um diesen Engpass zu beseitigen und dadurch mehr VMs mit Mikrodiensten auf demselben Host unterzubringen?
  6. Sind Lösungen wieProjekt CalicoHilfe oder geht es eher um ein niedrigeres Niveau?

Antwort1

Werden bei vorab geöffneten Kommunikations-Sockets zwischen VMs irgendwelche Schritte in der beschriebenen Liste ausgelassen?

Aufgrund des TCP-Handshake-Overheads können vorab geöffnete Sockets zwischen VMs/Containern hilfreich sein; und noch besser, wenn ein TLS vorhanden ist.

Obwohl allgemein anerkannt ist, dass der Handshake-Overhead vernachlässigbar gering ist, beginnt er bei häufiger Kommunikation eine bedeutende Rolle zu spielen.

Bei einem netzartigen Containernetzwerk ist es nicht sehr sinnvoll, einen Grenzzustand von M x N offenen Verbindungen zu haben. Eine einfache Keep-Alive-Lösung mit TTL basierend auf den Kommunikationsstatistiken Ihrer eigenen Container ist besser.

Bedenken Sie, dass zu viele Threads, die TCP-Verbindungen aufrechterhalten, einen weiteren Overhead verursachen. Stellen Sie daher sicher, dass Sie Epoll verwenden.

Mildert SDN solche Probleme irgendwie oder fügt es den Paketen noch mehr Overlays und zusätzliche Header hinzu?

Es werden weitere Overlays hinzugefügt, viele davon sind herstellergebunden, aber es gibt mindestens einesRohrleitungen SDNVerwandte Lösung, die unten beschrieben wird und sich auf die Docker-Umgebung bezieht.

Benötige ich wirklich den beschriebenen Prozess zur Kommunikation zwischen VM-1 und VM-2 oder gibt es einen speziellen Linux-Build „weniger sicher, mehr Leistung, Verwendung auf eigenes Risiko“?

Ich habe keinen „speziellen“ Linux-Build mit ausreichend vertrauenswürdiger Community- und Update-Unterstützung gefunden, aber Probleme mit dem langsamen Linux-TCP-Stack sind nichts Neues und es gibt viele Optionen zur Umgehung des Kernels.Cloudflare macht das.

AusArtikel, die ich gefunden habe, der langsame Linux-TCP-Stack ist bekannt und es gibt keine Option, einen Linux-Server einzubinden und zu gewinnen: Sie müssen dieses Torvald-Kind jedes Mal feinabstimmen, um Ihr eigenes Problem auf die eine oder andere Weise zu lösen.

Muss ich überhaupt bei Linux bleiben? Gibt es schnellere *BSD-ähnliche Systeme mit Docker-Unterstützung?

Habe keine Hinweise darauf gefunden, dass Windows-, MacOS- oder *BSD-ähnliche Systeme eine bessere Netzwerkfunktion aufweisen als das neueste Linux mit seinem langsamen TCP-Stack mit angewandtem Kernel-Bypass.

Welche Best Practices gibt es, um diesen Engpass zu beseitigen und dadurch mehr VMs mit Mikrodiensten auf demselben Host unterzubringen?

Es gibt also zwei Engpässe: Gast-Linux und Host-Linux.

Für Host-Linux, falls es nicht nur für das Hosten von Containern verwendet wird, gibt es eine Kernel-Bypass-Strategie mit einer großen Auswahl an Optionen, die in beschrieben werdenCloudflare-BlogUndArtikel „Warum verwenden wir den TCP-Stack des Linux-Kernels?“zum Schreiben Ihres eigenen anwendungsorientierten TCP-Stacks.

Für Gast-LinuxMacvlankann verwendet werden, um Layer 3 zu umgehen und den Docker-Container direkt mit der Netzwerkkarte mit seiner eigenen MAC-Adresse zu verbinden. Es istviel besser als Bridge, weil dadurch viele Netzwerkengpässe sowohl bei Gast- als auch bei Host-Linux gemildert werden. Stellen Sie jedoch sicher, dass Sie bereit sind, die MAC-Adresstabelle Ihres Routers um weitere Hundert oder Tausend Datensätze zu erweitern – höchstwahrscheinlich müssen Sie Ihr Netzwerk segmentieren.

Auch gemäßPräsentation virtueller Switching-Technologien und Linux BridgeEs gibt eine SR-IOV-Option, die sogar noch besser ist als Macvlan. Es istverfügbar für Docker 1.9+ für Mellanox Ethernet Adapterals Plugin, enthalten als Modus inRohrleitungen SDN, hatSRIOV-Plugin von Clear Containers– mehr als genug, um mit der Suche nach anwendungsorientierten Lösungen zu beginnen.

Helfen Lösungen wie Project Calico oder liegt es eher auf niedrigerem Niveau?

Es handelt sich um eine völlig andere Ebene und wird im Vergleich zu SRIOV und Macvlan keine bedeutenden Auswirkungen haben, aber sie tragen dazu bei, die Netzwerkverwaltung zusätzlich zu der von Ihnen gewählten Bypass-Lösung fast ohne Overhead zu vereinfachen.

Und ja...

Beobachten Sie Ihren Docker genau, da er unerwartete Dinge tun kann. Beispielsweise führt er Modprobes aus nf_natund xt_conntrackohne Grund führt er bei eingeschaltetem Macvlan zu zusätzlichen CPU-Ticks-Aufwendungen.

verwandte Informationen