Under andra kvartalet i år kommer vi att ha prisvärda servrar med upp till 48 kärnor (AMD:s Magny-kurser) och 64 trådar (Intel Nehalem EX). Det mest uppenbara sättet att utöva all den makten är att konsolidera enorma mängder virtuella maskiner på dessa kraftverk. Vanligtvis kommer vi förmodligen att se något i stil med 20 till 50 virtuella datorer på sådana maskiner. Portaggregation med ett quad-port gigabit Ethernet-kort kommer förmodligen inte att räcka. Om vi har 40 virtuella datorer på ett quad-port Ethernet är det mindre än 100 Mbit/s per virtuell dator. Vi är tillbaka i de tidiga Fast Ethernet-dagarna. Tills virtualiseringen tog över fick våra nätverksintensiva applikationer ett gigabitrör; nu kommer vi att erbjuda dem 10 gånger mindre? Detta är inte acceptabelt.
Visst, få applikationer behöver faktiskt en full 1Gbit/s pipe. Databasservrar behöver betydligt mindre, bara några megabit per sekund. Även vid full belastning, servrarna i våra databastester går sällan över 10Mbit/s. Webbservrar nöjer sig vanligtvis med några tiotals Mbit/s, men AnandTechs egen webbserver har ofta flaskhalsar av sin 100Mbit-anslutning. Filservrar kan helt mätta Gbit-länkar. Vår egen filserver i Sizing Server Lab sänder rutinmässigt 120MB/s (en mättad 1Gbit/s länk). Ju snabbare filservern är, desto kortare är väntetiden för att distribuera bilder och installera ytterligare programvara. Så om vi vill konsolidera den här typen av arbetsbelastningar på de nyaste “über-maskinerna”, behöver vi något bättre än en eller två gigabit-anslutningar för 40 applikationer.
Optiskt 10Gbit Ethernet – 10GBase-SR/LR – såg dagens ljus 2002. I likhet med optisk fiberkanal i lagringsvärlden var det mycket dyr teknik. Något mer prisvärt, 10G på “Infiniband-ish” kopparkabel (10GBase-CX4) föddes 2004. 2006 höll 10Gbit Ethernet via UTP-kabel (10GBase-T) löftet att 10G Ethernet skulle bli tillgängligt på koppar UTP-kablar. Det löftet har fortfarande inte förverkligats under 2010; CX4 är den överlägset mest populära kopparbaserade 10G Ethernet. Anledningen är att 10GBase-T PHYs behöver för mycket ström. De tidiga 10GBase-T-lösningarna behövde upp till 15W per port! Jämför detta med 0,5W som en typisk gigabit-port behöver, så förstår du varför du hittar så få 10GBase-T-portar på servrar. Broadcom rapporterade ett genombrott bara för några veckor sedan: Broadcom hävdar att deras nyaste 40nm PHY använder mindre än 4W per port. Ändå kommer det att ta ett tag innan 10GBase-T erövrar världen, eftersom den här typen av toppmodern teknik behöver lite tid för att mogna.
Vi bestämde oss för att kolla in några av de mer mogna CX4-baserade lösningarna eftersom de är anständigt prissatta och kräver mindre kraft. Till exempel går ett CX4-kort med dubbla portar så lågt som 6W… det vill säga 6W för kontrollern, två portar och resten av kortet. Så ett komplett NIC med dubbla portar behöver betydligt mindre än en av de tidiga 10GBase-T-portarna. Men tillbaka till vår virtualiserade server: kan 10Gbit Ethernet erbjuda något som nuvarande populära quad-port gigabit NIC inte kan?
Anpassa nätverkslagren för virtualisering
När många virtuella datorer träffar samma nätverkskort kan en hel del prestandaproblem uppstå. För det första kan en nätverksintensiv virtuell dator helt fylla upp sändningsköerna och blockera åtkomsten till styrenheten under en tid. Detta kommer att öka nätverkslatensen som de andra virtuella datorerna ser. Hypervisorn måste emulera en nätverksväxel som sorterar och dirigerar de olika paketen för de olika aktiva virtuella datorerna. En sådan emulerad switch kostar en hel del processorprestanda, och denna emulering och andra nätverksberäkningar kan alla köras på en kärna. I så fall kan prestandan för denna ena kärna begränsa din nätverksbandbredd och öka nätverkslatensen. Det är inte allt, eftersom att flytta runt data utan att kunna använda DMA innebär att CPU:n måste hantera alla minnesflyttnings-/kopieringsåtgärder också. Kort sagt, ett nätverkskort med en sändnings-/mottagningskö och en mjukvaruemulerad switch är inte en idealisk kombination om du vill köra många nätverksintensiva virtuella datorer: det kommer att minska den effektiva bandbredden, höja nätverkskortets latens och öka CPU-belastningen avsevärt. .
Flera företag har löst denna I/O-flaskhals genom att använda sig av flera köer”. Intel kallar det VMDq; Neterion kallar det IOV. En enda NIC-kontroller är utrustad med olika köer. Varje mottagningskö kan tilldelas ett virtuellt NIC för din VM och mappas till gästminnet på din virtuella dator. Avbrott är belastningsbalanserade över flera kärnor, vilket undviker problemet med att en CPU är helt överväldigad av avbrotten från tiotals virtuella datorer.
Med VMDq blir nätverkskortet en Layer 2-switch med många olika Rx/Tx-köer. (Källa: Intel VMDQ-teknik)
När paket anländer till styrenheten, sorterar nätverkskortets lager 2-klassificerare/sorterare paketen och placerar dem (baserat på de virtuella MAC-adresserna) i kön som är tilldelad en viss virtuell dator. Layer 2 routing görs alltså i hårdvara och inte i mjukvara längre. Hypervisorn tittar i rätt kö och dirigerar sedan dessa paket till rätt virtuella datorer. Paket som måste gå ut från din fysiska server placeras i överföringsköerna för varje virtuell dator. I den ideala situationen har varje virtuell dator sin egen kö. Paket skickas till den fysiska tråden på ett round-robin-sätt.
Hypervisorn måste stödja detta och din NIC-leverantör måste naturligtvis ha en “SR-IOV”-kapabel drivrutin för hypervisorn. VMware ESX 3.5 och 4.0 har stöd för VMDq och liknande teknologier, kallar det “NetQueue”. Microsoft Windows 2008 R2 stöder även detta, under namnet “VMQ”.
