Hová tegyem a VSWP fájlokat – VMware 101

Minden virtuális gép pár fájlban – VVol és VSAN esetén objektumban – reprezentálódik és míg igen sok fájlról pontosan tudjuk miért van ott és mi a dolga, addig van egy aminek elhelyezése és alapvetően a méretével való tervezés, néha kihívások elé állítja a embert.

Mielőtt azonban belemerülnénk a részletekbe, nézzük meg mik ezek a fájlok:

Haladjunk sorban:

  • log: Kiterjesztése magáért beszél, naplózásra használt, méghozzá a VM-et közvetlenül érintő folyamatok és akciók, események esetén.
  • vswp: na itt rögvest két ilyen fájl látható. Az egyik, amelyiknek “vmx” kezdete van, az az ESXi által, a virtuális gép egészének kezelésére felhasznált memória – pl virtual machine monitor (konzol), a virtuális hardver elemei stb. A másik az érdekesebb, az lényegében a virtuális gépnek adott memória méretével egyezik – kivéve ha van reservation.
  • hlog: Ez egy vCenter Server által használt állomány és olyan állományok nyilvántartására használt, amelyek ideiglenesen jönnek létre bizonyos akciók során. Ebben tárolja le ezeket és törli le ha nincs azokra többé szükség.
  • flat-vmdk: Ha nem RDM-et használunk, akkor pontosan ez az a fájl ami reprezentálja a VMDK tartalmát.
  • nvram: a virtuális gép BIOS-ának konfigurációját tartalmazza. Minden amit a BIOS-ban beállítunk, azt itt tárolja le. Ha letöröljük, akkor ez a fájl például a VM bekapcsolásakor létrejön.
  • vmdk: az adatot tartalmazó flat fájl descriptor/leíró állománya. Pointer-t tartalmaz a flat fájlra és egyéb információkat a virtuális disz szektorairól, fejekről és az adapter fajtájáról.
  • vmsd: A snapshot-okról tartalmaz metaadatokat. Akkor is ott van, ha egyébként nincs snapshot.
  • vmx: a virtuális gép konfigurációját leíró fájl és bár nem kifejezetten barátságos, azért kideríthető belőle a részletes kiépítés.

Látható fentebb a vCPU-k száma, a SCSI vezérlő fajtája, a VMDK descriptor-ra való hivatkozás, a hálózati kártya fajtáka, mely hálózathoz csatlakozik, milyen MAC-je van, mi a guest OS. Szeretném felhívni a figyelmet a vm.CreateDate bejegyzésre. Ez egy igen régóta várt dolog és a 6.7-tel jelent meg végre. Amennyiben a vCenter és az ESXi is 6.7-es verzión van, akkor lehet használni. Természetesen csak olyan gépekről tudja mikor hozták létre, amelyeket a 6.7 upgrade után hoztak létre, visszamenőleg nem képes előállítani a dátumot.

Na térjünk vissza a VSWP-re. Miért fontos ez a fájl és miért kell számolni a méretével és még kiemeltebben az elhelyezésével?

Fontos megérteni, hogy ezeket a fájlokat akkor használja az ESXi, mikor fizikai RAM szűkébe kerül. Négy állapot különböztetett meg és azokhoz különböző akciók tartoznak:

Hogyan határozza meg milyen állapotban van éppen? A minfree érték alapján, aminek képlete:

minFree = Az első 28 GB RAM-nál 899 MB + a 28 GB-on felüli rész 1%-a

A fenti példában az EPYC szerverben 128 GB RAM van, így ennél ez 899 MB + 1 GB, azaz 1899 MB. A hoszton is vizsgálható az állapot az ESXtop segítségével:

Méretük csökkenthető ha az adott VM-en reservation-t állítunk be, de én minden esetben, kivétel nélkül ellenzem a reservation használatát. Ha a fenti VM-nek adott 4GB memóriából 1 GB-ot rezerválok, akkor a vswp fájl mérete 1 GB-tal csökken. Ha mind a 4 GB-ot rezerválom akkor a vswp fájl mérete 0-ra csökken. Gyakori hiedelem, hogy ha beállítjuk a rezervációt, akkor azonnal csökken a fáj mérete, holott ez csak akkor történik meg ha kikapcsoljuk a VM-et, majd újra elindítjuk. A reservation hátránya, hogy ha a RAM-ot minden VM-nél dedikáljuk, akkor a hosztban lévő fizikai RAM-ot nem lehet túlfoglalni, szóval igazából oda a virtualizáció egyik legnagyobb előnye. Ezzel szemben nyilvánvalóan spórolhatunk a fizikai tárolónkon, hiszen ha egy nagyobb klaszterről beszélünk (például 8 darab, 1 TB RAM-mal szerelt kiszolgáló), akkor a fizikai RAM mérete 8 TB, amit ha teljesen kihasználunk akkor is minimum ennyi területre van szükség a virtuális gépek virtuális lemezei mellett. Ha túlfoglaljuk, azaz rendeltetésszerűen használjuk az ESXi-t, akkor ez felmehet magasabbra is.

Láthattuk fentebb, hogy a vswp fájlok alapértelmezetten a VM könyvtárában vannak, de ezt módosíthatjuk. Ha a hoszt, egy klaszter tagja, akkor azt klaszter szinten kell beállítani (Configure->General), míg ha standalone, akkor a beállítás a “Configure->Virtual Machines->Swap File Location” alatt van. Kusza, mert klaszter szinten azt tudjuk beállítani, hogy a hoszt szinten megadottat alkalmazza vagy a VM könyvtárban tárolja.

Mikor lehet érdekes, hogy ne a VM könyvtárban legyen a swap?

Például stretched cluster esetén lehet opció. Tehát ha van egy olyan Metro Cluster kiépítésem, ahol a VMware alatt szolgáló tárolók szinkronban replikálják egymás között a datastore-okat jelentő volume-okat. Ekkor ha például a VM-ek normál mozgása elsősorban adatközponton belül értelmezett – manuálisan vagy DRS host és VM szabályokkal – akkor igazából semmi érteme a vswp fájlokat is szinkronizálni. Tehát ha az egyik telephely kiesik, akkor az elérhetetlenné vált telephelyen addig futó virtuális gépeket a VMware HA újraindítja a másik telephelyen, ahhoz meg nincs szükség a swap-ra. Akkor pedig miért is kellene az ilyen “drága” tárterületeken elhelyezni ezeket a fájlokat, mikor amúgy csak akkor használja őket az ESXi, ha RAM limitált állapotba kerül.

Akkor is érdekes lehet, ha a hosztokban van valami tényleg gyors média, például NVMe SSD vagy Optane. Az biztosan gyorsabb lesz ha kevés a RAM és swap-ra van szükség, mint bármilyen SAN-on keresztül elért tároló. Hátránya az, hogy ilyen szűkösebb RAM állapotok mellett a vMotion-nak át kell vinnie a teljes vswp fájlt a VM futásával egy másik hosztra, mivel az nem közös tárolón van ebben az esetben. Ezt egyre kevésbé érzem problémának, mivel ma már nem ritka a 10/25/50 Gbit-es kapcsolat a hosztok között.

Mikor legyen mégis a VM könyvtárában?

Nem véletlenül ez az alapértelmezett, szóval az esetek 99%-ban használjuk ezt, de van pár eset, mikor érdemes kipróbálni a másik opciót. Ha nem probléma a plusz tárterülettel kapcsolatos igény és sokszor kerül valamelyik hoszt RAM constrained állapotba, akkor célravezető a vMotion életét megkönnyíteni azzal, hogy legalább a swap-ot nem kell átmozgatnia.