Hoxe falaremos dunha tecnoloxía interesante implementada no sistema de almacenamento Unity / Unity XT - FAST VP. Se escoitou falar de Unity por primeira vez, pódese usar a ligazón ao final do artigo para familiarizarse coas características do sistema. Traballei en FAST VP durante máis dun ano no equipo de deseño de Dell EMC. Hoxe quero falar sobre esta tecnoloxía con máis detalle e desvelar algúns detalles da súa implementación. Por suposto, só aqueles que están autorizados a ser revelados. Se estás interesado nos problemas de almacenamento eficiente de datos ou simplemente non entendes completamente a documentación, entón este artigo seguramente será útil e interesante.
Vouche dicir de inmediato o que non estará no material. Non haberá busca de competidores e comparación con eles. Tampouco penso falar de tecnoloxías similares de código aberto, porque o lector curioso xa as coñece. E, por suposto, non vou anunciar nada.
nivelación de almacenamento. Obxectivos e obxectivos de FAST VP
FAST VP significa Fully Automated Storage Tiring for Virtual Pool. É difícil? Nada, resolverémolo. A agrupación é unha forma de organizar o almacenamento de datos, na que hai varios niveis (niveles) onde se almacenan estes datos. Cada un ten as súas propias características. O máis importante: rendemento, volume e prezo de almacenar unha unidade de información. Por suposto, hai unha relación entre eles.
Unha característica importante da agrupación é que o acceso aos datos se proporciona de forma uniforme independentemente do nivel de almacenamento no que estea actualmente, e o tamaño da agrupación é igual á suma dos tamaños dos recursos incluídos nel. Aquí reside a diferenza coa caché: o tamaño da caché non se engade á cantidade total do recurso (neste caso o grupo), e os datos da caché duplican algún dato do medio principal (ou duplicaranse se o os datos da caché aínda non foron escritos). Ademais, a distribución dos datos por niveis está oculta ao usuario. É dicir, non ve exactamente que datos se localizan en cada nivel, aínda que pode influír nisto de forma indirecta, establecendo políticas (sobre elas máis adiante).
Agora vexamos as funcións da implementación da capa de almacenamento en Unity. En Unity, hai 3 niveis ou niveis:
- Rendemento extremo (SSD)
- Rendemento (SAS HDD 10k/15k RPM)
- Capacidade (NL-SAS HDD 7200RPM)
Preséntanse por orde decrecente de rendemento e prezo. O rendemento extremo inclúe só unidades de estado sólido (SSD). Nos outros dous niveis hai unidades de disco magnético que difiren en velocidade de rotación e, en consecuencia, rendemento.
Os medios de almacenamento do mesmo nivel e do mesmo tamaño combínanse nunha matriz RAID, formando un grupo RAID (grupo RAID, abreviado como RG); podes ler sobre os niveis RAID dispoñibles e recomendados na documentación oficial. A partir de grupos RAID dun ou máis niveis, fórmanse agrupacións de almacenamento, desde as que despois se distribúe o espazo libre. E xa desde o pool está asignado espazo para sistemas de ficheiros e LUN.
Por que necesito Tiring?
En resumo e resumo: conseguir máis resultados coa menor cantidade de recursos. Máis concretamente, o resultado adoita entenderse como un conxunto de características do sistema de almacenamento: a velocidade e o tempo de acceso, o custo de almacenamento e outras. O mínimo de recursos supón o menor custo: diñeiro, enerxía, etc. FAST VP só implementa os mecanismos para redistribuír datos en diferentes niveis no sistema de almacenamento Unity / Unity XT. Se me cres, podes saltar o seguinte parágrafo. Polo demais, vouvos contar un pouco máis.
Ao organizar correctamente os datos, podes aforrar no custo total do almacenamento sacrificando a velocidade de acceso a algunha información que se usa raramente e mellorar o rendemento movendo os datos aos que se accede con frecuencia a medios máis rápidos. Aquí alguén pode objetar que, aínda sen establecer niveis, un administrador normal sabe onde poñer que datos, que características do sistema de almacenamento son desexables para a súa tarefa, etc. Por suposto, isto é certo, pero a distribución de datos "manual" ten os seus inconvenientes:
- require tempo e atención do administrador;
- non sempre é posible "reformar" os recursos de almacenamento en condicións cambiantes;
- desaparece unha vantaxe importante: o acceso unificado a recursos situados en diferentes niveis de almacenamento.
Para que os administradores de almacenamento se preocupen menos pola seguridade laboral, engadirei que aquí tamén é necesaria unha planificación competente de recursos. Agora que se describiron brevemente as tarefas de nivelación, vexamos o que podes esperar de FAST VP. Este é o momento de volver á definición. As dúas primeiras palabras - Totalmente automatizada - tradúcense literalmente como "totalmente automatizada" e significan que a distribución dos niveis ocorre automaticamente. Ben, Virtual Pool é un pool de datos que inclúe recursos de diferentes niveis de almacenamento. Aquí tes o que parece:
De cara ao futuro, direi que FAST VP só move os datos dentro dun único grupo, e non entre varios grupos.
Tarefas resoltas por FAST VP
Falemos primeiro en abstracto. Temos un grupo e algún mecanismo que pode redistribuír os datos dentro deste grupo. Tendo en conta que a nosa tarefa é acadar a máxima produtividade, preguntémonos: de que xeitos se pode conseguir? Pode que haxa varios deles, e aquí FAST VP ten algo que ofrecer ao usuario, xa que a tecnoloxía é algo máis que un simple nivel de almacenamento. Aquí tes algunhas formas en que FAST VP pode aumentar o rendemento da piscina:
- Distribución de datos entre distintos tipos de discos, niveis
- Distribución de datos entre discos do mesmo tipo
- Distribución de datos ao ampliar o pool
Antes de ver como se realizan estas tarefas, necesitamos coñecer algúns datos esenciais sobre como funciona FAST VP. FAST VP funciona con bloques de certo tamaño: 256 megabytes. Este é o "anaco" contiguo máis pequeno de datos que se pode mover. Na documentación denomínase así: rebanada. Desde o punto de vista de FAST VP, todos os grupos RAID consisten nun conxunto de tales "pezas". En consecuencia, todas as estatísticas de E/S acumúlanse para tales bloques de datos. Por que se escolle este tamaño de bloque e reducirase? O bloque é bastante grande, pero este é un compromiso entre a granularidade dos datos (tamaño de bloque máis pequeno - distribución máis precisa) e os recursos informáticos dispoñibles: coas severas restricións existentes na memoria RAM e un gran número de bloques, os datos estatísticos poden levar demasiado e o número de cálculos crecerá proporcionalmente.
Como FAST VP coloca os datos no grupo. Políticos
Para controlar a colocación de datos nun grupo con FAST VP activado, existen as seguintes políticas:
- Nivel máis alto dispoñible
- Nivel automático
- Iniciar alto e despois Auto-Tier (predeterminado)
- Nivel máis baixo dispoñible
Afectan tanto á asignación de bloques inicial (os datos escríbense primeiro) como á reasignación posterior. Cando os datos xa estean colocados nos discos, a reasignación iniciarase segundo a programación ou manualmente.
O nivel máis alto dispoñible tenta colocar o novo bloque no nivel de maior rendemento. Se non hai espazo suficiente nel, o seguinte en termos de rendemento, pero entón os datos pódense mover a un nivel máis produtivo (se hai espazo ou se eliminan outros datos). O nivel automático coloca novos datos en diferentes niveis en función da cantidade de espazo dispoñible e redistribúeos en función da demanda e do espazo libre. Iniciar alto, a continuación, o nivel automático é a política predeterminada e tamén se recomenda. Inicialmente funciona como o nivel máis alto dispoñible e despois move os datos en función das estatísticas de uso. A política do nivel máis baixo dispoñible busca situar os datos no nivel de menor rendemento.
A transferencia de datos vai cunha prioridade baixa para non interferir co traballo útil do sistema de almacenamento, non obstante, hai unha configuración de "Taxa de reubicación de datos" que cambia a prioridade. Aquí hai unha peculiaridade: non todos os bloques de datos teñen a mesma orde de redistribución. Por exemplo, primeiro os bloques marcados como metadatos moveranse ao nivel máis rápido. Os metadatos son, por así dicir, "datos sobre datos", unha información adicional que non son datos do usuario, senón que almacena a súa descrición. Por exemplo, información no sistema de ficheiros sobre o bloque no que se atopa un ficheiro concreto. Isto significa que a velocidade de acceso aos datos depende da velocidade de acceso aos metadatos. Dado que os metadatos adoitan ser moito máis pequenos, espérase que os beneficios de movelos a discos máis rápidos sexan maiores.
Criterios que Fast VP utiliza no seu traballo
O criterio principal para cada bloque, aínda que sexa moi aproximado, é a característica da "demanda" de datos, que depende do número de operacións de lectura e escritura dun fragmento de datos. Esta característica chámase "Temperatura". Hai datos quentes que son máis quentes que os datos non reclamados. Calcúlase periodicamente, por defecto cun intervalo dunha hora.
A función de cálculo de temperatura ten as seguintes propiedades:
- En ausencia de E/S, os datos "enfríanse" co paso do tempo.
- Con máis ou menos a mesma carga no tempo, a temperatura primeiro aumenta e despois estabilizase nun intervalo determinado.
Ademais, téñense en conta as políticas descritas anteriormente e o espazo libre en cada nivel. Para claridade, vou dar unha imaxe da documentación. Aquí, as cores vermella, amarela e azul indican bloques con temperaturas altas, medias e baixas, respectivamente.
Pero volvamos ás tarefas. Así, podemos comezar a analizar o que se está a facer para resolver os problemas de FAST VP.
A. Distribución de datos en diferentes tipos de discos, niveis
En realidade, esta é a tarefa principal de FAST VP. O resto, en certo sentido, son derivados del. Dependendo da política seleccionada, os datos distribuiranse en diferentes niveis de almacenamento. En primeiro lugar, tense en conta a política de colocación, despois a temperatura dos bloques e o tamaño/velocidade dos grupos RAID.
Para as políticas de nivel máis alto/baixo dispoñible, todo é bastante sinxelo. Para os outros dous, este é o caso. Os datos distribúense en diferentes niveis, tendo en conta o tamaño e o rendemento dos grupos RAID: de xeito que a relación entre a "temperatura" total dos bloques e o "máximo rendemento condicional" de cada grupo RAID sexa aproximadamente a mesma. Así, a carga distribúese máis ou menos uniformemente. Os datos que son máis demandados móvense a medios máis rápidos, os datos que raramente se usan móvense a medios máis lentos. Idealmente, a distribución debería verse así:
B. Distribución de datos entre discos do mesmo tipo
Lembre, ao principio escribín que os portadores de información de unha ou máis os niveis se combinan nunha única piscina? No caso dun só nivel, FAST VP tamén ten que facer. Para maximizar o rendemento a calquera nivel, é desexable distribuír os datos de forma uniforme entre os discos. Isto permitirá (en teoría) obter o número máximo de IOPS. Os datos dentro dun grupo RAID pódense considerar distribuídos uniformemente entre os discos, pero este non sempre é o caso entre os grupos RAID. En caso de desequilibrio, FAST VP moverá os datos entre grupos RAID en proporción ao seu tamaño e ao seu "rendemento condicional" (en termos numéricos). Para claridade, mostrarei o esquema de reequilibrio entre tres grupos RAID:
C. Distribución dos datos ao ampliar o pool
Esta tarefa é un caso especial da anterior e realízase cando se engade un grupo RAID ao grupo. Para evitar que o grupo RAID recentemente engadido estea inactivo, trasladaranse a el algúns dos datos, o que significa que a carga de todos os grupos RAID será redistribuída.
Nivelación de desgaste SSD
A través da nivelación de desgaste, FAST VP pode prolongar a vida útil dun SSD, aínda que esta función non está directamente relacionada coa capa de almacenamento. Dado que xa hai datos de temperatura, tamén se ten en conta o número de operacións de escritura, sabemos como mover bloques de datos, sería lóxico que FAST VP tamén solucionase este problema.
Se o número de escrituras nun grupo RAID supera significativamente o número de escrituras noutro, FAST VP redistribuirá os datos segundo o número de escrituras. Por unha banda, isto elimina a carga e aforra o recurso dalgúns discos, por outra banda, engade "traballo" para os menos cargados, aumentando o rendemento xeral.
Así, FAST VP asume as tarefas tradicionais de Storage Tiring e fai algo máis que iso. Todo isto permítelle almacenar datos de forma eficiente no sistema de almacenamento Unity.
algunhas suxestións
- Non deixes de ler a documentación. Hai boas prácticas e funcionan bastante ben. Se os segues, entón non xorden problemas graves, por regra xeral. O resto dos consellos basicamente repítenos ou complementan.
- Se configuraches e habilitou FAST VP, déixao activado. Que asigne os datos no tempo previsto e pouco a pouco dunha vez ao ano e repercuta gravemente na realización doutras tarefas. Nestes casos, a redistribución de datos pode levar moito tempo.
- Teña coidado ao elixir unha xanela de traslado. Aínda que isto é obvio, intente elixir un tempo con menos carga en Unity e asignar un tempo suficiente.
- Planifica a túa expansión de almacenamento, faino a tempo. Esta é unha recomendación xeral que tamén é importante para FAST VP. Se a cantidade de espazo libre é moi pequena, o movemento de datos ralentizarase ou será imposible. Especialmente se descoidaches o punto 2.
- Ao expandir un grupo con FAST VP activado, non comeces coas unidades máis lentas. É dicir, ou engadimos todos os grupos RAID planificados á vez, ou engadimos primeiro os discos máis rápidos. Neste caso, a redistribución de datos a novos discos "rápidos" aumentará a velocidade global da agrupación. Se non, comezando con discos "lentos", podes ter unha situación moi desagradable. En primeiro lugar, os datos transferiranse a novos discos relativamente lentos e despois, ao engadir outros máis rápidos, na dirección oposta. Existen matices asociados a diferentes políticas de FAST VP, pero no caso xeral, esta situación é posible.
Se estás mirando este produto, podes probar Unity en acción de balde descargando a aplicación virtual Unity VSA.
Ao final do artigo, comparto algunhas ligazóns útiles:
- Páx
- – Breve descrición da función
- , formato pdf
Conclusión
Quero escribir moito, pero entendo que non todos os detalles interesarán ao lector. Por exemplo, pode falar con máis detalle sobre os criterios polos que FAST VP toma a decisión de transferir datos, sobre os procesos para analizar as estatísticas de E/S. Ademais, o tema da interacción con , e isto tira dun artigo separado. Incluso podes fantasear co desenvolvemento desta tecnoloxía. Espero que non fose aburrido e non te aburrira. Ata pronto!
Fonte: www.habr.com