Tänään puhumme mielenkiintoisesta tekniikasta, joka on toteutettu Unity/Unity XT -tallennusjärjestelmissä - FAST VP. Jos tämä on ensimmäinen kerta, kun kuulet Unitysta, voit tarkistaa järjestelmän ominaisuudet artikkelin lopussa olevan linkin avulla. Työskentelin Dell EMC -projektitiimin FAST VP:nä yli vuoden ajan. Tänään haluan puhua tästä tekniikasta yksityiskohtaisemmin ja paljastaa joitain yksityiskohtia sen toteutuksesta. Tietysti vain ne, jotka saa paljastaa. Jos olet kiinnostunut tehokkaaseen tietojen tallentamiseen liittyvistä kysymyksistä tai et yksinkertaisesti ole täysin ymmärtänyt dokumentaatiota, tämä artikkeli on varmasti hyödyllinen ja mielenkiintoinen.
Kerron sinulle heti, mitä materiaalissa ei ole. Kilpailijoita ei etsitä ja verrata niihin. En myöskään aio puhua vastaavista avoimen lähdekoodin teknologioista, koska utelias lukija tietää niistä jo. Ja tietenkään en aio mainostaa mitään.
Varastoinnin taso. FAST VP:n tavoitteet ja tavoitteet
FAST VP tarkoittaa Fully Automated Storage Tiring for Virtual Pool. Hieman vaikeaa? Ei hätää, selvitämme sen nyt. Tasoitus on tapa järjestää tietojen tallennus, jossa on useita tasoja (tasoja), joille nämä tiedot tallennetaan. Jokaisella on omat ominaisuutensa. Tärkeimmät: tietoyksikön tallennusteho, määrä ja hinta. Tietysti heidän välillään on suhde.
Tärkeä tasoituksen ominaisuus on, että pääsy tietoihin tarjotaan tasaisesti riippumatta tallennustasosta, jolla se sillä hetkellä sijaitsee, ja poolin koko on yhtä suuri kuin siihen sisältyvien resurssien kokojen summa. Tässä ovat erot välimuistista: välimuistin kokoa ei lisätä resurssin kokonaismäärään (tässä tapauksessa pooliin), ja välimuistitiedot kopioivat osan päämediatiedoista (tai kopioivat, jos tietoja välimuistista ei ole vielä kirjoitettu). Myös tietojen jakautuminen tasoittain on piilotettu käyttäjältä. Toisin sanoen hän ei näe tarkalleen, mitä dataa kullakin tasolla sijaitsee, vaikka hän voi vaikuttaa tähän epäsuorasti asettamalla käytäntöjä (niistä lisää myöhemmin).
Katsotaanpa nyt Unityn tallennustason toteutuksen ominaisuuksia. Unityssa on 3 tasoa tai tasoa:
- Äärimmäinen suorituskyky (SSD-levyt)
- Suorituskyky (SAS HDD 10k/15k RPM)
- Kapasiteetti (NL-SAS HDD 7200 RPM)
Ne on esitetty suorituskyvyn ja hinnan mukaan laskevassa järjestyksessä. Äärimmäinen suorituskyky sisältää vain SSD-asemat. Kaksi muuta tasoa sisältävät magneettiset levyasemat, jotka eroavat pyörimisnopeudesta ja vastaavasti suorituskyvystä.
Saman tason ja samankokoiset tallennusvälineet yhdistetään RAID-ryhmäksi, jolloin muodostuu RAID-ryhmä (RAID-ryhmä, lyhenne RG); Voit lukea saatavilla olevista ja suositelluista RAID-tasoista virallisesta dokumentaatiosta. Tallennusvarastot muodostetaan yhden tai useamman tason RAID-ryhmistä, joista sitten jaetaan vapaata tilaa. Ja allastilasta on varattu tilaa tiedostojärjestelmille ja LUN:ille.
Miksi tarvitsen tason?
Lyhyesti ja abstraktisti: saavuttaa parempia tuloksia käyttämällä mahdollisimman vähän resursseja. Tarkemmin sanottuna tulos ymmärretään yleensä joukkona tallennusjärjestelmän ominaisuuksia - nopeutta ja pääsyaikaa, tallennuskustannuksia ja muita. Resurssien vähimmäismäärä tarkoittaa vähiten menoja: rahaa, energiaa ja niin edelleen. FAST VP toteuttaa mekanismeja tietojen uudelleenjakamiseksi eri tasoille Unity/Unity XT -tallennusjärjestelmissä. Jos uskot minua, voit ohittaa seuraavan kappaleen. Lopusta kerron vähän enemmän.
Kun tiedot jakautuvat oikein tallennustasojen välillä, voit säästää tallennustilan kokonaiskustannuksissa uhraamalla pääsyn nopeudesta joihinkin harvoin käytettyihin tietoihin ja parantaa suorituskykyä siirtämällä usein käytetyt tiedot nopeampaan mediaan. Tässä joku voisi väittää, että jopa ilman porrastusta normaali järjestelmänvalvoja tietää minne mitkä tiedot sijoittaa, mitkä ovat hänen tehtävänsä kannalta toivottavat tallennusjärjestelmän ominaisuudet jne. Tämä on epäilemättä totta, mutta tietojen manuaalisessa jakamisessa on haittapuolensa:
- vaatii järjestelmänvalvojalta aikaa ja huomiota;
- Tallennusresursseja ei aina ole mahdollista "piirtää uudelleen" muuttuviin olosuhteisiin sopivaksi;
- tärkeä etu katoaa: yhtenäinen pääsy eri tallennustasoilla sijaitseviin resursseihin.
Lisätän, että pätevä resurssien suunnittelu on tarpeen tässäkin, jotta säilytysjärjestelmänvalvojat olisivat vähemmän huolissaan työn turvallisuudesta. Nyt kun porrastuksen tehtävät on hahmoteltu lyhyesti, katsotaanpa, mitä voit odottaa FAST VP:ltä. Nyt on aika palata määritelmään. Kaksi ensimmäistä sanaa – Fully Automated – käännetään kirjaimellisesti "täysin automatisoiduksi" ja tarkoittavat, että tasojen välinen jakautuminen tapahtuu automaattisesti. No, Virtual Pool on tietovarasto, joka sisältää resursseja eri tallennustasoilta. Tältä se näyttää:
Tulevaisuudessa sanon, että FAST VP siirtää tietoja vain yhden poolin sisällä, ei usean poolin välillä.
FAST VP ratkaisi ongelmat
Puhutaanpa ensin abstraktisti. Meillä on pooli ja jokin mekanismi, joka voi jakaa tietoja uudelleen tässä poolissa. Kun muistamme, että tavoitteemme on saavuttaa maksimaalinen tuottavuus, kysytään itseltämme: millä tavoilla voimme saavuttaa sen? Niitä voi olla useita, ja tässä FAST VP:llä on jotain annettavaa käyttäjälle, koska tekniikka on jotain muutakin kuin pelkkä varastointitaso. Tässä on joitain tapoja, joilla FAST VP voi parantaa altaan suorituskykyä:
- Tietojen jakautuminen erityyppisille levyille, tasoille
- Tietojen jakaminen samantyyppisten levyjen kesken
- Tietojen jakelu poolia laajennettaessa
Ennen kuin tarkastelemme, kuinka nämä tehtävät ratkaistaan, meidän on tiedettävä joitain tarpeellisia faktoja siitä, kuinka FAST VP toimii. FAST VP toimii tietyn kokoisilla lohkoilla - 256 megatavua. Tämä on pienin vierekkäinen "osa" dataa, jota voidaan siirtää. Asiakirjoissa tätä kutsutaan nimellä: slice. FAST VP:n näkökulmasta kaikki RAID-ryhmät koostuvat joukosta tällaisia "kappaleita". Vastaavasti kaikki I/O-tilastot kerätään tällaisille tietolohkoille. Miksi tämä lohkokoko valittiin ja pienennetäänkö sitä? Lohko on melko suuri, mutta tämä on kompromissi tiedon tarkkuuden (pienempi lohkokoko tarkoittaa tarkempaa jakautumista) ja käytettävissä olevien laskentaresurssien välillä: RAM-muistin nykyisten tiukkojen rajoitusten ja suuren lohkomäärän vuoksi tilastotiedot voivat viedä liikaa, ja laskelmien määrä kasvaa vastaavasti.
Kuinka FAST VP allokoi tiedot poolille. poliitikot
Seuraavien käytäntöjen avulla voit hallita tietojen sijoittamista pooliin, jossa FAST VP on käytössä:
- Korkein saatavilla oleva taso
- Automaattinen taso
- Aloita korkealta ja sitten automaattinen taso (oletus)
- Alin saatavilla oleva taso
Ne vaikuttavat sekä alkuperäiseen lohkoallokointiin (tiedot kirjoitetaan ensin) että myöhempään uudelleenallokointiin. Kun tiedot ovat jo levyllä, uudelleenjako käynnistetään aikataulun mukaan tai manuaalisesti.
Korkein käytettävissä oleva taso yrittää sijoittaa uuden lohkon tehokkaimmalle tasolle. Jos siinä ei ole tarpeeksi tilaa, se sijoitetaan seuraavaksi tuottavimmalle tasolle, mutta sitten tiedot voidaan siirtää tuottavammalle tasolle (jos tilaa on tai syrjäyttämällä muuta dataa). Auto-Tier sijoittaa uudet tiedot eri tasoille käytettävissä olevan tilan määrän mukaan, ja se jaetaan uudelleen kysynnän ja vapaan tilan mukaan. Aloita korkealta ja sitten Auto-Tier on oletuskäytäntö ja myös suositeltava. Alun perin sijoitettuna se toimii korkeimpana saatavilla olevana tasona, ja sitten tietoja siirretään sen käyttötilastoista riippuen. Alimman käytettävissä olevan tason käytäntö pyrkii sijoittamaan tiedot vähiten tuottavalle tasolle.
Tiedonsiirto tapahtuu alhaisella prioriteetilla, jotta se ei häiritse tallennusjärjestelmän hyödyllistä toimintaa, mutta on olemassa "Data relocation rate" -asetus, joka muuttaa prioriteettia. Tässä on erikoisuus: kaikilla tietolohkoilla ei ole samaa uudelleenjakojärjestystä. Esimerkiksi metatiedoiksi merkityt lohkot siirretään ensin nopeammalle tasolle. Metadata on niin sanotusti "dataa datasta", jotain lisätietoa, joka ei ole käyttäjädataa, vaan tallentaa sen kuvauksen. Esimerkiksi tiedostojärjestelmän tiedot siitä, missä lohkossa tietty tiedosto sijaitsee. Tämä tarkoittaa, että tietojen käyttönopeus riippuu metatietojen pääsyn nopeudesta. Koska metatiedot ovat tyypillisesti paljon pienempiä, niiden siirtämisestä tehokkaampiin levyihin odotetaan olevan suurempia hyötyjä.
Kriteerit, joita Fast VP käyttää työssään
Pääkriteeri kullekin lohkolle, hyvin karkeasti, on datan "kysynnän" ominaisuus, joka riippuu datafragmentin luku- ja kirjoitustoimintojen määrästä. Kutsumme tätä ominaisuutta "lämpötilaksi". On vaadittua (kuumaa) dataa, joka on "kuumempaa" kuin lunastamaton data. Se lasketaan säännöllisesti, oletusarvoisesti tunnin välein.
Lämpötilalaskentatoiminnolla on seuraavat ominaisuudet:
- I/O:n puuttuessa tiedot "jäähtyvät" ajan myötä.
- Enemmän tai vähemmän tasaisella kuormituksella ajan mittaan lämpötila ensin nousee ja sitten vakiintuu tietyllä alueella.
Seuraavaksi otetaan huomioon yllä kuvatut käytännöt ja kunkin tason vapaa tila. Selvyyden vuoksi annan kuvan dokumentaatiosta. Tässä punainen, keltainen ja sininen värit osoittavat lohkoja, joissa on korkea, keskitaso ja matala lämpötila.
Mutta palataanpa tehtäviin. Joten voimme alkaa analysoida, mitä tehdään FAST VP -ongelmien ratkaisemiseksi.
A. Tietojen jakautuminen erityyppisille levyille, tasoille
Itse asiassa tämä on FAST VP:n päätehtävä. Loput ovat tietyssä mielessä sen johdannaisia. Valitusta käytännöstä riippuen tiedot jaetaan eri tallennustasoille. Ensinnäkin huomioidaan sijoittelukäytäntö, sitten lohkon lämpötila ja RAID-ryhmien koko/nopeus.
Korkeimman/matalimman saatavilla olevan tason käytäntöjen osalta kaikki on melko yksinkertaista. Kahden muun kohdalla näin on. Tiedot jaetaan eri tasoille ottaen huomioon RAID-ryhmien koko ja suorituskyky: siten, että lohkojen kokonaislämpötilan suhde kunkin RAID-ryhmän "ehdolliseen maksimitehoon" on suunnilleen sama. Siten kuorma jakautuu enemmän tai vähemmän tasaisesti. Lisää kysyttyä dataa siirretään nopealle medialle ja harvoin käytettyä dataa siirretään hitaampaan mediaan. Ihannetapauksessa jakelun pitäisi näyttää suunnilleen tältä:
B. Tietojen jakaminen samantyyppisten levyjen kesken
Muista, että alussa kirjoitin, että tallennusväline yksi tai useampi yhdistetäänkö tasot yhdeksi altaaksi? Yhden tason tapauksessa myös FAST VP:llä on tehtävää. Parhaan suorituskyvyn saavuttamiseksi millä tahansa tasolla on suositeltavaa jakaa tiedot tasaisesti levyjen välillä. Tämän avulla (teoriassa) voit saada suurimman IOPS-määrän. RAID-ryhmän tietojen voidaan katsoa jakautuneen tasaisesti levyille, mutta näin ei aina ole RAID-ryhmien välillä. Epätasapainon sattuessa FAST VP siirtää tietoja RAID-ryhmien välillä suhteessa niiden kokoon ja "ehdolliseen suorituskykyyn" (numeerisesti). Selvyyden vuoksi näytän tasapainotusjärjestelmän kolmen RAID-ryhmän välillä:
B. Tietojen jakelu poolia laajennettaessa
Tämä tehtävä on edellisen erikoistapaus, ja se suoritetaan, kun RAID-ryhmä lisätään pooliin. Jotta äskettäin lisätty RAID-ryhmä ei jää käyttämättömäksi, osa tiedoista siirretään siihen, mikä tarkoittaa, että kuorma jaetaan uudelleen kaikkien RAID-ryhmien kesken.
SSD:n kulumisen tasoitus
Kulutustasoa käyttämällä FAST VP voi pidentää SSD-levyn käyttöikää, vaikka tämä ominaisuus ei liity suoraan Storage Tiringiin. Koska lämpötilatiedot ovat jo saatavilla, kirjoitusoperaatioiden määrä on myös huomioitu ja tietolohkoja osataan siirtää, olisi loogista, että FAST VP ratkaisee tämän ongelman.
Jos merkintöjen määrä yhdessä RAID-ryhmässä ylittää merkittävästi toisen merkintöjen määrän, FAST VP jakaa tiedot uudelleen kirjoitustoimintojen määrän mukaan. Toisaalta tämä keventää kuormaa ja säästää joidenkin levyjen resursseja, toisaalta se lisää "työtä" vähemmän ladatuille levyille, mikä lisää yleistä suorituskykyä.
Tällä tavalla FAST VP ottaa vastaan Storage Tiringin perinteiset haasteet ja tekee hieman enemmän. Kaikki tämä mahdollistaa tietojen tallentamisen varsin tehokkaasti Unity-tallennusjärjestelmään.
Muutamia vihjeitä
- Älä unohda lukea asiakirjoja. Parhaita käytäntöjä on olemassa, ja ne toimivat melko hyvin. Jos noudatat niitä, vakavia ongelmia ei yleensä synny. Loput neuvoista pohjimmiltaan toistavat tai täydentävät niitä.
- Jos olet määrittänyt ja ottanut käyttöön FAST VP:n, on parempi jättää se käyttöön. Anna sen jakaa dataa sille varattuna aikana ja pikkuhiljaa kuin kerran vuodessa ja vaikuttaen vakavasti muiden tehtävien suorittamiseen. Tällaisissa tapauksissa tietojen uudelleenjakaminen voi kestää kauan.
- Ole varovainen valitessasi siirtoikkunaa. Vaikka tämä on ilmeistä, yritä valita aika, jolloin Unitylle on vähiten kuormitusta, ja varata riittävästi aikaa.
- Suunnittele tallennusjärjestelmän laajentamista, tee se ajoissa. Tämä on yleinen suositus, joka on tärkeä myös FAST VP:lle. Jos vapaan tilan määrä on hyvin pieni, tiedonsiirto hidastuu tai muuttuu mahdottomaksi. Varsinkin jos olet laiminlyönyt kohdan 2.
- Kun laajennat poolia FAST VP:n ollessa käytössä, sinun ei pitäisi aloittaa hitaimmilla levyillä. Eli joko lisäämme kaikki suunnitellut RAID-ryhmät kerralla tai lisäämme ensin nopeimmat levyt. Tässä tapauksessa tietojen uudelleenjakaminen uusille "nopeille" levyille lisää poolin yleistä nopeutta. Muuten "hitailla" levyillä aloittaminen voi johtaa erittäin epämiellyttävään tilanteeseen. Ensin tiedot siirretään uusille, suhteellisen hitaille levyille, ja sitten, kun lisätään nopeampia, päinvastaiseen suuntaan. Tässä on vivahteita, jotka liittyvät erilaisiin FAST VP -käytäntöihin, mutta yleisesti ottaen samanlainen tilanne on mahdollinen.
Jos katsot tätä tuotetta, voit kokeilla Unitya ilmaiseksi lataamalla Unity VSA -virtuaalilaitteen.
Materiaalin lopussa jaan useita hyödyllisiä linkkejä:
- Sivu
- – toiminnon lyhyt kuvaus
- , pdf-muodossa
Johtopäätös
Haluaisin kirjoittaa paljon, mutta ymmärrän, että kaikki yksityiskohdat eivät kiinnosta lukijaa. Voit esimerkiksi puhua tarkemmin kriteereistä, joilla FAST VP tekee tiedonsiirtoa koskevia päätöksiä, I/O-tilastojen analysointiprosesseista. Myös vuorovaikutuksen aihe , ja tämä ansaitsee erillisen artikkelin. Voit jopa fantasoida tämän tekniikan kehityksestä. Toivottavasti se ei ollut tylsää, enkä kyllästyttänyt sinua. Nähdään taas!
Lähde: will.com