Leistungsoptimierung von Windows Server-Containern

Einleitung

Ab Windows Server 2022 sind zwei Containertypen verfügbar: Windows Server-Container und Hyper-V-Container. Jeder Containertyp unterstützt entweder die Server Core- oder Nano Server-SKU von Windows Server 2022.

Diese Konfigurationen haben unterschiedliche Leistungsauswirkungen, die wir unten detailliert erläutern, um zu verstehen, welche für Ihre Szenarien geeignet ist. Darüber hinaus beschreiben wir die Leistungsauswirkungen von Konfigurationen und beschreiben die Kompromisse mit den einzelnen Optionen.

Windows Server-Container und Hyper-V-Container

Windows Server-Container und Hyper-V-Container bieten viele der gleichen Portabilitäts- und Konsistenzvorteile, unterscheiden sich jedoch hinsichtlich ihrer Isolationsgarantien und Leistungsmerkmale.

Windows Server-Container bieten Anwendungsisolation durch Prozess- und Namespaceisolationstechnologie. Ein Windows Server-Container teilt einen Kernel mit dem Containerhost und allen Containern, die auf dem Host ausgeführt werden.

Hyper-V Container erweitern die von Windows Server-Containern bereitgestellte Isolation, indem jeder Container auf einem hochoptimierten virtuellen Computer ausgeführt wird. In dieser Konfiguration wird der Kernel des Containerhosts nicht für die Hyper-V Container freigegeben.

Die zusätzliche Isolation, die von Hyper-V Containern bereitgestellt wird, wird größtenteils durch eine Hypervisorschicht der Isolation zwischen dem Container und dem Containerhost erreicht. Dies wirkt sich auf die Containerdichte aus, da im Gegensatz zu Windows Server-Containern eine geringere Freigabe von Systemdateien und Binärdateien auftreten kann, was zu einem insgesamt größeren Speicher- und Speicherbedarf führt. Außerdem kommt es für einige Netzwerk-, Speicher-E/A- und CPU-Pfade zum erwarteten erhöhten Mehraufwand.

Nano Server und Server Core

Windows Server-Container und Hyper-V-Container bieten Unterstützung für Server Core. Erfahren Sie mehr über die Container-Basisimage-Optionen.

Nano Server ist ein remote verwaltetes Serverbetriebssystem, das für private Clouds und Rechenzentren optimiert ist. Es ähnelt Windows Server im Server Core-Modus, aber deutlich kleiner, verfügt über keine lokale Anmeldefunktion und unterstützt nur 64-Bit-Anwendungen, Tools und Agents. Es beansprucht viel weniger Speicherplatz, richtet deutlich schneller ein und erfordert viel weniger Updates und Neustarts als Windows Server. Wenn er neu startet, geschieht dies viel schneller.

Startzeit von Containern

Die Containerstartzeit ist in vielen Szenarien, in denen Container den größten Nutzen bieten, eine schlüsselmetrische Metrik. Daher ist es wichtig, zu verstehen, wie Sie die Startzeit des Containers am besten optimieren können. Nachfolgend finden Sie einige Tuning-Trade-Offs, die Sie verstehen können, um eine verbesserte Startzeit zu erzielen.

Erste Anmeldung

Microsoft liefert ein Basisimage für Nano Server und Server Core. Das Basisimage für Server Core wurde optimiert, indem der Mehraufwand für die Startzeit beseitigt wurde, der mit der ersten Anmeldung (Windows-Willkommensseite) verbunden ist. Dies ist beim Nano Server-Basisimage nicht der Fall. Diese Kosten können jedoch von Nano Server-basierten Images entfernt werden, indem mindestens eine Ebene zum Containerimage hinzugefügt wird. Für nachfolgende Containerstarts über das Image fällt der Aufwand für die erste Anmeldung dann nicht mehr an.

Ort des temporären Speicherbereichs

Für Container wird standardmäßig ein temporärer Speicherbereich auf Systemlaufwerkmedien des Containerhosts verwendet, um Daten während der Lebensdauer des ausgeführten Containers zu speichern. Dies dient als Systemlaufwerk des Containers, und damit erfolgen viele der Schreib- und Lesevorgänge während des Containerbetriebs über diesen Pfad. Für Hostsysteme, bei denen das Systemlaufwerk auf sich drehenden Magnetmedien (HDDs) vorhanden ist, aber schnellere Speichermedien (schnellere HDDs oder SSDs) verfügbar sind, ist es möglich, den Container scratch space auf ein anderes Laufwerk zu verschieben. Dies wird mithilfe des Befehls dockerd –g erreicht. Dieser Befehl ist global und wirkt sich auf alle Container aus, die auf dem System ausgeführt werden.

Geschachtelte Hyper-V-Container

Hyper-V für Windows Server 2022 bietet geschachtelte Hypervisorunterstützung. Das heißt, die Funktion zum Ausführen eines virtuellen Computers von einem virtuellen Computer aus. Dies eröffnet viele nützliche Szenarien, übertreibt aber auch einige Leistungseinbußen, die der Hypervisor verursacht, da zwei Hypervisorebenen über dem physischen Host ausgeführt werden.

