Isilon OneFS: O pool de SSD está próximo de atingir 100% ou está significativamente mais cheio do que o pool de discos rígidos associado — ID do evento: 100010018

Degradação do desempenho devido ao preenchimento de SSDs em um fluxo de trabalho que utiliza estratégias de SSD para melhorar o desempenho, como armazenar espelhamentos de metadados ou dados "dinâmicos" na SSD.
Este artigo se aplica a todas as versões do OneFS.

As estratégias de SSD diferentes de L3 incluem a possibilidade de preencher SSDs mais rapidamente do que o disco rígido. Uma SSD quase 100% cheia pode resultar em degradação significativa do desempenho.
Note que os problemas de "SSD cheia", assunto deste artigo da KB, não se aplicarão se todos os nós com SSDs as usarem para cache L3.

Condições necessárias para que haja um problema de desempenho:

• O armazenamento SSD que usa "isi status" deve exibir "Used/Size" para pelo menos alguns nós:
• A taxa de preenchimento da SSD é maior do que a taxa do disco rígido associado, por exemplo, o disco rígido está 70% cheio, enquanto as SSDs estão 80% cheias.
  Se a capacidade da SSD preenchida for aproximadamente a mesma do disco rígido e um pool de nós ou cluster inteiro estiver próximo dos limites de capacidade, consulte o Guia de solução de problemas do cliente Isilon: Solucionar problemas de um pool ou cluster completo

Fatores que contribuem para o preenchimento de SSDs mais rápido do que as unidades de disco rígido (HDD)

• Os snapshots podem ser um fator contribuinte significativo quando
  • Os diretórios são ajustados com frequência, como várias vezes por hora, especialmente pastas com alta taxa de alteração, inclusive inclusão, exclusão ou renomeação. Esses fatores são indicados quando a exibição de relatórios do trabalho SnapshotDelete mostra muitas "LINs excluídas", como meio milhão por trabalho.
  • Quando qualquer diretório "ativo", como na pasta com várias alterações de arquivo por minuto, tem um agendamento de política SyncIQ de "when-source-modified"
  • Muitos snapshots acumulados, como mais de 40 salvos em qualquer caminho, ou cinco mil ou mais um determinado momento.
  • O processo de limpeza de snapshots está sendo afetado pelo problema de governança de snapshots. Afeta apenas determinadas versões do OneFS; consulte o artigo da KB: "Grandes listas de governança de snapshots podem resultar na alocação de um grande número de blocos de extensão do IFM e preencher SSDs" (em inglês), em https://support.emc.com/kb/520985 (é necessária uma conta de suporte Dell para visualizar esse artigo)
  • O TreeDelete é frequentemente usado no fluxo de trabalho em um diretório protegido com snapshots locais ou do SyncIQ, e uma grande quantidade, como mais de meio milhão de LINs, é excluída rotineiramente quando o TreeDelete é executado, o que significa que as LINs excluídas são adicionadas à lista de alterações de snapshot. Quando a versão do OneFS é afetada pelo problema da lista de Governança de snapshots, os metadados de governança de snapshots podem reter LINs e crescer mais rapidamente do que os metadados de LINs removidas pela exclusão de arquivos.
• A política de pool de arquivos padrão ou as políticas personalizadas de pool de arquivos podem afetar uma porcentagem significativa de arquivos quando
  • "Data SSD Strategy: metadata" significa gravar uma cópia dos metadados na SSD.
  • "Data SSD Strategy: metadata-write" significa gravar todos os espelhamentos de metadados do cluster na SSD
  • "Data SSD Strategy: data" significa gravar todos os dados de arquivo em SSD (raro e pouco recomendado, a menos que toda ou a maior parte do armazenamento seja em SSD)
  • "Snapshot SSD Strategy: metadata" significa gravar uma cópia dos metadados da SSD na SSD
  • "Snapshot SSD Strategy: metadata-write" significa gravar todos os espelhamentos de metadados de snapshot na SSD
  • "Snapshot SSD Strategy: data" significa gravar arquivos de snapshot na SSD (raro e pouco recomendado, a menos que toda ou a maior parte do armazenamento seja em SSD)
  • Regras personalizadas de pool de arquivos aplicadas para aproveitar a SSD para pastas ou dados "dinâmicos" específicos como gravação de metadados ou destino de dados. A importância delas não é comum, mas, quando encontradas, geralmente envolvem uma pasta que foi cuidadosamente considerada antes de ser personalizada para melhorar o desempenho do aplicativo.
