PowerStore Metro Volume sur Fibre Channel, partie 3 : réplication FC, Metro Witness en cloud, Metro Volumes et Dell VSI

---

Série « build » en trois parties :Préparation et designFabrics Connectrix DS-7720B, ISL et zoningRéplication FC, Metro Witness en cloud et Metro Volumes (cet article)

Une partie 4 optionnelle traitera vSphere Metro Storage Cluster (HA/DRS) et la recette.

Synthèse

Les fabrics et le zoning sont en place (partie 2), la règle NMP est déjà sur les ESXi (partie 1). Cette dernière partie rend le Metro opérationnel :

1. Remote System en Fibre Channel entre les deux baies ;
2. Metro Witness sur une VM Linux dans le cloud, avec certificat adapté au NAT ;
3. déclaration des 10 ESXi sur les deux baies en Co-located with both systems ;
4. Dell VSI 10.11 dans le vSphere Client ;
5. datastores VMFS en Metro, avec rôle preferred réparti entre les sites ;
6. contrôle des 16 chemins côté ESXi et lecture des scénarios de panne.

Chaque étape peut se faire dans PowerStore Manager. VSI ne remplace pas PowerStore Manager pour l'infrastructure (Remote System, hôtes, Witness), mais il simplifie le cycle de vie des datastores Metro depuis vCenter.

Comme dans les parties précédentes, les noms, adresses IP et WWPN sont fictifs.

---

1. Prérequis

Prérequis	Contrôle	Source
Zoning de réplication actif sur les deux fabrics (8 zones)	cfgactvshow	Partie 2
Ports IOM0 P0/P1 en Replication, Import	PowerStore Manager > Hardware > Ports > Fibre Channel	H18153
Management PS-NORD ↔ PS-SUD joignable	Ping / HTTPS entre 10.10.10.20 et 10.20.10.20	H18153 : l'orchestration passe par le management, même en FC
NTP identique sur les baies, les ESXi et le Witness	PowerStore Manager > Settings > NTP ; chronyc tracking	H19163
Règle SATP policy=latency sur les 10 ESXi, aucun volume PowerStore présenté	esxcli storage nmp satp rule list	Partie 1
PowerStoreOS 5.0.0.2 sur les deux baies	PowerStore Manager > Settings > Software	Partie 1
Compatibilité VSI 10.11 / vSphere 8 / PowerStoreOS 5.0	Dell Simple Support Matrix	Guide VSI 10.11

---

2. Remote System en Fibre Channel

2.1 Ce qu'il faut savoir avant de cliquer

Point	Conséquence
Une seule connexion Remote System entre deux clusters	Metro, synchrone et asynchrone partagent ce lien
Type TCP ou FC choisi à la création, non modifiable	Changer de type = supprimer le Remote System et toutes les sessions
Créé d'un côté, visible des deux côtés	Une seule création, depuis PS-NORD
Identifiants utilisés une seule fois	Ensuite, authentification par certificats SSL

2.2 Identifiants temporaires (recommandé)

Sur PS-SUD : Settings > Security > Authentication > Temporary Credentials, puis générer un Temporary ID / Secret. Ils expirent au bout de 10 minutes. Dell les recommande plutôt qu'un compte administrateur pour créer un Remote System (H18153).

2.3 Création

Sur PS-NORD : Protection > Remote Systems > Add.

Champ	Valeur
Management address	ps-sud-01.infra.acme.example (10.20.10.20)
Data connection type	Fibre Channel (définitif)
Authentification	Temporary ID / Secret généré sur PS-SUD
Certificat	Vérifier puis accepter le certificat SSL présenté par PS-SUD

2.4 Validation

Contrôle	Où	Attendu
Remote System	Protection > Remote Systems (sur les deux baies)	Management et data connection OK, type Fibre Channel
Capacités	Colonne Capability	Metro présent
Conformité des chemins	Monitoring > Alerts	Aucune alerte de chemin de réplication manquant
Après toute modification du zoning	More Actions > Verify and Update	Connexion revérifiée et mise à jour

