Ügyfeleinktől egyre gyakrabban halljuk, hogy ilyen-olyan formában versenyképessé kell válniuk a belső IT-ra nézve a publikus felhőszolgáltatókkal. Ez több szempontból nyilvánvalóan lehetetlen, még akkor is ha a “data privacy” azaz adatbiztonságot úgy határozzák meg, hogy mindenképpen saját vagy kolokációs adatközpontban legyen a felhő.

Ma már erre számtalan lehetőség van. Így létezik az Oracle, Amazon, Microsoft stb. olyan szolgáltatásuk, amiben igazából az ügyfél adja az áramot és a hűtést, de minden mást teljesen vagy részelegesen a gyártó szolgáltat. Teszi ezt magával a felhővel is, aminek adott szintjét – IaaS,PaaS stb – szolgáltatásként vesszük igénybe. Saját adatközpontban van? Igen! Felhő? Igen!

Ennek egy másik megközelítése a VMware Cloud Foundation, ami arra az egyszerű feladatra hivatott, hogy a lehető legtöbb feladatot automatizáltan és szabványosan szolgáltassa. Többször, mint termék hivatkoznak/hivatkozunk rá, de alapvetően ez egy csomag, amiben legalább egy, de gyakorta három-négy komponenst már használnak az ügyfelek.

A fenti képen látható VMware szoftverek egy adott verzióját tartalmazza a VMware Cloud Foundation egy adott verziója – így a fenti esetben például a VCF 4.0, vSphere7-et. Ezektől a verzióktól sem felfelé, sem lefelé eltérni nem lehet, ugyanakkor nem szükséges minden komponenst használni – például az Automation és az Operations is lehet opcionális, bár erősen javallott használatuk.

A VMware Cloud Foundation előnye az előző bekezdés alapján már sejthető, nem enged “version drift”-et, azaz nem engedi meg, hogy a rendszerek életciklusa valamilyen fázisában más ütemben, más verzióra frissüljön vagy még inkább gyakori módon, megragadjon egy verzión. A VCF verzió, mint csomag az adott verziójú komponensekkel működik tökéletesen, ezt a gyártó garantálja, viszont csak azokkal.

Sajnos túl sokszor tapaszalunk olyat, hogy egy kiszolgáló vagy egy egész klaszter, a telepítést követő második évben eléri a végső állapotát és azt konzerválva használja az ügyfél még 3-4 évig. A VCF ezen úgy segíthet, hogy a frissítéseket automatizáltan hajtja végre, az üzemeltetésnek nem kell a vSphere – VCSA és ESXi – k, majd az NSX komponensek – controller, edge, hoszt oldali elemek – sőt még a Log Insight és Operations frissítésével sem kell kézzel bajlódnia, megteszi ezt az SDDC Manager.

Ez utóbbi a VCF lelke, a bővítéseket – ha egy új szervert állítunk be vagy egy egész klasztert – és a frissítéseket is az SDDC Manager végzi. Órában mérve ez éves szinten legalább 400 órát jelent egy jól karbantartott rendszer esetén és ennyit spórol meg vele az ügyfél legalább.

Felhő, felhő…mekkora az indulási méret?

Meglepő, de szerencsére itt nem kell egész rack-ekről vagy adatközpontról beszélni. Négy darab kiszolgálóval elindulhat és egészen nagyra nőhet – ezrekben mérhető az ESXi kiszolgálók száma, melyet kezelni képes.

Itt a konténerizáció, abban segít ez?

VMware oldaláról csak ez segít…kis túlzással. A vSphere 7 legnagyobb újdonsága a konténerek és a virtuális gépek egyenlő kezelése – biztos hallotta mindenki a “first class citizen” kifejezést már.

Ezt megvalósítani csak VMware Cloud Foundation segítségével lehet. Hívogató tehát a vCenter Server 7-ben a sok konténeres menü, azok csak akkor kelthetők életre, mikor VCF-ben kerül felhasználásra.

Természetesen egy ilyen Kubernetes-es – és minden egyéb járulékos komponens – világ, automatizáltan hozható létre egy VCF-ben, amely élvezi a VMware NSX Data Center – aka NSX-T – kiváló szolgáltatásait – tűzfal, load balancer stb. – és VSAN – vagy distinct tároló – rugalmas tárolási képességeit.

Több információ? Hogyan próbálhatom ki?

Vedd fel az 99999 Informatikával a kapcsolatot és segítünk minden kérdésben.