In mijn vorige post besprak ik de redenen waarom thin provisioning in het algemeen de beste manier is om schijfruimte toe te wijzen in virtuele opslagscenario ‘ s. Waarom? Vanwege:
- flexibiliteit
- besparing
met thin provisioning kunt u meerdere VM ‘ s (virtuele machines) op een fysieke harde schijf maken zonder u zorgen te hoeven maken of u de ruimte hebt om deze te bedekken, omdat uw hypervisor alleen de hoeveelheid ruimte die de VM gebruikt verdeelt. Als gevolg hiervan kunt u meer opslagruimte kopen als u het nodig hebt, in plaats van het bedrag van tevoren te raden.
maar thin provisioning heeft zijn beperkingen. Hier zijn de drie meest voorkomende nadelen die ik tot nu toe ben tegengekomen:
1. Verminderde prestaties
ik heb verschillende berichten en discussies gelezen over het verschil in prestaties tussen dunne VM ’s en dikke VM’ s. De algemene consensus? Thin provisioning biedt niet hetzelfde prestatieniveau als thin provisioning. Een server Fault thread bespreekt het risico dat dunne provisioned schijven sterk gefragmenteerd raken, wat de algehele prestaties beïnvloedt.
zoals commentator wazoox uitlegt:
zijn prestatie is voornamelijk fragmentatie. Bij het initialiseren van een aandrijving, zijn alle blokken aaneengesloten … terwijl ze sterk gefragmenteerd kunnen worden als ze dun zijn. “Het monitoren van de grootte en de uitbreiding ervan “gebeurt gewoon niet; sparse bestanden zijn eigenlijk een” gratis ” bestandssysteem functie en ze gewoon automatisch groeien wanneer blokken worden toegewezen aan hen.
maar op een recente Spiceworks-thread zegt Scott Alan Miller van MSP Niagara Technology Group dat het verschil in de meeste gevallen nominaal is en dat zorgen erover contraproductief is voor de meeste KMO ‘ s:
tenzij u een latency gevoelige, Io gebonden toepassing , dik is zelden een goede keuze. Het brengt gewoon te veel problemen of gebrek aan voordelen…het probleem is…het MKB heeft een mindset, veel van de tijd, van “prestaties over alles” terwijl, in werkelijkheid, prestaties is ongeveer het laatste wat het MKB nodig heeft. Wat ze nodig hebben is betrouwbaarheid, gemak van beheer, kostenbeheer, enz.
2. Over-allocatie van ruimte
omwille van de eenvoud, laten we zeggen dat je 1TB fysieke opslag hebt. U kunt 10 (of 100) VM ‘ s met dunne voorzieningen van 200 GB per stuk maken, hoewel uw fysieke opslag ze niet allemaal aankan als een meerderheid van hen hun capaciteit benadert, omdat op dit moment elke VM maximaal 50 GB per stuk gebruikt.
maar wat gebeurt er als u al die verschillende VM ‘ s niet controleert? Zoals wazoox zegt,
als je ooit geen echte schijfruimte meer hebt op dunne opslagruimte waar je te veel ruimte hebt toegewezen, kan elk schrijven een catastrofale storing veroorzaken op een of meerdere VM-schijven, meestal voorbij elke reparatie, dus je kunt beter je werkelijke schijfgebruik op de opslaghost zorgvuldig controleren.
dat is een legitieme zorg, maar IT-professionals zouden dat schijfgebruik moeten monitoren als een beste praktijk in het datacenter. In de eerder geciteerde Spiceworks thread legt commentator Darth Hoody het beter uit dan ik kan:
de enige reden om de voorziening niet te dun te maken is als u niet wilt, weet hoe, of op een andere manier uw opslag niet kunt of wil controleren en beheren. Ja, als kan zeker problemen veroorzaken als je overaanbod tot het punt waar u uw datastores uit de ruimte en knock-out al uw VM ‘ s. Er kunnen legitieme redenen voor zijn, maar voor mij is het verspillend en gewoon slechte praktijk.
3. Gebrek aan elasticiteit
hoewel met thin provisioning de schijfruimte naar behoefte kan worden uitgebreid, is de technologie niet elastisch. Met andere woorden, u kunt uw ruimte toewijzing uit te breiden, maar je kunt niet contracteren. SearchVirtualStorage, een TechTarget publicatie, bespreekt dit probleem in zijn post VMware thin provisioning: voors en tegens:
Thin provisioning creëert schijven die groeien maar niet echt krimpen; ze geven geen ruimte terug naar de totale vrije pool. In het geval van VMware, als je een dun-provisioned disk maakt, zal het groeien; als u gegevens van die schijf verwijdert, zal de VMDK krimpen, zodat er meer ruimte beschikbaar zal zijn in die gegevensopslag, maar de gegevensopslag krimpt niet en dus zal het niet beschikbaar zijn voor de array — controller voor andere doeleinden — tenzij de array-controller nulherkenning doet, wat veel array-controllers doen die thin provisioning doen-en u maakt ofwel een op nul geplaatste Dikke of een op eager-op nul geplaatste dikke schijf. Deze typen schijven zullen schijfruimte toewijzen en deze vullen met nullen.
toen Steve Snyder en ik een paar weken geleden praatten, kwamen we overeen dat een van de vele hypervisor platforms die er zijn uiteindelijk met echt elastische provisioning naar buiten zal komen. Maar geen van ons is erin geslaagd om enig concreet nieuws over deze ontwikkeling te vinden.