• Outros possíveis fatores que contribuem para o preenchimento das SSDs mais rápido do que o disco rígido:
  • Perfil pequeno do arquivo. Uma porcentagem significativa dos tamanhos de arquivo está abaixo de 128 KB, o que significa mais "metadados" (Lins, também conhecidos como IDs de arquivo) por volume de armazenamento
  • As sysctls personalizadas foram introduzidas para melhorar o desempenho armazenando espelhamentos, como btrees do sistema, espelhamentos delta do sistema e blocos de contagem de cotas. Isso é raro e, para clusters com mais de 2% de SSD, essas btrees raramente totalizam mais de 1% ou 2% de SSD.
  • O volume de armazenamento em cluster inclui menos de 2% de SSD, como uma parte significativa dos nós projetados para arquivamento nearline (NL) com pouca ou nenhuma SSD.
  • Um acúmulo de muitos arquivos ChangeListCreate (CLC) no cluster Dell PowerScale.

Todas as condições necessárias devem estar presentes, mais qualquer um dos fatores contribuintes ou uma combinação deles.

Comandos e recursos para detectar e identificar os principais contribuintes para o problema de as SSDs ficarem cheias mais rapidamente do que os discos rígidos:
A sintaxe é do OneFSv8.0.x, normalmente a mesma ou semelhante para OneFSv7.2.x e 8.1.x. Consulte o Guia do administrador da CLI para obter a sintaxe da versão do OneFS.

Comando                onde/por que é usado
isi status -q   identifica se os nós incluem "Used/Size" (possível problema), usam a SSD como cache L3 ou apresentam "No Storage SSDs".

" isi sync policies list -v |grep -vi target |egrep 'Name:|Path:|Schedule:' |paste - - - |tr -s "

para frequência de agendamento, inclusive qualquer agendamento como "when-source-modified"
isi snapshot snapshots list   exibe snapshots acumulados, seus SnapIDs e totais.
isi job status  lista os trabalhos SnapshotDelete e TreeDelete concluídos recentemente, inclusive o ID do trabalho.
isi job reports view <ID>   para analisar LINs excluídas e o total de LINs de um ID de trabalho de amostra.
isi filepool default-policy view   mostra as estratégias padrão de SSD metadados de dados e metadados de snapshot.
isi filepool policies list -v  mostra políticas personalizadas com detalhes da estratégia de SSD.
isi storagepool list  informa os nomes de pool de armazenamento no cluster, usados para visualizar e modificar políticas de pool de arquivos.
isi statistics ... protocol, client, heat e system apresentam estatísticas sobre o fluxo de trabalho atual, por exemplo, para estimar a taxa de leitura/gravação do protocolo e determinar os "principais comunicadores", como os arquivos e pastas mais acessados (em operações por segundo). Use "man isi-statistics" para obter uma sinopse das informações disponíveis.
cat /etc/mcp/override/sysctl.conf exibe o ajuste personalizado persistente do sysctl. Qualquer comando com "ssd" (por exemplo, efs.bam.layout.ssd) pode significar que um ajuste foi feito no comportamento da SSD. Entre em contato com a equipe de contas da Dell ou com o Suporte para obter orientações sobre o ajuste do sysctl e consulte o artigo da KB 462759 — OneFS: Configurando alterações do sysctl para persistirem por meio de reinicializações e upgrades de nós e clusters, em https://support.emc.com/kb/462759 (é necessária uma conta do Suporte Dell para visualizar esse artigo)

• O artigo da KB 520985 informa as versões do OneFS suscetíveis a grandes listas de governança de snapshots; consulte https://support.emc.com/kb/520985 (é necessária uma conta do Suporte Dell para visualizar esse artigo)
• Os dados do InsightIQ FSAnalyze (FSA) podem mostrar a porcentagem de arquivos "pequenos", ou seja, arquivos com menos de 128 k.

