Prestandajustering av Windows Server-containrar

Introduction

Från och med Windows Server 2022 är två typer av containrar tillgängliga: Windows Server-containrar och Hyper-V-containrar. Varje containertyp stöder antingen Server Core eller Nano Server SKU för Windows Server 2022.

Dessa konfigurationer har olika prestandakonsekvenser, som vi beskriver nedan för att hjälpa dig att förstå vad som är rätt för dina scenarier. Dessutom beskriver vi prestanda som påverkar konfigurationer och beskriver kompromisserna med vart och ett av dessa alternativ.

Windows Server-container och Hyper-V-containrar

Windows Server Container och Hyper-V-containrar erbjuder många av samma portabilitets- och konsekvensfördelar men skiljer sig när det gäller isoleringsgarantier och prestandaegenskaper.

Windows Server-containrar tillhandahåller programisolering genom process- och namnområdesisoleringsteknik. En Windows Server-container delar en kernel med containervärden och alla containrar som körs på värden.

Hyper-V Containers expanderar isoleringen som tillhandahålls av Windows Server-containrar genom att köra varje container på en mycket optimerad virtuell dator. I den här konfigurationen delas inte containervärdens kernel med Hyper-V Containers.

Den extra isolering som tillhandahålls av Hyper-V containrar uppnås till stor del genom ett hypervisor-lager av isolering mellan containern och värden för containern. Detta påverkar containerdensiteten eftersom, till skillnad från Windows Server-containrar, mindre delning av systemfiler och binärfiler kan uppstå, vilket resulterar i ett övergripande större lagrings- och minnesavtryck. Dessutom finns det förväntad ytterligare belastning i vissa nätverksvägar, lagrings-I/O och CPU-vägar.

Nano Server och Server Core

Windows Server-containrar och Hyper-V-containrar har stöd för Server Core, läs mer om alternativen för containerbasavbildning.

Nano Server är ett fjärradministrerat serveroperativsystem som är optimerat för privata moln och datacenter. Det liknar Windows Server i Server Core-läge, men betydligt mindre, har ingen lokal inloggningskapacitet och stöder endast 64-bitarsprogram, verktyg och agenter. Det tar upp mycket mindre diskutrymme, konfigurerar betydligt snabbare och kräver mycket färre uppdateringar och omstarter än Windows Server. När den startas om startas den om mycket snabbare.

Container Start-Up: Tid

Starttiden för containrar är ett nyckelmått i många av de scenarier som containrar har störst nytta av. Därför är det viktigt att förstå hur du bäst optimerar för starttiden för containrar. Nedan följer några justeringsavvägningar att förstå för att uppnå förbättrad uppstartstid.

Första inloggningen

Microsoft skickar en basavbildning för både Nano Server och Server Core. Basavbilden som levereras för Server Core har optimerats genom att ta bort initial uppstartsbelastning som är kopplad till första inloggningen (OOBE). Så är inte fallet med Nano Server-basavbildningen. Den här kostnaden kan dock tas bort från Nano Server-baserade avbildningar genom att minst ett lager läggs till i containeravbildningen. Senare containrar som startar från avbildningen medför inte kostnad för första inloggningen.

Läge för scratch-utrymme

Containrar använder som standard ett tillfälligt ledigt utrymme på containervärdens systemenhetsmedia för lagring under den aktiva containerns livslängd. Detta fungerar som containerns systemdisk, och därför följer många av de skrivningar och läsningar som görs vid containerdrift den här sökvägen. För värdsystem där systemenheten finns på snurrande diskmagnetmedia (HDD) men snabbare lagringsmedia är tillgängligt (snabbare hårddiskar eller SSD:er) är det möjligt att flytta containerns reputrymme till en annan enhet. Detta uppnås med hjälp av kommandot dockerd –g. Det här kommandot är globalt och påverkar alla containrar som körs i systemet.

Kapslade Hyper-V containrar

