Interactive · Metro NDM · VMAX → PowerMax · shared Brocade fabrics

Cable to Commit

The thirteen stages of a non-disruptive migration, drawn on one canvas. Thick grey lines are physical cables; thin coloured lines over them are zones; a cable with no colour on it is plugged in and doing nothing — the state most of Phase A lives in, and the distinction that trips people up. Step through it, or press play.

A once per array pair — link the arrays B repeat for every storage group C once, after the last group
Stage 1 / 13

View
Metro-based NDM migration canvas Two ESXi hosts and two arrays all cabled into the same two Brocade fabrics. Physical cables are drawn in grey; zones are drawn as coloured lines over them. The RDF director ports on both arrays share the same fabrics as the host traffic and carry their own array-to-array zone. esx-node-01 VMware ESXi · dual HBA HBA1 c7:52 HBA2 d3:19 esx-node-02 VMware ESXi · dual HBA HBA1 e1:44 HBA2 e9:2c Fabric A Brocade · domains 1–2 Fabric B Brocade · domains 11–12 2e:03 2e:43 2e:83 2e:c3 1e:4 2e:4 FA FB FA FB RF RF Engine 1 Engine 2 RDF Ready (RW) sg_prod_01 36 devices · R1 · holds the bias VMAX — source 000197900111 9b:0a 9b:4a 9b:8a 9b:ca 1e:4 2e:4 FA 1f:0a FB 2f:0a FA 3f:0a FB 4f:0a RF RF Engine 1 Engine 2 RDF no devices sg_prod_01 created by NDM · R2 · 36 paired devices PowerMax — target 000120400222 SRDF GROUP M_xxxxyyyy not created

Session state

—

—

Fabric zoning

Rollback available

—

—

Source device R1

—

—

Target device R2

—

—

SRDF pair

—

—

Host paths

—

—

physical cable host to fabric zone host to source array zone host to target array zone array to array RDF zone

Cabled, zoned, masked — three different things

A port can be cabled and carry nothing. It can be cabled and zoned and still show the host nothing. Only when a masking view presents a device through that port does a path appear. Phase A is entirely cabling and zoning; not one host sees anything new until B2 creates the masking view on the target.

The runbook — step, command, gate

PhaseStepTool and commandGate before moving on
A1Identify the RDF director ports on both arraysSYMsymcfg -sid <sid> list -dir all
GUISystem > Directors		RF ports identified on both arrays, spread across engines
A2Cable the RDF ports into Fabric A and Fabric BHWphysical cabling
FOSswitchshow		Four RF ports online, two per fabric, one from each array
A3Back up both fabric configsFOScfgshow · configuploadSaved and timestamped, before any zoning change
A4Create the array-to-array zone in both fabricsFOSzonecreate · cfgadd · cfgsave · cfgenableRDF zone effective in both fabrics; host zones untouched
A5Verify each array can see the otherSYMsymcfg discover then symsan list -sanrdfRemote RF port WWNs visible from the local array
A6Create the migration environmentSYMsymdm environment -validate then -setupRDF group present, labelled M_xxxxyyyy
B1Zone this SG's hosts to the target arrayFOSzonecreate · cfgadd · cfgsave · cfgenableNew host zones effective, existing zones untouched
B2Create the migration session for the SGSYMsymdm create -sg -validate then without -validateState reaches Migrating
B3Rescan and verify the host sees the new pathsVMWrescan HBAs
SYMsymdm list -detail		Path count doubled; new paths present but not ready
B4Let the pair synchronizeSYMsymrdf query on the NDM groupR2 invalid tracks at zero, pair active/active
B5Cut over application access to the targetSYMsymdm cutover -sg
GUICutover		Datastores mounted, VMs responsive, signed off
B6CommitSYMsymdm commit -sgPath count back to baseline
C1Clean up after the last groupFOSremove source and RDF zones
SYMsymdm environment -remove		No orphaned zones, masking views or RDF groups left behind

