A VMware csillogása mostanság eléggé megkopott és bizony azért a frissítések is el-elmaradtak az utóbb időben. Egy ilyen időszak után érkezett meg többek között, a vSphere 8U3. Mint lenni szokott, az U-verziókban azért van pár újdonság, nem csak hotfix-ek és patch-ek.
Maga a frissítés amúgy 8GB és feltehető a régi módon, a VAMI felületről, de működik az alacsonyabb „leállási ablakkal” kecsegtető mód is, amiben kigördül egy újabb VCSA és átmigrálódik a konfig. Én az előzővel frissítettem és meg is néztem, mik az újdonságok.
Átdolgozták a vCLS (vSphere Cluster Service)
Mikor kitalálták ez a vCLS gépekbe offload-olt működést, akkor sokan néztek sandítva erre. Ezen update előttig klaszterenként három ilyen vCLS gép jött létre, meglehetősen alacsony CPU/RAM és diszk igénnyel. A 8.0.3-ban ezt még lejjebb faragták.
Pre 8.0.3 a vCLS gépek az alábbi konfigurációval bírtak.
Továbbá mostantól nem az EAM tolja ki ezeket a gépeket (látható is volt az OVF deploy task amint létrehozta őket), hanem hanem az ESXi maga hozza létre ezeket és indítja el. Ennek is köszönhetően megszűnt a vCLS gépek által használt tárhely, nem foglalnak semennyit egyik datastore-on sem, az ESXi memóriájába kerültek. Szintén üdvözlendő változás, hogy mostantól nem három vCLS gép lesz per klaszter, hanem maximum kettő. Ennek az egésznek a fantázianeve az Embedded vCLS lett.
Lényeges, hogy a vCenter Server 8.0U3-ra történő firssítése még nem fogja ezt az Embedded vCLS módot eredményezni, szükség van a vSphere ESXi-k frissítésére is! Viszont ha a frissítés megtörtént, akkor automatikusan Embedded vCLS lesz.
vVols Stretched Storage Cluster Support
Nem túl gyakori hogy valaki használ vVol-t, de ha valaki mégis, akkor eddig nem nagyon tudodd stretched cluster-ben dolgozni vele, mivel nem volt támogatott. Ezt feloldották most és ez sem lehet akadályozó tényező. Egy uniform stretched cluster-en ábrázolták.
Limiting the Number of vSphere Hosts Sending UNMAP to a Given VMFS Datastore
Lényegesebb új képesség lehet pár klaszterben, pár ügyfélnél, elsősorban olyanoknál ahol rövid idő alatt létrejön egy csomó VM, majd el is törlődik. Nem mondom, hogy tipikus VDI, mert ott egy instant clone esetben azért bár létrejöhet nagyobb mennyiségű VMDK, de azok méretben azért nem túl nagyok. De elképzelhető, hogy ezek törlése vagy éppen nagyobb számú virtuális gép kikapcsolása megterheli a tárolót a rendszer mögött. Eddig is be lehetett állítani a reclaim sebességet MB/s mértékegységgel. Most konfigurálható lett az is, hogy egyszerre, egy időben hány darab ESXi hoszt küldhessen UNMAP-et a tárolónak. Alapértelmezetten ez 128, szóval egészen biztos hogy szűkebb környezetünkben ez a 128 magasabb szám, mint amennyi hoszt egy klaszterben van.
vSphere Live Patch
Eddig is volt bizonyos esetekben Quick Boot, de ezt most egy szinttel emelik. Kellett is, mivel az nem mindig kivitelezhető, mondjuk hetente, hogyha kiadnak egy magas CVSS miatt valami javítást, akkor a teljes környezeten telepíteni azt, rengeteg teljes hoszt leürítés mellett, újraindításokat igényel. Pont erre jött ez a funckió, mert elméletileg ez azt tudja, hogy bizonyos – tehát nem minden – javítás esetén nem lesz tradicionális maintenance módba tétel. Nem lesz csomó vMotion – akinél van DRS ugye – csak részben megy el a host maintenance módba. Itt jegyzem meg, hogy már háromféle maintenance mód van, mivel létezik a rendes, a partial és az NSX-ben értelmezett maintenance mód 🙂
Szóval annyi történik, hogy az ESXi ebbe a partial maintenance módba kerül, majd az új kód betöltődik, patchelődik és a VM-ek egy pillanatra stun-ba kerülnek és már futnak is tovább az új kóddal (FSR). Ez utóbbi történik amúgy akkor is, mikor egy futó géphez ad vagy távolít el valaki egy virtuális elemet – kontrollert, diszket, akármit.
Több infó itt található róla: https://core.vmware.com/blog/vsphere-live-patch
vCenter Reduced Downtime Update
Immáron minden topológia támogatott:
- az érintett vCenter az általa menedzselt hoszton/klaszterben fut – ez a Self-managed
- az érintett vCenter egy másik vCenter által menedzselt hoszton/klaszterben fut – ez a non self-managed
- az érintett vCenter ELM-ben van
- vCenter HA
Ütemezhető Snapshot törlés
Szerintem ez a legfontosabb – amit nem is írnak hogy már van ilyen is – új feature. Bár per virtuális gép kell ütemezni a taszkot, de végre van ilyen. Beállítható, hogy milyen gyakorisággal fusson egy olyan taszk, ami törli az általunk megadott időszak.
Végre valahára talán kevesebb „véletlenül ott maradt két éve” snapshot-tal. Remélem előbb/utóbb lehet ezt mondjuk klaszter szinten ütemezni és nem per VM.
Egyebek
Pár egyéb dolog, ami biztosan sokaknak releváns:
- DPU HA: Több DPU lehet a hosztokban, amik így active/standby módban működhetnek ha mondjuk NSX-el használnánk ilyet – mi mással ugye.
- két DPU aktívan: Ha kevés lenne egy DPU kapacitása, akkor két külön vDS-ben használva őket, mindkettő hajtható aktívan.
- Intel Xeon Max sorozat támogatása: HPC, AI/ML stb. Mondjuk a üres zöld téglalap gyártó legkelendőbb dobozába nem is rendelhető Max proci, de nem néztem végig az összes szervert, biztos van olyan amibe tehető és amin az ügyfél pont vSphere-t akarna futtatni.
- vGPU-k jobb kezelése. Ezúttal már nem kötelező azonos vGPU profilt használni egy adott ESXi hoszton az összes VM-hez. Már lehet más-más profil rendelve hozzájuk, azonos hoszton.
- vSphere DRS Settings for vGPU: a DRS beállításaiban megadható, hogy mekkora legyen a max stun time a vGPU-val szerelt gépek esetén ha éppen az jutna eszébe, hogy ilyet migrálna egyik hosztról a másikra.
- Virtual Machine Disabled Operations: Elsősorban backup termékek le tudnak/szoktak tiltani bizonyos műveleteket, amelyeket a mentés/visszaállítás bizonyos lépésében vagy folyamata közben nem lehet/szabad elvégezni. Persze eddig sem lehetett a DRS által – sem kézzel – vMotion-özni egy olyan VM-et, amin a mentési feladat éppen snapshot-ot töröl, de ez eddig failed task-ot dobott. Most el sem indul a taszk, szóval nem lesz failed, hogy ne ugorjon erre a monitoring.
Deprecated dolgok
- vSphere Trust Authority: ilyet vizsgán kívül sosem láttam sehol.
- Storage DRS and Storage IO Control with respect to IO latency. Azaz egy Storage DRS miatt használt datastore cluster esetén a migrációs döntésekben a késleltetés a következő főverzióban már nem lehet majd alapja a döntésnek.
Hivatalos link: https://core.vmware.com/resource/whats-new-vsphere-8-update-3#section8
