VMAX, PowerMax: Ikke-forstyrrende migrering for IBMi-værtsplatformen

Miljø for support:
NDM til IBMi er tilgængelig for understøttede IBMi-værtssystemer, der er tilsluttet VMAX- eller PowerMax-systemer, der kører version 5978.444.444 eller nyere af PowerMaxOS.

Dette gælder for IBMi logiske partitioner (LPAR er), der kører på IBM Power Server-platformen Power6 eller nyere og kører IBMi-operativsystemversion i6.1.1 eller nyere. VMAX- eller PowerMax generelle e-Lab-supportmatrix indeholder oplysninger og viser de understøttede Fibre Channel (FC) IBMi I/O-adaptere (IOA'er), også kaldet værtsbusadaptere (HBA'er). NDM understøttes også, når IBMi er en klient-LPAR med tildelte virtuelle I/O-ressourcer fra en IBM Virtual I/O-server (VIOS). Med funktionen IBM VIOS/VFC (NPIV) tildeles klientens LPAR er til virtuelle FC-adaptere (vFC'er) med henblik på tilslutning til storagesystemet ved hjælp af understøttede SAN-switche.

vFC'er fungerer som et gennemløb for værtsdiskforbindelsen; Fra værtssiden er dette fuldt gennemsigtigt, og alle understøttede funktioner fra storagesystemet er også tilgængelige i den virtualiserede adapteropsætning.

Migreringsscenarie for baggrund og på højt niveau:
Symmetrix Remote Data Facility (SRDF) blev udviklet i begyndelsen af 1990'erne som en DR-replikeringsteknologi (Disaster Recovery) til Dell Enterprise Storage-systemer. Det har også været brugt i mange år til at udføre lagerbaserede migreringer fra et array til et andet. Det betyder, at du kan forbinde det GAMLE og NYE systems "back-to-back" og kopiere dataenhederne, når du udfører en teknologiopdatering, ved at implementere et nyt storagesystem. Selvom SRDF-kopieringsprocessen for diskenhederne eller de logiske enheder (LUN'er) er gennemsigtig for de tilknyttede værtssystemer, krævede den traditionelt altid et kort offline "cut-over"-vindue, når kopieringsprocessen blev fuldført fra kildediskenhederne (R1'erne). Måldiskenhederne (nye) (R2'er) blev læst/skriveaktiveret, og værtssystemernes FC-forbindelser blev peget (via SAN-zoneinddeling og maskering) mod det nye system. 

SRDF/Metro blev introduceret med VMAX All Flash Storage-systemserien. SRDF/Metro giver ægte aktiv/aktiv værtsadgang til kilde- (R1) og mål-(R2) diskenheder fra begge systemer. SRDF/Metro fungerer sammen med understøttede værtsdrivere med flere stier til diskadgang. Dette omfatter den indbyggede IBMi Dynamic Multi Path (DMP)-beskyttelse af diskstier. IBMi DMP registrerer automatisk, hvis der er flere FC-stier til den samme diskenhed. Den indeholder også et grundlæggende, men effektivt "round robin"-belastningsjusteringsskema til at sprede diskens I/O-workload på tværs af de tilgængelige FC-adapterstier. IBMi DMP giver automatisk sti-failover, når forbindelser kan mislykkes, ved at omdirigere diskens I/O-handling til en af de resterende aktive stier. Når mislykkede forbindelser gendannes, gendanner IBMi automatisk disse stier og begynder at sende disk I/O til disse stier igen.

NDM med mulighed for METRO og precopy er baseret på den underliggende SRDF/Metro-teknologi for at give samtidig adgang til de gamle og de nye storageenheder.

OPRET fase:
Når der oprettes et SRDF/Metro-replikeringsenhedspar (R1>, R2), præsenteres den samme R1-enhedsidentitet fra R2-enheden i målmatrixet. I det væsentlige præsenteres det samme diskseriel ID og enhed WWPN fra begge enheder. Indledningsvis er den nye R2-enhed i tilstanden AA-NR/DEV-INACT (Active/Active-Not Ready/ Device Inactive). Når R1>R2-enhedsparret er synkroniseret, kan det gå i aktiv/aktiv tilstand ved at aktivere læse- og skriveadgang til R2-diskenheden.

