előző bejegyzésemben megvitattam azokat az okokat, amelyek miatt a thin provisioning általában a legjobb módja a lemezterület elosztásának a virtuális tárolási forgatókönyvekben. Miért? Mert:
- rugalmasság
- megtakarítás
a thin provisioning segítségével több virtuális Gépet (virtuális gépet) hozhat létre a fizikai merevlemezen anélkül, hogy aggódnia kellene, hogy van-e hely a lefedéshez, mert a hipervizor csak a virtuális gép által használt helyet osztja fel. Ennek eredményeként több tárhelyet vásárolhat, amennyire szüksége van rá, ahelyett, hogy idő előtt kitalálnia kellene az összeget.
de a vékony kiépítésnek megvannak a maga korlátai. Íme a három leggyakoribb hátrány, amellyel eddig találkoztam:
1. Csökkent teljesítmény
számos hozzászólást és szálat olvastam, amelyek vitatják a vékony kiépítésű virtuális gépek és a vastag kiépítésű virtuális gépek közötti teljesítménybeli különbséget. Az általános konszenzus? A Thin provisioning nem nyújt ugyanolyan szintű teljesítményt, mint a thin provisioning. A kiszolgálói Hibaszál tárgyalja annak kockázatát, hogy a vékony kiépítésű lemezek erősen széttöredeznek, ami befolyásolja az általános teljesítményt.
a wazoox kommentelő magyarázata szerint:
ő teljesítmény hit többnyire töredezettség. A meghajtó inicializálásakor az összes blokkja szomszédos…miközben erősen töredezetté válhatnak, ha vékonyak. A “méret figyelése és kiterjesztése” egyszerűen nem történik meg; a ritka fájlok valójában “ingyenes” fájlrendszer-funkciók, és egyszerűen automatikusan növekednek, amikor blokkokat osztanak ki nekik.
de egy friss Spiceworks szálon Scott Alan Miller, Az MSP Niagara Technology Group munkatársa azt mondja, hogy a legtöbb esetben a különbség névleges, és az ezzel kapcsolatos aggodalom a legtöbb kkv számára kontraproduktív:
hacsak nincs késleltetésre érzékeny, Io kötött alkalmazása, a vastag ritkán jó választás. Csak túl sok problémát vagy előnyök hiányát hozza…a probléma az … a kkv-k gondolkodásmódja, az idő nagy részében, a “teljesítmény minden felett”, amikor, a valóságban, a teljesítmény az utolsó dolog, amire a kkv-knak szükségük van. Szükségük van a megbízhatóságra, a könnyű kezelhetőségre, a költségkezelésre stb.
2. Túlzott Helykiosztás
az egyszerűség kedvéért tegyük fel, hogy 1 TB fizikai tárhelye van. Létrehozhat 10 (vagy 100) vékony kiépítésű, egyenként 200 GB-os virtuális gépet, annak ellenére, hogy a fizikai tárhely nem tudta kezelni mindet, ha többségük megközelítette a kapacitását, mivel jelenleg minden virtuális gép darabonként legfeljebb 50 GB-ot használ.
de mi történik, ha nem figyeli az összes különböző virtuális Gépet? Ahogy wazoox mondja,
ha valaha is elfogy a valódi lemezterület a vékony, kiépített tárhelyen, ahol túl kiosztott helyet, bármilyen írás katasztrofális hibát okozhat egy vagy több virtuális gép meghajtón, általában minden javításon túl, ezért jobb, ha gondosan figyelemmel kíséri a tényleges lemezhasználatot a tároló gazdagépen.
ez jogos aggodalom, de az informatikai szakembereknek figyelemmel kell kísérniük ezt a lemezhasználatot, mint az adatközpont legjobb gyakorlatát. A korábban idézett Spiceworks szálban, Darth Hoody kommentelő jobban elmagyarázza, mint én:
az egyetlen ok, hogy ne vékony rendelkezés, ha nem akarja, tudja, hogyan kell, vagy más módon nem tudja, vagy nem fogja ellenőrizni és kezelni a tárhelyet. Igen, ha határozottan problémákat okozhat, ha túlbiztosítja azt a pontot, ahol az adattárolókat a helyből futtatja, és kiüti az összes virtuális Gépet. Lehet, hogy törvényes okai vannak, de számomra ez pazarlás és csak rossz gyakorlat.
3. Rugalmasság hiánya
bár a vékony ellátás lehetővé teszi a lemezterület bővítését, amennyire szüksége van rá, a technológia nem rugalmas. Más szavakkal, kibővítheti a helykiosztást, de nem kötheti össze. A SearchVirtualStorage, a TechTarget kiadvány ezt a problémát a VMware thin provisioning: Pros and cons című bejegyzésében tárgyalja:
a vékony ellátás olyan lemezeket hoz létre, amelyek növekednek, de nem igazán zsugorodnak; nem térnek vissza a teljes szabad medencébe. A VMware esetében, ha létrehoz egy vékony kiépítésű lemezt, az növekedni fog; ha törli az adatokat a lemezről, a VMDK zsugorodik, így több hely áll rendelkezésre az adattárban, de az adattár nem zsugorodik, így nem lesz elérhető a tömb vezérlő számára más célokra — kivéve, ha a tömb vezérlő nulla felismerést végez, amit sok tömb vezérlő, amely vékony kiépítést végez—, és létrehoz egy nullázott vastag vagy egy lelkesen nullázott vastag lemezt. Az ilyen típusú lemezek kiosztják a lemezterületet, és nullákkal töltik meg.
Amikor Steve Snyder és én pár hete beszélgettünk, megállapodtunk abban, hogy a sok hipervizor platform közül az egyik végül valóban rugalmas ellátással fog megjelenni. De egyikünknek sem sikerült konkrét híreket találni erről a fejleményről.