Idag kommer vi att prata om en intressant teknik implementerad i Unity/Unity XT lagringssystem - FAST VP. Om det här är första gången du hör talas om Unity kan du kolla in systemets egenskaper genom att använda länken i slutet av artikeln. Jag arbetade på FAST VP i Dells EMC-projektteam i över ett år. Idag vill jag prata om denna teknik mer i detalj och avslöja några detaljer om dess genomförande. Naturligtvis bara de som får avslöjas. Om du är intresserad av frågor om effektiv datalagring eller helt enkelt inte helt har förstått dokumentationen, kommer den här artikeln säkert att vara användbar och intressant.
Jag ska genast berätta vad som inte finns i materialet. Det blir ingen sökning efter konkurrenter och jämförelse med dem. Jag planerar inte heller att prata om liknande teknologier från öppen källkod, eftersom den nyfikna läsaren redan vet om dem. Och självklart tänker jag inte annonsera någonting.
Lagringsnivå. Mål och mål för FAST VP
FAST VP står för Fully Automated Storage Tiering för Virtual Pool. Lite svårt? Inga problem, vi ska reda ut det nu. Tiering är ett sätt att organisera datalagring där det finns flera nivåer (tiers) där denna data lagras. Var och en har sina egna egenskaper. Det viktigaste: prestanda, volym och pris för att lagra en informationsenhet. Naturligtvis finns det ett förhållande mellan dem.
En viktig egenskap med nivådelning är att åtkomst till data tillhandahålls enhetligt oavsett på vilken lagringsnivå den för närvarande är belägen, och storleken på poolen är lika med summan av storleken på de resurser som ingår i den. Det är här skillnaderna från cachen ligger: storleken på cachen läggs inte till den totala volymen av resursen (poolen i det här fallet), och cachedata duplicerar något fragment av huvudmediadata (eller kommer att dupliceras om data från cachen har ännu inte skrivits). Dessutom är distributionen av data efter nivåer dold för användaren. Det vill säga, han ser inte exakt vilken data som finns på varje nivå, även om han kan påverka detta indirekt genom att sätta policyer (mer om dem senare).
Låt oss nu titta på funktionerna i implementeringen av lagringsnivåer i Unity. Unity har 3 nivåer, eller nivå:
- Extrem prestanda (SSD)
- Prestanda (SAS HDD 10k/15k RPM)
- Kapacitet (NL-SAS HDD 7200 RPM)
De presenteras i fallande ordning efter prestanda och pris. Extrem prestanda inkluderar endast solid state-enheter (SSD). De andra två nivåerna inkluderar magnetiska diskenheter, som skiljer sig åt i rotationshastighet och följaktligen prestanda.
Lagringsmedia från samma nivå och samma storlek kombineras till en RAID-array och bildar en RAID-grupp (RAID-grupp, förkortad RG); Du kan läsa om tillgängliga och rekommenderade RAID-nivåer i den officiella dokumentationen. Lagringspooler bildas av RAID-grupper från en eller flera nivåer, från vilka ledigt utrymme sedan distribueras. Och från poolen tilldelas utrymme för filsystem och LUN.
Varför behöver jag Tiering?
Kort och abstrakt: för att uppnå bättre resultat med ett minimum av resurser. Mer specifikt förstås resultatet vanligtvis som en uppsättning lagringssystemegenskaper - hastighet och åtkomsttid, lagringskostnad och andra. Minsta resurser betyder minsta utgifter: pengar, energi och så vidare. FAST VP implementerar mekanismer för att omfördela data över olika nivåer i Unity/Unity XT-lagringssystem. Om du tror mig kan du hoppa över nästa stycke. I övrigt ska jag berätta lite mer.
Korrekt distribution av data över lagringsnivåer gör att du kan spara på den totala kostnaden för lagring genom att offra åtkomsthastigheten till viss information som sällan används, och förbättra prestandan genom att flytta ofta använda data till snabbare media. Här kan någon hävda att även utan nivåindelning vet en normal administratör var man ska placera vilken data, vilka är de önskvärda egenskaperna hos ett lagringssystem för sin uppgift, etc. Detta är utan tvekan sant, men manuell distribution av data har sina nackdelar:
- kräver tid och uppmärksamhet från administratören;
- Det är inte alltid möjligt att ”rita om” lagringsresurser för att passa förändrade förhållanden;
- en viktig fördel försvinner: enhetlig tillgång till resurser som finns på olika lagringsnivåer.
För att få lagringsadministratörer att oroa sig mindre för jobbsäkerhet, vill jag tillägga att kompetent resursplanering är nödvändig även här. Nu när uppgifterna med nivåindelning beskrivs kortfattat, låt oss ta en titt på vad du kan förvänta dig av FAST VP. Nu är det dags att återgå till definitionen. De två första orden – Helautomatiskt – översätts bokstavligen som ”helautomatiserat” och betyder att fördelningen mellan nivåerna sker automatiskt. Jo, Virtual Pool är en datapool som innehåller resurser från olika lagringsnivåer. Så här ser det ut:
Framöver kommer jag att säga att FAST VP flyttar data endast inom en pool, och inte mellan flera pooler.
Problem lösta av FAST VP
Låt oss prata abstrakt först. Vi har en pool och någon mekanism som kan omfördela data inom denna pool. När vi kommer ihåg att vårt mål är att uppnå maximal produktivitet, låt oss fråga oss själva: på vilka sätt kan vi uppnå det? Det kan finnas flera av dem, och här har FAST VP något att erbjuda användaren, eftersom tekniken är något mer än bara lagringsnivåer. Här är några sätt på vilka FAST VP kan öka poolens prestanda:
- Fördelning av data över olika typer av diskar, nivåer
- Fördelning av data mellan diskar av samma typ
- Datadistribution vid utbyggnad av poolen
Innan vi tittar på hur dessa uppgifter löses behöver vi veta några nödvändiga fakta om hur FAST VP fungerar. FAST VP arbetar med block av en viss storlek - 256 megabyte. Detta är den minsta sammanhängande "bit" av data som kan flyttas. I dokumentationen är detta vad de kallar det: skiva. Ur FAST VPs synvinkel består alla RAID-grupper av en uppsättning sådana "bitar". Följaktligen ackumuleras all I/O-statistik för sådana datablock. Varför valdes denna blockstorlek och kommer den att minskas? Blocket är ganska stort, men detta är en kompromiss mellan datas granularitet (mindre blockstorlek betyder mer exakt distribution) och tillgängliga datorresurser: med tanke på de befintliga strikta begränsningarna för RAM och ett stort antal block kan statistikdata ta upp för mycket, och antalet beräkningar kommer att öka proportionellt.
Hur FAST VP allokerar data till poolen. Politiker
För att styra placeringen av data i en pool med FAST VP aktiverat finns följande policyer:
- Högsta tillgängliga nivå
- Auto-Tier
- Starta högt och sedan Auto-Tier (standard)
- Lägsta tillgängliga nivå
De påverkar både den initiala blockallokeringen (data som först skrivs) och efterföljande omallokering. När data redan finns på diskar, kommer omdistribution att initieras enligt ett schema eller manuellt.
Högsta tillgängliga nivå försöker placera ett nytt block på den högsta nivån. Om det inte finns tillräckligt med utrymme på den placeras den på den näst mest produktiva nivån, men då kan data flyttas till en mer produktiv nivå (om det finns utrymme eller genom att förskjuta annan data). Auto-Tier placerar ny data på olika nivåer beroende på mängden tillgängligt utrymme, och den omfördelas beroende på efterfrågan och ledigt utrymme. Börja högt, då är Auto-Tier standardpolicyn och rekommenderas också. När den först placeras fungerar den som den högsta tillgängliga nivån, och sedan flyttas data beroende på dess användningsstatistik. Policyn för lägsta tillgängliga nivå syftar till att placera data i den minst produktiva nivån.
Dataöverföring sker med låg prioritet för att inte störa lagringssystemets användbara funktion, men det finns en inställning för "Dataflyttningshastighet" som ändrar prioriteten. Det finns en egenhet här: inte alla datablock har samma omfördelningsordning. Till exempel kommer block markerade som metadata att flyttas till en snabbare nivå först. Metadata är så att säga ”data om data”, viss ytterligare information som inte är användardata, utan lagrar dess beskrivning. Till exempel information i filsystemet om vilket block en viss fil finns i. Detta innebär att hastigheten för åtkomst till data beror på hastigheten för åtkomst till metadata. Med tanke på att metadata vanligtvis är mycket mindre i storlek, förväntas fördelarna med att flytta den till hårddiskar med högre prestanda vara större.
Kriterier som Fast VP använder i sitt arbete
Huvudkriteriet för varje block, mycket grovt, är egenskapen för "efterfrågan" av data, vilket beror på antalet läs- och skrivoperationer för ett datafragment. Vi kallar denna egenskap "temperatur". Det finns efterfrågad (het) data som är "hetare" än outnyttjad data. Den beräknas periodiskt, som standard med en timmes intervall.
Temperaturberäkningsfunktionen har följande egenskaper:
- I frånvaro av I/O "kylar data" över tiden.
- Under mer eller mindre lika belastning över tid ökar först temperaturen och stabiliseras sedan i ett visst intervall.
Därefter beaktas policyerna som beskrivs ovan och det lediga utrymmet på varje nivå. För tydlighetens skull kommer jag att tillhandahålla en bild från dokumentationen. Här indikerar röda, gula och blå färger block med hög, medel respektive låg temperatur.
Men låt oss återgå till uppgifterna. Så vi kan börja analysera vad som görs för att lösa FAST VP-problem.
A. Fördelning av data över olika typer av diskar, nivåer
Egentligen är detta huvuduppgiften för FAST VP. Resten är på sätt och vis härledda av det. Beroende på vald policy kommer data att distribueras över olika lagringsnivåer. Först och främst beaktas placeringspolicyn, sedan blocktemperaturen och storleken/hastigheten på RAID-grupper.
För högsta/lägsta tillgängliga nivå-policyer är allt ganska enkelt. För de andra två är detta fallet. Data fördelas över olika nivåer med hänsyn till storleken och prestanda för RAID-grupper: så att förhållandet mellan den totala "temperaturen" för blocken och den "villkorliga maximala prestandan" för varje RAID-grupp är ungefär detsamma. Därmed fördelas belastningen mer eller mindre jämnt. Mer efterfrågad data flyttas till snabba medier och sällan använda data flyttas till långsammare media. Helst bör fördelningen se ut så här:
B. Fördelning av data mellan diskar av samma typ
Kom ihåg, i början skrev jag det lagringsmediet från en eller flera nivåer kombineras till en pool? När det gäller en enda nivå har FAST VP också arbete att göra. För att uppnå maximal prestanda på alla nivåer är det lämpligt att fördela data jämnt mellan diskarna. Detta kommer (i teorin) att tillåta dig att få maximal mängd IOPS. Data inom en RAID-grupp kan anses fördelad jämnt över diskar, men detta är inte alltid fallet mellan RAID-grupper. I händelse av obalans kommer FAST VP att flytta data mellan RAID-grupper i proportion till deras volym och "villkorlig prestanda" (i numeriska termer). För tydlighetens skull kommer jag att visa ett ombalanseringsschema bland tre RAID-grupper:
B. Datadistribution vid utbyggnad av poolen
Den här uppgiften är ett specialfall av den föregående och utförs när en RAID-grupp läggs till i poolen. För att säkerställa att den nyligen tillagda RAID-gruppen inte förblir inaktiv kommer en del av data att överföras till den, vilket innebär att belastningen kommer att omfördelas över alla RAID-grupper.
SSD Slitage Leveling
Genom att använda slitageutjämning kan FAST VP förlänga livslängden på en SSD, även om denna funktion inte är direkt relaterad till Storage Tiering. Eftersom temperaturdata redan finns tillgänglig, tas även hänsyn till antalet skrivoperationer, och vi vet hur man flyttar datablock, skulle det vara logiskt för FAST VP att lösa detta problem.
Om antalet poster i en RAID-grupp avsevärt överstiger antalet poster i en annan, kommer FAST VP att omfördela data i enlighet med antalet skrivoperationer. Å ena sidan avlastar detta belastningen och sparar resurserna för vissa diskar, å andra sidan lägger det till "arbete" för mindre laddade, vilket ökar den totala prestandan.
På så sätt tar FAST VP sig an de traditionella utmaningarna med Storage Tiering och gör lite mer än så. Allt detta gör att du kan lagra data ganska effektivt i Unity-lagringssystemet.
Några tips
- Försumma inte att läsa dokumentationen. Det finns bästa praxis, och de fungerar ganska bra. Om du följer dem, uppstår som regel inga allvarliga problem. Resten av råden upprepar eller kompletterar dem i princip.
- Om du har konfigurerat och aktiverat FAST VP är det bättre att låta det vara aktiverat. Låt den distribuera data på sin tilldelade tid och lite i taget än en gång om året och ha en allvarlig inverkan på utförandet av andra uppgifter. I sådana fall kan omfördelning av data ta lång tid.
- Var försiktig när du väljer flyttfönster. Även om detta är uppenbart, försök att välja en tid med minsta belastning på Unity och tilldela en tillräcklig tidsperiod.
- Planera att utöka ditt lagringssystem, gör det i tid. Detta är en allmän rekommendation som också är viktig för FAST VP. Om mängden ledigt utrymme är mycket liten, kommer datarörelsen att sakta ner eller bli omöjlig. Speciellt om du struntade i punkt 2.
- När du utökar en pool med FAST VP aktiverat bör du inte börja med de långsammaste diskarna. Det vill säga, vi lägger antingen till alla planerade RAID-grupper på en gång, eller lägger till de snabbaste diskarna först. I det här fallet kommer omfördelning av data till nya "snabba" diskar att öka poolens totala hastighet. Annars kan att börja med "långsamma" diskar leda till en mycket obehaglig situation. Först kommer data att överföras till nya, relativt långsamma diskar, och sedan, när snabbare läggs till, i motsatt riktning. Det finns nyanser här relaterade till olika FAST VP-policyer, men i allmänhet är en liknande situation möjlig.
Om du tittar på den här produkten kan du prova Unity gratis genom att ladda ner den virtuella Unity VSA-enheten.
I slutet av materialet delar jag flera användbara länkar:
- Sida
- – kort beskrivning av funktionen
- , pdf-format
Slutsats
Jag skulle vilja skriva om mycket, men jag förstår att inte alla detaljer kommer att vara intressanta för läsaren. Du kan till exempel prata mer i detalj om kriterierna för vilka FAST VP fattar beslut om dataöverföring, om processerna för att analysera I/O-statistik. Även ämnet interaktion med , och detta förtjänar en separat artikel. Du kan till och med fantisera om utvecklingen av denna teknik. Jag hoppas att det inte var tråkigt och att jag inte tråkade ut dig. Vi ses!
Källa: will.com