READY_TARGET Fase:
Når stien fra IBMi LPAR til R2-enheden nu er aktiveret (SAN-zoneinddeling allerede på plads og maskering af det nye system aktiveret af NDM readytgt-kommandoen), registrerer IBMi-værten nye FC-stier til den eksisterende diskenhed. I et IBMi NDM-scenarie vises de aktive/aktive R1 + R2-enheder.

COMMIT fase:
Ved at fjerne adgangen til R1-enhederne mister IBMi-værten nu adgangen til det gamle systems stier, men fortsætter med at køre på R2-enhederne ved hjælp af stierne til det nye system. Når dette er gjort, kan SAN-zoneinddelingen til det gamle system fjernes. Hjælpeprogrammet "reset multipath" på IBMi-systemet skal køres for at stoppe med at bruge de gamle inaktive stier og også stoppe eventuelle fejlmeddelelser, der er knyttet til disse nu "manglende" stier. Det kan tage en Initial Program Load (IPL) aka genstart, for permanent at fjerne de gamle inaktive stier og dens tilknyttede DMPxxx diskhardwareressourcer fra IBMi-værternes enhedskonfigurationsdatabase (IBMi Storage Management Information Repository), men dette er ikke en obligatorisk IPL, den kan også vente til den næste planlagte IPL. Til fjernelse af disse "forældede" enheder: STRSST>Start Service Tool>Hardware Service Manager>mislykkedes og ikke-rapporterende hardware: Vælg alle gamle diskressourcer DMPxxx til fjernelse med mulighed 4, og bekræft dette ved at trykke på Enter.

Overvejelser ved brug af Dell STM
PowerMax-storage, der også ofte omtales som "storage copy services toolkit" til IBMi-replikeringskontrol til VMAX, kører som et indbygget softwareprogram på en eller flere IBMi-værter. Den kan styre fjernreplikering for understøttede SRDF-konfigurationer og lokal replikering for SnapVX-snapshots på VMAX- og PowerMax-systemer. STM findes i to varianter: Standardfunktionsudgave og udgave med udvidede funktioner.

STM bruger båndkommunikation til lagerarrayet på tværs af FC-stierne, det bruger små dedikerede enheder, også nævnt som gatekeepere til sine systemopkald. Gatekeeperne til IBMi er specielle små enheder af typen D910 GK, der forbliver i afsnittet om ikke-konfigurerede diskenheder. Disse gatekeepere understøtter ikke multipath, flere single-pathed gatekeepers præsenteres typisk på det samme redundante sæt stier, der bruges til de almindelige ASP1-diske. Det anbefales at bruge mindst fire gatekeepere. Gatekeepere er ikke en del af NDM-migreringsprocessen, og efter migreringen fjernes adgangen til gatekeepere fra det gamle system, og nye gatekeepere fra det nye system præsenteres.

