Migration sans interruption (NDM) VMAX/PowerMax pour la plate-forme hôte IBMi

Environnement de support :
NDM for IBMi est disponible pour les systèmes hôtes IBMi pris en charge qui sont connectés à des matrices VMAX ou PowerMax exécutant la version 5978.444.444 ou ultérieure de PowerMaxOS.

Il s’agit des LPAR IBMi s’exécutant sur la plate-forme IBM Power Server Power6 ou une version supérieure et exécutant le système d’exploitation IBMi version i6.1.1 ou ultérieure. La matrice de support eLab générale VMAX ou PowerMax fournit des détails et répertorie les IOA Fibre Channel (FC) pris en charge (les IOA IBMi sont des adaptateurs d’E/S, ou HBA (adaptateurs de bus hôte)). NDM est également pris en charge lorsque IBMi est un LPAR client avec des ressources d’E/S virtuelles attribuées à partir d’un serveur d’E/S virtuel IBM (VIOS). Avec la fonction IBM VIOS/VFC (NPIV), des adaptateurs FC virtuels (vFC) sont attribués aux LPAR du client pour la connexion à la matrice de stockage à l’aide de commutateurs SAN pris en charge.
Les vFC servent de passerelle pour la connectivité du disque hôte. Du côté de l’hôte, cette opération est entièrement transparente et toutes les fonctionnalités prises en charge par la matrice de stockage sont également disponibles dans cette configuration d’adaptateur virtualisé.

Scénario de migration de back-ground et de haut niveau :
Symmetrix Remote Data Facility (SRDF) a été développé au début des années 1990 en tant que technologie de réplication de reprise après sinistre (DR) pour les matrices de stockage d’entreprise EMC. Il est également utilisé depuis de nombreuses années pour effectuer des migrations basées sur le stockage d’une matrice à une autre. Autrement dit, connectez le « back-to-back » de l’ANCIENNE et de la NOUVELLE matrice et copiez les volumes de données lors de l’actualisation de la technologie en implémentant une nouvelle matrice de stockage. Bien que le processus de copie SRDF des volumes ou unités logiques (LUN) soit transparent pour les systèmes hôtes rattachés, il nécessitait généralement une courte fenêtre de basculement hors ligne lorsque le processus de copie était terminé à partir des volumes sources (R1). Les volumes cibles (nouveaux) (R2) étaient activés en lecture/écriture et les connexions FC des systèmes hôtes étaient pointées (via le zonage et le masquage SAN) vers la nouvelle matrice. 

SRDF/Metro a été introduit avec la gamme de matrices de stockage VMAX All Flash. SRDF/Metro fournit un véritable accès hôte actif/actif aux volumes source (R1) et cible (R2) des deux matrices. SRDF/Metro fonctionne avec les pilotes hôte multipath pris en charge pour l’accès aux disques. Cela inclut la protection IBMi Dynamic Multi Path (DMP) native pour les chemins de disque. IBMi DMP détecte automatiquement s’il existe plusieurs chemins FC vers le même appareil de disque. Il fournit également un schéma d’équilibrage de charge « permutation circulaire » de base, mais efficace, pour répartir la charge applicative d’E/S de disque sur les chemins d’adaptateur FC disponibles. IBMi DMP fournit un basculement automatique des chemins lorsque les connexions peuvent échouer, en redirigeant l’opération d’E/S de disque vers l’un des chemins actifs restants. Lorsque les connexions défaillantes sont restaurées, IBMi restaure automatiquement ces chemins et recommence à envoyer des E/S de disque à ces chemins.

