VMAX, PowerMax: Avbruddsfri migrering for IBMi-vertsplattformen

Miljø for støtte:
NDM for IBMi er tilgjengelig for støttede IBMi-vertssystemer som er koblet til VMAX- eller PowerMax-arrayer som kjører versjon 5978.444.444 eller nyere av PowerMaxOS.

Dette er for logiske IBMi-partisjoner (LPAR-er) som kjører på IBM Power Server-plattformen Power6 eller nyere, og som kjører IBMi-operativsystemversjon i6.1.1 eller nyere. Den generelle VMAX- eller PowerMax-støttematrisen for e-Lab inneholder informasjon og viser de støttede Fibre Channel (FC) IBMi I/O-adapterne (IOA-ene), også kjent som vertsbussadaptere (HBA-er). NDM støttes også når IBMi er en klient-LPAR med tilordnede virtuelle I/O-ressurser fra en IBM Virtual I/O Server (VIOS). Med funksjonen IBM VIOS/VFC (NPIV) tilordnes virtuelle FC-adaptere (vFC-er) til klient-LPAR-ene for tilkobling til lagringsarrayet ved hjelp av støttede SAN-svitsjer.

vFC-er fungerer som en gjennomgang for vertsdisktilkoblingen; Fra vertssiden er dette helt gjennomsiktig, og alle støttede funksjoner fra lagringsarrayet er også tilgjengelige i det virtualiserte adapteroppsettet.

Scenario for migrering i grunnen og på høyt nivå:
Symmetrix Remote Data Facility (SRDF) ble utviklet tidlig på 1990-tallet som en Disaster Recovery (DR) replikeringsteknologi for Dell Enterprise Storage-arrayer. Den har også blitt brukt i mange år for å utføre lagringsbaserte migreringer fra en matrise til en annen. Det vil si at du kobler til "back-to-back" for OLD- og NEW-arrayet og kopierer datavolumene når du utfører en teknologioppdatering, ved å implementere et nytt lagringsarray. Selv om SRDF-kopieringsprosessen for volumene eller logiske enheter (LUN-er) er gjennomsiktig for de vedlagte vertssystemene, krevde den tradisjonelt alltid et kort, frakoblet "cut-over"-vindu når kopieringsprosessen ble fullført fra kildevolumene (R1s). Målvolumene (nye) volumer (R2-er) var lese-/skriveaktiverte, og FC-tilkoblingene til vertssystemene ble pekt (via SAN-sonering og maskering) til den nye matrisen. 

SRDF/Metro ble introdusert med VMAX All Flash-lagringsarray-serien. SRDF/Metro gir ekte aktiv/aktiv vertstilgang til kildevolumene (R1) og målvolumene (R2) fra begge arrayene. SRDF/Metro fungerer med støttede flerbanevertsdrivere for disktilgang. Dette inkluderer den opprinnelige IBMi Dynamic Multi Path (DMP)-beskyttelse for diskbaner. IBMi DMP oppdager automatisk om det er flere FC-baner til samme diskenhet. Den har også et grunnleggende, men effektivt "round robin"-belastningsskjema for å spre I/O-workloaden for disker på de tilgjengelige banene til FC-adapteren. IBMi DMP gir automatisk bane-failover når tilkoblinger kan mislykkes, ved å omdirigere I/O-diskoperasjonen til en av de gjenværende aktive banene. Når mislykkede tilkoblinger gjenopprettes, gjenoppretter IBMi automatisk disse banene og begynner å sende disk I/O til disse banene igjen.

NDM med METRO og forhåndskopieringsalternativet er basert på den underliggende SRDF/Metro-teknologien for å gi samtidig tilgang til de gamle og nye lagringsenhetene.

OPPRETT-FASEN:
Når et SRDF/Metro-replikeringsenhetspar (R1>R2) opprettes, vises den samme R1-enhetsidentiteten fra R2-enheten i målarrayet. I hovedsak presenteres samme disk seriell ID og enhet WWPN fra begge enhetene. I utgangspunktet er den nye R2-enheten i en tilstand av AA-NR/DEV-INACT (Aktiv / Aktiv-Ikke klar / Enhet Inaktiv). Når R1>R2-enhetsparet er synkronisert, kan det gå inn i en aktiv/aktiv tilstand ved å aktivere lese- og skrivetilgang til R2-volumet.

