Notează administratorului virtual dacă are sens să defragmentăm discul în sistemul de operare gazdă

Subiectul defragmentării sistemului de fișiere apare periodic pe forum, apoi doar prin poștă.

Deci este necesară defragmentarea în lumea virtuală, care este cunoscută pentru a ajuta foarte mult în lumea fizică?







De ce din ce este fragmentarea în general și care este impactul acesteia asupra performanței. Deci, fragmentarea este o situație în care blocurile unui fișier mare sunt împrăștiate pe un disc fizic într-o ordine aleatorie. Efectul fragmentării este clar vizibil pe o mașină obișnuită de acasă cu o unitate de hard disk și o mulțime de fișiere mari (filme, fotografii etc.). În acest caz, pentru a citi un fișier (de exemplu, când se copiază), capul discului nu poate efectua citirea secvențială liniară la viteza maximă, dar este forțat să arunce între blocuri. Desigur, tot timpul când capul se deplasează la cilindrul drept și așteaptă începutul blocului cu datele, nu există citire. Rezultatul este o scădere a vitezei de citire. Uneori, o reducere drastică dacă fișierul este împărțit în mai multe blocuri mici.
Tratamentul - prin citire / scriere secvențială, mutați blocurile de fișiere în jurul discului astfel încât să maximizeze succesiunea acestora și în mod corespunzător. reduce mișcarea capului la minim.

Pur și simplu, evident, duce la un avantaj ușor de măsurat. Dar este în lumea virtuală?

Și aici este înmormântat monstru.

Să ne imaginăm o infrastructură de dimensiuni medii cu câteva sute de mașini virtuale. Există o matrice productivă cu multe discuri în RAID, mașinile generează încărcături, viața se mișcă.
Fragmentarea sistemelor de fișiere din VM afectează performanța globală? Paradox, dar practic nici unul.

1) Din moment ce avem o serie de o multitudine de discuri pe care datele sunt răspândite mișcări uniform, este mult redusă cap de impact - sunt în mod substanțial paralel la citirea din mai multe discuri, și practic imprevizibil.
2) Cu cât este mai inteligentă matricea discurilor, cu atât mai puțin influența celei mai lente părți a discurilor - discuri. Mai mult RAM cache, cache-ul de-al doilea nivel de pe unitatea flash, unitățile de stocare mai multe niveluri reduce impactul în măsura în care pentru a încetini unitățile de disc fizice ajunge, uneori, doar 10% din operațiuni de citire. procesoare puternice, algoritmi de optimizare și o memorie cache mare oglindă cu baterie permite nu se grăbește să scrie în fluxul de comandă disc așa cum vine, și fă-o cel mai bun mod, în funcție de nivelul și alți parametri ai RAID, în numărul minim de operații.






3) Încărcarea simultană de la zeci sau chiar sute de mașini virtuale duce la faptul că numai în interiorul operațiunilor discului VM arata ca lectură liniară. Înainte ca citirea / scrierea matricei de disc să apară ca o secvență practică aleatorie de comenzi. Din faptul că fișierul din interiorul unui VM este inconsistent, aproape nimic nu se schimbă.

Total: dacă VM-urile sunt situate pe o matrice la nivel de intrare la scară redusă (sau pur și simplu pe un server RAID intern) pe un număr mic de date fizice. drive-uri (spindle), și sunt puține, apoi defragmentarea poate avea sens și poate reduce încărcarea sistemului de disc / îmbunătăți performanța generală.
Cu toate acestea, odată cu creșterea dimensiunii infrastructurii și a creșterii clasei sistemului de discuri, fragmentarea încetează să mai joace un rol semnificativ. Dar defragmentarea nu este o mântuire, ci un adevărat rău. Amintiți-vă că procesul de defragmentare reprezintă un set de operațiuni de citire / scriere (1 la 1) într-un volum care atinge până la 100% din datele de pe disc.

Se pare, cât de bine a început totul.

Nu toți iaganții sunt la fel de folositori.

Doar cu o zi înainte de ieri am ajuns într-o astfel de trivialitate. Server de fișiere VM pentru câteva sute de gigabytes. Ezhedovy backup Net Veritas. De asemenea, entuziaștii au pus și o defragmentare anuală, cu o schimbare de timp din backup. Nu este clar de ce o copie de siguranță întârziată, a coincis cu defragmentarea - și hi - instantanee a crescut aproape la dimensiunea unui disc de bază, loc pe storadzhe peste, masina nu va porni.
Ei bine, am reușit să eliberăm spațiul pentru SVmotion de la câteva alte VM-uri mici, cu o mulțime de bani. Apoi, va trebui să dezactivez serverul de fișiere în orele de lucru, câte clonare, respectiv perioada de întrerupere a celui mai important server corporativ, pentru care toată lumea ar fi păcălit.
Cel mai amuzant lucru este că au părăsit defragmentarea, trecând-o în timp. Voi arăta autorităților acest post, ar putea ajunge la simțurile lor.

Există îndoieli cu privire la pedeapsa RAID
Pe raționamentul de mai sus, raid1 este mai lent decât raid0 pentru scrierea de 2 ori, raid5 este 4, etc.
Ce arată măsurătorile reale?

Deci totul este acolo :-)

În plus, ați uitat să adăugați „la același număr de discuri“, pentru că dacă RAID0 pe N discuri, este de N ori mai rapid oglinda raid 1 dintr-o pereche de discuri.

Corect despre CBT. ctk-file nu ar trebui să crească - este creat de dimensiune, în funcție de dimensiunea vmdk corespunzătoare.

Dar, din cauza defragmentării, va exista un număr tot mai mare de blocuri modificate în acest tabel. Și va fi o copie de siguranță a informațiilor în sesiunea următoare și va afla că este necesar să copiați întreaga mașină de la zero:
1. Timpul de backup a crescut (și cu replicarea WAN acest lucru poate fi critic la toate)
2. Dimensiunea incrementului devine egală cu copia completă.
3. Plus întârzierea de a reconstrui o copie completă din astfel de creșteri sau când se recuperează.

Apropo pentru o lungă perioadă de timp a vrut să specificați - cbt înregistrări modificări de la ultima instantaneu, așa?

și anume dacă după instantaneu instantaneu a mai fost creat un altul - circuitul este rupt?







Trimiteți-le prietenilor: