FAST VP op Unity-opslag: hoe het werkt

Vandaag zullen we het hebben over een interessante technologie die is geïmplementeerd in het Unity / Unity XT-opslagsysteem - FAST VP. Als je voor het eerst over Unity hebt gehoord, kan de link aan het einde van het artikel worden gebruikt om vertrouwd te raken met de kenmerken van het systeem. Ik heb meer dan een jaar aan FAST VP gewerkt in het Dell EMC-projectteam. Vandaag wil ik meer in detail over deze technologie praten en enkele details van de implementatie ervan onthullen. Natuurlijk, alleen degenen die mogen worden onthuld. Als u geïnteresseerd bent in de kwesties van efficiënte gegevensopslag of de documentatie gewoon niet volledig hebt begrepen, dan zal dit artikel zeker nuttig en interessant zijn.

FAST VP op Unity-opslag: hoe het werkt

Ik zal je meteen vertellen wat er niet in het materiaal zal staan. Er zal niet naar concurrenten worden gezocht en met hen worden vergeleken. Ik ben ook niet van plan om over soortgelijke technologieën uit open source te praten, omdat de nieuwsgierige lezer er al van op de hoogte is. En natuurlijk ga ik nergens reclame voor maken.

opslaglagen. Doelen en doelstellingen van FAST VP

FAST VP staat voor Fully Automated Storage Tiering for Virtual Pool. Is het moeilijk? Niets, we komen er wel uit. Tiering is een manier om gegevensopslag te organiseren, waarbij er verschillende niveaus (tiers) zijn waar deze gegevens worden opgeslagen. Elk heeft zijn eigen kenmerken. Het belangrijkste: prestatie, volume en prijs van het opslaan van een informatie-eenheid. Natuurlijk is er een relatie tussen hen.

Een belangrijk kenmerk van tiering is dat toegang tot gegevens op uniforme wijze wordt verleend, ongeacht op welk opslagniveau deze zich momenteel bevindt, en dat de grootte van de pool gelijk is aan de som van de groottes van de bronnen die erin zijn opgenomen. Hier ligt het verschil met de cache: de grootte van de cache wordt niet opgeteld bij de totale hoeveelheid van de bron (in dit geval de pool), en de cachegegevens dupliceren een stuk gegevens van het hoofdmedium (of zullen dupliceren als de gegevens uit de cache zijn nog niet weggeschreven). Ook is de verdeling van gegevens per niveau verborgen voor de gebruiker. Dat wil zeggen, hij ziet niet precies welke gegevens zich op elk niveau bevinden, hoewel hij dit indirect kan beïnvloeden door beleid te bepalen (daarover later).

