VMAX, PowerMax: Безперервна міграція для хостинг-платформи IBMi

Середовище для підтримки:
NDM для IBMi доступний для підтримуваних хост-систем IBMi, які підключені до масивів VMAX або PowerMax під керуванням випуску PowerMaxOS 5978.444.444 або пізнішої версії.

Це стосується логічних розділів IBMi (LPAR), які працюють на платформі IBM Power Server Power6 або новішої версії та працюють під керуванням операційної системи IBMi версії i6.1.1 або новішої. Загальна матриця підтримки e-Lab VMAX або PowerMax надає детальну інформацію та перелічує підтримувані адаптери вводу/виводу IBMi (IOA) з волоконним каналом (FC), також відомі як адаптери хост-шини (HBA). NDM також підтримується, коли IBMi є клієнтським LPAR із призначеними віртуальними ресурсами вводу/виводу з віртуального сервера вводу/виводу IBM (VIOS). За допомогою функції IBM VIOS/VFC (NPIV) клієнтським LPAR призначаються віртуальні адаптери FC (vFC) для підключення до масиву зберігання даних за допомогою підтримуваних перемикачів SAN.

vFC виступають як наскрізний зв'язок для підключення хост-диска; З боку хоста це повністю прозоро, і всі підтримувані функції з масиву зберігання також доступні в цьому віртуалізованому налаштуванні адаптера.

Сценарій міграції на бекграунді та високому рівні:
Symmetrix Remote Data Facility (SRDF) був розроблений на початку 1990-х років як технологія реплікації Disaster Recovery (DR) для масивів Dell Enterprise Storage. Він також використовується протягом багатьох років для виконання міграції з одного масиву на основі сховища на інший. Це означає, що з'єднайте СТАРИЙ і НОВИЙ масиви «спина до спини» і скопіюйте обсяги даних при виконанні оновлення технології, реалізувавши новий масив зберігання. Незважаючи на те, що процес копіювання томів або логічних одиниць (LUN) за допомогою SRDF є прозорим для підключених хост-систем, традиційно він завжди вимагав короткого автономного «пересічного» вікна, коли процес копіювання завершувався з вихідних томів (R1). Цільові (нові) томи (R2) були включені для читання/запису, а FC-з'єднання хост-систем були спрямовані (через зонування та маскування SAN) на новий масив. 

SRDF/Metro був представлений з сімейством масивів зберігання даних VMAX All Flash. SRDF/Metro забезпечує справжній активний/активний хост-доступ до джерельного (R1) та цільового (R2) томів з обох масивів. SRDF/Metro працює з підтримуваними драйверами кількох шляхів хоста для доступу до диска. Це включає вбудований захист IBMi Dynamic Multi Path (DMP) для дискових шляхів. IBMi DMP автоматично визначає, чи є кілька шляхів FC до одного і того ж дискового пристрою. Він також забезпечує прості, але ефективну схему балансування навантаження за круговою системою для розподілу робочого навантаження вводу/виводу диска на доступні шляхи адаптера FC. IBMi DMP забезпечує автоматичне перемикання шляху після відмови при з'єднанні, перенаправляючи операцію вводу-виводу на один з активних шляхів, що залишилися. Коли невдалі з'єднання відновлюються, IBMi автоматично відновлює ці шляхи і знову починає відправляти дисковий ввід/вивід на ці шляхи.

NDM з METRO та опцією попереднього копіювання базується на базовій технології SRDF/Metro для забезпечення одночасного доступу до старих і нових пристроїв зберігання даних.

Фаза СТВОРЕННЯ:
Коли створюється пара пристроїв реплікації SRDF/Metro (R1>R2), така сама ідентичність пристрою R1 представлена від пристрою R2 у цільовому масиві. По суті, один і той же disk serial-ID і WWPN пристрою представлені від обох пристроїв. Спочатку новий пристрій R2 знаходиться в стані AA-NR/DEV-INACT (Активний/Активний-Не Готовий/ Пристрій Неактивний). Після синхронізації пари пристроїв R1>R2 він може перейти в активний/активний стан, увімкнувши доступ для читання та запису до тому R2.