Standardfunktioner:
Dette bruges til systemer, der kun bruger en *SYSBAS-lagerkonfiguration. *SYSBAS betyder systemet ASP1 + eventuelle yderligere User-ASP er (ASP 2-32). STM er kun installeret på kildenoden, og den styrer replikeringsparrene for alle diske i *SYSBAS som én enhed, der ikke kan deles.  Når der sker ændringer i den underliggende diskkonfiguration; det vil sige ændringer af diskens serienummer forårsaget af NDM-handlingen "unspoofing", er det tilstrækkeligt at udføre STM DISCOVER-kommandoen på IBMi-kildeværten. Kør indstillingen DISCOVER, når gatekeeperne fra det nye system præsenteres. Dette opdaterer den lokale symapi-database i IFS (Integrated File System) på værten (location= /var/symapi/db). STM-skærmene viser nu også de nye diskserienumre. Hvis der opstår problemer under parringen af replikeringsenheden i STM, er det også muligt kun at bruge installationsindstillingen til at starte med en ny konfigurationsopsætning. Dette har ingen indflydelse på opsætningen af replikeringsparringen, som allerede er konfigureret på VMAX-PowerMax-storagesystemet. For at få en ren arbejdsinstallation/opsætning skal du først dokumentere de tilknyttede STIER og TRIN i den aktuelle konfiguration (GO MAINCTL>1, IMAGES>vælg mulighed 2, for skærmbilledet SYSTEM-billede> til oprettelse af STIER som vist i nedenstående eksempel:

Afslut STM, slet mappen /var/symapi og dens undermapper. Slet EMCCTL-biblioteket. Kør STM installer programmet igen. Kør CRTSYMAPI. GO MAINCTL, tilknyt de samme STIER igen, som blev konfigureret tidligere. STM registrerer og viser nu status for den aktive replikeringsparring fra VMAX-PowerMax-storagesystemet. STM-driften er klar til at blive genoptaget nu.

Udvidede funktioner:
Dette bruges til systemer, der bruger en IBMi PowerHA-klyngeopsætning med en eller flere "omskiftelige" iASP (uafhængig ASP). I dette scenarie replikeres kun iASP, og denne iASP eller replikaer deraf kan præsenteres for noderne i PowerHA-klyngen. Hver klyngenode er allerede aktiv alene *SYSBAS (ASP1). iASP er konfigureret som en omskiftelig ressource inden for det delte klyngeenhedsdomæne. Der er typisk to eller fire noder i klyngen; det er i henhold til nedenstående eksempeldiagram for en 4-nodeklynge med produktionsnoden som kilde og med en ekstern DR-målknude og en SnapVX-backup-node på begge sider:

Der kræves ingen IPL fra nogen node for at bruge iASP eller dens replikaer. Når iASP-diskene præsenteres for en node i klyngen, kræver det kommandoen VARY ON for at gøre iASP tilgængelig for den pågældende node. I en PowerHA-opsætning installeres STM-kildeversionen på kildenoden (i EMCCTL-biblioteket). På alle andre noder (enten SRDF- eller SnapVX-målreplikaer) installeres målversionen (i EMCCTLC-biblioteket). Da alle noder er aktive, er der afhængigheder og kontroller og saldi indbygget i STM for visse handlinger i denne opsætning, der fjerner diskadgang for en node er forbudt, hvis iASP stadig er i VARY ON-tilstand for den node. Til internodekommunikationen kører der et STM-serverjob i EMCCTL-undersystemet på alle noder. Dette job kommunikerer inden for noderne på tværs af klyngens IP-grænseflader. Typiske STM-handlinger kan køres fra enhver node i klyngen. Dette kræver, at et sæt af de samme STM-diske, adaptere og stikonfigurationsfiler er tilgængelige på hver node. Under den indledende opsætning af STM til PowerHA konfigureres disse filer ved hjælp af MAINCTL-indstilling-16 fra kildenoden, og dette overfører også disse filer til målnoderne, som er IASPS-, ISRCIOA- og IMAGE-filerne i STM-installationsbibliotekerne EMCCTL og EMCCTLC. Disse filer kan også vises, det vil sige med DSPPFM EMCCTL / IMAGE. Filerne indeholder oplysninger om diske og diskadaptere, der anvendes til iASP-konfigurationen. Adapter-ID'er og diskserienumre gemmes i disse filer og bruges i STM-handlingerne.

Overvej nu virkningen af en ændring af diskens serienummer, der sker, når NDM-unspoofing-handlingen er udført. STM-konfigurationsfilerne indeholder stadig de gamle diskserienumre. De fleste STM-handlinger fungerer ikke længere, før disse konfigurationsfiler opdateres. Opdatering og udbredelse af disse filer kan udføres ved at følge den samme proces som under den indledende STM-installation, når MAINCTL>Option-16 (konfigurer iASP) køres, mens iASP-diskene gøres tilgængelige for målnoderne i det respektive PATH-STEP. Når disse filer er opdateret, fungerer STM iASP-handlinger som forventet igen. Hvis der opstår problemer, bør du overveje kun at køre en scratch-installation igen af STM for kilde- og målnoderne, herunder mulighed-16 for at konfigurere iASP PATH's/STEP's og oprette eller udbrede STM-konfigurationsfilerne.

Registrerede brugere med en Dell Support-konto kan se SRDF/TimeFinder Manager for IBM i for yderligere relevante oplysninger om disse STM-udgaver.

Overvejelser i forbindelse med den næste IPL efter nulstilling af enhedsidentitet, også kaldet "unspoof"-handling
NDM-unspoof-handlingen ændrer diskens serienumre. Dette kan kun gøres, når IBMi LPAR er nede. Når denne handling udføres efter migrering i en planlagt offline vedligeholdelsesplads, er der nogle overvejelser. Aktiveringen af IBMi LPAR styres fra IBM PowerServer Hardware Management Console (HMC), HMC leverer Hypervisor-funktionen til IBM PowerVM-virtualisering. På denne HMC har hver LPAR mindst en LPAR-profil med detaljer om LPAR-konfigurationen, det vil sige CPU / MEM, adaptere osv. Når LPAR er IPL-ed (IPL= Initial Program Load = boot sequence) for første gang, læser den konfigurationsdetaljerne fra den valgte profil. En særlig fane i profilen kaldes "Tagged I/O."  Tagged I/O-indstillingerne definerer, hvor LPAR skal søge efter Load Source (LS) (= bootdisk) under en B-type IPL og efter den "alternative genstartsenhed" under en D-type IPL, dvs. DVD eller bånd. Hvis LPAR med succes har IPL-ed for første gang, behøver den ikke at læse profilen igen, da de sidste IPL-oplysninger gemmes på hypervisoren. Ved næste IPL bruges standardindstillingen "aktuel konfiguration", medmindre LPAR-profilen vælges specifikt igen. Hvis der er specifikke ændringer for LS-controlleren eller for LS-diskdetaljerne mellem IPL'erne, accepterer LPAR ikke den ændrede LS-disk, og IPL'en mislykkes. Dette sker, hvis: LPAR aktiveres med indstillingen "aktuel konfiguration", eller hvis den mærkede I/O LS-adapter er indstillet til "ingen". Ændringen af LS-diskens serienummer er en sådan ændring, at LPAR ikke accepterer den, og hvor der kræves en aktivering med den korrekte valgte profil.

Skærmbilledet nedenfor viser den traditionelle HMC LPAR-profilvisning med en gyldig LS-adapter valgt:

Billedet nedenfor viser de samme oplysninger i den moderne version af HMC v10 med VIOS 3.x /4.x.

 

Andre nyttige oplysninger findes i PowerMax og VMAX: Bedste praksis og driftsvejledning

til migrering, der ikke er forstyrrende og med minimalt forstyrrelse======================================================================================

PRAKTISK IBMi NDM-procedure:

#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 <SN of Source> -tgt_sid <SN of target> 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 <SN of Source> -tgt_sid <SN of target> 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 <SN of Source> -tgt_sid <SN of target> -sg <SG to be Migrated> [-tgt_srp <target SRP>] [-tgt_pg <target 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<SN of SRC or TGT> -sg <SG to be Migrated> list –v –pairs_info -detail (shows device pairing)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
#symstat –sid <SRC SN> –rdfg<RDFG of Migration> –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 <SRC or TGT SN> -sg <SG to be Migrated> 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 <SRC or TGT SN> -sg <SG to be Migrated> 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 <SN of Source> -tgt_sid <SN of target> 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.

#NOTE: When STM (SRDF/TimeFinder Manager for IBMi) is used on the migrated LPAR, it requires a reconfiguration or as a minimum a DISCOVER command action, due to the changing of the LPAR's disk serial numbers.
#Refer to KB article 193832 for more info and procedure.

Kun ikke-maskerede enheder kan fjernes, så registrer og gem først detaljerne i den aktuelle maskeringsvisning, slet derefter MV'en, fjern spoof, og genskab derefter MV'en.

symaccess -sid xxx show view -name xxxxxxxx >masking_xxxxxxxx.txt
symaccess -sid xxx delete view -name xxxxxxxx 

Vis identitetsoplysninger om disk:

symdev -sid xxx list -identity_set
symdev -sid xxx list -identity -sg <sg-name>

For en enkelt enhed:

symdev -sid xxx reset -identity -dev xxx -nop

For en række enheder:

symdev -sid xxx reset -identity -devs xxx:xxx -nop

symaccess -sid xxx create view -name xxxxxxxx -sg xxxxxxxx -pg xxxxxxxx -ig xxxxxxxx 
symdev -sid xxx list -identity -sg <sg-name>

Bekræft fra IBM HMC, at LS-controlleren er indstillet til den korrekte FC-adapter i fanen "Tagged I/O" i LPAR-profilen.

Lad IKKE indstillingen "Tagged I/O" LS-controller være tom med "ingen" valgt.

IPL med B-Normal-indstillingen, og vælg LPAR-profilen for IPL, lad den IKKE være standardindstillingen for "aktuel konfiguration".

Nu IPL LPAR, og efter at systemet er online igen, skal du kontrollere diskens serienumre fra SST.

De serielle id er bør nu afspejle de nye systemers symdev-id og systemets serienummer.

=== End of Procedure ===