Recuperação de um pool degradado

Um pool degradado está em funcionamento, mas perdeu a redundância: mais uma falha de disco no mesmo grupo de dispositivos causará perda de dados. Este procedimento tem um único objetivo: restaurar a redundância sem perder nada no caminho. A velocidade importa aqui, mas a sequência importa mais: identificar o disco errado transforma um incidente em perda de dados.

O vStack Center obtém a integridade do pool de duas fontes, e elas podem divergir durante um incidente. O banco de dados do vStack Center armazena o estado coletado pelo inventário; as telas da interface o exibem. As consultas diretas aos nós contornam o banco de dados: elas consultam os nós no momento e não gravam nada no banco. Durante um incidente, confie na consulta direta e use as telas para informações de capacidade e indicadores dos processos em andamento.

Fonte	Onde está disponível	O que fornece	Quando usar
Consulta direta ao nó	Somente pela API	Uma árvore de pools e dispositivos com o estado de cada elemento	Confirmar o incidente e encontrar o disco com falha
Propriedades do pool informadas pelo ZFS	Cartão do pool, seção Properties	Capacidade, capacidade usada, eficiência e o nó que hospeda o pool	Examinar as propriedades de um pool específico
Banco de dados do vStack Center	Storage Resources, tabela ZFS pools	Integridade, capacidade usada, indicadores de resilver e de scrub	Determinar se a recuperação está em andamento e se há espaço suficiente

Uma consulta direta sem um nó especificado consulta todos os nós do cluster de uma vez e combina as respostas em uma única lista. Respostas parciais são permitidas: um nó indisponível aparece como uma entrada separada com o estado UNAVAILABLE e não faz a consulta inteira falhar. Disso decorre uma regra importante para ler a resposta: "o nó não respondeu" e "o pool falhou" são eventos diferentes e não devem ser confundidos.

A restauração da redundância usa a mesma operação da substituição planejada: o pool muda para um disco substituto e, em seguida, o resilver começa. A proteção contra perda de dados também se aplica durante um incidente: o vStack Center consulta o nó sobre o disco substituto e só envia o comando se esse disco estiver livre. Se o estado dele for desconhecido, a operação é recusada.

As operações com discos físicos, exceto o acendimento de indicadores, não estão disponíveis na interface web. Um administrador usa a API para consultar pools diretamente, consultar o papel de um disco, marcar um disco como spare, substituir um disco e remover um disco do cluster — consulte a referência da API.

Pré-requisitos

• O papel Cluster master (role_id=1), necessário para as operações com discos físicos e para a leitura dos pools do cluster;
• A flag feature.physical_disc_management: sem ela, o subsistema de discos fica indisponível, incluindo as consultas diretas aos pools, a lista de discos, a substituição, a marcação de um disco como spare e o acendimento de indicadores;
• Um disco substituto no mesmo nó do pool degradado: livre ou spare. Um disco substituto em outro nó não pode ser usado;
• Nenhuma outra substituição está em andamento neste pool: apenas uma substituição por pool de cada vez;
• vStack Center versão 3.0.5.

Etapa 1. Confirme que o pool está degradado

Primeiro, certifique-se de que a degradação é real e não causada por informações desatualizadas do banco de dados.

1. Abra Provider Data Center → Storage Resources. A tabela ZFS pools contém as colunas GUID, Name, Health, Consuming, Scrubbing, Resilvering, Current node e Capacity (RAW). A coluna Health identifica um pool não íntegro.

2. Consulte os pools diretamente pela API. A consulta é somente leitura e pode ser repetida com segurança, e responde a uma pergunta que a tela não responde: qual dispositivo dentro do pool falhou.

3. Leia a resposta como uma árvore achatada em uma lista.

   Nível da entrada	O que descreve	O que verificar
   Pool em um nó	O pool inteiro	Nome do pool, estado, nó
   Grupo de dispositivos	Um grupo dentro de um pool, como um mirror	Estado do grupo
   Dispositivo	Um disco específico	Caminho do dispositivo e estado

Uma entrada que mostra um nó no estado UNAVAILABLE significa que o nó não respondeu à consulta, e não que o pool dele falhou. Verifique esse nó separadamente na coluna Health da tabela Server Nodes; o incidente pode não envolver discos.

Os dados da tabela ZFS pools vêm do banco de dados; portanto, durante um incidente, compare-os com uma consulta direta: a tela pode mostrar o último estado registrado.