READY_TARGET етап:
Коли шлях від IBMi LPAR до пристрою R2 тепер включений (SAN Zoning вже на місці, а маскування для нового масиву активовано командою NDM readytgt), хост IBMi виявляє нові шляхи FC до існуючого дискового пристрою. У сценарії IBMi NDM представлені активні/активні пристрої R1 + R2.

Фаза COMMIT:
Видаляючи доступ до пристроїв R1, хост IBMi тепер втрачає доступ до шляхів старого масиву, але продовжує працювати на пристроях R2, використовуючи шляхи до нового масиву. Як тільки це буде зроблено, SAN-зонування до старого масиву можна буде прибрати. Утиліту "reset multipath" в системі IBMi слід запустити, щоб припинити використання старих неактивних шляхів, а також зупинити будь-які повідомлення про помилки, пов'язані з цими тепер "відсутніми" шляхами. Може знадобитися початкове завантаження програми (IPL), або перезавантаження, щоб назавжди видалити старі неактивні шляхи та пов'язані з ним ресурси диска DMPxxx з бази даних конфігурації пристроїв IBMi hosts (репозиторій інформації про керування сховищем IBMi), але це не обов'язковий IPL, він також може почекати до наступного запланованого IPL. Для зняття цих «несвіжих» пристроїв: STRSST>Start Service Tool>Hardware Service Manager>Failed and Non-reporting Hardware: виберіть всі старі дискові ресурси DMPxxx для видалення з опцією 4 і підтвердіть це, натиснувши enter.

Міркування під час використання Dell STM
STM, який також часто згадується як «інструментарій служб копіювання сховищ» для контролю реплікації IBMi для VMAX, сховище PowerMax працює як рідний програмний додаток на одному або декількох хостах IBMi. Він може керувати віддаленою реплікацією для підтримуваних конфігурацій SRDF та локальною реплікацією для знімків SnapVX на масивах VMAX, PowerMax. STM випускається в двох варіантах: Випуск Standard Features та Extended Features Edition.

STM використовує внутрішньосмуговий зв'язок з масивом зберігання через шляхи FC, він використовує невеликі виділені пристрої, які також згадуються як гейткіпери для своїх системних викликів. Гейткіперами для IBMi є спеціальні невеликі пристрої типу D910 GK, які залишаються в розділі неналаштованих дискових блоків. Ці гейткіпери не підтримують багатошляхові, кілька одношляхових гейткіперів зазвичай представлені на тому ж надлишковому наборі шляхів, який використовується для звичайних дисків ASP1. Рекомендується використовувати мінімум чотири гейткіпери. Гейткіпери не є частиною процесу міграції NDM, тому після міграції доступ до гейткіперів зі старого масиву видаляється і представляються нові гейткіпери з нового масиву.

Стандартні особливості:
Це використовується для систем, у яких використовується лише конфігурація сховища *SYSBAS. *SYSBAS означає Систему ASP1 + будь-які додаткові User-ASP (ASP 2-32). STM встановлюється тільки на вихідний вузол і керує парами реплікації для всіх дисків в *SYSBAS як одна неподільна сутність.  Коли відбуваються зміни в базовій конфігурації диска; тобто зміни серійного номера диска, спричинені операцією «розспуфінгу» NDM, достатньо виконати команду STM DISCOVER на хості джерела IBMi. Запустіть опцію DISCOVER, коли будуть представлені гейткіпери з нового масиву. Це оновлює локальну базу даних symapi в інтегрованій файловій системі (IFS) на хості (location= /var/symapi/db). Екрани STM тепер також відображають нові серійні номери дисків. У випадку, якщо під час сполучення пристрою реплікації в межах STM спостерігаються будь-які проблеми, також можна використовувати опцію встановлення лише для початку зі свіжим налаштуванням конфігурації. Це не впливає на налаштування сполучення реплікацій, яке вже налаштовано на масиві зберігання VMAX-PowerMax. Для чистого встановлення/налаштування скретчу спочатку задокументуйте пов'язані PATHS та STEPS у поточній конфігурації (GO MAINCTL>1, IMAGES>виберіть опцію 2, для образу> СИСТЕМИ створіть знімок екрана для екрана PATHS відповідно до наведеного нижче прикладу:

Вийдіть з STM, видаліть папку /var/symapi та її підпапки. Видаліть бібліотеку EMCCTL. Запустіть STM, встановіть програму ще раз. Запустіть CRTSYMAPI. GO MAINCTL, знову асоціюйте ті самі ШЛЯХИ, які були налаштовані раніше. Тепер STM виявляє та відображає стан активного сполучення реплікації з масиву зберігання VMAX-PowerMax. Вже зараз робота СТМ готова до відновлення.

Розширені можливості:
Це використовується для систем, які використовують кластерну установку IBMi PowerHA з одним або декількома «перемикаються» iASP (незалежним ASP). У цьому сценарії реплікується лише iASP, і цей iASP або його репліки можуть бути представлені вузлам у кластері PowerHA. Кожен вузол кластера вже активний на власному *SYSBAS (ASP1). iASP налаштований як перемикається ресурс у домені спільного кластерного пристрою. Зазвичай у кластері є два або чотири вузли; це відповідає наведеній нижче прикладній діаграмі для 4-вузлового кластера з виробничим вузлом як джерелом і з віддаленим цільовим вузлом DR і резервним вузлом SnapVX з обох боків:

Для використання iASP або його реплік не потрібен IPL від будь-якого вузла. Коли диски iASP представлені будь-якому вузлу в кластері, він вимагає команди VARY ON, щоб зробити iASP доступним для цього вузла. У конфігурації PowerHA версія STM Source встановлюється на вузол Source (у бібліотеці EMCCTL). На всіх інших вузлах (цільові репліки SRDF або SnapVX) встановлюється цільова версія (у бібліотеці EMCCTLC). Оскільки всі вузли активні, існують залежності та стримування та противаги, вбудовані в STM для певних операцій у цій конфігурації, тобто видалення доступу до диска для вузла заборонено, якщо iASP все ще знаходиться в стані VARI ON для цього вузла. Для міжвузлового зв'язку існує завдання STM-сервера, що виконується в підсистемі EMCCTL на всіх вузлах. Це завдання обмінюється даними між вузлами через IP-інтерфейси кластера. Типові операції STM можуть виконуватися з будь-якого вузла в кластері. Для цього потрібно, щоб на кожному вузлі був доступний набір однакових STM-дисків, адаптерів і файлів конфігурації шляху. Під час початкового налаштування STM для PowerHA ці файли налаштовуються за допомогою параметра MAINCTL 16 з вихідного вузла, і це також поширює ці файли на цільові вузли, які є файлами IASPS, ISRCIOA та IMAGE у бібліотеках встановлення STM EMCCTL та EMCCTLC. Ці файли також можуть бути показані, тобто за допомогою DSPPFM EMCCTL/IMAGE. Файли містять інформацію про диски та дискові адаптери, які використовуються для конфігурації iASP. Ідентифікатори адаптерів і серійні номери дисків зберігаються в цих файлах і використовуються в операціях STM.

Тепер розглянемо вплив зміни серійного номера диска, яка відбувається під час виконання операції розмінування NDM. Файли конфігурації STM все ще містять старі серійні номери дисків. Більшість операцій STM більше не працюють, доки ці файли конфігурації не будуть оновлені. Оновлення та розповсюдження цих файлів може бути виконано за тією ж процедурою, що й під час початкової інсталяції STM, коли виконується MAINCTL>Option-16 (configure iASP), а диски iASP стають доступними для цільових вузлів у відповідному PATH-STEP. Як тільки ці файли оновлюються, операції STM iASP знову функціонують належним чином. Якщо виникнуть будь-які проблеми, розгляньте можливість повторного запуску лише тимчасового встановлення STM для вихідних і цільових вузлів, включаючи опцію 16 для налаштування iASP PATH's/STEP і створення або розповсюдження файлів конфігурації STM.