isi_changelist_mod -l Esse comando exibirá uma lista de changelists existentes no cluster.

Para criar a solução mais eficaz, identifique o máximo possível de fatores que contribuem para o preenchimento das SSDs a partir da "descoberta" de causa acima.

Objetivo:
O objetivo é a resolução de problemas usando táticas simples com o menor impacto negativo no desempenho. O risco é evitado quando a SSD está a apenas alguns por cento da capacidade total do disco rígido, desde que este não esteja também imprudentemente cheio.

Ação:
Os exemplos de planos de ação abaixo estão classificados com os cenários mais frequentes e úteis na parte superior. Dependendo dos contribuintes de causa identificados, misture e combine táticas para criar um plano de ação proativo eficaz. Observe que sempre que uma política de pool de arquivos é alterada, é necessário executar um trabalho SmartPools (ou SetProtectPlus) para que as alterações entrem em vigor, o que pode levar dias.

Cenário A: Muitos snapshots contribuintes

Muitos snapshots, agendamentos frequentes de snapshot/sincronização e trabalhos SnapshotDelete ou TreeDelete geralmente relatam >500 mil LINs excluídas; a política padrão de pool de arquivos para dados é metadata (não metadata-write ou data) e a versão do OneFS tem problema de governança de snapshot.

Recomendado:

Mover metadados de snapshot para o disco rígido, deixando metadados de cluster que não sejam de snapshots na SSD.

Procedimento:

1. Definir a estratégia padrão de pool de arquivos para metadados de SSD como "avoid"

   isi filepool default-policy modify --snapshot-ssd-strategy avoid

2. Executar Smartpools (ou SetProtectPlus, caso o Smartpools não esteja licenciado)

   isi job start smartpools

Resultado:

Move os metadados de snapshot para o disco rígido. Embora essa tática possa reduzir o desempenho de leitura/namespace nos snapshots, ela retém os metadados do cluster na SSD.

Cenário B: Os espelhamentos de metadados são armazenados em SSD, e é improvável que os (meta)dados de snapshot sejam um fator significativo

Relativamente poucos snapshots e/ou pouco frequentes, a política padrão de pool de arquivos é metadata-write, e as políticas personalizadas de pool de arquivos não redirecionam uma quantidade significativa para a SSD.

Recomendado:

Modificar a política padrão do pool de arquivos (e políticas personalizadas substancialmente grandes) para mover espelhamentos de metadados da SSD para o disco rígido. Em seguida, com a SSD "sobressalente" (porcentagem disponível abaixo da porcentagem preenchida do disco rígido), criar/modificar políticas personalizadas do pool de arquivos para restaurar os espelhamentos de metadados para a SSD apenas em pastas de gravação/alteração "mais acessadas" com maior probabilidade de se beneficiarem, até que a porcentagem de preenchimento da SSD corresponda à do disco rígido. Essa tática requer licença do Smartpools e se beneficia mais do uso do "isi statistics heat" para determinar as pastas que mais se comunicam.

Procedimento:

1. Definir a estratégia padrão de pool de arquivos para metadados de SSD como metadata

   isi filepool default-policy modify --data-ssd-strategy metadata

2. Executar o trabalho Smartpools

   isi job start smartpools

3. Quando a SSD estiver abaixo da porcentagem de preenchimento do disco rígido após a remoção dos espelhamentos, usar políticas dedicadas de pool de arquivos para aproveitar a SSD agora disponível para gravação de metadados em pastas com alta porcentagem de gravação.
   O exemplo abaixo cria uma política de pool de arquivos que utiliza a gravação de metadados de SSD em arquivos de um diretório "bastante acessado" /ifs/data/sql/finance para um destino de armazenamento local chamado Performance_2.

   isi filepool policies create Save_SQL_Fin_Data --begin-filter --path=/ifs/data/SQL/finance --end-filter --data-access-pattern random --data-storage-target Performance_2 --data-ssd-strategy=metadata-write

4. Executar o trabalho Smartpools

   isi job start smartpools

5. Limpar o processo e repetir as etapas B4-B5 até que o preenchimento da SSD esteja com alguns por cento a menos de espaço livre do que o disco rígido.

Resultado:

Transfere os espelhamentos de metadados da SSD para o disco rígido, deixando apenas uma cópia de metadados na SSD, o que pode liberar até 80% da capacidade da SSD em situações em que os metadados da SSD são o principal contribuinte.
A primeira etapa provavelmente reduzirá o desempenho de gravação e manterá os benefícios das operações read/namespace_read com uma cópia de metadados restante na SSD.
As etapas subsequentes aproveitam a capacidade sobressalente criada na SSD para retornar à estratégia de gravação de metadados nas pastas de gravação/alteração mais acessadas, restaurando grande parte do desempenho de gravação perdido após a alteração da política padrão e reduzindo significativamente o risco das SSDs atingirem 100%.

Cenário C: Muitos snapshots E espelhamentos de metadados usam SSD

A combinação de A e B, ou seja, a existência de muitos snapshots e a política padrão de pool de arquivos para SSD de dados é metadata-write.

Recomendado:

Primeiro, usar o procedimento A para remover dados de snapshot das SSDs se o snapshot provavelmente for um fator significativo. Verificar o status da capacidade para ver se o problema foi resolvido e, em seguida, usar o procedimento B, se necessário. Os metadados de cluster para leituras de namespace geralmente beneficiam o desempenho do client mais do que os metadados de snapshot.

Cenário D: Problema não resolvido usando as resoluções acima, e o fluxo de trabalho de leitura predomina sobre o de gravação

A quantidade de SSD poderá ser insuficiente para todas as LINs se, por exemplo, o fluxo de trabalho for predominantemente de arquivos pequenos e a cominação do cluster incluir nós de classe NL com pouca ou nenhuma SSD. Se nenhuma das opções acima conseguir colocar a SSD em um nível seguro, igual ou abaixo dos níveis de disco rígido, considere converter as SSDs em cache L3 para evitar o sobrecarregamento e aproveitar a SSD disponível para estender a vida útil do cache L2.

Recomendado:

Converter SSDs em cache L3 e iniciar um trabalho Smartpools.

1. Converter SSDs da estratégia de metadados para serem usadas inteiramente para o cache L3.

   isi storagepool nodepools modify <storagepool name> --l3 true -f

   1. Opcional: Se namespace_read forem as operações de protocolo predominantes, um cluster terá uma grande porcentagem de arquivos pequenos e/ou pequenas quantidades de SSDs, como classe NL; ajustar L3 para armazenar apenas metadados e não dados.
      Opcional: Adicionar esta linha a /etc/mcp/override/sysctl.conf:

      efs.l3:efs.l3.meta_only=1

2. Executar o trabalho Smartpools

   isi job start smartpools

Resultado:

Transfere todos os dados e metadados da SSD que os armazena no disco rígido e converte SSDs para uma extensão do cache L2, preenchendo-as novamente com os dados e metadados expirados mais recentemente do cache L2.
Dependendo do fluxo de trabalho, o uso da SSD como cache L3 pode melhorar o desempenho. A estratégia L3 da SSD tende a ser melhor quando o tráfego do client é de 70:30 ou superior na taxa leitura/gravação, e melhor ainda quando os mesmos dados estão sendo lidos repetidamente por vários clients. Por exemplo, se o L2 estiver em torno de 80%, mas tiver um tempo de vida curto, o que significa que muitas das falhas de cache L2 se devem à expiração rápida do cache, o uso de SSD para L3 basicamente estenderá a vida útil dos dados em cache L2 e dos metadados e melhorará o desempenho reduzindo as falhas de cache. A configuração opcional acima de usar L3 apenas para metadados estende a vida útil do cache dos metadados, mas não economiza também os dados L2 expirados no cache L3. A opção L3 somente com metadados pode resultar em desempenho semelhante à estratégia de metadados de SSD, com a exceção de que apenas os metadados acessados mais recentemente são armazenados, o que significa que o benefício da aceleração de namespace é reduzido à medida que os dados ficam mais antigos (dados acessados há mais tempo).

Cenário E: Um acúmulo de muitos arquivos ChangeListCreate (CLC) no cluster Dell PowerScale.

Siga a resolução descrita no artigo da KB:000259887 PowerScale: Os arquivos ChangeListCreate preenchem SSDs e podem causar problemas de desempenho