Vandag sal ons praat oor 'n interessante tegnologie geïmplementeer in die Unity / Unity XT-bergingstelsel - FAST VP. As jy vir die eerste keer van Unity gehoor het, dan kan die skakel aan die einde van die artikel gebruik word om jouself met die kenmerke van die stelsel te vergewis. Ek het meer as 'n jaar aan FAST VP gewerk aan die Dell EMC-projekspan. Vandag wil ek in meer besonderhede oor hierdie tegnologie praat en 'n paar besonderhede van die implementering daarvan openbaar. Natuurlik net diegene wat toegelaat word om geopenbaar te word. As jy belangstel in die kwessies van doeltreffende databerging of eenvoudig nie die dokumentasie ten volle verstaan het nie, dan sal hierdie artikel beslis nuttig en interessant wees.
Ek sal jou dadelik vertel wat nie in die materiaal sal wees nie. Daar sal nie na mededingers gesoek word en met hulle vergelyk word nie. Ek is ook nie van plan om oor soortgelyke tegnologieë van oopbron af te praat nie, want die nuuskierige leser weet reeds daarvan. En natuurlik gaan ek niks adverteer nie.
bergingsvlak. Doelwitte en doelwitte van FAST VP
FAST VP staan vir Fully Automated Storage Tiering vir Virtual Pool. Is dit moeilik? Niks, ons sal dit uitvind. Tiering is 'n manier om databerging te organiseer, waarin daar verskeie vlakke (vlakke) is waar hierdie data gestoor word. Elkeen het sy eie kenmerke. Die belangrikste: prestasie, volume en prys van die stoor van 'n eenheid van inligting. Natuurlik is daar 'n verhouding tussen hulle.
’n Belangrike kenmerk van vlakverdeling is dat toegang tot data eenvormig verskaf word, ongeag op watter bergingsvlak dit tans is, en die grootte van die poel is gelyk aan die som van die groottes van die hulpbronne wat daarin ingesluit is. Hier lê die verskil van die kas: die grootte van die kas word nie by die totale hoeveelheid van die hulpbron gevoeg nie (die poel in hierdie geval), en die kasdata dupliseer een of ander stukkie data vanaf die hoofmedium (of sal dupliseer as die data van die kas nog nie geskryf is nie). Die verspreiding van data volgens vlakke word ook vir die gebruiker versteek. Dit wil sê, hy sien nie presies watter data op elke vlak geleë is nie, alhoewel hy dit indirek kan beïnvloed, deur beleide (daaroor later) op te stel.
Kom ons kyk nou na die kenmerke van die implementering van bergingsvlak in Unity. In Unity is daar 3 vlakke, of vlakke:
- Uiterste werkverrigting (SSD's)
- Werkverrigting (SAS HDD 10k/15k RPM)
- Kapasiteit (NL-SAS HDD 7200RPM)
Hulle word in dalende volgorde van prestasie en prys aangebied. Uiterste werkverrigting sluit slegs Solid State Drives (SSD's) in. In die ander twee vlakke is daar magnetiese skyfdryf, wat verskil in rotasiespoed en, dienooreenkomstig, in werkverrigting.
Bergingsmedia van dieselfde vlak en dieselfde grootte word in 'n RAID-skikking gekombineer, wat 'n RAID-groep vorm (RAID-groep, afgekort as RG); jy kan lees oor die beskikbare en aanbevole RAID-vlakke in die amptelike dokumentasie. Uit RAID-groepe van een of meer vlakke word stoorpoele gevorm, waaruit vrye spasie dan versprei word. En reeds vanaf die swembad word spasie vir lêerstelsels en LUN's toegewys.
Hoekom het ek Tiering nodig?
Kort en abstrak: om meer resultate te behaal met die minste hoeveelheid hulpbronne. Meer spesifiek word die resultaat gewoonlik verstaan as 'n stel kenmerke van die bergingstelsel - die spoed en tyd van toegang, die koste van berging, en ander. Die minimum hulpbronne beteken die minste koste: geld, energie, ensovoorts. FAST VP implementeer net die meganismes vir die herverspreiding van data oor verskillende vlakke in die Unity / Unity XT-bergingstelsel. As jy my glo, kan jy die volgende paragraaf oorslaan. Vir die res vertel ek jou 'n bietjie meer.
Deur data behoorlik te verdeel, kan jy op die algehele koste van berging bespaar deur die spoed van toegang tot sommige selde gebruikte inligting op te offer, en werkverrigting te verbeter deur gereelde toegang tot data na vinniger media te skuif. Hier kan iemand beswaar maak dat 'n normale admin, selfs sonder om 'n vlak te maak, weet waar om watter data te plaas, watter eienskappe van die stoorstelsel wenslik is vir sy taak, ens. Sekerlik, dit is waar, maar die verspreiding van data "handmatig" het sy nadele:
- vereis tyd en aandag van die administrateur;
- dit is nie altyd moontlik om bergingsbronne onder veranderende toestande te "hervorm" nie;
- 'n belangrike voordeel verdwyn: verenigde toegang tot hulpbronne wat op verskillende bergingsvlakke geleë is.
Om stooradministrateurs minder oor werksekerheid te laat bekommer, sal ek byvoeg dat bekwame hulpbronbeplanning ook hier nodig is. Noudat die take van vlakke kortliks uiteengesit is, kom ons kyk wat jy van FAST VP kan verwag. Dit is die tyd om terug te keer na die definisie. Die eerste twee woorde - Volledig outomaties - vertaal letterlik as "ten volle outomaties" en beteken dat die verspreiding van vlakke outomaties plaasvind. Wel, Virtual Pool is 'n datapoel wat hulpbronne van verskillende bergingsvlakke insluit. Hier is hoe dit lyk:
As ek vorentoe kyk, sal ek sê dat FAST VP slegs data binne 'n enkele poel beweeg, en nie tussen verskeie poele nie.
Take opgelos deur FAST VP
Kom ons praat eers abstrak. Ons het 'n poel en een of ander meganisme wat data binne hierdie poel kan herverdeel. As ons in gedagte hou dat ons taak is om maksimum produktiwiteit te bereik, laat ons onsself afvra: op watter maniere kan dit bereik word? Daar kan verskeie van hulle wees, en hier het FAST VP iets om die gebruiker te bied, aangesien die tegnologie iets meer is as net bergingsvlak. Hier is 'n paar maniere waarop FAST VP swembadprestasie kan verhoog:
- Verspreiding van data oor verskillende soorte skywe, vlakke
- Verspreiding van data tussen skywe van dieselfde tipe
- Verspreiding van data wanneer die swembad uitgebrei word
Voordat ons kyk na hoe hierdie take uitgevoer word, moet ons 'n paar noodsaaklike feite weet oor hoe FAST VP werk. FAST VP werk met blokke van 'n sekere grootte - 256 megagrepe. Dit is die kleinste aaneenlopende "brokkie" data wat geskuif kan word. In die dokumentasie word dit so genoem: sny. Uit die oogpunt van FAST VP bestaan alle RAID-groepe uit 'n stel sulke "stukke". Gevolglik word alle I/O-statistieke vir sulke datablokke opgehoop. Waarom word hierdie blokgrootte gekies en sal dit verminder word? Die blok is redelik groot, maar dit is 'n kompromie tussen datagranulariteit (kleiner blokgrootte - meer akkurate verspreiding) en beskikbare rekenaarhulpbronne: met die bestaande ernstige beperkings op RAM en 'n groot aantal blokke, kan statistieke data te veel neem, en die aantal berekeninge sal proporsioneel groei.
Hoe FAST VP plaas data in die swembad. Politici
Om die plasing van data in 'n poel met FAST VP geaktiveer te beheer, is daar die volgende beleide:
- Hoogste beskikbare vlak
- Outo-vlak
- Begin hoog dan outomatiese vlak (verstek)
- Laagste beskikbare vlak
Hulle beïnvloed beide die aanvanklike bloktoewysing (die data word eers geskryf) en die daaropvolgende hertoewysing. Wanneer die data reeds op die skywe geplaas is, sal die hertoewysing volgens die skedule of handmatig begin word.
Die Hoogste Beskikbare Vlak probeer om die nuwe blok op die hoogste presterende vlak te plaas. As daar nie genoeg spasie daarop is nie, die volgende een wat prestasie betref, maar dan kan die data na 'n meer produktiewe vlak geskuif word (as daar spasie is of ander data verdring). Auto-Tier plaas nuwe data in verskillende vlakke gebaseer op die hoeveelheid beskikbare spasie, en herverdeel dit op grond van aanvraag en vrye spasie. Begin Hoog dan is Auto-Tier die verstekbeleid en word ook aanbeveel. Werk aanvanklik as 'n Hoogste Beskikbare Vlak, en skuif dan data gebaseer op gebruikstatistieke. Die laagste beskikbare vlak-beleid poog om data op die vlak wat die minste presteer te plaas.
Die data-oordrag gaan met 'n lae prioriteit om nie in te meng met die nuttige werk van die bergingstelsel nie, maar daar is 'n "Data hervestigingskoers" instelling wat die prioriteit verander. Daar is 'n eienaardigheid hier: nie alle datablokke het dieselfde herverspreidingsvolgorde nie. Byvoorbeeld, blokke wat as metadata gemerk is, sal eers na die vinniger vlak geskuif word. Metadata is so te sê “data oor data”, sommige bykomende inligting wat nie gebruikersdata is nie, maar hul beskrywing stoor. Byvoorbeeld, inligting in die lêerstelsel oor watter blok 'n spesifieke lêer is. Dit beteken dat die spoed van toegang tot data afhang van die spoed van toegang tot metadata. Aangesien metadata tipies baie kleiner is, sal die voordele om dit na vinniger skywe te skuif na verwagting groter wees.
Kriteria wat Fast VP in sy werk gebruik
Die hoofkriterium vir elke blok, indien baie rofweg, is die kenmerk van die "aanvraag" van data, wat afhang van die aantal lees- en skryfbewerkings van 'n datafragment. Hierdie eienskap word "Temperatuur" genoem. Daar is warm data wat warmer is as onopgeëiste data. Dit word periodiek bereken, by verstek met 'n interval van een uur.
Die temperatuurberekeningsfunksie het die volgende eienskappe:
- In die afwesigheid van I / O, "koel" data met verloop van tyd.
- Met min of meer dieselfde las in tyd, neem die temperatuur eers toe en stabiliseer dan in 'n sekere reeks.
Verder word die beleide hierbo beskryf en die vrye spasie op elke vlak in ag geneem. Vir duidelikheid gee ek 'n prentjie uit die dokumentasie. Hier dui rooi, geel en blou kleure blokke met onderskeidelik hoë, medium en lae temperature aan.
Maar terug na die take. So, ons kan begin om te ontleed wat gedoen word om die probleme van FAST VP op te los.
A. Verspreiding van data oor verskillende tipes skywe, vlakke
Eintlik is dit die hooftaak van FAST VP. Die res, in 'n sekere sin, is afgeleides daarvan. Afhangende van die geselekteerde beleid, sal data oor verskillende bergingsvlakke versprei word. Eerstens word die plasingsbeleid in ag geneem, dan die temperatuur van die blokke en die grootte / spoed van die RAID-groepe.
Vir Hoogste/Laagste Beskikbare Vlak-polisse is alles redelik eenvoudig. Vir die ander twee is dit die geval. Data word oor verskillende vlakke versprei, met inagneming van die grootte en werkverrigting van RAID-groepe: sodat die verhouding van die totale "temperatuur" van blokke tot die "voorwaardelike maksimum werkverrigting" van elke RAID-groep ongeveer dieselfde is. Dus word die las min of meer eweredig versprei. Data wat meer in aanvraag is, word na vinniger media verskuif, minder gereeld gebruikte data word na stadiger media verskuif. Ideaal gesproke moet die verspreiding iets soos volg lyk:
B. Verspreiding van data tussen skywe van dieselfde tipe
Onthou, aan die begin het ek geskryf dat inligting draers van een of meer vlakke in een swembad gekombineer word? In die geval van 'n enkele vlak, het FAST VP ook werk om te doen. Om prestasie op enige vlak te maksimeer, is dit wenslik om data eweredig oor skywe te versprei. Dit sal (in teorie) toelaat om die maksimum aantal IOPS te kry. Data binne 'n RAID-groep kan beskou word as eweredig oor skywe versprei, maar dit is nie altyd die geval tussen RAID-groepe nie. In die geval van 'n wanbalans, sal FAST VP data tussen RAID-groepe skuif in verhouding tot hul grootte en "voorwaardelike prestasie" (in numeriese terme). Vir duidelikheid sal ek die herbalanseringskema tussen drie RAID-groepe wys:
C. Verspreiding van data wanneer die swembad uitgebrei word
Hierdie taak is 'n spesiale geval van die vorige een en word uitgevoer wanneer 'n RAID-groep by die poel gevoeg word. Om te verhoed dat die nuut bygevoegde RAID-groep ledig is, sal van die data daarheen oorgedra word, wat beteken dat die las op alle RAID-groepe herverdeel sal word.
SSD Dra Nivellering
Deur slytasie-nivellering kan FAST VP die lewe van 'n SSD verleng, hoewel hierdie kenmerk nie direk verband hou met Berging Tiering nie. Aangesien daar reeds temperatuurdata is, word die aantal skryfbewerkings ook in ag geneem, ons weet hoe om datablokke te skuif, dit sal logies wees vir FAST VP om hierdie probleem ook op te los.
As die aantal skrywes aan een RAID-groep die aantal skrywes na 'n ander aansienlik oorskry, sal FAST VP die data herverdeel volgens die aantal skrywes. Aan die een kant verwyder dit die las en spaar die hulpbron van sommige skywe, aan die ander kant voeg dit "werk" by vir minder gelaaide, wat die algehele werkverrigting verhoog.
FAST VP neem dus die tradisionele take van Storage Tiering aan en doen 'n bietjie meer as dit. Dit alles laat jou toe om data doeltreffend in die Unity-bergingstelsel te stoor.
Enkele wenke
- Moenie nalaat om die dokumentasie te lees nie. Daar is beste praktyke, en dit werk redelik goed. As jy hulle volg, ontstaan ernstige probleme as 'n reël nie. Die res van die wenke herhaal of vul dit basies aan.
- As jy FAST VP gekonfigureer en geaktiveer het, laat dit dan geaktiveer. Laat dit data toeken in die toegelate tyd en bietjie vir bietjie as een keer per jaar en het 'n ernstige impak op die uitvoering van ander take. In sulke gevalle kan die herverspreiding van data 'n lang tyd neem.
- Wees versigtig wanneer jy 'n hervestigingsvenster kies. Alhoewel dit voor die hand liggend is, probeer om 'n tyd te kies met die minste las op Unity en ken 'n voldoende hoeveelheid tyd toe.
- Beplan jou berginguitbreiding, doen dit betyds. Dit is 'n algemene aanbeveling wat ook belangrik is vir FAST VP. As die hoeveelheid vrye spasie baie klein is, sal die beweging van data vertraag of onmoontlik word. Veral as jy punt 2 afgeskeep het.
- Wanneer 'n swembad uitgebrei word met FAST VP geaktiveer, moenie met die stadigste dryf begin nie. Dit wil sê, óf ons voeg al die beplande RAID-groepe gelyktydig by, óf ons voeg eers die vinnigste skywe by. In hierdie geval sal die herverspreiding van data na nuwe "vinnige" skywe die algehele spoed van die swembad verhoog. Andersins, begin met "stadige" skywe, kan jy 'n baie onaangename situasie kry. Eerstens sal data oorgedra word na nuwe, relatief stadige skywe, en dan, wanneer vinniger bygevoeg word, in die teenoorgestelde rigting. Daar is nuanses wat verband hou met verskillende FAST VP-beleide, maar in die algemene geval is hierdie situasie moontlik.
As jy na hierdie produk kyk, kan jy Unity gratis in aksie probeer deur die Unity VSA virtuele toestel af te laai.
Aan die einde van die artikel deel ek 'n paar nuttige skakels:
- bladsy
- – kort beskrywing van die funksie
- , pdf-formaat
Gevolgtrekking
Ek wil oor baie skryf, maar ek verstaan dat nie al die besonderhede vir die leser van belang sal wees nie. U kan byvoorbeeld in meer besonderhede praat oor die kriteria waarvolgens FAST VP 'n besluit neem om data oor te dra, oor die prosesse vir die ontleding van I/O-statistieke. Ook die onderwerp van interaksie met , en dit trek op 'n aparte artikel. Jy kan selfs fantaseer oor die ontwikkeling van hierdie tegnologie. Ek hoop nie dit was vervelig nie en ek het jou nie verveel nie. Sien jou binnekort!
Bron: will.com