Зареєстровані користувачі з обліковим записом Dell Support можуть переглядати SRDF/TimeFinder Manager для IBM i для отримання додаткової актуальної інформації про ці випуски STM.

Міркування щодо наступного IPL після скидання ідентифікатора пристрою, так званої операції
«unspoof»Операція підміни NDM змінює серійні номери дисків. Це можна зробити тільки при відключенні IBMi LPAR. Коли ця операція виконується після міграції в заплановане автономне сховище, є деякі міркування. Управління активацією IBMi LPAR здійснюється з консолі управління апаратним забезпеченням IBM PowerServer (HMC), в HMC передбачена функція гіпервізора для віртуалізації IBM PowerVM. У цьому HMC кожен LPAR має принаймні один профіль LPAR із детальною інформацією про конфігурацію LPAR, тобто CPU/MEM, адаптери тощо. Коли LPAR вперше використовує IPL-ed (IPL= початкове завантаження програми = послідовність завантаження), він зчитує деталі конфігурації з вибраного профілю. Спеціальна вкладка в профілі називається «Позначений введення-виведення».  Параметри вводу/виводу з тегами визначають, де LPAR має шукати джерело навантаження (LS) (= завантажувальний диск) під час IPL типу B, а також «альтернативний пристрій перезапуску» під час IPL типу D, тобто DVD або касету. Якщо LPAR успішно пройшов IPL-ed вперше, йому не потрібно знову читати профіль, оскільки остання інформація IPL зберігається на гіпервізорі. У наступному IPL буде використано стандартний параметр «поточна конфігурація», якщо профіль LPAR не вибрано знову спеціально для цього. Якщо між IPL відбулися специфічні зміни для контролера LS або відомостей про диск LS, то LPAR не приймає змінений диск LS, і IPL виходить з ладу. Це відбувається, ЯКЩО: LPAR активується за допомогою параметра «поточна конфігурація» або якщо адаптер LS із тегом вводу/виводу встановлено на «немає». Зміна серійного номера диска LS є такою зміною, що LPAR не приймає її, і тут потрібна активація з правильним вибраним профілем.

На знімку екрана нижче показано традиційний вигляд профілю HMC LPAR із вибраним дійсним адаптером LS:

На зображенні нижче показана та ж інформація в режимі сучасної версії HMC v10 з VIOS 3.x /4.x.

 

Інша корисна інформація міститься в PowerMax і VMAX: Найкращі практики міграції, що не порушують роботу та мають мінімальні перешкоди, та операційний посібник

======================================================================================

ПРАКТИЧНА 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.

Лише незамасковані пристрої можна відфільтрувати, тому спочатку запишіть і збережіть деталі поточного режиму маскування, потім видаліть багатокористувацький пристрій, відхиляйте, а потім знову створіть MV.

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

Відображення ідентифікаційних даних диска:

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

Для одного пристрою:

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

Для цілого ряду пристроїв:

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>

Переконайтеся в IBM HMC, що в профілі LPAR, на вкладці "Tagged I/O", контролер LS налаштовано на правильний адаптер FC.

НЕ залишайте налаштування контролера LS «Позначений I/O» порожнім з вибраним «немає».

IPL з опцією B-Normal і виберіть профіль LPAR для IPL, НЕ залишайте його на опції за замовчуванням «поточна конфігурація».

Тепер IPL LPAR і після того, як система знову буде підключена до мережі, перевірте серійні номери дисків з SST.

Серійні ідентифікатори тепер повинні відображати ідентифікатор symdev нових масивів і серійний номер масиву.

=== End of Procedure ===