VMDK összehasonlítás Vastag ellátás Lusta és nulla, Vékony gondoskodás WindowsPro

Ha új virtuális merevlemezt hoz létre a VMware ESXi alatt, három különböző változat közül választhat. Az első pillantásra úgy néz ki, mint a vékony és a vastag ellátás közötti döntés, sokkal bonyolultabbá válik, amikor a megosztott tároló játékra kerül.

összehasonlítás

A virtuális környezetekben történő tárhely biztosításakor az az alapvető gond, hogy az alkalmazások csak annyi tárhelyet használhassanak fel, amennyire valójában szükségük van. Eltérések merülhetnek fel például akkor, ha a szoftver bizonyos mennyiségű lemezterületre számít a telepítéskor, de működés közben kevesebbel is megúszik.

Vékony ellátás a hipervizoron keresztül

Úgy tűnik, hogy a probléma nyilvánvaló válasza a vékony rendelkezésű VMDK. Létrehozáskor nem foglalnak le egy tárhelyet, hanem nőnek az adatok azon mennyiségével, amelyet a vendég operációs rendszer tárol bennük. Valójában érdekes lehetőségek azokon a tárolórendszereken, amelyek maguk nem kínálnak vékony kiépítést, például helyi vagy helyi lemezeket.

Az ilyen típusú VMDK hátránya, hogy folyamatosan figyelnie kell a tárolókapacitásokat, hogy az erőforrások túlfoglalása ne vezetjen teljes lemezekhez és az ebből eredő szűk keresztmetszetekhez. Ezenkívül az ilyen VMDK-k teljesítménye valamivel rosszabb, mint a vastag változatoké.

Lean memóriaallokáció a háttértár segítségével

Ha tároló tömböket használ, akkor használhatja a lean memória allokáció lehetőségét LUN szinten. A vékony kiépítés nem csak az egyes VMDK-kat, hanem a teljes ESXi adattárolókat is érinti. Pusztán technikai szempontból a Thin Provision típusú VMDK-k is létrehozhatók, de nincs sok értelme a kezelési erőfeszítések kétszeresét elfogadni nyilvánvaló előnyök nélkül.

Ha a vékony kiépítést átviszi a tároló háttérbe, akkor általában a vastag rendelkezés lusta nullázott típusú VMDK-kat használják. Bár az összes tárhelyet lefoglalják a VMFS-köteteken, ugyanúgy viselkednek, mint a vékony VMDK-k a sovány tárhely-elosztással rendelkező tárolótömbökön, mert csak akkor használják ott a blokkokat, amikor a vendégrendszer adatokat tárol.

A vastag ellátás alig várja a legjobb teljesítményt

Másrészről a vastag rendelkezés utáni nullázott típusú virtuális meghajtók önmagukban nem alkalmasak vékony kiépítésre, mert nem csak lefoglalják a számukra szánt lemezterületet létrehozásukkor, hanem az összes blokkot nullával írják felül. Ha ezt a folyamatot egy VAAI paranccsal lehet a tömbhöz kiszervezni, akkor a rendelkezésnek aligha kell tovább tartania, mint lusta nullázás esetén. De ez a VMDK utólag a legjobb teljesítményt nyújtja.

Tiszta kapcsolatok az egyszerű tárolórendszereken

Azon tárolórendszereken, amelyek maguk nem képesek vékony lemezeket befogadni, a VMDK beállításai viszonylag egyértelműek. A vékony kiépítést csak a hipervizoron keresztül lehet elvégezni, és vastag kiépítés esetén fontos megfontolni, hogy a rövidebb (lusta-nulla) létesítési idő részesül-e előnyben a kissé jobb teljesítményért (mohón nulla).

Holttér helyreállítási probléma

Az olyan adattárolók vékony kiépítésére alkalmas tároló tömbökön a tárolórendszerek gyártói általában vastag, lusta-nulla típusú VMDK-k használatát javasolják.

Ezzel a konstellációval azonban problémát jelentett az úgynevezett Dead Space Reclamation az vSphere 5-ig, mert a tárolási rendszert nem tájékoztatták, ha például egy VMDK-t a Storage vMotion segítségével más rendszerbe költöztettek, és ezért már nem volt rá szükség. Ezért nem tudta felszabadítani a VMDK által elfoglalt helyet.