I fortsĂ€ttningen av diskussionen om teknologier för att pĂ„skynda in- och utdataoperationer i samband med lagringssystem, inledda i , Ă€r det oavvisligt att nĂ€mna en populĂ€r funktion, nĂ€mligen tiering (Auto Tiering). Ăven om grundidĂ©n bakom denna funktion Ă€r ganska likartad hos olika tillverkare av lagringssystem, kommer vi att granska sĂ€rdragen i implementeringen av tiering med Qsan .
Trots mÄngfalden av data som lagras pÄ lagringssystemet, kan dessa data delas in i flera grupper beroende pÄ deras efterfrÄgan (anvÀndningsfrekvens). För de mest populÀra ("heta") data Àr det avgörande att organisera snabbt tillgÄng, medan mindre efterfrÄgade ("kalla") data kan behandlas med lÀgre prioritet.
För att organisera en sÄdan struktur anvÀnds exakt tiering-funktionen. I det hÀr fallet bestÄr datamÀngden inte av enhetliga diskar, utan av flera grupper av enheter som bildar olika lagringsnivÄer (tier). Genom en speciell algoritm flyttas data automatiskt mellan nivÄerna för att sÀkerstÀlla maximal total prestanda.
Lagring stöder upp till tre lagringsnivÄer:
- Tier 1: SSD, maximal prestanda
- Tier 2: HDD SAS 10K/15K, hög prestanda
- Tier 3: HDD NL-SAS 7.2K, maximal kapacitet
Auto Tiering-poolen kan innehÄlla alla tre nivÄerna eller bara tvÄ i valfria kombinationer. Inom varje Tier grupperas enheterna i vanliga RAID-grupper. För maximal flexibilitet kan RAID-nivÄn i varje Tier vara olika. D.v.s. till exempel, det finns inget som hindrar att organisera en struktur som 4x SSD RAID10 + 6x HDD 10K RAID5 + 12 HDD 7.2K RAID6.
Efter skapandet av volymer (virtuella diskar) pÄ -poolen börjar bakgrundssamlingen av statistik om alla in- och utdataoperationer. För detta delades utrymmet upp i block med en storlek pÄ 1 GB (s.k. sub LUN). Vid varje tillgÄng till ett sÄdant block tilldelas det en koefficient pÄ 1. Med tiden minskar denna koefficient. Efter 24 timmar, vid avsaknad av in- och utdataförfrÄgningar till detta block, kommer den att vara 0.5 och fortsÀtter att falla varje efterföljande timme.
Vid en viss tidpunkt (som standard varje dag vid midnatt) rangordnas de insamlade resultaten baserat pÄ aktiviteten i sub LUN efter deras poÀng. Baserat pÄ detta fattas beslut om vilka block som ska flyttas och i vilken riktning. DÀrefter sker faktiskt relokaliseringen av data mellan nivÄerna.
I Qsan-lagringssystemet Àr hanteringen av tiering-processen utmÀrkt implementerad med hjÀlp av mÄnga parametrar, vilket möjliggör en mycket flexibel anpassning av den slutgiltiga prestandan för arrayen.
För att bestÀmma det initiala lÀget för data och den prioriterade riktningen för deras flyttning anvÀnds policies som anges separat för varje volym:
- Auto Tiering â standardpolicy, dĂ€r den initiala placeringen och riktningen för flyttningen bestĂ€ms automatiskt, dvs. "heta" data strĂ€var efter att hamna pĂ„ den översta nivĂ„n, medan "kalla" data glider ner. Den initiala placeringen vĂ€ljs baserat pĂ„ det tillgĂ€ngliga utrymmet pĂ„ varje nivĂ„. Men det Ă€r viktigt att förstĂ„ att systemet i första hand strĂ€var efter att maximalt utnyttja de snabbaste lagringsenheterna. SĂ„ledes, om det finns ledigt utrymme, kommer data att placeras pĂ„ de övre nivĂ„erna. Denna policy passar de flesta scenarier dĂ€r efterfrĂ„gan pĂ„ data inte kan förutses i förvĂ€g.
- Börja med hög nivĂ„, och sedan Auto Tiering â skillnaden frĂ„n den föregĂ„ende Ă€r endast i den initiala placeringen av data (pĂ„ den snabbaste nivĂ„n)
- Maximalt hög nivĂ„ â data strĂ€var alltid efter att ta den snabbaste nivĂ„n. Om de under arbetets gĂ„ng flyttas nedĂ„t, kommer de att flyttas tillbaka sĂ„ snart som möjligt. Denna policy passar för data som krĂ€ver den snabbaste Ă„tkomsten.
- Minimalt nivĂ„ â data strĂ€var alltid efter att ta den lĂ€gsta nivĂ„n. Denna policy Ă€r utmĂ€rkt för sĂ€llan anvĂ€nda data (till exempel arkiv).
- Ingen flyttning â systemet identifierar automatiskt det initiala lĂ€get för data och utför inga flyttningar. Statistik fortsĂ€tter dock att samlas in ifall det senare skulle bli nödvĂ€ndigt med relokalisering.
Det Àr vÀrt att notera att Àven om policies definieras vid skapandet av varje volym, kan de Àndras flera gÄnger "i realtid" under systemets livscykel.
Utöver politik för tiering-mekanismen kan Ă€ven frekvens och takt för dataflytt mellan nivĂ„er stĂ€llas in. Specifika tider för flytt kan anges: dagligen eller pĂ„ utvalda veckodagar, samt minska intervallen för statistikinsamling till nĂ„gra timmar (minimalt intervall â 2 timmar). Om det behövs kan tidsramar (fönster för flytt) anges för att begrĂ€nsa tiden för dataflytt. Dessutom anges Ă€ven hastigheten för relokering â 3 lĂ€gen: snabbt, medelhastighet, lĂ„ngsamt.
Vid behov av omedelbar relokering av data finns möjlighet att utföra detta manuellt nÀr som helst pÄ begÀran av administratören.
Det Àr uppenbart att ju oftare och snabbare data flyttas mellan nivÄerna, desto mer flexibelt kommer lagringssystemet att anpassa sig efter aktuella driftsförhÄllanden. Men man bör ocksÄ komma ihÄg att flyttning medför en extra belastning (framför allt pÄ diskarna), sÄ data bör inte flyttas utan verkligt behov. Det Àr bÀttre att planera flyttningen till tider med minimal belastning. Om lagringssystemets arbete stÀndigt krÀver hög prestanda i ett 24/7-lÀge, bör hastigheten pÄ relokeringen sÀnkas till minimalt.
MÀngden instÀllningar för tiering kommer utan tvekan att glÀdja avancerade anvÀndare. Men Àven för dem som möter denna teknik för första gÄngen finns det inget att vara rÀdd för. StandardinstÀllningarna (Auto Tiering-politik, flyttning med maximal hastighet en gÄng per natt) kan tryggt anvÀndas, och i takt med att statistik samlas in kan olika parametrar justeras för att uppnÄ önskat resultat.
NÀr man jÀmför tiering med en lika populÀr teknik för att öka prestanda, som , bör man komma ihÄg de olika principerna bakom deras algoritmer.
SSD-caching
Auto Tiering
Tidsramen för effekten
NÀstan omedelbart. Men den mÀrkbara effekten kommer först efter att cachen har "vÀrmts upp" (minuter-timmar)
Efter insamling av statistik (frĂ„n 2 timmar, i idealfallet â en dag) plus tid för dataflytt
Effektens varaktighet
Tills data ersÀtts av en ny uppsÀttning (minuter-timmar)
Tills efterfrÄgan pÄ data Àr aktuell (en dag och mer)
Indikationer för anvÀndning
Omedelbar ökning av prestanda under kort tid (databaser, virtualiseringsmiljöer)
Ăkning av prestanda under en lĂ€ngre period (fil-, web-, och e-postservrar)
En annan egenskap hos tiering Àr möjligheten att anvÀnda det inte bara för scenarier av typen "SSD + HDD", utan Àven "snabba HDD + lÄngsamma HDD" eller till och med alla tre nivÄer, vilket i princip Àr omöjligt vid anvÀndning av SSD-cache.
Testning
För att testa funktionen hos tiering-algoritmerna genomförde vi ett enkelt test. En pool skapades bestÄende av tvÄ nivÄer SSD (RAID 1) + 7.2K HDD (RAID1), dÀr en volym med policy för "lÀgsta nivÄ" placerades. Det vill sÀga, data skulle alltid ligga pÄ de lÄngsammare diskarna.
AnvÀndargrÀnssnittet visar tydligt hur data placeras mellan nivÄerna
Efter att volymen hade fyllts med data Àndrade vi placeringspolicyn till Auto Tiering och körde IOmeter-testet.
Efter flera timmars testande, nÀr systemet lyckades samla statistik, inleddes omplaceringsprocessen.
Vid slutet av dataflyttningen hade vÄr testvolym helt "krupit" upp till den översta nivÄn (SSD).
UtvÀrdering
Auto Tiering Àr en fantastisk teknologi som gör det möjligt att öka prestandan för lagringssystemet med minimala materiella och tidsmÀssiga kostnader genom mer intensiv anvÀndning av snabba enheter. Applicerad pÄ den enda investeringen Àr licensen, som köps en gÄng för alla utan begrÀnsningar för volym/antal diskar/hyllor/osv. Denna funktionalitet kommer med sÄ rika instÀllningar att den kan tillfredsstÀlla praktiskt taget alla affÀrsbehov. Visualiseringen av processerna i grÀnssnittet gör att man effektivt kan hantera enheten.
KĂ€lla: habr.com
