A mai nap erősen megszórta a közösséget a VMware a bejelentéseivel.
vSphere 7 U1
Nagyon gyorsan követte a vSphere 7 GA-t az első update megjelenése.
A skálázhatóság tövább nőtt a VM-ek és a klaszterek mérete kapcsán, immáron 786 vCPU és 24TB RAM lett. SAP HANA és az EPIC Cache Operational Database workload igényelte ezt a méretet….félelmetes, főleg a 2-utas szerverek világában, de a 4-utas gépeknél majdnem lehetetlen beletenni ennyi RAM-ot fizikailag egy hosztba, de a pCPU:vCPU arány is nehezen tartható – még.
Eddig 64 hoszt lehetett egy klaszterben, mostantól 96 darab.
VMware vSphere with VMware Tanzu
A folyamatos átnevezések és összevonások közepette rengeteg megoldása állt elő a VMware-nek a konténer témára (link):
- vSphere Integrated Containers – VIC
- VMware Tanzu Kubernetes Grid – az új Essential PKS
- VMware Tanzu Kubernetes Grid Plus
- VMware Tanzu Kubernetes Grid (as a Service) in Tanzu Mission Control
- VMware Tanzu Kubernetes Grid with vSphere 7 – ez utóbbi eddig csak VMware Cloud Foundation 4.X – ben volt elérhető
Aztán most ez utóbbit tették elérhetővé VCF nélkül is, mezei vSphere 7 felhasználók számára.
Fel is került a VMware HOL-ra egy labor, amit itt lehet megtalálni:
Ha nincs időd végigcsinálni a labort, akkor itt van a teljes dokumentáció, képekkel:
https://docs.hol.vmware.com/HOL-2021/hol-2113-01-sdc_html_en/
Lényeg a lényeg, hogy nem feltétlen van szükség NSX-re és az általa adott szolgáltatásokra, amely önmagában megkönnyíti a bevezetést, szóval tényleg maximum órákban mérhető, míg egy VCF alapú bevezetés ennél egy, de inkább két nagyságrenddel több, illetve igényel hardvert is. Ez itt pedig kb bármin elfut amin a vSphere 7.
Szóval az NSX opcionális, sima vDS-sel is használható – az NSX-T 3.0 mondjuk vDS-t is használhat szóval rossz a hasonlat. Az NSX hiánya jelenti a load balancer hiányát is, ami azért elég fontos egy kontérenes világban, itt a HAproxy használható – állítólag majd lesz más gyártó is.
A VSAN, vvOL és mindenféle CSI-n keresztül használható tároló sem kell, használható a jó öreg VMFS-re formázott block vagy bármilyen fájl-alapú tároló is.
Nekem azért tetszik, mert átlátható és még az én, újdonságokra teljesen immunis agyamnak is emészthető.
VMware Cloud Foundation 4.1
Itt is elég gyorsan jönnek az új és új kiadások. Nem oly régen még a 4.0 volt friss, aztán rá 3-4 hétre a 4.0.1 és most rá egy hónapra a 4.1. Release notes még nics, szóval a BOM-ban csak annak változása biztos, amit ma bejelentettek, szóval vCenter Server 7 U1, vSphere ESXi 7 U1 új SDDC Manager és új vRealize csomag van benne.
Újdonságok:
- vSAN Data Persistence Platform: https://blogs.vmware.com/virtualblocks/2020/09/15/announcing-vsan-data-persistence-platform
- VMware Cloud Foundation Remote Clusters: Immáron a VCF képes kezelni más telephelyen lévő workload domain-eket. https://blogs.vmware.com/cloud-foundation/2020/09/15/extending-the-power-of-vmware-cloud-foundation-to-the-edge
Néhány megkötés és követelmény azért van, méhozzá minimum 3 és maximum 4 hoszt lehet egy ilyen klaszterben – de egy WLD-ben lehet több ilyen edge klaszter – 10 Mbit és 50ms max késleltetés.
Két opcó van, azaz itt alább az egész Workload domain van edge helyen.
Illetve amikor egy Workload domain egy klasztere van edge lokáción.
- A vVol megjelenése mint principal – azaz elsődleges – tároló a workload domain-ekben. A management domain-ben továbbra is VSAN a principal.
- A vRealize Suite Life Cycle Manager (vRSLCM) immáron automatikusan telepítődik az SDDC Manager által, illetve a vRSLCM végre felismeri hogy VCF-ben fut. A vRealize csomag 8.1 verziójának komponenseit képes telepíteni.
További információk: https://blogs.vmware.com/cloud-foundation/2020/09/15/whats-new-with-vmware-cloud-foundation-4-1/
VSAN 7 U1
- vSAN Shared Witness: Immáron akár 64 darab 2-node-os klasztert képes egy witness appliance kiszolgálni, szóval 64-edére csökkent az igény, mert eddig 1:1 volt az arány.
- „Compression only” beállítás: eddig csak egyben lehetett a deduplikációt és a tömörítést bekapcsolni, ezek után a tömörítést önmagában is be lehet állítani. Ennek kétségtelen előnye a deduplikáció CPU és RAM-igényének megspróolása, de az is, hogy ha egy disk group-ból kiesik egy lemez, akkor nem kerül üzemen kívülre az egész group – deduplikációnál ez így van.
- VSAN IO: Eddig ez fling-ként volt elérhető, most beépült. Ezzel lehetséges konkrét workload-ot, konkrét időszakban elemezni a VSAN szempontjából.
- vSAN HCI Mesh: Egy vSAN datastore-t, aminek lényegében a VSAN klaszter a határ, támogatott módon be lehet csatolni egy másik vSAN klaszterbe. Felmerül, hogy iSCSI-n/NFS-en ezt hasonlóan meg lehetett tenni eddig, de ez itt natív VSAN módon oldja meg. Így akár plusz kapacitás, akár migrációról van szó, a VSAN datastore felhasználható egy másik klaszterből, migráció esetén így egy időben végrehajtott Storage vMotion és vMotion a folyamat, hanem ez szétválasztható.
- Capacity reserve: Bekapcsolható külön a működéshez szükséges terület és a hoszt hibája esetén felhasználandó terület fenntartása. Ez nyilván leveszi ezt a mennyiséget az elérhető kapaciásból, így kényszerítve ki, hogy ha szükség lesz rá, akkor lesz elegendő kapacitás.
- VSAN File Services SMB, Kerberos + Active Directory: Eddig NFS-en volt elérhető a File Services, már SMB-n is. AD authentikáció SMB-vel és Kerberos az NFS-el is elérhetővé vált.