Avui parlarem d'una tecnologia interessant implementada al sistema d'emmagatzematge Unity / Unity XT - FAST VP. Si heu sentit a parlar d'Unity per primera vegada, podeu utilitzar l'enllaç al final de l'article per familiaritzar-vos amb les característiques del sistema. Vaig treballar a FAST VP durant més d'un any a l'equip de disseny de Dell EMC. Avui vull parlar d'aquesta tecnologia amb més detall i revelar alguns detalls de la seva implementació. Per descomptat, només aquells que es permeten ser revelats. Si esteu interessats en els problemes d'emmagatzematge eficient de dades o simplement no heu entès completament la documentació, aquest article us serà útil i interessant.
De seguida us diré què no hi haurà al material. No hi haurà cerca de competidors i comparació amb ells. Tampoc penso parlar de tecnologies semblants de codi obert, perquè el lector curiós ja les coneix. I, és clar, no faré publicitat de res.
classificació d'emmagatzematge. Objectius i objectius de FAST VP
FAST VP són les sigles de Fully Automated Storage Tiring for Virtual Pool. És difícil? Res, ho entendrem. La classificació és una manera d'organitzar l'emmagatzematge de dades, en la qual hi ha diversos nivells (nivells) on s'emmagatzemen aquestes dades. Cadascun té les seves pròpies característiques. El més important: rendiment, volum i preu d'emmagatzemar una unitat d'informació. Per descomptat, hi ha una relació entre ells.
Una característica important de la classificació és que l'accés a les dades es proporciona de manera uniforme, independentment del nivell d'emmagatzematge en què es trobi actualment, i la mida del grup és igual a la suma de les mides dels recursos inclosos en ell. Aquí rau la diferència amb la memòria cau: la mida de la memòria cau no s'afegeix a la quantitat total del recurs (en aquest cas, el grup), i les dades de la memòria cau duplica algunes dades del mitjà principal (o es duplicaran si el les dades de la memòria cau encara no s'han escrit). A més, la distribució de dades per nivells està oculta a l'usuari. És a dir, no veu exactament quines dades es troben a cada nivell, tot i que hi pot influir indirectament, establint polítiques (sobre elles més endavant).
Vegem ara les característiques de la implementació de la classificació d'emmagatzematge a Unity. A Unity, hi ha 3 nivells o nivells:
- Rendiment extrem (SSD)
- Rendiment (disc dur SAS 10k/15k RPM)
- Capacitat (NL-SAS HDD 7200 RPM)
Es presenten en ordre descendent de rendiment i preu. El rendiment extrem només inclou unitats d'estat sòlid (SSD). En els altres dos nivells hi ha unitats de disc magnètic, que difereixen en velocitat de rotació i, en conseqüència, en rendiment.
Els mitjans d'emmagatzematge del mateix nivell i la mateixa mida es combinen en una matriu RAID, formant un grup RAID (grup RAID, abreujat com a RG); podeu llegir sobre els nivells RAID disponibles i recomanats a la documentació oficial. A partir de grups RAID d'un o més nivells, es formen agrupacions d'emmagatzematge, a partir dels quals després es distribueix l'espai lliure. I ja des de l'agrupació s'assigna espai per a sistemes de fitxers i LUN.
Per què necessito Tiring?
En resum i resum: per aconseguir més resultats amb la menor quantitat de recursos. Més concretament, el resultat s'acostuma a entendre com un conjunt de característiques del sistema d'emmagatzematge: la velocitat i el temps d'accés, el cost d'emmagatzematge i altres. El mínim de recursos significa el menor cost: diners, energia, etc. FAST VP només implementa els mecanismes per redistribuir dades a diferents nivells del sistema d'emmagatzematge Unity / Unity XT. Si em creus, pots saltar el paràgraf següent. Per la resta, us explicaré una mica més.
Mitjançant l'ordenació adequada de les dades, podeu estalviar en el cost total de l'emmagatzematge sacrificant la velocitat d'accés a informació que no s'utilitza poc i millorar el rendiment movent les dades d'accés freqüent a mitjans més ràpids. Aquí algú pot objectar que fins i tot sense nivells, un administrador normal sap on posar quines dades, quines característiques del sistema d'emmagatzematge són desitjables per a la seva tasca, etc. Per descomptat, això és cert, però la distribució de dades "manualment" té els seus inconvenients:
- requereix temps i atenció de l'administrador;
- no sempre és possible "reformar" els recursos d'emmagatzematge en condicions canviants;
- desapareix un avantatge important: l'accés unificat als recursos situats a diferents nivells d'emmagatzematge.
Perquè els administradors d'emmagatzematge es preocupin menys per la seguretat laboral, afegiré que aquí també cal una planificació de recursos competent. Ara que s'han descrit breument les tasques de la classificació, anem a veure què podeu esperar de FAST VP. És el moment de tornar a la definició. Les dues primeres paraules - Totalment automatitzat - es tradueixen literalment com "totalment automatitzat" i signifiquen que la distribució dels nivells es produeix automàticament. Bé, Virtual Pool és un grup de dades que inclou recursos de diferents nivells d'emmagatzematge. Aquí teniu el que sembla:
De cara al futur, diré que FAST VP només mou dades dins d'un sol grup, i no entre diversos grups.
Tasques resoltes per FAST VP
Parlem primer de manera abstracta. Tenim un grup i algun mecanisme que pot redistribuir dades dins d'aquest grup. Tenint en compte que la nostra tasca és aconseguir la màxima productivitat, preguntem-nos: de quina manera es pot aconseguir? Pot ser que n'hi hagi diversos, i aquí FAST VP té alguna cosa a oferir a l'usuari, ja que la tecnologia és quelcom més que un simple nivell d'emmagatzematge. Aquí hi ha algunes maneres en què FAST VP pot augmentar el rendiment de la piscina:
- Distribució de dades entre diferents tipus de discs, nivells
- Distribució de dades entre discos del mateix tipus
- Distribució de dades en ampliar el pool
Abans de veure com es realitzen aquestes tasques, hem de conèixer alguns fets essencials sobre com funciona FAST VP. FAST VP funciona amb blocs d'una mida determinada: 256 megabytes. Aquest és el "tros" contigu més petit de dades que es pot moure. A la documentació s'anomena així: tall. Des del punt de vista de FAST VP, tots els grups RAID consisteixen en un conjunt d'aquestes "peces". En conseqüència, totes les estadístiques d'E/S s'acumulen per a aquests blocs de dades. Per què es tria aquesta mida de bloc i es reduirà? El bloc és bastant gran, però es tracta d'un compromís entre la granularitat de les dades (mida de bloc més petita - distribució més precisa) i els recursos informàtics disponibles: amb les severes restriccions existents a la memòria RAM i un gran nombre de blocs, les dades estadístiques poden prendre massa, i el nombre de càlculs creixerà proporcionalment.
Com FAST VP col·loca les dades a la piscina. Els polítics
Per controlar la col·locació de dades en un grup amb FAST VP habilitat, hi ha les polítiques següents:
- Nivell més alt disponible
- Nivell automàtic
- Comença a alt i després a nivell automàtic (per defecte)
- Nivell més baix disponible
Afecten tant l'assignació inicial del bloc (primer s'escriuen les dades) com la posterior reassignació. Quan les dades ja estiguin col·locades als discs, la reassignació s'iniciarà segons la programació o manualment.
El nivell més alt disponible intenta col·locar el bloc nou al nivell de rendiment més alt. Si no hi ha prou espai, el següent en termes de rendiment, però aleshores les dades es poden moure a un nivell més productiu (si hi ha espai o s'exclouen altres dades). Auto-Tier col·loca dades noves en diferents nivells en funció de la quantitat d'espai disponible i les redistribueix segons la demanda i l'espai lliure. La política predeterminada és Start High i Auto-Tier i també es recomana. Funciona com a nivell més alt disponible inicialment i després mou les dades en funció de les estadístiques d'ús. La política del nivell més baix disponible pretén col·locar les dades al nivell de menys rendiment.
La transferència de dades té una prioritat baixa per no interferir amb el treball útil del sistema d'emmagatzematge, però hi ha una configuració de "Taxa de reubicació de dades" que canvia la prioritat. Aquí hi ha una particularitat: no tots els blocs de dades tenen el mateix ordre de redistribució. Per exemple, primer els blocs marcats com a metadades es mouran al nivell més ràpid. Les metadades són, per dir-ho d'alguna manera, "dades sobre dades", una informació addicional que no són dades d'usuari, sinó que emmagatzema la seva descripció. Per exemple, informació del sistema de fitxers sobre quin bloc es troba un fitxer concret. Això vol dir que la velocitat d'accés a les dades depèn de la velocitat d'accés a les metadades. Atès que les metadades solen ser molt més petites, s'espera que els avantatges de traslladar-les a discs més ràpids siguin més grans.
Criteris que Fast VP utilitza en el seu treball
El criteri principal per a cada bloc, encara que sigui molt aproximat, és la característica de la "demanda" de dades, que depèn del nombre d'operacions de lectura i escriptura d'un fragment de dades. Aquesta característica s'anomena "Temperatura". Hi ha dades actualitzades que són més actuals que les dades no reclamades. Es calcula periòdicament, per defecte amb un interval d'una hora.
La funció de càlcul de temperatura té les propietats següents:
- En absència d'E/S, les dades "es refreden" amb el temps.
- Amb més o menys la mateixa càrrega en el temps, la temperatura primer augmenta i després s'estabilitza en un rang determinat.
A més, es tenen en compte les polítiques descrites anteriorment i l'espai lliure de cada nivell. Per a més claredat, donaré una imatge de la documentació. Aquí, els colors vermell, groc i blau indiquen blocs amb temperatures altes, mitjanes i baixes, respectivament.
Però tornem a les tasques. Així, podem començar a analitzar què s'està fent per resoldre els problemes de FAST VP.
A. Distribució de dades entre diferents tipus de discs, nivells
De fet, aquesta és la tasca principal de FAST VP. La resta, en cert sentit, en són derivats. En funció de la política seleccionada, les dades es distribuiran entre diferents nivells d'emmagatzematge. En primer lloc, es té en compte la política de col·locació, després la temperatura dels blocs i la mida/velocitat dels grups RAID.
Per a les polítiques de nivell més alt/baix disponible, tot és bastant senzill. Per als altres dos, aquest és el cas. Les dades es distribueixen en diferents nivells, tenint en compte la mida i el rendiment dels grups RAID: de manera que la relació entre la "temperatura" total dels blocs i el "rendiment màxim condicional" de cada grup RAID sigui aproximadament la mateixa. Així, la càrrega es distribueix de manera més o menys uniforme. Les dades que tenen més demanda es traslladen a mitjans més ràpids, les dades que s'utilitzen amb menys freqüència es traslladen a mitjans més lents. Idealment, la distribució hauria de semblar a això:
B. Distribució de dades entre discs del mateix tipus
Recordeu, al principi vaig escriure que els portadors d'informació de un o més els nivells es combinen en una sola piscina? En el cas d'un sol nivell, FAST VP també té feina a fer. Per maximitzar el rendiment a qualsevol nivell, és desitjable distribuir les dades de manera uniforme entre els discos. Això permetrà (en teoria) obtenir el nombre màxim d'IOPS. Les dades dins d'un grup RAID es poden considerar distribuïdes de manera uniforme entre els discos, però això no sempre és el cas entre els grups RAID. En cas d'un desequilibri, FAST VP mourà les dades entre grups RAID en proporció a la seva mida i al "rendiment condicional" (en termes numèrics). Per a més claredat, mostraré l'esquema de reequilibri entre tres grups RAID:
C. Distribució de dades en ampliar el pool
Aquesta tasca és un cas especial de l'anterior i es realitza quan s'afegeix un grup RAID al grup. Per evitar que el grup RAID recentment afegit estigui inactiu, algunes de les dades s'hi transferiran, la qual cosa significa que la càrrega de tots els grups RAID es redistribuirà.
Nivelació de desgast SSD
Mitjançant l'anivellament del desgast, FAST VP pot allargar la vida útil d'un SSD, tot i que aquesta característica no està directament relacionada amb l'emmagatzematge en nivells. Com que ja hi ha dades de temperatura, també es té en compte el nombre d'operacions d'escriptura, sabem com moure els blocs de dades, seria lògic que FAST VP també solucionés aquest problema.
Si el nombre d'escriptures a un grup RAID supera significativament el nombre d'escriptures a un altre, FAST VP redistribuirà les dades segons el nombre d'escriptures. D'una banda, això elimina la càrrega i estalvia el recurs d'alguns discs, d'altra banda, afegeix "treball" per als menys carregats, augmentant el rendiment general.
Així, FAST VP assumeix les tasques tradicionals de Storage Tiring i fa una mica més que això. Tot això us permet emmagatzemar dades de manera eficient al sistema d'emmagatzematge Unity.
alguns consells
- No descuideu la lectura de la documentació. Hi ha bones pràctiques i funcionen força bé. Si els seguiu, no sorgeixen problemes greus, per regla general. La resta de consells bàsicament els repeteixen o complementen.
- Si heu configurat i activat FAST VP, deixeu-lo activat. Deixeu que assigni les dades en el temps previst i poc a poc d'un cop a l'any i tingui un impacte greu en la realització d'altres tasques. En aquests casos, la redistribució de dades pot trigar molt de temps.
- Aneu amb compte a l'hora de triar una finestra de trasllat. Tot i que això és obvi, intenteu triar un temps amb menys càrrega a Unity i assigneu-hi una quantitat de temps suficient.
- Planifiqueu la vostra expansió d'emmagatzematge, feu-ho a temps. Aquesta és una recomanació general que també és important per a FAST VP. Si la quantitat d'espai lliure és molt petita, el moviment de dades s'alentirà o es farà impossible. Sobretot si heu descuidat el punt 2.
- Quan amplieu un grup amb FAST VP habilitat, no comenceu amb les unitats més lentes. És a dir, o afegim tots els grups RAID planificats alhora, o bé afegim primer els discs més ràpids. En aquest cas, la redistribució de dades a nous discs "ràpids" augmentarà la velocitat general de l'agrupació. En cas contrari, començant amb discs "lents", podeu obtenir una situació molt desagradable. En primer lloc, les dades es transferiran a nous discs relativament lents, i després, en afegir-ne de més ràpids, en la direcció oposada. Hi ha matisos associats a diferents polítiques de FAST VP, però en el cas general, aquesta situació és possible.
Si esteu mirant aquest producte, podeu provar Unity en acció gratuïtament baixant l'aparell virtual Unity VSA.
Al final de l'article, comparteixo uns quants enllaços útils:
- Pàgina
- - Breu descripció de la funció
- , format pdf
Conclusió
Vull escriure moltes coses, però entenc que no tots els detalls seran d'interès per al lector. Per exemple, podeu parlar amb més detall sobre els criteris pels quals FAST VP pren la decisió de transferir dades, sobre els processos d'anàlisi de les estadístiques d'E/S. També, el tema de la interacció amb , i això recull un article separat. Fins i tot podeu fantasejar amb el desenvolupament d'aquesta tecnologia. Espero que no hagi estat avorrit i no t'hagi avorrit. Fins aviat!
Font: www.habr.com