VNX: Qual é a diferença entre LUNs estáticos e dinâmicos?

LUN estático:

Quando um LUN estático é criado, todo o espaço que será usado para o LUN é reservado; se houver espaço insuficiente no pool, o LUN estático não será criado. Uma alocação inicial de 3 GiB contém metadados e dados do usuário e, conforme os usuários salvam dados adicionais ao LUN, fatias de 1GiB são alocadas conforme necessário. Essas fatias contêm 1 GiB de endereços de bloco lógico (LBAs) contíguos, assim, quando uma fatia é gravada pela primeira vez, ela será alocada ao LUN estático. Como o rastreamento acontece em uma granularidade de 1 GiB, a quantidade de metadados é relativamente baixa e as pesquisas necessárias para encontrar a localização da fatia no Pool são rápidas. Como as pesquisas são necessárias, os acessos a LUNs estáticos serão mais lentos do que os acessos a LUNs tradicionais.

LUN dinâmico:

Os LUNs dinâmicos também alocam fatias de 1 GiB quando é necessário espaço, mas a granularidade dentro dessas fatias está no nível de bloco de 8 KiB. Toda fatia de 1 GiB será alocada a apenas um LUN dinâmico, mas os blocos de 8 KiB não serão necessariamente de LBAs contíguos. A sobrerreserva é permitida, de modo que, o tamanho total dos LUNs dinâmicos em um pool pode exceder o tamanho do espaço de dados físico disponível. O monitoramento é necessário para garantir que as condições de falta de espaço não ocorram. Há uma sobrecarga consideravelmente maior associada a LUNs dinâmicos do que com LUNs estáticos e tradicionais, e como resultado, o desempenho é reduzido de forma substancial.

Como calcular metadados de LUNs de pool?

Os metadados são associados ao uso de LUNs estáticos e dinâmicos. Os metadados são usados para localizar os dados nas LUNs privadas usadas na estrutura de Pools (desempenho lento devido às pesquisas necessárias para encontrar a localização da fatia no Pool). A quantidade de metadados depende do tipo e do tamanho do LUN.

Para metadados de LUN estático (GB) = .001* capacidade (GB) + 3 GB
Para metadados de LUN dinâmico (GB) = .02* capacidade (GB) + 3 GB

Em resumo, note que:

O uso de LUNs dinâmicos não é compatível em alguns ambientes: por exemplo, em grupos de armazenamento do VNX File.
Os LUNs dinâmicos nunca devem ser usados quando o alto desempenho for um objetivo importante (consulte o artigo335002).
O espaço do pool deve ser monitorado cuidadosamente (LUNs dinâmicos permitem a sobrerreserva de pool, enquanto que os LUNs estáticos não). O sistema emite um alerta quando o consumo de qualquer pool atinge um limite selecionável pelo usuário.  Por padrão, esse limite é de 70% e permite tempo de amostra para que o usuário tome qualquer ação corretiva necessária (consulte o artigo 78223).

Os LUNs dinâmicos devem ser posicionados em ambientes em bloco, nos quais a economia de espaço e a eficiência de armazenamento superam o desempenho como os principais objetivos. As áreas em que o espaço de armazenamento é tradicionalmente superalocado e nas quais a funcionalidade de alocação de espaço sob demanda de LUN dinâmico seria uma vantagem, incluem diretórios base de usuário e espaços de dados compartilhados.

Se a FAST VP for um requisito e os LUNs de pool estiverem sendo propostos por esse motivo, é importante lembrar que os LUNs estáticos alcançam melhor desempenho do que os LUNs dinâmicos.
Esteja ciente de que os LUNs dinâmicos não são recomendados em determinados ambientes. Entre eles estão o Exchange 2010 e sistemas de arquivos no VNX.

O espaço é atribuído a LUNs dinâmicos com uma granularidade de 8 KiB (dentro de uma fatia de 1 GiB). A implicação aqui é que o rastreamento é necessário para cada 8 KiB de dados salvos em um LUN dinâmico e esse rastreamento envolve sobrecarga de capacidade na forma de metadados. Além disso, como não é possível prever a localização dos 8 KiB de dados, cada acesso de dados a um LUN dinâmico exige uma pesquisa para determinar a localização dos dados. Se os metadados não estiverem residindo na memória no momento, será necessário ter acesso ao disco e isso resultará em um tempo de resposta prolongado. Isso faz com que os LUNs dinâmicos sejam consideravelmente mais lentos do que os LUNs tradicionais e mais lentos do que os LUNs estáticos. Como os LUNs dinâmicos usam esses metadados adicionais, a recuperação desses LUNs após certos tipos de falha (por exemplo, falhas de cache sujo) demorará consideravelmente mais do que a recuperação de LUNs estáticos ou tradicionais. Portanto, uma recomendação importante é colocar aplicativos essenciais em LUNs estáticos ou tradicionais.

