PowerStore Metro Volume sur Fibre Channel — Partie 1 : préparation et design

Julien HOKINI · 25 octobre 2026 · 14 min de lecture

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

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

Synthèse

Cet article est un retour d'expérience, pas un lab : la plateforme décrite a été déployée et éprouvée en conditions réelles. Deux PowerStore 1200T, un par site, à 10 km l'un de l'autre, portent des Metro Volumes actifs/actifs pour un cluster vSphere étendu de 10 ESXi. La réplication synchrone passe en Fibre Channel, par les mêmes fabrics que les accès hôtes. Le Metro Witness est hébergé dans le cloud.

Cet article fixe le design avant toute configuration :

versions et prérequis ;
fonctionnement de la baie ;
plan de ports et nombre de chemins ;
mode de connectivité Metro ;
nommage et adressage ;
préparation des ESXi (profil NMP), qui doit précéder la présentation du premier volume.

1. Périmètre

Élément	Choix
Baies	2 × PowerStore 1200T, un cluster mono-appliance par site
Version	PowerStoreOS 5.0.0.2 sur les deux clusters
I/O modules	2 modules FC 32G par nœud (IOM0, IOM1), 2 ports câblés par module
Switches	4 × Connectrix DS-7720B (OEM Brocade G720), FOS 9.2.2c
Fabrics	A et B indépendants, un switch par site et par fabric
Inter-site	1 ISL de 10 km par fabric, fibre noire, mode LE
Hôtes	10 × ESXi 8 (5 par site), HBA FC 2 ports (1 par fabric)
Accès hôtes	Uniforme, Co-located with both systems
Chemins	16 par Metro Volume et par ESXi
Witness	VM Linux dans le cloud, joignable par chaque site via sa propre sortie Internet

Hors périmètre : protocole NVMe, Metro fichier, HA/DRS vMSC (partie 4).

2. Versions

2.1 Historique utile de Metro Volume

Version	Apport
3.0	Metro Volume pour VMFS (ESXi), réplication sur TCP
3.6	Metro Witness
4.0	Metro Volume Groups, support Windows et Linux
4.2	Réplication asynchrone bloc sur FC
4.3	Réplication synchrone bloc sur FC
4.4	Metro Volume sur FC
5.0	Version de référence de la série

Source : Dell PowerStore: Replication Technologies (H18153).

2.2 Pourquoi 5.0.0.2

Patch	Point notable
5.0.0.0 / 5.0.0.1	Publiés en juillet 2026
5.0.0.1	Ne pas installer si la réplication Metro fichier est utilisée ou prévue
5.0.0.2	Publié en août 2026, corrige le point précédent. Documente un cas connu : après un unplanned failover puis un reprotect, certaines sessions Metro bloc peuvent rester en System Paused. Contournement : promote de la ressource Metro du côté qui détient les données de production les plus récentes, puis auto-réparation de la session

Le cas System Paused est traité dans la procédure de reprise de la partie 3. Toujours relire les release notes du patch le plus récent avant le build.

3. Matrice de prérequis

Exigence	Valeur retenue	Source / contrôle
PowerStoreOS	5.0.0.2 sur les deux clusters, même version	Release notes
Version minimale Metro FC	4.4	H18153
Modèle	T ou Q, même modèle des deux côtés recommandé	H18241 : en bascule, une baie absorbe tout
RTT inter-site	≤ 5 ms (ici : environ 0,1 ms)	H19163
Distance	≤ 100 km (ici : 10 km)	H19163
Protocole hôte Metro	FC ou iSCSI en SCSI, VMFS	H19163
Switches	DS-7720B, FOS 9.2.2c	À valider dans E-Lab avec PowerStoreOS 5.0.0.2
ESXi	vSphere 8.0 Ux	E-Lab + PowerStore Host Configuration Guide
HBA	Modèle, firmware, driver ESXi	E-Lab
ISL	SFP LWL 32G 10 km, mode LE (pas de licence Extended Fabrics requise ; elle est de toute façon incluse sur DS-7720B)	Partie 2
Witness	Linux listé dans la Simple Support Matrix (ici : RHEL 9, sous réserve), TCP 443 entrant, NTP	H19163
Management	IP PS-NORD ↔ PS-SUD joignables	H18153 : l'orchestration de la réplication passe par le management, même en FC

