A VMware infrastuktúra egyik legfontosabb eleme kétségkívül a vCenter Server. Amolyan karmester és egyben mindenes is, hiszen olyan sokféle feladata van, hogy felsorolni is tetemes hosszúságú listát eredményez.
Az azonban könnyen megérthető, hogy lényegében ez az ablakunk a VMware hosztjainkra, a virtuális gépeinkre. Van Host UI és igazából akár minden egyes ESXi hoszt management IP-jét beírva a böngészőnkbe, eljutunk valami hasonló felügyeleti felületig, de abban korlátos a véghez vihető akcíók száma, illetve ha vCenter-ben bizonyos hosztokat egy klaszterbe szerveztünk, akkor azt az ESXi oldaláról vizsgálva, annyit látunk, hogy VM jönnek-mennek a DRS normál illetve a High Availivilty eseti működése következtében.
Annyi biztos, hogy a HA működéséhez nem szükséges a vCenter Server. Aki mást állít, az talán azért van, mert keveri azzal, hogy a HA bekapcsolásához és konfigurációjához viszont elengedhetetlen. Viszont ha már be van kapcsolva, akkor a vCenter Server kis túlzással kikapcsolható. Ebből fakad az is, hogy nyugodtan tehető akár egy általa kezelt HA klaszterre is, igazából ez az amit én is preferálok abban az esetben ha valaki mégis szeretné függetleníteni a menedzselt entitástól és inkább tenné egy standalone ESXi-re – vagy telepítené fizikai kiszolgálóra a Windows-os vCenter Servert. Ekkor bár a klaszterben futó VM-ek – ha közös tárolón vannak – védettek a hosztot érintő hibák ellen, de a vCenter Server nem, mivel egyetlen géphez van kötve. Szóval amennyiben nincs másik klaszter ami független például az adott telephelytől, környezettől, zónától, akkor amolyan „no brainer” hogy bizony saját maga által kezelt klaszterre kell tenni, ezzel biztosítva a túlélését egy kiszolgálót érintő hiba esetén.
Mielőtt a mentés és visszaállításról írnék, elemezzük mire kell és mennyi idő alatt kell visszaállni, ha beüt valami olyan hiba, ami a vCenter teljes elvesztésével vagy magának a vCenter szolgáltatásának, adatbázisának sérülésével jár.
| Funkció | Működik-e |
| High Availability | Igen – VM-ek újraindítása a vCenter Server nélkül is megy. Klasztert bővíteni nem lehet azonban. |
| Distributed Resource Scheduler | Nem |
| vMotion | Nem |
| Storage vMotion | Nem |
| vDS | Igen de nem menedzselhető. |
Azon lehet vitatkozni kell-e DRS ha a vCenter éppen elérhetetlen. Válasszuk ketté, ha a vCenter Server az általa menedzselt klaszteren van és ott történik valami hiba ami a vCenter-en kívüli, de őt is érinti, akkor nem. A DRS egy reaktív – bár már írtam korábban a vRealize Operations használata esetén bekapcsolható prediktív módról – funkció, azaz ha egy hoszt túlterheltté vagy a terhelés maga nagyon arányatalanná válik, akkor vMotion felhasználásával megpróbálja kiegyenlíteni azt. Igaz ez a Storage vMotion-ra is, amely hasonlót tesz a datastore szinten, csak a késleltetést és szabad helyet vesz figyelembe. Szóval egy beállt és nem különlegesen dinamikus terhelést kiszolgáló klaszter esetén az a pár perc/1X perc amíg a vCenter visszatér, nem okoz különösebb fejfájást.
Ha a vCenter egyébként azért áll le, mert benne megsérül valami, akkor ennek helyrebillentése nem automatikus, nekünk kell valamit tenni. Itt természetesen a kiesés hossza miatt, elképzelhető az üzemeltetésnek olyan feladata, hogy hozzon létre egy PG-t a vDS-en vagy éppen állítson be affinitási szabályt két gépre stb. Na ekkor kell valamit tenni gyorsan. De mit?
A vCenter Server nálam a VCSA-t jelenti. Mindenki aki Microsoft Windows-on futtatja, annak nagyon gyorsan indítania kell egy projektet a VCSA-ra migráció miatt. A Windows-os vCenter egy szükséges rossz volt, de a 6.7-es VCSA már nagyon erősen meghaladta a Windows-os párját. Utóbbi azért volt néhány alkalmazásban óhajtott, mert Windows Failover Cluster-ben lehetett redundáns vCenter építeni. Már van VCHA is, lásd itt:
File based
Mentés
Nem lesz meglepő, de image és fájl alapon is lehetséges a mentés. A VCSA 6.7 környékén elért oda a VCSA saját mentési megoldása, hogy képes ütemezetten menteni a saját konfigurációját FTP, FTPS, HTTP, HTTPS vagy SCP protokolon valami távoli helyre.
A „configure” kiválasztása után, minden részletet meg kell/lehet adni. A schedule-nál a leggyakrabb ütemezhetőség a napi, így aki ennél is gyakrabban kíván menteni, annak inkább az image szintű mentés – is – a célravezető.
Eseti mentés is indítható, de mindegyikre igaz az alábbi kitétel.
Visszaállítás
Meglepő de visszaállítás a fentebb a VCSA felületéről indítva nem lehetséges. A fenti ábrán egyébként a legfontosabb követelményt mutatja is, nem mást mint a „The restore process requires that both the installer and backup versions are identical” kitétellel. Azaz pontosan arra VCSA installer-re van szükség amilyen verziójú VCSA-ból a mentés készült. Ezt jó ha megjegyezzük és a frissítések során az ISO-kat eltároljuk, ki tudja.
A restore során nem a meglévő VCSA-t állítjuk helyre, hanem egy újba állítjuk vissza a konfigurációt a mentésből. Meglepő, de ez a VCSA installer első ablakából indítható, bevallom, én zsigerből az elsőre/másodikra szoktam kattintani, de álljon alább a kép, hogy van Restore gomb is.
Mint a telepítés, az upgrade, így ez is két lépésből áll. Az első lépés lényegében minden esetben azonos, felkerül egy új VM entitás az általunk megadott névvel, IP és egyéb beállításokkal.
A harmadik lépésben meg kell adni a backup helyét, teljes elérési úttal.
Ha jól csináltuk, akkor kilistázza a mentéseket az adott helyen, szóval csak a mentés főkönyvtárát kell megadni.
Itt az egyik mentést kiválasztva sok más kérdés nincs és a folyamat lényegében innentől végképp megegyezik az összes többi VCSA workflow-al.
Image based
[UPDATE]: A VCSA 7-ben az image alapú nem csak nem javasolt, hanem egyáltalán nem támogatott.
A snapshot alapú mentést és visszaállítást nem részletezem, mert a mentési szoftverek igen sokfélék lehetnek és igen változatos módon lehet belőlük a visszaállítást elvégezni.
Alapvető probléma azonban, hogy ezek a szoftverek a vCenter Server szolgáltatásain keresztül készítik a snapshot-ot, azon keresztül fut az inventory és egyéb számukra elengedhetetlen aktivitás. Na most ha a vCenter nem elérhető, akkor a visszaállítás célja sem tud vCenter lenni, ekkor ez szükségszerűen egy ESXi hoszt kell legyen, direktben.
Mire számíthatunk a visszaállítás után?
Ha a mentés és az aktuális állapot között nem módosult semmi, akkor természetesen sok mindent nem fogunk „veszteni”. Ezzel szemben ha:
- új VM entitások nem jelennek meg a vCenter inventory-ban – vagy orphaned lesznek- , manuálisan kell őket regisztrálni
- out of date linked clone-ok
Verdict
Mindkettőt javaslom használni, egészen egyszerűen azért mert két formátumban, két helyen is eltároljuk a működő konfigurációt és mint tudjuk, az egy példányban létező adat az nem adat. Egy esetben nem lehet/szabad image based mentést végezni és az a vCenter HA – VCHA. Az ilyen rendszerben a snapshot készítése a vCenter HA – nem a vSphere HA – működésében komoly hibát idézhet elő, így csak a file based – VAMI alapú – mentés támogatott.
És hogy milyen gyakran látok megállt VCSA telepítéseket? Önmaguk, azaz a Photon OS és a rajta futó egyéb szoftverek miatt soha. A hosztok/tároló hibája miatt pedig annál többet.