Laten we nu eens kijken naar de kenmerken van de implementatie van opslaglagen in Unity. In Unity zijn er 3 niveaus of niveaus:

  • Extreme prestaties (SSD's)
  • Prestaties (SAS HDD 10k/15k RPM)
  • Capaciteit (NL-SAS HDD 7200 RPM)

Ze worden gepresenteerd in dalende volgorde van prestatie en prijs. Extreme prestaties omvatten alleen Solid State Drives (SSD's). In de andere twee niveaus zijn er magnetische schijfstations, die verschillen in rotatiesnelheid en dus in prestaties.

Opslagmedia van hetzelfde niveau en dezelfde grootte worden gecombineerd tot een RAID-array, waardoor een RAID-groep wordt gevormd (RAID-groep, afgekort als RG); u kunt lezen over de beschikbare en aanbevolen RAID-niveaus in de officiële documentatie. Uit RAID-groepen van een of meer niveaus worden opslagpools gevormd, waaruit vervolgens vrije ruimte wordt verdeeld. En al vanuit de pool wordt ruimte toegewezen voor bestandssystemen en LUN's.

FAST VP op Unity-opslag: hoe het werkt

Waarom heb ik Tiering nodig?

In het kort en abstract: om meer resultaat te bereiken met de minste hoeveelheid middelen. Meer specifiek wordt het resultaat meestal begrepen als een reeks kenmerken van het opslagsysteem - de snelheid en tijd van toegang, de opslagkosten en andere. Het minimum aan middelen betekent de minste kosten: geld, energie, enzovoort. FAST VP implementeert alleen de mechanismen voor het herverdelen van gegevens over verschillende niveaus in het Unity / Unity XT-opslagsysteem. Als je me gelooft, kun je de volgende paragraaf overslaan. Voor de rest zal ik je wat meer vertellen.

Door gegevens op de juiste manier te stapelen, kunt u besparen op de totale kosten van opslag door de snelheid van toegang tot sommige zelden gebruikte informatie op te offeren, en kunt u de prestaties verbeteren door veelgebruikte gegevens naar snellere media te verplaatsen. Hier kan iemand tegenwerpen dat zelfs zonder tiering een normale beheerder weet waar hij welke gegevens moet plaatsen, welke kenmerken van het opslagsysteem wenselijk zijn voor zijn taak, enz. Zeker, dit is waar, maar de distributie van gegevens "handmatig" heeft zijn nadelen:

  • vraagt ​​tijd en aandacht van de beheerder;
  • het is niet altijd mogelijk om opslagresources te "hervormen" onder veranderende omstandigheden;
  • een belangrijk voordeel verdwijnt: uniforme toegang tot bronnen die zich op verschillende opslagniveaus bevinden.

Om ervoor te zorgen dat opslagbeheerders zich minder zorgen hoeven te maken over baanzekerheid, voeg ik eraan toe dat competente resourceplanning ook hier nodig is. Nu de taken van tiering kort zijn geschetst, laten we eens kijken wat u kunt verwachten van FAST VP. Dit is het moment om terug te keren naar de definitie. De eerste twee woorden - Volledig geautomatiseerd - vertalen zich letterlijk als "volledig geautomatiseerd" en betekenen dat de verdeling van niveaus automatisch plaatsvindt. Welnu, Virtual Pool is een datapool met bronnen van verschillende opslagniveaus. Hier is hoe het eruit ziet:

FAST VP op Unity-opslag: hoe het werkt

Vooruitkijkend zal ik zeggen dat FAST VP alleen gegevens verplaatst binnen een enkele pool, en niet tussen meerdere pools.

Taken opgelost door FAST VP

Laten we eerst abstract praten. We hebben een pool en een mechanisme dat gegevens binnen deze pool kan herverdelen. In gedachten houdend dat het onze taak is om maximale productiviteit te bereiken, laten we ons afvragen: op welke manieren kan dit worden bereikt? Er kunnen er meerdere zijn, en hier heeft FAST VP de gebruiker iets te bieden, aangezien de technologie meer is dan alleen opslaglagen. Hier zijn enkele manieren waarop FAST VP de poolprestaties kan verbeteren:

  • Verdeling van gegevens over verschillende soorten schijven, niveaus
  • Verdeling van gegevens over schijven van hetzelfde type
  • Distributie van gegevens bij uitbreiding van de pool

Voordat we gaan kijken hoe deze taken worden volbracht, moeten we enkele essentiële feiten weten over hoe FAST VP werkt. FAST VP werkt met blokken van een bepaalde grootte - 256 megabytes. Dit is het kleinste aaneengesloten 'brok' aan gegevens dat kan worden verplaatst. In de documentatie heet het zo: slice. Vanuit het oogpunt van FAST VP bestaan ​​alle RAID-groepen uit een set van dergelijke "stukjes". Dienovereenkomstig worden alle I/O-statistieken verzameld voor dergelijke datablokken. Waarom is voor deze blokgrootte gekozen en wordt deze verkleind? Het blok is vrij groot, maar dit is een compromis tussen gegevensgranulariteit (kleinere blokgrootte - nauwkeurigere distributie) en beschikbare computerbronnen: met de bestaande ernstige beperkingen op RAM en een groot aantal blokken, kunnen statistische gegevens te veel kosten, en het aantal berekeningen zal evenredig groeien.

Hoe FAST VP gegevens in de pool plaatst. Politici

Om de plaatsing van gegevens in een pool met FAST VP ingeschakeld te regelen, zijn er de volgende beleidsregels:

  • Hoogste beschikbare niveau
  • Automatische laag
  • Begin hoog dan Auto-Tier (standaard)
  • Laagste beschikbare niveau

Ze beïnvloeden zowel de initiële toewijzing van het blok (de gegevens worden eerst geschreven) als de daaropvolgende hertoewijzing. Wanneer de gegevens al op de schijven zijn geplaatst, wordt de herverdeling volgens schema of handmatig gestart.

De hoogst beschikbare laag probeert het nieuwe blok op de best presterende laag te plaatsen. Als er niet genoeg ruimte op is, de volgende qua prestaties, maar dan kunnen de gegevens naar een productiever niveau worden verplaatst (als er ruimte is of andere gegevens worden verdrongen). Auto-Tier plaatst nieuwe gegevens in verschillende lagen op basis van de hoeveelheid beschikbare ruimte en verdeelt deze opnieuw op basis van vraag en vrije ruimte. Start High then Auto-Tier is het standaardbeleid en wordt ook aanbevolen. Werkt in eerste instantie als een hoogst beschikbare laag en verplaatst vervolgens gegevens op basis van gebruiksstatistieken. Het beleid voor het laagste beschikbare niveau probeert gegevens op het minst presterende niveau te plaatsen.

De gegevensoverdracht gaat met een lage prioriteit om het nuttige werk van het opslagsysteem niet te verstoren, maar er is een instelling voor "Gegevensverplaatsingssnelheid" die de prioriteit verandert. Er is hier een bijzonderheid: niet alle datablokken hebben dezelfde herverdelingsvolgorde. Blokken die zijn gemarkeerd als metagegevens, worden bijvoorbeeld als eerste naar de snellere laag verplaatst. Metadata is als het ware "data over data", wat aanvullende informatie die geen gebruikersgegevens zijn, maar hun beschrijving opslaat. Bijvoorbeeld informatie in het bestandssysteem over in welk blok een bepaald bestand zich bevindt. Dit betekent dat de snelheid van toegang tot data afhankelijk is van de snelheid van toegang tot metadata. Aangezien metadata doorgaans veel kleiner zijn, zullen de voordelen van het verplaatsen naar snellere schijven naar verwachting groter zijn.

Criteria die Fast VP hanteert in haar werk

Het belangrijkste criterium voor elk blok, zij het zeer grofweg, is het kenmerk van de "vraag" naar gegevens, die afhangt van het aantal lees- en schrijfbewerkingen van een gegevensfragment. Deze eigenschap wordt "Temperatuur" genoemd. Er zijn hot data die hotter zijn dan niet-opgeëiste data. Het wordt periodiek berekend, standaard met een interval van een uur.

De temperatuurberekeningsfunctie heeft de volgende eigenschappen:

  • Bij afwezigheid van I / O "koelen" gegevens na verloop van tijd af.
  • Bij min of meer dezelfde belasting in de tijd loopt de temperatuur eerst op en stabiliseert dan in een bepaald bereik.

Verder wordt rekening gehouden met het hierboven beschreven beleid en de vrije ruimte op elke laag. Voor de duidelijkheid zal ik een afbeelding uit de documentatie geven. Hier geven rode, gele en blauwe kleuren blokken aan met respectievelijk hoge, gemiddelde en lage temperaturen.

FAST VP op Unity-opslag: hoe het werkt

Maar terug naar de taken. We kunnen dus beginnen met analyseren wat er wordt gedaan om de problemen van FAST VP op te lossen.

A. Verdeling van gegevens over verschillende soorten schijven, niveaus

Eigenlijk is dit de hoofdtaak van FAST VP. De rest is er in zekere zin afgeleiden van. Afhankelijk van het geselecteerde beleid worden gegevens verdeeld over verschillende opslaglagen. Allereerst wordt er rekening gehouden met het plaatsingsbeleid, vervolgens met de temperatuur van de blokken en de grootte/snelheid van de RAID-groepen.

Voor het hoogst/laagst beschikbare niveau is alles vrij eenvoudig. Voor de andere twee is dit het geval. Gegevens worden verdeeld over verschillende niveaus, rekening houdend met 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 hetzelfde is. Zo wordt de belasting min of meer gelijkmatig verdeeld. Gegevens waar meer vraag naar is, worden verplaatst naar snellere media, minder vaak gebruikte gegevens worden verplaatst naar langzamere media. Idealiter zou de verdeling er ongeveer zo uit moeten zien:

FAST VP op Unity-opslag: hoe het werkt

B. Verdeling van gegevens over schijven van hetzelfde type

Vergeet niet, in het begin schreef ik die informatiedragers van een of meer niveaus worden gecombineerd in één pool? In het geval van een enkel niveau heeft FAST VP ook werk te doen. Om de prestaties op elk niveau te maximaliseren, is het wenselijk om gegevens gelijkmatig over schijven te verdelen. Hierdoor kan (in theorie) het maximale aantal IOPS worden verkregen. Gegevens binnen een RAID-groep kunnen worden beschouwd als gelijkmatig verdeeld over schijven, maar dit is niet altijd het geval tussen RAID-groepen. In het geval van een onbalans, zal FAST VP gegevens verplaatsen tussen RAID-groepen in verhouding tot hun grootte en "voorwaardelijke prestatie" (in numerieke termen). Voor de duidelijkheid zal ik het herbalanceringsschema tussen drie RAID-groepen laten zien:

FAST VP op Unity-opslag: hoe het werkt

C. Distributie van gegevens bij uitbreiding van de pool

Deze taak is een speciaal geval van de vorige en wordt uitgevoerd wanneer een RAID-groep aan de pool wordt toegevoegd. Om te voorkomen dat de zojuist toegevoegde RAID-groep inactief is, wordt een deel van de gegevens ernaar overgedragen, wat betekent dat de belasting van alle RAID-groepen opnieuw wordt verdeeld.

SSD-slijtage-nivellering

Door wear leveling kan FAST VP de levensduur van een SSD verlengen, hoewel deze functie niet direct gerelateerd is aan Storage Tiering. Aangezien er al temperatuurgegevens zijn, wordt ook rekening gehouden met het aantal schrijfbewerkingen, we weten hoe we gegevensblokken moeten verplaatsen, het zou logisch zijn als FAST VP dit probleem ook oplost.

Als het aantal schrijfbewerkingen naar de ene RAID-groep aanzienlijk groter is dan het aantal schrijfbewerkingen naar een andere, zal FAST VP de gegevens herverdelen op basis van het aantal schrijfbewerkingen. Aan de ene kant verwijdert dit de belasting en bespaart het de bron van sommige schijven, aan de andere kant voegt het "werk" toe voor minder belaste schijven, waardoor de algehele prestaties toenemen.

FAST VP neemt dus de traditionele taken van Storage Tiering over en doet iets meer dan dat. Dit alles stelt u in staat om efficiënt gegevens op te slaan in het Unity-opslagsysteem.

Een paar tips

  1. Vergeet niet de documentatie te lezen. Er zijn best practices en ze werken redelijk goed. Als u ze volgt, doen zich in de regel geen ernstige problemen voor. De rest van de tips herhalen ze in principe of vullen ze aan.
  2. Als je FAST VP hebt geconfigureerd en ingeschakeld, laat het dan ingeschakeld. Laat het gegevens toewijzen in de toegewezen tijd en beetje bij beetje dan één keer per jaar en een serieuze impact hebben op de uitvoering van andere taken. In dergelijke gevallen kan de herverdeling van gegevens lang duren.
  3. Wees voorzichtig bij het kiezen van een verhuisvenster. Hoewel dit duidelijk is, probeer een tijd te kiezen met de minste belasting van Unity en wijs voldoende tijd toe.
  4. Plan uw opslaguitbreiding, doe het op tijd. Dit is een algemene aanbeveling die ook belangrijk is voor FAST VP. Als de hoeveelheid vrije ruimte erg klein is, zal de verplaatsing van gegevens vertragen of onmogelijk worden. Zeker als je punt 2 over het hoofd hebt gezien.
  5. Wanneer u een pool uitbreidt met FAST VP ingeschakeld, begin dan niet met de langzaamste schijven. Dat wil zeggen, ofwel voegen we alle geplande RAID-groepen in één keer toe, ofwel voegen we eerst de snelste schijven toe. In dit geval zal het herdistribueren van gegevens naar nieuwe "snelle" schijven de algehele snelheid van de pool verhogen. Anders kunt u, beginnend met "trage" schijven, een zeer onaangename situatie krijgen. Eerst worden de gegevens overgebracht naar nieuwe, relatief trage schijven, en vervolgens, bij het toevoegen van snellere schijven, in de tegenovergestelde richting. Er zijn nuances verbonden aan verschillende FAST VP-beleidslijnen, maar in het algemeen is deze situatie mogelijk.

Als u naar dit product kijkt, kunt u Unity gratis in actie proberen door de Unity VSA virtual appliance te downloaden.

FAST VP op Unity-opslag: hoe het werkt

Aan het einde van het artikel deel ik een paar nuttige links:

Conclusie

Ik wil over veel schrijven, maar ik begrijp dat niet alle details voor de lezer interessant zullen zijn. U kunt bijvoorbeeld meer in detail praten over de criteria op basis waarvan FAST VP een beslissing neemt om gegevens over te dragen, over de processen voor het analyseren van I / O-statistieken. Ook het onderwerp van interactie met Dynamische zwembaden, en dit trekt een apart artikel aan. Je kunt zelfs fantaseren over de ontwikkeling van deze technologie. Ik hoop dat het niet saai was en ik jou ook niet. Tot we elkaar weer ontmoeten!

Bron: www.habr.com

Voeg een reactie