READY_TARGET-fasen:
Når banen fra IBMi LPAR til R2-enheten nå er aktivert (SAN-sonering allerede på plass og maskering for det nye arrayet aktivert av NDM readytgt-kommandoen), oppdager IBMi-verten nye FC-baner til den eksisterende diskenheten. I et IBMi NDM-scenario vises de aktive/aktive R1 + R2-enhetene.

COMMIT-fasen:
Ved å fjerne tilgangen til R1-enhetene, mister IBMi-verten nå tilgangen til den gamle matrisens baner, men fortsetter å kjøre på R2-enhetene ved hjelp av banene til det nye arrayet. Når dette er gjort, kan SAN-soneringen til den gamle matrisen fjernes. Den "reset multipath" verktøyet på IBMi-systemet bør kjøres, for å slutte å bruke de gamle inaktive baner og også stoppe eventuelle feilmeldinger knyttet til disse nå "mangler" baner. Det kan ta en Initial Program Load (IPL) aka omstart, for permanent å fjerne de gamle inaktive banene, og tilhørende DMPxxx-diskmaskinvareressurser fra IBMi-vertens enhetskonfigurasjonsdatabase (IBMi lagringsadministrasjonsinformasjonslager), men dette er ikke en obligatorisk IPL, den kan også vente til neste planlagte IPL. For fjerning av disse "foreldede" enhetene: STRSST>Start Service Tool>Maskinvareserviceleder>Mislykket og ikke-rapporterende maskinvare: velg alle gamle diskressurser DMPxxx for fjerning med alternativ 4, og bekreft det ved å trykke enter.

Hensyn ved bruk av Dell STM
STM, også ofte kalt "verktøysett for lagringskopieringstjenester" for IBMi-replikeringskontroll for VMAX, kjører PowerMax-lagring som en innebygd programvare på én eller flere IBMi-verter. Den kan kontrollere ekstern replikering for støttede SRDF-konfigurasjoner og lokal replikering for SnapVX-øyeblikksbilder på VMAX- og PowerMax-arrayer. STM kommer i to smaker: Standardfunksjonsutgave og utvidet funksjonsutgave.

STM bruker kommunikasjon i bånd til lagringsarrayet på tvers av FC-banene, den bruker små dedikerte enheter, også nevnt som portvakter for systemanropene. Gatekeepers for IBMi er spesielle små D910 GK-type enheter som forblir i ikke-konfigurerte diskenheter. Disse portvokterne støtter ikke flerbane, flere ensporede portvoktere presenteres vanligvis på det samme overflødige settet med baner som brukes for de vanlige ASP1-diskene. Det anbefales å bruke minimum fire portvoktere. Portvoktere er ikke en del av NDM-migreringsprosessen, og etter overføringen fjernes derfor tilgangen til portvoktere fra den gamle matrisen og nye portvoktere fra den nye matrisen presenteres.

