Erfarenheter från att virtualisera stora miljöer i Hyper-V. (MS SQL, Exchange och Sharepoint)

Tyvärr inget som jag har speciellt mycket erfarenhet från att göra (har bara fuskat lite i labbmiljöer), men det finns andra som kan sånt..
Jag satt och surfade runt lite då jag hittade tre tester av att lägga Microsoft Exchange 2010, Microsoft SQL server 2008 R2 och Microsoft Sharepoint 2010 på en enda fysisk host som i sin tur kör Microsoft Hyper-V R2 SP1.

Själva grunduppsättningen är likadan i alla testerna.
Det är en singel-server (en HP BL680c med 4st CPUer (totalt 24 kärnor), 128GB RAM) som kör Microsoft Hyper-V R2 SP1 på Windows Server 2008 R2 SP1.
Från denna server finns dubbla 4Gbit anslutningar till lagringen. Denna i sin tur består av ett EMC CX4-960 med 155st 15k rpm FC diskar. Jupp det är en hyffsad lagringslösning för en fysisk server, men varför inte. :)
Kontentan är att testerna som utförs inte påverkas av lagringslösningen. Det finns prestanda så det räcker i EMC-skåpet, och det är precis det som är meningen. Målet med testerna är att se hur mycket det går att pressa ut från en och samma server.
Det skall även säga att alla VHD-filer körs med "fixed" storlek för att inte tappa prestanda där heller.

Nåja. Om vi kikar på testerna då:

Exchange 2010 på Hyper-V R2 SP1
Hela testen hittar man här:
http://www.enterprisestrategygroup.com/2011/06/microsoft-exchange-2010-and-hyper-v-r2-sp1-performance-analysis/

Här har man kört med fyra stycken virtuella maskiner och låtit varje virtuell server ha hand om upp till 5 000st Exchange 2010 mailboxar.
Det skall även noteras att maildatabaserna synkades mellan Exchange servarna precis som man skulle ha gjorts i en verklig situation för att få redundansen (en så kallad DAG).
För att emulera användare har man använt JetStress och låtit den emulera användare med 250MB mailboxar och en IO rate på 0,15 IOPS per mailbox... Om man översätter detta till vanlig svenska så motsvaras det alltså av användare som tar emot och skickar totalt ca 150mail per dygn. (Se även denna technet artikel för mer info om IOPS i Exchange 2010).

Kontentan av testet är att med 5 000 mailboxar per server och 4 servrar, alltså totalt 20 000 mailboxar på samma hårdvara) var responstiden 5,28 ms.
Det är ruskigt bra med tanke på att Microsoft rekommenderar att man bör hålla sig under 20 ms.
De fyra virtuella maskinerna var inte speciellt stora heller. 4 vCPU och 4GB vRAM per maskin är inte speciellt mycket... Min gissning är att databas-disken (en RAID-10 på 88st diskar) och log-disken (en RAID-10 på 16st diskar) är en stor del i varför man fick in så pass många användare.

I slutet av testen finns det en mängd länkar till andra artiklar kring virtualisering av Exchange 2010



SQL 2008 R2 på Hyper-V R2 SP1
Precis som tidigare kan man hitta hela testen här http://www.enterprisestrategygroup.com/2011/06/microsoft-sql-server-2008-r2-and-hyper-v-r2-sp1-performance-analysis/
(observera att det är en annan URL än i förra testen).

I denna test har man använt 4st virtuella maskiner med vardera 4vCPUer och 16GB vRAM.
Det är alltid svårt att testa prestanda i MS SQL. Det är så enormt olika beroende på hur applikationen som använder databasen jobbar och ställer frågor/uppdateringar till databasen.

Att man här kom fram till 20 000 samtidiga användare per virtuell maskin, vilket då totalt blir 80 000 användare på en och samma fysiska server (när 4st virtuella maskiner användes) är egentligen tämligen intetsägande.
Det som är riktigt intressant är att man gjorde samma test igen och jämförde en virtuell maskin med 4 vCPUer och 16GB vRAM mot en fysisk server med 4 CPUer och 16GB RAM.
Här uppmätte man en skillnad på ca 12% mellan fysisk och virtuell server, vilket faktiskt är rätt OK (även om VMware har rapporterat om nedåt 5-7% på nya vSphere 5, se bland annat här och här, medans andra som gjort tester också har fått 12%).
Vad jag försöker säga med all denna texten är att Virtulisering av MS SQL absolut går att göra och att precis samma "tänk" som när man skapar en fysisk SQL-server skall användas när man skapar en virtuell. Det blir en viss prestanda påverkan från hypervisorn, men med tanke på hur snabba processorer och liknande är idag så bör detta oftast inte vara ett problem. Speciellt inte med tanke på alla andra fördelar man får genom att virtualisera...

Kika gärna igenom alla länkarna i slutet av artikeln från ESG (Enterprise Strategy Group). Det finns MASSOR med nyttigt kring virtualisering av MS SQL.


Sist men inte minst har man testat att virtualisera
Sharepoint 2010 på Hyper-V R2 SP1
Hela artikeln hittar man här: http://www.enterprisestrategygroup.com/2011/06/microsoft-sharepoint-2010-and-hyper-v-r2-sp1-performance-analysis/

De virtuella maskinerna har antingen 4vCPUer och 32GB minne, eller 2 vCPUer ch 4GB minne.
MS SQL hade 4 vCPU och 32GB vRAM.
IIS-servern och Sharepoint servern hade 2vCPUer och 4GB vRAM vardera.

Totalt användes 1st virtuell server med MS SQL, 1st virtuell server med Sharepoint på och 1-3st virtuella servrar med IIS som agerade web-frontar.
De användare som simulerades var rätt lugna (89% browse, 10% ladda upp och 1% check-in/check-out). Som lastbalancerare användes även en F5 Networks BIT-IP local Traffic Manager.

Nåja, det intressanta tycker jag var att det som slog i taket var CPUn på web-fronten när man körde med bara en enda web-front.
Genom att lägga till ytterligare två stycken webb-frontar blev det istället CPUn på SQL som fick börja jobba.
Med 3st web-frontar var det totalt 460 800 samtidiga användare (alltså fyra hundra sextio TUSEN!!!) Det är ruskigt mycket.  :)

Återigen är det en helt otrolig massa hårddiskar som används för en och samma lösning, men kontentan av testen är rätt enkel. JA det är fullt möjligt att virtualisera Sharepoint, till och med rätt intelligent att göra.

Även denna artikel har ett antal bra länkar till ytterligare läsning i ämnet virtualisering av Sharepoint.


Så vad är det jag försöker komma fram till med denna bloggpost?
Precis det jag har sagt massor med gånger:
- Det är ytterst få saker som inte går att virtualisera. Ibland behöver man tänka till lite extra, men oftast är det bara att köra. :)
Skall man dock köra en enorm lösning med massor av användare så går det också, ofta är det till och med så att man får en sån mängd fördelar med att virtualisera att det uppväger de (ofta rätt låga) prestanda förlusterna man får av hypervisorn...