Túlzott erőforrás igények negatív hatásai

Virtuális gépek igénylésekor mindenki igyekszik sok erőforrást kérni a saját szervere számára. Legtöbb esetben többet, mint amire szükség lenne. A fizikai világban nincs semmi negatív hatása annak, ha egy szerverben pl. 4 processzor van, de a rajta futó rendszer megelégedne akár egy processzor is (Maximum a szerver fogyasztása megnő). Sőt itt valóban érdemes már az elején telerakni a gépet processzorral vagy memóriával, mert ki tudja mi lesz akkor, ha bővíteni kellene, de nem lesz rá pénz a későbbiekben.

Sajnos ez a hozzáállás nem változott meg a virtualizáció bevezetése után sem. Nyílván az alkalmazások erőforrás igényeinél is igyekeznek olyan értékeket megadni, amik túl vannak a valós igényeken. Nem egyszer fordult már elő, hogy pl. túlzott lemez igény esetében alkudoztam, végül lényegesen kevesebben egyeztünk meg, és a gép a mai napig üzemel.

Milyen negatív hatása van, ha több erőforrást kérünk a gépünk számára, mint ami szükséges? Fontos dolog, hogy akkor beszélhetünk csak negatív hatásról, ha valamelyik erőforrást túlfoglaltuk. Azaz több memória van kiosztva, mint ami fizikailag a hostban van, vagy több virtuális CPU van az egy hoston futó virtuális gépekben, mint amennyi fizikai mag van bennük.

Túl sok vCPU

Egy operációs rendszer általában feltételezi, hogy az általa kezelt processzorok megközelítőleg azonos órajelen működnek. Ez a fizikai világban nyilvánvaló. Virtualizáció esetén viszont a hypervisor-nak kell biztosítania, hogy az operációs rendszer „azt higgye” hogy minden általa kezelt processzor azonos órajelen működik. Abban az esetben, ha az összes virtuális CPU száma <= mint a fizikai magok száma, akkor ez nem tűnik nehéz feladatnak, hiszen akkor minden vCPU megkap egy fizikai magot, nem kell osztoznia más gépekkel. De a virtualizáció egyik lényege pont az, hogy a meglévő erőforrásokat minél jobban kihasználjuk, ezért egy fizikai CPU-t 2,3,4 vagy még több vCPU-t kiszolgál. Ebben az esetben a hypervisor CPU scheduler-ének a feladata, hogy egy bizonyos algoritmus alapján kiszolgálja az összes virtuális gépet. Nem nehéz belátni, hogy ha több vCPU van, mint pCPU, akkor előfordulhat az, hogy egy több vCPU-t tartalmazó virtuális gép egyik processzora tudna dolgozni, de egy másik vCPU éppen akkor nem kap a scheduler-től processzor erőforrást, így az előző is várakozni kényszerül. Minél több vCPU van egy virtuális gépben, ez annál valószínűbb. Ebből pedig következik, hogy feleslegesen kért több processzor negatívan befolyásolja (befolyásolhatja)a hoston futó összes virtuális gép teljesítményét. Ez nyílván egy bizonyos mértékig nem észlelhető, de eljuthat egy olyan mértékig, amikor már a gép működésén is észre lehet venni.

A másik negatív hatás, hogy a virtuális gép memória overhead-je megnő (több vCPU, több memória igény), ezáltal feleslegesen vesz el memóriát más gépek elől. Ráadásul ez a memória hozzá lesz rendelve a géphez, nem vesz részt a különböző memória optimalizáló eljárásokban.

Sok ilyan igénnyel találkozok, ahol több processzort kérnek a gépbe. Pedig a helyes módszer az lenne (leszámítva persze néhány kivételt), ha egy processzorral indulna a gép, és ha ez a későbbiekben kevésnek bizonyul, lehet növelni a számát. Az újabb operációs rendszerek esetén nem probléma persze a több processzorról átállni egy processzorra, de a régebbiek esetében ezzel lehetnek problémák, így inkább mindig a kevéstől a több felé kellene haladni.

 Túl sok RAM