NDM est basé sur la technologie SRDF/Metro sous-jacente pour fournir un accès simultané aux anciens et nouveaux appareils de stockage. Lorsqu’une paire d’appareils de réplication SRDF/Metro (R1>R2) est créée, la même identité d’appareil R1 est présentée à partir de l’appareil R2 dans la matrice cible. Essentiellement, les mêmes ID série de disque et WWPN d’appareil sont présentés à partir des deux appareils. Initialement, le nouvel appareil R2 est dans un état AA-NR/DEV-INACT (Actif/Actif-Non prêt/Appareil inactif). Une fois que la paire d’appareils R1>R2 est synchronisée, elle peut passer à l’état Actif/Actif en activant l’accès en lecture et écriture au volume R2. Lorsque le chemin de l’IBMi LPAR vers l’appareil R2 est désormais activé (segmentation SAN et masquage pour la nouvelle matrice activée), l’hôte IBMi découvre un nouveau chemin FC vers l’appareil de disque existant. Dans un scénario IBMi NDM, nous présentons les appareils R1 + R2 Actif/Actif, puis en supprimant l’accès aux appareils R1, l’hôte IBMi perd l’accès aux chemins de l’ancienne matrice, mais continue à s’exécuter sur les appareils R2. Une fois cette opération effectuée, l’environnement peut être nettoyé. Supprimez l’ancien masquage R1, supprimez l’ancienne segmentation et exécutez un utilitaire de « réinitialisation multichemin » sur le système IBMi pour arrêter d’utiliser les anciens chemins inactifs. Il peut s’écouler une charge de programme initiale (IPL) ou redémarrage, pour supprimer les anciens chemins inactifs de la base de données de configuration des appareils des hôtes IBMi (référentiel d’informations de gestion du stockage IBMi). Mais il ne s’agit pas d’une tâche obligatoire, il peut également attendre la prochaine IPL planifiée. 
 
Autres informations utiles:
"NDM Best practices and operational guide"
https://infohub.delltechnologies.com/t/dell-powermax-and-vmax-non-disruptive-and-minimally-disruptive-migration-best-practices-and-operational-guide/
===========================================================================================================================================================================================================

PRACTICAL IBMi NDM Procédure:
 

#NDM (Non Disruptive Migration) procedure for IBMi host environments.
#From VMAX>>>VMAX, VMAX>>>PMAX, PMAX>>>PMAX
#Written: Q4-2021
#Author: Wopke Hoekstra CSA IBMi Global Practice
#Version: 5
==========================================================================================

# Just for reference: PowerMax OS 5978 Levels:

Name        Release Level/Code  
Elm         5978.144.144
Elm SR      5978.221.221
Foxtail     5978.444.444
Foxtail SR  5978.479.479
Hickory     5978.669.669
Hickory SR  5978.711.711
==========================================================================================
#PREREQS:
# MINIMUM Microcode Requirements: Foxtail (NDM IBMi support and NDM METRO-Mode available)
# MINIMUM of 2 RF directors per array are required
# Central external UniSphere/SE (SymCLI) server required with access to the source and target arrays
# MINIMUM SE version of 9.1
====================================================================================================

#Actual Customer Environment where this procedure was used:
# "OLD" VMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479
# "NEW" PMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479 

============================================================================================================
#Suggested NDM procedure: METRO NDM with Pre-Copy
#Also refer to the DELL EMC PowerMax NDM Whitepaper: Paragraph 3.2.4 / page 120
============================================================================================================

#PROCEDURE: Metro-based NDM with precopy 
#NOTE: (NDM with precopy allows end users to copy application data from the source array to target array while the application is still running on the source array)

#SAN requirements:
#Existing Host FC IOA ports/WWPN's will be used to also zone to the new target array's FA-ports. NO NEED for additional host FC connections.
#NOTE: The NEW array needs to be connected to the same SAN Fabric's as the OLD array.
#For each zone; add the desired target-array's FA-port WWPN into the existing zone (already containing the host initiator WWPN and OLD array FA-port WWPN)
#Or alternatively create new zones with same initiators to the new target-array's FA-ports

#NOTE: For LPAR's using VIOS/VFC(NPIV) connections and when the environment is setup for Live Partition Mobility, the vFC's secondary WWPN will be included in the zoning/masking.
#The secondary WWPN's will not be active and are not in the source array's Login History Table. NDM does not accept inactive WWPN's to be in the IG of the source host, hence the NDM VALIDATE and CREATE commands will fail.
#WORKAROUND: Temporarily remove the secondary WWPN's from the source LPAR IG. After the migration, simply add these secondary WWPN's back into the new IG on the target array. 

#Setup-phase: 
#symdm –src_sid  -tgt_sid  environment -setup
symdm -sid 008 -tgt_sid 661 environment setup
#NDM RDFGroup will be created.

Now modify the SAN zoning to include the target-array FA-ports.
#NOTE: No devices are presented from the target-array yet.
#NOTE: You can already check if the existing initiator-WWPN's are actively logging in to the new array
symaccess -sid 661 list logins -dirport 1d:4

