Uppdatering av testbädden – arbetsstationsinfrastruktur
Bakgrund:
I början av september publicerade vi ett stycke som beskriver vår SMB / SOHO NAS (Small & Medium Business / Small Office Home Office Network Attached Storage) testbädd. Därefter fick vi omfattande feedback från läsare angående testbädden samt den föreslagna testmetoden. Den universella konsensus var att VM-tätheten (virtuell maskin) kunde ökas (med tanke på de dubbla Xeon-processorerna och den minimala belastningen på CPU från arbetsbelastningen). Läsare pekade också hjälpsamt på spår som potentiellt skulle kunna replikera NAS-användning i typiska hemscenarier.
Vi bestämde oss för att implementera förslagen inom ramen för den befintliga arbetsstationen. Som en påminnelse är vår NAS-testbädd baserad på Asus Z9PED8-WS moderkort med dubbla Xeon E5-2630-processorer. CPU:erna har 6 kärnor vardera och moderkortet har 14 SATA-portar. Två av SATA-portarna är anslutna till 128 GB SSD:er som innehåller värdoperativsystemet (Windows Server 2008 R2 Enterprise) och Hyper-V ögonblicksbild / diverse data för de virtuella datorerna. De övriga 12 SATA-portarna är anslutna till 12 x 64 GB OCZ Vertex 4 SSD:er. Moderkortet har 7 PCIe x16-platser, av vilka tre var upptagna av 3 x Intel ESA I-340 T4 fyrports GbE NIC. På den här arbetsstationen kunde vi köra 12 Windows 7 virtuella datorer, där varje virtuell dator fick en dedikerad fysisk disk och en dedikerad fysisk GbE-port.
Vi hade noggrant planerat den infrastruktur som krävs för testbädden för att säkerställa att systemet inte skulle drabbas av flaskhalsar när det genererade trafik för NAS:en som testades. Vi hade dock inte uttryckligen planerat att öka VM-densiteten från 1 VM per CPU-kärna / 1 fysisk disk per VM / 1 fysisk GbE-port per VM. Efter att ha gjort en profilering av Iometer-arbetsbelastningen upptäckte vi att det inte skulle finnas några problem med att öka VM-densiteten.
Balansera nätverkskraven:
Med tanke på syftet med testbädden var det omöjligt att ge upp kravet att en fysisk GbE-port skulle vara bunden till varje virtuell dator. Om VM-densiteten skulle öka skulle det bli absolut nödvändigt att lägga till fler GbE-portar till testbädden. Lyckligtvis hade Intel försett oss med tolv ESA I-340 T4-enheter i själva inledningsskedet.
Efter att ha avslutat vår första konstruktion hade vi 4 PCIe x16-platser kvar ofyllda. En av PCIe-platserna måste användas för lagringsexpansion (mer om detta i nästa underavsnitt), vilket lämnade oss med tre platser som skulle fyllas med ESA I-340-enheterna. Detta ökade antalet fysiska GbE-portar i maskinen från 14 (3 x ESA I-340 + 2 x Native Z9PED8-WS) till 26 (6 x ESA I-340 + 2 x Native Z9PED8-WS). En av de inbyggda GbE-portarna användes av värdoperativsystemet och den andra lämnades oansluten i vår ursprungliga version. I uppdateringsprocessen bestämde vi oss för att dra fördel av den extra inbyggda GbE-porten och använda den för en av de nya virtuella datorerna. Med den nya konfigurationen kunde vi alltså gå upp till 25 virtuella datorer.
Lagringsutmaningen:
Vår främsta utmaning låg i det faktum att vi inte längre hade råd att dedikera en fysisk disk till varje virtuell dator. För att förvärra saken ytterligare var alla SATA-portar upptagna. Så här i efterhand var det inte ett särskilt bra beslut att ansluta en 64 GB SSD helt till varje virtuell dator. Även om det var möjligt att lagra två VHD-filer som motsvarar startdiskarna för två virtuella datorer i var och en av SSD:erna, valde vi inte att gå den vägen av två skäl. Det upptagna diskutrymmet för varje virtuell dator var ganska nära hälften av SSD-kapaciteten när operativsystemet och de tillhörande benchmarkingprogrammen lades ihop. Vi ville inte heller gå igenom hela processen med att installera de befintliga virtuella datorerna igen. Det hade varit trevligt att ha 128 GB eller 256 GB SSD-enheter anslutna till varje SATA-port och inte gått med den dedikerade fysiska disken i första hand. För uppdateringen behövde vi mer lagring, men det fanns inga tillgängliga SATA-portar. Lösningen var att använda någon sorts PCIe-baserad HBA/lagringsenhet.
För att uppnå snabb vändning bestämde vi oss för att avbilda en av de tolv 64 GB SSD:erna till en VHD-fil och använda kopior av den för den nya virtuella datorn. Detta innebar att varje VHD-fil var nära 64 GB i storlek. Medan expansionen av nätverkskapaciteten gjorde att testbädden kunde vara värd för upp till 25 virtuella datorer, var vi tvungna att lägga till minst 13 x 64 GB (832 GB) över PCIe-kortplatsen för att göra det möjligt. En lösning skulle ha varit att lägga till en SATA – PCIe-bryggadapter och lägga till en SATA-enhet till systemet. Men alla tillgängliga SATA-platser i chassit hade redan tagits upp. All lagring måste begränsas till utrymmet över PCIe-kortplatsen. Vi kunde ha gått in för en PCIe SSD med hög kapacitet, men kostnadsöverväganden gjorde att vi var tvungna att släppa idén. En lösning presenterades i form av OCZ RevoDrive Hybrid.
OCZ RevoDrive Hybrid består av en 1 TB 2,5″ hårddisk och 100 GB NAND i ett tvålagers PCIe 2.0 x4-kort. drivrutin och DataPlex-programvara som ser till att hårddisken och NAND-flashen presenterar sig för operativsystemet som en enda enhet. I vårt avsedda användningsscenario var enheten avsedd att fungera som en sekundär lagringsenhet i värdoperativsystemet. All dokumentation från OCZ såväl som olika recensioner undvek helt att nämna användningen av enheten som en sekundär lagringsenhet, och faktiskt avrådde aktivt från användningen på det sättet.
Vi tog några risker och installerade RevoDrive Hybrid i den enda återstående PCIe-platsen. En drivrutin var endast tillgänglig för Windows 7, men den installerades utan problem på Windows Server 2008 R2. Under Diskhantering dök enheten upp som två enheter, en 93 GB SSD och en 931 GB hårddisk. Vi gjorde 13 VHD-kopior av en av de 64 GB fysiska hårddiskarna på hårddisken och satte upp 13 nya virtuella datorer med konfigurationer som liknar de befintliga virtuella datorerna. En fysisk GbE-port dedikerades till varje virtuell dator och en annan nätverksport skapades för att ansluta till arbetsstationens interna nätverk (med värdoperativsystemet som DHCP-server). Den enda skillnaden jämfört med de befintliga virtuella datorerna var att en VHD-fil måste kopplas till den interna disken på den virtuella datorn istället för en fysisk disk på 64 GB.
Prestandaöverväganden:
Uppdateringen av arbetsstationens interna delar gick utan problem och vi kunde få igång 25 virtuella datorer utan några större problem. Uppenbarligen tog uppstart och avstängning av VMs 13 till 25 (VHD-filer på PCIe HDD) samtidigt mer tid än vi skulle ha velat. Men när de virtuella datorerna väl hade startat upp var åtkomst via SSH och körande program som inte stressade diskundersystemet i den virtuella datorn smidigt. Vårt benchmarking-skript (att köra Dynamo-trafikgeneratorn på varje virtuell dator med IOMeter-instansen i värdoperativsystemet) var också trivialt att uppdatera och exekveras utan några hicka.
Framöver kommer vi att betona NAS-system genom att komma åt det samtidigt från upp till 25 virtuella datorer, vilket är representativt för en medelstor SMB-installation. För alla riktmärken som kan stressa det interna diskundersystemet, kommer vi att fortsätta med de 12 virtuella datorerna på de dedikerade SSD:erna.
