1. Az alapozó rész

Nem tudok rá jó magyar kifejezést*, ezért marad a Node Fairness, de mi is ez az avatlanok számára egészen meglepő eredményt hozó új, WS16-os hibatűrő fürt képesség?

Egyszerűen szólva, nagyjából azt tudja, amit a System Center Virtual Machine Manager már jó régóta**: gondoskodik arról, hogy pl. egy Hyper-V fürtben a virtuális gépek a fürttagok terhelésétől függően automatikusan és kiesés nélkül kerüljenek át az egyik, vagy másik hostra.

Így megy ez – ebben az esetben kézzel indítva az optimalizálást – a VMM alatt

Tehát ha egy WS16 fürt egyik tagján több erőforrás (CPU és RAM) van, mint a másikon, akkor a fürt Live Migration-nal elköltözteti a virtuális gépet a “szabadabb” fürttagra. A dolog szépsége, hogy alapértelmezés szerint ez a képesség be van kapcsolva és működik is szépen (erre utaltam a “meglepő eredménnyel”). Persze azért van lehetőségünk a konfigurálásra, először kérdezzük le, hogy most hogyan működik?

Get-Cluster | fl AutoBalancer*

A képen látható második opció, azaz az AutoBalancerLevel értéke a képesség agresszivitását szabályozza, 3 fokozatban:

– Akkor legyen 1 (low), ha a host terhelésének küszöbét 80%-ra szeretnénk belőni, magyarul csak majd efelett induljon el majd a hadelhadd.
– Akkor legyen 2 (medium), ha a host terhelésének küszöbét 70%-ra akarjuk beállítani.
– Akkor legyen 3 (high), ha host terhelésének küszöbét 60%-ra akarjuk beállítani.

A host terhelésének megállapításához két mutatót csekkol a fürt: 1. Mennyi volt a CPU használat átlaga az elmúlt 5 percben?; 2. Mennyi a jelenleg foglalt RAM? Ha csak az egyik eléri a küszöböt***, indul a Live Migration.

Persze át is állíthatjuk a küszöbértéket:

(Get-Cluster).AutoBalancerLevel = 3

Az AutoBalancerMode viszont az egész képesség durvább (magasabb) szintű konfigurálására szolgál. Az érteke:

– 0, ha ki akarjuk kapcsolni.
– 1, ha csak akkor működjön, ha egy új host érkezik a fürtbe (node join, pl. reboot után).
– 2, ha egy új host érkezik a fürtbe, és/vagy 30 percenként is kezdjen el robotolni.

És persze ezt is megvariálhatjuk:

(Get-Cluster).AutoBalancerMode = 2

Ha pedig a GUI-t szeretjük jobban, akkor: Failover Cluster Manager > Cluster_neve > Properties > Balancer fül.

2. A haladó rész

Még egy fontos dolog, hogy azért ebben a cikkben is beszélhessek a SC család tagjairól: ha nagyon okosan és előrelátóan (:D) egy System Center VMM-ből felügyeljük a clustert (magyarul van a hostokon egy VMM agent), akkor jó ha tudjuk, hogy a VMM letiltja ezt az egész bulit, és ha kézzel át is állítjuk a fürtön, akkor hamarosan újra lekapcsolja majd, ergo ebben az esetben használjuk inkább a VMM-be épített céleszközt erre.

Ez az eszköz a Dynamic Optimization, ami a fürtö(ke)t tartalmazó host group-okon konfigurálható (Hyper-V és VMware egyaránt), és amely több vizsgálatot végez, például képes a tárolók vagy a hálózat I/O értékét is figyelni, és többre képes a reakciók terén is. Illetve a hostok BMC kártyáinak (iLO, DRAC, RSA, stb.) beállítása után kombinálható lesz az energiaoptimalizálással, azaz képes lesz bizonyos szabályok (pl. alacsony terhelés) mentén ki-be kapcsolgatni egy hostot, hogy ne kelljen nekünk egy plusz Paks3 a szerverterembe.

A DO és a PO is többet tud

De ha a DO nem aktív, a fenti optimalizálás akkor is képes működni a VMM-ből is, csak kézzel: az adott fürt helyi menüjében “Optimize Hosts” néven szerepel a parancs (ennek eredménye látható az első képen). Ha netalántán – egy VMM esetén is – végképp ragaszkodunk a WS16 Node Fairness-hez, akkor le is kell tiltanuk a fürttagokon az efféle optimalizálási lehetőségét.

Az ebben a témában még menőbb dolog a PRO (Performance and Resource Optimization) használata a hostok, a VM-ek és a VMM irányába, amely egyetlen hátránya az előnye is egyben, azaz egy SCOM is kell hozzá :D. Ezután viszont a SCOM, a PRO képes hardver vagy pl. alkalmazás Management Pack-ek segítségével lesz képes az optimalizálást még tovább finomítani.

A PRO globális engedélyezéshez egy SCVMM<>SCOM kapcsolat konfigurálása szükséges

Szóval a SCVMM vagy az SCVMM/SCOM páros az igazi megoldás erre a feladatra (is), de azért enélkül is van élet: ahogy a cikkből kiderül, egy szimpla WS16 fürt is képes a fentiek alapján az alapszintű automatikus VM terheléselosztásra.

—
*”Igazságos csomóponti terheléselosztás” lenne a szerencsétlen, de hát…
**Egész pontosan a VMM 2008 óta.
***A működés további heurisztikájáról egyelőre többet nem árul el a Microsoft.