4. Contraintes structurantes

Contrainte	Conséquence
Un seul Remote System par paire de clusters	Metro, synchrone et asynchrone entre PS-NORD et PS-SUD partagent le même transport
Type de connexion (TCP ou FC) choisi à la création, non modifiable	Changer de transport = supprimer le Remote System, donc toutes les sessions. Le choix FC est définitif à l'échelle du projet
Réplication FC : pas de raccordement direct baie-à-baie	Les ports de réplication passent par les switches
Pas de migration interne d'un Metro Volume	Le placement sur l'appliance est figé tant que le volume est Metro
QoS non répliquée	Créer les mêmes politiques QoS des deux côtés
Une écriture n'est acquittée qu'après persistance sur les deux baies	La baie la plus lente fixe la latence d'écriture des deux sites

5. Architecture du PowerStore 1200T

5.1 Appliance et nœuds

Deux nœuds (A et B) par appliance. Chaque volume a une affinité de nœud : un seul nœud porte son I/O optimisée à un instant donné.
Cache d'écriture persisté sur des disques NVMe NVRAM (2 sur 1200T).
FC uniquement par I/O modules. Dell recommande le module le plus rapide en slot 0.
Mode de déploiement Block optimized ou Unified choisi à l'installation, non réversible sans réinitialisation. Choix retenu : Block optimized, aucun usage fichier.
Depuis 4.4, aucun system bond n'est créé par défaut. Sans objet pour un cluster mono-appliance.

5.2 ALUA et Target Port Groups

PowerStore expose un Target Port Group par nœud. Pour un volume :

Chemin	État ALUA
Ports du nœud d'affinité	Active/Optimized (AO)
Ports de l'autre nœud	Active/Non-optimized (AN)

En cas de panne du nœud d'affinité, PowerStore ne transfère pas l'état AO au nœud survivant : il ne reste que des chemins AN. Ce comportement oriente le choix du profil NMP (§9).

5.3 Chemin d'écriture Metro

Metro Volume repose sur une architecture symétrique actif/actif : la baie qui reçoit l'écriture joue le rôle de source, l'autre de destination. La séquence est celle de la réplication synchrone décrite dans H18153 :

Étape	Écriture reçue par la baie locale	Écriture reçue par la baie distante
1. Write	ESXi → switch local → PS-NORD	ESXi → switch local → ISL → PS-SUD
2. Miroir	PS-NORD → PS-SUD (FC, ISL)	PS-SUD → PS-NORD (FC, ISL)
3. Commit destination	PS-SUD	PS-NORD
4. Ack du miroir	PS-SUD → PS-NORD (ISL)	PS-NORD → PS-SUD (ISL)
5. Commit source	PS-NORD	PS-SUD
6. ACK hôte	PS-NORD → ESXi	PS-SUD → ESXi via l'ISL
Traversées de l'ISL	2 (1 aller-retour)	4 (2 allers-retours)

Simplifications du schéma :

l'ordre « commit destination puis commit source » est celui de la figure Dell. Le texte Dell ne dit pas si le commit local se fait en parallèle du miroir ;
la copie entre les nœuds A et B d'une même baie (persistance NVRAM) n'est pas représentée ;
le miroir est dessiné sur le fabric A. En réalité, la réplication utilise les ports IOM0 des deux fabrics.

Conséquences de design :

Latence d'écriture ≈ latence locale + RTT inter-site + latence d'écriture de la baie distante.
Chaque baie doit absorber 100 % des écritures, pas 50 %.
Les lectures sont servies par la baie qui reçoit l'I/O.

5.4 Dynamic Resiliency Engine

Pas de RAID group ni de hot spare dédié : l'espace de reconstruction est réparti sur tous les disques.
Tolérance simple ou double défaillance disque, choisie à l'installation.
Dell recommande au moins 10 disques en simple tolérance et 19 en double pour optimiser la capacité utile.
Même tolérance sur les deux baies. En Metro, une reconstruction sur une baie ralentit les écritures des deux sites.

5.5 Réduction de données

Mécanisme	Comportement
Zero detect	Les blocs nuls ne consomment rien
Déduplication	Toujours active, peut être différée en période de forte charge
Compression	Toujours active
Provisionnement	Tout est thin

