S2D em ReadOnly pós-quebra de energia: Conflito de metadados na pool (6-node cluster)

Olá Andre Jesus, obrigado por postar na comunidade Microsoft Q&A.

Quando ocorre uma queda de energia abrupta em um cluster S2D, as operações de gravação que estavam em andamento podem não ser concluídas em todos os nós, fazendo com que os metadados da pool armazenados localmente nos discos fiquem fora de sincronia (metadata conflict ou split-brain). Como medida de segurança estrita para evitar corrupção irreversível dos dados, o S2D coloca a storage pool no modo ReadOnly. Os dois discos com o status Lost Communication exacerbam essa situação, pois o cluster impede novas gravações até ter a garantia de que o quórum da pool e a consistência dos metadados foram devidamente restabelecidos.

A abordagem mais segura inicialmente não é tentar um force recovery autoritativo dos metadados de forma destrutiva, pois um passo em falso aqui pode destruir a redundância. A melhor prática é informar ao cluster que a tempestade já passou e tentar remontar a pool em leitura/gravação de forma graciosa.

Solução Padrão:

1. Tente investigar os dois discos reportando "Lost Communication". Muitas vezes, verificar a conectividade, realizar um reseat (remoção e reinserção física do disco, se for hot-swap) ou até mesmo reiniciar os serviços de armazenamento no nó que os hospeda pode fazer os discos voltarem ao estado OK. Retomar o quórum físico facilita o aceite da pool.
2. Tente limpar a flag de ReadOnly manualmente. Em um dos nós sobreviventes, abra o PowerShell como Administrador e execute:

Get-StoragePool -FriendlyName "NomeDaSuaPool" | Set-StoragePool -IsReadOnly $false

3. Se o comando for bem-sucedido e a pool voltar online, você deve iniciar a tarefa de verificação de integridade dos dados para recuperar as inconsistências residuais do crash:

Get-ScheduledTask -TaskName "Data Integrity Scan for Crash Recovery" | Start-ScheduledTask

4. Após o início do scan, tente anexar (attach) seus Virtual Disks que possivelmente ficaram desanexados:

Get-VirtualDisk | Where-Object OperationalStatus -eq 'Detached' | Connect-VirtualDisk

Workaround e Considerações Avançadas:

Se o comando Set-StoragePool retornar um erro de "Access Denied", isso geralmente significa que o cluster bloqueou o recurso e assumiu um estado de falha. Nesse caso, tente forçar o recurso da pool a ficar online utilizando os cmdlets de cluster:

Get-ClusterResource | Where-Object ResourceType -eq "Storage Pool" | Start-ClusterResource

Se a dessincronização dos metadados for severa e os comandos padrão forem rejeitados, não existe um comando de "force recovery" seguro no S2D voltado para uso direto do usuário que não carregue um risco altíssimo de perda de dados. Se chegar a este cenário extremo, será necessário analisar microscopicamente os metadados do cluster.

Para referência adicional sobre os estados do S2D, você pode consultar a documentação oficial da Microsoft:

• Solucionar problemas do Espaços de Armazenamento Diretos
• Status de integridade e operacionais dos Espaços de Armazenamento