Itt is igaz amit az előző pont végén írtam, azaz minél több memóriát adunk egy virtuális gépnek, annál nagyobb lesz a memória overhead. (Az a memória mennyiség, amit a virtuális gép futtatásához használ a hypervisor)

Ezen kívül megnő a virtuális gép diszk igénye is. Ráadásul ez két helyen is jelentkezik.

• az operációs rendszer lapozó file mérete függ a memória mérettől (ez persze szabadon állítható, de pl. egy Windows 2008 R2, ha mást nem mondunk akkor a RAM méretének kb. 150%-át is képes lefoglalni).  Azaz egy 20GB RAM esetén biztosítanunk kell, hogy alapesetben 30GB-os lapozó file-nak legyen hely.
• a másik pedig az a diszk terület, amit a fizikai host használ abban az esetben ha már semmilyen módszerrel nem tudja kielégíteni a virtuális gépek memória igényét a fizikai memóriájából, ezért kénytelen a virtuális gépnek egy swap területből „memóriát” biztosítani, hasonlóan mint ahogy az általános operációs rendszerek használják a lapozó file-t. Azért, hogy a host ezt minden esetben meg tudja tenni, minden virtuális gép esetében biztosít egy a virtuális gép RAM méretével megegyező diszk területet. Ez talán nem tűnik soknak elsőre, de ha pl. van 15 db 4GB-os gépünk, akkor ez már 60GB. Ha nem bővelkedünk storage területben, akkor igen is számítani tud 10-20GB is.

Túl nagy diszkek

Talán ez a legnyilvánvalóbb. Ha több diszket kérünk egy virtuális géphez, akkor kevesebb marad a többinek. Illetve az olcsónak nem nevezhető SAN-os diszkekből többet kell használni, mint ami valójában szükséges lenne.

Szerencsére a VMware nyújt erre is megoldást. Ez pedig a Thin provisioned diszkek használata. Ez a következőképen működik. Valaki kér a virtuális géphez egy 100GB-os diszket, és persze kap is. Az operációs rendszer számára látszik a 100GB. Viszont a tényleges foglalása a storage-on annyi, amennyit valóban elfoglalnak az állományok, mappák a lemezen. Ha ez 10GB, akkor a tényleges foglalás 10GB. Természetesen ennek vannak előnyei és hátrányai is.

• nem bánunk pazarlóan a tárterülettel
• ki tudunk osztani a ténylegesnél több diszket is (pl. egy 500GB-os storage területen akár 1TB szumma diszk igényű virtuális gépet ), viszont
• monitorozni kell a tényleges helyfoglalást, mert ha az összes hely elfogy, leállnak az azon a területen futó virtuális gépek (storage DRS jól jön ilyen esetben, feltéve ha a legdrágább licensszel rendelkezünk)
• ha a fentebb említett 100GB-os diszkre a rendszergazda felmásol egy 90GB-os mappát, majd törli azt, akkor ez a törölt terület a storage számára már foglalt marad. (A következő ESX verziók már biztosan fognak erre is megoldást biztosítani a VMware tools-on keresztül)
• amikor először írunk egy eddig nem használt diszk területre, az lassabban fog megtörténni, mint egy nem Thin provisioned diszk esetében
• nem mindig használhatunk ilyen diszket (Fault Tolerance és MSCS cluster megköveteli a Thick diszk használatát

Összefoglalva, igyekezzünk mindig csak annyi erőforrást kérni, amennyire szükségünk van. Ha alulméreteztünk valamit, biztosan kérni fogjuk a bővítést, de ha valamiből sok van, szinte biztos hogy nehéz meggyőzni a szerver gazdáit, hogy kevesebbel is hasonló teljesítményre lenne képes a gépe.