Prestaties afstemmen van Windows Server-containers

Introductie

Vanaf Windows Server 2022 zijn er twee typen containers beschikbaar: Windows Server-containers en Hyper-V-containers. Elk containertype ondersteunt de Server Core- of Nano Server-SKU van Windows Server 2022.

Deze configuraties hebben verschillende gevolgen voor de prestaties, die hieronder worden beschreven om u te helpen begrijpen wat geschikt is voor uw scenario's. Daarnaast beschrijven we de prestaties die van invloed zijn op configuraties en beschrijven we de compromissen met elk van deze opties.

Windows Server-container en Hyper-V-containers

Windows Server-container en Hyper-V-containers bieden veel van dezelfde draagbaarheids- en consistentievoordelen, maar verschillen in termen van hun isolatiegaranties en prestatiekenmerken.

Windows Server-containers bieden isolatie van toepassingen via proces- en naamruimteisolatietechnologie. Een Windows Server-container deelt een kernel met de containerhost en alle containers die op de host worden uitgevoerd.

Hyper-V Containers uitbreiden over de isolatie die door Windows Server-containers wordt geboden door elke container uit te voeren op een maximaal geoptimaliseerde virtuele machine. In deze configuratie wordt de kernel van de containerhost niet gedeeld met de Hyper-V Containers.

De extra isolatie die door Hyper-V containers wordt geboden, wordt in grote mate bereikt door een hypervisorlaag van isolatie tussen de container en de containerhost. Dit is van invloed op de containerdichtheid, omdat, in tegenstelling tot Windows Server-containers, minder delen van systeembestanden en binaire bestanden kan optreden, wat resulteert in een algehele grotere opslag- en geheugenvoetafdruk. Bovendien is er de verwachte verdere overhead in sommige netwerk-, opslag-IO- en CPU-paden.

Nano Server en Server Core

Windows Server Containers en Hyper-V Containers bieden ondersteuning voor Server Core: meer informatie over de opties voor de containerbasisimages.

Nano Server is een extern beheerd serverbesturingssysteem dat is geoptimaliseerd voor privéclouds en datacenters. Het is vergelijkbaar met Windows Server in de Server Core-modus, maar aanzienlijk kleiner, heeft geen lokale aanmeldingsmogelijkheden en ondersteunt alleen 64-bits toepassingen, hulpprogramma's en agents. Het neemt veel minder schijfruimte in beslag, stelt aanzienlijk sneller in en vereist veel minder updates en opnieuw opstarten dan Windows Server. Wanneer het opnieuw wordt opgestart, wordt het veel sneller opnieuw opgestart.

Container Start-Up Tijdstip

Opstarttijd van containers is een belangrijke metriek in veel van de scenario's die containers het grootste voordeel bieden. Daarom is het essentieel om te begrijpen hoe u het beste de opstarttijd van containers kunt optimaliseren. Hieronder volgen enkele afwegingen bij het afstemmen om een verbeterde opstarttijd te bereiken.

Eerste keer inloggen

Microsoft levert basisimages voor zowel Nano Server als Server Core. De basisafbeelding die voor Server Core verzonden wordt, is geoptimaliseerd door de overhead van de opstarttijd weg te nemen die is gekoppeld aan de eerste keer dat er wordt ingelogd (OOBE). Dit is niet het geval bij de basisinstallatiekopieën van Nano Server. Deze kosten kunnen echter worden verwijderd uit op Nano Server gebaseerde images door ten minste één laag aan de containerimage toe te voegen. Voor de volgende container die vanaf de afbeelding start, worden de eerste inlogkosten niet in rekening gebracht.

Locatie van scratchruimte

