Täna räägime huvitavast tehnoloogiast, mis on rakendatud Unity/Unity XT salvestusruumis – FAST VP. Kui olete esmakordselt Unity'st kuulnud, siis artikli lõpus olevast lingist leiate süsteemi omadustega tutvumise. Dell EMC projektimeeskonnas töötasin FAST VP kallal üle aasta. Täna tahan rääkida sellest tehnoloogiast lähemalt ja paljastada mõned rakenduse üksikasjad. Muidugi ainult need, mida on lubatud paljastada. Kui teid huvitavad andmete efektiivne salvestamine või te ei ole dokumentatsiooniga täielikult kursis, siis see artikkel on kindlasti kasulik ja huvitav.
Ütlen kohe, mida see materjal ei sisalda. See ei hõlma konkurentide uuringut ega nende võrdlemist. Samuti ei kavatse ma rääkida sarnastest tehnoloogiatest open source'is, sest uudishimulik lugeja teab neist nagunii. Ja muidugi ma ei kavatse midagi reklaamida.
Salvestustasemete jaotamine. FAST VP eesmärgid ja ülesanded
FAST VP tähistab Fully Automated Storage Tiering for Virtual Pool. Kas see on keeruline? Pole midagi, selgitame. Tase (tiering) on andmete salvestamise korraldamise meetod, kus on mitu taset, kuhu need andmed salvestatakse. Igal tasemel on omad omadused. Kõige olulisemad on: jõudlus, maht ja hinna salvestamine ühe infoühiku kohta. Muidugi on nende vahel seos.
Oluline omadus tasemete jaotamisel on see, et andmetele pääseb ligi ühtlaselt, sõltumata sellest, millisel salvestustaseme andmed hetkel paiknevad, ja paagis oleva mahu suurus on võrdne sellesse kuuluvate ressursside summaga. Siin peituvad erinevused vahemälus: vahemälu suurust ei liideta üldisele ressursi mahule (antud juhul paagile), ja vahemälu andmed dubleerivad mingit fragmenti peamisest andmekandjast (või dubleerivad, kui vahemälast andmed pole veel salvestatud). Samuti on andmete jaotamine tasemete vahel kasutajale varjatud. See tähendab, et ta ei näe, millised andmed on igal tasemel, kuigi ta saab sellele kaudselt mõjutada, määrates poliitikaid (millest räägime hiljem).
Nüüd vaatame Unity salvestustasemete rakendamise omadusi. Unity's on määratletud 3 taset ehk tier'i:
- Äärmuslik jõudlus (SSD-d)
- Jõudlus (SAS HDD 10k/15k RPM)
- Mahutus (NL-SAS HDD 7200 RPM)
Need ei ole järjestatud laskuvas järjekorras tootlikkuse ja hinna järgi. Extreme performance hõlmab ainult tahkisettevõtteid (SSD). Kaks teist taset sisaldavad magnetkettaid, mis erinevad pöörlemiskiiruselt ja seega tootlikkuselt.
Ühest tasemest ja ühest suurusest infohoidla elemendid üheskoos moodustavad RAID-massiivi, luues RAID-grupi (RAID group, lühendatult – RG); saadaval ja soovitatavad RAID-tasemed leiate ametlikust dokumentatsioonist. RAID-grupid, mis koosnevad ühest või mitmest tasemest, loovad andmete salvestamise basseinid (Storage pool), millest jagatakse seejärel vaba ruum. Ja siis eraldatakse basseinist ruum failisüsteemide ja LUN-ide jaoks.
Miks mul on tieringut vaja?
Lühidalt ja abstraktselt: et saavutada suuremat tulemust, kasutades minimaalset ressursi. Kui rääkida konkreetselt, siis tulemusena mõistetakse tavaliselt salvestussüsteemi (СХД) omaduste kogumit – kiirus ja ligipääsu aeg, salvestuskulud ja muu. Minimaalsete ressursside all mõistetakse madalaid kulusid: raha, energiat ja nii edasi. FAST VP rakendab just neid mehhanisme andmete ümberjaotamiseks erinevatesse tasemetesse Unity/Unity XT salvestussüsteemis. Kui usute mind, siis võite järgmise lõigu vahele jätta. Muudest räägin veidi põhjalikumalt.
Andmete õige jaotamine salvestustasemetel võimaldab vähendada salvestussüsteemi koguhinda, ohverdades ligipääsukiiruselt harva kasutatavale teabele, ja suurendades tootlikkust, liikudes sagedamini kasutatavate andmete suunas kiirematele hoidladele. Siiski võib keegi väita, et ka ilma tieringuta teab normaalne administraator, kuhu milliseid andmeid paigutada, millised on soovitud СХД omadused tema ülesande jaoks jne. Ilmselt see nii on, kuid andmete „käsi-juhiks” jaotamisel on oma puudused:
- see nõuab administraatori aega ja tähelepanu;
- ei õnnestu alati „kohandada” СХД ressursse muutunud tingimustele;
- kaob oluline eelis: ühtne juurdepääs ressurssidele, mis asuvad erinevates salvestustasemetes.
Ettejuhtivate storage-adminide murede vähendamiseks töökohtade turvalisuse üle lisan, et ressursi planeerimine on siin samuti vajalik. Nüüd, kui tiering'i ülesanded on lühidalt kirjeldatud, vaatame, mida FAST VP-lt oodata. Siin on õige aeg naasta määratluse juurde. Esimesed kaks sõna – Fully Automated – tõlgitakse sõna-sõnalt kui „täiesti automatiseeritud“ ja tähendavad, et taseme jaotamine toimub automaatselt. Virtual Pool on andmebasin, kuhu kuuluvad erinevate salvestustaseme ressurssidest. Nii see välja näeb:
Eelnevalt öeldes ütlen, et FAST VP liigutab andmeid ainult ühe basseini sees, mitte mitme basseini vahel.
FAST VP lahendatavad ülesanded
Alustame abstraktselt. Meil on bassein ja teatud mehhanism, mis suudab andmeid selle basseini sees ümber jaotada. Meeles pidades, et meie eesmärk on saavutada maksimaalset jõudlust, peame küsima: milliseid viise saame selle saavutamiseks kasutada? Viise võib olla mitu, ja siin on FAST VP-l kasutajale midagi pakkuda, kuna tehnoloogia on midagi enamat kui lihtsalt salvestustaseme jaotamine. Teisi viise, kuidas FAST VP võib basseini jõudlust suurendada, on:
- Andmete jaotamine erinevat tüüpi ketaste vahel, tasemed
- Andmete jaotamine sama tüüpi ketaste vahel
- Andmete jaotamine basseini laiendamisel
Enne kui arutame, kuidas need ülesanded lahendatakse, peame teadma mõningaid FAST VP tööks vajalikke fakte. FAST VP tegutseb kindla suurusega plokkidega – 256 megabaiti. See on minimaalne pidev „tükk“ andmeid, mida saab liigutada. Dokumentatsioonis nimetatakse seda slice'iks. FAST VP jaoks koosneb kõik RAID-grupid sellistest „tükikestest“. Vastavalt sellele koguneb kogu sisendi/unjäägi statistika selliste andmeplokkide jaoks. Miks on just selline ploki suurus valitud ja kas seda vähendatakse? Plokk on piisavalt suur, kuid see on kompromiss andmete granulaarsuse (väiksem ploki suurus – täpsem jaotamine) ja olemasolevate arvutusressursside vahel: olemasolevate mälupiirangute ja suure plokiarvu tõttu võivad statistiliste andmete kogumine olla liiga suured ning arvutuste arv suureneb proportsionaalselt.
Kuidas FAST VP paigutab andmeid basseini. Poliitikad
Andmete haldamiseks FAST VP lubatud mahus on olemas järgmised poliitikad:
- Kõrgeim saadaval tase
- Automaatne tasandamine
- Alusta kõrgest ja seejärel automaatne tasandamine (vaikimisi)
- Madalaim saadaval tase
Need mõjutavad nii algset ploki paigutust (andmed kirjutatakse esmakordselt) kui ka edaspidist ümberjaotamist. Kui andmed on juba ketastel paigutatud, algatatakse ümberjaotamine plaanipäraselt või käsitsi.
Kõrgeim saadaval tase püüab paigutada uue ploki kõige tootlikkamale tasemele. Kui seal pole ruumi, siis järgmiseks tootlikumale tasemele, kuid hiljem võivad andmed liikuda võimsamale tasemele (kui ruumi on või teised andmed on välja tõrjutud). Automaatne tasandamine paigutab uued andmed erinevatesse tasemetesse sõltuvalt vabast ruumidest, ja need ümberjaotatakse nõudluse ja vabade kohtade järgi. Alusta kõrgest ja seejärel automaatne tasandamine on vaikimisi poliitika ja samuti soovitatav. Algse paigutuse ajal töötab see nagu Kõrgeim saadaval tase, seejärel toimub andmete liigutamine sõltuvalt nende kasutusstatistikast. Madalaima saadaval oleva taseme poliitika püüdleb andmete paigutamise poole vähem tootlikule tasemele.
Andmete üleviimine toimub madala prioriteediga, et mitte segada SẻHDi kasulikku tööd, kuid siin on seadistus „Andmete üleviimise määr“, mis muudab prioriteedi. Siin on omadus: mitte kõik andmeplokid ei oma sama üleviimise järjekorda. Näiteks plokid, mis on märgitud metadatatena, liiguvad kiiremale tasemele esimesena. Metadatas on, kui nii võib öelda, „andmed andmete kohta“, mingisugune täiendav info, mis ei ole kasutajaandmed, kuid hoiab nende kirjeldust. Näiteks failisüsteemis olev teave, millises plokis konkreetne fail asub. See tähendab, et andmete ligipääsukiirus sõltub metadatade ligipääsukiirusest. Arvestades, et metadatas on tavaliselt palju väiksemad, on oodata, et nende paigutamine tootlikumatele ketastele toob suurema kasu.
Kriteeriumid, mida Fast VP oma toimingutes kasutab
Peamine kriteerium iga ploki jaoks, kui väga laias laastus rääkida, on andmete "nõudlikkuse" omadus, mis sõltub lugemise ja kirjutamise toimingute arvust andmefragmendi kohta. Seda omadust nimetatakse meil "Temperatuuriks". On nõutud (kuumad) andmed, mis on "kuumemad" kui toimetamata. Seda arvutatakse perioodiliselt, vaikimisi ühe tunni järel.
Temperatuuri arvutamise funktsioonil on sellised omadused:
- Ilma sisend-/väljundita andmed aja jooksul "jahtuvad".
- Kui koormus on ajas enam-vähem ühtlane, tõuseb temperatuur esmalt ja stabiliseerub seejärel teatud vahemikus.
Edasi arvesse võetakse ülaltoodud poliitikad ja vaba ruum igal tier'il. Illustratiivsetena toome siin dokumentatsioonist pildi. Siin on punase, kollase ja sinise värviga tähistatud plokid, mille temperatuur on kõrge, keskmine ja madal vastavalt.
Kuid naaseme ülesannete juurde. Seega, võime alustada uurimist, mida tehakse FAST VP ülesannete lahendamiseks.
A. Andmete jaotamine erinevate tüüpi kettaste, tasemete vahel.
Tegelikult on see FAST VP peamine ülesanne. Ülejäänud on mingis mõttes selle tuletatud. Sõltuvalt valitud poliitikast jaotatakse andmed erinevatesse salvestustasemetesse. Esiteks arvesse võetakse paigutuspoliitika, seejärel plokkide temperatuur ja RAID-gruppide suurus/kiirus.
Kõrgeima/madalima saadaval oleva taseme poliitikate puhul on kõik piisavalt lihtne. Ülejäänud kahe puhul on asi selline. Erinevate tasemete vahel jaotatakse andmeid RAID-gruppide suuruse ja jõudluse arvestamisega: nii, et plokkide kogutemperatuuri suhe igas RAID-grupis "tingimuslikku maksimaalset jõudlust" oleks enam-vähem ühesugune. Seega jaotatakse koormus enam-vähem ühtlaselt. Rohkem nõutud andmed liiguvad kiiretele meediatele, harva kasutatavad – aeglasematele. Ideaalis peaks jaotamine välja nägema enam-vähem selline:
B. Andmete jaotamine ühe tüüpi kettaste vahel.
Kas mäletate, et alguses rääkisin, et andmekandjad on üks või mitu Kas tas tähendab, et erinevad tasemed ühendatakse üheks puuks? Ühe taseme puhul on FAST VP tõepoolest tööd. Et ükskõik millise astme jõudlus oleks maksimaalne, on soovitatav andmed võrdselt jaotada kettade vahel. See võimaldab (teoreetiliselt) saavutada maksimaalse IOPS-i arvu. Andmeid RAID-grupis saab pidada võrdselt jaotatuks kettade vahel, kuid RAID-gruppide vahel ei ole see ka kaugeltki alati nii. Tasakaalu puudumise korral liigutab FAST VP andmeid RAID-gruppide vahel proportsionaalselt nende mahule ja „tinglikule jõudlusele“ (numbrilises mõttes). Näitan ilustreerimise jaoks kolmest RAID-grupist koosnevat tasakaalustamise skeemi:
V. Andmete jaotamine puu laiendamisel
See ülesanne on eelneva erijuht ja viiakse ellu, kui puule lisatakse RAID-grupp. Et uus RAID-grupp ei oleks idle, kantakse osa andmetest sellele üle, mistõttu jaotatakse koormus kõigi RAID-gruppide vahel ümber.
SSD kulumise joondamine
FAST VP kulumise joondamise abil võib pikendada SSD eluiga, kuigi see funktsioon ei ole otseselt seotud Storage Tiering'uga. Kuna temperatuuriandmed on juba olemas, arvestatakse ka kirjutamiste operations, ning me oskame andmeplokke liigutada, oleks loogiline, et FAST VP lahendaks ka selle ülesande.
Kui kirjutamiste arv ühte RAID-gruppi ületab oluliselt kirjutamiste arvu teises, siis FAST VP jagab andmed ümber vastavalt kirjutamiste operations arvule. Ühelt poolt vähendab see koormust ja säästab üksikute ketaste ressursse, teisalt lisab see „tööd“ vähem koormatud kettastele, suurendades üldist jõudlust.
Seega võtab FAST VP enda peale traditsioonilised Storage Tiering ülesanded ja teeb veidi rohkemgi. Kõik see võimaldab piisavalt tõhusalt andmeid hoida Unity perekonna SÜS-des.
Mõned soovitused
- Ärge alahindage dokumentatsiooni lugemist. On parimad praktikad ja need toimivad üsna hästi. Juhindudes neist, ei esine tavaliselt tõsiseid probleeme. Ülejäänud soovitused kordavad peamiselt või täiendavad neid.
- Kui olete FAST VP seadistanud ja sisse lülitanud, siis jätke see parem sisse. Laske tal andmeid jaotada ettenähtud aja jooksul järk-järgult, kui et kord aastas, tehes tõsist mõju teistele ülesannetele. Sellistel juhtudel võib andmete ümberjaotamine võtta kaua aega.
- Olge tähelepanelik relokatsiooniaja valimisel. Kuigi see on ilmselge, pange proovige valida aeg, mil Unity koormus on väikseim, ja eraldage piisavalt aega.
- Plaani HDA laiendamine ja tee seda õigel ajal. See on üldine soovitus, mis on oluline ka FAST VP jaoks. Kui vaba ruumi on väga vähe, aeglustub või muutub andmete üleviiimine võimatuks. Eriti kui oled kaheksandat punkti tähelepanuta jätnud.
- FAST VP sisse lülitamisega HDA laiendamisel ei tohiks alustada kõige aeglasematest ketastest. See tähendab, et kas lisame kõik plaanitud RAID-grupid kohe või lisame alguses kõige kiiremad kettad. Sellisel juhul suurendab andmete ümberjaotamine uutest "kiiretest" kettadest kogu HDA kiirus. Vastasel juhul, kui alustate "aeglaste" ketastega, võib olukord osutuda väga ebameeldivaks. Esiteks toimub andmete edasiviimine uutele, suhteliselt aeglastele ketastele, seejärel lisatakse kiiremad kettad tagasi. Siin on nüansse, mis on seotud erinevate FAST VP poliitikatega, kuid üldiselt on sarnane olukord võimalik.
Kui kaalute seda toodet, siis saate Unityt tasuta katsetada, laadides alla Unity VSA virtuaalse seadme.
Kokkuvõtteks jagan mõningaid kasulikke linke:
- Leht
- – funktsiooni lühikirjeldus
- , pdf formaadis
Kokkuvõte
Tahaksin palju kirjutada, kuid ma mõistan, et kõik detailid ei pruugi lugejat huvitada. Näiteks võiksin rohkem selgitada kriteeriume, mille alusel FAST VP teeb otsuseid andmete edasiviimiseks, analüüsides sisendi/väljundi statistikat. Samuti ei ole käsitlemata teema suhtlus , mis vajab eraldi artiklit. Võin isegi spekuleerida selle tehnoloogia arengu teema üle. Loodan, et see ei olnud igav ja ma ei väsitanud teid. Kohtumiseni!
Allikas: habr.com