Etapa 2. Determine se a recuperação já está em andamento

Se o resilver já começou, por exemplo porque o pool substituiu automaticamente um disco spare, uma intervenção causará danos.

1. Na tabela ZFS pools, verifique a coluna Resilvering do pool em questão. O valor um significa "recuperação em andamento": aguarde a conclusão e depois decida se a substituição é necessária.
2. Abra o pool e leia a seção Properties: Capacity, Provisioned, Used e Free. Um pool muito cheio demora mais para se recuperar, e deve haver espaço suficiente para o resilver.
3. Verifique também Scrubbing: uma verificação de integridade iniciada no nó também aumenta a carga sobre o pool.

Etapa 3. Localize o disco com falha

Uma consulta direta fornece o caminho do dispositivo; as telas fornecem o modelo, a localização no gabinete e a integridade do disco. Faça a correspondência com precisão: você removerá um disco físico, que é identificado pelo gabinete e pelo slot.

1. Pegue o caminho do dispositivo na entrada da consulta direta com estado anormal.
2. Abra a seção Pool Disks do cartão do pool (ou a seção Disks do cartão do nó) e encontre esse caminho na aba Placement, na coluna Device. Os campos adjacentes Enclosure_device, Enclosure_id e Dev_index indicam a localização do disco no gabinete.
3. Verifique o modelo e a integridade do disco na aba Disk props, nas colunas Model, Size (GB) e Status.
4. Acenda o indicador do disco para que o engenheiro na sala de servidores escolha o slot correto. Na seção Disks do cartão do nó, vá para a aba Front view ou Inner view. Cada disco tem ali botões de indicador de localização e de falha. Durante um incidente, o indicador de falha é mais adequado: ele indica explicitamente "este disco falhou".
5. Verifique se os indicadores estão acesos na aba LED on panel, nas colunas Led_fault e Led_locate.

Se o caminho da resposta direta não constar da lista de discos, o disco não foi inventariado. Execute um inventário do nó para a classe cam e depois ses, e abra a lista novamente.

Etapa 4. Verifique se o pool está importado

Um tipo separado de incidente parece degradação, mas exige outra solução: o pool não está em execução no nó. Um pool é executado no cluster como um serviço. Enquanto o serviço está parado, o cluster não vê o pool.

1. Na tabela ZFS pools, verifique a coluna Current node: ela indica qual nó hospeda o pool no momento. Um valor vazio ou a ausência do pool na tabela indica que o serviço do pool não está em execução.
2. Abra o pool a partir da tabela e, no menu Actions, selecione Start pool.
3. Certifique-se de que o pool aparece na tabela como em execução e depois repita a consulta direta: o pool também deve aparecer nessa resposta.

A permissão do serviço é um segundo atributo, independente: um serviço desabilitado não será iniciado, não importa quantas vezes você tente iniciá-lo. A habilitação e a desabilitação não estão disponíveis na interface web; um administrador executa essas operações pela API. O procedimento é explicado em "Gerenciamento dos serviços do cluster".

Um comando aceito confirma o recebimento pelo Cluster Manager, e não que o serviço realmente foi iniciado. A tabela de pools mostra o estado real quando o nó responde.

Etapa 5. Encontre ou prepare um disco substituto

A substituição não começará até que haja um disco livre disponível no nó. Livre significa um papel "spare" ou "não utilizado". O papel no banco de dados pode estar desatualizado, por isso confirme-o com uma consulta direta.

1. Encontre candidatos na seção Disks do cartão do nó: na aba ZFS props, um disco livre tem os campos Pool name e Vdev_pool_name vazios. Verifique Size (GB): o disco substituto deve ser pelo menos do mesmo tamanho que o disco substituído.
2. Atualize o papel do candidato consultando o nó diretamente pela API: o nó informa sobre o disco pelo caminho do dispositivo, e o vStack Center registra o papel atual.
3. Se nenhum disco estiver explicitamente marcado como spare, marque um disco livre como spare pela API. O nó recusa essa operação em um disco com dados ativos, a menos que a operação seja forçada. Este é um mecanismo de proteção.
4. Leia novamente a lista de discos e certifique-se de que o Pool name do disco substituto está vazio.

cuidado

Não use um disco de outro pool como substituto, mesmo que ele pareça livre. A proteção rejeitará o comando com o código -24907, mas verificar o papel antes da chamada é mais fácil do que investigar uma recusa durante um incidente.

