i mitt tidigare inlägg diskuterade jag skäl till varför tunn provisioning i allmänhet är det bästa sättet att allokera diskutrymme i virtuella lagringsscenarier. Varför? På grund av:
- flexibilitet
- besparingar
med tunn provisioning kan du skapa flera virtuella datorer (virtuella maskiner) på en fysisk hårddisk utan att oroa dig för om du har utrymme att täcka det eftersom din hypervisor bara fördelar mängden utrymme som VM använder. Som ett resultat kan du köpa mer lagringsutrymme när du behöver det, snarare än att behöva gissa beloppet i förväg.
men tunn provisioning har sina begränsningar. Här är de tre vanligaste nackdelarna jag har stött på hittills:
1. Minskad prestanda
jag har läst flera inlägg och trådar som diskuterar skillnaden i prestanda mellan tunna provisionerade VM och tjocka provisionerade. Den allmänna konsensus? Tunn provisionering erbjuder inte samma prestanda som tjock provisionering. En serverfelgänga diskuterar risken för att tunna diskar blir kraftigt fragmenterade, vilket påverkar övergripande prestanda.
som kommentator wazoox förklarar:
han prestanda hit är mestadels fragmentering. När man initierar en enhet är alla dess block sammanhängande … medan de kan bli kraftigt fragmenterade när de är tunna. ”Övervakning av storleken och förlängning av den” sker helt enkelt inte; glesa filer är faktiskt en ”fri” filsystemfunktion och de växer helt enkelt automatiskt när Block tilldelas dem.
men på en ny Spiceworks-tråd säger Scott Alan Miller från MSP Niagara Technology Group att skillnaden i de flesta fall är nominell och att oroa sig för det är kontraproduktivt för de flesta små och medelstora företag:
om du inte har en latenskänslig, Io-bunden applikation är tjock sällan ett bra val. Det ger bara för många problem eller brist på fördelar…problemet är…små och medelstora företag har en tankegång, mycket av tiden, av ”prestanda över allt” när, i verkligheten, prestanda handlar om det sista som små och medelstora företag behöver. Vad de behöver är tillförlitlighet, enkel hantering, kostnadshantering etc.
2. Överallokering av utrymme
för enkelhetens skull, låt oss säga att du har 1 TB fysisk lagring. Du kan skapa 10 (eller 100) tunna virtuella datorer på 200 GB vardera, även om din fysiska Lagring inte kunde hantera dem alla om en majoritet av dem närmade sig sin kapacitet, för för närvarande använder varje VM högst 50 GB styck.
men vad händer om du misslyckas med att övervaka alla de olika VM? Som wazoox säger,
om du någonsin har slut på riktigt diskutrymme på tunt reserverat lagringsutrymme där du över allokerat utrymme, kan varje skrivning medföra ett katastrofalt fel på en eller flera VM-enheter, vanligtvis bortom någon reparation, så du bör övervaka din faktiska diskanvändning på lagringsvärden noggrant.
det är ett legitimt problem, men IT-proffs bör övervaka den diskanvändningen som en bästa praxis i datacentret. I den tidigare citerade Spiceworks-tråden förklarar kommentaren Darth Hoody det bättre än jag kan:
den enda anledningen till att inte tunna bestämmelse är om du inte vill, vet hur, eller på annat sätt inte kan eller inte kommer att övervaka och hantera din lagring. Ja, om kan definitivt orsaka problem om du overprovision till den punkt där du kör dina datalager ur rymden och slå ut alla dina VM. Det kan finnas legitima skäl till det, men för mig är det slöseri och bara dålig övning.
3. Brist på elasticitet
även om tunn provisioning låter dig utöka ditt diskutrymme när du behöver det, är tekniken inte elastisk. Med andra ord kan du utöka din rymdallokering, men du kan inte kontraktera den. SearchVirtualStorage, en TechTarget-publikation, diskuterar detta problem i sin post VMware thin provisioning: fördelar och nackdelar:
tunn provisionering skapar diskar som växer men inte riktigt krymper; de returnerar inte utrymme tillbaka till den totala fria poolen. I VMware-fallet, om du skapar en tunn tillhandahållen disk, kommer den att växa; om du tar bort data från den disken kommer VMDK att krympa så det kommer att finnas mer utrymme tillgängligt i den datalagret, men datalagret krymper inte och det kommer inte att vara tillgängligt för array controller för andra ändamål — om inte array controller gör noll erkännande, vilket många array controllers som gör tunn provisioning gör — och du skapar antingen en nollad tjock eller en ivrig nollad tjock disk. Dessa typer av skivor kommer att fördela diskutrymme och fylla den med nollor.
när Steve Snyder och jag pratade för några veckor sedan kom vi överens om att en av de många hypervisorplattformarna där ute så småningom kommer ut med riktigt elastisk provisioning. Men ingen av oss har lyckats hitta några konkreta nyheter om denna utveckling.