Procedura di migrazione SRDF IBMi

Quando i clienti eseguono le partizioni logiche (LPAR) del client IBMi sullo storage su disco esterno DELL EMC VMAX/PMAX e desiderano aggiornare l'array corrente a una nuova generazione, possono sfruttare SRDF per eseguire una migrazione dei dati in background e il cutover sul nuovo array con un impatto minimo sui downtime. Questo utilizzo di SRDF viene anche definito SRDF/Data Mobility.
Per i clienti in cui non è consentito alcun downtime, consultare un altro articolo che descrive IBMi Non-Disruptive Migration (NDM) for VMAX/PMAX, disponibile a questo link:
https://www.dell.com/support/kbdoc/en-us/000193832/vmax-powermax-non-disruptive-migrations-for-the-ibmi-host-platform

Per qualsiasi LPAR IBMi, TUTTI i volumi devono essere inclusi nella replica SRDF. Ciò include il source di carico (=bootdisk), a causa della diversa natura della piattaforma IBMi con la sua progettazione LIC/OS univoca basata sul design dell'architettura di storage a livello singolo AS/400. Per qualsiasi replica di storage IBMi, è ALL o NOTHING. Vedere la figura seguente per la descrizione della configurazione (temporanea) durante la migrazione.

I VECCHI e i NUOVI array di origine in PROD-DC sono connessi con collegamenti SRDF temporanei per la migrazione. In genere, anche questi vengono eseguiti attraverso gli switch SAN, quindi è necessario suddividerli in zone di conseguenza. Le alternative sono una configurazione di "connessione diretta" oppure i clienti possono utilizzare collegamenti IP Gige (connessioni Gigabit Ethernet tramite switch LAN).


Mentre le LPAR IBMi rimangono operative, vengono create le relazioni SRDF tra i VECCHI e i NUOVI array. Il processo di sincronizzazione asincrona in background di tutti i dati dei volumi è trasparente per l'host IBMi e le relative applicazioni. È necessario creare nuove connessioni SAN dalle fabric SAN esistenti al nuovo array. Per le schede host IBMi FC o vFC esistenti, lo zoning SAN deve essere configurato di conseguenza. Quando le nuove connessioni e la suddivisione in zone sono pronte, verificare sul nuovo PMAX che le WWPN dell'adattatore IBMi stiano effettuando l'accesso alle rispettive porte FA sul nuovo PMAX.

NOTA BENE: Per la piattaforma IBMi, è necessario utilizzare solo la suddivisione in zone SAN "single-initiator>single-target".

NOTA BENE: Convalidare l'accesso WWPN dell'adattatore IBMi da Unisphere o con il comando SymCLI (esempio): symaccess -sid 123 list logins -dirport 1c:0
======================================================================================================
Fase di preparazione (comandi di esempio):

controllare la connettività SRDF dal NUOVO array con il comando symsan SymCLI:

symsan list -sanrdf -sid 000420200123 -dir ALL -port ALL

Creare i nuovi dispositivi di destinazione IBMi sul nuovo array e aggiungerli a un nuovo StorageGroup (SG):

symdev create -sid 123 -tdev -emulation as400 -cap 82400 -captype cyl -N 64 -v -nop
symsg -sid 123 create sg_ibmi_lpar1_asp1_1 -srp SRP_1 -slo diamond
symaccess -sid 123 -name sg_ibmi_lpar1_asp1_1-type storage add devs 100-13F

Creare i rispettivi InitiatorGroup (IG) e PortGroup (PG) sul NUOVO array:

symaccess -sid 123 create -name ig_ibmi_lpar1_asp1_1 -type init
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init set ig_flags on OS2007 -disable
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde2
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde4
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde6
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde8
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde3
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde5
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde7
symaccess -sid 123-name ig_ibmi_lpar1_asp1_1 -type init add -wwn 0123456789abcde9

symaccess -sid 123 create -name pg_ibmi_lpar1_asp1_1 -type port -protocol SCSI_FC
symaccess -sid 123-name pg_ibmi_lpar1_asp1_1 -type port add -dirport 1c:0
symaccess -sid 123-name pg_ibmi_lpar1_asp1_1 -type port add -dirport 1c:1
symaccess -sid 123-name pg_ibmi_lpar1_asp1_1 -type port add -dirport 2c:0
symaccess -sid 123-name pg_ibmi_lpar1_asp1_1 -type port add -dirport 2c:1

Creare un nuovo gruppo SRDF dinamico temporaneo tra il VECCHIO e il NUOVO array:

symrdf addgrp -sid 000420200123 -rdfg 100 -remote_sid 000 000297800456 -remote_rdfg 100 -dir 1D:03,2D:03,1D:07,2D:07 -remote_dir 1E:03,2E:03,1E:07,2E:07 -label LPAR1_MIG

Eseguire CreatePair per il rispettivo (SG) e avviare la sincronizzazione in modalità Adaptive Copy Disk:

symrdf createpair -sid 456 -type R1 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 -remote_sg sg_ibmi_lpar1_asp1_1 -establish -rdf_mode acp_disk

Monitorare il processo di sincronizzazione:

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

A causa della natura dello stato del link SRDF di "copia adattiva", con I/O attivi ancora in arrivo nell'array di origine dall host IBMi, i link potrebbero non raggiungere uno stato "sincronizzato", come previsto.
Quando il processo di sincronizzazione ha copiato la maggior parte dei dati nel nuovo array (meno di 1.000 registrazioni delle modifiche non valide in sospeso), il cutover offline può essere eseguito in base alla finestra di manutenzione pianificata dal cliente. Si consiglia di pianificare un'interruzione dell'attività di 2 ore delle app aziendali sugli host di cui viene eseguita la migrazione. Ciò dovrebbe fornire un tempo adeguato per l'arresto dei processi dell'applicazione e delle sessioni utente, lo spegnimento del sistema, l'esecuzione del cutover, l'IPL del sistema e il riavvio dei processi e dei sottosistemi dell'applicazione.
 
Fase di cutover (comandi di esempio):

Controllare i collegamenti SRDF e gli stati delle coppie di dispositivi:

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Applicazioni finali, sottosistemi e utenti attivi sulla LPAR.
PWRDWNSYS la LPAR.
Monitorare l'HMC per verificare che la partizione logica sia inattiva nello stato "Not Activated".

Impostare i collegamenti SRDF in modalità SYNC.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 set mode sync

Monitorare le modifiche di stato fino a quando tutti i dispositivi non vengono "sincronizzati" con zero percorsi non validi.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Dividere i link SRDF.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 split

NOTA: Il processo di suddivisione SRDF lascia invariati i volumi di origine durante l'ulteriore processo di migrazione. Questa immagine di origine SRDF precedente contiene una copia "point-in-time" coerente dei dati LPAR dal momento in cui è stata eseguita la divisione. Poiché la partizione logica IBMi era inattiva durante la suddivisione, questa immagine è coerente al 100%. In uno stato split, le copie R1 e R2 vengono RW_enabled per l'host. Questa immagine R1 sull'array OLD può essere utilizzata per un fallback immediato sull'array OLD. Nel caso in cui si verifichino problemi imprevisti e la migrazione venga annullata. In tal caso, è necessario ripristinare la suddivisione in zone/il masking nell'array OLD.

Dopo la suddivisione, monitorare la modifica dello stato.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Creare un backup del VECCHIO database di masking dell'array.

Symaccess -sid 456 list view -v -detail>masking-456_<date>.txt

Eliminare il masking dell'array OLD per la rispettiva LPAR IBMi.

Symaccess -sid 456 delete view mv_ibmi_lpar1_asp1_1

Creare NUOVO masking di array.

symaccess -sid 123 create view -name mv_ibmi_lpar1_asp1_1 -sg sg_ibmi_lpar1_asp1_1 -pg pg_ibmi_lpar1_asp1_1 -ig ig_ibmi_lpar1_asp1_1

Attivare nuovamente la LPAR dall'HMC con la normale modalità B-IPL.
Monitorare il processo IPL dall'HMC.

Nella schermata di accesso, accedere con l'autorizzazione di accesso SST. Eseguire STRSST e controllare lo stato dei dischi e dei percorsi dei dischi. Prendere nota della modifica del numero di serie del disco IBMi che riflette i nuovi volumi dell'array e l'ID seriale.

Il team di amministrazione del cliente/delle app può ora riprendere tutte le normali operazioni su questa LPAR.

La migrazione è completata.


Fase post-migrazione (comandi di esempio):

Quando il cliente ha dichiarato un cutover riuscito (non è richiesto alcun fallback), la configurazione temporanea può essere pulita.

Pulizia dell'associazione di dispositivi di migrazione SRDF.

symrdf deletepair -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1

symrdf removegrp -sid 000420200123 -rdfg 100

Pulizia dello zoning SAN sui rispettivi switch:
Dall'host IBMi all'array OLD.
Rimuovere le zone SRDF dal VECCHIO al NUOVO array (al termine dell'ultima migrazione).