Procédure de migration d’IBMi SRDF

Lorsque les clients exécutent leurs partitions logiques (LPAR) du client IBMi sur un stockage sur disque externe DELL EMC VMAX/PMAX et souhaitent actualiser leur baie actuelle vers une nouvelle génération, ils peuvent utiliser SRDF pour exécuter une migration des données en arrière-plan et un basculement vers la nouvelle baie avec un impact minimal sur les temps d’arrêt. Cette utilisation de SRDF est également appelée SRDF/mobilité des données.
Pour les clients pour lesquels aucun temps d’arrêt n’est autorisé, reportez-vous à un autre article décrivant IBMi Non-Disruptive Migration (NDM) for VMAX/PMAX, disponible sur ce lien :
https://www.dell.com/support/kbdoc/en-us/000193832/vmax-powermax-non-disruptive-migrations-for-the-ibmi-host-platform

Pour toute LPAR IBMi, TOUS les volumes doivent être inclus dans la réplication SRDF. Cela inclut la source de chargement (=bootdisk), en raison de la nature différente de la plate-forme IBMi avec sa conception unique LIC/OS basée sur la conception architecturale de stockage à niveau unique AS/400. Pour toute réplication de stockage IBMi, c’est TOUT ou RIEN. Reportez-vous à la figure ci-dessous pour obtenir la description de la configuration (temporaire) lors de la migration.

Les baies sources OLD et NEW dans PROD-DC sont connectées avec des liens SRDF temporaires pour la migration. Ceux-ci s’exécutent généralement également via les commutateurs SAN, ils doivent donc être zonés en conséquence. Les alternatives sont une configuration « connexion directe » ou les clients peuvent utiliser des liaisons IP Gige (connexions Gigabit Ethernet via des commutateurs LAN).


Alors que les LPAR IBMi restent opérationnelles, les relations SRDF entre les anciennes et nouvelles baies sont créées. Le processus de synchronisation asynchrone en arrière-plan de toutes les données des volumes est transparent pour l’hôte IBMi et ses applications. Vous devez créer de nouvelles connexions SAN entre les fabrics SAN existants et la nouvelle baie. Pour les adaptateurs hôtes FC ou vFC IBMi existants, le zonage SAN doit être configuré en conséquence. Lorsque les nouvelles connexions et le zonage sont prêts, vérifiez sur le nouveau PMAX que les WWPN de l’adaptateur IBMi se connectent aux ports FA respectifs sur le nouveau PMAX.

REMARQUE : Pour la plate-forme IBMi, seul le zonage SAN « initiateur>unique cible » doit être utilisé.

REMARQUE : Validez la connexion WWPN de l’adaptateur IBMi à partir d’Unisphere ou avec la commande SymCLI (exemple) : symaccess -sid 123 list logins -dirport 1c :0
======================================================================================================
Prepare Phase (exemples de commandes) :

vérifiez la connectivité SRDF à partir de la NOUVELLE baie à l’aide de la commande SymCLI symsan :

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

Créez les nouveaux appareils cibles IBMi sur la nouvelle baie et ajoutez-les à un nouveau groupe de stockage (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

Créez respectivement InitiatorGroup (IG) et PortGroup (PG) sur la NOUVELLE baie :

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

Créez un nouveau groupe SRDF dynamique temporaire entre l’ANCIENNE et la NOUVELLE baie :

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

Effectuez une opération CreatePair pour le (SG) respectif et démarrez la synchronisation en mode Disque de copie évolutive :

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

Surveillez le processus de synchronisation :

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

En raison de la nature de l’état du lien SRDF de « copie évolutive », avec des E/S actives arrivant toujours dans la baie source à partir de l’hôte IBMi, les liens peuvent ne pas atteindre un état « synchronisé », ce qui est normal et attendu.
Lorsque le processus de synchronisation a copié la majeure partie des données sur la nouvelle baie (moins de 1 000 pistes non valides en attente), le basculement hors ligne peut être effectué en fonction de la fenêtre de maintenance planifiée par le client. Nous vous recommandons de prévoir une panne de 2 heures des applications métiers sur le ou les hôtes migrés. Cela doit permettre l’arrêt des tâches d’application et des sessions utilisateur, la mise hors tension du système, l’exécution du basculement, l’IPL du système et le redémarrage des sous-systèmes d’application et des tâches.
 
Phase de basculement (exemples de commandes) :

Vérifiez les liens SRDF et les états des paires d’appareils :

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Applications finales, sous-systèmes et utilisateurs actifs sur LPAR.
PWRDWNSYS la LPAR.
Surveillez la console HMC afin de confirmer que la partition LPAR est arrêtée et définie sur l’état « Not Activated ».

Définissez les liens SRDF en mode SYNC.

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

Surveillez le changement d’état jusqu’à ce que tous les appareils soient « synchronisés » sans aucune piste non valide.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Fractionner les liens SRDF.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 split

Remarque : Le processus SRDF Split laisse les volumes sources intacts et inchangés pendant le processus de migration ultérieur. Cette ancienne image source SRDF contient une copie « instantanée » cohérente des données LPAR à partir de l’heure à laquelle le fractionnement a été effectué. Étant donné que la LPAR IBMi était en panne lors du fractionnement, cette image est cohérente à 100 %. À l’état fractionné, les copies R1 et R2 sont RW_enabled pour l’hôte. Cette image R1 sur l’ANCIENNE baie peut être utilisée pour une solution de secours immédiate vers l’ANCIENNE baie. Si des problèmes inattendus se produisent et annulent la migration. Dans ce cas, le zonage/masquage sur l’ANCIENNE baie doit être rétabli.

Après le fractionnement, surveillez le changement d’état.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Créez une sauvegarde de l’ANCIENNE base de données de masquage de baies.

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

Supprimez l’ANCIEN masquage de baie pour la LPAR IBMi correspondante.

Symaccess -sid 456 delete view mv_ibmi_lpar1_asp1_1

Créez un NOUVEAU masquage de baie.

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

Réactivez le LPAR à partir de la console HMC en mode B-IPL normal.
Surveillez le processus IPL à partir de la console HMC.

Sur l’écran de connexion, connectez-vous avec l’autorisation d’accès SST. Exécutez STRSST et vérifiez l’état des disques et des chemins d’accès aux disques. Notez la modification du numéro de série du disque IBMi qui reflète les nouveaux volumes de baie et l’ID série.

L’équipe d’administration du client/des applications peut désormais reprendre toutes ses opérations normales sur cette LPAR.

La migration est terminée.


Phase de post-migration (exemples de commandes) :

Lorsque le client a déclaré un basculement réussi (aucun retour arrière requis), la configuration temporaire peut être nettoyée.

Nettoyage du couplage des appareils de migration SRDF.

symrdf deletepair -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1

symrdf removegrp -sid 000420200123 -rdfg 100

Nettoyez le zonage SAN sur les commutateurs respectifs :
De l’hôte IBMi à l’ANCIENNE baie.
Et supprimez les zones SRDF de l’ANCIENNE vers la NOUVELLE baie (une fois la dernière migration terminée).