Hodiaŭ ni parolos pri interesa teknologio efektivigita en stoksistemoj Unity/Unity XT - FAST VP. Se ĉi tio estas la unua fojo, kiam vi aŭdis pri Unity, tiam vi povas kontroli la karakterizaĵojn de la sistemo uzante la ligilon ĉe la fino de la artikolo. Mi laboris pri FAST VP en la projektteamo de Dell EMC dum pli ol unu jaro. Hodiaŭ mi volas paroli pli detale pri ĉi tiu teknologio kaj malkaŝi kelkajn detalojn pri ĝia efektivigo. Kompreneble, nur tiuj, kiuj rajtas esti malkaŝitaj. Se vi interesiĝas pri aferoj de efika konservado de datumoj aŭ simple ne plene komprenis la dokumentadon, tiam ĉi tiu artikolo certe estos utila kaj interesa.
Mi tuj diros al vi, kio ne estos en la materialo. Ne estos serĉado de konkurantoj kaj komparo kun ili. Mi ankaŭ ne planas paroli pri similaj teknologioj el malferma fonto, ĉar la scivolema leganto jam scias pri ili. Kaj, kompreneble, mi nenion reklamos.
Stokado Tiering. Celoj kaj celoj de FAST VP
FAST VP signifas Plene Aŭtomatigita Stokado Tiring por Virtuala Pool. Iom malfacila? Neniu problemo, ni eltrovos ĝin nun. Tiering estas maniero organizi datumstokadon, en kiu ekzistas pluraj niveloj (tavoj), kie ĉi tiuj datumoj estas stokitaj. Ĉiu havas siajn proprajn trajtojn. La plej grava: rendimento, volumo kaj prezo de stokado de unuo de informo. Kompreneble, estas rilato inter ili.
Grava trajto de nivelado estas, ke aliro al datumoj estas provizita unuforme sendepende de la stokada nivelo, ĉe kiu ĝi troviĝas nuntempe, kaj la grandeco de la naĝejo estas egala al la sumo de la grandecoj de la rimedoj inkluditaj en ĝi. Ĉi tie kuŝas la diferencoj de la kaŝmemoro: la grandeco de la kaŝmemoro ne estas aldonita al la totala volumo de la rimedo (naĝejo en ĉi tiu kazo), kaj la kaŝmemoro-datumoj duplikatas iun fragmenton de la ĉefaj amaskomunikilaj datumoj (aŭ duplikos se la datumoj de la kaŝmemoro ankoraŭ ne estas skribitaj). Ankaŭ, la distribuo de datumoj laŭ niveloj estas kaŝita de la uzanto. Tio estas, li ne vidas precize, kiaj datumoj troviĝas ĉe ĉiu nivelo, kvankam li povas influi tion nerekte fiksante politikojn (pli pri ili poste).
Nun ni rigardu la funkciojn de la efektivigo de stokado-nivelado en Unity. Unueco havas 3 nivelojn, aŭ nivelon:
- Ekstrema rendimento (SSDoj)
- Efikeco (SAS HDD 10k/15k RPM)
- Kapacito (NL-SAS HDD 7200 RPM)
Ili estas prezentitaj en malkreskanta ordo de rendimento kaj prezo. Ekstrema rendimento inkluzivas nur solidstatajn diskojn (SSDoj). La aliaj du partoj inkluzivas magnetajn diskojn, kiuj diferencas en rotacia rapideco kaj, sekve, rendimento.
Stokmedioj de la sama nivelo kaj la sama grandeco estas kombinitaj en RAID-tabelon, formante RAID-grupon (RAID-grupo, mallongigita kiel RG); Vi povas legi pri disponeblaj kaj rekomenditaj RAID-niveloj en la oficiala dokumentaro. Stokejoj estas formitaj de RAID-grupoj de unu aŭ pluraj niveloj, de kiuj libera spaco tiam estas distribuita. Kaj de la naĝejo spaco estas asignita por dosiersistemoj kaj LUNoj.
Kial mi bezonas Tiering?
Mallonge kaj abstrakte: atingi pli grandajn rezultojn uzante minimumon de rimedoj. Pli specife, la rezulto estas kutime komprenata kiel aro de stokadsistemoj - rapideco kaj alirtempo, stokadokosto kaj aliaj. La minimumo de rimedoj signifas la plej malgrandan elspezon: monon, energion, ktp. FAST VP efektivigas mekanismojn por redistribuado de datumoj trans malsamaj niveloj en stokadsistemoj Unity/Unity XT. Se vi kredas min, tiam vi povas salti la sekvan alineon. Por la cetero, mi rakontos al vi iom pli.
Taŭga distribuado de datumoj tra stokado-niveloj permesas ŝpari la ĝeneralan koston de stokado oferante alirrapidecon al kelkaj malofte uzataj informoj, kaj plibonigi rendimenton movante ofte uzatajn datumojn al pli rapidaj amaskomunikiloj. Ĉi tie iu povus argumenti, ke eĉ sen tiesigo, normala administranto scias kie loki kiajn datumojn, kiuj estas la dezirindaj trajtoj de konserva sistemo por sia tasko, ktp. Ĉi tio estas sendube vera, sed mane distribuado de datumoj havas siajn malavantaĝojn:
- postulas tempon kaj atenton de la administranto;
- Ne ĉiam eblas "redesegni" stokajn rimedojn por konveni ŝanĝiĝantajn kondiĉojn;
- grava avantaĝo malaperas: unueca aliro al rimedoj situantaj ĉe malsamaj stokniveloj.
Por ke la stokadadministrantoj malpli zorgu pri laborsekureco, mi aldonos, ke ankaŭ ĉi tie necesas kompetenta planado de rimedoj. Nun kiam la taskoj de tiesigo estas mallonge skizitaj, ni rigardu kion vi povas atendi de FAST VP. Nun estas la tempo por reveni al la difino. La unuaj du vortoj - Plene Aŭtomatigitaj - estas laŭvorte tradukitaj kiel "plene aŭtomatigitaj" kaj signifas, ke la distribuo inter niveloj okazas aŭtomate. Nu, Virtuala Pool estas datuma naĝejo, kiu inkluzivas rimedojn de malsamaj stokadniveloj. Jen kiel ĝi aspektas:
Rigardante antaŭen, mi diros, ke FAST VP movas datumojn nur ene de unu naĝejo, kaj ne inter pluraj naĝejoj.
Problemoj solvitaj de FAST VP
Unue ni parolu abstrakte. Ni havas naĝejon kaj iun mekanismon kiu povas redistribui datumojn ene de ĉi tiu naĝejo. Memorante, ke nia celo estas atingi maksimuman produktivecon, ni demandu nin: kiajn manierojn ni povas atingi ĝin? Povas esti pluraj el ili, kaj ĉi tie FAST VP havas ion por proponi al la uzanto, ĉar la teknologio estas io pli ol nur stokado-nivelado. Jen kelkaj manieroj kiel FAST VP povas pliigi la rendimenton de naĝejo:
- Distribuado de datumoj tra malsamaj specoj de diskoj, niveloj
- Distribuado de datumoj inter samtipaj diskoj
- Distribuado de datumoj dum vastigado de la naĝejo
Antaŭ ol ni rigardas kiel ĉi tiuj taskoj estas solvitaj, ni devas scii iujn necesajn faktojn pri kiel funkcias FAST VP. FAST VP funkcias kun blokoj de certa grandeco - 256 megabajtoj. Ĉi tiu estas la plej malgranda apuda "peco" de datumoj, kiuj povas esti movitaj. En la dokumentado jen kiel ili nomas ĝin: tranĉaĵo. El la vidpunkto de FAST VP, ĉiuj RAID-grupoj konsistas el aro de tiaj "pecoj". Sekve, ĉiuj I/O-statistikoj estas akumulitaj por tiaj datumblokoj. Kial oni elektis ĉi tiun blokgrandecon kaj ĉu ĝi estos reduktita? La bloko estas sufiĉe granda, sed ĉi tio estas kompromiso inter la granulareco de la datumoj (pli malgranda blokgrandeco signifas pli precizan distribuon) kaj disponeblaj komputikresursoj: pro la ekzistantaj striktaj limigoj pri RAM kaj granda nombro da blokoj, statistikaj datumoj povas okupi. tro multe, kaj la nombro da kalkuloj proporcie pliiĝos.
Kiel FAST VP asignas datumojn al la naĝejo. Politikistoj
Por kontroli la lokigon de datumoj en naĝejo kun FAST VP ebligita, ekzistas la sekvaj politikoj:
- Plej Alta Disponebla Nivelo
- Aŭtomata nivelo
- Komencu Alta tiam Aŭtomatan Nivelon (defaŭlte)
- Plej Malalta Disponebla Nivelo
Ili influas kaj la komencan blokasigno (datenoj unue skribitaj) kaj postan reasignadon. Kiam la datumoj jam troviĝas sur diskoj, redistribuo komenciĝos laŭ horaro aŭ permane.
Plej Alta Disponebla Nivelo provas meti novan blokon ĉe la plej alta rendimenta nivelo. Se ne estas sufiĉe da spaco sur ĝi, ĝi estas metita ĉe la sekva plej produktiva nivelo, sed tiam la datumoj povas esti movitaj al pli produktiva nivelo (se estas spaco aŭ per delokigado de aliaj datumoj). Auto-Tier metas novajn datumojn sur malsamaj niveloj depende de la kvanto de disponebla spaco, kaj ĝi estas redistribuita depende de postulo kaj libera spaco. Komencu Alta tiam Aŭtomata Nivelo estas la defaŭlta politiko kaj ankaŭ rekomendita. Kiam komence metita, ĝi funkcias kiel la Plej Alta Disponebla Nivelo, kaj tiam la datumoj estas movitaj depende de ĝiaj uzadostatistikoj. La Politiko de Plej Malalta Disponebla Nivelo celas meti datumojn en la malplej produktivan nivelon.
Transdono de datumoj okazas kun malalta prioritato por ne malhelpi la utilan funkciadon de la stokada sistemo, tamen ekzistas agordo "Translokigo de datumoj", kiu ŝanĝas la prioritaton. Estas propreco ĉi tie: ne ĉiuj datumblokoj havas la saman redistribuan ordon. Ekzemple, blokoj markitaj kiel metadatenoj unue estos movitaj al pli rapida nivelo. Metadatumoj estas, por tiel diri, "datumoj pri datumoj", iuj aldonaj informoj, kiuj ne estas uzantdatenoj, sed konservas ĝian priskribon. Ekzemple, informoj en la dosiersistemo pri kiu bloko troviĝas aparta dosiero. Ĉi tio signifas, ke la rapideco de aliro al datumoj dependas de la rapideco de aliro al metadatenoj. Konsiderante ke metadatenoj estas tipe multe pli malgrandaj en grandeco, la avantaĝoj de movi ĝin al pli alt-efikecaj diskoj estas atenditaj esti pli grandaj.
Kriterioj kiujn Fast VP uzas en sia laboro
La ĉefa kriterio por ĉiu bloko, tre proksimume, estas la karakterizaĵo de la "postulo" de la datumoj, kiu dependas de la nombro da legado kaj skriba operacioj de datumfragmento. Ni nomas ĉi tiun karakterizaĵon "Temperturo". Estas postulataj (varmaj) datumoj, kiuj estas "pli varmaj" ol nepostulataj datumoj. Ĝi estas kalkulita periode, defaŭlte je intervaloj de unu horo.
La funkcio de kalkulo de temperaturo havas la jenajn ecojn:
- En foresto de I/O, datumoj "malvarmiĝas" dum tempo.
- Sub pli-malpli egala ŝarĝo laŭlonge de la tempo, la temperaturo unue pliiĝas kaj poste stabiliĝas en certa intervalo.
Poste, la politikoj priskribitaj supre kaj la libera spaco ĉe ĉiu nivelo estas konsiderataj. Por klareco, mi provizos bildon el la dokumentaro. Ĉi tie ruĝaj, flavaj kaj bluaj koloroj indikas blokojn kun altaj, mezaj kaj malaltaj temperaturoj, respektive.
Sed ni revenu al la taskoj. Do, ni povas komenci analizi, kio estas farita por solvi FAST VP-problemojn.
A. Distribuado de datumoj tra malsamaj specoj de diskoj, niveloj
Efektive, ĉi tio estas la ĉefa tasko de FAST VP. La ceteraj, iusence, estas derivaĵoj de ĝi. Depende de la elektita politiko, datumoj estos distribuitaj tra malsamaj stokadniveloj. Antaŭ ĉio, la lokiga politiko estas konsiderata, tiam la bloktemperaturo kaj la grandeco/rapideco de RAID-grupoj.
Por Plej Altaj/Plej Malsupraj Disponeblaj Tier-politikoj ĉio estas sufiĉe simpla. Por la aliaj du tio estas la kazo. Datenoj estas distribuitaj trans malsamaj niveloj konsiderante la grandecon kaj efikecon de RAID-grupoj: tiel ke la rilatumo de la totala "temperaturo" de la blokoj al la "kondiĉa maksimuma efikeco" de ĉiu RAID-grupo estas proksimume la sama. Tiel, la ŝarĝo estas distribuita pli-malpli egale. Pli da postulataj datumoj estas movitaj al rapidaj amaskomunikiloj, kaj malofte uzataj datumoj estas movitaj al pli malrapidaj amaskomunikiloj. Ideale, la distribuo devus aspekti kiel ĉi tio:
B. Distribuado de datumoj inter samtipaj diskoj
Memoru, ke komence mi skribis tiun konservadon de unu aŭ pli niveloj estas kombinitaj en unu naĝejon? En la kazo de ununura nivelo, FAST VP ankaŭ havas laboron por fari. Por atingi maksimuman rendimenton je ajna nivelo, estas konsilinde distribui datumojn egale inter diskoj. Ĉi tio (teorie) permesos al vi akiri la maksimuman kvanton da IOPS. Datenoj ene de RAID-grupo povas esti konsideritaj distribuitaj egale trans diskoj, sed tio ne estas ĉiam la kazo inter RAID-grupoj. En kazo de malekvilibro, FAST VP movos datumojn inter RAID-grupoj proporcie al ilia volumeno kaj "kondiĉa agado" (laŭ nombraj terminoj). Por klareco, mi montros reekvilibran skemon inter tri RAID-grupoj:
B. Distribuado de datumoj kiam pligrandigas la naĝejon
Ĉi tiu tasko estas speciala kazo de la antaŭa kaj estas farita kiam RAID-grupo estas aldonita al la naĝejo. Por certigi, ke la lastatempe aldonita RAID-grupo ne restos senmova, iuj el la datumoj estos transdonitaj al ĝi, kio signifas, ke la ŝarĝo estos redistribuita tra ĉiuj RAID-grupoj.
SSD Eluziĝo-nivelado
Uzante eluziĝon, FAST VP povas plilongigi la vivon de SSD, kvankam ĉi tiu funkcio ne rekte rilatas al Stokado-Tierado. Ĉar temperaturdatumoj jam disponeblas, la nombro da skribaj operacioj ankaŭ estas konsiderata, kaj ni scias kiel movi datumblokojn, estus logike, ke FAST VP solvu ĉi tiun problemon.
Se la nombro da eniroj en unu RAID-grupo signife superas la nombron da eniroj en alia, FAST VP redistribuos la datumojn laŭ la nombro da skribaj operacioj. Unuflanke, ĉi tio malpezigas la ŝarĝon kaj ŝparas la rimedon de iuj diskoj, aliflanke, ĝi aldonas "laboron" por malpli ŝarĝitaj, pliigante ĝeneralan rendimenton.
Tiamaniere, FAST VP prenas la tradiciajn defiojn de Stokado-Tierado kaj faras iom pli ol tio. Ĉio ĉi permesas vin konservi datumojn sufiĉe efike en la Unity-stokada sistemo.
Iuj konsiloj
- Ne neglektu legi la dokumentadon. Estas plej bonaj praktikoj, kaj ili funkcias sufiĉe bone. Se vi sekvas ilin, tiam, kiel regulo, ne aperas seriozaj problemoj. La resto de la konsiloj esence ripetas aŭ kompletigas ilin.
- Se vi agordis kaj ebligis FAST VP, estas pli bone lasi ĝin ebligita. Lasu ĝin distribui la datumojn en sia asignita tempo kaj iom post iom ol unufoje jare kaj havante seriozan efikon sur la plenumado de aliaj taskoj. En tiaj kazoj, datuma redistribuo povas daŭri longan tempon.
- Atentu kiam vi elektas translokigan fenestron. Kvankam ĉi tio estas evidenta, provu elekti tempon kun la malplej ŝarĝo de Unity kaj asigni sufiĉan tempon.
- Planu vastigi vian stokan sistemon, faru ĝin ĝustatempe. Ĉi tio estas ĝenerala rekomendo, kiu gravas ankaŭ por FAST VP. Se la kvanto de libera spaco estas tre malgranda, tiam datummovado malrapidiĝos aŭ fariĝos neebla. Precipe se vi neglektis la punkton 2.
- Kiam vi vastigas naĝejon kun FAST VP ebligita, vi ne devus komenci per la plej malrapidaj diskoj. Tio estas, ni aŭ aldonas ĉiujn planitajn RAID-grupojn samtempe, aŭ unue aldonas la plej rapidajn diskojn. En ĉi tiu kazo, redistribui datumojn al novaj "rapidaj" diskoj pliigos la ĝeneralan rapidecon de la naĝejo. Alie, komenci per "malrapidaj" diskoj povas konduki al tre malagrabla situacio. Unue, datumoj estos transdonitaj al novaj relative malrapidaj diskoj, kaj poste, kiam pli rapidaj estos aldonitaj, en la kontraŭa direkto. Estas nuancoj ĉi tie rilataj al malsamaj FAST VP-politikoj, sed ĝenerale, simila situacio eblas.
Se vi rigardas ĉi tiun produkton, vi povas provi Unity senpage elŝutante virtualan aparaton Unity VSA.
Ĉe la fino de la materialo, mi dividas plurajn utilajn ligilojn:
- Paĝo
- – mallonga priskribo de la funkcio
- , pdf-formato
konkludo
Mi ŝatus skribi pri multe, sed mi komprenas, ke ne ĉiuj detaloj estos interesaj por la leganto. Ekzemple, vi povas paroli pli detale pri la kriterioj per kiuj FAST VP faras decidojn pri transdono de datumoj, pri la procezoj de analizo de I/O-statistikoj. Ankaŭ, la temo de interago kun , kaj ĉi tio meritas apartan artikolon. Vi povas eĉ fantazii pri la evoluo de ĉi tiu teknologio. Mi esperas, ke ĝi ne estis enuiga kaj mi ne enuigis vin. Ĝis revido!
fonto: www.habr.com