Si une alerte de chemins manquants apparaît, revenir à la partie 2 : chaque port IOM0 P0/P1 doit être zoné vers un port par nœud de la baie distante. Ne pas créer de Metro Volume tant que l'alerte est active.

---

3. Metro Witness dans le cloud

3.1 Fonctionnement

Élément	Comportement (H19163)
Rôle	Arbitre en cas de rupture entre les baies. Il ne voit jamais d'I/O hôte
Flux	Baie → Witness uniquement, en HTTPS (TCP 443) via le réseau de management. Le Witness n'initie aucune connexion
Keep-alive	Chaque appliance interroge régulièrement le Witness (HTTP GET)
Session	Renouvelée une fois par jour par la baie preferred ; expire après 7 jours sans renouvellement
Décision	En cas de rupture, chaque baie demande la fracture. Le non-preferred envoie sa demande avec un délai : la première demande reçue gagne
Portée	Un seul Witness par cluster, appliqué à toutes les sessions Metro (y compris celles qui existaient avant son enregistrement)
Sauvegarde	Inutile : le Witness ne contient rien d'irremplaçable. Il se réinstalle et se réenregistre (guide VSI 10.11)

3.2 VM cloud

Paramètre	Valeur
FQDN	wit-01.cloud.acme.example
IP publique / privée	203.0.113.10 / 172.16.50.10
OS	Linux listé dans la PowerStore Simple Support Matrix (ici RHEL 9, sous réserve de la matrice)
Règles entrantes	TCP 443 depuis 198.51.100.10 (sortie DC-NORD) et 198.51.100.20 (sortie DC-SUD) ; TCP 22 depuis le bastion d'administration uniquement
Heure	NTP synchronisé, obligatoire
Indépendance	Chaque site sort par son propre accès Internet (voir §8)

3.3 Installation

# Linux supporté (ex. RHEL 9) — VM Witness, en root
# Pare-feu local : HTTPS autorisé (préférable à la désactivation du pare-feu)
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

# Heure
systemctl enable --now chronyd
chronyc tracking

# Paquet Dell (dnf résout les dépendances Java/SQLite)
dnf install ./dell-witness-service-<version>.noarch.rpm
systemctl status dell-witness-service

3.4 Certificat : le point qui bloque en cloud

Le certificat est généré à l'installation avec le nom d'hôte et l'IP principale de la VM. En cloud, cette IP principale est l'IP privée (172.16.50.10). Or les baies joignent le Witness par l'IP publique ou le FQDN : l'enregistrement échoue si ce nom n'est pas dans le Subject Alternative Name du certificat.

# Contrôle du SAN actuel
echo "" | openssl s_client -connect wit-01.cloud.acme.example:443 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

# Régénération avec l'IP publique, l'IP privée et le FQDN (script fourni par le RPM)
/opt/dell-witness-service/scripts/replace_certificate.sh -i "203.0.113.10 172.16.50.10" -f "wit-01.cloud.acme.example"

# Nouveau contrôle : les 3 entrées doivent apparaître
echo "" | openssl s_client -connect wit-01.cloud.acme.example:443 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

3.5 Enregistrement sur les deux baies

# Sur le Witness : jeton valable 10 minutes, utilisable pour PS-NORD et PS-SUD
/opt/dell-witness-service/scripts/generate_token.sh
# Empreinte du certificat, à comparer avec celle affichée par PowerStore Manager
/opt/dell-witness-service/scripts/thumbprint.sh

Sur PS-NORD puis sur PS-SUD, dans le délai de 10 minutes :

• dans PowerStore Manager : Protection > Metro Witness > Add ; indiquer le nom, le FQDN (présent dans le SAN) et le jeton, puis valider l'empreinte ;
• ou dans VSI : Menu > Dell VSI > Storage Systems > baie > onglet Metro Witness > +. Il faut être propriétaire de la baie dans VSI.

État Witness (cluster)	Signification
OK	Tous les nœuds joignent le Witness
Partially Connected	Une partie des nœuds seulement, ou Witness non enregistré sur le pair
Disconnected	Aucun nœud ne joint le Witness