Standardfunksjoner:
Dette brukes for systemer som bare bruker en *SYSBAS-lagringskonfigurasjon. *SYSBAS betyr systemet ASP1 + eventuelle ekstra bruker-ASP-er (ASP 2-32). STM installeres bare på kildenoden, og den kontrollerer replikeringsparene for alle disker i *SYSBAS som én enhet som ikke kan deles.  Når det skjer endringer i den underliggende diskkonfigurasjonen; det vil si serienummerendringer forårsaket av NDM "unspoofing"-operasjonen, er det tilstrekkelig å utføre STM DISCOVER-kommandoen på IBMi-kildeverten. Kjør alternativet DISCOVER når portvokterne fra den nye matrisen vises. Dette oppdaterer den lokale symapi-databasen i det integrerte filsystemet (IFS) på verten (location= /var/symapi/db). STM-skjermbildene gjenspeiler nå også de nye serienumrene for disken. Hvis det oppstår problemer med sammenkoblingen av replikeringsenheten i STM, er det også mulig å bare bruke installasjonsalternativet for å starte med et nytt konfigurasjonsoppsett. Dette har ingen innvirkning på oppsettet for replikeringsparing som allerede er konfigurert på VMAX-PowerMax-lagringsarrayet. For en ren installasjon / oppsett av riper, må du først dokumentere de tilknyttede PATHS og STEPS i gjeldende konfigurasjon (GO MAINCTL>1, IMAGES>velg alternativ 2, for SYSTEM-bildet> opprett skjermopptak for PATHS-skjermen i henhold til eksemplet nedenfor:

Avslutt STM, slett /var/symapi-mappen og undermappene. Slett EMCCTL-biblioteket. Kjør STM, installer programmet på nytt. Kjør CRTSYMAPI. GO MAINCTL, tilknytte de samme banene igjen som ble konfigurert tidligere. STM oppdager og viser nå status for den aktive replikeringsparingen fra VMAX-PowerMax-lagringsarrayet. STM-driften er klar til å gjenopptas nå.

Utvidede funksjoner:
Dette brukes for systemer som bruker et IBMi PowerHA-klyngeoppsett med en eller flere "byttbare" iASP (uavhengig ASP). I dette scenariet replikeres bare iASP, og denne iASP eller replikaen derav kan presenteres for nodene i PowerHA-klyngen. Hver klyngenode er allerede aktiv på egen hånd *SYSBAS (ASP1). iASP er konfigurert som en byttbar ressurs innenfor det delte klyngeenhetsdomenet. Det er vanligvis to eller fire noder i klyngen; det er i henhold til eksempeldiagrammet nedenfor for en 4-nodeklynge med produksjonsnoden som kilde og med en ekstern DR-målnode og en SnapVX-sikkerhetskopinode på begge sider:

Ingen IPL fra en node er nødvendig for å bruke iASP eller dens replikaer. Når iASP-diskene presenteres for en node i klyngen, krever det at kommandoen VARY ON gjør iASP tilgjengelig for den noden. I et PowerHA-oppsett er STM-kildeversjonen installert på kildenoden (i EMCCTL-biblioteket). På alle andre noder (enten SRDF eller SnapVX-målreplikaer) er målversjonen installert (i EMCCTLC-biblioteket). Når alle noder er aktive, er det avhengigheter og kontroller og saldoer innebygd i STM for visse operasjoner i dette oppsettet som fjerner disktilgang for en node er forbudt hvis iASP fortsatt er i VARY ON-tilstand for den noden. For kommunikasjon mellom noder kjører en STM-serverjobb i EMCCTL-delsystemet på alle noder. Denne jobben kommuniserer i nodene på tvers av klyngens IP-grensesnitt. Typiske STM-operasjoner kan kjøres fra en hvilken som helst node i klyngen. Dette krever at et sett med samme STM-disk, adaptere og banekonfigurasjonsfiler er tilgjengelig på hver node. Under det første oppsettet av STM for PowerHA, er disse filene konfigurert ved hjelp av MAINCTL option-16 fra kildenoden, og dette forplanter også disse filene til målnodene, som er IASPS-, ISRCIOA- og IMAGE-filene i STM-installasjonsbibliotekene EMCCTL og EMCCTLC. Disse filene kan vises også, det vil si med DSPPFM EMCCTL / IMAGE. Filene inneholder informasjon om disker og diskadaptere som brukes til iASP-konfigurasjonen. Adapter-ID-er og diskserienumre lagres i disse filene og brukes i STM-operasjoner.

Nå bør du vurdere virkningen av en serienummerendring som skjer når NDM-forfalskningsoperasjonen utføres. STM-konfigurasjonsfilene inneholder fortsatt serienumrene til den gamle disken. De fleste STM-operasjoner fungerer ikke lenger før disse konfigurasjonsfilene er oppdatert. Oppdatering og overføring av disse filene kan gjøres ved å følge samme prosess som under den første STM-installasjonen når MAINCTL>Option-16 (konfigurer iASP) kjøres mens iASP-diskene blir gjort tilgjengelig for målnodene i respektive PATH-STEP. Når disse filene er oppdatert, fungerer STM iASP-operasjoner som forventet igjen. Hvis det oppstår problemer, bør du vurdere å bare kjøre en installasjon av STM på nytt for kilde- og målnodene, inkludert alternativ-16 for å konfigurere iASP PATH's/STEP's og opprette eller overføre STM-konfigurasjonsfilene.

Registrerte brukere med en Dell Support-konto kan se SRDF/TimeFinder Manager for IBM i for mer relevant informasjon om disse STM-utgavene.

Betraktninger for neste IPL etter tilbakestilling av enhetsidentitet, også kjent som "unspoof"-operasjon
NDM unspoof-operasjonen endrer diskserienumrene. Dette kan bare gjøres når IBMi LPAR er nede. Når denne operasjonen utføres etter overføringen i et planlagt, frakoblet vedlikeholdsspor, må du ta hensyn til. Aktiveringen av IBMi LPAR styres fra IBM PowerServer Hardware Management Console (HMC), HMC gir hypervisorfunksjonen for IBM PowerVM-virtualiseringen. På denne HMC har hver LPAR minst en LPAR-profil med detaljer om LPAR-konfigurasjonen, det vil si CPU/MEM, adaptere osv. Når LPAR er IPL-ed (IPL = Initial Program Load = boot sequence) for første gang, leser den konfigurasjonsdetaljene fra den valgte profilen. En spesiell fane i profilen heter "Tagged I / O."  De kodede I/O-innstillingene definerer hvor LPAR-en må søke etter lastkilden (LS) (= bootdisk) under en B-type IPL, og etter den "alternative omstartsenheten" under en IPL av D-typen, det vil si DVD eller kassett. Hvis LPAR har lykkes IPL-ed for første gang, trenger den ikke å lese profilen igjen, da den siste IPL-informasjonen blir lagret på hypervisoren. Ved neste IPL brukes standardinnstillingen "gjeldende konfigurasjon", med mindre LPAR-profilen er valgt spesifikt igjen. Hvis det er spesifikke endringer for LS-kontrolleren eller for LS-diskdetaljene mellom IPL-ene, godtar ikke LPAR den endrede LS-disken, og IPL mislykkes. Dette skjer, hvis: LPAR aktiveres med alternativet "gjeldende konfigurasjon", eller hvis den merkede I/O-adapteren er satt til "ingen". Endringen av LS-diskens serienummer er en slik endring at LPAR ikke godtar det, og hvor en aktivering med riktig profil valgt er nødvendig.

Skjermbildet nedenfor viser den tradisjonelle HMC LPAR-profilvisningen med en gyldig LS-adapter valgt:

Bildet nedenfor viser den samme informasjonen i den moderne versjonsvisningen av HMC v10 med VIOS 3.x /4.x.

 

Du finner annen nyttig informasjon i PowerMax og VMAX: Anbefalte fremgangsmåter og driftsveiledning for ikke-forstyrrende og minimalt forstyrrende migrering

======================================================================================

PRAKTISK IBMi NDM-prosedyre:

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

Bare umaskerte enheter kan forfalskes, så først må du registrere og lagre detaljene i gjeldende maskeringsvisning, deretter slette MV-en, fjerne forfalskning og deretter opprette MV-en på nytt.

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

Vis detaljer om diskidentitet:

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

For en enkelt enhet:

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

For en rekke enheter:

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>

Kontroller at LS-kontrolleren er satt til riktig FC-adapter

i kategorien "Tagged I/O" i LPAR-profilen i "Tagged I/O".IKKE la innstillingen for "Tagged I/O" LS-kontrolleren stå tom med "none" valgt.

IPL med B-Normal-alternativet og velg LPAR-profilen for IPL, IKKE la det være standardalternativet "gjeldende konfigurasjon."

Nå IPL LPAR og etter at systemet er tilbake på nettet, bekrefter du diskserienumrene fra SST.

De serielle ID-ene skal nå gjenspeile de nye matrisene symdev ID og array-serienummer.

=== End of Procedure ===