A mai nap több vCenter telepítésben megjelent egy új “frissítés”, ami nem más mint a vSphere 7.0 U2. Attól függően, hogy ki mit használ a vSphere családban – itt nem a pure virtualizációra gondolok csak – fontos és kevésbé lényeges változásokra készülhet.
Születik éppen egy vSphere with Tanzu cikkem és abban éppen azt tárgyalom, hogy miért is kell NSX-T egy redundáns load balancer érdekében. Eddig ha nem volt NSX-T, akkor volt HAproxy, de az önmagában nem tudott redundáns lenni – mármint a vSphere HA nyilván védte, de más nem.
vSphere with Tanzu és NSX Advanced Load Balancer Essentials
Mostantól a licenszekbe – vSphere for Tanzu esetén – foglalva elérhető a néhai AVI network load balancer-e, ezáltal támogatottan lehetővé téve a:
- redundáns load balancer funciókat (Control plane, TKG Guest klaszterek számára)
- network service policy alapú konfigurálhatóság
- Lifecycle Manager-be illő frissíthetőség
- teljes támogatás
Nagyon jó videó a beállításról.
Confidential Container
Egy Tanzu-s környezetben kétféle módja van az alkalmazások futtatásának. TKG klaszter, ami upstream Kubernetes és a vSphere Pod, ami nem upstream, de közel áll hozzá. Utóbbi natívan az ESXi-n fut, a VI admin tényleg a mélyére is láthat. Az NSX-T igen komoly szinten képes ezekhez szabályokat csatolni. Na ezt most újabb szintre emeli az U2, amennyiben valaki AMD EPYC processzort használ az ESXi-k alatt.
“Confidential Containers for vSphere Pods, leveraging the AMD SEV-ES memory and CPU data encryption on AMD EPYC platforms for modern and easy-to-use data-in-use protections.”
1.19-es Kubernetes frissítés
A VMware a TKG Guest klaszterek esetén mindig upstream Kubernetes-t és annak verzióit követi módosítás nélkül. Ez most ért el a Tanzu-ban az 1.19-es verzióra. Ezek frissítése is egyszerűen megvalósítható.
Ami – szerintem nincs eléggé kiemelve – hogy a fejlesztő által megadhatóvá vált a service type load balancer esetén definiált IP-cím. Eddig ez véletlenszerű volt, már lehet statikus is.
AMD EPYC optimalizációk
Az EPYC processzorok első generációja még elég “furcsa” design-nal – CCX stb – jelent meg, amit a második generáció jelentősen feloldott. Az U2-ben további kiaknázható teljesítmény érhető el a gyártó szerint “AMD EPYC CPU optimizations, bringing impressive performance gains to workloads running on AMD EPYC platforms.” igen komoly mértékben. Egyelőre erről nincs sok inforáció, de talán a NUMA környékén tekergették a potmétereket.
ESXi Suspend-to-Memory
Szűk réteg számára lehet érdekes, de úgy frissíthető egy ESXi hoszt, hogy a rajta futó virtuális gépeket nem kell leállítani, illetve ha van másik hoszt elegendő erőforrással, akkor arra vMotion-nel átvinni őket. Tehát futó VM-eket “fagyaszt” meg a frissítés idéejére. Nyilván ezalatt azok nem működnek, viszont nem kell őket sem leállítani, sem a frissítés után újra – akár sorrendben – bekapcsolni. Nem gondolom hogy sok előfordulási eset lehet, de jó tudni hogy ilyenre is van lehetőség.
Még több információ erről itt: https://core.vmware.com/blog/make-esxi-upgrades-faster-suspend-memory
vMotion Auto Scale
Mivel ma már nem kevés helyen van 25/40/50/100 gigabites hálózati interfész a kiszolgálókban, egyre gyakrabbá válik, hogy annak képességei egy vMotion – igazából több vMotion esemény – esetén nem használódik ki. Persze vannak trükkök, mint több vMotion interfész beállítása vagy éppen az advanced parameter-ek állítgatása, de mindkettő manuális dolog.
A frissítés megoldja, hogy az ilyen magasabb sávszélességgel rendelkező hosztokon az optimalizációt – több vMotion interfészt nem fog létrehozni – de például 25 gigabites esetén állítólag érezhetően tud majd segíteni. Egy vMotion szál egyébként maximálisan kb 15 Gbit forgalmat tud “elhasználni” tehát innen a nagyobb sávszélességek esetén észrevehető javulás.
Ez annyit jelent, hogy a következő stream “leosztást” állítja be:
- 25 GbE = 2 vMotion stream
- 40 GbE = 3 vMotion stream
- 100 GbE = 7 vMotion stream
VMware vSphere Native Key Provider
Ha eddig titkosított VSAN volt az igény ,akkor küldő KMIP képes KMS-re volt szükség. Most ennek követelménye megszünt, már a VCSA is tud KMS lenni.
TPM a Windows és Linux guest-ekben
A hosztban található – elég sokban van azért már – TPM nélkül lehetséges a guest Windows és Linux-ok számára vTPM-et biztosítani.
VMware Time Provider Plugin for Precision Time on Windows
Erről és alapvetően a legjobb gyakorlatokról az NTP kapcsán hamarosan jelentkezem egy bejegyzéssel. Az U2-ben VM hardware 18 – és felfelé – van leheőség Precision Clock eszközt adni a VM-nek. Ez pontosabb időt tud biztosítani mint az NTP alapú megoldások.
VSAN 7.0 U2
Diszaggregált hiperkonvergencia
Jól hanzik, ilyet már régóta látunk a piacon, de most már “ingyen van”. Szóval ha van egy VSAN klaszter – nyilván ezt licenszelni kell VSAN Enterprise vagy Enterprise plusz szintre – akkor arról tárterületet ki lehet adni – semmi iSCSI vagy NFS – natív VSAN módon. És most a lényeg, ezen felhasználókat NEM kell licenszelni.
Mindezt úgy hogy:
- lehet hibrdi vagy all-flash akár.
- titkosítás támogatott.
- csak tömörítás vagy deco is támogatott.
- és akár 128 hoszt lehet ilyen vápír, azaz egy VSAN klaszteren csüngő.
John Nicholson itt mutatja be miről van szó:
Health check history and correlation
Több másik VMware termékben szerepelt már ez az idővonal alapú napló. Most a VSAN esetében is elérhető lett, időpontra bontva mutatja a VSAN-unk egészségi állapotát érintő változásokat és azoknak elhárítását.
Efficiency Enhancements
Ezek az olyan számszerűsíthetetlen dolgok.
- Improved performance when using RAID-5/6 erasure codes
- Improved larges equential writes
- Reduced CPU usage
- Improved CPU efficiency writing data to cache/buffer tier
- Improved small random I/O
vSAN over RDMA
Az RDMA Mellanox hálózati interfészek már a VSAN HCL-en, melyeken használható az RDMA. Ha valaki killer VSAN klasztert akar építeni, akkor ez az egyik alapköve annak.
