Täna räägime huvitavast tehnoloogiast, mis on rakendatud Unity/Unity XT andmemäludes – FAST VP. Kui te olete Unityga esmakordselt kokku puutunud, saate süsteemi omadustega tutvuda artikli lõpus oleva lingi kaudu. Olen Dell EMC projekti meeskonnas töötanud üle aasta FAST VP kallal. Täna tahan rääkida sellest tehnoloogiast lähemalt ja avalikustada mõned selle rakendamise detailid. Loomulikult ainult need, mida on lubatud jagada. Kui teid huvitavad tõhusad andmete salvestamise küsimused või kui te pole dokumentatsiooniga täielikult tuttav, siis see artikkel on kindlasti kasulik ja huvitav.
Ütlen kohe ära, mida selles materjalis ei ole. Ei ole konkurentide otsimist ega nende võrdlemist. Samuti ei kavatse ma rääkida sarnastest tehnoloogiatest open source valdkonnast, kuna uudishimulikel lugejatel on neist niikuinii teadlikkus. Ja loomulikult ei plaani ma midagi reklaamida.
Salvestuse kihistamine. FAST VP eesmärgid ja ülesanded
FAST VP tähistab Fully Automated Storage Tiering for Virtual Pool. Käsitletav teema võib olla keeruline, kuid kohe saame sellega hakkama. Tiering on andmete salvestamise korraldamise meetod, kus andmed paiknevad mitmel tasemel. Igal tasemel on oma omadused, sealhulgas jõudlus, maht ja iga üksuse salvestamise hind. Loomulikult on nende omavaheline seos.
Tieringu oluline omadus on see, et juurdepääs andmetele on ühtne, sõltumata sellest, millisel salvestustasemel need parasjagu asuvad, ja kogumahu suurus on võrdselt ressursside, mis sinna kuuluvad, summaga. Siin peituvad erinevused vahemälus: vahemälu suurust ei liideta üldise ressursi kogumahuga (antud juhul ülesande puu), ja vahemälu andmed peegeldavad mingit fragmenti peamisest salvestusmediast (või peegeldavad neid, kui vahemälu andmeid veel ei salvestata). Samuti on andmete jaotamine tasemete vahel kasutaja eest varjatud. See tähendab, et ta ei näe, millised konkreetsed andmed igal tasemel asuvad, kuigi saab sellele kaudselt mõju avaldada, seadistades poliitikaid (sellest räägime hiljem).
Vaatame nüüd storage tiering omadusi Unity's. Unitys eristatakse 3 taset ehk tieri:
- Äärmuslik jõudlus (SSD-d)
- Jõudlus (SAS HDD 10k/15k RPM)
- Mahutavus (NL-SAS HDD 7200 RPM)
Need on järjestatud vastavalt jõudlusele ja hinnale. Äärmusliku jõudluse alla kuuluvad ainult pooljuhtmälu seadmed (SSD). Kahel teisel tier'il on magnetkettad, mis erinevad pöörlemise kiirusest ja seega ka jõudlusest.
Ühest tasemest ja sama suurusega andmehoidjad kogutakse RAID-massiiviks, moodustades RAID-grupi (RAID group, lühendatult – RG); saadaval ja soovitatavad RAID-tasemed on kirjas ametlikus dokumentatsioonis. RAID-gruppidest ühe või mitme taseme põhjal moodustatakse andmete talletamise basseinid (Storage pool), millest jaotatakse hiljem vabade kohtade. Ning basseinist eraldatakse koht failisüsteemide ja LUN-ide jaoks.
Aga miks on mulle Tiering vajalik?
Kokkuvõttes ja abstraktselt: et saavutada paremaid tulemusi, kasutades vähem ressursse. Konkreetsemalt mõistetakse tulemuse all tavaliselt salvestussüsteemi omaduste kogumit – kiirus ja ligipääsu aeg, salvestamise ning muude kulude hind. Minimaalsete ressursside all peetakse silmas vähimaid kulutusi: raha, energiat jne. FAST VP реализует just andmete jaotamise mehhanisme erinevate tasemete vahel Unity/Unity XT salvestussüsteemis. Kui te mulle usute, siis võite järgmise lõike vahele jätta. Ülejäänutele selgitan lähemalt.
Õige andmete jagamine salvestustasandite vahel võimaldab vähendada salvestussüsteemi kogukulu, ohverdades ligipääsukiirus harva kasutatavatele andmetele, ja tõsta efektiivsust, liigutades sageli kasutatavad andmed kiirematele seadmetele. Siinkohal võib keegi väita, et isegi ilma tiering'ita teab normaalne administraator, kuhu millised andmed paigutada, millised salvestussüsteemi omadused on tema ülesande jaoks soovitatavad jne. Kahtlemata on see tõsi, kuid andmete käsitsi jaotamisel on oma puudused:
- nõuab administraatori aega ja tähelepanu;
- ei pruugi alati õnnestuda salvestussüsteemi ressursse kohandada muutunud tingimuste järgi;
- kaob oluline eelis: ühtne juurdepääs ressursidele, mis asuvad erinevatel salvestustasemetel.
Et storage-adminid vähem muretseksid töökindluse pärast, lisaksin, et ressursiplaneerimine on siin samuti vajalik. Nüüd, kui tiering'u ülesandeid on lühidalt käsitletud, vaatame, mida FAST VP-lt oodata. Siin on aeg tagasi pöörduda määratlemise juurde. Esimesed kaks sõna – Fully Automated – tõlgitakse sõna-sõnalt kui "täiesti automatiseeritud", mis tähendab, et tasemete jagamine toimub automaatselt. Virtual Pool on aga andmepank, mis sisaldab ressursse erinevatelt salvestustasemetelt. Nii see välja näeb:
Eelnevalt öeldes, FAST VP liigutab andmeid ainult ühe panga sees, mitte mitme pangaga vahel.
Ülesanded, mida FAST VP lahendab
Alustame abstraktselt. Meil on bassein ja mingi mehhanism, mis suudab andmeid selle sise ümber jaotada. Pea meeles, et meie ülesanne on saavutada maksimaalne jõudlus, seega küsime, milliseid viise saavutamiseks on olemas? Nende võimalusi võib olla mitmeid ja siin on FAST VP-l kasutajale midagi pakkuda, kuna tehnoloogia esindab enamat kui lihtsalt salvestustaseme jagamine. Siin on viisid, kuidas FAST VP võib basseinide jõudlust suurendada:
- Andmete jaotamine erinevate ketastüübi ja tasemete vahel
- Andmete jaotamine ühe tüüpi ketaste vahel
- Andmete jaotamine basseinide laiendamisel
Enne kui arutame, kuidas neid ülesandeid lahendatakse, peame teadma mõningaid olulisi fakte FAST VP töö kohta. FAST VP töötab kindla suurusega blokikeste – 256 megabaiti. See on minimaalne pidev "andmepalake", mida saab liigutada. Dokumentatsioonis nimetatakse seda just nii: slice. FAST VP vaatenurgast koosnevad kõik RAID-grupid sellistest "palakestest". Vastavalt sellele koguneb kogu sisendi- ja väljundi statistika nende andmepalake tegemiseks. Miks on valitud just selline blokisuurus ja kas seda vähendatakse? Blokisuurus on küllalt suur, kuid see on kompromiss andmete granulaarsuse (väiksem blokisuurus – täpsem jaotamine) ja olemasolevate arvutusressursside vahel: olemasolevate mälupiirangute ja suurte blokihulkade tõttu võivad statistikaandmed võtta liiga palju ruumi ja arvutuste arv kasvab proportsionaalselt.
Kuidas FAST VP paigutab andmeid basseinides. Poliitikad
Andmete paigutamise haldamiseks basseinis, kus on ühendatud FAST VP, kehtivad järgmised poliitikad:
- Kõrgeim saadaval tase
- Automaatne tasandamine
- Alusta kõrgest, seejärel automaatne tasandamine (vaikimisi)
- Madalaim saadaval tase
Need to look at both the initial block placement (when data is first recorded) and subsequent redistribution. Once the data is placed on the disks, redistribution will be initiated either on a schedule or manually.
Highest Available Tier attempts to place a new block at the highest-performing level. If there is not enough space, it moves to the next performance level, but later, the data can be moved to a higher-performance level (if space allows or by displacing other data). Auto-Tier places new data at various levels depending on available space size, while redistribution is based on demand and free space. Start High then Auto-Tier is the default and also recommended policy. Initially, it works like Highest Available Tier, and subsequently, data is moved according to their usage statistics. The Lowest Available Tier policy aims to place data at the least-performing level.
Andmete ülekandmine toimub madala prioriteediga, et mitte segada SAN-i tõhusat toimimist, kuid on olemas seadistus „Andmete ümberpaigutamise kiirus”, mis muudab prioriteedi. Siin on eripära: mitte kõik andmepaketid ei oma sama järjekorda ümberjaotamisel. Näiteks andmepaketid, mis on märgistatud metaandmetena, liiguvad esmalt kiiremale tasemele. Metaandmed on, kui nii võib öelda, „andmed andmete kohta”, täiendav teave, mis ei ole kasutajaandmed, vaid sisaldab nende kirjeldust. Näiteks teave failisüsteemis, millises plokis seesama fail asub. See tähendab, et juurdepääsu kiirus andmetele sõltub metaandmete juurdepääsu kiirusest. Arvestades, et metaandmed on tavaliselt palju väiksema suurusega, oodatakse nende liigutamisest kõrgema jõudlusega kettasektoritesse rohkem kasu.
Kriteeriumid, mida Fast VP oma töös kasutab
Iga ploki peamine kriteerium, väga lihtsustatult öeldes, on andmete „nõudluse” omadus, mis sõltub andmefragmendi lugemis- ja kirjutamistegevuse arvust. Meil nimetatakse seda omaduseks „Temperatuur”. On nõutud (hot) andmeid, mis on „kuumemad” kui mittetootlikud. See arvutatakse perioodiliselt, vaikimisi ühe tunni intervalliga.
Temperatuuri arvutamise funktsioonil on järgmised omadused:
- Ilma sisend- ja väljundita andmed aja jooksul „jahenevad”.
- Aja jooksul ühtlase koormuse korral temperatuur alguses tõuseb ja seejärel stabiliseerub teatud vahemikus.
Edasi arvestatakse ülaltoodud poliitikaid ja vaba ruumi igal tier'il. Selguse huvides tooge välja pilt dokumentatsioonist. Siin on punase, kollase ja sinisega märgitud kõrge, keskmise ja madala temperatuuriga plokid vastavalt.
Aga naaseme ülesannete juurde. Nii et saame alustada selle lahendamiseks vajalike tegevuste analüüsi FAST VP.
A. Andmete jaotamine erinevate ketaste, tasemete vahel.
FAST VP põhiülesanne on täpselt see. Ülejäänud, mingil määral, on sellest tulenevad. Sõltuvalt valitud poliitikast jaotatakse andmed erinevatele salvestustasanditele. Esmalt arvestatakse paigutuspoliitikaga, seejärel blokki temperatuuri ja RAID-gruppide suuruse/kiirus.
Kõrgeima/ madalaima saadavaloleku taseme poliitikate puhul on kõik piisavalt lihtne. Muudel kahe puhul on asi nii: erinevatel tasanditel jaotatakse andmed arvesse võttes RAID-gruppide suurust ja jõudlust, et summateeritud blokkide 'temperatuuri' suhe iga RAID-grupi 'tingimusliku maksimaalse jõudlusega' oleks enam-vähem sama. Niisiis jaotatakse koormus enam-vähem ühtlaselt. Rohkem nõutavad andmed liigutatakse kiiretele kandjatele, harva kasutatavad aga aeglasematele. Ideaalses jaotuses peaks see välja nägema umbes selline:
B. Andmete jaotamine sama tüüpi ketaste vahel
Pidage meeles, et alguses kirjutasin, et teabe kandjad on ühest või mitmest kihi kombineeritakse ühte basse? Ühe tasandi puhul on FAST VP-l samuti olemas töö. Selleks, et mistahes tasandi jõudlus oleks maksimaalne, on soovitatav andmed ühtlaselt ketaste vahel jaotada. See võimaldab (teoreetiliselt) saavutada maksimaalse IOPS-i arvu. Andmeid RAID-grupis võib pidada ühtlaselt jaotatuks ketaste vahel, kuid RAID-gruppide vahel ei ole see sugugi alati nii. Üksikute tulemuste osas liikleb FAST VP andmeid RAID-gruppide vahel kooskõlas nende mahu ja „tinglikku jõudlust“ (numbriliselt). Selguse huvides demonstreerin pärast kolmest RAID-grupist koosnevat ümberjagamisskeemi:
K. Andmete jaotamine basse laiendamisel
See ülesanne on eelneva erijuht ja seda täidetakse siis, kui basse lisatakse RAID-grupi. Selleks, et uus RAID-grupp ei jääks ootama, kantakse sellele üle osa andmeid, mis omakorda tähendab, et koormus kõigile RAID-groupidele jaotatakse ümber.
SSD kulumise tasandamine
FAST VP suudab pikendada SSD eluiga, kuigi see funktsioon ei ole otseselt seotud salvestustasemete haldamisega. Kuna temperatuuriteave on juba olemas ning kirjutamistegevust arvestatakse samuti, siis on andmeblokid meie ülesanne teisaldada. Seega oleks mõistlik, et FAST VP lahendab ka selle ülesande.
Kui ühe RAID-grupi kirjutamisaktiivsuse maht on oluliselt suurem kui teisel, siis FAST VP jaotab andmed ümber vastavalt kirjutamistegevusele. Ühelt poolt vähendab see koormust ja säästab teatud ketaste eluea, kuid samas suurendab see "tööd" vähem koormatud kettaste jaoks, tõstes üldist sooritusvõimet.
Seega võtab FAST VP enda peale traditsioonilised salvestustasemete haldamise ülesanded ja teeb veel natuke rohkem. See kõik võimaldab efektiivselt andmeid salvestada Unity perekonna salvestussüsteemides.
Mõned näpunäited
- Ärge alahinnake dokumentatsiooni lugemist. On olemas parimad praktikud, ja need toimivad väga hästi. Nende järgimine aitab vältida tõsiseid probleeme. Ülejäänud näpunäited kordavad või täiendavad peamiselt neid.
- Kui olete FAST VP seadistanud ja sisselülitanud, jätke see parem sisse. Las see jaotab andmeid talle ettenähtud ajal tasakesi, mitte kord aastas, avaldades tõsist mõju teistele ülesannetele. Sellistes olukordades võib andmete ümberjaotamine võtta kaua aega.
- Olge reaalokatsioonikava valimisega ettevaatlik. Kuigi see tundub ilmne, püüdke valida aeg, mil Unityl on kõige vähem koormust, ja eraldage piisavalt aega.
- Planeerige andmesalvestuse laiendust ja tehke seda õigeaegselt. See on üldine soovitus, mis on oluline ka FAST VP jaoks. Kui vabade ruumide maht on väga väike, aeglustub andmete liikumine või muutub see võimatuks. Eriti kui olete punkti 2 tähelepanuta jätnud.
- FAST VP rakendamisel ei tohiks alustada aeglastest kettadest. Tähendab, et kas lisame kõik planeeritud RAID-grupid kohe või alustame kiiremate ketastega. Sellisel juhul tõstab uute "kiirete" ketastele andmete üleviimine kogu puhangu kiirus. Vastupidiselt, kui alustada "aeglastest" ketastest, võib tekkida väga ebameeldiv olukord. Esmalt toimub andmete üleviimine uutele, suhteliselt aeglastele hetkedele, ja hiljem, kiiremate lisamisel, vastupidises suunas. Siin on nüansid, mis on seotud erinevate FAST VP poliitikatega, kuid üldiselt on selline olukord võimalik.
Kui te vaatate seda toodet, siis saab Unity't tasuta proovida, laadides alla Unity VSA virtuaalse seadme.
Lõpetuseks jagan mitmeid kasulikke linke:
- Lehekülg
- – funktsiooni lühike kirjeldus
- , pdf formaadis
Kokkuvõte
Tahaksin rääkida paljusid asju, kuid mõistan, et kõik detailsed detailid ei pruugi lugejat huvitada. Näiteks võiks täpsemalt rääkida kriteeriumidest, mille alusel FAST VP otsustab andmete üleviimise, sisendi-väljundi statistika analüüsi protsessidest. Samuti ei ole üldse käsitletud teemat suhtlemisest , mis väärib eraldi artiklit. Võib isegi natuke fantaseerida, kuidas see tehnoloogia areneda võiks. Loodan, et see ei olnud igav ja et ma teid ei väsitanud. Kohtumiseni!
Allikas: habr.com
