Sen jälkeen kun klusteroitu VMDK otettiin käyttöön VMFS-tietosäilöissä, Windows Server Failover Clusterin (WSFC) kaltaiset sovellukset eivät enää edellytä RDM:ien (Raw Device Mappings) -määrityksiä SCSI-3:n pysyvien varausten (SCSI3-PR) käyttämiseen. Tämän vuoksi Broadcom ei tarjoa RDM-tukea NVMeoF-protokollalle. Asiakkaiden, jotka käyttävät RDM:iä SDC:n kanssa ja haluavat siirtyä NVMe/TCP:hen, on muunnettava kyseiset levyt VMDK:iksi VMFS-tietosäilössä, jossa on klusteroitu VMDK-ominaisuus. Tätä muuntamista ei voi tehdä Storage vMotionilla, joten WSFC:n kaltaiset sovellukset aiheuttavat käyttökatkoja.

Tämä tietämyskannan artikkeli koskee seuraavia:

• SDC:stä NVMe/TCP:hen PowerFlex 5.0 -järjestelmissä siirtyvät asiakkaat
• VMware vSphere 8.0U3- ja 9.x-ympäristöt, jotka käyttävät RDM:iä, joissa on joko usean kirjoittajan ohjain tai jaettu fyysinen scsi-väyläohjain levyille
• Oracle RAC -klusterit
• Windows Serverin vikasietoklusterointi, mukaan lukien:
  • SQL Serverin vikasietoklusterit
  • Tiedostopalvelinklusterit
  • Cluster Quorum -levyt

Tuki:

Dell tukee seuraavia versioita klusteroidussa VMDK:ssa:

• ESXi-versiot 8.0U3 ja 9.x
  • Nämä versiot tukevat NVMe/TCP Clustered VMDK:ta PowerFlex 5.0:ssa
• PowerFlex 5.0
  • PowerFlex 4.x -versiota ei tueta

PowerFlex 4.x:ää tuetaan, kun muunnat Oracle RAC:tä etkä käytä klusteroitua VMDK:ta.

Vaikka tämä tietämyskannan artikkeli keskittyy klusteroituihin sovelluksiin, voit muuntaa erilliset RDM-virtuaalikoneet VMDK-virtuaalikoneiksi käyttämällä samanlaisia menetelmiä, erityisesti jos Oraclessa on ASM. Jos käytät RDM:iä, koska tarvitset suoria läpivientilaitteita, muuntaminen VMDK:iksi ei ole sopiva ratkaisu.

Yleiskuvaus

Tässä artikkelissa esitellään tuetut parhaat käytännöt olemassa olevien SDC- ja RDM-pohjaisten sovellusklustereiden muuntamiseksi jaetuiksi VMDK:iksi NVMe/TCP-tietosäilöissä. Muunnosmenetelmät vaihtelevat sovellusvaatimusten mukaan. Suunnittele sen mukaan. Dell olettaa, että tämän tietämyskannan artikkelin käyttäjä hallitsee sopimuksen kattamat tekniikat. Siksi vaiheet ovat korkean tason ja sisältävät harvoin syntaksia.

Tässä käsitellään kahta ensisijaista RDM-käyttötapausta:

1. Oracle RAC käyttää fyysisiä RDM:iä ja useita kirjoittajia
2. Windows Server Failover Clustering (WSFC) fyysisten RDM:ien avulla SCSI3-PR:lle

VMware-virtuaalikoneiden virtuaalitallennusohjaimeen liittyy tärkeä käsite, joka on tärkeää ymmärtää ennen jatkamista. Nämä ohjaimet vastaavat virtuaalilevyjen liittämisestä virtuaalikoneeseen. Virtuaaliohjaimia ei ole sidottu pohjana olevan tietosäilön käyttämään fyysiseen tallennusprotokollaan. Esimerkiksi oletusohjauskoneen nimi on SCSI, mutta se on täysin virtuaalinen eikä kuvasta tai rajoita alla käytettävää fyysistä tallennusvälinettä. Tämän abstraktion vuoksi sillä ei ole toiminnallista eroa, liitetäänkö VMDK virtuaalisen SCSI- vai NVMe-ohjaimen avulla riippumatta siitä, onko tallennusprotokolla SCSI vai NVMeoF. Käytännössä VMware suosittelee yleensä SCSI-ohjainten käyttöä tallennustyypistä riippumatta VMware Paravirtual (PVSCSI) -tyypistä, koska ne tarjoavat yleensä paremman vakauden ja paremman suorituskyvyn useimmille työkuormille. Voit kuitenkin halutessasi käyttää NVMe-ohjaimia. 