Points de dimensionnement :

Chaque baie stocke sa propre copie : la capacité est consommée deux fois.
Dimensionner sur le ratio de réduction (déduplication + compression), pas sur le ratio d'efficacité, qui inclut thin provisioning et snapshots.
Après une migration massive, le ratio progresse pendant plusieurs jours, le temps que la déduplication différée rattrape son retard.

6. Plan de ports

6.1 Règles Dell

Règle	Source
Deux fabrics ; chaque nœud et chaque hôte sur les deux	H18241
Au moins 2 chemins par nœud et par hôte ; pas plus de 8 chemins par volume	H18241
Réplication FC : au moins 2 ports par nœud	H18153
Seuls les ports en dual SCSI mode répliquent : en général les ports 0 et 1 de chaque module FC (colonne Capabilities = `Replication, Import`)	H18153
Plusieurs modules FC : réplication sur le premier module	H18241
Dédier les ports à un usage quand c'est possible ; en FC, la dédicace passe par le zoning	H18241 / H18153
Zoning de réplication : une source et une destination par zone, chaque port zoné vers un port par nœud distant	H18153

6.2 Affectation retenue

Identique sur les deux baies et les deux nœuds :

Port	Fabric	Hôtes	Réplication Metro
IOM0 P0	A	✔	✔
IOM0 P1	B	✔	✔
IOM1 P0	A	✔	—
IOM1 P1	B	✔	—

Par baie : 8 ports câblés (4 par fabric), dont 4 portent aussi la réplication.

6.3 Comptage des chemins

Chaque HBA est zoné vers les 4 ports de son fabric sur chaque baie :

Par Metro Volume, par ESXi	HBA0 (fabric A)	HBA1 (fabric B)	Total
Vers PS-NORD (nœuds A + B)	4	4	8
Vers PS-SUD (nœuds A + B)	4	4	8
Total	8	8	16

Zoning de réplication : 2 ports par nœud × 2 nœuds × 2 nœuds distants = 8 zones (4 par fabric).

6.4 Écarts assumés

Sujet	Recommandation Dell	Choix retenu	Impact	Mitigation
Chemins par volume	≤ 8	16 (8 par baie)	Plus de chemins à superviser ; nombre de devices par hôte réduit	Validation Dell avant production ; supervision du nombre de chemins
Ports de réplication	Dédiés	Partagés avec les hôtes sur IOM0	Bande passante partagée sur 4 ports par baie	Mesure de charge des ports IOM0 ; option de retrait des ports IOM0 du zoning hôtes

Le texte Dell ne dit pas si la limite de 8 chemins s'applique par baie ou au volume Metro vu par l'hôte. Les exemples du white paper Metro en accès uniforme donnent 8 chemins au total. Ce point est à faire valider par Dell.

Côté ESXi 8, deux limites s'appliquent :

32 chemins maximum par LUN FC ;
4096 chemins au total par hôte : à 16 chemins par device, cela plafonne à 256 devices par hôte, en comptant les autres baies présentées.

Source : Configuration Maximums vSphere 8, à vérifier sur configmax.broadcom.com pour la version exacte.

7. Connectivité Metro : Co-located with both systems

7.1 Les trois modes

Mode PowerStore	Usage prévu par Dell	États ALUA vus par l'hôte
Co-located with local system	Hôte et baie dans le même site, chemins non équidistants	AO sur la baie locale
Co-located with remote system	Hôte distant de la baie	AN uniquement sur cette baie
Co-located with both systems	Hôte et deux baies équidistants (même salle ou liaison optimale)	AO sur les deux baies

7.2 États ALUA obtenus

Volume avec affinité nœud A sur les deux baies, vu depuis n'importe quel ESXi :

Cible	Chemins	État
PS-NORD nœud A	4	AO
PS-NORD nœud B	4	AN
PS-SUD nœud A	4	AO
PS-SUD nœud B	4	AN

8 chemins AO sur 16, répartis sur les deux sites.

7.3 Justification

