VMAX, PowerMax: Migrace bez přerušení pro hostitelskou platformu IBMi

Prostředí pro podporu:
NDM pro IBMi je k dispozici pro podporované hostitelské systémy IBMi, které jsou připojené k polím VMAX nebo PowerMax se systémem PowerMaxOS verze 5978.444.444 nebo novější.

Pro logické oddíly IBMi (LPAR) spuštěné na platformě IBM Power Server Power6 nebo novější a s operačním systémem IBMi verze i6.1.1 nebo novější. Obecná matice podpory VMAX nebo PowerMax e-Lab obsahuje podrobnosti a seznam podporovaných adaptérů Fibre Channel (FC) IBMi I/O (IOA), neboli adaptérů hostitelské sběrnice (HBA). Migrace bez přerušení je podporována také v případě, že je platforma IBMi klientským oddílem LPAR s virtuálními zdroji I/O přiřazenými ze serveru IBM VIOS (Virtual I/O Server). Díky funkci IBM VIOS/VFC (NPIV) jsou klientským oddílům LPAR přiřazeny virtuální adaptéry FC (vFC) pro připojení k diskovému poli pomocí podporovaných přepínačů SAN.

Systémy vFC fungují jako průchozí modul pro konektivitu hostitelského disku. Na straně hostitele je tato možnost zcela transparentní a všechny podporované funkce z diskového pole jsou k dispozici také v nastavení virtualizovaného adaptéru.

Scénář migrace na pozadí a na vysoké úrovni:
Nástroj Symmetrix Remote Data Facility (SRDF) byl vyvinut na počátku 90. let 20. století jako replikační technologie zotavení po havárii (DR) pro pole podnikových úložišť Dell. Používá se také po mnoho let k provádění migrace na bázi úložiště z jednoho pole do druhého. To znamená, že při aktualizaci technologie pomocí nasazení nového diskového pole se připojí STARÉ a NOVÉ diskové pole typu „back-to-back“ a zkopírují se datové svazky. I když je proces kopírování svazků nebo logických jednotek (LUN) pomocí SRDF transparentní pro připojené hostitelské systémy, tradičně vždy vyžadoval krátké offline okno "cut-over" po dokončení procesu kopírování ze zdrojových svazků (R1). Cílové (nové) svazky (R2s) byly povoleny pro čtení / zápis a připojení FC hostitelských systémů byla směrována na nové pole (prostřednictvím zónování a maskování sítě SAN). 

Funkce SRDF/Metro byla zavedena do řady diskových polí VMAX All Flash. SRDF/Metro poskytuje skutečný přístup typu aktivní/aktivní hostitel ke zdrojovým (R1) a cílovým (R2) svazkům z obou polí. Funkce SRDF/Metro funguje s podporovanými hostitelskými ovladači Multi-Path pro přístup k disku. To zahrnuje nativní ochranu IBMi DMP (Dynamic Multi Path) pro cesty k diskům. Funkce IBMi DMP automaticky zjistí, zda ke stejnému diskovému zařízení vede více cest FC. Poskytuje také základní, ale efektivní schéma vyrovnávání zatížení na způsob kruhového dotazování, které umožňuje rozšířit zatížení I/O disku na dostupné cesty adaptéru FC. Funkce IBMi DMP zajišťuje automatické přepnutí cesty v případě selhání připojení pomocí přesměrování operace I/O disku na jednu ze zbývajících aktivních cest. Po obnovení selhávajících připojení IBMi tyto cesty automaticky obnoví a začne do těchto cest znovu odesílat vstupně-výstupní operace disku.

Nástroj NDM s možností METRO a předkopírováním vychází ze základní technologie SRDF/Metro a poskytuje současný přístup ke starému i novému úložišti.

Fáze CREATE:
Při vytvoření páru zařízení pro replikaci SRDF/Metro (R1>R2) se zobrazí stejná identita zařízení R1 ze zařízení R2 v cílovém poli. V podstatě se z obou zařízení zobrazí stejné sériové ID disku a název WWPN zařízení. Zpočátku je nové zařízení R2 ve stavu AA-NR/DEV-INACT (Active/Active-Not Ready/ Device Inactive). Jakmile je pár zařízení R1>R2 synchronizován, může přejít do stavu aktivní/aktivní povolením přístupu pro čtení a zápis ke svazku R2.

