VMAX、PowerMax: IBMiホスト プラットフォームの無停止移行

サポート環境:
NDM for IBMiは、PowerMaxOSのリリース5978.444.444以降を実行しているVMAXまたはPowerMaxアレイに接続されているサポート対象のIBMiホスト システムで使用できます

これは、IBM Power Server プラットフォーム Power6 以降で実行され、IBMi オペレーティング・システム バージョン i6.1.1 以降を実行している IBMi 論理区画 (LPAR) 用です。VMAXまたはPowerMaxの一般的なe-Labサポート マトリックスは、サポート対象のFibre Channel (FC) IBMi I/Oアダプター(IOA)、別名ホスト バス アダプター(HBA)の詳細とリストを提供します。また、IBMiがIBM仮想I/Oサーバー(VIOS)から仮想I/Oリソースを割り当てられたクライアントLPARである場合も、NDMがサポートされます。IBM VIOS/VFC(NPIV)機能を使用すると、仮想FCアダプター(vFC)がクライアントLPARに割り当てられ、サポートされているSANスイッチを使用してストレージ アレイに接続できるようになります

vFC は、ホスト ディスク接続のパススルーとして機能します。ホスト側からは、これは完全に透過的であり、ストレージ アレイでサポートされているすべての機能は、仮想化アダプターのセットアップでも使用できます

バックグラウンドおよび高レベルの移行シナリオ:
Symmetrix Remote Data Facility(SRDF)は、1990年代初頭に、Dellエンタープライズ ストレージ アレイ用のディザスター リカバリー(DR)レプリケーション テクノロジーとして開発されました。これはまた、1つのアレイから別のアレイへのストレージ ベースの移行を実行するために、長年使用されてきました。つまり、新しいストレージ アレイを実装してテクノロジーを更新するときに、新旧アレイを「連続的に」接続し、データ ボリュームをコピーします。ボリュームまたは論理ユニット(LUN)のSRDFコピー プロセスは、接続されたホスト システムに対して透過的ですが、従来は、ソース ボリューム(R1)からコピー プロセスが完了したときに、短いオフラインの「カットオーバー」ウィンドウが常に必要でした。ターゲット（新規）ボリューム(R2)が読み取り/書き込み可能で、ホスト システムのFC接続が（SANゾーニングとマスキングを介して）新しいアレイにポイントされていました。

SRDF/Metroは、VMAX All Flashストレージ アレイ ファミリーで導入されました。SRDF/Metroは、両方のアレイからソース(R1)およびターゲット(R2)ボリュームへの真のアクティブ/アクティブ ホスト アクセスを提供します。SRDF/Metroは、ディスク アクセスの際にサポートされているホスト マルチパス ドライバーと連携します。これには、ディスク パスに対するネイティブIBMiダイナミック マルチ パス(DMP)保護が含まれます。IBMi DMPは、同じディスク デバイスに複数のFCパスがあるかどうかを自動的に検出します。また、使用可能なFCアダプター パス全体にディスクI/Oワークロードを分散するため、基本的かつ効果的な「ラウンド ロビン」ロード バランシング スキームも提供します。IBMi DMPは、ディスクI/O操作を残りのアクティブ パスのいずれかにリダイレクトすることで、接続が失敗した場合に自動パス フェールオーバーを提供します。障害が発生した接続が復元されると、IBMiはそれらのパスを自動的にリカバリーし、これらのパスへのディスクI/Oの送信を再開します

METROおよびプレコピー オプションを使用したNDMは、基盤となるSRDF/Metroテクノロジーに基づいており、古いストレージ デバイスと新しいストレージ デバイスへの同時アクセスを提供します