Etapa 6. Inicie a substituição

Um administrador executa a substituição pela API. Todas as verificações ocorrem antes de o comando ser enviado ao nó: uma chamada inválida não chegará ao disco.

Prepare o seguinte:

• O nó que contém o disco com falha e o disco substituto;
• O nome do pool, da coluna Name da tabela ZFS pools;
• O caminho do dispositivo com falha, obtido na consulta direta;
• O caminho do disco substituto, que deve ser diferente do caminho do dispositivo com falha.

Um comando aceito significa "enviado ao nó". O resultado real chega na resposta do nó: em caso de sucesso, o disco substituto é marcado como membro do pool; em caso de falha, um erro é retornado, e o disco antigo não é marcado automaticamente como defeituoso.

Não envie o mesmo comando novamente. Uma segunda substituição no mesmo pool é rejeitada com o código -24906, e uma segunda operação destrutiva no mesmo disco, com -24504.

Etapa 7. Aguarde a restauração da redundância

A recuperação é executada no nó; o vStack Center apenas a exibe. Verifique dois lugares: o estado atual da árvore em uma consulta direta e o indicador do processo na tela de pools.

1. Na tabela ZFS pools, acompanhe as colunas Health e Resilvering. O valor um em Resilvering significa que a recuperação está em andamento; zero com um valor íntegro em Health significa que ela foi concluída.
2. Repita as consultas diretas para esse nó. O sucesso significa que o caminho do disco substituto tomou o lugar do caminho antigo, e os estados do pool e do grupo de dispositivos voltaram ao normal.
3. Verifique a composição do pool no cartão do pool, na aba Placement da seção Pool Disks.

Até que o pool volte a um estado íntegro, trate-o como vulnerável: a redundância ainda não foi restaurada, e outra falha no mesmo grupo de dispositivos causará perda de dados.

Conclusão do trabalho

1. Apague os indicadores: cartão do nó → seção Disks → aba Front view ou Inner view. Verifique o resultado na aba LED on panel.
2. Remova o disco com falha do cluster antes de removê-lo fisicamente. Essa operação usa a API com o número de série ou o caminho do dispositivo. Confirme com uma consulta direta que o pool não usa mais esse disco.
3. Restaure a reserva de discos spare. O disco substituto agora está no pool, e não resta nenhum spare no nó: coloque um novo disco online no cluster e marque-o como spare.
4. Atualize o inventário após as alterações físicas: execute um inventário do nó para a classe ses e depois cam. Caso contrário, a lista de discos manterá uma entrada do disco removido com um Last_seen desatualizado.
5. Leia a propriedade autoreplace do pool pela API. Se ela estiver desabilitada, um disco spare não será substituído automaticamente, e a próxima substituição precisará ser iniciada manualmente de novo.

Verificação do resultado

O que verificar	Onde ver	Resultado esperado
O pool recuperou a redundância	Storage Resources, coluna Health	O pool é exibido como íntegro
O pool usa o disco substituto	Consulta direta pela API	O caminho do disco substituto tomou o lugar do caminho do dispositivo com falha
O resilver terminou	Storage Resources, coluna Resilvering	Valor 0 com um valor íntegro em Health
O disco substituto está registrado como membro do pool	Cartão do pool, Pool Disks → ZFS props	Os campos Pool name e Vdev_pool_name do disco substituto estão preenchidos
O disco com falha foi removido do cluster	Pela API	A flag "online no cluster" foi limpa
Os indicadores estão apagados	Seção Disks → LED on panel	Led_fault e Led_locate estão apagados
A reserva de discos spare foi restaurada	Pela API	O nó tem um disco com o papel "spare" e Pool name vazio
Todos os nós respondem	Consulta direta pela API	A resposta não contém entradas no estado UNAVAILABLE

Se algo der errado