READY_TARGET fáze:
Pokud je nyní povolena cesta z databáze IBMi LPAR k zařízení R2 (zónování sítě SAN je již zavedeno a maskování pro nové pole je aktivováno příkazem NDM readytgt), hostitel IBMi zjistí nové cesty FC ke stávajícímu diskovému zařízení. Ve scénáři IBMi NDM jsou prezentována aktivní/aktivní zařízení R1 + R2.

Fáze odevzdání:
Odebráním přístupu k zařízením R1 nyní hostitel IBMi ztratí přístup k cestám starého pole, ale nadále běží na zařízeních R2 pomocí cest k novému poli. Poté je možné zónování sítě SAN na staré pole odebrat. V systému IBMi by měl být spuštěn nástroj "reset multipath", aby se přestaly používat staré neaktivní cesty a také aby se zastavily všechny chybové zprávy spojené s těmito nyní "chybějícími" cestami. Může to trvat Initial Program Load (IPL) neboli restart, aby se trvale odstranily staré neaktivní cesty a související hardwarové zdroje disku DMPxxx z databáze konfigurace zařízení hostitelů IBMi (IBMi storage management information repository), ale nejedná se o povinné IPL, může také počkat na další plánované IPL. Postup demontáže těchto "zastaralých" zařízení: Nástroj STRSST>Start Service Manager>Hardware Service Manager>selhal a nehlásí hardware: Vyberte všechny staré diskové zdroje DMPxxx k odebrání pomocí možnosti 4 a potvrďte to stisknutím klávesy Enter.

Co je třeba zvážit při používání nástroje Dell STM
Úložiště PowerMax STM, často označované také jako "storage copy services toolkit" pro řízení replikace IBMi pro VMAX, běží jako nativní softwarová aplikace na jednom nebo více hostitelích IBMi. Může řídit vzdálenou replikaci pro podporované konfigurace SRDF a místní replikaci pro snapshoty SnapVX v polích VMAX a PowerMax. STM se dodává ve dvou variantách: Edice Standard Features a edice Extended Features.

STM používá in-band komunikaci s diskovým polem napříč FC trasami, používá malá vyhrazená zařízení, také zmiňovaná jako gatekeepery pro svá systémová volání. Gatekeepery pro IBMi jsou speciální malá zařízení typu D910 GK, která zůstávají v sekci nenakonfigurovaných diskových jednotek. Tyto servery gatekeeper nepodporují funkci Multipath, více serverů gatekeeper s jednou cestou je obvykle prezentováno na stejné redundantní sadě cest, které se používají pro běžné disky ASP1. Doporučuje se používat minimálně čtyři gatekeepery. Servery gatekeeper nejsou součástí procesu migrace NDM, proto se po migraci odebere přístup ke strážcům brány ze starého pole a zobrazí se noví gatekeeper z nového pole.