作成フェーズ:
SRDF/Metroレプリケーション デバイス ペア(R1>R2)が作成されると、ターゲット アレイのR2デバイスから同じR1デバイスIDが提示されます。基本的に、両方のデバイスから同じディスク シリアルIDとデバイスWWPNが提示されます。最初、新しいR2デバイスはAA-NR/DEV-INACT (Active/active-Not Ready/ Device Inactive)の状態です。R1>R2デバイス ペアが同期されると、R2ボリュームへの読み取り/書き込みアクセスが有効化され、アクティブ/アクティブ状態になります

READY_TARGETフェーズ:
IBMi LPARからR2デバイスへのパスが有効になると(SANゾーニングがすでに実施され、NDM readytgtコマンドによってアクティブ化された新しいアレイのマスキングが行われる)、IBMiホストは既存のディスク デバイスへの新しいFCパスを検出します。IBMi NDMのシナリオでは、アクティブ/アクティブR1 + R2デバイスが表示されます

COMMITフェーズ:
R1デバイスへのアクセスを削除することで、IBMiホストは古いアレイのパスにアクセスできなくなりますが、新しいアレイへのパスを使用してR2デバイスで実行は続行されます。これが完了したら、古いアレイへのSANゾーニングを削除できます。古い非アクティブ パスの使用を停止し、現在「欠落している」これらのパスに関連するエラー メッセージを停止するには、IBMiシステムで「reset multipath」ユーティリティーを実行する必要があります。IBMi ホストのデバイス構成データベース (IBMi ストレージ管理情報リポジトリ) から古い非アクティブ・パスとそれに関連する DMPxxx ディスク・ハードウェア・リソースを完全に削除するには、初期プログラム・ロード (IPL) 別名リブートが必要になる場合がありますが、これは必須の IPL ではなく、次回の計画 IPL まで待機することもできます。これらの「古い」デバイスを削除するには、次の手順を実行します。STRSST>Start Service Tool>Hardware Service Manager>Failed and Non-reporting Hardware: オプション 4 を使用して削除するすべての古いディスクリソース DMPxxx を選択し、Enter キーを押して確定します

Dell STMを使用する際の考慮事項
STMは、VMAXのIBMiレプリケーション制御用の「ストレージ コピー サービス ツールキット」とも呼ばれます。PowerMaxストレージは、1つまたは複数のIBMiホスト上でネイティブ ソフトウェア アプリケーションとして実行されます。サポートされているSRDF構成のリモート レプリケーションと、VMAX、PowerMaxアレイ上のSnapVXスナップショットのローカル レプリケーションを制御できます。STMには2つのタイプがあります。標準機能エディションと拡張機能エディション。

STMは、FCパスを介してストレージ アレイへのインバンド通信を使用し、システム コールのGatekeeperとも呼ばれる小型の専用デバイスを使用します。IBMi の Gatekeeper は、非構成ディスク装置セクションに残る特殊な小型 D910 GK タイプの装置です。これらのGatekeeperはマルチパスをサポートしておらず、複数のシングルパスGatekeeperは通常、通常のASP1ディスクに使用されるのと同じ冗長パス セットに表示されます。少なくとも4つのGatekeeperを使用することをお勧めします。GatekeeperはNDM移行プロセスの一部ではないため、移行後、古いアレイのGatekeeperへのアクセスは削除され、新しいアレイの新しいGatekeeperが表示されます

