Ma a Unity/Unity XT tárolórendszerben megvalósított érdekes technológiáról, a FAST VP-ről lesz szó. Ha először hall a Unity-ról, a cikk végén található linken megismerheti a rendszer jellemzőit. A Dell EMC projektcsapatában több mint egy éve dolgozom a FAST VP-n. Ma szeretném részletesebben bemutatni ezt a technológiát, és felfedni néhány megvalósítási részletet. Természetesen csak azokat, amelyeket megoszthatok. Ha érdekli az adatkezelés hatékonysága, vagy csak nem teljesen biztos a dokumentációban, ez a cikk bizonyára hasznos és érdekes lesz.
Rögtön tisztázom, hogy mi nem lesz a cikkben. Nem fogok versenytársakat keresni és összehasonlítani őket. Szintén nem tervezem, hogy nyílt forráskódú hasonló technológiákról meséljek, hiszen a kíváncsi olvasó amúgy is tud róluk. És természetesen nem tervezek semmit reklámozni.
Tárolási szintezés. A FAST VP céljai és feladatai
A FAST VP a Fully Automated Storage Tiering for Virtual Pool rövidítése. Bonyolultnak tűnik? Semmi baj, mindjárt tisztázom. A szintezés egy adatkezelési módszer, ahol több szint (tier) van, ahol az adatok tárolódnak. Mindegyiknek megvannak a saját jellemzői. A legfontosabbak: teljesítmény, tárolási kapacitás és az információ tárolásának ára. Természetesen ezek között kapcsolat van.
A szintezés fontos jellemzője, hogy az adatokhoz való hozzáférés egységesen történik függetlenül attól, hogy melyik tárolási szinten találhatók éppen, és a tárolómedence mérete a benne lévő erőforrások méreteinek összegével egyenlő. Ebből adódik a különbség a cache és a tárolás között: a cache mérete nem hozzáadódik a teljes erőforrás (jelen esetben a medence) összterjedelméhez, és a cache adatai megismételnek egy adatdarabot az alap média forrásában (vagy megismételnek, ha a cache-ből származó adatok még nincsenek rögzítve). A szintekre való adatmegosztás a felhasználó elől rejtve van. Tehát nem látja, hogy mely adatok találhatók minden szinten, bár közvetetten befolyásolhatja ezt a politikák megadásával (erről később).
Most nézzük meg a tárolási szintézés megvalósításának jellemzőit a Unityben. A Unity három szintet, vagy tier-t különböztet meg:
- Extrém teljesítmény (SSD-k)
- Teljesítmény (SAS HDD 10k/15k RPM)
- Kapacitás (NL-SAS HDD 7200 RPM)
A teljesítmény és ár csökkenő sorrendjében kerülnek bemutatásra. Az Extreme teljesítmény kizárólag SSD meghajtókat tartalmaz. A másik két szintben mágneses lemezek találhatók, amelyek a fordulatszámmal és így a teljesítménnyel különböznek.
Az egy szinten és azonos méretű tárolóeszközök RAID tömbbe vannak összekapcsolva, létrehozva egy RAID csoportot (RAID group, rövidítve RG); a rendelkezésre álló és javasolt RAID szintekről az hivatalos dokumentációban olvashat. A RAID csoportokból egy vagy több szintet tárolási poolok (Storage pool) alkotnak, ahonnan a szabad helyet elosztják. Az tárolási poolból pedig helyet jelölnek ki fájlrendszerek és LUN-ok számára.
Miért van szükségem Tieringre?
Röviden és absztrakt módon: a maximális eredmény elérése, a lehető legkevesebb erőforrással. Konkrétabban, az eredmény alatt általában a tárolórendszer jellemzőinek összességét értjük - sebesség és elérési idő, tárolási költség és egyebek. A legkevesebb erőforrás alatt minimum költségeket értjük: pénz, energia stb. A FAST VP éppen az adatmegosztás mechanizmusait valósítja meg a Unity/Unity XT tárolórendszerek különböző szintjein. Ha nekem hisz, akkor a következő bekezdést átugorhatja. Azoknak, akik nem hisznek, röviden mesélek róla.
Az adatok helyes elosztása a tárolási szintek között lehetővé teszi a tárolórendszer összköltségének csökkentését azzal, hogy feláldozza a hozzáférési sebességet néhány ritkán használt információért, és növeli a teljesítményt, ha a gyakran használt adatokat gyorsabb tárolóra helyezi. Valaki ellenkezhet, hogy a tiering nélkül is a normális adminisztrátor tudja, hova kell helyezni az adatokat, és milyen kívánatos jellemzők illenek a feladataihoz stb. Kétségtelenül így van, de az adatok „kézi” elosztásának megvannak a hátrányai:
- idő és figyelem szükséges az adminisztrátortól;
- nem mindig sikerül az erőforrásokat a megváltozott körülményekhez igazítani;
- elveszik egy fontos előny: a homogenizált hozzáférés az különböző tárolási szinteken lévő erőforrásokhoz.
Annak érdekében, hogy a tárolóadminisztrátorok kevésbé aggódjanak a munkahelyi biztonság miatt, hozzátenném, hogy a megfelelő erőforrás-tervezés itt is elengedhetetlen. Most, hogy a tiering feladatok röviden vázolva vannak, nézzük meg, mit várhatunk a FAST VP-től. Itt az ideje visszatérni a definícióhoz. Az első két szó - Fully Automated - szó szerint „teljesen automatizált”-ra fordítható, ami azt jelenti, hogy a szintek közötti elosztás automatikusan történik. A Virtual Pool pedig azt a tárolási erőforrások egyesített medencéjét jelenti, ahová különböző tárolási szinteken elérhető erőforrások kerülnek. Itt van, hogyan néz ki ez:
Előrehaladva elmondhatom, hogy a FAST VP csak egyetlen medencén belül mozgatja az adatokat, nem több medence között.
A FAST VP által megoldott feladatok
Először beszéljünk absztrakt módon. Van egy medencénk és egy mechanizmusunk, amely képes az adatokat újraosztani ezen a medencén belül. Figyelembe véve, hogy a célunk a maximális teljesítmény elérése, tegyük fel a kérdést: milyen módokon érhetjük el ezt? Több lehetőség is van, és a FAST VP itt többet kínál a felhasználónak, mivel a technológia nem csupán tárolási szintek kezeléséről szól. Íme néhány módszer, ahogyan a FAST VP növelheti a medence teljesítményét:
- Az adatok elosztása különböző típusú meghajtók között, szintek szerint
- Az adatok elosztása egyetlen típusú meghajtó között
- Az adatok elosztása a medence bővítésekor
Mielőtt áttérnénk arra, hogyan oldják meg ezeket a feladatokat, meg kell tudnunk néhány szükséges tényt a FAST VP működéséről. A FAST VP 256 megabájt méretű blokkokkal dolgozik. Ez a minimális folyamatos "darab" adat, amely áthelyezhető. A dokumentációban így nevezik: slice. A FAST VP szempontjából minden RAID-csoport ilyen „darabok” gyűjteményéből áll. Ennek megfelelően minden bemeneti-kimeneti statisztika ezekre a blokkokra vonatkozik. Miért éppen ilyen blokk méretet választottak, és csökkenthető-e? A blokk viszonylag nagy, de egy kompromisszum a rakodás finomságával (minél kisebb a blokk, annál pontosabb az elosztás) és a rendelkezésre álló számítási erőforrásokkal: a meglévő merev korlátok miatt a RAM-ra és a blokkok számának magasra emelkedésével az adatok statisztikái túl soká váltak, és a számítások mennyisége arányosan megnövekedett.
Hogyan helyezi el a FAST VP az adatokat a medencében. Politikai irányelvek
Ahhoz, hogy a FAST VP-vel rendelkező adattároló medence kezelését lebonyolíthassuk, az alábbi politikák állnak rendelkezésre:
- Legmagasabb elérhető szint
- Automatikus szint
- Kezdj magas szinten, majd automatikus szint (alapértelmezett)
- Legalacsonyabb elérhető szint
Ezek befolyásolják mind az inicializáló blokk elhelyezését (amikor először írunk adatokat), mind a későbbi áthelyezést. Ha az adatok már elhelyezésre kerültek a lemezeken, az áthelyezést ütemezés alapján vagy manuálisan indítják.
A legmagasabb elérhető szint megpróbálja a új blokkot a legnagyobb teljesítményű szintre elhelyezni. Ha ez a szint telítve van, akkor a következő legjobbra, de az adatok később áthelyezhetők egy nagyobb teljesítményű szintre (hely rendelkezésre állása esetén, vagy más adatok elmozdításával). Az automatikus szint az új adatokat a rendelkezésre álló hely nagyságától függően különböző szintekre helyezi, míg az áthelyezések a kereslet és a szabad hely függvényében történnek. A kezdd magas szinten, majd automatikus szint – az alapértelmezett politika és a javasolt is. Az inicializálás során úgy működik, mint a legmagasabb elérhető szint, majd az adatok áthelyezése a használati statisztikájuk szerint történik. A legalacsonyabb elérhető szint politika a legkevésbé teljesítményes szintre igyekszik elhelyezni az adatokat.
Az adatok áthelyezése alacsony prioritással történik, hogy ne akadályozza a tárolórendszer hatékony működését, azonban van egy "Adatáthelyezési sebesség" beállítás, amely megváltoztatja a prioritást. Fontos megjegyezni, hogy nem minden adatblokk rendelkezik azonos áthelyezési prioritással. Például, a metadatokként megjelölt blokkokat először a gyorsabb szintre helyezik át. A metadatok olyan, úgynevezett "adatok az adatokkal" információk, amelyek nem felhasználói adatok, de a tárolt adatok leírását tartalmazzák. Például, az információ egy fájlrendszerben arról, hogy melyik blokkban található egy adott fájl. Ez azt jelenti, hogy az adatokhoz való hozzáférés sebessége a metadatokhoz való hozzáférés sebességétől függ. Tekintettel arra, hogy a metadatok általában sokkal kisebb méretűek, az elmozdításuk a nagyobb teljesítményű lemezekre jelentős előnyökkel jár.
A Fast VP által használt kritériumok
A fő kritérium minden blokk számára, ha nagyon leegyszerűsítjük, a „kereslet” jellemzője, amely a blokk olvasási és írási műveleteinek számától függ. Ezt a jellemzőt nálunk „Hőmérsékletnek” hívják. Vannak keresett (hot) adatok, amelyek „forróbbak”, mint a nem keresett adatok. Ezt időszakonként számítjuk, alapértelmezés szerint egy órás időközönként.
A hőmérséklet számításának funkciója a következő tulajdonságokkal rendelkezik:
- Be-/kimenet hiányában az adatok idővel „lehűlnek”.
- Ha az időben közel azonos a terhelés, a hőmérséklet először emelkedik, majd stabilizálódik egy meghatározott tartományban.
Ezt követően figyelembe veszik a fent leírt politikát és a szabad helyet minden szinten. A dokumentációból itt van egy ábra. A piros, sárga és kék színnel a magas, közepes és alacsony hőmérsékletű blokkok vannak jelölve.
De térjünk vissza a feladatokhoz. Tehát neki lehet állni azoknak a feladatoknak a megoldásának, amelyeket a FAST VP teljesít.
A. Az adatok elosztása különböző típusú lemezek között, szintek szerint
Ez valójában a FAST VP fő feladata. A többi, bizonyos értelemben, ebből származik. A választott politikától függően az adatok különböző tárolási szintek között kerülnek elosztásra. Elsősorban a helyezési politika számít, ezt követi a blokkok hőmérséklete és a RAID-csoportok mérete / sebessége.
A Highest / Lowest Available Tier politikák esetében minden eléggé egyszerű. A másik két politikával az a helyzet, hogy az adatok a különböző szinteken a RAID-csoportok mérete és teljesítménye figyelembevételével kerülnek szétosztásra, hogy a blokkok összesített „hőmérséklete” és a RAID-csoportok „feltételezett maximális teljesítménye” közötti arány nagyjából azonos legyen. Így a terhelés többé-kevésbé egyenletesen oszlik meg. A keresett adatok gyors tárolókra, a ritkán használtak pedig lassabbakra kerülnek. Ideális esetben a felosztásnak körülbelül így kell kinéznie:
B. Az adatok elosztása az azonos típusú lemezek között
Ne felejtsd el, hogy az elején írtam, hogy az információs tárolók egy vagy több A szintek egyetlen poolba egyesülnek? Az egyetlen szint esetében a FAST VP-nek is van szerepe. A teljesítmény maximalizálása érdekében célszerű az adatokat egyenletesen elosztani a meghajtók között. Ez lehetővé teszi (elméletileg), hogy maximális számú IOPS-t érjünk el. Az RAID-csoporton belüli adatok egyenletesen oszthatók meg a meghajtók között, míg az RAID-csoportok között ez messze nem mindig van így. Egyensúlyhiány esetén a FAST VP arányosan áthelyezi az adatokat az RAID-csoportok között azok mérete és „feltételezett teljesítménye” (számértékben) alapján. Az áthelyezési sémát a három RAID-csoport között az alábbiakban mutatom be:
B. Az adatok elosztása a pool bővítésekor
Ez a feladat egy különleges esete az előzőnek, és akkor hajtják végre, amikor egy RAID-csoportot adnak hozzá a poolhoz. Annak érdekében, hogy az újonnan hozzáadott RAID-csoport ne álljon üresen, egy rész adatot áthelyeznek rá, ezáltal az összes RAID-csoport terhelése átcsoportosul.
SSD elhasználódás kiegyenlítése
A FAST VP elhasználódás kiegyenlítésével meghosszabbíthatja az SSD élettartamát, bár ez a funkció közvetlenül nem kapcsolódik a Storage Tieringhez. Mivel már rendelkezésre állnak hőmérsékleti adatok és a bejegyzések számát is figyelembe vesszük, valamint a blokkokat is képesek vagyunk áthelyezni, logikus lenne, hogy a FAST VP ezt a feladatot is megoldja.
Abban az esetben, ha az egy RAID-csoportba történő írások száma jelentősen magasabb, mint egy másik RAID-csoportba, a FAST VP az írási műveletek számának megfelelően átcsoportosítja az adatokat. Ez egyrészt csökkenti a terhelést és megőrzi az egyes meghajtók erőforrásait, másrészt „munkát” ad a kevésbé terhelt meghajtóknak, növelve ezzel az összteljesítményt.
Így a FAST VP átvállalja a hagyományos Storage Tiering feladatokat, és még egy kicsit túllép ezen. Mindez lehetővé teszi az adatok hatékony tárolását az Unity sorozatú tárolókban.
Néhány tanács
- Ne hagyja figyelmen kívül a dokumentáció olvasását. Vannak bevált gyakorlatok, és ezek valóban jól működnek. Ha követi őket, akkor komoly problémák általában nem merülnek fel. A többi tanács alapvetően ezek ismétlését vagy kiegészítését jelenti.
- Ha beállította és aktiválta a FAST VP-t, akkor jobb, ha bekapcsolva hagyja. Hadd osztja el az adatokat a számára kijelölt időben és fokozatosan, mint egyszer egy évben, komoly hatással a többi feladat teljesítményére. Ilyen esetekben az adatok áthelyezése hosszú időt vehet igénybe.
- Figyeljen oda a relokációs ablak kiválasztására. Bár nyilvánvaló, próbálja meg a legkisebb terhelésű időszakot választani a Unity számára, és szánjon elegendő időt rá.
- Tervezze meg a tároló bővítését, és tegye ezt időben. Ez egy általános ajánlás, ami a FAST VP számára is fontos. Ha a szabad terület mennyisége nagyon kicsi, az adatok áthelyezése lelassulhat, vagy akár lehetetlenné válhat. Különösen, ha figyelmen kívül hagyta a 2. pontot.
- A FAST VP engedélyezésével bővítéskor nem kell a leglassabb lemezekkel kezdeni. Azaz vagy minden tervezett RAID-csoportot egyidejűleg adunk hozzá, vagy először a leggyorsabb lemezeket. Ebben az esetben az adatok új, „gyors” lemezekre való áthelyezése növeli a tároló általános sebességét. Ellenkező esetben, ha a „lassú” lemezekkel kezdjük, nagyon kellemetlen helyzetet eredményezhet. Először az adatok új, viszonylag lassú lemezekre történő áthelyezése történik, majd, amikor gyorsabbakat adunk hozzá, az ellenkező irányba. Itt vannak részletek, amelyek a FAST VP különböző politikáival kapcsolatosak, de általánosságban hasonló helyzet lehetséges.
Ha érdekli ez a termék, kipróbálhatja a Unity-t ingyenesen a Unity VSA virtuális alkalmazás letöltésével.
A cikk végén megosztok néhány hasznos linket:
- Oldal
- – a funkció rövid leírása
- , pdf formátumban
Zárás
Sok mindenről szeretnék beszélni, de értem, hogy nem minden részlet érdekes az olvasó számára. Például bővebben mesélhetnék azokról a kritériumokról, amelyeket a FAST VP figyelembe vesz az adatok áthelyezéséről, valamint a bemeneti-kimeneti statisztikák elemzési folyamatairól. Az interakció témája a , pedig az egy külön cikket érdemel. Még arról is lehetne fantáziálni, hogy hogyan fejlődhet ez a technológia. Remélem, nem volt unalmas, és nem fárasztottam el magukkal. Viszontlátásra!
Forrás: habr.com
