Dall'introduzione di VMDK in cluster su datastore VMFS, applicazioni come Windows Server Failover Cluster (WSFC) non richiedono più RDM (Raw Device Mapping) per utilizzare le prenotazioni persistenti SCSI-3 (SCSI3-PR). Per questo motivo, Broadcom non offre supporto RDM per il protocollo NVMeoF. I clienti che utilizzano RDM con SDC e desiderano passare a NVMe/TCP devono convertire tali dischi in VMDK su un datastore VMFS con la proprietà VMDK in cluster. Questa conversione non può essere eseguita con Storage vMotion, pertanto applicazioni come WSFC incorreranno in downtime.

Questo articolo della Knowledge Base si applica a:

• Clienti che passano da SDC a NVMe/TCP sui sistemi PowerFlex 5.0
• Ambienti VMware vSphere 8.0U3 e 9.x che utilizzano RDM con multi-writer o controller bus SCSI fisico condiviso per dischi
• Cluster Oracle RAC
• Windows Server Failover Clustering, tra cui:
  • Cluster di failover di SQL Server
  • Cluster di file server
  • Dischi quorum cluster

Supporto:

Quando si utilizza VMDK in cluster, Dell supporta le seguenti versioni di queste procedure:

• ESXi versioni 8.0U3 e 9.x
  • Queste versioni supportano NVMe/TCP Clustered VMDK su PowerFlex 5.0
• PowerFlex 5.0
  • PowerFlex 4.x non è supportato

Quando si converte Oracle RAC, se non si utilizza Clustered VMDK, PowerFlex 4.x è supportato.

Sebbene questo articolo della Knowledge Base sia incentrato sulle applicazioni in cluster, è possibile convertire le VM standalone con RDM in VMDK utilizzando procedure simili, in particolare nel caso di Oracle con ASM. Se si utilizzano RDM perché sono necessari dispositivi passthrough diretti, la conversione in VMDK non è una soluzione appropriata.

Panoramica

Questo articolo descrive gli approcci supportati basati su best practice per la conversione di SDC esistenti e cluster di applicazioni basate su RDM in VMDK condivisi su datastore NVMe/TCP. I metodi di conversione variano in base ai requisiti dell'applicazione. Pianifica di conseguenza. Dell si aspetta che l'utente di questo articolo della KB conosca le tecnologie coperte; Pertanto, i passaggi sono di alto livello e raramente includono la sintassi.

Sono disponibili due casi d'uso principali di RDM:

1. Oracle RAC che utilizza RDM fisici con multi-writer
2. Windows Server Failover Clustering (WSFC) con RDM fisici per SCSI3-PR

Esiste un concetto importante relativo al controller di storage virtuale nelle VM VMware che è essenziale comprendere prima di procedere. Questi controller sono responsabili della connessione dei dischi virtuali alla VM. I controller virtuali non sono vincolati al protocollo di storage fisico utilizzato dal datastore sottostante. Ad esempio, sebbene il controller predefinito sia etichettato come "SCSI", è interamente virtuale e non riflette né limita il trasporto di storage fisico utilizzato al di sotto. A causa di questa astrazione, non fa alcuna differenza funzionale se si collega un VMDK utilizzando un controller SCSI o NVMe virtuale, indipendentemente dal fatto che il protocollo di storage sia SCSI o NVMeoF. In pratica, VMware consiglia in genere di utilizzare controller SCSI indipendentemente dal tipo di storage VMware Paravirtual (PVSCSI), in quanto tendono a offrire maggiore stabilità e prestazioni migliorate per la maggior parte dei carichi di lavoro; tuttavia, è possibile utilizzare i controller NVMe se si preferisce. 

1. Oracle RAC: Conversione di RDM in VMDK

Alcuni ambienti Oracle RAC utilizzano RDM per fornire storage condiviso per file di dati o gruppi di dischi ASM, anziché VMDK. È possibile convertire queste configurazioni online, anche se alcuni metodi richiedono tempi di inattività. Copriamo sia i modelli basati su RDM che quelli ASM.

1.1 RAC senza ASM

Se Oracle Automatic Storage Management (ASM) non è in uso, è possibile eseguire la conversione online utilizzando uno dei seguenti metodi.

Opzione A - Migrazione online dei file di dati

1. Creare nuovi VMDK condivisi:
• Datastore VMFS su NVMe/TCP (proprietà VMDK in cluster NON richiesta)
• Thick Provision Eager Zeroed (EZT)
• Multi-writer abilitato
2. Collegare VMDK a tutti i nodi RAC.
3. Aggiungere nuovi file di dati utilizzando i VMDK.
4. Eseguire la migrazione dei dati da datafile basati su RDM a file di dati basati su VMDK.
5. Eliminare i datafile originali basati su RDM.
6. Utilizzare crsctl/ocrconfig per spostare il clusterware.

Questo approccio evita i downtime, ma può richiedere lo spostamento dei dati a livello di tablespace o di oggetto, che può richiedere molto tempo.

Opzione B - Conversione in ASM (preferita)

La conversione ad ASM semplifica la gestione dello storage a lungo termine ed è lo stato finale strategico consigliato.

Esistono due approcci supportati:

• Migrazione online in gruppi di dischi ASM
• RMAN medianteBACKUP COME COPIA DATABASE
• Richiede una breve interruzione dell'alimentazione
• Più veloce e più sicuro per database di grandi dimensioni
• Comunemente preferito per i sistemi di produzione