Containers gebruiken standaard een tijdelijke scratchruimte op de systeemstationmedia van de containerhost voor opslag tijdens de levensduur van de actieve container. Dit fungeert als het systeemstation van de container, en daardoor volgen veel van de schrijf- en leesbewerkingen die bij de containeroperatie worden uitgevoerd dit pad. Voor hostsystemen waar het systeemstation bestaat op draaiende schijf magnetische media (HDD's) maar snellere opslagmedia beschikbaar zijn (snellere HDD's of HDD's), is het mogelijk om de scratchruimte van de container naar een ander station te verplaatsen. Dit wordt bereikt met behulp van de opdracht dockerd -g. Deze opdracht is systeemwijd en heeft invloed op alle containers die op het systeem worden uitgevoerd.

Ingebouwde Hyper-V containers

Hyper-V voor Windows Server 2022 biedt geneste hypervisorondersteuning. Dat wil gezegd: de mogelijkheid om een virtuele machine uit te voeren vanuit een virtuele machine. Dit opent veel nuttige scenario's, maar overdreven ook een zekere invloed op de prestaties die de hypervisor ondervindt, omdat er twee niveaus van hypervisors zijn die boven de fysieke host worden uitgevoerd.

Voor containers is dit van invloed op het uitvoeren van een Hyper-V container in een virtuele machine. Aangezien een Hyper-V Container isolatie biedt via een hypervisorlaag tussen zichzelf en de containerhost, is er, wanneer de containerhost een Hyper-V virtuele machine is, prestatieoverhead gekoppeld aan de opstarttijd van containers, opslag-io, netwerk-io en doorvoer en CPU.

Opslag

Gekoppelde gegevensvolumes

Containers bieden de mogelijkheid om het hostsysteemstation van de container te gebruiken voor de scratchruimte van de container. De scratchruimte van de container heeft echter een levensduur die gelijk is aan die van de container. Als de container wordt gestopt, gaat de scratchruimte en alle bijbehorende gegevens weg.

Er zijn echter veel scenario's waarin gegevens behouden blijven onafhankelijk van de levensduur van de container. In deze gevallen ondersteunen we het mounten van gegevensvolumes van de containerhost in de container. Voor Windows Server-containers is er een te verwaarlozen IO-padoverhead gekoppeld aan gekoppelde gegevensvolumes (bijna systeemeigen prestaties). Bij het koppelen van gegevensvolumes aan Hyper-V containers is er echter sprake van prestatievermindering van de I/O op dat pad. Bovendien wordt deze impact versterkt bij het uitvoeren van Hyper-V containers binnen virtuele machines.

Kladruimte

Zowel Windows Server-containers als Hyper-V-containers bieden standaard een dynamische VHD van 20 GB voor de scratchruimte van de container. Voor beide containertypen neemt het container-besturingssysteem een deel van die ruimte in beslag en dit geldt voor elke container die is gestart. Het is dus belangrijk om te onthouden dat elke container die is gestart, enige invloed heeft op de opslag en afhankelijk van de werkbelasting maximaal 20 GB van de back-upopslagmedia kan schrijven. Serveropslagconfiguraties moeten worden ontworpen met dit in gedachten.

Netwerken

Windows Server-containers en Hyper-V-containers bieden verschillende netwerkmodi die het beste aansluiten bij de behoeften van verschillende netwerkconfiguraties. Elk van deze opties bevat hun eigen prestatiekenmerken.

Vertaling van Windows-netwerkadressen (WinNAT)

Elke container ontvangt een IP-adres van een intern privé-IP-voorvoegsel (bijvoorbeeld 172.16.0.0/12). Het doorsturen of toewijzen van poorten van de containerhost naar container-endpoints wordt ondersteund. Docker maakt standaard een NAT-netwerk wanneer de dockerd voor het eerst wordt uitgevoerd.

Van deze drie modi is de NAT-configuratie het duurste netwerk-IO-pad, maar heeft de minste configuratie nodig.

Windows Server-containers gebruiken een host-vNIC om te koppelen aan de virtuele switch. Hyper-V Containers gebruiken een synthetische VM-netwerkinterfacekaart (niet blootgesteld aan de VM van het hulpprogramma) voor aansluiting op de virtuele switch. Wanneer containers communiceren met het externe netwerk, worden pakketten gerouteerd via WinNAT, waarbij adresvertalingen worden toegepast, wat enige overhead met zich meebrengt.

Doorzichtig

Elk containereindpunt is rechtstreeks verbonden met het fysieke netwerk. IP-adressen van het fysieke netwerk kunnen statisch of dynamisch worden toegewezen met behulp van een externe DHCP-server.

Transparante modus is de goedkoopste in termen van het io-pad van het netwerk en externe pakketten worden rechtstreeks doorgegeven aan de virtuele NIC van de container die directe toegang tot het externe netwerk geeft.

L2-brug

Elk containereindpunt bevindt zich in hetzelfde IP-subnet als de containerhost. De IP-adressen moeten statisch worden toegewezen vanaf hetzelfde voorvoegsel als de containerhost. Alle containereindpunten op de host hebben hetzelfde MAC-adres vanwege laag-2-adresomzetting.

L2 Bridge-modus is beter presterend dan de WinNAT-modus omdat deze directe toegang biedt tot het externe netwerk, maar minder goed presterend is dan de transparante modus, omdat hiermee ook MAC-adresomzetting wordt geïntroduceerd.