Migración no disruptiva (NDM, por sus siglas en inglés) de VMAX/PowerMax para la plataforma de host de IBMi

Entorno para soporte:
NDM para IBMi está disponible en los sistemas host de IBMi soportados que están conectados a arreglos VMAX o PowerMax que ejecutan la versión 5978.444.444 o posterior de PowerMaxOS.

Esto es para LPAR de IBMi que se ejecutan en la plataforma IBM Power Server Power6 o posterior y que ejecutan la versión del sistema operativo i6.1.1 o posterior de IBMi. La matriz de soporte eLab general de VMAX o PowerMax proporciona detalles y enumera los IOA de Fibre Channel (FC) soportados (los IOA de IBMi son adaptadores de I/O, también conocido como HBA [adaptadores de bus del host]). NDM también es soportado cuando IBMi es un LPAR de cliente con recursos de I/O virtuales asignados de un servidor de I/O virtual (VIOS) de IBM. Con la función IBM VIOS/VFC (NPIV), los adaptadores FC virtuales (vFC) se asignan a los LPAR del cliente para conectarse al arreglo de almacenamiento mediante switches SAN soportados.
Los vFC actúan como una transferencia a la conectividad del disco del host. Desde el lado del host, esto es totalmente transparente y todas las funciones soportadas del arreglo de almacenamiento también están disponibles en esa configuración de adaptador virtualizado.

Fondo y situación de migración de alto nivel:
Symmetrix Remote Data Facility (SRDF) se desarrolló a principios de la década de los 90 como una tecnología de replicación de recuperación ante desastres (DR, por sus siglas en inglés) para los arreglos de almacenamiento empresarial de EMC. También se ha utilizado durante muchos años para realizar migraciones basadas en almacenamiento de un arreglo a otro. Es decir, conecte los arreglos OLD y NEW “uno después del otro” y copie los volúmenes de datos cuando realice una actualización de tecnología mediante la implementación de un nuevo arreglo de almacenamiento. A pesar de que el proceso de copia de SRDF de los volúmenes o las unidades lógicas (LUN, por sus siglas en inglés) es transparente para los sistemas host conectados, de forma tradicional siempre requería una breve ventana de “migración” offline cuando el proceso de copia se completaba desde los volúmenes fuente (R1). Los volúmenes (nuevos) de objetivo (R2) estaban habilitados para lectura o escritura y las conexiones FC de los sistemas host se señalaron (mediante la zonificación y el enmascaramiento de SAN) al nuevo arreglo. 

SRDF/Metro se presentó con la familia de arreglos de almacenamiento VMAX All Flash. SRDF/Metro proporciona un verdadero acceso activo o de host activo a los volúmenes de fuente (R1) y objetivo (R2) desde ambos arreglos. SRDF/Metro funciona con controladores de múltiples rutas de host soportadas para el acceso al disco. Esto incluye la protección nativa de múltiples rutas dinámicas (DMP, por sus siglas en inglés) de IBMi para las rutas de disco. DMP de IBMi detecta de forma automática si hay varias rutas de FC al mismo dispositivo de disco. También proporciona un esquema de balanceo de carga “Round Robin” básico, pero eficaz para distribuir la carga de trabajo de I/O del disco entre las rutas de adaptador FC disponibles. DMP de IBMi proporciona conmutación por error de rutas automático cuando las conexiones pueden fallar, mediante el redireccionamiento de la operación de I/O del disco a una de las rutas activas restantes. Cuando se restauran las conexiones fallidas, IBMi recupera esas rutas de forma automática y comienza a enviar las I/O del disco a estas rutas de nuevo.

NDM se basa en la tecnología SRDF/Metro subyacente para proporcionar acceso simultáneo a los dispositivos de almacenamiento antiguos y nuevos. Cuando se crea un par de dispositivos de replicación de SRDF/Metro (R1>R2), se presenta la misma identidad de dispositivo R1 desde el dispositivo R2 en el arreglo objetivo. En esencia, el mismo ID de serie de disco y WWPN del dispositivo se presentan desde ambos dispositivos. Al inicio, el nuevo dispositivo R2 se encuentra en un estado de AA-NR/DEV-INACT (activo/activo-no listo/dispositivo inactivo). Una vez que se sincroniza el par de dispositivos R1>R2, puede entrar en un estado activo / activo mediante la habilitación del acceso de lectura y escritura al volumen R2. Cuando la ruta del LPAR de IBMi al dispositivo R2 ahora está habilitada (Zonificación y enmascaramiento de SAN para el nuevo arreglo activado), el host de IBMi descubre una nueva ruta FC al dispositivo de disco existente. En una situación NDM de IBMi, presentamos los dispositivos R1 y R2 activo / activo y, luego, mediante la eliminación del acceso a los dispositivos R1, el host de IBMi pierde el acceso a las rutas del arreglo antiguo, pero continúa ejecutándose en los dispositivos R2. Una vez hecho esto, se puede limpiar el entorno; elimine el enmascaramiento R1 antiguo, elimine la zonificación antigua y ejecute una utilidad de “reset multipath” en el sistema IBMi para detener el uso de las rutas inactivas antiguas. Es posible que se necesite una carga inicial del programa (IPL, por sus siglas en inglés), también conocida como reinicio, para eliminar las rutas inactivas antiguas de la base de datos de configuración de dispositivos (repositorio de información de administración de almacenamiento de IBMi) de los hosts de IBMi, pero esta no es una tarea obligatoria, sino que también puede esperar hasta la próxima IPL planificada. 
 
Otra información útil:
"Mejores prácticas de NDM y guía operacional"
https://infohub.delltechnologies.com/t/dell-powermax-and-vmax-non-disruptive-and-minimally-disruptive-migration-best-practices-and-operational-guide/
========================================== =================================================

PRÁCTICO NDM de IBMi Procedimiento:
 

#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.