Mise à jour du Witness : rpm -e dell-witness-service, installation du nouveau paquet, désenregistrement sur chaque baie, nouveau jeton, réenregistrement. Après une mise à jour de l'OS ou de Java : systemctl restart dell-witness-service.

---

4. Déclaration des hôtes

4.1 Modèle retenu

Objet	PS-NORD	PS-SUD
Hôtes	esx-n01 … esx-n05, esx-s01 … esx-s05	Identique
Initiateurs	2 WWPN par hôte (HBA0 + HBA1)	Identique
Host group	HG-ESX-METRO (10 hôtes)	HG-ESX-METRO (10 hôtes)
Connectivité Metro	Co-located with both systems	Co-located with both systems

Avec both, tous les hôtes ont la même connectivité sur les deux baies : un seul host group par baie suffit. Le choix et ses conséquences sont détaillés en partie 1, §7.

4.2 PowerStore Manager

Compute > Hosts & Host Groups > Add Host, sur chaque baie :

1. Nom de l'hôte, OS ESXi, protocole Fibre Channel ;
2. Initiateurs : les deux WWPN détectés de l'hôte. S'ils n'apparaissent pas, revoir le zoning (partie 2, §6.5) ;
3. Connectivité hôte : Co-located with both systems ;
4. Puis Add Host Group HG-ESX-METRO avec les 10 hôtes.

Les libellés exacts de la connectivité peuvent varier selon la version de PowerStore Manager. Après création, contrôler dans les propriétés de chaque hôte, sur les deux baies, que both est bien appliqué.

4.3 Alternative avec VSI

VSI sait ajouter les hôtes (Dell VSI > Storage Systems > baie > onglet Hosts > +, protocole FC) et modifier leur connectivité (More Actions > Modify Host Connectivity). En mode Metro, VSI déduit le type de connectivité des baies sélectionnées (Select System(s)). Sélectionner les deux baies pour obtenir both, puis vérifier le résultat dans PowerStore Manager.

Je préfère créer les hôtes et les host groups dans PowerStore Manager : le host group et la connectivité restent sous contrôle explicite, et VSI prend la suite pour les datastores.

---

5. Dell VSI 10.11

5.1 Ce que VSI apporte dans ce design

Fonction VSI	Intérêt pour le Metro
Création de datastore VMFS (volume + mapping + VMFS en un assistant)	Moins d'allers-retours entre PowerStore Manager et vCenter
Configure Metro sur un datastore existant	Passage en Metro depuis vCenter
Onglet Metro du datastore	État de session, rôle preferred, état du Witness, pause / reprise
Modify Preferred Role	Bascule du rôle avant une maintenance, sans quitter vCenter
Extension d'un datastore Metro	VSI met la session en pause, étend, puis la reprend automatiquement
Métriques de réplication synchrone	Mirror Overhead Write Latency, Mirror Write IOPS, Mirror Bandwidth : le coût réel du Metro
Host Best Practices	Contrôle des paramètres ESXi (à manier avec prudence, §5.4)

5.2 Déploiement

Étape	Détail
OVA	Déployée depuis le vSphere Client (Deploy OVF Template) : IP, masque, passerelle, DNS, NTP
Initial Setup	Navigateur vers l'IP de la VM : import des certificats vCenter, mot de passe Redis/base, enregistrement de vCenter (compte administrateur)
Mot de passe root	À changer au premier démarrage (avertissement affiché)
Comptes vCenter supportés	vsphere.local et Active Directory ; pas localos
Placement	Hors des datastores Metro et hors du cluster qu'il supervise si possible : l'outil de pilotage ne doit pas tomber avec ce qu'il pilote

Flux à ouvrir (guide VSI 10.11, tableau des ports par défaut) :

Source	Destination	Port
Plug-in VSI (vSphere Client)	VM VSI (IAPI)	443
VM VSI	vCenter	443
VM VSI	DNS	53 (+ ICMP pour le contrôle de santé DNS)
VM VSI	PowerStore (management)	443, à confirmer : le tableau du guide 10.11 ne liste pas de ligne PowerStore

5.3 Enregistrement des baies

