Comparație VMDK Thick Provision Lazy-Zeroed și Eager-Zeroed, Thin Provision WindowsPro
Dacă creați un nou hard disk virtual sub VMware ESXi, puteți alege între trei variante diferite. Ceea ce la prima vedere pare o decizie între aprovizionarea subțire și groasă devine mult mai complicat atunci când intră în joc stocarea partajată.
Preocuparea fundamentală atunci când furnizează spațiu de stocare în medii virtuale este că aplicațiile ar trebui să consume doar atâtea resurse de stocare cât au nevoie de fapt. Pot apărea discrepanțe, de exemplu, atunci când software-ul așteaptă un anumit spațiu pe disc atunci când este instalat, dar apoi trece cu mai puțin în timpul funcționării.
Aprovizionare subțire prin hipervizor
Răspunsul evident la această problemă pare să fie VMDK-uri cu dispoziții subțiri. Nu își rezervă niciun spațiu de stocare atunci când sunt create, ci cresc cu cantitatea de date pe care sistemul de operare invitat le stochează în ele. De fapt, acestea sunt o opțiune interesantă pentru sistemele de stocare care nu oferă aprovizionare subțire, cum ar fi discurile locale către cele locale.
Dezavantajul acestui tip de VMDK este că trebuie să monitorizați constant capacitățile de stocare, astfel încât rezervarea excesivă a resurselor să nu conducă la dischete complete și la blocajele rezultate. În plus, performanța acestor VMDK-uri este puțin mai slabă decât cea a variantelor groase.
Alocarea slabă a memoriei prin backend de stocare
Dacă utilizați tablouri de stocare, veți utiliza opțiunea de alocare a stocării slabe la nivelul LUN. Aprovizionarea subțire nu afectează atunci numai VMDK-urile individuale, ci și întregul depozit de date ESXi. Din punct de vedere pur tehnic, VMDK-uri de tipul Thin Provision pot fi create și acolo, dar nu are prea mult sens să accepți de două ori efortul de gestionare fără avantaje evidente.
Dacă transferați aprovizionarea subțire către backend-ul de stocare, de obicei se utilizează VMDK-uri de tipul cu furnizare groasă lazy-zeroed. Deși rezervă tot spațiul de stocare pe volumele VMFS, se comportă într-un mod similar cu VMDK-urile subțiri pe matricile de stocare cu alocare de stocare slabă, deoarece folosesc blocuri acolo doar când sistemul invitat stochează date.
Provizioane groase dornice de zero pentru cele mai bune performanțe
Pe de altă parte, unitățile virtuale de tipul „provizionare groasă”, în sine, nu sunt potrivite pentru aprovizionarea subțire, deoarece nu numai că rezervă spațiul pe disc destinat lor atunci când sunt create, dar suprascriu toate blocurile cu zerouri. Dacă acest proces poate fi externalizat în matrice printr-o comandă VAAI, atunci provizionarea ar trebui să dureze mai mult decât cu lenește la zero. Dar acest VMDK oferă cea mai bună performanță după aceea.
Relații clare pe sisteme de stocare simple
Pe sistemele de stocare care nu pot găzdui singuri discuri subțiri, opțiunile VMDK sunt relativ clare. Aprovizionarea subțire se poate face numai prin intermediul hipervizorului și cu aprovizionarea groasă este important să se ia în considerare dacă un timp de aprovizionare mai scurt (leneș-zero) este preferat unei performanțe ușor mai bune (nerăbdător).
Problemă de recuperare a spațiului mort
Pe tablourile de stocare care sunt capabile de aprovizionare subțire a magazinelor de date, producătorii sistemelor de stocare recomandă de obicei utilizarea VMDK-urilor groase de tip leneș-zero.
Cu toate acestea, o problemă cu această constelație a fost așa-numita Recuperare a spațiului mort până la vSphere 5, deoarece sistemul de stocare nu a fost informat dacă, de exemplu, un VMDK a fost migrat către un alt sistem folosind Storage vMotion și, prin urmare, nu mai era necesar. Prin urmare, nu a putut elibera spațiul ocupat de VMDK.