10 km de fibre, soit environ 0,1 ms de RTT : la différence de latence entre baie locale et distante est faible.
Le Round Robin policy=latency (§9) choisit parmi les chemins AO ceux de plus faible latence mesurée, donc les chemins locaux dans la plupart des cas.
Critère de retour vers local/remote : si les mesures montrent une part significative d'I/O sur les chemins distants, ou une saturation des ISL. Le test est prévu en partie 3.

7.4 Points de vigilance

Les ISL portent les I/O hôtes croisées en plus de la réplication. Avec un seul ISL par fabric, sa perte reporte tout sur l'autre fabric.
Avec iops=1, ESXi répartirait l'I/O à parts égales entre les 8 chemins AO, donc la moitié vers le site distant.
En fracture inter-site, rien ne change : le côté non-preferred de chaque Metro Volume passe indisponible, et le Witness arbitre.

8. Nommage et adressage

Les noms, adresses IP et WWPN sont fictifs : ils ne correspondent pas à la plateforme du client. Le domaine .example est réservé (RFC 2606), et les plages 198.51.100.0/24 et 203.0.113.0/24 sont réservées à la documentation (RFC 5737).

8.1 Services communs

Service	Nom	IP
Domaine DNS	`infra.acme.example`	—
DNS / NTP DC-NORD	`dns01.infra.acme.example`	10.10.10.5
DNS / NTP DC-SUD	`dns02.infra.acme.example`	10.20.10.5
vCenter	`vc01.infra.acme.example`	10.10.10.10

8.2 Stockage et SAN

Équipement	Nom	IP management
PowerStore DC-NORD (cluster)	`ps-nord-01.infra.acme.example`	10.10.10.20
PowerStore DC-NORD (nœuds, réservées)	—	10.10.10.21–24
PowerStore DC-SUD (cluster)	`ps-sud-01.infra.acme.example`	10.20.10.20
PowerStore DC-SUD (nœuds, réservées)	—	10.20.10.21–24
Fabric A DC-NORD (DID 11)	`fca-nord-01`	10.10.10.31
Fabric B DC-NORD (DID 21)	`fcb-nord-01`	10.10.10.32
Fabric A DC-SUD (DID 12)	`fca-sud-01`	10.20.10.31
Fabric B DC-SUD (DID 22)	`fcb-sud-01`	10.20.10.32

Le nombre exact d'IP de management par appliance dépend du mode de déploiement et de la version. Je réserve un bloc de quatre IP par baie ; le décompte est à vérifier dans le guide de planification réseau PowerStore 5.0.

8.3 ESXi

Site	Hôtes	IP management
DC-NORD	`esx-n01` … `esx-n05`	10.10.20.11–15
DC-SUD	`esx-s01` … `esx-s05`	10.20.20.11–15

8.4 Witness cloud

Élément	Valeur
FQDN	`wit-01.cloud.acme.example`
IP publique	203.0.113.10
IP privée (réseau cloud)	172.16.50.10
Sortie Internet DC-NORD (NAT)	198.51.100.10
Sortie Internet DC-SUD (NAT)	198.51.100.20

8.5 Matrice de flux

Source	Destination	Port	Usage
PS-NORD, PS-SUD (management)	`wit-01` (IP publique)	TCP 443	Metro Witness
Bastion d'administration	`wit-01`	TCP 22	Administration, génération du jeton
`wit-01`	NTP	UDP 123	Synchronisation horaire, obligatoire
PS-NORD ↔ PS-SUD	management	HTTPS	Orchestration de la réplication
PS-NORD, PS-SUD	DNS, NTP	53, 123	Services de base

Contraintes réseau du Witness :

Règle de sécurité cloud : 443 autorisé uniquement depuis 198.51.100.10 et 198.51.100.20.
Chaque site joint le cloud par sa propre sortie Internet. Si DC-NORD sort par DC-SUD, la perte de DC-SUD prive aussi DC-NORD du Witness. La matrice de pannes Dell met alors les volumes hors ligne des deux côtés.
Avec du NAT, le certificat généré à l'installation ne contient que l'IP privée. Il faudra le régénérer avec l'IP publique et le FQDN (partie 3).
Latence maximale vers le Witness : aucune valeur dans la documentation du projet. À vérifier dans Dell PowerStore: Protecting Your Data et la Simple Support Matrix.

8.6 Convention WWPN et alias

