Ma a Unity/Unity XT tárolórendszerekben megvalósított érdekes technológiáról fogunk beszélni - FAST VP. Ha most hall először a Unity-ről, akkor a cikk végén található hivatkozás segítségével megtekintheti a rendszer jellemzőit. Több mint egy évig dolgoztam FAST alelnökként a Dell EMC projektcsapatánál. Ma részletesebben szeretnék beszélni erről a technológiáról, és feltárom a megvalósítás néhány részletét. Természetesen csak azokat, amelyeket szabad felfedni. Ha érdekli a hatékony adattárolás kérdése, vagy egyszerűen nem értette meg teljesen a dokumentációt, akkor ez a cikk minden bizonnyal hasznos és érdekes lesz.
Azonnal elmondom, mi nem lesz benne az anyagban. Nem kell versenytársakat keresni és összehasonlítani velük. Nem is tervezek nyílt forráskódú hasonló technológiákról beszélni, mert a kíváncsi olvasó már tud róluk. És persze nem fogok semmit reklámozni.
Tárolási szintek. A FAST VP céljai és célkitűzései
A FAST VP a Fully Automated Storage Tiring for Virtual Pool rövidítése. Kicsit nehéz? Semmi gond, most kitaláljuk. A rétegezés az adattárolás megszervezésének módja, amelyben több szinten (szinten) tárolják ezeket az adatokat. Mindegyiknek megvannak a maga sajátosságai. A legfontosabb: egy egységnyi információ tárolásának teljesítménye, mennyisége és ára. Természetesen van köztük kapcsolat.
A rétegezés fontos jellemzője, hogy az adatokhoz való hozzáférést egységesen biztosítják, függetlenül attól, hogy éppen milyen tárhelyszinten vannak, és a készlet mérete megegyezik a benne foglalt erőforrások méretének összegével. Ebben rejlenek a gyorsítótártól való eltérések: a gyorsítótár méretét nem adják hozzá az erőforrás teljes mennyiségéhez (ebben az esetben a készlethez), és a gyorsítótár adatok megkettőzik a fő médiaadatok egy részét (vagy megkettőződnek, ha a gyorsítótárból még nem írtak adatokat). Ezenkívül az adatok szintek szerinti elosztása rejtve van a felhasználó elől. Vagyis nem látja pontosan, hogy az egyes szinteken milyen adatok helyezkednek el, bár ezt közvetett módon a házirendek meghatározásával tudja befolyásolni (azokról később).
Most nézzük meg a Unity tárolási rétegzésének megvalósításának jellemzőit. Az egységnek 3 szintje vagy szintje van:
- Extrém teljesítmény (SSD)
- Teljesítmény (SAS HDD 10k/15k RPM)
- Kapacitás (NL-SAS HDD 7200 RPM)
A teljesítmény és az ár csökkenő sorrendjében jelennek meg. Az extrém teljesítmény csak a szilárdtestalapú meghajtókat (SSD) foglalja magában. A másik két szint magában foglalja a mágneses lemezmeghajtókat, amelyek különböznek a forgási sebességben és ennek megfelelően a teljesítményben.
Az azonos szintű és azonos méretű tárolóeszközöket RAID-tömbbé egyesítik, így RAID-csoportot alkotnak (RAID-csoport, rövidítve RG); Az elérhető és ajánlott RAID-szintekről a hivatalos dokumentációban olvashat. A tárolókészletek egy vagy több szint RAID-csoportjaiból jönnek létre, amelyekből a szabad terület szétosztásra kerül. A készletből pedig a fájlrendszerek és a LUN-ok számára helyet foglalnak el.
Miért van szükségem Tiringre?
Röviden és elvontan: minimális erőforrás felhasználásával nagyobb eredményeket elérni. Pontosabban, az eredmény általában a tárolási rendszer jellemzőinek összessége - sebesség és hozzáférési idő, tárolási költség és mások. Az erőforrások minimuma a legkisebb ráfordítást jelenti: pénzt, energiát stb. A FAST VP mechanizmusokat valósít meg az adatok különböző szintjei közötti újraelosztására a Unity/Unity XT tárolórendszerekben. Ha hiszel nekem, akkor kihagyhatod a következő bekezdést. A többiről mesélek még egy kicsit.
Az adatok megfelelő elosztása a tárolási szintek között lehetővé teszi, hogy megtakarítsa a tárolás teljes költségét azáltal, hogy feláldozza a hozzáférési sebességet néhány ritkán használt információhoz, és javítja a teljesítményt a gyakran használt adatok gyorsabb adathordozóra való áthelyezésével. Itt valaki azzal érvelhet, hogy a normál rendszergazda rétegezés nélkül is tudja, hogy milyen adatokat hova helyezzen el, mik a feladatához szükséges tárolórendszer kívánatos tulajdonságai stb. Ez kétségtelenül igaz, de az adatok kézi terjesztésének megvannak a maga hátrányai:
- időt és figyelmet igényel az adminisztrátortól;
- A tárolási erőforrásokat nem mindig lehet „átrajzolni” a változó körülményekhez igazodva;
- egy fontos előny eltűnik: egységes hozzáférés a különböző tárolási szinteken található erőforrásokhoz.
Annak érdekében, hogy a tárolási rendszergazdák kevésbé aggódjanak a munka biztonsága miatt, hozzáteszem, hogy itt is szükség van hozzáértő erőforrás-tervezésre. Most, hogy röviden felvázoltuk a rétegezés feladatait, nézzük meg, mire számíthatunk a FAST VP-től. Itt az ideje, hogy visszatérjünk a definícióhoz. Az első két szót – Teljesen automatizált – szó szerint „teljesen automatizáltnak” fordítják, és azt jelenti, hogy a szintek közötti eloszlás automatikusan megtörténik. Nos, a Virtual Pool egy olyan adattár, amely különböző tárolási szintek erőforrásait tartalmazza. Így néz ki:
A jövőre nézve azt mondom, hogy a FAST VP csak egy készleten belül mozgatja az adatokat, több készlet között nem.
A FAST VP megoldotta a problémákat
Először beszéljünk absztrakt módon. Van egy készletünk és néhány mechanizmusunk, amely újraoszthatja az adatokat ezen a készleten belül. Emlékezve arra, hogy célunk a maximális termelékenység elérése, tegyük fel magunknak a kérdést: milyen módszerekkel érhetjük el? Több is lehet belőlük, és itt a FAST VP kínál valamit a felhasználónak, hiszen a technológia több, mint puszta tárolási szint. Íme néhány módszer, amellyel a FAST VP növelheti a medence teljesítményét:
- Adatok elosztása különböző típusú lemezeken, szinteken
- Adatok elosztása az azonos típusú lemezek között
- Adatelosztás a készlet bővítésekor
Mielőtt megvizsgálnánk, hogyan oldják meg ezeket a feladatokat, tudnunk kell néhány szükséges tényt a FAST VP működéséről. A FAST VP bizonyos méretű - 256 megabájtos - blokkokkal működik. Ez a legkisebb összefüggő adatcsomag, amely áthelyezhető. A dokumentációban ezt hívják: szelet. A FAST VP szempontjából minden RAID csoport ilyen „darabokból” áll. Ennek megfelelően az összes I/O statisztika felhalmozódik az ilyen adatblokkokhoz. Miért ezt a blokkméretet választották és csökkenteni fogják? A blokk meglehetősen nagy, de ez kompromisszum az adatok granularitása (kisebb blokkméret pontosabb elosztást jelent) és a rendelkezésre álló számítási erőforrások között: a RAM jelenlegi szigorú korlátai és a blokkok nagy száma miatt előfordulhat, hogy a statisztikai adatok elfoglalnak. túl sok, és ezzel arányosan nő a számítások száma.
Hogyan osztja ki a FAST VP az adatokat a készlethez. Politikusok
Az adatok FAST VP engedélyezett készletben való elhelyezésének szabályozásához a következő házirendek léteznek:
- A legmagasabb elérhető szint
- Auto-Tier
- Start High, majd Auto-Tier (alapértelmezett)
- A legalacsonyabb elérhető szint
Mind a kezdeti blokk-allokációt (az adatok első írása), mind a későbbi újraelosztást érintik. Amikor az adatok már lemezen vannak, az újraelosztás ütemezett vagy manuálisan indul.
Legmagasabb elérhető szint megpróbál egy új blokkot elhelyezni a legjobban teljesítő szintre. Ha nincs rajta elég hely, akkor a következő legproduktívabb szintre kerül, de ekkor az adatok produktívabb szintre helyezhetők (ha van hely, vagy más adatok kiszorításával). Az Auto-Tier a rendelkezésre álló hely mennyiségétől függően különböző szinteken helyezi el az új adatokat, és a kereslet és a szabad hely függvényében újraosztja. A Start High, majd az Auto-Tier az alapértelmezett házirend, és szintén ajánlott. Kezdetben elhelyezve a legmagasabb elérhető szintként működik, majd az adatokat a használati statisztikától függően mozgatják. A legalacsonyabb elérhető szint házirendje arra törekszik, hogy az adatokat a legkevésbé produktív szintre helyezze.
Az adatátvitel alacsony prioritással történik, hogy ne zavarja a tárolórendszer hasznos működését, azonban van egy „Adatáthelyezési sebesség” beállítás, amely megváltoztatja a prioritást. Van itt egy sajátosság: nem minden adatblokknak ugyanaz az újraelosztási sorrendje. Például a metaadatként megjelölt blokkok először gyorsabb szintre kerülnek. A metaadatok úgymond „adatok az adatokról”, néhány további információ, amely nem felhasználói adat, de a leírását tárolja. Például a fájlrendszerben található információk arról, hogy egy adott fájl melyik blokkban található. Ez azt jelenti, hogy az adatokhoz való hozzáférés sebessége a metaadatokhoz való hozzáférés sebességétől függ. Tekintettel arra, hogy a metaadatok általában sokkal kisebb méretűek, a nagyobb teljesítményű lemezekre való áthelyezésből származó előnyök várhatóan nagyobbak.
Kritériumok, amelyeket a Fast VP alkalmaz a munkája során
Az egyes blokkok fő kritériuma, nagyon durván, az adatok „igényének” jellemzője, amely az adattöredék olvasási és írási műveleteinek számától függ. Ezt a jellemzőt „hőmérsékletnek” nevezzük. Vannak igényelt (forró) adatok, amelyek „forróbbak”, mint a nem igényelt adatok. Kiszámítása időszakosan történik, alapértelmezés szerint egyórás időközönként.
A hőmérséklet számítási funkció a következő tulajdonságokkal rendelkezik:
- I/O hiányában az adatok idővel „lehűlnek”.
- Idővel többé-kevésbé egyenlő terhelés mellett a hőmérséklet először emelkedik, majd egy bizonyos tartományban stabilizálódik.
Ezután a fent leírt házirendeket és az egyes szinteken lévő szabad területet veszik figyelembe. Az egyértelműség kedvéért adok egy képet a dokumentációból. Itt a piros, sárga és kék színek magas, közepes és alacsony hőmérsékletű blokkokat jelölnek.
De térjünk vissza a feladatokhoz. Tehát elkezdhetjük elemezni, hogy mi történik a FAST VP problémák megoldása érdekében.
A. Az adatok elosztása különböző típusú lemezeken, szinteken
Valójában ez a FAST VP fő feladata. A többi bizonyos értelemben ennek származéka. A kiválasztott házirendtől függően az adatok különböző tárolási szintek között lesznek elosztva. Először is az elhelyezési szabályzatot veszik figyelembe, majd a blokk hőmérsékletét és a RAID csoportok méretét/sebességét.
A legmagasabb/legalacsonyabb elérhető szint házirendjei esetében minden meglehetősen egyszerű. A másik kettő esetében ez a helyzet. Az adatok különböző szinteken vannak elosztva, figyelembe véve a RAID-csoportok méretét és teljesítményét: így a blokkok teljes „hőmérsékletének” az egyes RAID-csoportok „feltételes maximális teljesítményéhez” viszonyított aránya megközelítőleg azonos. Így a terhelés többé-kevésbé egyenletesen oszlik el. A több keresett adat a gyors adathordozóra, a ritkán használt adat pedig lassabb adathordozóra kerül. Ideális esetben a disztribúciónak valahogy így kell kinéznie:
B. Az adatok elosztása az azonos típusú lemezek között
Ne feledje, az elején írtam, hogy az adathordozót a egy vagy több a szinteket egy medencébe egyesítik? Egy szint esetén a FAST VP-nek is van dolga. A maximális teljesítmény elérése érdekében bármely szinten tanácsos az adatokat egyenletesen elosztani a lemezek között. Ez (elméletileg) lehetővé teszi a maximális mennyiségű IOPS elérését. A RAID-csoporton belüli adatok egyenletesen elosztottnak tekinthetők a lemezek között, de ez nem mindig igaz a RAID-csoportok között. Kiegyensúlyozatlanság esetén a FAST VP a mennyiségükkel és a „feltételes teljesítményükkel” (számszerűen kifejezve) arányosan mozgatja az adatokat a RAID-csoportok között. Az egyértelműség kedvéért bemutatok egy újraegyensúlyozási sémát három RAID-csoport között:
B. Adatelosztás a készlet bővítésekor
Ez a feladat az előző speciális esete, és akkor hajtják végre, amikor egy RAID-csoportot adnak a készlethez. Annak érdekében, hogy az újonnan hozzáadott RAID-csoport ne maradjon tétlen, az adatok egy része átkerül rá, ami azt jelenti, hogy a terhelés újraelosztásra kerül az összes RAID-csoport között.
SSD kopásszint-szabályozás
A kopáskiegyenlítés használatával a FAST VP meghosszabbíthatja az SSD élettartamát, bár ez a funkció nem kapcsolódik közvetlenül a Storage Tiringhez. Mivel a hőmérsékleti adatok már rendelkezésre állnak, az írási műveletek számát is figyelembe veszik, és tudjuk, hogyan kell az adatblokkokat mozgatni, logikus lenne, ha a FAST VP megoldaná ezt a problémát.
Ha az egyik RAID-csoport bejegyzéseinek száma jelentősen meghaladja a másikban lévő bejegyzések számát, a FAST VP újraelosztja az adatokat az írási műveletek számának megfelelően. Ez egyrészt tehermentesíti és megtakarítja egyes lemezek erőforrásait, másrészt „munkát” ad a kevésbé terhelteknek, növelve az általános teljesítményt.
Ily módon a FAST VP megbirkózik a Storage Tiering hagyományos kihívásaival, és ennél valamivel többet tesz. Mindez lehetővé teszi az adatok elég hatékony tárolását a Unity tárolórendszerben.
Néhány tipp
- Ne hagyja figyelmen kívül a dokumentáció elolvasását. Vannak bevált gyakorlatok, és elég jól működnek. Ha követi őket, akkor általában nem merül fel komoly probléma. A tanács többi része alapvetően megismétli vagy kiegészíti ezeket.
- Ha konfigurálta és engedélyezte a FAST VP-t, jobb, ha engedélyezve hagyja. Hagyja, hogy az adatokat a rászabott időben és apránként, mint évente egyszer terjeszthesse, ami komoly hatással van az egyéb feladatok ellátására. Ilyen esetekben az adatok újraelosztása hosszú ideig tarthat.
- Legyen óvatos az áthelyezési ablak kiválasztásakor. Bár ez nyilvánvaló, próbáljon olyan időpontot választani, amikor a Unity a legkevesebb terhelést okozza, és elegendő időt szánjon rá.
- Tervezze meg tárolórendszerének bővítését, tegye meg időben. Ez egy általános ajánlás, amely a FAST VP számára is fontos. Ha a szabad hely nagyon kicsi, akkor az adatmozgás lelassul vagy lehetetlenné válik. Főleg, ha figyelmen kívül hagytad a 2. pontot.
- Ha a FAST VP engedélyezett készletet bővíti, ne a leglassabb lemezekkel kezdje. Vagyis vagy egyszerre adjuk hozzá az összes tervezett RAID-csoportot, vagy először adjuk hozzá a leggyorsabb lemezeket. Ebben az esetben az adatok új „gyors” lemezekre történő újraelosztása növeli a készlet általános sebességét. Ellenkező esetben a „lassú” lemezekkel való kezdés nagyon kellemetlen helyzethez vezethet. Először az adatok új, viszonylag lassú lemezekre kerülnek átvitelre, majd a gyorsabbak hozzáadásakor az ellenkező irányba. Itt vannak árnyalatok a különböző FAST VP szabályzatokkal kapcsolatban, de általában hasonló helyzet lehetséges.
Ha ezt a terméket nézi, ingyenesen kipróbálhatja a Unity-t a Unity VSA virtuális készülék letöltésével.
Az anyag végén megosztok néhány hasznos linket:
- Oldal
- – a funkció rövid leírása
- , pdf formátumban
Következtetés
Sok mindenről szeretnék írni, de megértem, hogy nem minden részlet lesz érdekes az olvasó számára. Például részletesebben beszélhet arról, hogy a FAST VP milyen kritériumok alapján hoz döntéseket az adatátvitelről, az I/O statisztikák elemzésének folyamatairól. Valamint az interakció témája , és ez külön cikket érdemel. Még fantáziálni is lehet ennek a technológiának a fejlődéséről. Remélem nem volt unalmas és nem untatlak benneteket. Viszlát!
Forrás: will.com