1.2 RAC che utilizza già ASM

Se ASM è in uso, la sostituzione di RDM è semplice e online:

1. Creare nuovi VMDK condivisi:
• Datastore VMFS su NVMe/TCP (proprietà VMDK in cluster NON richiesta)
• Thick Provisioning desideroso azzerato
• Multi-writer abilitato
2. Aggiungere i VMDK al gruppo di dischi ASM.
3. Consentire il completamento del ribilanciamento ASM.
4. Eliminare i dischi ASM supportati da RDM.
5. Utilizzare crsctl/ocrconfig per spostare il clusterware.

Questo processo non richiede downtime delle applicazioni e presenta rischi minimi.

2. WSFC: Conversione di RDM in VMDK

⚠️ Importante: Eseguire la migrazione WSFC un disco alla volta per mantenere la stabilità del cluster. Questo esempio è un cluster a due nodi.

2.1 Prerequisiti (obbligatori)

Requisiti di VMware

• La versione hardware della macchina virtuale supporta VMDK in cluster
• Datastore VMFS su NVMe/TCP
• Funzione VMDK in cluster abilitata
• Dischi azzerati con impazienza di thick provisioning
• Nessuna snapshot sulle VM cluster
• Storage DRS disabilitato

Requisiti WSFC

• Cluster integro
• Convalida del cluster pulita (avvertenze accettabili)
• Ogni disco ha un singolo nodo proprietario

2.2 Creare nuovi VMDK condivisi

Per ogni disco RDM:

1. Creare un nuovo VMDK sul datastore NVMe/TCP (è richiesto un VMDK in cluster):
• Dimensioni uguali o superiori
• Thick Provisioning desideroso azzerato
2. Collegare il VMDK a entrambi i nodi del cluster:
• Stesso tipo di controller SCSI (PVSCSI consigliato)
• Stesso numero del controller
• Stesso ID SCSI
• Abilitare la condivisione del bus fisico SCSI

2.3 Preparare il disco (solo nodo proprietario)

Sul nodo proprietario corrente:

1. Portare online il nuovo disco.
2. Inizializzare come GPT.
3. Formattare NTFS con 128 KB.
4. Assegnare una lettera di unità temporanea.

Sul nodo secondario, lasciare il disco offline.

2.4 Migrazione dei dati (disco per disco)

Esempio per un disco dati di SQL Server:

1. Eseguire il failover del ruolo SQL sul nodo proprietario.
2. Arrestare le risorse SQL (SQL Server) utilizzando il precedente RDM e mantenere online il disco.
3. Copiare i dati utilizzando robocopy dove R è RDM e V è il nuovo VMDK:
   1. robocopy R:\ Presso:\ /MIR /COPYALL /DCOPY:T /R:0 /W:0
4. Verificare l'integrità dei dati.
5. Modificare le lettere dell'unità in modo che il nuovo disco abbia una lettera precedente.
6. Aggiornare le dipendenze delle risorse del cluster per fare riferimento al nuovo disco.
7. Portare le risorse online.
8. Spostare la proprietà su un altro nodo da testare.
9. Al termine, rimuovere la dipendenza dal vecchio disco (RDM).
10. Ripetere la procedura per ogni disco di dati

Ripetere questo processo per:

• Dischi di log
• Temp

2.5 Sostituire la risorsa disco del cluster

Dopo la convalida:

1. Rimuovere il disco RDM precedente dal ruolo cluster.
2. Aggiungere il nuovo disco VMDK al ruolo.
3. Verificare la proprietà e le dipendenze.
4. Spostare la proprietà su un altro nodo da testare.

2.6 Migrazione del disco quorum (se in uso)

Per evitare un'interruzione accidentale dell'alimentazione del cluster:

1. Passare temporaneamente al quorum alla maggioranza dei nodi anziché al disco.
   1. Set-ClusterQuorum -NodeMajority
2. Seguire la sezione 2.3 per aggiungere un nuovo disco.
3. Aggiungere il disco al cluster nell'interfaccia utente o Add-ClusterDisk in PS.
4. Impostare il nuovo disco come quorum nell'interfaccia utente o Set-ClusterQuorum -DiskWitness "Cluster Disk X"
5. Offline e rimuovere il disco RDM.

3 Rimuovere RDM

Solo dopo la convalida corretta in entrambi i casi d'uso:

1. Rimuovere i mapping RDM da entrambe le VM.
2. Scollegare le LUN dagli host ESXi.
3. Umap dei volumi in PowerFlex Manager.

4 Problemi comuni

1. Mancato utilizzo dei dischi EZT
   • Le soluzioni in cluster qui trattate richiedono EZT: nessun supporto per thin o zeroedthick
2. Configurazione del controller non corrispondente. Qualsiasi mancata corrispondenza riportata di seguito impedisce al disco di funzionare correttamente nel cluster.
   • Lo stesso tipo di controller SCSI
   • Lo stesso numero di controller
   • Lo stesso ID SCSI
3. Errore durante l'impostazione del multi-writer sui vmdk Oracle EZT su ogni VM (nodo) per ogni VMDK
4. Errore nell'impostazione della condivisione del bus fisico SCSI sul controller per WSFC 

4.1 Supporto alla configurazione

Link alla documentazione aggiuntiva (in ordine sparso):

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