Vandaag bespreken we een interessante technologie die is geïmplementeerd in de Unity/Unity XT storage, namelijk FAST VP. Als je voor het eerst van Unity hoort, kun je via de link aan het einde van het artikel meer te weten komen over de specificaties van het systeem. In het projectteam van Dell EMC heb ik meer dan een jaar aan FAST VP gewerkt. Vandaag wil ik dieper ingaan op deze technologie en enkele details van de implementatie onthullen. Uiteraard alleen de details die ik mag delen. Als je geïnteresseerd bent in effectieve dataopslag of gewoon niet helemaal bekend bent met de documentatie, zal dit artikel zeker nuttig en interessant zijn.
Ik zal meteen zeggen wat er niet in dit artikel staat. Er zal geen concurrentieanalyse worden uitgevoerd en ik zal niet vergelijken met andere vergelijkbare technologieën van open source, omdat geïnteresseerde lezers daar al van op de hoogte zijn. En natuurlijk heb ik geen intentie om iets te adverteren.
Storage Tiering. Doelen en taken van FAST VP
FAST VP staat voor Fully Automated Storage Tiering for Virtual Pool. Klinkt ingewikkeld? Geen zorgen, we zullen het uit elkaar halen. Tiering is een methode van dataopslagorganisatie waarbij er verschillende niveaus (tiers) zijn waar deze gegevens worden opgeslagen. Elk niveau heeft zijn eigen kenmerken. De belangrijkste zijn: prestaties, capaciteit en kosten voor het opslaan van één informatie-eenheid. Uiteraard is er een relatie tussen deze factoren.
Een belangrijke eigenschap van tiering is dat toegang tot gegevens uniform wordt verleend, ongeacht op welk opslagniveau ze zich bevinden. De grootte van de pool is gelijk aan de som van de dimensies van de bronnen die erin zijn opgenomen. Hierin ligt het verschil met cache: de grootte van de cache wordt niet opgeteld bij het totale volume van de bron (de pool in dit geval), en de gegevens in de cache dupliceren een fragment van de gegevens op het primaire opslagmedium (of zullen dat doen als de gegevens uit de cache nog niet zijn geschreven). Bovendien is de verdeling van gegevens over de niveaus verborgen voor de gebruiker. Dit betekent dat ze niet kunnen zien welke specifieke gegevens op elk niveau zijn geplaatst, hoewel ze dit indirect kunnen beïnvloeden door beleid (hierover later meer) in te stellen.
Laten we nu kijken naar de kenmerken van de implementatie van storage tiering in Unity. In Unity worden 3 niveaus, of tiers, onderscheiden:
- Extreme performance (SSDs)
- Performance (SAS HDD 10k/15k RPM)
- Capacity (NL-SAS HDD 7200 RPM)
Ze zijn gerangschikt op aflopende prestaties en prijs. In Extreme performance worden uitsluitend solid-state drives (SSD) opgenomen. In de andere twee tiers – schijven met magnetische opslag, die verschillen in rotatiesnelheid en daarmee in prestaties.
Opslagmedia van één niveau en dezelfde grootte worden samengevoegd in een RAID-array, wat een RAID-groep (RAID group, afgekort – RG) vormt; u kunt meer lezen over beschikbare en aanbevolen RAID-niveaus in de officiële documentatie. Uit RAID-groepen van één of meerdere niveaus worden opslagpools (Storage pool) gevormd, van waaruit beschikbare ruimte vervolgens wordt verdeeld. Uit de pool wordt ruimte toegewezen aan bestandssystemen en LUN's.
Waarom heb ik tiering nodig?
Kort samengevat en abstract: om een groter resultaat te behalen met minimale middelen. Meer specifiek wordt met resultaat meestal de combinatie van kenmerken van de SCSI-oplossingen bedoeld – snelheid en toegangstijd, opslagkosten en andere. Met minimale middelen worden de laagste kosten bedoeld: geld, energie, enz. FAST VP implementeert precies de mechanismen voor het herschikken van gegevens over verschillende niveaus binnen de Unity/Unity XT SCSI-systemen. Als je me gelooft, kun je de volgende alinea overslaan. Voor de anderen vertel ik wat meer.
Een juiste distributie van gegevens over opslagniveaus helpt om de totale kosten van de SCSI-oplossing te verlagen, door de toegangssnelheid naar minder vaak gebruikte informatie op te schorten, en de prestaties te verhogen door vaak gebruikte gegevens naar snellere opslagmedia te verplaatsen. Hier kan iemand inbrengen dat een goede admin ook zonder tiering weet waar welke gegevens moeten worden geplaatst, wat voor hem wenselijke kenmerken van de SCSI-oplossing zijn, enz. Dat klopt zeker, maar handmatige distributie van gegevens heeft zijn nadelen:
- het vereist tijd en aandacht van de administrator;
- het is niet altijd mogelijk om de SCSI-bronnen aan te passen aan veranderde omstandigheden;
- een belangrijk voordeel vervalt: uniforme toegang tot bronnen die zich op verschillende opslagniveaus bevinden.
Om ervoor te zorgen dat storage-beheerders zich minder zorgen maken over hun baanzekerheid, voeg ik eraan toe dat een goede planning van middelen ook hier noodzakelijk is. Nu de taken van tiering kort zijn geschetst, laten we eens bekijken wat we van FAST VP kunnen verwachten. Dit is het moment om terug te keren naar de definitie. De eerste twee woorden – Fully Automated – worden letterlijk vertaald als "volledig geautomatiseerd" en betekenen dat de indeling van niveaus automatisch gebeurt. Een Virtual Pool is een pool van gegevens die middelen van verschillende opslagniveaus omvat. Zo ziet het eruit:
Om vooruit te lopen, kan ik zeggen dat FAST VP gegevens alleen binnen één pool verplaatst, en niet tussen meerdere pools.
Taken die door FAST VP worden opgelost
Laten we eerst abstract praten. We hebben een pool en een mechanisme dat gegevens binnen deze pool kan herschikken. Houdend in gedachten dat onze taak is om de maximale prestaties te bereiken, stellen we ons de vraag: op welke manieren kan dit worden bereikt? Er kunnen verschillende manieren zijn, en hier heeft FAST VP wat te bieden aan de gebruiker, aangezien de technologie meer is dan alleen storage tiering. Dit zijn de manieren waarop FAST VP de prestaties van de pool kan verhogen:
- Verdeling van gegevens over verschillende soorten schijven en niveaus
- Verdeling van gegevens binnen schijven van hetzelfde type
- Verdeling van gegevens bij het uitbreiden van de pool
Voordat we bekijken hoe deze taken worden opgelost, moeten we enkele noodzakelijke feiten over het functioneren van FAST VP weten. FAST VP werkt met blokken van een bepaalde grootte – 256 megabyte. Dit is het minimale continue "stuk" gegevens dat kan worden verplaatst. In de documentatie wordt het zo genoemd: slice. Vanuit het perspectief van FAST VP bestaan alle RAID-groepen uit een set van dergelijke "stukken". Dienovereenkomstig worden alle statistieken over in- en uitgaand verkeer verzameld voor dergelijke datablocks. Waarom is precies deze blokgrootte gekozen en zal deze worden verkleind? De blokgrootte is vrij groot, maar dit is een compromis tussen de granulariteit van de gegevens (een kleinere blokgrootte leidt tot een nauwkeurigere verdeling) en de beschikbare rekenmiddelen: bij de huidige strikte beperkingen van het geheugen en een groot aantal blokken kunnen gegevensstatistieken te veel ruimte innemen, waardoor het aantal berekeningen evenredig toeneemt.
Hoe FAST VP gegevens in de pool plaatst. Beleid
Om gegevensplaatsing in een pool met ingeschakelde FAST VP te beheren, zijn er de volgende beleidsregels:
- Hoogste Beschikbare Niveau
- Auto-Tier
- Begin Hoog en dan Auto-Tier (standaard)
- Laagste Beschikbare Niveau
Ze hebben invloed op zowel de initiële plaatsing van een blok (data die voor het eerst worden geschreven) als op de daaropvolgende herschikking. Zodra de gegevens op de schijven zijn geplaatst, wordt herschikking gestart volgens een schema of handmatig.
Hoogste Beschikbare Niveau probeert een nieuw blok op het meest prestatiegerichte niveau te plaatsen. Bij gebrek aan ruimte op dat niveau, op het volgende prestatie-niveau, maar daarna kunnen de gegevens naar een hoger prestatie-niveau worden verplaatst (indien er ruimte beschikbaar is of door andere gegevens te verdringen). Auto-Tier plaatst nieuwe gegevens op verschillende niveaus, afhankelijk van de beschikbare ruimte, en herschikt ze op basis van vraag en vrije ruimte. Begin Hoog en dan Auto-Tier is het standaardbeleid en ook de aanbevolen optie. Bij de initiële plaatsing werkt het als Hoogste Beschikbare Niveau, waarna gegevens worden verplaatst op basis van gebruiksstatistieken. Het beleid Laagste Beschikbare Niveau probeert gegevens op het minst prestatiegerichte niveau te plaatsen.
Gegevensverplaatsing gebeurt met een lage prioriteit om de nuttige werkzaamheden van de SANS niet te verstoren, maar er is een instelling "Data relocation rate" die de prioriteit wijzigt. Hier is een bijzonderheid: niet alle gegevensblokken hebben dezelfde volgorde van herschikking. Bijvoorbeeld, blokken die als metadata zijn gemarkeerd, worden eerst naar een snellere niveau verplaatst. Metadata zijn, om het zo te zeggen, "gegevens over gegevens", extra informatie die geen gebruikersgegevens zijn maar hun beschrijving opslaat. Bijvoorbeeld, informatie in het bestandssysteem over welk blok een specifiek bestand bevat. Dit betekent dat de toegangssnelheid tot gegevens afhankelijk is van de toegangssnelheid tot de metadata. Aangezien metadata doorgaans veel kleiner zijn, wordt een grotere winst verwacht door hun verplaatsing naar snellere schijven.
De criteria die Fast VP gebruikt in zijn werking
De belangrijkste criteria voor elk blok, heel grof gezegd, is de eigenschap "vraag naar" gegevens, die afhankelijk is van het aantal lees- en schrijfoperaties van een gegevensfragment. Deze eigenschap noemen we "Temperatuur". Er zijn gevraagde (hot) gegevens die "heter" zijn dan niet-gevraagde. Dit wordt periodiek berekend, standaard om de uur.
De functie voor het berekenen van de temperatuur heeft de volgende eigenschappen:
- Bij afwezigheid van in- en uitvoer koelen de gegevens in de loop der tijd af.
- Bij een min of meer constante belasting in de loop der tijd, neemt de temperatuur eerst toe en stabiliseert deze vervolgens binnen een bepaald bereik.
Vervolgens worden de hierboven beschreven beleidsmaatregelen en de beschikbare ruimte op elk tier in aanmerking genomen. Voor de duidelijkheid geef ik een afbeelding uit de documentatie. Blocken met hoge, gemiddelde en lage temperatuur zijn hier respectievelijk in rood, geel en blauw benadrukt.
Maar laten we terugkeren naar de taken. Dus, we kunnen beginnen met de analyse van wat er gedaan wordt om de FAST VP-taken op te lossen.
A. Verdeling van gegevens over verschillende soorten schijven, niveaus
Dit is in feite de belangrijkste taak van FAST VP. De andere zijn op de een of andere manier afgeleid van deze. Afhankelijk van het gekozen beleid worden de gegevens verdeeld over verschillende opslagniveaus. Eerst wordt rekening gehouden met het plaatsingsbeleid, daarna met de temperatuur van blokken en de grootte/snelheid van RAID-groepen.
Voor de beleidsmaatregelen Hoogste/Laagste Beschikbare Tier is het vrij eenvoudig. Voor de andere twee geldt het volgende. Gegevens worden over verschillende niveaus verdeeld met inachtneming van de grootte en prestaties van RAID-groepen: zodat de verhouding van de totale "temperatuur" van blokken tot de "voorwaardelijke maximale prestatie" van elke RAID-groep ongeveer gelijk is. Op deze manier wordt de belasting min of meer gelijkmatig verdeeld. Meer gevraagde gegevens worden naar snelle opslagmedia verplaatst, en zelden gebruikte naar de langzamere. Idealiter zou de verdeling ongeveer als volgt moeten zijn:
B. Verdeling van gegevens binnen schijven van één type
Vergeet niet, in het begin schreef ik dat opslagmedia uit één of meerdere Hoe niveaus worden samengevoegd in één pool? In het geval van een enkel niveau is er ook werk voor FAST VP. Om de prestaties van een niveau maximaal te maken, is het wenselijk om de gegevens gelijkmatig over de schijven te verdelen. Dit zou (in theorie) het maximale aantal IOPS kunnen opleveren. De gegevens binnen een RAID-groep kunnen als gelijkmatig verdeeld over de schijven worden beschouwd, maar tussen RAID-groepen is dit lang niet altijd zo. In het geval van ongelijkheid zal FAST VP gegevens tussen RAID-groepen verplaatsen in verhouding tot hun volume en 'voorwaardelijke prestaties' (in numerieke termen). Ter illustratie laat ik een schema zien van de herschikking tussen drie RAID-groepen:
V. Gegevensverdeling bij uitbreiding van de pool
Deze taak is een speciaal geval van de vorige en wordt uitgevoerd wanneer er een RAID-groep aan de pool wordt toegevoegd. Om ervoor te zorgen dat de nieuw toegevoegde RAID-groep niet idle is, zullen enkele gegevens naar deze worden verplaatst, wat betekent dat de belasting over alle RAID-groepen opnieuw wordt verdeeld.
Versleten-uitlijning SSD
Met de versleten-uitlijning kan FAST VP de levensduur van SSD's verlengen, hoewel deze functie niet direct verband houdt met Storage Tiering. Aangezien er al temperatuurgegevens beschikbaar zijn, wordt ook het aantal schrijfoperaties in overweging genomen, kunnen we gegevensblokken verplaatsen, dus het zou logisch zijn dat FAST VP deze taak ook zou oplossen.
In het geval dat het aantal schrijfbewerkingen naar één RAID-groep aanzienlijk hoger is dan het aantal schrijfbewerkingen naar een andere, zal FAST VP de gegevens opnieuw verdelen op basis van het aantal schrijfoperaties. Aan de ene kant verlicht dit de belasting en behoudt het de levensduur van sommige schijven, terwijl het aan de andere kant 'werk' toevoegt voor minder belaste schijven en de algehele prestaties verhoogt.
Op deze manier neemt FAST VP de traditionele taken van Storage Tiering op zich en doet daar nog wat bovenop. Dit stelt ons in staat om gegevens behoorlijk effectief op te slaan in de Unity-opslagsystemen.
Enkele tips
- Sluit het lezen van documentatie niet uit. Er zijn best practices, en deze werken over het algemeen goed. Als je ze volgt, ontstaan er meestal geen ernstige problemen. De andere tips herhalen of aanvullen deze meestal.
- Als je FAST VP hebt ingesteld en ingeschakeld, laat het dan aan. Laat het de gegevens op de juiste momenten verspreiden, beetje bij beetje, in plaats van eens per jaar met een aanzienlijke impact op de prestaties van andere taken. In dergelijk geval kan het herverdelen van gegevens lang duren.
- Let goed op de keuze van het venster voor de relocatie. Hoewel dit voor de hand ligt, probeer een tijd met de minste belasting op Unity te kiezen en genoeg tijd vrij te maken.
- Plan de uitbreiding van de opslag, doe dit op tijd. Dit is een algemene aanbeveling die ook belangrijk is voor FAST VP. Als de beschikbare ruimte zeer klein is, kan het verplaatsen van gegevens vertragen of onmogelijk worden. Vooral als je punt 2 hebt genegeerd.
- Bij het uitbreiden van de pool met ingeschakeld FAST VP, moet je niet beginnen met de langzaamste schijven. Ofwel voeg je alle geplande RAID-groepen tegelijk toe, ofwel begin je met de snelste schijven. In dit geval zal het herverdelen van gegevens naar de nieuwe 'snelle' schijven de algehele snelheid van de pool verhogen. Anders, als je met 'langzame' schijven begint, kan dat tot een zeer onaangename situatie leiden. Eerst worden gegevens verplaatst naar nieuwe, relatief langzame schijven, en daarna, bij het toevoegen van snellere, in de omgekeerde richting. Hier zijn nuances verbonden aan verschillende FAST VP-beleiden, maar in het algemeen is zo'n situatie mogelijk.
Als je deze product overweegt, kun je Unity in actie gratis uitproberen door Unity VSA-virtuele appliance te downloaden.
Tot slot deel ik een aantal nuttige links:
- Pagina
- – korte beschrijving van de functie
- , pdf-formaat
Conclusie
Ik wil veel schrijven, maar ik begrijp dat niet alle details de lezer zullen interesseren. Bijvoorbeeld, ik kan uitgebreid ingaan op de criteria die FAST VP gebruikt om te beslissen over het verplaatsen van gegevens, en op de processen van het analyseren van invoer-uitvoerstatistieken. Ook is het onderwerp interactie met , dat vraagt om een apart artikel. We kunnen zelfs fantaseren over de ontwikkeling van deze technologie. Ik hoop dat het niet saai was en dat ik je niet heb vermoeid. Tot de volgende keer!
Bron: habr.com
