Virtualizare - adâncimea cozii (adâncimea coadă) și un algoritm adaptiv pentru managementul coadă în vmware

Ca administratori cunosc sisteme de stocare de date, diferite componente SAN-rețea au un parametru numit adâncime coadă (Queue Adâncime). El este serverul HBA-adaptor (care, de exemplu, care rulează VMware ESX / ESXi) și portul de stocare Storage Processor'a (SP). Adâncimea cozii definește cât de multe IOPS (IO) pot fi prelucrate simultan pe dispozitiv.

Virtualizare - adâncimea cozii (adâncimea coadă) și un algoritm adaptiv pentru managementul coadă în vmware

Așa cum am menționat deja. în cazul în care, înainte de SP de ESX server / ESXi utilizează o cale activă unică, adâncimea de matrice coadă portul țintă (T) trebuie să satisfacă următoarea relație:

în care Q - este o adâncime coadă HBA-adaptor și L - numerele LUN deservite de sistemul de stocare SP. Dacă avem mai multe căi active la aceeași parte SP dreaptă trebuie să fie, de asemenea, înmulțit cu P - numărul de moduri.

Prin urmare, în infrastructura virtuală VMware vSphere avem mai multe gazde au acces la același LUN prin SP și relația următoare:

T> = ESX1 (Q * L * P) + ESX2 (Q * L * P) +, etc.

Adâncimea Coadă pe servere

Această opțiune este, de asemenea, implicit este de 32. El este la nivel global determină cât de multe IOPS (iOS) poate emite un maximum de o mașină virtuală pentru fiecare LUN simultan. În același timp, se stabilește valoarea maximă în IOs pentru toate mașinile virtuale de pe LUN. Aceasta este, în cazul în care este setat la 32, toate mașinile pot stoarce simultan 32 IOs, acesta este confirmat într-un articol Jason Boche. în cazul în care 3 mașini generează 32 IO simultan la un singur LUN și LUN sunt într-adevăr toate același 32 în loc de 3 * 32:

Aici se vede că activitatea se desfășoară 30 de echipe (maximum 32) pentru stabilirea DQLEN, în timp ce restul de 67 sunt încă în coada de așteptare. Aceasta este, parametrul definește bara maximă în IO pentru o mașină la LUN, sau pentru toate mașinile de pe LUN.

Este important ca Depth parametrii Coadă și DSNRO au fost stabilite în aceeași valoare. Această recomandare VMware. Deci, dacă luați în cap pentru a schimba unul dintre ei - nu uita de-al doilea. Și amintiți-vă că opțiunea DSNRO pentru gazdă - o globală și, prin urmare, se aplică tuturor LUN, conectat la gazdă.

Target Port Coadă Adâncime pe tablouri

Pentru matrice de disc (sau, mai degrabă, SP) din toate - asta în cazul în care el sladyvaet SCSI-comandă la momentul respectiv, în timp ce prelucrate și executate pachetul anterior. Normal gama medie-matrice are o adâncime coadă de 2048 sau mai mult. În cazul în care matrice primește o coadă de IO comenzi mai multă valoare țintă Port Coadă Adâncime, instruiește în urmă QFULL. ceea ce înseamnă că coada este completă și serverul gazdă trebuie să facă acest lucru. VMware ESX / ESXi reactioneaza la acest lucru, după cum urmează: - reduce rândul său, pe verifică dacă QFULL dispărut și în cazul în care au dispărut, apoi crește treptat adâncimea cozii pentru acest LUN (poate dura până la un minut) Lun și periodic (la fiecare 2 secunde) . Acesta este motivul pentru care frânele, care apar adesea în utilizatorii VMware ESX / ESXi.

Cum de a gestiona coada si un algoritm adaptiv pentru VMware

Acum devine clar de ce nu ne-am expune imediat parametru Disk.SchedNumReqOutstanding pe gazde VMware ESX / ESXi la o valoare maximă - putem apela la matrice SP QFULL. Pe de altă parte, să-l reducă, prea rău - vom limita numărul de operații IO de la gazdă la LUN.

Prin urmare, avem nevoie de o abordare flexibilă, și este de la VMware (coadă algoritm adaptiv adâncime). Acesta funcționează astfel: vom activa folosind parametrii Disk.QFullSampleSize și Disk.QFullThreshold în Setări avansate. Acestea influențează aici că:

  • QFullSampleSize - în cazul în care numărul de numărul de răspunsuri QFULL (este OCUPAT) depășește ea, ESX / ESXi jumătate taie adâncimea cozii (LUN adâncimea coadă)
  • QFullThreshold - în cazul în care numărul de răspunsuri pe care QFULL sau BUSY nu mai este să-l depășească, The ESX / ESXi va crește treptat adâncimea cozii LUN de 1 (cum ar fi, la fiecare 2 secunde).

Dar indiferent cât de mult a scăzut DQLEN - sub valoarea setată DSNRO ne nu va cădea. Ea ne protejează de eșecul neașteptat de performanță. Apropo, acești parametri sunt, de asemenea, la nivel mondial -, astfel încât, dacă unul (de exemplu, inhibarea) matrice de la gazdă va fi supus efectelor adaptive ale ESX / ESXi, și apoi pentru o alta (de exemplu, productivitatea) va fi realizată de astfel de trucuri.

Acum, puteți citi în continuare pe această temă:

Adică morală a poveștii este - Descriere implicită pentru DSNRO Coadă Profunzimea și potrivite pentru cele mai multe cazuri. Dar, uneori, are sens să le schimbe. Dar, în acest caz, este necesar să se țină cont de parametrii de depozitare, structura SAN, numărul de LUN, și alți parametri care afectează performanța de intrare-ieșire.