PowerFlex : Conversion SDC en NVMe/TCP pour les applications en cluster utilisant des RDM sur vSphere
Résumé: Cet article de la base de connaissances explique comment effectuer la conversion WSFC à un haut niveau. Il couvre également la conversion d’un environnement Oracle RAC de RDM en VMDK partagés sur NVMe/TCP, même si Oracle RAC ne nécessite pas SCSI3-PR. Oracle RAC peut s’exécuter sur un datastore VMFS basé sur un SDC, mais comme PowerFlex ne prend pas en charge les VMDK en cluster sur un VMFS basé sur un SDC, les applications dépendantes de SCSI3-PR ne peuvent pas utiliser cette configuration. Les explications d’Oracle RAC sont également de haut niveau. ...
Instructions
Depuis l’introduction de VMDK en cluster sur les datastores VMFS, les applications telles que Windows Server Failover Cluster (WSFC) ne nécessitent plus de mappages de périphériques bruts (RDM) pour utiliser les réservations persistantes SCSI-3 (SCSI3-PR). Pour cette raison, Broadcom n’offre pas de prise en charge RDM pour le protocole NVMeoF. Les clients qui utilisent des RDM avec le SDC et qui souhaitent passer à NVMe/TCP doivent convertir ces disques en disques VMDK sur un datastore VMFS avec la propriété Clustered VMDK. Cette conversion ne peut pas être effectuée avec Storage vMotion, de sorte que les applications telles que WSFC subiront des interruptions de service.
Cet article de la base de connaissances s’applique aux personnes suivantes :
- Clients passant de SDC à NVMe/TCP sur les systèmes PowerFlex 5.0
- Environnements VMware vSphere 8.0U3 et 9.x utilisant des RDM avec un multi-writer ou un contrôleur de bus SCSI physique partagé pour disques
- Clusters Oracle RAC
- Clustering de basculement Windows Server, notamment :
- Clusters de basculement SQL Server
- Clusters de serveurs de fichiers
- Disques du quorum de clusters
Support :
Dell prend en charge les versions suivantes pour ces procédures lors de l’utilisation de VMDK en cluster :
- ESXi versions 8.0U3 et 9.x
- Ces versions prennent en charge NVMe/TCP Clustered VMDK sur PowerFlex 5.0
- PowerFlex 5.0
- PowerFlex 4.x n’est pas pris en charge
Lors de la conversion d’Oracle RAC, si vous n’utilisez pas de VMDK en cluster, PowerFlex 4.x est pris en charge.
Bien que cet article de la base de connaissances se concentre sur les applications en cluster, vous pouvez convertir des machines virtuelles autonomes avec RDM en VMDK en utilisant des procédures similaires, en particulier dans le cas d’Oracle avec ASM. Si vous utilisez des RDM parce que vous avez besoin de périphériques de transfert direct, la conversion en VMDK n’est pas une solution appropriée.
Présentation
Cet article décrit les meilleures pratiques prises en charge pour la conversion de clusters d’applications SDC et RDM existants en VMDK partagés sur des datastores NVMe/TCP. Les méthodes de conversion diffèrent en fonction des exigences de l’application. Planifiez en conséquence. Dell s’attend à ce que l’utilisateur de cet article de la base de connaissances maîtrise les technologies couvertes ; Par conséquent, les étapes sont de haut niveau et incluent rarement la syntaxe.
Les deux principaux cas d’utilisation de RDM sont couverts ici :
- Oracle RAC utilisant des RDM physiques avec multi-writer
- Windows Server Failover Clustering (WSFC) à l’aide de RDM physiques pour SCSI3-PR
Il existe un concept important concernant le contrôleur de stockage virtuel dans les machines virtuelles VMware, qu’il est essentiel de comprendre avant de continuer. Ces contrôleurs sont responsables de la connexion des disques virtuels à la machine virtuelle. Les contrôleurs virtuels ne sont pas liés au protocole de stockage physique utilisé par le datastore sous-jacent. Par exemple, bien que le contrôleur par défaut soit étiqueté « SCSI », il est entièrement virtuel et ne reflète ni ne restreint pas le transport de stockage physique utilisé en dessous. En raison de cette abstraction, il n’y a aucune différence fonctionnelle si vous attachez un VMDK à l’aide d’un contrôleur SCSI ou NVMe virtuel, que le protocole de stockage soit SCSI ou NVMeoF. En pratique, VMware recommande généralement d’utiliser des contrôleurs SCSI, quel que soit le type de stockage VMware Paravirtual (PVSCSI), car ils ont tendance à offrir une plus grande stabilité et des performances améliorées pour la plupart des charges applicatives. Toutefois, vous pouvez utiliser des contrôleurs NVMe si vous préférez.
1. Oracle RAC : Conversion de RDM en VMDK
Certains environnements Oracle RAC utilisent des RDM plutôt que des VMDK pour fournir un stockage partagé pour les fichiers de données ou les groupes de disques ASM. Il est possible de convertir ces configurations en ligne, bien que certaines méthodes nécessitent des temps d’arrêt. Nous couvrons à la fois les modèles basés sur RDM et ASM.
1.1 RAC sans ASM
Si Oracle Automatic Storage Management (ASM) n’est pas utilisé, vous pouvez effectuer une conversion en ligne à l’aide de l’une des méthodes suivantes.
Option A : Migration de fichiers de données en ligne
- Créez de nouveaux VMDK partagés :
- Datastore VMFS sur NVMe/TCP (propriété VMDK en cluster NON requise)
- Thick Provision Eager Zeroed (EZT)
- Multi-writer activé
- Rattachez des VMDK à tous les nœuds RAC.
- Ajoutez de nouveaux fichiers de données à l’aide des VMDK.
- Migrez les données des fichiers de données RDM vers les fichiers de données basés sur VMDK.
- Supprimez les fichiers de données RDM d’origine.
- Utilisez crsctl/ocrconfig pour déplacer le clusterware.
Cette approche permet d’éviter les interruptions de service, mais peut nécessiter le déplacement des données au niveau du tablespace ou au niveau de l’objet, ce qui peut prendre beaucoup de temps.
Option B : Convertir en ASM (de préférence)
La conversion en ASM simplifie la gestion du stockage à long terme et constitue l’état final stratégique recommandé.
Il existe deux approches prises en charge :
- Migration en ligne vers des groupes de disques ASM
- RMAN à l’aidede BACKUP AS COPY DATABASE
- Nécessite une courte interruption de service
- Plus rapide et plus sûr pour les bases de données volumineuses
- Généralement préféré pour les systèmes de production
1.2 RAC utilise déjà ASM
Si ASM est en cours d’utilisation, le remplacement du RDM est simple et en ligne :
- Créez de nouveaux VMDK partagés :
- Datastore VMFS sur NVMe/TCP (propriété VMDK en cluster NON requise)
- Thick Provision Eager Zeroed
- Multi-writer activé
- Ajoutez les disques VMDK au groupe de disques ASM.
- Laissez le rééquilibrage ASM se terminer.
- Supprimez les disques ASM sauvegardés par des RDM.
- Utilisez crsctl/ocrconfig pour déplacer le clusterware.
Ce processus ne nécessite aucune interruption de service des applications et présente un risque minime.
2. WSFC : Conversion de RDM en VMDK
⚠️ Important : Effectuez la migration WSFC un disque à la fois pour maintenir la stabilité du cluster. Cet exemple est un cluster à deux nœuds.
2.1 Prérequis (obligatoires)
Exigences VMware
- La version matérielle de la machine virtuelle prend en charge les disques VMDK en cluster
- Datastore VMFS sur NVMe/TCP
- Fonctionnalité VMDK en cluster activée
- Thick Provision Eager Zeroed Disks
- Aucun snapshot sur les machines virtuelles de cluster
- DRS de stockage désactivé
Configuration requise pour WSFC
- Cluster intègre
- Validation du cluster propre (avertissements acceptables)
- Chaque disque dispose d’un seul nœud propriétaire
2.2 Créer de nouveaux VMDK partagés
Pour chaque disque RDM :
- Créez un nouveau VMDK sur un datastore NVMe/TCP (VMDK en cluster requis) :
- Taille identique ou supérieure
- Thick Provision Eager Zeroed
- Rattachez le VMDK aux deux nœuds du cluster :
- Même type de contrôleur SCSI (PVSCSI recommandé)
- Même numéro de contrôleur
- Même ID SCSI
- Activer le partage de bus physique SCSI
2.3 Préparer le disque (nœud propriétaire uniquement)
Sur le nœud propriétaire actuel :
- Mettez le nouveau disque en ligne.
- Initialiser en tant que GPT.
- Formatez NTFS avec 128 Ko.
- Attribuez une lettre de lecteur temporaire.
Sur le nœud secondaire, laissez le disque hors ligne.
2.4 Migration des données (disque par disque)
Exemple pour un disque de données SQL Server :
- Basculez le rôle SQL sur le nœud propriétaire.
- Arrêtez les ressources SQL (SQL Server) à l’aide de l’ancien RDM et conservez le disque en ligne.
- Copiez les données à l’aide de robocopy où R est le RDM et V le nouveau VMDK :
- robocopy R :\ C:\ /MIR /COPYALL /DCOPY :T /R :0 /W :0
- Vérifiez l’intégrité des données.
- Modifiez les lettres de lecteur pour que le nouveau disque ait l’ancienne lettre.
- Mettez à jour les dépendances des ressources du cluster pour référencer le nouveau disque.
- Mettez des ressources en ligne.
- Déplacez la propriété vers un autre nœud pour le tester.
- Une fois l’opération terminée, supprimez la dépendance à l’ancien disque (RDM).
- Répétez l’opération pour chaque disque de données
Répétez cette procédure pour :
- Disques de log
- Temp
2.5 Remplacer la ressource disque du cluster
Après validation :
- Supprimez l’ancien disque RDM du rôle de cluster.
- Ajoutez le nouveau disque VMDK au rôle.
- Confirmez la propriété et les dépendances.
- Déplacez la propriété vers un autre nœud pour le tester.
2.6 Migration des disques quorum (le cas échéant)
Pour éviter les pannes accidentelles du cluster :
- Basculez temporairement le quorum sur la majorité des nœuds plutôt que sur le disque.
- Set-ClusterQuorum -NodeMajority
- Suivez la section 2.3 pour ajouter un nouveau disque.
- Ajoutez le disque au cluster dans l’interface utilisateur ou Add-ClusterDisk dans PS.
- Définissez le nouveau disque comme quorum dans l’interface utilisateur ou Set-ClusterQuorum -DiskWitness « Cluster Disk X »
- Mettez hors ligne et retirez le disque RDM.
3 Supprimer les RDM
Uniquement après validation réussie dans l’un ou l’autre cas d’utilisation :
- Supprimez les mappages RDM des deux machines virtuelles.
- Détachez les LUN des hôtes ESXi.
- Umap des volumes dans PowerFlex Manager.
4 Problèmes courants
- Défaut d’utilisation des disques EZT
- Les solutions en cluster abordées ici nécessitent EZT : aucune prise en charge de thin ou zeroedthick
- Configuration de contrôleur incompatible. Toute incompatibilité ci-dessous empêche le disque de fonctionner correctement dans le cluster.
- Le même type de contrôleur SCSI
- Le même numéro de contrôleur
- Le même ID SCSI
- Échec de la définition de multi-writer sur Oracle EZT vmdks sur chaque machine virtuelle (nœud) pour chaque VMDK
- Échec de la définition du partage de bus physique SCSI sur le contrôleur pour WSFC
4.1 Prise en charge de la configuration
|
Configuration |
Support |
Remarques |
|
VMDK partagés (multi-writers) sur VMFS |
✅ Soutenu |
État final recommandé pour Oracle RAC |
|
Thick Provision Eager Zeroed (EZT) |
✅ Soutenu |
Obligatoire pour les disques en cluster |
|
Contrôleur PVSCSI avec partage de bus physique SCSI |
✅ Soutenu |
Requis pour WSFC sur les disques VMDK en cluster |
|
RDM physiques avec partage de bus physique SCSI |
✅ Pris en charge (hérité) |
N’est plus recommandé |
|
RDM physiques avec NVMe/TCP |
❌ Non pris en charge |
Indisponible |
|
VMDK avec allocation dynamique ou mise à zéro différée |
❌ Non pris en charge |
Instabilité du disque du cluster |
|
Snapshots sur les machines virtuelles de cluster |
❌ Non pris en charge |
Retirer |
|
DRS de stockage sur les machines virtuelles en cluster |
❌ Non pris en charge |
Désactiver pour les charges applicatives de cluster |
|
Combinaison de RDM et de VMDK (temporairement) |
✅ Soutenu |
Lors de la migration uniquement |
|
Stockage vMotion des disques VMDK partagés |
❌ Non pris en charge |
Bien qu’il soit rattaché à plusieurs machines virtuelles |
Informations supplémentaires
Liens supplémentaires vers la documentation (sans ordre particulier) :
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://www.vmware.com/docs/vmw-vmdk-whitepaper-mmt
https://learn.microsoft.com/windows-server/administration/windows-commands/robocopy