O que você vê	Causa	O que fazer
Um nó está no estado UNAVAILABLE na resposta da consulta direta	O nó não respondeu à consulta. Isso não indica um pool degradado	Verifique o nó na tabela Server Nodes; o incidente pode não envolver discos
Código de erro -25003	Não foi possível obter a lista de nós do cluster ao consultar todos os nós	Consulte os nós individualmente e verifique a disponibilidade do Cluster Manager
Código de erro -24907	O disco substituto não está livre: seu papel não é "spare" nem "não utilizado"	Escolha outro disco ou libere este; atualize o papel com uma consulta direta
Código de erro -24908	Não foi possível determinar o estado do disco substituto: o nó não respondeu ou a solicitação excedeu o tempo limite	A substituição foi rejeitada intencionalmente. Verifique a conectividade com o nó e consulte o disco novamente
Código de erro -24906	Já há uma substituição em andamento neste pool	Aguarde o término da substituição atual: uma substituição por pool
Código de erro -24905	O dispositivo com falha e o novo dispositivo são o mesmo	Especifique dispositivos diferentes
Código de erro -24902	O pool está vazio ou não existe no nó	O pool pode não estar importado. Verifique Current node e inicie o pool pelo menu Actions
Código de erro -24903	O caminho do dispositivo com falha não foi informado	Use o caminho obtido na consulta direta
Código de erro -24904, -24502, -24402, -24803	A validação do formato do caminho do dispositivo falhou	Use um caminho no formato /dev/daN
Código de erro -24504	Uma operação destrutiva já está em andamento no disco	Aguarde a resposta do nó: duas operações destrutivas não podem ser executadas no mesmo disco
Código de erro -24503	O disco já está marcado como spare	Não é necessário repetir; verifique o papel do disco
Código de erro -24307, -24316	O formato do nome do gabinete está incorreto ou o gabinete não foi encontrado	Use um nome no formato /dev/sesN; se as informações divergirem, colete novamente o inventário dos gabinetes
Código de erro -24311, -24313, -24315	O valor do indicador não é 0 nem 1, ou nenhum indicador foi informado	Informe pelo menos um indicador com valor 0 ou 1
Código de erro -25002, -24901, -24501, -24401, -24301, -24201, -24801	A flag feature.physical_disc_management está desabilitada	Habilite o gerenciamento de discos físicos nas opções do cluster
Código de erro -403	A operação está disponível apenas para o papel Cluster master	Entre com um papel de nível de cluster
Código de erro -29	Não foi possível obter o mapa de pools do banco de dados	Baseie-se nas consultas diretas: o banco de dados está indisponível no momento
Código de erro -20512, -20522, -713	A validação do nome do serviço ou do nó falhou, ou o comando não chegou ao Cluster Manager	Use o nome do pool da coluna Name e verifique a disponibilidade do Cluster Manager
O comando é aceito, mas o estado não muda	O comando apenas foi encaminhado ao agente do nó	Abra as telas novamente e repita a consulta direta; o resultado chega na resposta do nó
A consulta direta informa "íntegro", mas a tabela ZFS pools informa "degradado"	As informações do banco de dados estão desatualizadas: o inventário as atualiza	Confie na consulta direta; atualize o banco de dados coletando os dados do host
A substituição foi bem-sucedida, mas o pool continua degradado	Mais de um disco falhou no pool, ou há uma falha em outro grupo de dispositivos	Leia novamente a árvore inteira na consulta direta e substitua os demais dispositivos com falha, um de cada vez
O pool está degradado, mas a árvore não contém discos com falha	O pool pode ter perdido acesso a alguns dispositivos por causa de um nó, e não de um disco	Verifique os estados dos nós e o serviço do pool; nenhuma substituição de disco é necessária

Limitações

Não é possível iniciar uma verificação de integridade do pool a partir do vStack Center; essa operação não está disponível. A coluna Scrubbing apenas informa se um processo iniciado no nó está em execução.

A integridade atual do pool obtida por consultas diretas não é gravada no banco de dados do vStack Center: uma consulta direta retorna o estado no momento da chamada. Ela não pode fornecer um histórico de eventos de degradação.

O progresso do resilver não está disponível em porcentagem; há apenas um indicador de que ele está em andamento. Estime a duração a partir do tamanho do pool na seção Properties.

Veja também

• O procedimento planejado quando o disco ainda está funcionando — "Substituição planejada de disco em um nó".
• O modelo da camada de armazenamento e as fontes do estado do pool — "Pools de armazenamento".
• O mapa de pools, a página do pool e as consultas diretas aos nós — "Visualização dos pools do cluster".
• Os serviços de pool e suas atribuições a nós — "Gerenciamento dos serviços do cluster".

Métodos da API

Operações da API nesta página: pd-pools-status, pd-list, pd-status-map, pd-led, pd-info, pd-spare, pd-replace, pd-use, pd-unuse, pool-map, pool-map-by-guid, pools-list, pools-get, get-statusmap, node-list, node-inventory, host-inventory, cluster-service-enable, cluster-service-start — consulte a referência da API.