Em alguns ambientes, aqueles com alta localidade de referência de dados, o FAST Cache pode ajudar a reduzir os impactos no desempenho da pesquisa de metadados. 

Unidades

* Decimal: todos são potências de 10

** KB, MB, GB, TB — 103, 106, 109, 1012
** 1.000, 1.000.000, 1.000.000.000, 1.000.000.000.000

* Binário: todos são potências de 2

** KiB, MiB, GiB, TiB — 210, 210, 220, 230, 240
** 1.024 — 1.048.576 — 1.073.741.824 — 1.099.511.627.776

* Os fabricantes de discos usam unidades decimais para listar a capacidade
*As velocidades de link são medidas em unidades decimais
* Os tamanhos de E/S, página de cache e LUN são unidades binárias

As unidades usadas no projeto de ambientes de armazenamento podem ser confusas. No sistema SI de medição, os multiplicadores são decimais e mega, por exemplo, significa 106 ou 1.000.000.
No entanto, algumas medidas usadas em TI são baseadas nos equivalentes binários, que são um pouco maiores que as unidades decimais. Note, por exemplo, que no nível TB/TiB a unidade binária é quase 10% maior que a unidade decimal.
Os fabricantes de discos especificam tamanhos de disco em unidades decimais e usam um tamanho de setor de 512 bytes ao discutir tamanhos formatados. Os sistemas VNX Block e seus predecessores CLARiiON usam setores de 520 bytes e isso também deve ser levado em consideração. Note que os tamanhos de cache, LUN e sistema de arquivos são especificados em unidades binárias.
As unidades binárias são um padrão relativamente novo, estabelecido pela IEC em 2000. O padrão foi aceito por todas as principais organizações de padrões, incluindo o IEEE.

No flare 32, quando você cria um novo LUN estático, todas as fatias são pré-atribuídas. Isso serve para manter todas as fatias na mesma SP quando o LUN é criado, "os LBAs do array são atribuídos sequencialmente" para impedir que algumas fatias sejam atribuídas ao par da controladora (isso pode ocorrer em determinadas circunstâncias).
 

LUN estático na versão 32:

Com a introdução do novo Ambiente operacional (OE) do EMC VNX para bloco versão 5.32, versão do arquivo 7.1, não há alteração no comportamento dos LUNs dinâmicos, mas os LUNs estáticos serão totalmente alocados na criação. Isso significa que todas as fatias de 1 GB serão alocadas quando o LUN for criado pela primeira vez. As gravações ainda serão organizadas de acordo com o intervalo de endereços de bloco lógico, como era originalmente o caso. LUNs estáticos e dinâmicos podem compartilhar o mesmo pool. Quando um LUN estático é criado, toda a sua capacidade é reservada e alocada no pool para uso por esse LUN.  Portanto, um LUN estático nunca ficará sem capacidade. Todas as novas gravações estão localizadas e distribuídas em toda a área pré-alocada, de modo que a capacidade relatada pelo host é aproximadamente igual à capacidade consumida. LUNs estáticos têm desempenho superior ao dos LUNs dinâmicos devido ao endereçamento direto e devem ser usados para aplicativos em que o desempenho é mais importante do que a economia de espaço. Esse aprimoramento tem implicações benéficas para o FAST VP, pois, ao alocar totalmente o LUN de pool estático na criação, os usuários podem controlar melhor em qual nível as fatias são gravadas. À medida que os pools são inicialmente criados e ainda há espaço suficiente no nível mais alto, os usuários podem ter certeza de que, ao criar um LUN com o nível mais alto disponível ou com o nível mais alto, os dados do nível automático serão gravados no nível mais alto, pois o LUN é alocado imediatamente.

Consumo de LUN estático por nível para a versão 31:

Quando você cria um LUN estático, o armazenamento do pool necessário para esse LUN não é realmente alocado, mas é reservado. Como essas reservas são baseadas no pool e não no nível, esse armazenamento reservado não se reflete no detalhamento do nível no nível do LUN estático até que o LUN estático seja gravado e o armazenamento seja realmente alocado.
Além disso, quando você define uma preferência de armazenamento em camadas para um LUN estático, o armazenamento é reservado apenas para o LUN, mesmo que o LUN estático pareça estar totalmente provisionado. Como essas reservas não são feitas em um nível por camada, no momento em que os dados forem realmente alocados ao LUN estático como resultado de uma gravação, o nível de armazenamento solicitado originalmente pode não estar mais disponível. Se você ativar o FAST, esse problema será resolvido durante as realocações subsequentes.