1. Oracle RAC: RDM:ien muuntaminen VMDK:iksi

Jotkin Oracle RAC -ympäristöt käyttävät RDM:iä jaetun tallennustilan tarjoamiseen datatiedostoille tai ASM-levyryhmille VMDK:iden sijaan. Nämä asetukset on mahdollista muuntaa verkossa, vaikka jotkut menetelmät vaativat seisokkeja. Katamme sekä RDM-pohjaisen että ASM: n.

1.1 RAC ilman ASM:ää

Jos Oracle Automatic Storage Management (ASM) ei ole käytössä, voit muuntaa sen verkossa jollakin seuraavista tavoista.

Vaihtoehto A — Datatiedostojen siirtäminen verkossa

1. Luo uusia jaettuja VMDK:ita:
• VMFS-tietosäilö NVMe/TCP:ssä (klusteroitu VMDK-ominaisuus EI PAKOLLINEN)
• Paksu varaus innokas nollattu (EZT)
• Usean kirjoittajan käyttö
2. VMDK:iden liittäminen kaikkiin RAC-solmuihin
3. Uusien datatiedostojen lisääminen VMDK:iden avulla.
4. Siirrä tiedot RDM-pohjaisista datatiedostoista VMDK-pohjaisiin datatiedostoihin.
5. Pudota alkuperäiset RDM-pohjaiset datatiedostot.
6. Siirrä klusteriohjelmia komennolla crsctl/ocrconfig.

Tämä lähestymistapa välttää seisokkeja, mutta saattaa edellyttää taulukkotilan tai objektitason tietojen siirtämistä, mikä voi olla aikaa vievää.

Vaihtoehto B - Muunna ASM: ksi (ensisijainen)

ASM:ään siirtyminen yksinkertaistaa pitkän aikavälin tallennuksen hallintaa, ja sitä suositellaan strategiseksi lopputilaksi.

Tuettuja lähestymistapoja on kaksi:

• Online-siirto ASM-levyryhmiin
• RMAN käyttäenBACKUP AS COPY DATABASE -TIETOKANTAA
• Vaatii lyhyen seisokin
• Nopeampi ja turvallisempi suurille tietokannoille
• Yleisesti suositeltava tuotantojärjestelmissä

1.2 ASM:ää jo käyttävä RAC

Jos ASM on käytössä, RDM:n vaihto on yksinkertaista ja verkossa:

1. Luo uusia jaettuja VMDK:ita:
• VMFS-tietosäilö NVMe/TCP:ssä (klusteroitu VMDK-ominaisuus EI PAKOLLINEN)
• Paksu varaus innokas nollattu
• Usean kirjoittajan käyttö
2. Lisää VMDK:t ASM-levyryhmään.
3. Anna ASM-tasapainotuksen valmistua.
4. Pudota RDM:ien tukemat ASM-levyt.
5. Siirrä klusteriohjelmia komennolla crsctl/ocrconfig.

Tämä prosessi ei vaadi sovellusten seisokkeja ja aiheuttaa minimaalisen riskin.

2. WSFC: RDM:ien muuntaminen VMDK:iksi

⚠️ Tärkeää: Suorita WSFC-siirto levy kerrallaan klusterin vakauden ylläpitämiseksi. Esimerkissä on kyse kaksisolmuisesta klusterista.

2.1 Edeltävä osaaminen (pakollinen)

VMware-vaatimukset

• VM-laitteistoversio tukee klusteroituja VMDK-tiedostoja
• VMFS-tietosäilö NVMe/TCP:ssä
• Klusteroitu VMDK-ominaisuus käytössä
• Paksu varaus Innokas nollatut levyt
• Ei tilannevedoksia klusterivirtuaalikoneissa
• Tallennustilan DRS poistettu käytöstä

WSFC-vaatimukset

• Klusteri kunnossa
• Klusterin vahvistus puhdas (varoitukset hyväksyttävät)
• Jokaisella levyllä on yksi omistava solmu

2.2 Luo uusia jaettuja VMDK:ita

