Procedura migracji IBMi SRDF

Jeśli klienci uruchamiają partycje logiczne (LPAR klienta) IBMi na zewnętrznej pamięci dyskowej DELL EMC VMAX/PMAX i chcą odświeżyć bieżącą macierz do nowej generacji, mogą wykorzystać SRDF do przeprowadzenia migracji danych w tle i przejścia do nowej macierzy przy minimalnym przestoju. Takie użycie SRDF jest również określane jako SRDF/Data Mobility.
W przypadku klientów, w których przestoje nie są dozwolone, zapoznaj się z innym artykułem opisującym niezakłócającą migracji IBMi (NDM) dla VMAX/PMAX, który można znaleźć pod tym łączem:
https://www.dell.com/support/kbdoc/en-us/000193832/vmax-powermax-non-disruptive-migrations-for-the-ibmi-host-platform

W przypadku każdej LPAR IBMi replikacja SRDF musi obejmować WSZYSTKIE wolumeny. Dotyczy to również źródła obciążenia (=bootdisk), ze względu na odmienny charakter platformy IBMi z jej unikalną konstrukcją LIC/OS opartą na jednopoziomowej architekturze pamięci masowej AS/400. W przypadku każdej replikacji pamięci masowej IBMi jest to WSZYSTKO albo NIC. Na poniższym rysunku przedstawiono opis (tymczasowej) konfiguracji podczas migracji.

Macierze źródłowe OLD i NEW w kontrolerze domeny PROD-są połączone z tymczasowymi łączami SRDF na potrzeby migracji. Zazwyczaj przechodzą one również przez przełączniki SAN, dlatego należy je odpowiednio podzielić na strefy. Alternatywą jest konfiguracja "direct connect" lub klienci mogą korzystać z łączy Gige IP (połączenia Gigabit Ethernet przez przełączniki LAN).


Podczas gdy LPAR IBMi nadal działają, tworzone są relacje SRDF między macierzami OLD i NEW. Proces asynchronicznej synchronizacji danych wszystkich woluminów w tle jest niewidoczny dla hosta IBMi i jego aplikacji. Należy utworzyć nowe połączenia SAN z istniejących sieci szkieletowej SAN do nowej macierzy. W przypadku istniejących kart hosta IBMi FC lub vFC należy odpowiednio skonfigurować podział na strefy SAN. Gdy nowe połączenia i podział na strefy są gotowe, sprawdź na nowym PMAX, czy WWPN adaptera IBMi logują się do odpowiednich portów FA w nowym PMAX.

UWAGA: W przypadku platformy IBMi należy używać tylko stref SAN "single-initiator-single-target>".

UWAGA: Sprawdź poprawność logowania WWPN karty IBMi z Unisphere lub za pomocą komendy SymCLI (przykład): symaccess -sid 123 list logins -dirport 1c:0
======================================================================================================
Prepare Phase (sample commands):

Sprawdź łączność SRDF z NOWEJ macierzy za pomocą polecenia symsan SymCLI:

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

Utwórz nowe urządzenia docelowe IBMi w nowej macierzy i dodaj je do nowej grupy 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

Utwórz odpowiednio InitiatorGroup(IG) i PortGroup(PG) w NOWEJ macierzy:

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

Utwórz nową tymczasową dynamiczną grupę SRDF między STARĄ i NOWĄ macierzą:

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

Wykonaj CreatePair dla odpowiedniego (SG) i uruchom synchronizację w trybie dysku kopii adaptacyjnej:

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

Monitoruj proces synchronizacji:

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Ze względu na charakter stanu łącza "kopia adaptacyjna" SRDF, gdy aktywne operacje we/wy nadal przychodzą do macierzy źródłowej z hosta IBMi, łącza mogą nie osiągnąć stanu "zsynchronizowanego", jest to normalne i oczekiwane.
Gdy proces synchronizacji skopiuje większość danych do nowej macierzy (mniej niż 1000 zaległych nieprawidłowych ścieżek), przejście do trybu offline można wykonać zgodnie z planowanym przez klienta oknem konserwacji. Zalecamy zaplanowanie 2-godzinnej przerwy w działaniu aplikacji biznesowych na hostach, które są migrowane. Powinno to zapewnić odpowiednią ilość czasu na zatrzymanie zadań aplikacji i sesji użytkownika, wyłączenie systemu, wykonanie przełączenia w sieci, IPL systemu oraz ponowne uruchomienie podsystemów i zadań aplikacji.
 
Faza przełączenia (przykładowe polecenia):

Sprawdź łącza SRDF i stany parowania urządzeń:

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Aplikacje końcowe, podsystemy i aktywni użytkownicy na LPAR.
PWRDWNSYS LPAR.
Monitoruj konsolę HMC, aby upewnić się, że LPAR nie działa w stanie "Nieaktywowany".

Ustaw łącza SRDF w trybie SYNC.

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

Monitoruj zmiany statusu do momentu "zsynchronizowania" wszystkich urządzeń z zerową liczbą nieprawidłowych ścieżek.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Podziel łącza SRDF.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 split

Uwaga: Proces podziału SRDF pozostawia woluminy źródłowe nietknięte i niezmienione podczas dalszego procesu migracji. Ten stary obraz źródłowy SRDF zawiera spójną kopię danych LPAR z punktu w czasie od momentu przeprowadzenia podziału. Ponieważ LPAR IBMi nie działał podczas podziału, ten obraz jest w 100% spójny. W stanie podziału obie kopie R1 i R2 są RW_enabled dla hosta. Ten obraz R1 w macierzy OLD może być używany do natychmiastowego powrotu do macierzy OLD. W przypadku napotkania nieoczekiwanych problemów migracja zostanie anulowana. W takim przypadku należy przywrócić podział na strefy/maskowanie do STAREJ macierzy.

Po podzieleniu monitoruj zmianę stanu.

symrdf -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1 query

Utwórz kopię zapasową bazy danych maskowania STAREJ tablicy.

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

Usuń maskowanie STAREJ macierzy dla odpowiedniego LPAR IBMi.

Symaccess -sid 456 delete view mv_ibmi_lpar1_asp1_1

Utwórz NOWE maskowanie macierzy.

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

Ponownie aktywuj LPAR z konsoli HMC w normalnym trybie B-IPL.
Monitoruj proces IPL z konsoli HMC.

Na ekranie logowania zaloguj się przy użyciu autoryzacji dostępu SST. Uruchom narzędzie STRSST i sprawdź stan dysków oraz ich ścieżek. Zwróć uwagę na zmianę numeru seryjnego dysku IBMi, która odzwierciedla nowe woluminy macierzy i identyfikator szeregowy.

Zespół administratorów klienta/aplikacji może teraz wznowić wszystkie normalne operacje na tym LPAR.

Na tym kończy się migracja.


Faza po migracji (przykładowe polecenia):

Jeśli klient zadeklaruje pomyślne przeniesienie w nowe miejsce (nie jest wymagane rozwiązanie awaryjne), konfiguracja tymczasowa może zostać wyczyszczona.

Czyszczenie parowania urządzeń migracji SRDF.

symrdf deletepair -sid 456 -rdfg 100 -sg sg_ibmi_lpar1_asp1_1

symrdf removegrp -sid 000420200123 -rdfg 100

Wyczyść strefy SAN na odpowiednich przełącznikach:
Z hosta IBMi do starej macierzy.
I usuń strefy SRDF ze STAREJ do NOWEJ macierzy (po zakończeniu ostatniej migracji).