Objet	Format d'alias	Exemple
Port PowerStore	`<baie>_<nœud>_<IOM>_<port>`	`PSN_NA_IOM0_P0`
HBA ESXi	`<hôte>_<HBA>`	`ESX-N01_HBA0`

Les WWPN sont relevés dans PowerStore Manager (Hardware > Ports > Fibre Channel, colonne SCSI WWPN) et sur les ESXi. Les valeurs de la partie 2 sont fictives.

9. Préparation des ESXi : best practices et profil NMP

La règle SATP ne s'applique qu'aux devices réclamés après sa création. Elle doit donc être en place sur les 10 ESXi avant la présentation du premier volume PowerStore. C'est pour cette raison qu'elle figure dans la préparation.

9.1 Profil NMP retenu

Élément	Valeur	Source
SATP	`VMW_SATP_ALUA` avec `tpgs_on`	H18116 / H19163
PSP	`VMW_PSP_RR`	H18116 / H19163
Option PSP	`policy=latency`	H19163 (Metro)
Règle système vSphere 7+	Présente par défaut pour PowerStore : ALUA + RR `iops=1`	H18116

Pourquoi policy=latency plutôt que la règle système iops=1 :

Panne de nœud : PowerStore ne promeut pas le nœud survivant en AO. Avec iops=1, ESXi répartit l'I/O sur tous les chemins AN, y compris ceux de la baie distante. Le white paper Metro recommande donc policy=latency.
Mode both : policy=latency garde l'I/O sur les chemins AO locaux en nominal.
H18116 indique que policy=latency est une alternative acceptable à iops=1, et la préconise sur les liens qui subissent de la congestion.

9.2 Commandes

Vérifier la règle système :

bash

# ESXi 8 — esxcli
esxcli storage nmp satp rule list -s VMW_SATP_ALUA | grep -i powerstore

Ajouter la règle Metro, sur chaque ESXi :

bash

# ESXi 7/8 — esxcli (sur ESXi 6.7, ajouter -o disable_action_OnRetryErrors)
esxcli storage nmp satp rule add -c tpgs_on -e "PowerStore" -M PowerStore -P VMW_PSP_RR -O "policy=latency" -s VMW_SATP_ALUA -t vendor -V DellEMC

Sur l'ensemble du cluster en PowerCLI, utiliser le script Set-PowerStoreMetroNmpRule.ps1 fourni avec l'article. Il est idempotent, accepte -WhatIf et produit un rapport CSV.

Rattrapage d'un device réclamé avant la règle :

bash

# ESXi 8 — par device et par hôte
esxcli storage nmp psp roundrobin deviceconfig get -d naa.68ccf098000000000000000000000001
esxcli storage nmp psp roundrobin deviceconfig set -d naa.68ccf098000000000000000000000001 -t latency

9.3 Autres paramètres hôte

Paramètre	Valeur	Source	Remarque
Queue depth HBA, DSNRO	Défaut	H18116	Modifier uniquement sur besoin mesuré
`Disk.QFullSampleSize` / `QFullThreshold`	Défaut	H18116	—
`/DataMover/MaxHWTransferSize`	16384 si seules des PowerStore sont présentées	H18116	Garder la valeur par défaut si d'autres baies sont présentées
Claim rules XCOPY (240 Mo)	Option	H18116	PowerStoreOS 3.0+, plus efficace que MaxHWTransferSize
VAAI (ATS, XCOPY, UNMAP, Block Zero)	Actif par défaut	H18116	Contrôle : `esxcli storage core device vaai status get`
HBA : firmware, driver	Versions E-Lab	Host Connectivity Guide	`esxcli storage san fc list` pour relever les WWPN

bash

# ESXi 8 — taille XCOPY, uniquement si toutes les baies présentées sont des PowerStore
esxcfg-advcfg -g /DataMover/MaxHWTransferSize
esxcfg-advcfg -s 16384 /DataMover/MaxHWTransferSize

Les réglages HA/DRS (APD/PDL, admission control, groupes par site) relèvent de vSphere Metro Storage Cluster et seront traités dans la partie 4.

10. Initial Configuration Wizard

À exécuter sur chaque baie. Les libellés peuvent varier en 5.0.