標準機能:
これは、*SYSBAS ストレージ構成のみを使用するシステムに使用されます。*SYSBAS とは、システム ASP1 + 追加のユーザー ASP (ASP 2-32) を意味します。STM はソース・ノードにのみインストールされ、*SYSBAS 内のすべてのディスクの複製ペアを 1 つの分割不能エンティティーとして制御します。  基盤となるディスク構成に変更が発生した場合。つまり、NDMの「なりすまし解除」操作によってディスク シリアル番号が変更された場合は、IBMiソース ホストでSTM DISCOVERコマンドを実行するだけで十分です。新しいアレイのGatekeeperが表示されたら、DISCOVERオプションを実行します。これにより、ホスト上のIFS(統合ファイル システム)内のローカルsymapiデータベースが更新されます(location= /var/symapi/db)。STM画面には、新しいディスクのシリアル番号も反映されます。STM内のレプリケーション デバイスのペアリングで問題が発生した場合は、インストール オプションのみを使用して、新しい構成セットアップから開始することもできます。これは、VMAX-PowerMaxストレージ アレイですでに構成されているレプリケーション ペアリングのセットアップには影響しません。クリーン スクラッチ インストール/セットアップを行うには、まず、現在の構成で関連するパスとステップを文書化し(GO MAINCTL>1、IMAGES>システム イメージのオプション2を選択します> 次の例に従って、PATHS画面のスクリーン キャプチャを作成します。

STMを終了し、/var/symapiフォルダーとそのサブフォルダーを削除します。EMCCTLライブラリーを削除します。STMを実行して、プログラムを再度インストールします。CRTSYMAPIを実行します。GO MAINCTLで、以前に構成したのと同じパスを再度関連付けます。STMは、VMAX-PowerMaxストレージ アレイからのアクティブなレプリケーション ペアリングのステータスを検出して表示するようになりました。STM操作を再開する準備が整いました。

拡張機能:
これは、1 つ以上の「切り替え可能」iASP (独立 ASP) を含む IBMi PowerHA クラスター・セットアップを使用するシステムに使用されます。このシナリオでは、iASP のみが複製され、この iASP またはそのレプリカを PowerHA クラスター内のノードに提示できます。各クラスター・ノードは、それ自身の *SYSBAS (ASP1) で既にアクティブになっています。iASPは、共有クラスター デバイス ドメイン内の切り替え可能なリソースとして構成されます。通常、クラスターには 2 つまたは 4 つのノードがあります。つまり、次の図の例に示すように、本番ノードをソースとし、リモートDRターゲット ノードとSnapVXバックアップ ノードを両側に持つ4ノード クラスターの場合です。

iASPまたはそのレプリカを使用するために、どのノードからのIPLも必要ありません。iASP ディスクがクラスター内の任意のノードに提示される場合、そのノードで iASP を使用できるようにするために VARY ON コマンドが必要です。PowerHA セットアップでは、STM ソース・バージョンはソース・ノード (EMCCTL ライブラリー内) にインストールされます。他のすべてのノード(SRDFまたはSnapVXターゲット レプリカのいずれか)では、ターゲット バージョンが(EMCCTLCライブラリーに)インストールされます。すべてのノードがアクティブであるため、このセットアップでは、iASP がまだそのノードの VARY ON 状態にある場合、ノードのディスク・アクセスを除去することは禁止されるという、特定の操作のために STM に組み込まれた依存関係とチェック・アンド・バランスがあります。ノード間通信の場合、すべてのノードの EMCCTL サブシステムで実行されている STM サーバー・ジョブがあります。このジョブは、クラスターIPインターフェイスを介してノード内で通信します。一般的なSTM操作は、クラスター内の任意のノードから実行できます。これには、各ノードで同じ STM ディスク、アダプター、およびパス構成ファイルのセットが使用可能である必要があります。PowerHA の STM の初期セットアップ時に、これらのファイルはソース・ノードから MAINCTL オプション 16 を使用して構成され、これにより、これらのファイルはターゲット・ノード (STM インストール・ライブラリー EMCCTL および EMCCTLC 内の IASPS、ISRCIOA、および IMAGE ファイル) にも伝搬されます。これらのファイルは、DSPPFM EMCCTL/IMAGE を使用して表示することもできます。ファイルには、iASP構成に使用されるディスクとディスク アダプターに関する情報が含まれています。アダプターIDとディスクのシリアル番号はこれらのファイルに格納され、STM操作で使用されます

次に、NDMのスプーフィング解除操作の実行時に発生するディスク シリアル番号の変更の影響について考えてみましょう。STM構成ファイルには、古いディスクのシリアル番号がまだ含まれています。ほとんどのSTM操作は、これらの構成ファイルが更新されるまで機能しなくなります。これらのファイルの更新と伝播は、MAINCTL>Option-16 (iASP の設定) が実行され、iASP ディスクがそれぞれの PATH-STEP でターゲット ノードで使用可能になったときに、最初の STM インストール時と同じプロセスに従って実行できます。これらのファイルがアップデートされると、STM iASP操作は再び期待どおりに機能します。問題が発生した場合は、iASP PATH/STEPを構成し、STM構成ファイルを作成または伝播するためのオプション16を含む、ソース ノードとターゲット ノードに対してSTMのスクラッチ インストールのみを実行することを検討してください。

Dellサポート アカウントを持つ登録ユーザーは、 SRDF/TimeFinder Manager for IBM i を参照して、これらのSTMエディションの関連情報を確認できます

デバイスIDのリセット後の次回のIPL(別名「スプーフィング解除」操作)に関する考慮事項
NDMのスプーフィング解除操作では、ディスクのシリアル番号が変更されます。これは、IBMi LPARがダウンしている場合にのみ実行できます。この操作が移行後に計画的なオフライン メンテナンス スロットで実行される場合、いくつかの考慮事項があります。IBMi LPARの活動化はIBM PowerServer Hardware Management Console (HMC)から制御され、HMCはIBM PowerVM仮想化のハイパーバイザー機能を提供します。この HMC では、各 LPAR には、LPAR 構成 (CPU/MEM、アダプターなど) に関する詳細を含む少なくとも 1 つの LPAR プロファイルがあります。LPAR は、初めて IPL 処理 (IPL= 初期プログラム・ロード = ブート・シーケンス) されるときに、選択されたプロファイルから構成の詳細を読み取ります。プロファイルの特別なタブは、「タグ付きI/O」と呼ばれます。  タグ付き入出力設定は、LPAR が B タイプ IPL 時にロード・ソース (LS) (= ブート・ディスク) を検索し、D タイプ IPL 時に「代替再始動装置」、つまり DVD またはテープを検索する必要がある場所を定義します。LPAR が初めて正常に IPL 処理された場合は、最後の IPL 情報がハイパーバイザーに保管されるため、プロファイルを再度読み取る必要はありません。次回の IPL では、LPAR プロファイルが再度明示的に選択されない限り、デフォルト設定の「現行構成」が使用されます。IPL と IPL の間に LS コントローラーまたは LS ディスクの詳細に特定の変更がある場合、LPAR は変更された LS ディスクを受け入れず、IPL は失敗します。これは、次の場合に発生します。LPARは、「現在の構成」オプションで、またはタグ付きI/O LSアダプターが「なし」に設定されている場合にアクティブ化されます。LS ディスクのシリアル番号の変更は、LPAR がそれを受け入れず、正しいプロファイルが選択されたアクティベーションが必要なような変更です

以下のスクリーン・キャプチャーは、有効な LS アダプターが選択された従来の HMC LPAR プロファイル・ビューを示しています。

以下の図は、VIOS 3.x/4.x を搭載した HMC v10 の最新バージョン・ビューでの同じ情報を示しています。

 

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を削除し、スプーフィングを解除してからMVを再作成します。

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

ディスクIDの詳細を表示します。

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 プロファイルの「タグ付き I/O」タブで、LS コントローラーが正しい FC アダプターに設定されていることを確認します

「なし」を選択した状態で「タグ付きI/O」LSコントローラー設定を空のままにしないでください。

「B-Normal」オプションを指定して IPL を実行し、IPL の LPAR プロファイルを選択します。デフォルト・オプションの「現行構成」のままにしないでください

LPARのIPLを実行し、システムがオンラインに戻ったら、SSTからディスクのシリアル番号を確認します。

シリアルIDに、新しいアレイsymdev IDとアレイのシリアル番号が反映されます。

=== End of Procedure ===