Menu > Dell VSI > Storage Systems > + :

• enregistrer PS-NORD et PS-SUD. VSI exige que la baie distante soit enregistrée pour configurer un Metro ;
• Storage Access : donner l'accès aux groupes d'administration vCenter concernés ;
• VASA Provider : facultatif (utile seulement pour des vVols, hors périmètre ici) ;
• Hosts : passer cette étape si les hôtes sont déjà créés dans PowerStore Manager (§4.2).

Celui qui enregistre la baie en devient propriétaire dans VSI. Certaines actions lui sont réservées (Witness, Host Best Practices) : utiliser un compte d'équipe plutôt qu'un compte nominatif.

5.4 Host Best Practices : attention au profil NMP

VSI compare les paramètres des ESXi à ses valeurs recommandées et peut les appliquer (Configure > Dell VSI > Host Best Practices, ou au niveau du cluster).

• Le guide VSI 10.11 ne détaille pas la liste des paramètres PowerStore contrôlés. Avant d'appliquer, lire la liste affichée et décocher tout paramètre qui remettrait le Round Robin en iops=1 à la place du policy=latency posé en partie 1.
• Appliquer hôte par hôte ou sur des groupes de 10 hôtes maximum : le guide signale que certaines tâches ne se terminent pas au-delà de 10 hôtes.
• Réservé à l'utilisateur qui a enregistré vCenter dans VSI.
• Après application, recontrôler la règle SATP et la configuration RR d'un device de test (§7).

---

6. Datastores Metro

6.1 Règles de répartition

Règle	Justification
Rôle preferred du côté où tournent les VM du datastore	En fracture, seul le preferred (ou le gagnant du Witness) reste en ligne
Datastores DS-NORD-xx preferred PS-NORD, DS-SUD-xx preferred PS-SUD	Charge et risque répartis sur les deux sites
VMDK d'une même application sur le même datastore, ou dans un volume group Metro avec cohérence d'écriture	Rôle et état communs, pas de split entre les disques d'une application
Mêmes politiques QoS des deux côtés	La QoS n'est pas répliquée
Pas de renommage d'un datastore en Metro actif via VSI	Bloqué par VSI tant que la session n'est pas en pause ou terminée

Le preferred initial est la baie sur laquelle le Metro est configuré. Créer DS-NORD-* depuis PS-NORD et DS-SUD-* depuis PS-SUD, ou utiliser Modify Preferred Role ensuite (possible uniquement en Active-Active, sans impact I/O).

6.2 Avec VSI

