I dag skal vi snakke om en interessant teknologi implementert i Unity/Unity XT lagringssystemer - FAST VP. Hvis dette er første gang du hører om Unity, kan du sjekke ut systemkarakteristikkene ved å bruke lenken på slutten av artikkelen. Jeg jobbet på FAST VP i Dell EMC-prosjektteamet i over ett år. I dag vil jeg snakke om denne teknologien mer detaljert og avsløre noen detaljer om implementeringen. Selvfølgelig bare de som får lov til å bli avslørt. Hvis du er interessert i problemer med effektiv datalagring eller rett og slett ikke helt har forstått dokumentasjonen, vil denne artikkelen absolutt være nyttig og interessant.
Jeg skal fortelle deg med en gang hva som ikke er i materialet. Det vil ikke være søk etter konkurrenter og sammenligning med dem. Jeg har heller ikke tenkt å snakke om lignende teknologier fra åpen kildekode, fordi den nysgjerrige leseren allerede vet om dem. Og jeg kommer selvfølgelig ikke til å annonsere noe.
Lagringsnivå. Mål og mål for FAST VP
FAST VP står for Fully Automated Storage Tiering for Virtual Pool. Litt vanskelig? Ikke noe problem, vi finner ut av det nå. Tiering er en måte å organisere datalagring der det er flere nivåer (tiers) hvor disse dataene lagres. Hver har sine egne egenskaper. Det viktigste: ytelse, volum og pris for å lagre en informasjonsenhet. Selvfølgelig er det et forhold mellom dem.
Et viktig trekk ved tiering er at tilgang til data gis jevnt uavhengig av lagringsnivået den befinner seg på, og størrelsen på bassenget er lik summen av størrelsene på ressursene som er inkludert i den. Det er her forskjellene fra cachen ligger: størrelsen på cachen legges ikke til det totale volumet av ressursen (pool i dette tilfellet), og cache-dataene dupliserer et fragment av hovedmediedataene (eller vil duplisere hvis data fra cachen er ennå ikke skrevet). Dessuten er distribusjonen av data etter nivåer skjult for brukeren. Det vil si at han ikke ser nøyaktig hvilke data som ligger på hvert nivå, selv om han kan påvirke dette indirekte ved å sette retningslinjer (mer om dem senere).
La oss nå se på funksjonene til implementeringen av lagringsnivå i Unity. Unity har 3 nivåer, eller nivå:
- Ekstrem ytelse (SSD-er)
- Ytelse (SAS HDD 10k/15k RPM)
- Kapasitet (NL-SAS HDD 7200 RPM)
De presenteres i synkende rekkefølge etter ytelse og pris. Ekstrem ytelse inkluderer bare solid state-stasjoner (SSD-er). De to andre nivåene inkluderer magnetiske diskstasjoner, som varierer i rotasjonshastighet og følgelig ytelse.
Lagringsmedier fra samme nivå og samme størrelse kombineres til en RAID-array, og danner en RAID-gruppe (RAID-gruppe, forkortet til RG); Du kan lese om tilgjengelige og anbefalte RAID-nivåer i den offisielle dokumentasjonen. Lagringsbassenger dannes fra RAID-grupper fra ett eller flere nivåer, hvorfra ledig plass deretter distribueres. Og fra bassenget tildeles plass til filsystemer og LUN-er.
Hvorfor trenger jeg Tiering?
Kort og abstrakt: for å oppnå bedre resultater ved å bruke et minimum av ressurser. Mer spesifikt blir resultatet vanligvis forstått som et sett med lagringssystemegenskaper - hastighet og tilgangstid, lagringskostnader og andre. Minimum av ressurser betyr minst utgifter: penger, energi og så videre. FAST VP implementerer mekanismer for redistribuering av data på tvers av ulike nivåer i Unity/Unity XT lagringssystemer. Hvis du tror meg, kan du hoppe over neste avsnitt. For resten skal jeg fortelle deg litt mer.
Riktig distribusjon av data på tvers av lagringsnivåer lar deg spare på de totale lagringskostnadene ved å ofre tilgangshastighet til noe sjelden brukt informasjon, og forbedre ytelsen ved å flytte ofte brukte data til raskere medier. Her kan noen hevde at selv uten nivådeling, vet en normal administrator hvor han skal plassere hvilke data, hva er de ønskelige egenskapene til et lagringssystem for oppgaven hans, etc. Dette er utvilsomt sant, men manuell distribusjon av data har sine ulemper:
- krever tid og oppmerksomhet fra administratoren;
- Det er ikke alltid mulig å "tegne om" lagringsressurser for å passe skiftende forhold;
- en viktig fordel forsvinner: enhetlig tilgang til ressurser plassert på forskjellige lagringsnivåer.
For å få lagringsadministratorer til å bekymre seg mindre om jobbsikkerhet, vil jeg legge til at kompetent ressursplanlegging er nødvendig også her. Nå som oppgavene med nivådeling er kort skissert, la oss ta en titt på hva du kan forvente av FAST VP. Nå er det på tide å gå tilbake til definisjonen. De to første ordene – Fully Automated – blir bokstavelig talt oversatt som «helautomatisert» og betyr at fordelingen mellom nivåene skjer automatisk. Vel, Virtual Pool er en datapool som inkluderer ressurser fra forskjellige lagringsnivåer. Slik ser det ut:
Når jeg ser fremover, vil jeg si at FAST VP flytter data kun innenfor én pool, og ikke mellom flere pools.
Problemer løst av FAST VP
La oss snakke abstrakt først. Vi har en pool og en eller annen mekanisme som kan omfordele data innenfor denne poolen. Når vi husker at målet vårt er å oppnå maksimal produktivitet, la oss spørre oss selv: hvilke måter kan vi oppnå det på? Det kan være flere av dem, og her har FAST VP noe å tilby brukeren, siden teknologien er noe mer enn bare lagertiering. Her er noen måter FAST VP kan øke bassengytelsen på:
- Distribusjon av data på tvers av ulike typer disker, nivåer
- Distribuere data mellom disker av samme type
- Datadistribusjon ved utvidelse av bassenget
Før vi ser på hvordan disse oppgavene løses, må vi vite noen nødvendige fakta om hvordan FAST VP fungerer. FAST VP opererer med blokker av en viss størrelse - 256 megabyte. Dette er den minste sammenhengende "klumpen" av data som kan flyttes. I dokumentasjonen er dette hva de kaller det: skive. Fra synspunktet til FAST VP består alle RAID-grupper av et sett med slike "biter". Følgelig akkumuleres all I/O-statistikk for slike datablokker. Hvorfor ble denne blokkstørrelsen valgt og vil den bli redusert? Blokken er ganske stor, men dette er et kompromiss mellom granulariteten til dataene (mindre blokkstørrelse betyr mer nøyaktig distribusjon) og tilgjengelige dataressurser: gitt de eksisterende strenge begrensningene på RAM og et stort antall blokker, kan statistikkdata ta opp for mye, og antall beregninger vil øke proporsjonalt.
Hvordan FAST VP allokerer data til bassenget. Politikere
For å kontrollere plassering av data i en pool med FAST VP aktivert, eksisterer følgende retningslinjer:
- Høyeste tilgjengelige nivå
- Auto-Tier
- Start høyt og deretter Auto-Tier (standard)
- Laveste tilgjengelige nivå
De påvirker både den første blokkallokeringen (data først skrevet) og påfølgende omallokering. Når dataene allerede er plassert på disker, vil redistribuering startes i henhold til en tidsplan eller manuelt.
Høyeste tilgjengelige nivå forsøker å plassere en ny blokk på nivået med høyest ytelse. Hvis det ikke er nok plass på den, plasseres den på det nest mest produktive nivået, men da kan dataene flyttes til et mer produktivt nivå (hvis det er plass eller ved å forskyve andre data). Auto-Tier plasserer nye data på ulike nivåer avhengig av mengden tilgjengelig plass, og de blir omfordelt avhengig av etterspørsel og ledig plass. Start høyt, så er Auto-Tier standardpolicyen og anbefales også. Når den først plasseres, fungerer den som det høyeste tilgjengelige nivået, og deretter flyttes dataene avhengig av bruksstatistikken. Retningslinjene for lavest tilgjengelig nivå søker å plassere data i det minst produktive nivået.
Dataoverføring skjer med lav prioritet for ikke å forstyrre den nyttige driften av lagringssystemet, men det er en "Dataflyttehastighet"-innstilling som endrer prioriteten. Det er en særegenhet her: ikke alle datablokker har samme omfordelingsrekkefølge. For eksempel vil blokker merket som metadata bli flyttet til et raskere nivå først. Metadata er så å si «data om data», noe tilleggsinformasjon som ikke er brukerdata, men som lagrer beskrivelsen. For eksempel informasjon i filsystemet om hvilken blokk en bestemt fil ligger i. Dette betyr at hastigheten på tilgang til data avhenger av hastigheten på tilgang til metadata. Gitt at metadata vanligvis er mye mindre i størrelse, forventes fordelene ved å flytte dem til disker med høyere ytelse å være større.
Kriterier som Fast VP bruker i sitt arbeid
Hovedkriteriet for hver blokk, veldig grovt sett, er karakteristikken for "etterspørselen" av dataene, som avhenger av antall lese- og skriveoperasjoner til et datafragment. Vi kaller denne egenskapen "temperatur". Det er etterspurte (hot) data som er "hottere" enn data som ikke er gjort krav på. Den beregnes med jevne mellomrom, som standard med intervaller på én time.
Temperaturberegningsfunksjonen har følgende egenskaper:
- I fravær av I/O, "kjøles" data ned over tid.
- Ved mer eller mindre lik belastning over tid øker først temperaturen og stabiliserer seg deretter i et visst område.
Deretter blir retningslinjene beskrevet ovenfor og ledig plass på hvert nivå tatt i betraktning. For klarhet vil jeg gi et bilde fra dokumentasjonen. Her indikerer røde, gule og blå farger blokker med henholdsvis høy, middels og lav temperatur.
Men la oss komme tilbake til oppgavene. Så vi kan begynne å analysere hva som gjøres for å løse FAST VP-problemer.
A. Distribusjon av data på tvers av ulike typer disker, nivåer
Faktisk er dette hovedoppgaven til FAST VP. Resten er på en måte avledet av det. Avhengig av den valgte policyen, vil data bli distribuert over ulike lagringsnivåer. Først av alt tas plasseringspolicyen i betraktning, deretter blokktemperaturen og størrelsen/hastigheten til RAID-grupper.
For retningslinjer for høyeste/laveste tilgjengelige nivå er alt ganske enkelt. For de to andre er dette tilfellet. Data fordeles på ulike nivåer med hensyn til størrelsen og ytelsen til RAID-grupper: slik at forholdet mellom den totale "temperaturen" til blokkene og den "betingede maksimale ytelsen" for hver RAID-gruppe er omtrent det samme. Dermed blir belastningen fordelt mer eller mindre jevnt. Mer etterspurte data flyttes til raske medier, og sjelden brukte data flyttes til tregere medier. Ideelt sett bør distribusjonen se omtrent slik ut:
B. Distribusjon av data mellom disker av samme type
Husk, i begynnelsen skrev jeg det lagringsmediet fra en eller fler nivåer er kombinert til ett basseng? Når det gjelder et enkelt nivå, har FAST VP også arbeid å gjøre. For å oppnå maksimal ytelse på et hvilket som helst nivå, er det tilrådelig å fordele data jevnt mellom diskene. Dette vil (i teorien) tillate deg å få maksimal mengde IOPS. Data innenfor en RAID-gruppe kan betraktes som fordelt jevnt over disker, men dette er ikke alltid tilfellet mellom RAID-grupper. I tilfelle ubalanse vil FAST VP flytte data mellom RAID-grupper i forhold til deres volum og "betinget ytelse" (i numeriske termer). For klarhetens skyld vil jeg vise et rebalanseringsskjema blant tre RAID-grupper:
B. Datadistribusjon ved utvidelse av bassenget
Denne oppgaven er et spesialtilfelle av den forrige og utføres når en RAID-gruppe legges til bassenget. For å sikre at den nylig tilførte RAID-gruppen ikke forblir inaktiv, vil noen av dataene bli overført til den, noe som betyr at lasten blir omfordelt på tvers av alle RAID-grupper.
SSD-slitasjeutjevning
Ved å bruke slitasjeutjevning kan FAST VP forlenge levetiden til en SSD, selv om denne funksjonen ikke er direkte relatert til Storage Tiering. Siden temperaturdata allerede er tilgjengelig, tas det også hensyn til antall skriveoperasjoner, og vi vet hvordan vi flytter datablokker, vil det være logisk for FAST VP å løse dette problemet.
Hvis antallet oppføringer i en RAID-gruppe betydelig overstiger antall oppføringer i en annen, vil FAST VP omfordele dataene i henhold til antall skriveoperasjoner. På den ene siden avlaster dette belastningen og sparer ressursen til noen disker, på den annen side legger det til "arbeid" for mindre belastede, og øker den generelle ytelsen.
På denne måten tar FAST VP de tradisjonelle utfordringene med Storage Tiering og gjør litt mer enn det. Alt dette lar deg lagre data ganske effektivt i Unity-lagringssystemet.
Noen tips
- Ikke glem å lese dokumentasjonen. Det er beste praksis, og de fungerer ganske bra. Hvis du følger dem, oppstår det som regel ingen alvorlige problemer. Resten av rådene gjentar eller utfyller dem i utgangspunktet.
- Hvis du har konfigurert og aktivert FAST VP, er det bedre å la det være aktivert. La den distribuere dataene i den tildelte tiden og litt etter litt enn en gang i året og ha en alvorlig innvirkning på utførelsen av andre oppgaver. I slike tilfeller kan omdistribuering av data ta lang tid.
- Vær forsiktig når du velger et flyttevindu. Selv om dette er åpenbart, prøv å velge et tidspunkt med minst belastning på Unity og avsett en tilstrekkelig tidsperiode.
- Planlegg å utvide lagringssystemet ditt, gjør det i tide. Dette er en generell anbefaling som også er viktig for FAST VP. Hvis mengden ledig plass er veldig liten, vil databevegelsen avta eller bli umulig. Spesielt hvis du forsømte punkt 2.
- Når du utvider en pool med FAST VP aktivert, bør du ikke starte med de tregeste diskene. Det vil si at vi enten legger til alle planlagte RAID-grupper på en gang, eller legger til de raskeste diskene først. I dette tilfellet vil redistribuering av data til nye "raske" disker øke den totale hastigheten til bassenget. Ellers kan det å starte med "trege" disker føre til en veldig ubehagelig situasjon. Først vil data overføres til nye, relativt trege disker, og deretter, når raskere legges til, i motsatt retning. Det er nyanser her knyttet til ulike FAST VP-policyer, men generelt er en lignende situasjon mulig.
Hvis du ser på dette produktet, kan du prøve Unity gratis ved å laste ned den virtuelle Unity VSA-enheten.
På slutten av materialet deler jeg flere nyttige lenker:
- Side
- – kort beskrivelse av funksjonen
- , pdf-format
Konklusjon
Jeg vil gjerne skrive om mye, men jeg forstår at ikke alle detaljene vil være interessante for leseren. Du kan for eksempel snakke mer detaljert om kriteriene som FAST VP tar beslutninger om dataoverføring etter, om prosessene for å analysere I/O-statistikk. Også temaet interaksjon med , og dette fortjener en egen artikkel. Du kan til og med fantasere om utviklingen av denne teknologien. Jeg håper det ikke var kjedelig, og jeg kjedet deg ikke. Ser deg igjen!
Kilde: www.habr.com