För några år sedan, när jag var på EMC World, fick jag chansen att träffa Chuck Hollis och flera andra VMware-anställda för att prata om en idé de hade. De ville utnyttja outnyttjade lokala lagringsresurser i en ESX-värd. Istället för att bara lagra ESX-startavbildningen ville de göra resursen användbar för virtuella maskiner i hela ESX-klustret. Vi pratade om vad som verkade vara ett klustrat filsystem som kunde skydda data över ESX-värdar. Jag påpekade att roterande diskar är långsamma och de pratade om att använda SSD-enheter för att accelerera I/O-operationer. Det var en intressant idé och jag var nyfiken på om något någonsin skulle komma ut av den. Som ni kanske gissat kom det faktiskt något ut av den: Virtuellt SAN. Med den första utgåvan av VSAN var jag intresserad men, erkänner jag, lite besviken. Här är vi, ett år efter allmän tillgänglighet, och VSAN har tagit ett språng framåt med den senaste uppdateringen av VSAN 6.0.
Naturligtvis är VSAN 6.0 bättre, snabbare och större. I linje med vSphere 6.0 kan VMDK:er få upp till 62TB och kan ha upp till 64 värdar i klustret. Antalet virtuella maskiner på en nod har fördubblats från 100 till 200, med maximalt 6,400 4 per kluster. Fler noder betyder mer kapacitet och mer prestanda. Genom att använda 9TB-enheter sätter gränsen runt XNUMX petabyte av råkapacitet.
VSAN 6.0 introducerar en ny lagringspolicybaserad hanteringsmodell, som tillåter policyer på en VM-nivå snarare än hela datalagret. Detta gör att varje virtuell dator kan ha sina egna inställningar för saker som tillgänglighet, prestanda och tunn provisionering. Dessa är dynamiska inställningar, så om en virtuell dator plötsligt behöver extra skydd kommer VSAN att anpassa sig. Jämfört med tidigare versioner är detta nya tillvägagångssätt mycket enklare och möjliggör mer granulär kontroll.
Historiskt har VSAN opererat i en hybridkonfiguration med traditionella magnetiska enheter som kapacitetslagring, med flash som läscache för att påskynda prestanda. För att uppnå högsta prestanda har en all-flash-konfiguration införts. För att hålla kostnaderna för detta alternativ nere kommer kapacitetens roll att spelas av en kostnadseffektiv MLC-enhet. VSAN kräver fortfarande en cachingnivå, men inte för prestanda. Istället är tanken att minimera skrivbelastningen på kapacitetsnivån och förlänga dess livslängd. Det är viktigt att överväga arbetsbördans skrivegenskaper.

I ett försök att förbättra användbarheten i bladservrar har VSAN 6.0 nu ett High Density Direct Attached Storage-alternativ. Jag ser inte detta som ett bra alternativ eftersom VMware fortfarande rekommenderar att alla servrar i ett VSAN-kluster har samma lagringskonfiguration. Att använda så många externa JBOD-kapslingar använder en betydande mängd bladchassifastigheter, så detta kan vara en mycket dyr lösning.

VSAN 6.0 är nu rackmedveten. Genom att skapa Fault Domains, som representerar minst tre rack, kommer VSAN att vara intelligent nog att distribuera data över dessa rack. Detta kommer att hjälpa till att skydda mot strömavbrott, problem med lagringskontroller och nätverksfel.
Vad är nästa rubrik Kan nästa version av VSAN användas tillsammans med en extern lagringsuppsättning? Faktum är att detta är något Chuck Hollis pratade om för mer än ett år sedan på sin blogg. Nu när vi har en utökad Fault Domain, blir nästa steg ett utsträckt VSAN-kluster? Jag kan se en framtid där VSAN utökas till vCloud Air som en förenkling av katastrofåterställning. Anmärkningsbarhet som saknas i VSAN 6.0 är alla typer av datareduktionsteknik och andra avancerade datatjänster. Med den senaste utvecklingen av VSAN 6.0 är det tydligt att VMware har investerat hårt i tekniken. Jag ser fram emot vad nästa release kan ge.
Om författaren
Mark May är lagringsingenjör i Cincinnati, Ohio. Han har arbetat med företagslagring och säkerhetskopiering i över 15 år. Han är en EMC Elect, Cisco Champion och ivrig tekniker. På sin fritid gillar han att hjälpa andra att förstå den ständigt föränderliga lagringsbranschens in- och utkanter. Han finns online på en mängd olika ställen, men de två mest troliga är hans personliga blogg och Twitter @cincystorage.




Amazon