Nagyon sok helyen használnak SD kártyát, USB kulcsot boot “lemezként” aminek több oka is lehet. Például spórolás, egyszerűsítés, vagy éppen a szerver fizikai helyeinek maximális kihasználása. Ma a legtöbb gyártó már RAID opciókat kínál az integrált SD kártyák megbízhatóságának növelésére, hiszen az SD kártyákat nem folyamatos vagy teljesítmény igényes írási és olvasási műveletek végrehajtására tervezték.
A technológiából kifolyólag több problémával is szembesülhettünk: a kártyák gyakran tönkremennek, elhasználódnak. A tükrözött kártyák sokszor egyszerre mennek tönkre a sok írástól ha a scratch particíó, a logolás vagy a dump írása engedélyezve maradt az eszközre.
Az újonnan megjelenő szolgáltatások mint pl.: Tanzu, NSX-T, vSAN és egyéb komponensek, nem ritkán nagyméretű moduljai igénylik a teljesítményt, rendelkezésre álló helyet és nem utolsó sorban a rugalmasságot és a megbízhatóságot. Megkönnyítve ezen és egyéb gyártói alkalmazások működését, működtetését vagy éppen a hibakeresést a VMware a 7-es verzióban újragondolta a rendszerlemezzel szemben támasztott követelményeket.
A vSphere 7-ben fent említett okok miatt új rendszerlemez kiosztást terveztek. A korábbi verziókban a partíciók száma és mérete fix méretű volt, míg a vSphere 7-ben a méret dinamikusan változhat a rendelkezésre álló terület függvényében.
Rendszerpartíciók
A partíciók kiosztásának összehasonlítása a régi és az új ESXi verzók között:
A fenti ábrán jól látható, hogy a vSphere 6 esetében két partíciót leszámítva mind fix méretű. Ez a két partíció a scratch és a VMFS datastore amelyek abban az esetben kerültek létrehozásra, ha a rendszerlemez nagyobb mint 8,5 GB és nem USB flash drive típusú. A harmadik dinamikusnak jelölt large core-dump, abban az esetben kerül létrehozásra csak, ha a rendszerlemez nagyobb mint 3,4 GB.
Az ESXi 7 négy partíciót tartalmaz:
1, System boot
- Boot loader és EFI modulok
- FAT 16 formátum
2-3, Boot-banks
- Rendszer terület az ESXi boot modulok tárolására (bootbank 0 és 1)
- FAT 16 formátum
4, OSDATA
- Általános tárterület az extra (nem boot) modulok tárolására, rendszerkonfiguráció és állapot és rendszer vm tárolására
- VMFS-L formátum
ESX-OSDATA adattípusok
A vSphere 7-ben bemutatkozó ESX-OSDATA partíció két részre van osztva, mégpedig ROM és RAM adatra. A RAM típusú adatok a gyakran változó, a ROM típusú adatok a ritkán változó adatok.
RAM adatok:
- Log állományok
- Gyakran változó adatállományok
- VMFS global traces
- vSAN EPD
- Mükődő adatbázisok
ROM adatnak minősülő állományok:
- VMtools ISO
- Konfigurációs állományok
- Core dumpok
A korábbi small core-dump, locker, large core-dump és scratch partíciók a vSphere 7 esetén mind az ESX-OSDATA részei lettek.
Az ESX-OSDATA partíciót nagy megbízhatóságú és perzisztens lemezen (HDD vagy SSD) kell létrehozni a megnövekedett számú I/O kérések miatt, amik lehetnek pl.:
- Szervízállapot lekérdezések
- Időzítetett mentő scriptek
- Különbőző funkciók és megoldások tárolhatják a saját állományaikat
ESXi 7 partíciók:
Az 1. ábrán látható, hogy a vSphere 7-ben egyedül a boot partíció fix 100 MB. A többi dinamikusan változik attól függően, hogy ez egy friss telepítés vagy upgrade, és függ a rendelkezésre álló lemez/média méretétől. 128 GB méret felett a VMFS datastore automatikusan létrejön a virtuális gépek adatainak tárolására.
Ha a rendszer (pontosabban a VMFS-L Locker partició) SD kártyára vagy USB eszközre kerül telepítésre, akkor az ESXi-OSDATA partíció a ROM és RAM típusú adatok helyett csak ROM típusú adatokat fog tárolni. A RAM típusú adatok a rendszermemóriában létrehozott RAM diszken kerülnek tárolásra.
Tervezési lehetőségek
A vSphere 7 több különböző típusú diszket/médiát támogat rendszerlemeznek, de egy fontos megkötés van, miszerint nagy teherbírású diszket válasszunk. Ezek lehetnek HDD, SSD, NVMe vagy bootolhatunk SAN-ról is. További javaslatok a legalább 32 GB lemezméret, illetve SAN boot-nál az LUN nem lehet megosztott több ESXi között.
Ha továbbra is SD kártyát szeretnénk használni, az alábbiakat érdemes megfontolni:
- Válasszunk a hardver gyártó által támogatott, magas teherbírású SD kártyákat. (minimum 128 TBW és 100 MB/s IO)
- Szükség lesz egy legalább 32 GB-s VMFS datastore-ra ahova az ESX-OSDATA partíció fog kerülni.
- 128 GB-nál nagyobb SD kártya esetén a rendszer automatikusan létrehoz egy VMFS partíciót, amit törölni kell, hogy megelőzzük az élettartam csökkenést.
- Ha a VMware tools partíció lokálisan jött létre, át kell irányítani RAM diszkre. (LINK)
Követelmények és változások a vSphere 7 Update 3 frissítéssel:
- Szimpla SD kártya használata (kiegészítő tárterület nélkül az ESX-OSDATA számára) nem javasolt, illetve a következő nagyobb frissítés után nem lesz támogatott.
- A közeljövőben az egyetlen támogatott megoldás a legalább 8 GB méretű SD kártya kiegészítve lokálisan csatolt merevlemezzel
- Válasszunk a hardver gyártó által támogatott, magas teherbírású SD kártyákat. (minimum 1 TBW)
- Szükség lesz egy legalább 32 GB-s VMFS datastore-ra ahova az ESX-OSDATA partíció fog kerülni.
- 128 GB-nál nagyobb SD kártya esetén a rendszer automatikusan létrehoz egy VMFS partíciót, amit törölni kell hogy megelőzzük az élettartam csökkenést.
- A VMware tools partíciót át kell irányítani RAM diszkre. (LINK)
- A scratch partíciót szintén perzisztens (SSD, HDD, NVMe stb..) diszkre kell irányítani. VMware nem támogatja a /scratch partíciót SD/USB médián (LINK)
- Ha nincs elérhető perzisztens tároló a /tmp partíció a memóriából lefoglalt RAM diszken kerül elhelyezésre. Ennek használata és esetleges betelése hatással lehet az ESXi host teljesítményére.
- A core dump hálózati lokációra kerüljön átirányításra (LINK)
- Dupla SD kártya használata sem megbízható. Ahogy említettem általában egyszerre mennek tönkre, vagy a tükrözés miatt az egyik kártya meghibásodása a másik kártya működésképtelenségét is okozhatja.
- Ha az ESXI host már frissítve lett 7-es verzióra, akkor az autoPartition=True beállítás az ESX-OSData partíciót átmozgatja egy lokálisan csatolt lemezre a következő indulásnál (LINK)
Konklúzió
Ahogy látszik: a VMware egyre kevésbé támogatja már most, a jövőben pedig egyáltalán nem fogja az SD kártyák használatát. Jelenleg még ugyan használhatóak fizikai diszk kiegészítéssel és az I/O műveletek csökkentésével, de ha a rendszereink SD kártyáról indulnak érdemes már tervezni az átállást.