Étape	PS-NORD	PS-SUD	Remarque
Nom du cluster	`ps-nord-01`	`ps-sud-01`	—
Mode de déploiement	Block optimized	Block optimized	Identique sur les deux baies, non réversible
Tolérance DRE	Simple ou double selon le nombre de disques	Identique	—
Management (IP, masque, passerelle)	10.10.10.20/24, gw 10.10.10.1	10.20.10.20/24, gw 10.20.10.1	—
DNS	10.10.10.5, 10.20.10.5	10.20.10.5, 10.10.10.5	Serveur local en premier
NTP	10.10.10.5, 10.20.10.5	10.20.10.5, 10.10.10.5	Obligatoire pour le Witness
Storage network (iSCSI/NVMe-TCP)	Non configuré	Non configuré	Plateforme 100 % FC
SupportAssist	Activé	Activé	Selon la politique du client
Upgrade	PowerStoreOS 5.0.0.2	PowerStoreOS 5.0.0.2	Avec le Pre-Upgrade Health Check

Après l'assistant, vérifier dans Hardware > Ports > Fibre Channel :

les 8 ports câblés sont up en 32G ;
IOM0 P0/P1 et IOM1 P0/P1 affichent Replication, Import dans Capabilities ;
relever les SCSI WWPN pour le zoning.

11. Dimensionnement des ISL

Un ISL par fabric transporte :

la réplication Metro : 100 % des écritures des Metro Volumes ;
les I/O hôtes croisées : avec le mode both, toute I/O envoyée sur un chemin AO distant ;
en mode dégradé, tout le trafic du fabric perdu.

Règle	Valeur
Capacité requise par ISL	Pic d'écriture Metro + I/O croisées, sur un seul ISL (l'autre fabric peut tomber)
Vitesse	32G : le DS-7720B propose des SFP LWL 10 km en 32G, ses SFP 64G sont SWL uniquement (fiche technique Dell H18424)
Mode	LE, aux deux extrémités (partie 2)
Redondance	Aucune à l'intérieur d'un fabric. La perte d'un ISL fait basculer le trafic sur l'autre fabric ; la perte des deux est une fracture Metro

Vérification (fin de phase)

Contrôle	Attendu
PowerStoreOS	5.0.0.2 sur les deux baies
E-Lab	Combinaison ESXi / HBA / driver / firmware / FOS 9.2.2c / PowerStoreOS 5.0.0.2 validée
Mode de déploiement et DRE	Identiques sur les deux baies
Ports FC	8 ports up par baie ; IOM0 P0/P1 en `Replication, Import`
WWPN	Relevés pour les 16 ports PowerStore et les 20 ports HBA
Règle SATP	`policy=latency` présente sur les 10 ESXi, aucun volume PowerStore présenté avant
NTP	Synchronisé sur PS-NORD, PS-SUD, ESXi et Witness
Witness	VM déployée, 443 ouvert depuis les deux IP de sortie uniquement
Sorties Internet	Indépendantes par site (`traceroute` depuis chaque segment management)
Écarts	16 chemins et réplication partagée validés avec Dell

Risques / points d'attention

Type de Remote System figé : FC est définitif pour la paire de clusters.
Règle SATP créée après la présentation des volumes : devices en iops=1 sans alerte visible.
16 chemins par volume : hors recommandation Dell, à valider ; limite ESXi de 4096 chemins par hôte.
Réplication sur des ports hôtes : surveiller la charge des ports IOM0.
Un seul ISL par fabric : sa perte reporte les I/O croisées et la réplication sur l'autre fabric.
Witness et sorties Internet : une dépendance entre sites rend la perte d'un site fatale aux deux.
5.0.0.2 : connaître la procédure System Paused avant le premier test de bascule.

Sources

Dell PowerStore: Replication Technologies (H18153)
Dell PowerStore: Metro Volume (H19163)
Dell PowerStore: Best Practices Guide (H18241)
Dell PowerStore: VMware vSphere Best Practices (H18116)
PowerStoreOS 5.0.0.x Patch Release Notes (Dell KB 000489647)
Broadcom KB 318954 — Maximum number of supported paths reached
VMware Configuration Maximums — configmax.broadcom.com

Partie 2 : fabrics Connectrix DS-7720B, ISL en mode LE et zoning hôtes et réplication.