I dag vil vi tale om en interessant teknologi implementeret i Unity/Unity XT-lagringssystemer - FAST VP. Hvis det er første gang, du hører om Unity, så kan du tjekke systemets egenskaber ved at bruge linket i slutningen af artiklen. Jeg arbejdede på FAST VP på Dell EMC-projektteamet i over et år. I dag vil jeg tale om denne teknologi mere detaljeret og afsløre nogle detaljer om dens implementering. Selvfølgelig kun dem, der får lov til at blive afsløret. Hvis du er interesseret i spørgsmål om effektiv datalagring eller simpelthen ikke helt har forstået dokumentationen, så vil denne artikel helt sikkert være nyttig og interessant.
Jeg fortæller dig med det samme, hvad der ikke vil være i materialet. Der vil ikke være nogen søgning efter konkurrenter og sammenligning med dem. Jeg har heller ikke tænkt mig at tale om lignende teknologier fra open source, fordi den nysgerrige læser allerede kender til dem. Og selvfølgelig vil jeg ikke reklamere for noget.
Opbevaringsniveau. Mål og mål for FAST VP
FAST VP står for Fully Automated Storage Tiering for Virtual Pool. Lidt svært? Intet problem, vi finder ud af det nu. Tiering er en måde at organisere datalagring på, hvor der er flere niveauer (tiers), hvor disse data lagres. Hver har sine egne karakteristika. Det vigtigste: ydeevne, volumen og pris for lagring af en informationsenhed. Selvfølgelig er der et forhold mellem dem.
Et vigtigt træk ved tiering er, at adgangen til data gives ensartet uanset lagerniveauet, hvor den i øjeblikket er placeret, og puljens størrelse er lig med summen af størrelserne af de ressourcer, der er inkluderet i den. Det er her, forskellene fra cachen ligger: størrelsen af cachen føjes ikke til ressourcens samlede volumen (puljen i dette tilfælde), og cachedataene duplikerer et fragment af hovedmediedataene (eller vil duplikere, hvis data fra cachen er endnu ikke blevet skrevet). Også distributionen af data efter niveauer er skjult for brugeren. Det vil sige, at han ikke kan se præcis, hvilke data der er placeret på hvert niveau, selvom han kan påvirke dette indirekte ved at fastsætte politikker (mere om dem senere).
Lad os nu se på funktionerne i implementeringen af lagertiering i Unity. Unity har 3 niveauer eller niveauer:
- Ekstrem ydeevne (SSD'er)
- Ydeevne (SAS HDD 10k/15k RPM)
- Kapacitet (NL-SAS HDD 7200 RPM)
De præsenteres i faldende rækkefølge efter ydeevne og pris. Ekstrem ydeevne inkluderer kun solid state-drev (SSD'er). De to andre niveauer inkluderer magnetiske diskdrev, som adskiller sig i rotationshastighed og følgelig ydeevne.
Lagermedier fra samme niveau og samme størrelse kombineres til et RAID-array, der danner en RAID-gruppe (RAID-gruppe, forkortet til RG); Du kan læse om tilgængelige og anbefalede RAID-niveauer i den officielle dokumentation. Opbevaringspuljer dannes af RAID-grupper fra et eller flere niveauer, hvorfra ledig plads så fordeles. Og fra poolen er der allokeret plads til filsystemer og LUN'er.
Hvorfor har jeg brug for Tiering?
Kort og abstrakt: at opnå større resultater ved brug af et minimum af ressourcer. Mere specifikt forstås resultatet normalt som et sæt af lagersystemkarakteristika - hastighed og adgangstid, lageromkostninger og andre. Et minimum af ressourcer betyder de mindste udgifter: penge, energi og så videre. FAST VP implementerer mekanismer til omfordeling af data på tværs af forskellige niveauer i Unity/Unity XT-lagringssystemer. Hvis du tror mig, så kan du springe næste afsnit over. For resten vil jeg fortælle dig lidt mere.
Korrekt distribution af data på tværs af lagerniveauer giver dig mulighed for at spare på de samlede omkostninger ved lagerplads ved at ofre adgangshastigheden til nogle sjældent brugte oplysninger og forbedre ydeevnen ved at flytte ofte brugte data til hurtigere medier. Her kan nogen hævde, at selv uden niveaudeling ved en normal administrator, hvor han skal placere hvilke data, hvad er de ønskelige egenskaber ved et lagersystem til hans opgave osv. Dette er uden tvivl sandt, men manuel distribution af data har sine ulemper:
- kræver tid og opmærksomhed fra administratoren;
- Det er ikke altid muligt at "gentegne" lagerressourcer, så de passer til skiftende forhold;
- en vigtig fordel forsvinder: samlet adgang til ressourcer placeret på forskellige lagerniveauer.
For at få lageradministratorer til at bekymre sig mindre om jobsikkerhed, vil jeg tilføje, at kompetent ressourceplanlægning også er nødvendig her. Nu hvor opgaverne med niveaudeling er kort skitseret, lad os tage et kig på, hvad du kan forvente af FAST VP. Nu er det tid til at vende tilbage til definitionen. De to første ord – Fuldt automatiseret – er bogstaveligt talt oversat til "fuldautomatiseret" og betyder, at fordelingen mellem niveauerne sker automatisk. Nå, Virtual Pool er en datapool, der inkluderer ressourcer fra forskellige lagerniveauer. Sådan ser det ud:
Når jeg ser fremad, vil jeg sige, at FAST VP kun flytter data inden for én pulje, og ikke mellem flere pools.
Problemer løst af FAST VP
Lad os først tale abstrakt. Vi har en pulje og en eller anden mekanisme, der kan omfordele data i denne pulje. Når vi husker, at vores mål er at opnå maksimal produktivitet, så lad os spørge os selv: på hvilke måder kan vi opnå det? Dem kan der være flere af, og her har FAST VP noget at tilbyde brugeren, da teknologien er noget mere end blot lagertiering. Her er nogle måder, hvorpå FAST VP kan øge poolens ydeevne:
- Fordeling af data på tværs af forskellige typer diske, niveauer
- Fordeling af data mellem diske af samme type
- Datafordeling ved udvidelse af puljen
Før vi ser på, hvordan disse opgaver løses, skal vi kende nogle nødvendige fakta om, hvordan FAST VP fungerer. FAST VP opererer med blokke af en vis størrelse - 256 megabyte. Dette er den mindste sammenhængende "klump" af data, der kan flyttes. I dokumentationen er det, hvad de kalder det: skive. Fra FAST VP's synspunkt består alle RAID-grupper af et sæt af sådanne "stykker". Følgelig akkumuleres al I/O-statistik for sådanne datablokke. Hvorfor blev denne blokstørrelse valgt, og vil den blive reduceret? Blokken er ret stor, men dette er et kompromis mellem dataenes granularitet (mindre blokstørrelse betyder mere nøjagtig distribution) og tilgængelige computerressourcer: givet de eksisterende strenge begrænsninger på RAM og et stort antal blokke, kan statistikdata fylde for meget, og antallet af beregninger vil stige forholdsmæssigt.
Hvordan FAST VP allokerer data til puljen. Politikere
For at kontrollere placeringen af data i en pulje med FAST VP aktiveret findes følgende politikker:
- Højest tilgængelige niveau
- Auto-tier
- Start højt og derefter Auto-Tier (standard)
- Laveste tilgængelige niveau
De påvirker både den indledende blokallokering (data først skrevet) og efterfølgende omallokering. Når dataene allerede er placeret på diske, påbegyndes omfordeling i henhold til en tidsplan eller manuelt.
Højest tilgængelige niveau forsøger at placere en ny blok på det højest ydende niveau. Hvis der ikke er plads nok på den, placeres den på det næstmest produktive niveau, men så kan data flyttes til et mere produktivt niveau (hvis der er plads eller ved at fortrænge andre data). Auto-Tier placerer nye data på forskellige niveauer afhængigt af mængden af tilgængelig plads, og de omfordeles afhængigt af efterspørgsel og ledig plads. Start højt, så er Auto-Tier standardpolitikken og anbefales også. Når den først placeres, fungerer den som det højeste tilgængelige niveau, og derefter flyttes dataene afhængigt af dens brugsstatistik. Politikken for det laveste tilgængelige niveau søger at placere data i det mindst produktive niveau.
Dataoverførsel sker med lav prioritet for ikke at forstyrre den nyttige drift af lagersystemet, men der er en "Dataflytningshastighed"-indstilling, der ændrer prioriteten. Der er en ejendommelighed her: ikke alle datablokke har den samme omfordelingsrækkefølge. For eksempel vil blokke markeret som metadata blive flyttet til et hurtigere niveau først. Metadata er så at sige "data om data", nogle yderligere informationer, der ikke er brugerdata, men gemmer dens beskrivelse. For eksempel information i filsystemet om, hvilken blok en bestemt fil er placeret i. Det betyder, at hastigheden af adgang til data afhænger af hastigheden af adgang til metadata. Da metadata typisk er meget mindre i størrelse, forventes fordelene ved at flytte dem til diske med højere ydeevne at være større.
Kriterier som Fast VP bruger i sit arbejde
Hovedkriteriet for hver blok, meget groft sagt, er karakteristikken for "efterspørgslen" af dataene, som afhænger af antallet af læse- og skriveoperationer af et datafragment. Vi kalder denne karakteristik "Temperatur". Der er efterspurgte (hot) data, der er "varmere" end uhævede data. Det beregnes periodisk, som standard med intervaller på en time.
Temperaturberegningsfunktionen har følgende egenskaber:
- I mangel af I/O "køles data af" over tid.
- Ved nogenlunde ens belastning over tid stiger temperaturen først og stabiliserer sig derefter i et vist område.
Dernæst tages der hensyn til de ovenfor beskrevne politikker og den ledige plads på hvert niveau. For klarhedens skyld vil jeg give et billede fra dokumentationen. Her angiver røde, gule og blå farver blokke med henholdsvis høj, medium og lav temperatur.
Men lad os vende tilbage til opgaverne. Så vi kan begynde at analysere, hvad der bliver gjort for at løse FAST VP-problemer.
A. Fordeling af data på tværs af forskellige typer diske, niveauer
Faktisk er dette hovedopgaven for FAST VP. Resten er på en måde afledt af det. Afhængigt af den valgte politik vil data blive fordelt på tværs af forskellige lagerniveauer. Først og fremmest tages der hensyn til placeringspolitikken, derefter bloktemperaturen og størrelsen/hastigheden af RAID-grupper.
For politikker for højeste/laveste tilgængelige niveau er alt ganske enkelt. For de to andre er dette tilfældet. Data fordeles på forskellige niveauer under hensyntagen til størrelsen og ydeevnen af RAID-grupper: således at forholdet mellem den samlede "temperatur" af blokkene og den "betingede maksimale ydeevne" for hver RAID-gruppe er omtrent det samme. Dermed fordeles belastningen nogenlunde jævnt. Mere efterspurgte data flyttes til hurtige medier, og sjældent brugte data flyttes til langsommere medier. Ideelt set skulle fordelingen se sådan ud:
B. Fordeling af data mellem diske af samme type
Husk, i begyndelsen skrev jeg det lagringsmedie fra en eller flere niveauer kombineres til én pulje? I tilfælde af et enkelt niveau har FAST VP også arbejde at gøre. For at opnå maksimal ydeevne på ethvert niveau, er det tilrådeligt at fordele data jævnt mellem diske. Dette vil (i teorien) give dig mulighed for at få den maksimale mængde IOPS. Data inden for en RAID-gruppe kan betragtes som fordelt jævnt på tværs af diske, men dette er ikke altid tilfældet mellem RAID-grupper. I tilfælde af ubalance vil FAST VP flytte data mellem RAID-grupper i forhold til deres volumen og "betinget ydeevne" (i numeriske termer). For klarhedens skyld vil jeg vise et rebalanceringsskema blandt tre RAID-grupper:
B. Datafordeling ved udvidelse af puljen
Denne opgave er et specialtilfælde af den forrige og udføres, når en RAID-gruppe føjes til puljen. For at sikre, at den nyligt tilføjede RAID-gruppe ikke forbliver inaktiv, vil nogle af dataene blive overført til den, hvilket betyder, at belastningen vil blive omfordelt på tværs af alle RAID-grupper.
SSD-slidudjævning
Ved at bruge slidudjævning kan FAST VP forlænge levetiden af en SSD, selvom denne funktion ikke er direkte relateret til Storage Tiering. Da temperaturdata allerede er tilgængelige, tages der også højde for antallet af skriveoperationer, og vi ved, hvordan man flytter datablokke, ville det være logisk for FAST VP at løse dette problem.
Hvis antallet af poster i en RAID-gruppe væsentligt overstiger antallet af poster i en anden, vil FAST VP omfordele dataene i overensstemmelse med antallet af skriveoperationer. På den ene side aflaster dette belastningen og sparer ressourcen på nogle diske, på den anden side tilføjer det "arbejde" for mindre belastede, hvilket øger den samlede ydeevne.
På denne måde påtager FAST VP de traditionelle udfordringer med Storage Tiering og gør lidt mere end det. Alt dette giver dig mulighed for at gemme data ganske effektivt i Unity-lagersystemet.
Et par tip
- Forsøm ikke at læse dokumentationen. Der er bedste praksis, og de fungerer ganske godt. Hvis du følger dem, opstår der som regel ingen alvorlige problemer. Resten af rådene gentager eller supplerer dem grundlæggende.
- Hvis du har konfigureret og aktiveret FAST VP, er det bedre at lade det være aktiveret. Lad det distribuere dataene i dens tildelte tid og lidt efter lidt end en gang om året og have en alvorlig indvirkning på udførelsen af andre opgaver. I sådanne tilfælde kan omfordeling af data tage lang tid.
- Vær forsigtig, når du vælger et flyttevindue. Selvom dette er indlysende, så prøv at vælge et tidspunkt med den mindste belastning på Unity og allokér et tilstrækkeligt tidsrum.
- Planlæg at udvide dit lagersystem, gør det til tiden. Dette er en generel anbefaling, der også er vigtig for FAST VP. Hvis mængden af ledig plads er meget lille, vil databevægelsen blive langsommere eller umulig. Især hvis du forsømte punkt 2.
- Når du udvider en pulje med FAST VP aktiveret, bør du ikke starte med de langsomste diske. Det vil sige, at vi enten tilføjer alle planlagte RAID-grupper på én gang, eller tilføjer de hurtigste diske først. I dette tilfælde vil omfordeling af data til nye "hurtige" diske øge poolens samlede hastighed. Ellers kan det at starte med "langsomme" diske føre til en meget ubehagelig situation. Først vil data blive overført til nye, relativt langsomme diske, og derefter, når der tilføjes hurtigere, i den modsatte retning. Der er nuancer her relateret til forskellige FAST VP-politikker, men generelt er en lignende situation mulig.
Hvis du ser på dette produkt, kan du prøve Unity gratis ved at downloade Unity VSA virtual appliance.
I slutningen af materialet deler jeg flere nyttige links:
- Side
- – kort beskrivelse af funktionen
- , pdf-format
Konklusion
Jeg vil gerne skrive om meget, men jeg forstår, at ikke alle detaljerne vil være interessante for læseren. For eksempel kan du tale mere detaljeret om de kriterier, som FAST VP træffer beslutninger om dataoverførsel efter, om processerne for at analysere I/O-statistikker. Også emnet interaktion med , og dette fortjener en separat artikel. Du kan endda fantasere om udviklingen af denne teknologi. Jeg håber ikke, det var kedeligt, og jeg kedede dig ikke. Vi ses!
Kilde: www.habr.com