2.9. Entenda a recriação de cluster

O cluster de armazenamento se recupera sozinho. Em caso de falha em um nó ou disco, o cluster tentará restaurar os dados perdidos automaticamente, ou seja, recriar-se.

O processo de reconstrução tem várias etapas. Cada CS envia uma mensagem de pulsação para um MDS a cada 5 segundos. Se a pulsação não for enviada, o CS é considerado “inativo” e o MDS informa a todos os componentes do cluster que eles devem parar de solicitar operações nesses dados. Se nenhuma pulsação for recebida de um CS em 15 minutos, o MDS considera esse CS offline e inicia a recriação do cluster (quando os pré-requisitos abaixo são atendidos). Durante o processo, o MDS localiza CSes que não possuem partes (réplicas) dos dados perdidos e restaura os dados – uma parte (réplica) por vez – da seguinte forma:

  • Quando a replicação é usada, as réplicas existentes de um fragmento degradado são bloqueadas (para que permaneçam idênticas) e uma é copiada para o novo CS. Se nesse momento um cliente precisar ler alguns dados que ainda não foram recriados, ele lerá a réplica remanescente desses dados, caso houver uma.
  • Quando o código de correção de erros (erasure coding) é usado, o novo CS solicita quase todas as partes de dados remanescentes para recriar o que falta. Se nesse momento um cliente precisar ler alguns dados que ainda não foram recriados, os dados serão recriados fora da sua vez e lidos.

Nota

Se um nó ou disco ficar offline durante a manutenção, a recuperação automática do cluster será atrasada para economizar recursos do cluster. O atraso padrão é 30 minutos. Você pode ajustá-lo configurando o parâmetro mds.wd.offline_tout_mnt em milissegundos, com o comando vstorage -c <cluster_name> set-config.

A autorrecuperação exige mais tráfego de rede e recursos de CPU quando a replicação é usada. Por outro lado, a recriação com código de correção de erros (erasure coding) é mais lenta.

Para que um cluster possa se recriar, ele precisa ter pelo menos:

  1. A mesma quantidade de nós íntegros exigida pelo modo de redundância
  2. Espaço livre suficiente para acomodar o máximo de dados que um nó possa armazenar

O primeiro pré-requisito pode ser explicado no exemplo a seguir. Em um cluster que funciona no modo de código de correção de erros (erasure coding) 5+2 e tem sete nós (ou seja, o mínimo), cada parte dos dados do usuário é distribuída por 5+2 nós para fins de redundância, ou seja, todos os nós são usados. Em caso de falha de um ou dois nós, os dados do usuário não serão perdidos, mas o cluster ficará degradado e não será capaz de se recriar até que pelo menos sete nós fiquem íntegros novamente (ou seja, até que você adicione os que faltam). Para fins de comparação, em um cluster que funciona no modo de código de correção de erros (erasure coding) 5+2 e tem dez nós, cada parte dos dados do usuário é distribuída por 5+2 nós aleatórios em dez para equilibrar a carga nos CSs. Em caso de falha de até três nós, esse cluster ainda terá nós suficientes para se recriar.

O segundo pré-requisito pode ser explicado no exemplo a seguir. Em um cluster que tem dez nós de 10 TB, pelo menos 1 TB em cada nó deve ser mantido livre para que, caso haja a falha de um nó, seus 9 TB de dados possam ser recriados nos nove nós restantes. No entanto, se um cluster tem dez nós de 10 TB e um nó de 20 TB, cada nó menor deve ter pelo menos 2 TB livres caso o nó maior venha a falhar (já o nó maior deve ter 1 TB livre).

Duas recomendações que ajudam a aliviar a sobrecarga de recriação:

  • Para simplificar a recriação, mantenha as contagens de disco e os tamanhos de capacidade uniformes em todos os nós.
  • A recriação aumenta a carga da rede e a latência das operações de leitura e gravação. Quanto maior a largura de banda de rede do cluster, mais rápida será a recriação do cluster e a liberação da largura de banda.