#To check the environment at any time:
#symdm –src_sid  -tgt_sid  environment -validate
symdm -src_sid 336 -tgt_sid 662 environment -validate
symdm -src_sid 008 -tgt_sid 661 environment -validate

Other commands to display further details:
symdm -sid 336 -environment list
symcfg -sid 336 list -rdfg all
symcfg -sid 008 list -rdfg all

#NOTE: Take a copy of the source-array's masking database before the activity:
symaccess -sid 336 list view -all -v -detail>masking336_24Nov2021.txt
symaccess -sid 008 list view -all -v -detail>masking008_24Nov2021.txt

#Create Phase (with precopy: (run validation prior to execution))
#This creates an SRDF/Metro session with NDM attributes and puts the SRDF/Metro pair into adaptive copy disk mode. 
#It starts syncing data from R1 to R2. 
#Bias is on the Metro-based NDM source.
#symdm create –src_sid  -tgt_sid  -sg  [-tgt_srp ] [-tgt_pg ] -precopy 
#First validate:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy -validate
#Then execute:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy

#Check NDM status:
#symdm –sid xxx list (-v) (-detail)
#symdm –sid -sg  list –v –pairs_info -detail (shows device pairing)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
#symstat –sid  –rdfg –type RDF –i xx
symdm -sid 008 list

#ReadyTGT Phase: 
#Moves RDF pair state from adaptive copy mode to Active/Active(in case of witness protection) or Active/Bias (without witness protection).
#Target devices are moved into a read/write mode, It puts the NDM pair in Active/Active or Active/Bias mode
#Masking view is created on the target array using the masking elements created during the create command.
#symdm –sid  -sg  readytgt
symdm -sid 008 -sg SG_IBMPROD1_1 readytgt

#Check status:
#symdm –sid xxx list (-v) (-detail)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
symdm -sid 008 list

#On the IBMi LPAR, check for new detected FC paths (to the devices on new PowerMax)
#Logon to LPAR, go into System Service Tools: STRSST and go to "work with disks"> "disk configuration"> "9.Disk Paths"
#Let the system discover the paths, this may take a few minutes, just hit F5 to refresh the disk path status screen and verify all disks have the new paths added.

#Commit Phase (this is the actual cutover to the new array):
#symdm –sid  -sg  commit
symdm -sid 008 -sg SG_IBMPROD1_1 commit

#The masking views will be removed on the old source array.
#On the IBMi LPAR, check for the old paths going into "failed" status (these failing paths are the paths to the old source array)
#Zoning cleanup: Remove the old array's FA-ports from the respective zones for this LPAR.
#Use SST procedure to run MULTIPATH RESETTER macro (this will prevent further error messages being sent to the QSYSOPR MSGQ until the system is IPL-ed)
#After next planned IPL, the path status will be correct again, with only the new active paths listed.

#ONLINE MIGRATION COMPLETED!
============================

#Remove NDM environment (ONLY after last migration is completed):
#symdm -sid xxx -environment -list
#symdm –src_sid  -tgt_sid  environment -remove
symdm -sid 008 -tgt_sid 661 environment -remove
============================================================================================================

#Reset Device external Identity (un-Spoof) (Optional OFFLINE operation).
#Resetting the target's device external identity back to the original array-based identity of the NEW array (changes the IBMi disk serial number (= Vol.ID + Array-ID))
#THIS REQUIRES A SHUTDOWN OF THE IBMi LPAR!
#Can be done as planned activity when the IBMi LPAR is doing an offline activity, and will be re-IPL-ed... I.e. for full backup, scheduled IPL, etc.

#Only unmasked devices can be unspoofed, so first record/save the details of the current masking view, then delete the MV, unspoof and then recreate the MV.
symaccess -sid xxx show view -name xxxxxxxx >masking_xxxxxxxx.txt
symaccess -sid xxx delete view -name xxxxxxxx 
symdev -sid xxx list -identity_set
# For a single device: symdev -sid xxx reset -identity -dev xxx -nop
# For a range of devices: symdev -sid xxx reset -identity -devs xxx:xxx -nop
symaccess -sid xxx create view -name xxxxxxxx -sg xxxxxxxx -pg xxxxxxxx -ig xxxxxxxx 

#Now IPL the LPAR and after system is back online, verify the disk serial numbers from SST.
#The serial ID's should now reflect the new arrays symdev ID and array serial number.