Desde a introdução do VMDK em cluster em datastores VMFS, aplicativos como o WSFC (Windows Server Failover Cluster) não exigem mais RDMs (Raw Device Mappings) para usar reservas persistentes SCSI-3 (SCSI3-PR). Por isso, a Broadcom não oferece suporte a RDM para o protocolo NVMeoF. Os clientes que usam RDMs com o SDC e desejam migrar para NVMe/TCP devem converter esses discos em VMDKs em um datastore VMFS com a propriedade de VMDK em cluster. Essa conversão não pode ser feita com o Storage vMotion, portanto, aplicativos como o WSFC incorrerão em tempo de inatividade.

Este artigo da KB aplica-se a:

• Clientes migrando de SDC para NVMe/TCP em sistemas PowerFlex 5.0
• Ambientes VMware vSphere 8.0U3 e 9.x que usam RDMs com vários gravadores ou controlador de barramento SCSI físico compartilhado para discos
• Clusters do Oracle RAC
• Clustering de failover do Windows Server, incluindo:
  • SQL Server Failover Clusters
  • Clusters de servidor de arquivos
  • Discos de quorum de cluster

Suporte:

A Dell oferece suporte às seguintes versões para esses procedimentos ao usar VMDK em cluster:

• ESXi versões 8.0U3 e 9.x
  • Essas versões são compatíveis com VMDK em cluster NVMe/TCP no PowerFlex 5.0
• PowerFlex 5.0
  • O PowerFlex 4.x não é compatível

Ao converter o Oracle RAC, se você não estiver usando VMDK em cluster, o PowerFlex 4.x será compatível.

Embora este artigo da KB se concentre em aplicativos em cluster, você pode converter VMs independentes com RDMs em VMDKs usando procedimentos semelhantes, especialmente no caso do Oracle com ASM. Se você estiver usando RDMs porque precisa de dispositivos de passagem direta, a conversão em VMDKs não será uma solução apropriada.

Visão geral

Este artigo descreve as abordagens de práticas recomendadas compatíveis para converter clusters existentes de aplicativos SDC baseados em RDM em VMDKs compartilhados em armazenamentos de dados NVMe/TCP. Os métodos de conversão diferem com base nos requisitos do aplicativo. Planeje de acordo. A Dell espera que o usuário desta KB seja proficiente nas tecnologias cobertas; portanto, as etapas são de alto nível e raramente incluem sintaxe.

Há dois casos de uso principais de RDM abordados aqui:

1. Oracle RAC usando RDMs físicos com vários gravadores
2. WSFC (Windows Server Failover Clustering) usando RDMs físicos para SCSI3-PR

Há um conceito importante em relação ao controlador de armazenamento virtual em VMs VMware que é essencial entender antes de prosseguir. Esses controladores são responsáveis por conectar discos virtuais à VM. Os controladores virtuais não estão vinculados ao protocolo de armazenamento físico usado pelo datastore subjacente. Por exemplo, embora o controlador padrão seja rotulado como "SCSI", ele é totalmente virtual e não reflete ou restringe o transporte de armazenamento físico usado em. Devido a essa abstração, não faz diferença funcional se você anexa um VMDK usando um controlador SCSI ou NVMe virtual, independentemente de o protocolo de armazenamento ser SCSI ou NVMeoF. Na prática, a VMware geralmente recomenda o uso de controladores SCSI, independentemente do armazenamento do tipo VMware Paravirtual (PVSCSI), pois eles tendem a oferecer maior estabilidade e desempenho aprimorado para a maioria das cargas de trabalho; no entanto, você pode usar controladores NVMe, se preferir. 

1. Oracle RAC: Convertendo RDMs em VMDKs

Alguns ambientes Oracle RAC usam RDMs para fornecer armazenamento compartilhado para datafiles ou grupos de discos ASM, em vez de VMDKs. É possível converter essas configurações on-line, embora alguns métodos exijam tempo de inatividade. Cobrimos baseado em RDM e ASM.

1.1 RAC sem ASM

Se o Oracle Automatic Storage Management (ASM) não estiver em uso, você poderá converter on-line usando um dos métodos a seguir.

Opção A — migração de arquivos de dados on-line

1. Crie novos VMDKs compartilhados:
• Datastore VMFS em NVMe/TCP (a propriedade VMDK em cluster NÃO é necessária)
• Thick Provision Eager Zeroed (EZT)
• Vários gravadores ativados
2. Conecte VMDKs a todos os nós do RAC.
3. Adicione novos arquivos de dados usando os VMDKs.
4. Migre dados de datafiles baseados em RDM para datafiles baseados em VMDK.
5. Solte os datafiles originais baseados em RDM.
6. Use crsctl/ocrconfig para mover o clusterware.

Essa abordagem evita o tempo de inatividade, mas pode exigir movimentação de dados no nível do espaço de tabela ou no nível do objeto, o que pode ser demorado.

Opção B — Converter em ASM (preferencial)

A conversão para ASM simplifica o gerenciamento de armazenamento em longo prazo e é o estado final estratégico recomendado.

Existem duas abordagens compatíveis:

• Migração on-line para grupos de discos ASM
• RMAN usandoBACKUP AS COPY DATABASE
• Requer uma breve interrupção
• Mais rápido e seguro para grandes bancos de dados
• Comumente preferido para sistemas de produção

1.2 O RAC já está usando o ASM

