VMAX, PowerMax: Avbrottsfri migrering för IBMi-värdplattformen

Miljö för support:
NDM för IBMi är tillgängligt för IBMi-värdsystem som stöds och som är anslutna till VMAX- eller PowerMax-disksystem som kör version 5978.444.444 eller senare av PowerMaxOS.

Detta är för IBMi logiska partitioner (LPAR) som körs på IBM Power Server-plattformen Power6 eller senare och kör IBMi-operativsystemet version i6.1.1 eller senare. Den allmänna stödmatrisen för VMAX eller PowerMax e-Lab innehåller information och en lista över de Fibre Channel (FC) IBMi I/O-adaptrar (IOA) som stöds, även kallade HBA-värdbussadaptrar. NDM stöds också när IBMi är en klient-LPAR med tilldelade virtuella I/O-resurser från en IBM Virtual I/O Server (VIOS). Med funktionen IBM VIOS/VFC (NPIV) tilldelas virtuella FC-adaptrar (vFC) till klientens LPAR:er för anslutning till lagringsmatrisen med hjälp av SAN-switchar som stöds.

vFC:er fungerar som ett vidarekopplingsprotokoll för värddiskanslutningen. Från värdsidan är detta helt transparent och alla funktioner som stöds från lagringsdisksystemet är även tillgängliga i den virtualiserade adapterkonfigurationen.

Scenario för migrering på bakplan och hög nivå:
Symmetrix Remote Data Facility (SRDF) utvecklades i början av 1990-talet som en replikeringsteknik för katastrofåterställning (DR) för Dell Enterprise-lagringsdisksystem. Den har också använts i många år för att utföra lagringsbaserade migreringar från ett disksystem till ett annat. Det innebär att du kopplar ihop det GAMLA och det nya disksystemets "rygg mot rygg" och kopierar datavolymerna när du utför en teknikuppdatering genom att implementera ett nytt lagringsdisksystem. Även om SRDF-kopieringsprocessen för volymerna eller de logiska enheterna (LUN) är transparent för de anslutna värdsystemen, har det traditionellt alltid krävts ett kort "cut-over"-offlinefönster när kopieringsprocessen slutfördes från källvolymerna (R1). Målvolymerna (nya) (R2) var läs-/skrivaktiverade och värdsystemens FC-anslutningar riktades (via SAN-zonindelning och maskering) till det nya disksystemet. 

SRDF/Metro introducerades med VMAX All Flash-serien för lagringsdisksystem. SRDF/Metro ger äkta aktiv/aktiv värdåtkomst till käll- (R1) och mål- (R2) volymerna från båda disksystemen. SRDF/Metro fungerar med värddrivrutiner med flera sökvägar som stöds för diskåtkomst. Detta inkluderar det inbyggda IBMi Dynamic Multi Path (DMP)-skyddet för disksökvägar. IBMi DMP identifierar automatiskt om det finns flera FC-sökvägar till samma diskenhet. Det ger också ett grundläggande men effektivt belastningsutjämningsschema för resursallokering för att sprida diskens I/O-arbetsbelastning över de tillgängliga FC-adaptersökvägarna. IBMi DMP ger automatisk sökvägsredundans när anslutningar kan misslyckas genom att omdirigera diskens I/O-åtgärd till en av de återstående aktiva sökvägarna. När misslyckade anslutningar återställs återställer IBMi automatiskt dessa sökvägar och börjar skicka disk-I/O till dessa sökvägar igen.

NDM med METRO- och förkopieringsalternativ baseras på den underliggande SRDF/Metro-tekniken för att ge samtidig åtkomst till den gamla och den nya lagringsenheten.

SKAPA-fas:
När ett SRDF/Metro-replikeringsenhetspar (R1>R2) skapas visas samma R1-enhetsidentitet från R2-enheten i måldisksystemet. I princip visas samma diskserie-ID och enhetens WWPN från båda enheterna. Inledningsvis är den nya R2-enheten i tillståndet AA-NR/DEV-INACT (Aktiv/aktiv-Inte redo/Enhet inaktiv). När R1>R2-enhetsparet har synkroniserats kan det försättas i ett aktivt/aktivt läge genom att aktivera läs- och skrivåtkomst till R2-volymen.

