Aqui está um problema em um WSFC (Windows Server Failover Cluster) 2016 que hospeda uma Instância de Cluster de Failover SQL (FCI) que emprega o Storage Spaces Direct (S2D). Em cada servidor, após a criação inicial bem-sucedida, o S2D adicionou automaticamente um volume RAID não utilizado ao pool de armazenamento (embora o S2D não possa ser criado em volumes RAID e insista absolutamente em discos não montados). Agora está quebrado, devido a - até onde eu pude descobrir - exatamente isso. Como conseqüência, o disco virtual está offline, derrubando todo o cluster. Ele não volta a ficar on-line devido a um recurso de rede de cluster ausente. Os discos em questão podem ser retirados, mas não removidos. O reparo do disco virtual não é executado, o teste de compatibilidade de cluster reivindica uma configuração inválida.
Esta é uma nova configuração. Então, eu poderia simplesmente excluir o disco virtual, o cluster ou até os servidores e começar de novo. Mas antes de sermos produtivos, preciso ter certeza de que isso nunca mais acontecerá. O sistema disparando no joelho virtual para uma parada fatal, adicionando desnecessariamente e incorretamente um disco não suportado, não é uma plataforma que possamos implantar. Então, principalmente, preciso de uma maneira de impedir que isso aconteça, em vez de repará-lo agora. Meu palpite é que impedir uma configuração do S2D de pegar mais discos do que foi criado seria suficiente. O custo de uma interação potencialmente mais manual durante uma substituição real do disco é insignificante para o clusterf ... que temos aqui. Por mais que eu tenha procurado a documentação até agora, no entanto, não consigo encontrar nenhuma maneira de controlar isso. A menos que esteja faltando alguma coisa, nem o Set-StoragePool,
Qualquer ajuda ou dica seria muito apreciada.
A seguir, são apresentados mais detalhes sobre o exposto acima: Temos duas máquinas servidores HPE DL380 Gen9 duplamente conectadas entre si por Ethernet de 10 GB com capacidade RDMA e via 1 GB à rede do cliente. Cada recurso possui um controlador RAID HP ??? e um simples controlador HBA HP ?? (já que o S2D exige e funciona apenas em discos não montados diretamente conectados). A configuração de armazenamento compreende um OS-RAID no controlador RAID, um Files-RAID no controlador RAID e o conjunto de discos conectados diretamente no HBA destinado ao S2D.
Configurei 2 datacenter do Windows Servers 2016 nos OS-RAIDs, instalei o recurso WSFC, executei e passei no teste de compatibilidade de cluster, incluindo a opção S2D, criei o cluster sem armazenamento, adicionei uma testemunha de compartilhamento de arquivo (em uma máquina separada), habilitei o S2D no pool de armazenamento, que consistia automaticamente em todos os discos não organizados, e em cima desse pool criou um disco virtual do tipo espelho e usou o NTFS como sistema de arquivos, já que esse deveria ser o FS de escolha para uma FCI do SQL instalação.
Em seguida, instalei o SQL 2016 standard edition como um FCI nesse cluster, importei um banco de dados e testei tudo. Tudo estava bem. O banco de dados estava ali e mais rápido do que nunca. O failover forçado e automático foi fácil. Tudo parecia bom.
No dia seguinte, tentamos usar o RAID de arquivos restante. A primeira coisa foi mudar o nível do RAID, pois não gostamos da pré-configuração. Logo após excluir o volume RAID pré-configurado e criar um novo (em cada servidor), detectamos que o cluster estava inoperante. Pelo que pude descobrir até agora, o volume Files-RAID pré-configurado foi entretanto adicionado automaticamente ao pool e, como acabamos de excluí-lo, ele estava ausente no pool. Enquanto verifiquei, encontrei o novo Files-RAID, enquanto ainda estava sendo criado, já mostrado como uma unidade física do pool. Portanto, o pool agora incluía 2 volumes RAID em cada servidor, um dos quais nem existia. Esses volumes (mas não seus discos) são listados pelo Get-PhysicalDisk junto com os discos realmente físicos no HBA, não tendo certeza se isso é regular.
Consegui retirar esses discos físicos (ou seja, aqueles que são realmente os volumes RAID) e agora estão marcados como aposentados. Mas eles ainda estão na piscina e não posso removê-los agora, tentando fazer isso falhar. Um Repair-VirtualDisk deve reconstruir o disco virtual para um estado adequado apenas nos discos restantes (passei por isso: https://social.technet.microsoft.com/Forums/windows/en-US/dbbf317b-80d2-4992- b5a9-20b83526a9c2 / espaço de armazenamento-remova-disco-físico? forum = winserver8gen ), mas esse trabalho termina imediatamente, "com êxito", é claro, sem nenhum efeito.
A tentativa de alternar o disco virtual novamente online falha, informando que um recurso de cluster de rede está indisponível. Pelo que entendi, isso só poderia se referir ao pool de armazenamento (disponível), pois os discos ausentes não são recursos de cluster. O pool não mostra erros para corrigir. A execução do teste de compatibilidade de cluster exige uma configuração não adequada para um cluster.
Não consigo encontrar nenhuma parte que possa se mover mais um centímetro, a coisa toda parece um impasse para sempre. Alguma idéia de como impedir que um WSFC em execução se processe dessa maneira?
Não encontrei nenhuma mensagem de erro que achei particularmente esclarecedora e não queria bombardear ainda mais a página publicando todas elas. Se alguém quiser obter detalhes específicos, entre em contato.
Muito obrigado pelo seu tempo, pessoal!
Karsten
Atualização conforme solicitado pelo Sr. Raspberry
Get-PhysicalDisk -CanPool $true | Sort Model | ft FriendlyName, BusType, CanPool, OperationalStatus, HealthStatus, Usage, SizeAlém disso, há alguma chance de você ter cometido um erro ao reconfigurar o File-RAID atribuindo uma unidade S2D a um novo RAID?