Bei Containern hat dies Auswirkungen, wenn ein Hyper-V Container auf einem virtuellen Computer ausgeführt wird. Da ein Hyper-V-Container eine Isolation über eine Hypervisorebene zwischen sich selbst und dem Containerhost bietet, gibt es bei einem Hyper-V-basierten virtuellen Computer Leistungseinbußen hinsichtlich der Startzeit des Containers, Speicher-I/O, Netzwerk-I/O, Durchsatz, und CPU.

Lagerung

Eingebundene Datenvolumes

Bei Containern ist es möglich, dass das Systemlaufwerk des Containerhosts für den sicheren Speicherbereich des Containers verwendet wird. Der sichere Speicherbereich des Containers verfügt aber über eine ähnlich lange Lebensdauer wie der Container. Dies bedeutet, dass der temporäre Speicherbereich und alle zugeordneten Daten verloren gehen, wenn der Container angehalten wird.

Es gibt jedoch viele Szenarien, in denen Daten unabhängig von der Containerlebensdauer beibehalten werden sollen. Für diese Fälle wird das Einbinden von Datenvolumes vom Containerhost in den Container unterstützt. Für Windows Server-Container ist der E/A-Pfadaufwand, der mit eingebundenen Datenvolumes verbunden ist, vernachlässigbar (nahezu native Leistung). Wenn Datenvolumes aber in Hyper-V-Container eingebunden werden, kommt es unter diesem Pfad zu E/A-Leistungsbeeinträchtigungen. Darüber hinaus wird diese Auswirkung übertrieben, wenn Hyper-V Container auf virtuellen Computern ausgeführt werden.

Temporärer Speicherbereich

Sowohl für Windows Server-Container als auch für Hyper-V-Container wird für den temporären Speicherbereich des Containers standardmäßig eine dynamische VHD mit 20 GB bereitgestellt. Für beide Containertypen nimmt das Containerbetriebssystem einen Teil dieses Speicherplatzes ein, und dies gilt für jeden gestarteten Container. Daher ist es wichtig zu beachten, dass jeder gestartete Container einige Speicherwirkungen hat, und je nach Workload kann bis zu 20 GB des Sicherungsspeichermediums geschrieben werden. Serverspeicherkonfigurationen sollten unter Berücksichtigung dieser Konfigurationen entworfen werden.

Vernetzung

Windows Server-Container und Hyper-V-Container bieten verschiedene Netzwerkmodi, die den Anforderungen unterschiedlicher Netzwerkkonfigurationen am besten entsprechen. Jede dieser Optionen stellt ihre eigenen Leistungsmerkmale dar.

Windows-Netzwerkadressenübersetzung (WinNAT)

Jeder Container empfängt eine IP-Adresse von einem internen, privaten IP-Präfix (z. B. 172.16.0.0/12). Portweiterleitung/Zuordnung vom Containerhost zu Containerendpunkten wird unterstützt. Docker erstellt standardmäßig ein NAT-Netzwerk, wenn die Dockerd zum ersten Mal ausgeführt wird.

Von diesen drei Modi ist die NAT-Konfiguration der teuerste Netzwerk-E/A-Pfad, verfügt jedoch über die geringste Menge an Konfiguration.

Windows Server-Container verwenden eine Host-vNIC für die Verbindung mit dem virtuellen Switch. Hyper-V-Container verwenden eine synthetische VM-NIC (nicht für die Utility-VM verfügbar gemacht) für die Verbindung mit dem virtuellen Switch. Wenn Container mit dem externen Netzwerk kommunizieren, werden Pakete über WinNAT weitergeleitet, wobei Adressübersetzungen angewendet werden, was zu einem gewissen Aufwand führt.

Durchsichtig

Jeder Containerendpunkt ist direkt mit dem physischen Netzwerk verbunden. IP-Adressen aus dem physischen Netzwerk können mithilfe eines externen DHCP-Servers statisch oder dynamisch zugewiesen werden.

Transparenter Modus ist der am wenigsten teure Netzwerk-E/A-Pfad, und externe Pakete werden direkt an die virtuelle Container-NIC übergeben, die direkten Zugriff auf das externe Netzwerk ermöglicht.

L2-Brücke

Jeder Containerendpunkt befindet sich im gleichen IP-Subnetz wie der Containerhost. Die IP-Adressen müssen aus demselben Präfix wie der Container-Host statisch zugewiesen werden. Alle Containerendpunkte auf dem Host weisen aufgrund der Layer-2-Adressübersetzung dieselbe MAC-Adresse auf.

Der L2-Brückenmodus ist leistungsfähiger als der WinNAT-Modus, da er direkten Zugriff auf das externe Netzwerk bietet, aber weniger performant als der transparente Modus, da er auch die MAC-Adressübersetzung einführt.