READY_TARGET fasen:
När sökvägen från IBMi LPAR till R2-enheten nu är aktiverad (SAN-zonindelning finns redan på plats och maskering för det nya disksystemet aktiveras av NDM readytgt-kommandot) identifierar IBMi-värden nya FC-sökvägar till den befintliga diskenheten. I ett IBMi NDM-scenario visas de aktiva/aktiva R1 + R2-enheterna.

COMMIT-fasen:
Genom att ta bort åtkomsten till R1-enheterna förlorar IBMi-värden nu åtkomsten till det gamla disksystemets sökvägar, men fortsätter att köras på R2-enheterna med hjälp av sökvägarna till det nya disksystemet. När detta är gjort kan SAN-zonindelningen till det gamla disksystemet tas bort. Verktyget "reset multipath" på IBMi-systemet bör köras för att sluta använda de gamla inaktiva sökvägarna och även stoppa eventuella felmeddelanden som är associerade med dessa nu "saknade" sökvägar. Det kan krävas en IPL (Initial Program Load) aka omstart för att permanent ta bort de gamla inaktiva sökvägarna och dess tillhörande DMPxxx-diskhårdvaruresurser från IBMi-värdarnas enhetskonfigurationsdatabas (IBMi-lagringsinformationslager för lagringshantering), men detta är inte en obligatorisk IPL, det kan också vänta till nästa planerade IPL. För borttagning av dessa "inaktuella" enheter: STRSST>Starta Service Tool>Hardware Service Manager>Misslyckades och icke-rapporterande hårdvara: Välj alla gamla diskresurser DMPxxx för borttagning med alternativ 4 och bekräfta det genom att trycka på Enter.

Att tänka på när du använder Dell STM
STM, som ofta kallas "verktygslådan för lagringskopieringstjänster" för IBMi-replikeringskontroll för VMAX, PowerMax-lagring körs som en inbyggd programvara på en eller flera IBMi-värdar. Den kan styra fjärreplikering för SRDF-konfigurationer som stöds och lokal replikering för SnapVX-snapshots på VMAX- och PowerMax-disksystem. STM finns i två smaker: Standardfunktioner och utökade funktioner.

STM använder in-band-kommunikation till lagringsmatrisen över FC-sökvägarna, den använder små dedikerade enheter, som även kallas gatekeepers för sina systemanrop. Portvakterna för IBMi är speciella små enheter av typen D910 GK som finns kvar i avsnittet icke-konfigurerade diskenheter. Dessa gatekeepers stöder inte multipath, flera single-pathed gatekeepers presenteras vanligtvis på samma redundanta uppsättning sökvägar som används för de vanliga ASP1-diskarna. Vi rekommenderar att du använder minst fyra grindvakter. Gatekeepers är inte en del av NDM-migreringsprocessen, vilket innebär att åtkomsten till gatekeepers från det gamla disksystemet tas bort efter migreringen och nya gatekeepers från det nya disksystemet presenteras.

