Csak én hívom „advanced” jelzővel, amúgy a VMware inkább „improved”-nek nevezi. Tisztázzuk mi az a DRS…..
Egy VMware klaszterben a hosztok terhelésének kiegyenlítésére szolgáló automatizmus, amely a vCenter Server által biztosított. Ebből fakad az, hogy a vCenter-től függ, ha az nem fut, akkor nincs DRS. Továbbá ez alapesetben egy reaktív funkció, szóval akkor lép akcióba, ha a terhelés már nem egyenletes – van predictive DRS is, amely a vRealize Operations-al rendelkező ügyfeleknek opció, másnak egyáltalán nem. Ez utóbbi a histórikus monitoring adatok alapján információt ad a DRS-nek, hogy visszatérő terhelések esetén rendezze át a klaszterben futó virtuális gépeket, hogy a várható és mindenképpen bekövetkező terheléskor a klaszter azzal együtt legyen kiegyenlített.
A DRS minden ötödik percben fut, akkor jönnek létre azok a javaslatok, melyik gépet hová kellene mozgatni. Partially automated esetén ezt ki is írja, Fully automated esetén pedig végre is hajtja. Ez az ablak ismerős lehet, egy vízmértéken mutatja meg hogy mennyire dolgoznak egymáshol közeli terheléssel az ESXi-k. A buborék amúgy csak jobbra képes elmozdulni a középső állapotából.
Bármilyen furcsán is hangzik, de a DRS mindig a hosztok egyenletes kihasználására törekedett, amely nyilván igen gyakran hozta a virtuális gépek jobb futását, mivel a nem túlterhelt hoszton alapvetően nekik is jut a használni kívánt és hozzárendelt erőforrásokból, de kétségtelen hogy a hosztok irányából látta a terhelést.
A vSphere 7 megjelenésével ez gyökeresen megváltozott. Az öt perc helyett immáron percenként fut a DRS kalkuláció, illetve a hosztok „mellett” immáron inkább a virtuális gép szemszögéből vizsgálja a terhelést. Ennek érdekében minden VM-re számol egy úgynevezett DRS score értéket, amelyet százalékos formában tár elénk. A 0% a legrosszabb, a 100% a legjobb, de nagyon fontos tisztázni, hogy ez nem azt az értéket jelenti, hogy a VM nem kapja meg amit kér és emiatt csak például 87%-ra képes annak amire az erőforrásai alapján képes lenne. Az érték a VM erőforrásainak biztosításának hatékonyságát jelzi. Alább látható a klaszterben futó virtuális gépekre számolt DRS score, amely a „CPU % RDY (Ready), Memory swap, CPU cache behavior” értékekből kerül kalkulációra. Fontos, hogy
A fenti vízmérték helyett a klasztereken ez kerül megjelenítésre a 7.0-tól kezdődöen, amely tulajdonképpen a fenti VM DRS score-ból számolt átlagot mutatja a bal oldalon, a jobb oldalon pedig 20%-os bontásban azon VM-ek számát és megoszlását, amelyek a 20-as intervallumokban találhatóak.
Tényleg jegyezzük meg, hogy attól hogy egy VM a 20-40% kategóriában van, még nem jelenti azt hogy szenved, csupán azt hogy a rengeteg tényező alapján amit a DRS figyelembe képes venni (performance metrics, kapacitás stb) ilyen értékkel rendelkezik. Előbbiek nyilvánvalóan azok, amiket fentebb is említettem, a CPU RDY és egyebe, utóbbi pedig például az, hogyha a VM hirtelen szeretné kihajtani minden processzorát, akkor van-e elegendő mozgástere a hosztnak. Na ezekből számolódik a VM DRS score. Ezt ki is írja nekünk.
Lényeg a lényeg, hogy a VM DRS Score, a Cluster DRS score segítségével megpróbálkozik a hosztok CPU és RAM terhelése mellett/inkább helyett a virtuális gépekkel törődni, hogy mindig legyen elegendő szabad kapacitás a hirtelen megnövekvő CPU/RAM terhelésre a VM-ek által, illetve hogy azért a hosztokban jelentkező kiszolgás se helyezze a magát a hosztot komolyabb terhelés alá. Tehát ha van egy olyan hoszt a klaszterben, amely egy alacsonyabb VM DRS score-al rendelkező gép számára jobb VM DRS score-et tud szolgálni, akkor mozgatja a VM-et.
Scalable shares
A resource pool-ok nagyon sok rendszerben teljesen rosszul használtak, amolyan rendezési elemként tekintenek rájuk, szóval semmi sincs konfigurálva rajtuk – nincs reservation, sem limit a normal share érték használt. Bár erre a célre a VM folder-rek használandóak, de azokat a „Hosts and clusters” nézetben nem látni és egy valamire való admin úgyis mindig azt használja.
Itt azt fontos megérteni mielőtt belekezdünk, hogy a resource pool-oknak – amennyiben nincs limit/reservation konfigurálva – csak akkor van lényegi értékük, ha valamilyen formában versenyezni kellene a processzor vagy memória-erőforrásokért, tehát egy nem túlfoglalt/túlterhelt rendszerben SEMMI értelmük.
vSphere 6.7-ig ha létrehoztunk mondjuk három resource pool-t mondjuk így:
A share értékek a high-normal-low sorban 8000-4000-2000 számmal bírnak, szóval 4:2:1 a megoszlás. Azonban ez egy resource pool-ban lévő virtuális gépek számára egyenlő arányban – ha nincs limit/reservation a VM szintjén, illetve azonos mennyiségű vCPU/RAM-mal rendelkeznek- osztódnak ki a resource pool-nak járó erőforrások. Találkoztam nagy ügyfélnél olyan beállítással, amely az üzleti kritikus szervereknek versenyhelyzetben kevesebb erőforrást biztosított mint a Test/Dev VM-eknek!
Szóval nézzük tovább a példát.
| share | share érték | VM-ek száma | share/VM |
|---|---|---|---|
| high | 8000 | 4 | 2000 |
| normal | 4000 | 2 | 2000 |
| low | 2000 | 1 | 2000 |
Egy ilyen beállításban, minden VM attól függetlenül hogy melyik resource pool-ban van, azonos mennyiségű erőforrást kap. Ez nem túl fair, főleg akkor nem ha a high RP-be beteszünk még két VM-et.
| share | share érték | VM-ek száma | share/VM |
|---|---|---|---|
| high | 8000 | 6 | 1333 |
| normal | 4000 | 2 | 2000 |
| low | 2000 | 1 | 2000 |
Ezt senki sem akarja, ahelyett hogy pozitív irányba változtatná a resource pool-ok használata a teljesítményt éppen az ellenkezőjét okozza. Beállítottad a share értékét valamire és a VM annál lehet végül kevesebbet kap. Ennél még az is sokkal jobb lenne, ha nem lennének resource-pool-ok, mert ott mindenki egyenlő. (Ezért szoktam mondani, hogy jól ki kell számolni ezt és ha nem érted, nem vagy biztos magadba, keress szakértőt!) 6.7-ig a virtuális gépek számának változásával a share-értékeket is szükséges volt állítgatni.
A vSphere 7-tel ez megváltozott, rájött a VMware is arra, hogy ez nem olyan szép. Analógiát vonnék a % alapú admission control beállítással, ahol régebben ha újabb hoszt került be a klaszterbe, akkor át kellett írni a %-okat, azt hiszem 6.7-ben vezették be a „host failure tolerates”-ből származtatott automatikus %-ot. Megjelent hát a Scalable Shares nevő funció, amely bekapcsolása pont a fentebbi esetet zárja ki.
Szóval a fenti példa esetén annyiban változik meg minden, hogy a share-eket a VM-ek számával is számolja.
| scalable share enabled RP | share érték | VM-ek száma | scalable share effektív share | share/VM |
|---|---|---|---|---|
| high | 8000 | 6 | 6*8000=48000 | 8000 |
| medium | 4000 | 2 | 2*4000=8000 | 4000 |
| low | 2000 | 1 | 1*2000=2000 | 2000 |
Nincs nagy matek, a VM annyit kap, amennyit az RP-n beállítasz, attól függetlenül hány VM van vele azonos RP-ben. Szóval a relatív távolságokat tartja meg az RP-k között minden esetben.
Hol kapcsolhatod be? Cluster és Resource pool szintjén, ha előbbin állítod be akkor minden RP örökli.
Összefoglaló
A DRS-nél nincs mit eldönteni, mostantól így működik, ha tetszik ha nem. Véleményem szerint sokkal korrektebben viselkedik, mint eddig. A scalable share pedig egy olyan mentőőv, amelyet a gyengén úszók nyakába dob a VMware, mert sokszor látni a rossz beállítások miatt szenvedő klasztereket, pusztán a vSphere 7 előtti működés meg nem értése miatt. Aki eddig tudta és számolta is a szükséges értékeket, most mentesül ettől.