Se o ASM estiver em uso, a substituição do RDM será simples e on-line:

1. Crie novos VMDKs compartilhados:
• Datastore VMFS em NVMe/TCP (propriedade VMDK clusterizada NÃO obrigatória)
• Provisionamento estático Eager Zeroed
• Vários gravadores ativados
2. Adicione os VMDKs ao grupo de discos do ASM.
3. Permita a conclusão do rebalanceamento de ASM.
4. Solte discos ASM apoiados por RDMs.
5. Use crsctl/ocrconfig para mover o clusterware.

Esse processo não requer tempo de inatividade do aplicativo e apresenta riscos mínimos.

2. WSFC: Convertendo RDMs em VMDKs

⚠️ Importante: Execute a migração WSFC um disco de cada vez para manter a estabilidade do cluster. Este exemplo é um cluster de dois nós.

2.1 Pré-requisitos (obrigatórios)

Requisitos da VMware

• A versão de hardware da VM é compatível com VMDKs em cluster
• Datastore VMFS em NVMe/TCP
• Recurso VMDK em cluster ativado
• Thick Provision Eager Zeroed Disks
• Nenhum snapshot nas VMs do cluster
• DRS de armazenamento desativado

Requisitos do WSFC

• Integridade do cluster
• Limpeza da validação do cluster (advertências aceitáveis)
• Cada disco tem um único nó proprietário

2.2 Criar novos VMDKs compartilhados

Para cada disco RDM:

1. Crie um novo VMDK no datastore NVMe/TCP (VMDK em cluster obrigatório):
• Mesmo tamanho ou tamanho maior
• Provisionamento estático Eager Zeroed
2. Conecte o VMDK aos dois nós do cluster:
• Mesmo tipo de controladora SCSI (recomenda-se PVSCSI)
• Mesmo número de controlador
• Mesmo ID de SCSI
• Habilitar o compartilhamento de barramento físico SCSI

2.3 Preparar disco (somente nó proprietário)

No nó proprietário atual:

1. Coloque o novo disco on-line.
2. Inicialize como GPT.
3. Formate NTFS com 128 KB.
4. Atribua uma letra de unidade temporária.

No nó secundário, deixe o disco off-line.

2.4 Migrar dados (disco por disco)

Exemplo para um disco de dados do SQL Server:

1. Falha da função SQL para o nó proprietário.
2. Interrompa os recursos SQL (SQL Server) usando o RDM antigo, mantenha o disco on-line.
3. Copie dados usando robocopy em que R é o RDM e V é o novo VMDK:
   1. robocopy R:\ V:\ /MIR/COPYALL /DCOPY:T /R:0 /W:0
4. Verifique a integridade dos dados.
5. Altere as letras da unidade para que o novo disco tenha a letra antiga.
6. Atualize as dependências dos recursos do cluster para fazer referência ao novo disco.
7. Coloque recursos on-line.
8. Mova a propriedade para outro nó para testar.
9. Quando terminar, remova a dependência do disco antigo (RDM).
10. Repita para cada disco de dados

Repita esse processo para:

• Discos de registro
• Temp

2.5 Substituir recurso de disco do cluster

Após a validação:

1. Remova o disco RDM antigo da função de cluster.
2. Adicione o novo disco VMDK à função.
3. Confirme a propriedade e as dependências.
4. Mova a propriedade para outro nó para testar.

2.6 Migração de disco de quórum (se em uso)

Para evitar a interrupção acidental do cluster:

1. Alterne temporariamente o quórum para maioria de nós, em vez de disco.
   1. Set-ClusterQuorum -NodeMajority
2. Siga a seção 2.3 para adicionar um novo disco.
3. Adicione o disco ao cluster na interface do usuário do ou Add-ClusterDisk no PS.
4. Defina o novo disco como o quorum na interface do usuário ou Set-ClusterQuorum -DiskWitness "Cluster Disk X"
5. Off-line e remova o disco RDM.

3 Remova RDMs

Somente após validação bem-sucedida em qualquer um dos casos de uso:

1. Remova os mapeamentos de RDM de ambas as VMs.
2. Desconecte as LUNs dos hosts do ESXi.
3. Umap dos volumes no PowerFlex Manager.

4 Problemas comuns

1. Falha ao usar discos EZT
   • As soluções em cluster abordadas neste documento requerem EZT (não há suporte para thin, ou zeroedthick)
2. Configuração do controlador incompatível. Qualquer disparidade abaixo impede que o disco funcione corretamente no cluster.
   • O mesmo tipo de controladora SCSI
   • O mesmo número de controlador
   • O mesmo ID de SCSI
3. Falha ao definir vários gravadores nos vmdks do Oracle EZT em cada VM (nó) de cada VMDK
4. Falha ao definir o compartilhamento de barramento físico SCSI no controlador para WSFC 

4.1 Suporte à configuração

Links de documentação adicional (sem ordem específica):

https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver17

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

https://knowledge.broadcom.com/external/article/313472/microsoft-windows-server-failover-cluste.html

https://blogs.vmware.com/cloud-foundation/2023/07/06/shared-disk-clustering-on-vsphere-getting-out-of-the-multi-writer-flag-jam/

https://www.vmware.com/docs/vmw-vmdk-whitepaper-mmt

https://learn.microsoft.com/en-us/troubleshoot/windows-server/high-availability/configuring-witness-resource

https://learn.microsoft.com/windows-server/administration/windows-commands/robocopy