I dag handlar vi om en intressant teknik implementerad i lagringssystemet Unity/Unity XT â FAST VP. Om du hör om Unity för första gĂ„ngen kan du via lĂ€nken i slutet av artikeln bekanta dig med systemets egenskaper. Jag har arbetat i projektteamet pĂ„ Dell EMC med FAST VP i över ett Ă„r. Idag vill jag ge en mer detaljerad beskrivning av denna teknik och avslöja vissa detaljer om dess implementation. SjĂ€lvklart endast de som jag fĂ„r avslöja. Om du Ă€r intresserad av effektiva datalagringsfrĂ„gor eller bara inte helt har förstĂ„tt dokumentationen, kommer denna artikel garanterat att vara anvĂ€ndbar och intressant.
LÄt mig genast klargöra vad materialet inte kommer att innehÄlla. Det kommer inte att finnas nÄgon konkurrensanalys eller jÀmförelse med andra. Jag planerar heller inte att prata om liknande teknologier frÄn open source, eftersom nyfikna lÀsare redan kÀnner till dem. Och sjÀlvklart tÀnker jag inte reklamera för nÄgot.
LagringsnivÄindelning. MÄl och uppgifter för FAST VP
FAST VP stÄr för Fully Automated Storage Tiering for Virtual Pool. SvÄrt? Ingen fara, vi reder ut det. NivÄindelning Àr ett sÀtt att organisera datalagring dÀr det finns flera nivÄer (tiers) dÀr dessa data lagras. Varje nivÄ har sina egna egenskaper. De viktigaste Àr: prestanda, volym och kostnad för att lagra en enhet information. SjÀlvklart finns det ett samband mellan dem.
En viktig egenskap hos nivÄindelning Àr att Ätkomst till data tillhandahÄlls enhetligt oavsett vilken lagringsnivÄ de för nÀrvarande befinner sig pÄ, och storleken pÄ poolen Àr summan av storlekarna pÄ de resurser som ingÄr i den. HÀr ligger skillnaderna frÄn cachen: storleken pÄ cachen lÀggs inte till den totala storleken pÄ resurserna (poolen i detta fall), utan cachedata duplicerar en del av data frÄn den primÀra lagringsenheten (eller kommer att dupliceras om cachedata Ànnu inte har skrivits). Fördelningen av data över nivÄerna Àr Àven dold för anvÀndaren. Det vill sÀga, han ser inte vilken data som Àr placerad pÄ varje nivÄ, Àven om han kan pÄverka detta indirekt genom att ange policyer (mer om dem senare).
Nu ska vi titta pÄ egenskaperna hos implementationen av lagringsnivÄindelning i Unity. I Unity finns det tre nivÄer, eller tiers:
- Extrem prestanda (SSDs)
- Prestanda (SAS HDD 10k/15k RPM)
- Kapacitet (NL-SAS HDD 7200 RPM)
De presenteras i ordning efter prestanda och pris. I Extreme performance ingÄr enbart SSD-lagringsenheter. I de tvÄ andra nivÄerna ingÄr hÄrddiskar som skiljer sig Ät med avseende pÄ rotationshastighet och dÀrmed prestanda.
Lagringsenheter frĂ„n samma nivĂ„ och storlek sammanfogas i en RAID-konstruktion, vilket bildar en RAID-grupp (RAID group, förkortat â RG); om tillgĂ€ngliga och rekommenderade RAID-nivĂ„er kan du lĂ€sa i den officiella dokumentationen. FrĂ„n RAID-grupper med en eller flera nivĂ„er bildas lagringspooler (Storage pool) dĂ€r den lediga platsen senare fördelas. Och frĂ„n poolen allokeras utrymme för filsystem och LUN:er.
Vad behöver jag tiering för?
Kort och abstrakt sagt: för att uppnĂ„ större resultat med minimiresurser. Mer konkret avses med resultat oftast en samling egenskaper för lagringssystemet â hastighet och Ă„tkomsttid, lagringskostnad, och liknande. Med minimiressurser menas de lĂ€gsta kostnaderna: pengar, energi och sĂ„ vidare. FAST VP implementerar just mekanismer för omfördelning av data över olika nivĂ„er i Unity/Unity XT-lagringssystemet. Om ni tror mig kan ni hoppa över nĂ€sta stycke. För andra berĂ€ttar jag lite mer.
RÀtt fördelning av data över lagringsnivÄerna gör att man kan spara pÄ den totala kostnaden för lagringssystemet, genom att offra Ätkomsthastigheten till viss sÀllan anvÀnd information, och öka prestandan genom att flytta ofta anvÀnda data till snabbare enheter. HÀr kan nÄgon invÀnda att en normal administratör Àven utan tiering vet var olika data ska placeras, vilka egenskaper lagringssystemet bör ha för hans uppgift och sÄ vidare. Det Àr utan tvekan sant, men manuell datafördelning har sina nackdelar:
- krÀver tid och uppmÀrksamhet frÄn administratören;
- Àr det inte alltid möjligt att 'omforma' lagringssystemets resurser efter förÀndrade förhÄllanden;
- gÄr en viktig fördel förlorad: enhetlig Ätkomst till resurser som befinner sig pÄ olika lagringsnivÄer.
För att lagringsadministratörer ska vara mindre bekymrade över jobbsĂ€kerhet, vill jag tillĂ€gga att noggrann resursplanering ocksĂ„ behövs hĂ€r. Nu nĂ€r uppgifterna om tiering kortfattat har skisserats, lĂ„t oss se vad vi kan förvĂ€nta oss av FAST VP. HĂ€r Ă€r det dags att Ă„tergĂ„ till definitionen. De första tvĂ„ orden â Fully Automated â översĂ€tts ordagrant som "helt automatiserad" och betyder att fördelningen efter nivĂ„er sker automatiskt. Och Virtual Pool Ă€r en databas som bestĂ„r av resurser frĂ„n olika lagringsnivĂ„er. SĂ„ hĂ€r ser det ut:
För att gÄ hÀndelserna i förvÀg, sÀger jag att FAST VP endast flyttar data inom en pool, inte mellan flera pooler.
Uppgifter som löses av FAST VP
LÄt oss först prata abstrakt. Vi har en pool och en viss mekanism som kan omfördela data inom denna pool. Med tanke pÄ att vÄrt mÄl Àr att uppnÄ maximal prestanda, stÀller vi oss frÄgan: vilka sÀtt kan vi nÄ detta? Det kan finnas flera, och hÀr har FAST VP mycket att erbjuda anvÀndaren, eftersom tekniken representerar mer Àn bara lagrings-tiering. HÀr Àr de sÀtt som FAST VP kan öka prestandan i poolen:
- Fördelning av data över olika typer av diskar, nivÄer
- Fördelning av data bland diskar av samma typ
- Fördelning av data vid utvidgning av poolen
Innan vi gĂ„r igenom hur dessa uppgifter löses, behöver vi veta nĂ„gra viktiga fakta om hur FAST VP fungerar. FAST VP arbetar med block av en viss storlek â 256 megabyte. Det Ă€r det minsta kontinuerliga "stycket" data som kan flyttas. I dokumentationen kallas det just: slice. Ur FAST VPs synvinkel bestĂ„r alla RAID-grupper av en uppsĂ€ttning sĂ„dana "bitar". DĂ€rför samlas all statistik över in- och utdata för sĂ„dana datablock. Varför har just denna blockstorlek valts och kommer den att minskas? Blocket Ă€r tillrĂ€ckligt stort, men det Ă€r en avvĂ€gning mellan datagranularitet (mindre blockstorlek â mer exakt fördelning) och tillgĂ€ngliga berĂ€kningsresurser: med nuvarande hĂ„rda begrĂ€nsningar av det tillgĂ€ngliga minnet och ett stort antal block kan statistiken ta för mycket resurser, och antalet berĂ€kningar kommer att öka proportionellt.
Hur FAST VP placerar data i poolen. Policys
För att hantera datalagringen i en pool med aktiverad FAST VP finns det följande policies:
- Högsta tillgÀngliga nivÄ
- Auto-Tier
- Börja högt och sedan Auto-Tier (standard)
- LÀgsta tillgÀngliga nivÄ
De pÄverkar bÄde den ursprungliga placeringen av blocket (data som skrivs första gÄngen) och den efterföljande omfördelningen. NÀr data vÀl har placerats pÄ diskarna kommer omfördelningen att initieras enligt schema eller manuellt.
Högsta tillgÀngliga nivÄ försöker placera ett nytt block pÄ den mest prestandakraftiga nivÄn. Vid brist pÄ utrymme dÀr kommer det att placeras pÄ nÀsta bÀsta nivÄ, men senare kan data flyttas till en mer prestandakraftig nivÄ (om det finns utrymme eller genom att trÀnga bort andra data). Auto-Tier placerar nya data pÄ olika nivÄer beroende pÄ storleken pÄ det tillgÀngliga utrymmet, och de omfördelas baserat pÄ efterfrÄgan och ledigt utrymme. Börja högt och sedan Auto-Tier Àr standardpolicy och Àven den rekommenderade. Vid den initiala placeringen fungerar den som Högsta tillgÀngliga nivÄ, och dÀrefter flyttas data baserat pÄ deras anvÀndningsstatistik. Policyn LÀgsta tillgÀngliga nivÄ syftar till att placera data pÄ den minst prestandakraftiga nivÄn.
Dataflyttning sker med lÄg prioritet för att inte störa den nyttiga driften av lagringssystemet, men det finns en instÀllning för "Data relocation rate" som Àndrar prioriteten. HÀr finns en speciell egenskap: inte alla datablok har samma prioritering för omfördelning. Till exempel kommer block som Àr mÀrkta som metadata att flyttas till en snabbare nivÄ först. Metadata Àr, om man sÄ vill, "data om data", en slags extra information som inte Àr anvÀndardata, men som lagrar deras beskrivning. Till exempel, information i filsystemet om vilket block en specifik fil finns i. Det betyder att Ätkomsthastigheten till data beror pÄ Ätkomsthastigheten till metadata. Eftersom metadata vanligtvis Àr mycket mindre i storlek, förvÀntas vinsten av deras flytt till mer prestandakraftiga diskar vara större.
Kriterierna som Fast VP anvÀnder i sitt arbete
Huvudkriteriet för varje block, grovt sett, Àr egenskapen "efterfrÄgan" av data, som beror pÄ antalet lÀs- och skrivoperationer av datasegmentet. Denna egenskap kallar vi "Temperatur". Det finns efterfrÄgade (hot) data som Àr "hetare" Àn oanvÀnda. Den berÀknas periodiskt, som standard med en timmes intervall.
Funktionen för temperaturberÀkning har följande egenskaper:
- I avsaknad av in- och utdata "kyls" data över tid.
- Vid mer eller mindre konstant belastning ökar temperaturen först och stabiliseras sedan inom ett visst intervall.
DÀrefter beaktas de strategier som beskrivits ovan och det lediga utrymmet pÄ varje nivÄ. För tydlighetens skull tar jag med en bild frÄn dokumentationen. HÀr betecknas block med hög, medelhög och lÄg temperatur med röd, gul och blÄ fÀrg.
Men lÄt oss ÄtervÀnda till uppgifterna. SÄ, vi kan börja bryta ner vad som görs för att lösa FAST VP-uppgifterna.
A. Datafördelning över olika typer av diskar, nivÄer
Detta Àr i grund och botten huvuduppgiften för FAST VP. De andra Àr pÄ ett sÀtt hÀrledda frÄn den. Beroende pÄ den valda strategin kommer data att fördelas över olika lagringsnivÄer. Först och frÀmst beaktas placeringstrategin, sedan blockens temperatur och storlek/prestanda hos RAID-grupper.
För strategierna Högsta/LÀgsta tillgÀngliga nivÄ Àr det ganska enkelt. För de andra tvÄ ser det ut sÄ hÀr. Data fördelas över olika nivÄer med hÀnsyn till storlek och prestanda hos RAID-grupper: sÄ att förhÄllandet mellan den totala "temperaturen" av blocken och den "hypotetiska maximala prestandan" hos varje RAID-grupp Àr ungefÀr detsamma. PÄ sÄ sÀtt blir belastningen mer eller mindre jÀmnt fördelad. Mer efterfrÄgade data flyttas till snabba lagringsenheter, sÀllan anvÀnda till lÄngsammare. Idealiskt bör fördelningen se ut ungefÀr sÄ hÀr:
B. Datafördelning bland diskar av samma typ
Kom ihÄg, i början skrev jag att lagringsenheter frÄn ett eller flera Hur mÄnga nivÄer sammanfogas till en pool? NÀr det gÀller en enda nivÄ finns det ocksÄ arbete för FAST VP. För att maximera prestandan pÄ nÄgon nivÄ Àr det önskvÀrt att distribuera data jÀmnt mellan diskarna. Detta kommer i teorin att ge maximal mÀngd IOPS. Data inom en RAID-grupp kan betraktas som jÀmnt fördelade bland diskarna, men mellan RAID-grupper Àr det lÄngt ifrÄn alltid sÄ. Vid obalans kommer FAST VP att flytta data mellan RAID-grupper proportionellt mot deras volym och "villkorlig prestanda" (i numerisk form). För tydlighetens skull visar jag en rebalance-schema bland tre RAID-grupper:
B. Datafördelning vid utvidgning av poolen
Detta Ă€r ett sĂ€rskilt fall av föregĂ„ende och utförs nĂ€r en RAID-grupp lĂ€ggs till en pool. För att den nyanl ĐŽĐŸĐ±Đ°ĐČĐ”Đœ RAID-gruppen inte ska stĂ„ oanvĂ€nd kommer en del av data att flyttas till den, vilket innebĂ€r att belastningen pĂ„ alla RAID-grupper kommer att omfördelas.
UtjÀmning av SSD-slitage
Genom att anvÀnda utjÀmning av slitage kan FAST VP förlÀnga livslÀngden pÄ SSD:er, Àven om denna funktion inte direkt relaterar till Storage Tiering. Eftersom vi redan har data om temperaturen och antalet skrivoperationer beaktas, kan vi flytta datablok, sÄ det skulle vara logiskt för FAST VP att ocksÄ lösa denna uppgift.
Om antalet skrivningar till en RAID-grupp betydligt överstiger antalet skrivningar till en annan, kommer FAST VP att omfördela data i enlighet med antalet skrivoperationer. à ena sidan minskar detta belastningen och skyddar resurserna hos vissa diskar, Ä andra sidan ökar det "arbetsbelastningen" för de mindre belastade, vilket ökar den totala prestandan.
DÀrmed tar FAST VP pÄ sig de traditionella uppgifterna för Storage Tiering och gör Àven lite mer Àn sÄ. Allt detta gör att data kan lagras ganska effektivt inom Unity-familjen av lagringssystem.
NĂ„gra tips
- Försummas inte lĂ€sning av dokumentationen. Det finns bĂ€sta metoder, och de fungerar ganska bra. Om man följer dem uppstĂ„r vanligtvis inga allvarliga problem. Ăvriga rĂ„d upprepar eller kompletterar huvudsakligen dessa.
- Om du har konfigurerat och aktiverat FAST VP, Àr det bÀst att ha det aktiverat. LÄt det fördela data under den tid som Àr avsatt för det, istÀllet för att göra det en gÄng om Äret och pÄverka andra uppgifter negativt. I sÄdana fall kan datamigreringen ta lÄng tid.
- Var noga med att vĂ€lja rĂ€tt tid för relokeringen. Ăven om det Ă€r uppenbart, försök att vĂ€lja en tid med lĂ€gst belastning pĂ„ Unity och avsĂ€tt tillrĂ€ckligt med tid.
- Planera för att utöka lagringssystemet i tid. Det hÀr Àr en allmÀn rekommendation som Àven Àr viktig för FAST VP. Om mÀngden ledigt utrymme Àr mycket liten, kommer dataöverföringen att bli lÄngsammare eller omöjlig. SÀrskilt om du har Äsidosatt punkt 2.
- NÀr du expanderar poolen med aktiverat FAST VP, bör du inte börja med de lÄngsammaste diskarna. Det vill sÀga, antingen lÀgger du till alla planerade RAID-grupper pÄ en gÄng, eller sÄ börjar du först med de snabbaste diskarna. PÄ sÄ sÀtt kommer dataöverföringen till de nya 'snabba' diskarna att öka den totala hastigheten pÄ poolen. Annars, om du börjar med de 'lÄngsamma' diskarna, kan du hamna i en vÀldigt obehaglig situation. Först kommer data att överföras till de nya, relativt lÄngsamma diskarna, och sedan, nÀr snabbare lÀggs till, kommer det att gÄ i motsatt riktning. HÀr finns det nyanser kopplade till olika FAST VP-policies, men i allmÀnhet Àr en sÄdan situation möjlig.
Om du övervÀger denna produkt kan du prova Unity gratis genom att ladda ner Unity VSA virtual appliance.
Avslutningsvis delar jag nÄgra anvÀndbara lÀnkar:
- Sida
- â en kort beskrivning av funktionen
- , PDF-format
Slutsats
Det finns mycket jag vill skriva om, men jag förstĂ„r att inte alla detaljer kommer att intressera lĂ€saren. Till exempel kan man berĂ€tta mer om kriterierna som FAST VP anvĂ€nder för att fatta beslut om dataöverföring, samt om processerna för analys av in- och utdata-statistik. Ămnet för interaktionen med , det Ă€r nĂ€stan en egen artikel. Man kan till och med spekulera kring utvecklingen av denna teknik. Jag hoppas att det inte var trĂ„kigt och att jag inte uttröttade er. Tills nĂ€sta gĂ„ng!
KĂ€lla: habr.com
