はじめに
IBM PowerのIaaSであるPower Virtual Server (PowerVS) でIBM PowerHA SystemMirror for i (PowerHA for i) の地理的ミラーリング機能を利用した災対構成を検証として作ってみる機会がありましたので、セットアップ手順をまとめてみたいと思います。
1. 今回の構成イメージ
大阪と東京のリージョンにPowerVSワークスペースを作成し、それぞれにIBM i 7.5のインスタンスをデプロイしました。今回は大阪を本番サイト、東京を災対サイトと見立てています。大阪のIBM i のシステム名はI75OSAKA、東京のIBM i のシステム名はI75TOKYOとして、いずれもPowerHAのソフトウェア・オプションを付けてデプロイしました。PowerVSワークスペース間はTransit Gatewayで疎通可能としています。
なお、Transit Gatewayで異なるリージョンのPowerVSワークスペースをつなげる際にはこちらがとても分かりやすく、参考になるかと思います。
今回の環境ではネットワークとして以下4つのものを構成しました。いずれもプライベート・ネットワークで構成して、Transit Gatewayにクラウド接続 (Direct Link Connect) で接続しています。
- サービス・ネットワーク
IBM i にアクセスするためのネットワークで、実環境におけるエンド・ユーザー・アクセスのネットワークの位置付けです。 - ハートビート用ネットワーク
PowerHAのクラスター機能でクラスター・ノード (IBM i) 間で互いのノードの死活監視を行うためのネットワークです。 - ミラーリング用ネットワーク
地理的ミラーリングでデータの転送を行うためのネットワークです。地理的ミラーリングではノードごとに最大4つのIPアドレスを指定することができますので、今回は4つのセグメントを用意してそれぞれIPアドレスを割り振るようにしています。
IBM i のディスク構成ですが、IASP用に2つのボリュームを各システムに用意しています。
これらを踏まえたイメージが以下となります。
IPアドレスは各セグメントで、第4オクテットが11のアドレスを割り振っています。
では、ここから構成作業に移っていきます。
2. クラスター構成の事前準備
IBM i でクラスターを構成するにあたり、各システムで以下の設定をしておくことが必要です。
- *INETD TCP/IPサーバー
クラスターでは*INETD を使用しますので、以下のコマンドで自動開始を*YESに設定後、開始しておきます。
CHGTCPSVR SVRSPCVAL(*INETD) AUTOSTART(*YES)
STRTCPSVR SERVER(*INETD)
開始するとas400-clusterというサービスが起動します。
- ALWADDCLUネットワーク属性
ネットワーク属性のALWADDCLUの値を*ANYもしくは*RQSAUTにしておく必要がありますので、今回は以下のコマンドで*ANYに設定しました。
CHGNETA ALWADDCLU(*ANY)
DSPNETAコマンドで確認するとそれぞれ以下のようになっています。
- システム値QALWUSRDMN
PowerVSのIBM i ではデプロイした直後はシステム値QALWUSRDMNの値がQTEMPになっていてそのままではクラスターの構成ができませんでした。今回は*ALLに変更するようにしています。
CHGSYSVAL SYSVAL(QALWUSRDMN) VALUE('*ALL')
DSPSYSVALコマンドで確認するとそれぞれ*ALLになっていることが分かります。
事前確認項目の詳細はIBM i 7.5のIBM Docsにまとめられていますので、以下リンク先の各項目を見ていただくと良いと思います。
事前準備が終わったので、いよいよ地理的ミラーを構成していきます！
3. 地理的ミラーリングの構成
地理的ミラーリングは大きく以下のような流れで構成していきます。
- クラスターの作成
- 本番ノード側でのIASPの作成
- 装置クラスター資源サービス (装置CRG) の作成
- 地理的ミラーの構成
3.1. クラスターの作成
まずはクラスターをCRTCLUコマンドで作成します。フェールオーバー発生時は、メッセージ待ち行列QSYSOPRにメッセージが出されるようにして、切替は自動で行わずにユーザー側からの応答を必要とするようにしました。
このコマンドでクラスターCLUSTERが作成されて、そこにクラスター・ノードとしてI75OSAKAとI75TOKYOを入れています。ノードの登録においてはそれぞれのノードでハートビートで使用するIPアドレスを指定しています。またコマンドの中では装置ドメインDEVDMNにも各ノードが入るように作成しています。
CRTCLU CLUSTER(CLUSTER) NODE((I75OSAKA ('10.10.100.11')) (I75TOKYO ('10.10.200.11'))) DEVDMN(DEVDMN) CLUMSGQ(QSYS/QSYSOPR) FLVWAITTIM(*NOMAX)
作成時のログです。
4 > CRTCLU CLUSTER(CLUSTER) NODE((I75OSAKA ('10.10.100.11')) (I75TOKYO ('10.1
0.200.11'))) DEVDMN(DEVDMN) CLUMSGQ(QSYS/QSYSOPR) FLVWAITTIM(*NOMAX)
クラスター CLUSTER が作成されました。
クラスター・ノード I75OSAKA がクラスター CLUSTER で始動されました。
クラスター・ノード I75TOKYO がクラスター CLUSTER で始動されました。
PowerHA バージョンが 5.0 から 5.1 にアップグレードされました。
PowerHA バージョンが 5.1 から 5.2 にアップグレードされました。
PowerHA バージョンが 5.2 から 5.3 にアップグレードされました。
コマンド STRCLUNOD は正常に完了しました。
ノード I75OSAKA が，クラスター CLUSTER 内の装置ドメイン DEVDMN に追加さ
れました。
ノード I75TOKYO が，クラスター CLUSTER 内の装置ドメイン DEVDMN に追加さ
れました。
コマンド ADDDEVDMNE は正常に完了しました。
コマンド CRTCLU は正常に完了しました。
WRKCLU → オプション6でクラスター・ノードを確認してみます。
STARTパラメーターがデフォルトの*YESで作成されましたので各ノードは活動状態になりました。
これでクラスターの作成は完了です。
3.2. 本番ノード側でのIASPの作成
本番ノード側でIASPを作成します。今回は各システムに20GiBと10GiBのボリュームを1個ずつの計2個のボリュームをIASP用として接続しています。そのうち20GiBのボリュームを1次IASP、10GiBのボリュームを2次IASPとして作成したいと思います。
2次IASPはシステムASPに対するユーザーASPと同じような位置付けで、ジャーナルなどの容量を別に確保しておきたいオブジェクトを配置するために用意するIASPになります。なお、2次IASPは必須ではありませんので、1つの大きな1次IASPを構成するというのももちろんできます。今回は1次IASPの名称としてIASP01、2次IASPの名称としてIASP02という形で作成しました。
なお、IASPの構成は時間がかかるのでSBMJOBでバッチ投入した方がいいかもしれません。
バッチ投入の際はディスク装置名を画面で指定することができないので予めSSTなどで装置名を確認しておく必要あります。また、CONFIRM(*NO) として実行確認画面を出さないようにします。以下のコマンド・ストリングはSBMJOBでバッチ投入する際のものです。
CFGDEVASP ASPDEV(IASP01) ACTION(*CREATE) TYPE(*PRIMARY) UNITS(DPH014) CONFIRM(*NO)
CFGDEVASP ASPDEV(IASP02) ACTION(*CREATE) TYPE(*SECONDARY) UNITS(DPH001) CONFIRM(*NO) PRIASPDEV(IASP01)
IASPを作成した後のI75OSAKAでのWRKDSKSTSの様子です。IASPとして144番の1次IASP、145番の2次IASPが作成されたことが分かります。
IASPの装置記述もそれぞれ作成されました。なお1次IASPであるIASP01をオンに構成変更すると、2次IASPも自動的にオンに構成変更されるようになっています。
これで本番ノードでのIASP作成が完了です。
3.3. 装置クラスター資源サービス (装置CRG) の作成
装置CRGをCRTCRGコマンドで作成します。
CRG作成時に回復ドメインに各ノードを組み込み、切り替え時のノードの優先順位を付けます。今回はI75OSAKAが本番とし、I75TOKYOが待機という位置付けで構成しています。ノードの指定時にミラーリング用IPアドレスも指定するのですが、今回は各ノードで最大である4つのIPアドレスを指定しています。ノード間で切り替わる装置として1次IASPと2次IASPの装置記述を指定し、ノード間のフェールオーバーではメッセージ待ち行列QSYS/QSYSOPRにメッセージが送信され、ユーザーの応答を待つような仕組みを想定しています。なお、CRGの作成だけでこの時点ではまだ開始はしないようにするのが注意点です。
CRTCRG CRG(DEVCRG) CRGTYPE(*DEV) RCYDMN((I75OSAKA *PRIMARY *LAST OSAKA ('10.10.101.11' '10.10.102.11' '10.10.103.11' '10.10.104.11')) (I75TOKYO *BACKUP 1 TOKYO ('10.10.201.11' '10.10.202.11' '10.10.203.11' '10.10.204.11'))) CFGOBJ((IASP01 *DEVD *ONLINE) (IASP02 *DEVD *PRIMARY)) EXITPGM(*NONE) FLVMSGQ(QSYS/QSYSOPR) FLVWAITTIM(*NOMAX) CLUSTER(CLUSTER)
CRG作成時のログです。このタイミングで待機ノード側にIASPの装置記述が作成されます。
4 > CRTCRG CRG(DEVCRG) CRGTYPE(*DEV) RCYDMN((I75OSAKA *PRIMARY *LAST OSAKA ('
10.10.101.11' '10.10.102.11' '10.10.103.11' '10.10.104.11')) (I75TOKYO *B
ACKUP 1 TOKYO ('10.10.201.11' '10.10.202.11' '10.10.203.11' '10.10.204.11
'))) CFGOBJ((IASP01 *DEVD *ONLINE) (IASP02 *DEVD *PRIMARY)) EXITPGM(*NONE
) FLVMSGQ(QSYS/QSYSOPR) FLVWAITTIM(*NOMAX) CLUSTER(CLUSTER)
装置記述 IASP01 が I75TOKYO で作成されました。
装置記述 IASP02 が I75TOKYO で作成されました。
クラスター CLUSTER 内にクラスター資源グループ DEVCRG が作成されました。
WRKCLU → オプション9で作成した装置CRGを確認してみます。CRGはまだ活動状態にはなっていないです。
さらにオプション6で回復ドメインを確認します。ノードI75OSAKAが本番ノードでI75TOKYOがバックアップ・ノードになっています。地理的ミラーはまだ構成しておらず、I75TOKYOへのIASPの同期は行われていないので、I75TOKYOへはまだ切り替えられないということで「不適格」という状況になっています。
以上で装置CRGの作成が完了です。
3.4. 地理的ミラーの構成
いよいよ最終ステップの地理的ミラーの構成です。地理的ミラーの構成にあたっては、
- ジョブQHASVRが両方のノードで活動状態になっていること
- 装置CRGが非活動状態であること
- IASPの装置記述が両方のノードに存在すること
- 本番ノードでIASPがオフに構成変更になっていること
が前提になっていますのでまずは各ノードで確認しておきます。
確認が終わりますと、CFGGEOMIRコマンドで地理的ミラーを構成します。
CFGGEOMIRはIASP単位で実施します。そのため、まず1次IASP用のCFGGEOMIRを実行後、2次IASP用のCFGGEOMIRを実行します。2つの構成コマンドでは、セッションは同じ名称を指定するようにします。
また、地理的ミラーの同期/非同期もこのコマンドで指定します。今回は検証ということで同期で構成していますが、大阪-東京のように別サイト間での同期ですので、本来は非同期にするのかなと思います。
このコマンドは装置CRGが非活動状態である必要がありますので、1つ目のコマンドでは開始を*NOとして実行しています。また、このコマンドの実行で待機ノード側のIASPの作成処理が行われますので、時間がかかります。こちらも本番ノードにおけるIASPの作成と同じようにバッチ投入すると良いかもしれません。またCONFIRM(*NO) として実行確認画面を出さないようにします。以下のコマンド・ストリングはSBMJOBでバッチ投入する際のものです。
CFGGEOMIR ASPDEV(IASP01) ACTION(*CREATE) DELIVERY(*SYNC) COMPRESS(*RESYNC) TGTNODE(I75TOKYO) UNITS(DPH014) SSN(TOKYO01/OSAKA01/GEOMIRSSN) START(*NO) CONFIRM(*NO) CLUSTER(CLUSTER) CRG(DEVCRG)
CFGGEOMIR ASPDEV(IASP02) ACTION(*CREATE) DELIVERY(*SYNC) COMPRESS(*RESYNC) TGTNODE(I75TOKYO) UNITS(DPH015) SSN(TOKYO02/OSAKA02/GEOMIRSSN) CONFIRM(*NO) CLUSTER(CLUSTER) CRG(DEVCRG)
実行後、WRKCLU → オプション10で確認してみます。セッション・タイプが*GEOMIRのASPコピー記述が作成されていることが分かります。各ASPコピー記述が同じセッションになっていることも分かります。
オプション25でセッションを見てみます。
1次IASPと2次IASPともにI75OSAKAからI75TOKYOに向かってコピーされていて、現時点でコピー進捗は100%で、データの状況が「USABLE」になっていますので、ノード間で切り替えが行える状態になっていることが分かります。
以上で地理的ミラーの構成が完了しました！
4. 計画切り替えと非計画切り替えを試してみる
作った地理的ミラーの環境は、本番ノードがI75OSAKA、待機ノードがI75TOKYOとなっています。
まず計画切り替え (=I75TOKYOを本番の役割にする) を行ってみたいと思います。計画切り替えは CHGCRGPRI コマンドを待機ノード側で実施します。
CHGCRGPRI CRG(DEVCRG) CLUSTER(CLUSTER)
I75TOKYOの5250画面には実行状況が出されます。
実行状況に出力されている通り、切り替え元 (今回は本番ノード) ではジョブQCSTVRYDEVがIASPのオフへの構成変更を実施してくれます。
この検証では5分程で切り替えが完了しました。
実際にはIASPの大きさや含まれるオブジェクトの数によって変わってくると思います。
ASPセッションの様子を見てみます。
IASP01、IASP02共にI75TOKYOからI75OSAKAにコピーがされるようになっていることが分かります。計画切り替えはこれで完了です。
次に非計画切り替えを試してみたいと思います。
今回は本番ノードであるI75OSAKAを制限状態にしてみました。
すると、I75TOKYOのメッセージ待ち行列QSYS/QSYSOPRにフェールオーバーの応答待ちメッセージCPABB02が出されます。
なお、QSYSOPRの転送が「*DFT」になっていると応答待ちメッセージに対してデフォルトの応答が返されてしまうので今回は転送モードを「*NOTIFY」にしておきました。
Gで応答して切り替えを実行します。するとQSYSOPRにはIASPのコピーが保留状態になったことが記録されました。
切り替えが終わったタイミングでWRKCLU → オプション9 → で装置CRGの回復ドメインの様子を見てみました。
DEVCRGの1次ノードがI75TOKYOになったことが分かります。
ASPセッションは中断状態になっています。これでフェールオーバーが完了です。
なお、I75OSAKA立ち上げ後に各ノードを本来の役割に戻す場合は大きく、
- クラスター・ノードI75OSAKAの開始
- CHGASPSSNコマンドでASPセッションを再開
- CHGCRGPRIコマンドでI75OSAKAに計画切り替え
の順で実施していくことになります。
5. 終わりに
今回はPowerHA SystemMirror for i 地理的ミラーの構成をPowerVSの大阪と東京間で構成してみました。PowerVSではTransit GatewayやVRAを使うことでリージョン間のネットワークをつなげることができ、手軽に災対構成を組むことができます。PowerVSのIBM i では有償のオプションでPowerHA SystemMirror for i をすぐ使えるようになっています。IBM i のストレージとしてIASPにする必要はありますが、地理的ミラーの構成自体はスムーズにできるかと思いますので、機会があればぜひ試してみてください。