1. Création du VMFS : clic droit sur le cluster > Dell VSI > Create Datastore > VMFS. Choisir PS-NORD pour un DS-NORD-xx, protocole FC, les 10 hôtes, puis la capacité et les politiques (performance, QoS, protection).
2. Passage en Metro : Storage > datastore > Configure > Dell VSI > Configure Storage > carte Protection > Configure Metro. Choisir PS-SUD comme Remote System.
3. Mapping distant : par défaut, VSI mappe automatiquement les hôtes sur le volume distant. Activer View host mappings pour vérifier les hôtes proposés avant de valider, ou cocher Do not perform the host mapping operation et mapper ensuite (Host Mappings > Map Hosts > baie Metro).
4. Rescan des hôtes (VSI le signale : le datastore n'apparaît sur tous les membres d'un host group qu'après un rescan).

6.3 Avec PowerStore Manager

1. Storage > Volumes > Create sur la baie preferred, mapping au host group HG-ESX-METRO.
2. Volume > Protect > Configure Metro Volume > Remote System PS-SUD (FC).
3. Sur la baie distante, mapper le volume Metro au host group HG-ESX-METRO. Le mapping est possible pendant la synchronisation initiale ; l'I/O côté distant n'est autorisée qu'en Active-Active.
4. Rescan ESXi, puis création du VMFS depuis vCenter.

6.4 Synchronisation et états

La synchronisation initiale démarre en asynchrone (snapshots), passe en différentiel, puis bascule en Operating Normally (Active-Active). Un snapshot interne sert ensuite de base commune pour les resynchronisations.

État de session	Accès hôte
Operating Normally (Active-Active)	Les deux baies
Synchronizing / Switching to Active-Active	Preferred (ou promoted) uniquement
Fractured	Preferred, ou gagnant du Witness, uniquement
Paused	Preferred uniquement ; non-preferred hors ligne pour les hôtes

État Witness (session)	Signification
Engaged	Nominal : le Witness arbitrera
Disengaged	Witness non utilisé : normal pendant une fracture, anomalie sinon
Disengaged Invalid Configuration	Witness mal configuré côté preferred
Disengaged Failed To Initialize	Échec d'initialisation

Côté VSI, l'onglet Metro du datastore affiche l'état de session et du Witness.

---

7. Contrôles ESXi

7.1 Par device

# ESXi 8 — esxcli
esxcli storage core adapter rescan --all        # ⚠ charge transitoire : un hôte à la fois en production

esxcli storage nmp device list -d naa.68ccf09800aaaaaaaaaaaaaaaaaaaaaa
#   Storage Array Type: VMW_SATP_ALUA
#   Path Selection Policy: VMW_PSP_RR
#   Path Selection Policy Device Config: {policy=latency,...}

esxcli storage nmp path list -d naa.68ccf09800aaaaaaaaaaaaaaaaaaaaaa | grep -c "Group State: active$"
esxcli storage nmp path list -d naa.68ccf09800aaaaaaaaaaaaaaaaaaaaaa | grep -c "Group State: active unoptimized"

Contrôle	Attendu (nominal, both)
SATP / PSP	VMW_SATP_ALUA / VMW_PSP_RR
Configuration RR	policy=latency
Chemins	16
active (AO)	8 : nœud d'affinité des deux baies
active unoptimized	8
Device en iops=1	Device réclamé avant la règle : esxcli storage nmp psp roundrobin deviceconfig set -d <naa> -t latency

7.2 Sur tout le cluster

Répéter le contrôle sur les 10 ESXi et pour chaque datastore Metro. Tout device qui n'a pas 16 chemins, 8 AO, ou dont la configuration RR ne contient pas latency, signale un écart de zoning, de mapping ou de connectivité.

---

8. Scénarios de panne

8.1 Lecture dans ce design

Événement	Chemins vus d'un ESXi DC-NORD	Effet Metro
Nominal	16 (8 AO)	Active-Active
Perte ISL A	12	Active-Active via le fabric B ; gel du zoning sur le fabric A
Perte ISL A + B	8 (locaux)	Fracture : chaque datastore reste en ligne côté preferred (arbitrage Witness)
Perte de la baie PS-NORD	8 vers PS-SUD (via ISL)	PS-SUD gagne l'arbitrage, tous les datastores restent en ligne
Perte du Witness seul	16	Aucun impact I/O, Witness Disconnected, alerte

8.2 Matrice Dell avec Witness (H19163)

Preferred	Non-preferred	Lien réplication	Lien preferred → Witness	Lien non-preferred → Witness	Witness	Résultat
OK	OK	OK	OK	OK	OK	En ligne des deux côtés
✗	OK	OK	OK	OK	OK	En ligne sur le non-preferred
✗	OK	OK	OK	✗	OK	Hors ligne des deux côtés
OK	✗	OK	OK	OK	OK	En ligne sur le preferred
OK	✗	OK	✗	OK	OK	Hors ligne des deux côtés
OK	✗	OK	OK	OK	✗	Hors ligne des deux côtés
OK	OK	✗	OK	OK	OK	En ligne sur le preferred
OK	OK	✗	OK	✗	OK	En ligne sur le preferred
OK	OK	✗	✗	✗	OK	Hors ligne des deux côtés
OK	OK	✗	✗	OK	OK	Dépend de l'ordre des pannes

Conséquence directe pour un Witness en cloud : la perte d'une baie combinée à la perte de l'accès Internet de la baie survivante met tous les volumes hors ligne. Si DC-SUD sort sur Internet par DC-NORD, perdre DC-NORD revient à cumuler les deux pannes. D'où la règle : une sortie Internet indépendante par site, vérifiée par traceroute depuis chaque réseau de management.

8.3 Opérations manuelles

Opération	Disponible en	Risque
Pause	Quasi tous états	Non-preferred hors ligne pour les hôtes
Resume	Paused	Resynchronisation depuis le preferred (passage par Fractured, puis Active-Active)
Modify Preferred Role	Active-Active uniquement	Aucun pour l'I/O
Promote	Paused, Fractured	⚠ Split-brain si l'autre baie sert encore de l'I/O : vérifier qu'elle est réellement arrêtée
Demote	Paused, côté preferred	Coupe l'I/O du preferred : préalable à un promote planifié

8.4 Cas connu en 5.0.0.2

Release notes PowerStoreOS 5.0.0.2 : après un unplanned failover suivi d'un reprotect, certaines sessions Metro bloc peuvent rester en System Paused. Contournement documenté : promote de la ressource Metro du côté qui détient les données de production les plus récentes, puis la session s'auto-répare. À intégrer à la procédure de retour à la normale, avant le premier test de bascule.

---

9. Exploitation

Sujet	Règle
Supervision	État de session ≠ Active-Active, Witness ≠ Engaged ou ≠ OK, alertes PowerStore, erreurs ISL (MAPS)
Coût du Metro	Métriques VSI Mirror Overhead Write Latency et Mirror Write IOPS par datastore
Maintenance d'un site	Modify Preferred Role des datastores concernés vers l'autre baie, vMotion des VM, puis intervention
NDU PowerStoreOS	Pre-Upgrade Health Check (VSI recommande de le lancer une semaine avant), une baie à la fois ; les sessions Metro actives continuent pendant la NDU
Extension de datastore	Via VSI : pause, extension, reprise automatiques. Pas de réduction possible
Witness	Mise à jour OS/Java : redémarrage du service ; pas de sauvegarde nécessaire
Zoning	Jamais pendant une segmentation d'ISL (partie 2) ; Verify and Update sur le Remote System après modification

---

Vérification (fin de build)

Contrôle	Attendu
Remote System	OK des deux côtés, type FC, aucune alerte de chemin
Witness	OK sur PS-NORD et PS-SUD ; SAN du certificat avec IP publique et FQDN
Hôtes	10 hôtes, 2 initiateurs chacun, Co-located with both systems sur les deux baies
VSI	2 baies enregistrées Connected ; Witness visible dans l'onglet Metro Witness
Sessions Metro	Active-Active, Witness Engaged, rôles conformes à la répartition
ESXi	16 chemins, 8 AO / 8 AN, policy=latency sur tous les devices PowerStore
Sorties Internet	Indépendantes par site (traceroute)

Risques / points d'attention

• Un Remote System créé en TCP par erreur n'est pas modifiable : tout est à refaire.
• Sans IP publique ni FQDN dans le certificat du Witness, les baies ne peuvent pas l'enregistrer.
• Avec une sortie Internet partagée entre sites, la perte d'un site met tous les volumes hors ligne.
• Des Host Best Practices VSI appliquées sans relecture peuvent ramener le Round Robin en iops=1.
• Un mapping automatique VSI non vérifié peut laisser des hôtes sans accès côté distant, avec des chemins incomplets.
• Un promote sur une baie encore active provoque un split-brain et une perte de données à la resynchronisation.
• Si VSI est hébergé sur un datastore Metro, l'outil de pilotage tombe avec la plateforme qu'il pilote.

Sources

• Dell PowerStore: Replication Technologies (H18153) : Remote System FC, identifiants temporaires, Verify and Update
• Dell PowerStore: Metro Volume (H19163) : Witness, états, matrice de pannes, connectivité hôte
• Dell PowerStore: VMware vSphere Best Practices (H18116)
• Dell Virtual Storage Integrator for VMware vSphere Client 10.11, Product Guide (février 2026)
• PowerStoreOS 5.0.0.x Patch Release Notes (Dell KB 000489647)

Fin de la série build. Partie 4 (optionnelle) : vSphere Metro Storage Cluster (HA, APD/PDL, groupes DRS par site) et recette.