Three zone families, and none of them may be merged. Host to source, host to target, array to array. The RDF zone contains no host initiators at all, so it will legitimately look different from every other zone in the config — that is correct and should not be "fixed". And never name targets on both arrays in one zone: it works, and then removing it after commit takes production targets out with it.

One masking view for a whole cluster

A shared VMFS datastore means every node in the cluster must see the same devices. The masking is built as a cascaded initiator group — one child per host, all of them inside a parent — so that a single masking view covers the whole cluster. NDM clones that structure onto the target, which means one cutover command changes every node at the same instant.

Cascaded initiator group and masking view for an ESXi cluster Four ESXi nodes each own a child initiator group holding that node's two HBA world wide names. The parent initiator group holds the four child group names and no initiators. That parent, a port group spanning both fabrics, and the shared storage group form a single masking view. Effective paths are the intersection of that masking view with the fabric zoning. HOST SIDE · ESXi CLUSTER — initiators (HBAs) INSIDE THE STORAGE ARRAY (PowerMax) — IG · PG · SG · masking view esx-node-01 HBA1 c7:52 HBA2 d3:19 esx-node-02 HBA1 e1:44 HBA2 e9:2c esx-node-03 HBA1 a2:81 HBA2 b6:37 esx-node-04 HBA1 f4:0d HBA2 c9:55 ig_esx01 child IG · members: 2 initiators c7:52 d3:19 ig_esx02 child IG · members: 2 initiators e1:44 e9:2c ig_esx03 child IG · members: 2 initiators a2:81 b6:37 ig_esx04 child IG · members: 2 initiators f4:0d c9:55 ig_cluster_prod parent IG · members: 4 child IG names — no initiators held directly ig_esx01 ig_esx02 ig_esx03 ig_esx04 mv_cluster_prod masking view · the join of exactly these three, one view for the whole cluster IG · ig_cluster_prod the parent group above 8 initiators via 4 children PG · pg_pmax_fa — spans both fabrics 1f:0a · fabric A 2f:0a · fabric B 3f:0a · fabric A 4f:0a · fabric B SG · sg_prod_01 36 devices · shared VMFS parent SG brings its children sg_prod_01 — the unit of migration Every node mounts every datastore in this group, so one cutover moves all four nodes at once You cannot migrate half a storage group, which is why the wave boundary is the cluster boundary Effective paths = masking view AND zoning the view offers ports, zoning decides which are reachable HBA1 c7:52 · fabric A reaches 1f:0a and 3f:0a — 2 paths HBA2 d3:19 · fabric B reaches 2f:0a and 4f:0a — 2 paths 4 paths per node · 16 across the cluster

Why every node must be rescanned

Cutover is one operation on one storage group. It sets the source devices host inactive for all four nodes simultaneously. A node that never discovered the target paths has nothing left to fail over to. Toggle a node below to see the difference.

Metro specifics worth knowing

BehaviourDetail
Bandwidth is sharedBecause the RDF ports use the same fabrics as host traffic, the copy competes for ISL bandwidth. Check ISL utilisation before starting a large group.
Copy mode during syncThe pair is put into adaptive copy disk mode while data moves from R1 to R2. It is not synchronous replication during this phase.
When the target becomes usableThe session goes active/active only after all SCSI information and application data have synchronized. Until then the R2 carries DEV-INACT.
BiasBias sits on the source. If the link drops, the source stays accessible and the target does not — the safe default for a migration.
CancelSuspends the session. The R2 returns to DEV-INACT and all I/O is redirected back to R1.
One group, many migrationsThe RDF group created at A6 is used by every storage group you migrate between this array pair. Built once, removed once.
readytgt optionClears DEV-INACT on the R2 and goes active/active without waiting for synchronization to finish. It removes the "wait for zero invalid tracks" gate — know whether your runbook uses it.
sync-stop optionMakes the source DEV-INACT so all I/O runs through the target, moving the session to CutoverNoSync. Used to test application performance on the target before committing.