Standard-funktioner:
Detta används för system som endast använder en *SYSBAS-lagringskonfiguration. *SYSBAS avser systemets ASP1 + eventuella ytterligare användar-ASP (ASP 2-32). STM är endast installerat på källnoden och styr replikeringsparen för alla diskar i *SYSBAS som en odelbar enhet.  När ändringar sker i den underliggande diskkonfigurationen; det vill säga ändringar av diskens serienummer som orsakas av NDM-åtgärden "unspoofing", räcker det att utföra STM DISCOVER-kommandot på IBMi-källvärden. Kör alternativet DISCOVER när gatekeepers från den nya matrisen presenteras. Detta uppdaterar den lokala symapi-databasen i det integrerade filsystemet (IFS) på värden (location= /var/symapi/db). STM-skärmarna visar nu även de nya diskserienumren. Om några problem observeras i replikeringsenhetens parkoppling inom STM är det också möjligt att endast använda installationsalternativet för att börja med en ny konfigurationskonfiguration. Detta påverkar inte konfigurationen av replikeringsparkopplingen som redan har konfigurerats på VMAX-PowerMax-lagringsdisksystemet. Om du vill installera och konfigurera en ren scratch dokumenterar du först de associerade sökvägarna och stegen i den aktuella konfigurationen (GO MAINCTL>1, IMAGES>välj alternativ 2 för SYSTEM-avbildningen> och skapa en skärmdump för skärmen PATHS enligt exemplet nedan:

Avsluta STM och ta bort mappen /var/symapi och dess undermappar. Ta bort EMCCTL-biblioteket. Kör STM och installera programmet igen. Kör CRTSYMAPI. GO MAINCTL, associera samma SÖKVÄGAR igen som konfigurerades tidigare. STM identifierar och visar nu status för det aktiva replikeringsparet från VMAX-PowerMax-lagringsdisksystemet. STM-verksamheten är redo att återupptas nu.

Utökade funktioner:
Detta används för system som använder en IBMi PowerHA-klusterkonfiguration med en eller flera "växlingsbara" iASP (oberoende ASP). I det här scenariot replikeras endast iASP och denna iASP eller replikens därav kan presenteras för noderna i PowerHA-klustret. Varje klusternod är redan aktiv på sin egen *SYSBAS (ASP1). iASP är konfigurerad som en växlingsbar resurs i den delade klusterenhetsdomänen. Det finns vanligtvis två eller fyra noder i klustret. Det vill säga enligt exempeldiagrammet nedan för ett kluster med fyra noder med produktionsnoden som källa och med en fjärrnod för katastrofåterställning och en SnapVX-säkerhetskopieringsnod på båda sidor:

Ingen IPL från någon nod krävs för att använda iASP eller dess repliker. När iASP-diskarna presenteras för en nod i klustret krävs kommandot VARY ON för att iASP ska bli tillgänglig för noden. I en PowerHA-konfiguration installeras STM-källversionen på källnoden (i EMCCTL-biblioteket). På alla andra noder (antingen SRDF- eller SnapVX-målrepliker) installeras målversionen (i EMCCTLC-biblioteket). När alla noder är aktiva finns det beroenden och kontroller och saldon inbyggda i STM för vissa åtgärder i den här konfigurationen som det är förbjudet att ta bort diskåtkomst för en nod om iASP fortfarande är i tillståndet VARY ON för noden. För kommunikation mellan noder körs ett STM-serverjobb i EMCCTL-undersystemet på alla noder. Det här jobbet kommunicerar mellan noderna via klustrets IP-gränssnitt. Typiska STM-åtgärder kan köras från valfri nod i klustret. Detta kräver att en uppsättning av samma STM-disk, adaptrar och sökvägskonfigurationsfiler är tillgängliga på varje nod. Under den första installationen av STM för PowerHA konfigureras dessa filer med MAINCTL-alternativet-16 från källnoden och detta sprider även dessa filer till målnoderna, dvs. IASPS-, ISRCIOA- och IMAGE-filerna i STM-installationsbiblioteken EMCCTL och EMCCTLC. Dessa filer kan också visas, det vill säga med DSPPFM EMCCTL/IMAGE. Filerna innehåller information om diskar och diskadaptrar som används för iASP-konfigurationen. Adapter-ID och diskserienummer lagras i dessa filer och används i STM-åtgärderna.

Tänk nu på effekten av en ändring av diskens serienummer som inträffar när NDM-förfalskningsåtgärden är klar. STM-konfigurationsfilerna innehåller fortfarande de gamla diskserienumren. De flesta STM-åtgärder fungerar inte längre förrän dessa konfigurationsfiler har uppdaterats. Uppdatering och spridning av dessa filer kan göras genom att följa samma process som under den första STM-installationen när MAINCTL>Option-16 (konfigurera iASP) körs medan iASP-diskarna görs tillgängliga för målnoderna i respektive PATH-STEP. När dessa filer har uppdaterats fungerar STM iASP-åtgärder som förväntat igen. Om några problem uppstår bör du överväga att bara köra en scratch-installation igen av STM för käll- och målnoderna, inklusive alternativet-16 för att konfigurera iASP-sökvägarna/STEP och skapa eller sprida STM-konfigurationsfilerna.

Registrerade användare med ett Dell-supportkonto kan visa SRDF/TimeFinder Manager för IBM i för ytterligare relevant information om dessa STM-versioner.

Överväganden för nästa IPL efter återställningen av enhetsidentiteten, även kallad "unspoof"-åtgärd
NDM unspoof-åtgärden ändrar diskens serienumren. Detta kan bara göras när IBMi LPAR är nere. När den här åtgärden görs efter migreringen på en planerad offlineunderhållsplats finns det några saker att tänka på. Aktiveringen av IBMi LPAR styrs från IBM PowerServer Hardware Management Console (HMC), HMC tillhandahåller Hypervisor-funktionen för IBM PowerVM-virtualiseringen. På denna HMC har varje LPAR minst en LPAR-profil med information om LPAR-konfigurationen, det vill säga CPU/MEM, adaptrar och så vidare. När LPAR IPL-as (IPL = Initial Program Load = boot sequence) för första gången läser den konfigurationsinformationen från den valda profilen. En särskild flik i profilen kallas "Taggad I/O".  De taggade I/O-inställningarna definierar var LPAR måste söka efter Load Source (LS) (= bootdisk) under en B-type IPL och efter den "alternativa omstartsenheten" under en D-type IPL, det vill säga DVD eller band. Om LPAR har lyckats IPL-ed för första gången behöver den inte läsa proffsetfile igen, eftersom den senaste IPL-informationen lagras på hypervisorn. Vid nästa IPL används standardinställningen "aktuell konfiguration", såvida inte LPAR-profilen specifikt väljs igen. Om det finns specifika ändringar för LS-styrenheten eller för LS-diskdetaljerna mellan IPL:er, accepterar LPAR inte den ändrade LS-disken och IPL misslyckas. Detta händer OM: LPAR aktiveras med alternativet "aktuell konfiguration" eller om den taggade I/O LS-adaptern är inställd på "none". Ändringen av LS-diskens serienummer är en sådan ändring att LPAR inte accepterar den och där en aktivering med rätt profil vald krävs.

Skärmbilden nedan visar den traditionella HMC LPAR-profilvyn med en giltig LS-adapter vald:

Bilden nedan visar samma information i den moderna versionsvyn för HMC v10 med VIOS 3.x /4.x.

 

Annan användbar information finns i PowerMax och VMAX: Bästa praxis och driftsmanual

för migrering utan avbrott och minimalt avbrott======================================================================================

PRAKTISK IBMi NDM-procedur:

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

Endast omaskerade enheter kan avförfalskas, så registrera och spara först informationen om den aktuella maskeringsvyn, ta sedan bort MV, ta bort förfalskningen och återskapa sedan MV.

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

Visa information om diskidentitet:

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

För en enskild enhet:

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

För en rad olika 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>

Kontrollera från IBM HMC att i LPAR-profilen, på fliken "Tagged I/O", att LS-styrenheten är inställd på rätt FC-adapter.

Lämna INTE inställningen "Tagged I/O" LS controller tom med "none" valt.

IPL med B-Normal-alternativet och välj LPAR-proffsetfile för IPL, lämna det INTE till standardalternativet "aktuell konfiguration".

IPL nu LPAR och efter att systemet är online igen, verifiera diskens serienummer från SST.

Serie-ID:n bör nu återspegla det nya disksystemets symdev-ID och disksystemets serienummer.

=== End of Procedure ===