Hyper-V för Windows Server 2022 erbjuder kapslat hypervisor-stöd. Det vill: möjligheten att köra en virtuell dator inifrån en virtuell dator. Detta öppnar upp många användbara scenarier men överdriver även vissa prestandaeffekter som hypervisor-programmet medför, eftersom det finns två nivåer av hypervisor-program som körs ovanför den fysiska värden.

För containrar påverkas detta när du kör en Hyper-V-container på en virtuell maskin. Eftersom en Hyper-V-container erbjuder isolering genom ett hypervisorlager mellan sig själv och containervärden, finns det prestandaomkostnader när containervärden är en Hyper-V-baserad virtuell dator. Dessa omkostnader är kopplade till starttid för containern, lagrings-I/O, nätverks-I/O, genomströmning och CPU.

Storage

Monterade datavolymer

Containrar erbjuder möjligheten att använda containerns värdsystemenhet för containerns reputrymme. Containerns tillfälliga lagringsutrymme har dock en livslängd som är lika med containerns livslängd. När containern stoppas försvinner alltså det tillfälliga utrymmet och alla associerade data.

Det finns dock många scenarier där det är önskvärt att ha data oberoende av containerns livslängd. I dessa fall stöder vi montering av datavolymer från containervärden till containern. För Windows Server-containrar är den I/O-överkostnaden som är associerad med monterade datavolymer försumbara (nära naturlig prestanda). Men när du monterar datavolymer i Hyper-V-containrar finns det en viss försämring av I/O-prestanda i den processen. Dessutom är den här effekten överdriven när du kör Hyper-V containrar i virtuella datorer.

Scratch Space

Både Windows Server-containrar och Hyper-V-containrar ger en dynamisk VHD på 20 GB som standard för containerns scratchutrymme. För båda containertyperna tar containeroperativsystemet upp en del av det utrymmet, och det gäller för varje container som startas. Därför är det viktigt att komma ihåg att varje container som startas har viss lagringspåverkan, och beroende på arbetsbelastningen kan skriva upp till 20 GB lagringsmedia. Serverlagringskonfigurationer bör utformas med detta i åtanke.

Networking

Windows Server-containrar och Hyper-V containrar erbjuder olika nätverkslägen för att bäst passa behoven i olika nätverkskonfigurationer. Vart och ett av dessa alternativ visar sina egna prestandaegenskaper.

Översättning av Windows-nätverksadresser (WinNAT)

Varje container får en IP-adress från ett internt, privat IP-prefix (till exempel 172.16.0.0/12). Portvidarebefordring/mappning från containervärden till containerslutpunkter stöds. Docker skapar ett NAT-nätverk som standard när dockerd först körs.

Av dessa tre lägen är NAT-konfigurationen den dyraste nätverks-I/O-sökvägen, men har den minsta mängd konfiguration som behövs.

Windows Server-containrar använder ett virtuellt värdnätverk för att ansluta till den virtuella växeln. Hyper-V Containers använder ett syntetiskt VM NIC (som inte exponeras för Utility VM) för att ansluta till den virtuella switchen. När containrar kommunicerar med det externa nätverket dirigeras paket via WinNAT med tillämpade adressöversättningar, vilket medför vissa omkostnader.

Transparent

Varje containerslutpunkt är direkt ansluten till det fysiska nätverket. IP-adresser från det fysiska nätverket kan tilldelas statiskt eller dynamiskt med hjälp av en extern DHCP-server.

Transparent läge är det minst kostsamma när det gäller nätverks-I/O-sökvägen, och externa paket skickas direkt till det virtuella nätverkskortet i containern vilket ger direkt åtkomst till det externa nätverket.

L2-brygga

Varje containerslutpunkt finns i samma IP-undernät som containervärden. IP-adresserna måste tilldelas statiskt med samma prefix som värddatorn för containern. Alla containerslutpunkter på värden kommer att ha samma MAC-adress på grund av Layer-2-adressöversättning.

L2-bryggläge är mer högpresterande än WinNAT-läge eftersom det ger direkt åtkomst till det externa nätverket, men mindre högpresterande än transparent läge eftersom det också introducerar MAC-adressöversättning.