Siden introduktionen af klynge-VMDK på VMFS-datalagre kræver programmer som Windows Server Failover Cluster (WSFC) ikke længere RDM'er (Raw Device Mappings) for at bruge SCSI-3 permanente reservationer (SCSI3-PR). Derfor tilbyder Broadcom ikke RDM-understøttelse af NVMeoF-protokollen. Kunder, der bruger RDM'er med SDC, og som ønsker at flytte til NVMe/TCP, skal konvertere disse diske til VMDK'er på et VMFS-datalager med egenskaben Clustered VMDK. Denne konvertering kan ikke udføres med Storage vMotion, så programmer som WSFC medfører nedetid.

Denne KB gælder for:

• Kunder, der flytter fra SDC til NVMe/TCP på PowerFlex 5.0-systemer
• VMware-, vSphere 8.0U3- og 9.x-miljøer, der bruger RDM er med enten multi-writer eller delt fysisk scsi bus-controller til diske
• Oracle RAC-klynger
• Windows Server Failover-klyngedannelse, herunder:
  • SQL Server-failover-klynger
  • Filserverklynger
  • Klyngequorum-diske

Support:

Dell understøtter følgende versioner af disse procedurer ved brug af klynget VMDK:

• ESXi-versionerne 8.0U3 og 9.x
  • Disse versioner understøtter NVMe/TCP-klynget VMDK på PowerFlex 5.0
• PowerFlex 5.0
  • PowerFlex 4.x understøttes ikke

Når du konverterer Oracle RAC, og du ikke bruger klyngelagret VMDK, understøttes PowerFlex 4.x.

Selvom denne KB fokuserer på klyngeprogrammer, kan du konvertere enkeltstående VM'er med RDM'er til VMDK'er ved hjælp af lignende procedurer, især i tilfælde af Oracle med ASM. Hvis du bruger RDM'er, fordi du har brug for direkte passthrough-enheder, er konvertering til VMDK'er ikke en passende løsning.

Oversigt

Denne artikel beskriver de understøttede, bedste praksis-tilgange til konvertering af eksisterende SDC, RDM-baserede programklynger til delte VMDK'er på NVMe/TCP-datalagre. Omregningsmetoder varierer baseret på applikationskrav. Planlæg i overensstemmelse hermed. Dell forventer, at brugeren af denne KB er dygtig til de omfattede teknologier. Derfor er trin på højt niveau og indeholder sjældent syntaks.

Der er to primære RDM-brugsscenarier, der er dækket her:

1. Oracle RAC bruger fysiske RDM er med multi-writer
2. Windows Server Failover Clustering (WSFC), der bruger fysiske RDM er til SCSI3-PR

Der er et vigtigt koncept vedrørende virtuel lagercontroller i VMware VM'er, som er vigtigt at forstå, før du fortsætter. Disse controllere er ansvarlige for at forbinde virtuelle diske til VM'en. Virtuelle controllere er ikke bundet til den fysiske storageprotokol, der bruges af det underliggende datalager. For eksempel, mens standardcontrolleren er mærket som "SCSI", er den helt virtuel og afspejler eller begrænser ikke den fysiske lagertransport, der bruges nedenunder. På grund af denne abstraktion gør det ingen funktionel forskel, om du tilslutter en VMDK ved hjælp af en virtuel SCSI- eller NVMe-controller, uanset om lagringsprotokollen er SCSI eller NVMeoF. I praksis anbefaler VMware generelt at bruge SCSI-controllere uanset opbevaring af typen VMware Paravirtual (PVSCSI), da de har tendens til at tilbyde større stabilitet og forbedret ydeevne for de fleste arbejdsbelastninger; Du kan dog bruge NVMe-controllere, hvis du foretrækker det. 

1. Oracle RAC: Konvertering af RDM er til VMDK'er

Nogle Oracle RAC-miljøer bruger RDM'er til at levere delt storage til datafiler eller ASM-diskgrupper i stedet for VMDK'er. Det er muligt at konvertere disse opsætninger online, selvom nogle metoder kræver nedetid. Vi dækker både RDM-baseret og ASM.

1.1 RRR uden ASM

Hvis Oracle Automatic Storage Management (ASM) ikke er i brug, kan du konvertere online ved hjælp af en af følgende metoder.

Mulighed A – Onlinedatafilmigrering

1. Opret nye delte VMDK'er:
• VMFS-datalager på NVMe/TCP (VMDK-klyngeejendom IKKE påkrævet)
• Tyk klargøring ivrig nulstillet (EZT)
• Understøttelse af flere skrivemaskiner
2. Knyt VMDK'er til alle RAC-noder.
3. Tilføj nye datafiler ved hjælp af VMDK'erne.
4. Overfør data fra RDM-baserede datafiler til VMDK-baserede datafiler.
5. Slip de oprindelige RDM-baserede datafiler.
6. Brug crsctl/ocrconfig til at flytte clusterware.

Denne fremgangsmåde forhindrer nedetid, men kan kræve dataflytning på tabelplads- eller objektniveau, hvilket kan være tidskrævende.

Mulighed B – Konverter til ASM (foretrukket)

Konvertering til ASM forenkler langsigtet storageadministration og er den anbefalede strategiske sluttilstand.

Der findes to understøttede tilgange:

• Onlinemigrering til ASM-diskgrupper
• RMAN brugerBACKUP AS COPY DATABASE
• Kræver en kort afbrydelse
• Hurtigere og sikrere for store databaser
• Almindeligvis foretrukket til produktionssystemer

1.2 RAC, der allerede anvender ASM

Hvis ASM er i brug, er RDM-udskiftning ligetil og online:

1. Opret nye delte VMDK'er:
• VMFS-datalager på NVMe/TCP (VMDK-klyngeegenskab IKKE påkrævet)
• Tyk klargøring ivrig nulstillet
• Understøttelse af flere skrivemaskiner
2. Føj VMDK'erne til ASM-diskgruppen.
3. Tillad ASM-genbalancering at fuldføre.
4. Drop ASM-diske, der understøttes af RDM'er.
5. Brug crsctl/ocrconfig til at flytte clusterware.

Denne proces kræver ingen nedetid for applikationen og udgør en minimal risiko.

2. WSFC: Konvertering af RDM er til VMDK'er

⚠️ Vigtigt: Udfør WSFC-migrering én disk ad gangen for at bevare klyngestabiliteten. Dette eksempel er en klynge med to noder.

2.1 Forudsætninger (obligatoriske)

VMware-krav

• VM-hardwareversionen understøtter grupperede VMDK'er
• VMFS-datalager på NVMe/TCP
• Grupperet VMDK-funktion aktiveret
• Tyk klargøring ivrige nulstillede diske
• Ingen snapshots på klynge-VM'er
• Storage DRS deaktiveret

WSFC-krav

• Klynge sund
• Klyngevalidering ren (advarsler acceptable)
• Hver disk har en enkelt ejernode

2.2 Opret nye delte VMDK'er

For hver RDM-disk:

1. Opret en ny VMDK på NVMe/TCP-datalager (VMDK med klynger påkrævet):
• Samme eller større størrelse
• Tyk klargøring ivrig nulstillet
2. Knyt VMDK til begge klyngenoder:
• Samme SCSI-controllertype (PVSCSI anbefales)
• Samme controllernummer
• Samme SCSI-id
• Aktivér SCSI fysisk busdeling

2.3 Forbered disk (kun ejernode)

På den aktuelle ejernode:

1. Gør den nye disk online.
2. Initialiser som GPT.
3. Format NTFS med 128KB.
4. Tildel et midlertidigt drevbogstav.

Lad disken være offline på den sekundære node.

2.4 Migrer data (disk-for-disk)

Eksempel på en SQL Server-datadisk:

1. Fejl SQL-rollen til den ejende node.
2. Stop SQL-ressourcer (SQL Server) ved hjælp af den gamle RDM, hold disken online.
3. Kopier data ved hjælp af robokopi, hvor R er RDM og V er den nye VMDK:
   1. robokopi R:\ V:\ /MIR /COPYALL /DCOPY:T /R:0 /W:0
4. Bekræft dataintegritet.
5. Skift drevbogstaver, så den nye disk har gamle bogstaver.
6. Opdater klyngeressourceafhængigheder, så de refererer til den nye disk.
7. Bring ressourcer online.
8. Flyt ejerskabet til en anden node for at teste.
9. Når du er færdig, skal du fjerne afhængigheden af den gamle disk (RDM).
10. Gentag for hver datadisk

Gentag denne proces for:

• Logdiske
• Temp

2.5 Udskift klyngediskressource

Efter validering:

1. Fjern den gamle RDM-disk fra klyngerollen.
2. Føj den nye VMDK-disk til rollen.
3. Bekræft ejerskab og afhængigheder.
4. Flyt ejerskabet til en anden node for at teste.

2.6 Quorum-diskmigrering (hvis den er i brug)

Sådan forhindrer du utilsigtet klyngeafbrydelse:

1. Skift midlertidigt quorum til nodeflertal i stedet for disk.
   1. Set-ClusterQuorum – NodeMajority
2. Følg Section 2.3 for at tilføje en ny disk.
3. Føj disken til klyngen i brugergrænsefladen eller Add-ClusterDisk i PS.
4. Indstil den nye disk som quorum i UI eller Set-ClusterQuorum -DiskWitness "Cluster Disk X"
5. Offline, og fjern RDM-disken.

3 Fjern RDM'er

Først efter vellykket validering i begge brugstilfælde:

1. Fjern RDM-tilknytninger fra begge VM'er.
2. Afmonter LUN'er fra ESXi-værter.
3. Umap enhederne i PowerFlex Manager.

4 Almindelige problemer

1. Manglende brug af EZT-diske
   • De klyngeløsninger, der er dækket her, kræver EZT – ingen understøttelse af tynd eller zeroedthick
2. Uoverensstemmende controllerkonfiguration. Nedenstående uoverensstemmelse forhindrer disken i at fungere korrekt i klyngen.
   • Den samme SCSI-controllertype
   • Det samme controllernummer
   • Det samme SCSI-id
3. Manglende indstilling af multi-writer på Oracle EZT vmdks på hver VM (node) for hver VMDK
4. Manglende indstilling af SCSI fysisk busdeling på controlleren til WSFC 

4.1 Understøttelse af konfiguration

Yderligere dokumentationslinks (i vilkårlig rækkefølge):

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