Standardní vlastnosti:
To platí pro systémy, které používají pouze konfiguraci úložiště *SYSBAS. *SYSBAS znamená systémový ASP1 + všechny další uživatelské ASP (ASP 2-32). Nástroj STM je nainstalován pouze ve zdrojovém uzlu a řídí replikační páry pro všechny disky v *SYSBAS jako jednu nedělitelnou entitu.  Když dojde ke změnám v základní konfiguraci disku; To znamená, že změny sériových čísel disku způsobené operací "unspoofing" NDM, stačí na zdrojovém hostiteli IBMi provést příkaz STM DISCOVER. Až se zobrazí servery gatekeeper z nového pole, spusťte možnost DISCOVER. Tím se aktualizuje místní databáze symapi v integrovaném systému souborů (IFS) na hostiteli (location= /var/symapi/db). Na obrazovkách modulu STM se nyní zobrazují také sériová čísla nových disků. V případě, že se při párování zařízení pro replikaci v nástroji STM vyskytnou nějaké problémy, je také možné použít možnost instalace pouze k zahájení s novým nastavením konfigurace. Nemá to žádný vliv na nastavení párování replikace, které je již nakonfigurováno v diskovém poli VMAX-PowerMax. Pro čistou pomocnou instalaci/nastavení nejprve zdokumentujte související CESTY a KROKY v aktuální konfiguraci (GO MAINCTL>1, IMAGES>vyberte možnost 2, pro bitovou kopii> SYSTEM vytvořte snímek obrazovky pro obrazovku PATHS podle následujícího příkladu:

Ukončete nástroj STM a odstraňte složku /var/symapi a její podsložky. Odstraňte knihovnu EMCCTL. Spusťte STM, nainstalujte program znovu. Spusťte příkaz CRTSYMAPI. GO MAINCTL, znovu přidružte stejné CESTY, jaké byly nakonfigurovány dříve. Nástroj STM nyní detekuje a zobrazuje stav aktivního párování replikace z diskového pole VMAX-PowerMax. Provoz STM je připraven k okamžitému obnovení.

Rozšířené funkce:
To se používá pro systémy, které používají nastavení clusteru IBMi PowerHA s jedním nebo více "přepínatelnými" iASP (nezávislé ASP). V tomto scénáři se replikuje pouze iASP a tento iASP nebo jeho repliky lze prezentovat uzlům v clusteru PowerHA. Každý uzel clusteru je již aktivní sám o sobě *SYSBAS (ASP1). IASP je konfigurován jako přepínatelný prostředek v doméně zařízení sdíleného clusteru. V clusteru jsou obvykle dva nebo čtyři uzly. To je podle níže uvedeného příkladu diagramu pro cluster se 4 uzly s produkčním uzlem jako zdrojem a se vzdáleným cílovým uzlem zotavení po havárii a záložním uzlem SnapVX na obou stranách:

K použití iASP nebo jeho replik není vyžadováno žádné IPL z žádného uzlu. Když jsou disky iASP prezentovány libovolnému uzlu v clusteru, je vyžadován příkaz VARY ON, aby byly iASP tomuto uzlu k dispozici. V nastavení PowerHA je zdrojová verze STM nainstalována na zdrojovém uzlu (v knihovně EMCCTL). Na všech ostatních uzlech (cílová replika SRDF nebo SnapVX) se nainstaluje cílová verze (v knihovně EMCCTLC). Vzhledem k tomu, že jsou aktivní všechny uzly, jsou do STM integrovány závislosti a kontroly a rovnováhy pro určité operace v tomto nastavení, které zakazují odebrání přístupu k disku uzlu, pokud je iASP pro daný uzel stále ve stavu VARY ON. Pro komunikaci mezi uzly běží v subsystému EMCCTL na všech uzlech úloha serveru STM. Tato úloha komunikuje v rámci uzlů napříč IP rozhraními clusteru. Typické operace STM lze spustit z libovolného uzlu v clusteru. To vyžaduje, aby na každém uzlu byla k dispozici sada stejných disků STM, adaptérů a konfiguračních souborů cesty. Během počátečního nastavení STM for PowerHA jsou tyto soubory konfigurovány pomocí možnosti MAINCTL 16 ze zdrojového uzlu, což také šíří tyto soubory do cílových uzlů, což jsou soubory IASPS, ISRCIOA a IMAGE v instalačních knihovnách STM EMCCTL a EMCCTLC. Tyto soubory lze také zobrazit, tj. pomocí DSPPFM EMCCTL/IMAGE. Soubory obsahují informace o discích a diskových adaptérech použitých pro konfiguraci iASP. ID adaptéru a sériová čísla disků jsou uložena v těchto souborech a používají se při operacích STM.

Nyní zvažte dopad změny sériového čísla disku, ke které dojde po dokončení operace zrušení spoofingu NDM. Konfigurační soubory modulu STM stále obsahují stará sériová čísla disků. Většina operací STM již není funkční, dokud nejsou tyto konfigurační soubory aktualizovány. Aktualizace a šíření těchto souborů lze provést stejným postupem jako při počáteční instalaci STM, když je spuštěna možnost MAINCTL>16 (configure iASP), zatímco jsou disky iASP zpřístupněny cílovým uzlům v příslušném kroku PATH. Po aktualizaci těchto souborů operace STM iASP opět fungují podle očekávání. Pokud se vyskytnou nějaké problémy, zvažte opětovné spuštění pouze pomocné instalace STM pro zdrojový a cílový uzel, včetně možnosti 16 pro konfiguraci iASP PATH's/STEP a vytvoření nebo šíření konfiguračních souborů STM.

Registrovaní uživatelé s účtem podpory Dell mohou zobrazit další relevantní informace o těchto edicích STM v nástroji SRDF/TimeFinder Manager for IBM i .

Důležité informace o dalším IPL po resetování identity zařízení, neboli operaci
"unspoof"Operace zrušení podvržení NDM změní sériová čísla disků. To lze provést pouze v případě, že je IBMi LPAR mimo provoz. Pokud se tato operace provádí po migraci v plánovaném slotu offline údržby, je třeba vzít v úvahu několik aspektů. Aktivace IBMi LPAR je řízena z IBM PowerServer Hardware Management Console (HMC), HMC poskytuje funkci Hypervisor pro virtualizaci IBM PowerVM. V tomto řadiči HMC má každá služba LPAR alespoň jeden profil LPAR s podrobnostmi o konfiguraci protokolu LPAR, tj. CPU/MEM, adaptérech atd. Když je LPAR poprvé IPL-ed (IPL = Initial Program Load = bootovací sekvence), načte podrobnosti o konfiguraci z vybraného profilu. Speciální karta v profilu se nazývá "Tagged I/O".  Označená nastavení I/O definují, kde má LPAR hledat zdroj zátěže (LS) (= bootdisk) během IPL typu B a "alternativní restartovací zařízení" během IPL typu D, tj. DVD nebo kazetu. Pokud LPAR úspěšně provedl IPL-ed poprvé, nemusí znovu číst profil, protože poslední informace o IPL se uloží do hypervisoru. Při dalším IPL se použije výchozí nastavení "aktuální konfigurace", pokud není profil LPAR znovu specificky vybrán. Pokud mezi IPL dojde ke specifickým změnám řadiče LS nebo detailů disku LS, LPAR nepřijme změněný disk LS a IPL selže. K tomu dochází, pokud: Paměť LPAR se aktivuje s možností "current configuration" nebo pokud je označený adaptér I/O LS nastaven na hodnotu "none". Změna sériového čísla disku LS je natolik velká, že ji LPAR nepřijme a je nutná aktivace se správným vybraným profilem.

Níže uvedený snímek obrazovky ukazuje tradiční zobrazení profilu HMC LPAR s vybraným platným adaptérem LS:

Níže uvedený obrázek ukazuje stejné informace v zobrazení moderní verze HMC v10 s VIOS 3.x /4.x.

 

Další užitečné informace jsou obsaženy v PowerMax a VMAX: Vzorové postupy a provozní příručka

k migraci bez přerušení a minimálně======================================================================================

PRAKTICKÝ postup IBMi NDM:

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

Pouze nemaskovaná zařízení lze zfalšovat, takže nejprve zaznamenejte a uložte podrobnosti aktuálního maskovacího zobrazení, poté odstraňte MV, zrušte zfalšování identity a pak znovu vytvořte MV.

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

Zobrazení podrobností o identitě disku:

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

Pro jedno zařízení:

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

Pro řadu zařízení:

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>

Ověřte na portálu IBM HMC, že v profilu LPAR na kartě "Tagged I/O" je řadič LS nastaven na správný adaptér FC.

NENECHÁVEJTE nastavení řadiče LS "Tagged I/O" prázdné s vybranou možností "none".

IPL s možností B-Normal a vyberte profil LPAR pro IPL, NENECHÁVEJTE to na výchozí možnosti "aktuální konfigurace".

Nyní spusťte IPL LPAR a poté, co je systém opět online, ověřte sériová čísla disků z SST.

Sériová ID by nyní měla odpovídat symdev ID nového pole a sériovému číslu pole.

=== End of Procedure ===