Kunkin RDM-levyn osalta:

1. Uuden VMDK:n luominen NVMe/TCP-tietosäilöön (edellyttää klusteroitua VMDK:ta):
• Sama tai suurempi koko
• Paksu varaus innokas nollattu
2. Liitä VMDK molempiin klusterisolmuihin:
• Sama SCSI-ohjaintyyppi (suositus PVSCSI)
• Sama ohjainnumero
• Sama SCSI-tunnus
• SCSI:n fyysisen väylän jakamisen käyttöönotto

2.3 Levyn valmisteleminen (vain omistajasolmu)

Nykyisessä omistavassa solmussa:

1. Siirrä uusi levy online-tilaan.
2. Alusta nimellä GPT.
3. Alusta NTFS, jossa on 128 kt.
4. Määritä väliaikainen asemakirjain.

Jätä toissijaisen solmun levy offline-tilaan.

2.4 Tietojen siirtäminen (levykohtaisesti)

Esimerkki SQL Server -datalevystä:

1. SQL-roolin suorittaminen omistavaan solmuun epäonnistuu.
2. Pysäytä SQL-resurssit (SQL Server) käyttämällä vanhaa RDM: ää ja pidä levy online-tilassa.
3. Kopioi tiedot robokopiolla, jossa R on RDM ja V on uusi VMDK:
   1. robocopy R:\ V:\ /MIR /COPYALL /DCOPY:T /R:0 /W:0
4. Tarkista tietojen eheys.
5. Muuta aseman kirjaimia niin, että uudella levyllä on vanha kirjain.
6. Päivitä klusteriresurssien riippuvuudet viittaamaan uuteen levyyn.
7. Tuo resurssit verkkoon.
8. Siirrä omistajuus toiseen solmuun testattavaksi.
9. Kun olet valmis, poista riippuvuus vanhasta levystä (RDM).
10. Toista tämä jokaiselle datalevylle

Toista tämä prosessi:

• Lokilevyt
• Temp

2.5 Vaihda klusterilevyresurssi

Vahvistuksen jälkeen:

1. Irrota vanha RDM-levy klusteriroolista.
2. Lisää uusi VMDK-levy rooliin.
3. Vahvista omistajuus ja riippuvuudet.
4. Siirrä omistajuus toiseen solmuun testattavaksi.

2.6 Koorumin levyn siirto (jos käytössä)

Voit estää klusterin aiheuttamat häiriöt seuraavasti:

1. Vaihda tilapäisesti päätösvaltaiseksi solmuksi levyn sijaan.
   1. Set-ClusterQuorum -NodeMajority
2. Lisää uusi levy kohdan 2.3 mukaisesti.
3. Lisää levy klusteriin käyttöliittymässä tai Add-ClusterDisk PS: ssä.
4. Aseta uusi levy koorumiksi käyttöliittymässä tai Set-ClusterQuorum -DiskWitness "Cluster Disk X"
5. Offline-tilassa ja irrota RDM-levy.

3 Poista RDM:t

Vasta onnistuneen validoinnin jälkeen kummassakin käyttötapauksessa:

1. Poista RDM-yhdistämismääritykset molemmista virtuaalikoneista.
2. Irrota LUNit ESXi-isännistä.
3. Yhdistä asemat PowerFlex Managerissa.

4 Yleisiä ongelmia

1. EZT-levyjen käyttämättä jättäminen
   • Tässä käsitellyt klusteroidut ratkaisut vaativat EZT:n – ei tukea ohuille tai zeroedthick-paksuille
2. Ohjaimen kokoonpano ei täsmää. Mikä tahansa alla oleva ristiriita estää levyä toimimasta oikein klusterissa.
   • Sama SCSI-ohjaintyyppi
   • Sama ohjainnumero
   • Sama SCSI-tunnus
3. Usean kirjoittajan määritys Oracle EZT vmdk:ssa epäonnistui kussakin virtuaalikoneessa (solmussa) kullekin VMDK:lle
4. Fyysisen SCSI-väylän jakamisen käyttöönotto WSFC-ohjaimessa epäonnistui 

4.1 Kokoonpanon tuki

Lisädokumentaatiolinkit (ei erityisessä järjestyksessä):

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

https://learn.microsoft.com/sql/sql-server/failover-clusters/windows/change-failover-cluster-instance-storage

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