プライベート・ネットワークで接続した IBM i Power HA で地域的ミラーを構成する
今回は、IBM PowerHA SystemMirror for i (5770-HAS) で障害対策に取り組んでみたいと思います。
今回のポイントは、下記になります。
- 2台の IBM i を異なるサーバーに配置させる
- IBM i 間の接続にはプライベート・ネットワークを利用する
- IBM i Power HA の構成は 5250 画面から CL コマンドで行い、Navigator for i の GUI は利用しない(手順の説明が煩雑になるのと ssh トンネルを Navigator for i 用に張るのが手間なので)
- HA の方法は独立 ASP をコピーする地域的ミラーを利用する
インスタンスの作成
インスタンスを作成します。
インスタンス数を 2 以上にすると、どのように配置するのかの「コロケーション・ルール」や「命名規則」が指定できます。
今回は HA が目的なので「コロケーション・ルール」に「異なるサーバー」を指定します。
こうしておけば、別々のサーバーにデプロイされることが保証されるので、一つのサーバーがダウンしても、どちらかのインスタンスは稼働しています。
今回のブートイメージは、ライセンス受託済み、ssh 鍵認証設定済み、環境の日本語化済みの状態を事前にキャプチャーしておいたものを使います。
ただし、特別な設定はしていません。
HA の利用が試用期間を超える・試用の範囲を超える場合は「IBM i Power HA」をオーダーします。
インスタンスの作成時にボリュームの作成・接続ができますが、ここではボリュームは作成・接続しません。
今回の様に、複数のインスタンスを作成する時に、ここでボリュームを作成・接続すると、 複数のインスタンスから同じデータ・ボリュームにデータを書き込める「共有可能 (Shareable)」ボリュームとして作成されてしまいます。
仮に 10GB x 1 ボリュームを作成した場合、各々のインスタンスに独立して接続される 10GB ボリュームが合計 2 つ作成されるのではなく、両方のインスタンスから書き込み可能な 10GB ボリュームがひとつ作成されるだけです。
しかし、IBM i 用のボリュームでは、共有はあり得ません。
インスタンス作成が完了後、各々のインスタンスに共有不可のボリュームを作成・接続します。
外部から操作のための「パブリック・ネットワーク」をオンにします。
IBM i 同士を接続する「プライベート・ネットワーク」は、後から構成します。
インスタンスを作成します。
インスタンスが作成されました。
名前に「V7R3」を付けて「命名規則」が「数値接尾部」なので「V7R3-1」と「V7R3-2」になりました。
なお、IBM i のシステム名には「-」が使えないので「-」を「#」に置き換えた「V7R3#1」と「V7R3#2」がシステム名に設定されていました。
プライベート・ネットワークの作成
プライベート・ネットワーク・サブネットを作成します。
名前を付け、アドレス範囲を CIDR で指定です。
指定範囲は任意です。今回はプライベート IP アドレスから 172.16.1.0/24 を指定しました。
独立 ASP 用ボリュームとプライベート・ネットワークの接続
「V7R3-1」を構成します。
ますは、独立 ASP 用ボリュームの構成です。
現在は、80GB のディスクが 1 本構成されているだけです。
WRKDSKSTS
独立 ASP 用のボリュームを「新規追加」します。
今回は 10GB をひとつ共有可能「オフ」で追加します。
ポータルの再表示で接続が確認できます。
IBM i からも追加が確認できました。ボリュームは、IBM i 上では非構成になっています。
WRKDSKSTS
次に、プライベート・ネットワークの構成です。
現在 IBM i が認識している通信資源を確認しておきます。
WRKHDWRSC TYPE(*CMN)
「プライベート・ネットワーク」に対して「既存のネットワークを接続」します。
先ほど作ったプライベート・ネットワークを選び「172.16.1.11」を指定します。
ポータルの再表示で接続が確認できます。
IBM i が認識している通信資源をもう一度、確認します。
WRKHDWRSC TYPE(*CMN)
「イーサネット・ポート CMN06」が追加されました。
「V7R3-2」に対しても、同様の処理を行います。
10GB のボリュームを非共用で作成・接続します。
プライベート・ネットワークを IP で「172.16.1.12」で接続します。
プライベート・ネットワークとして追加された通信資源を確認します。
TCP/IP の構成
ポータルから IP アドレスをセットしても IBM i 上で IP アドレスが構成されるわけではありません。通信資源が追加されるだけです。
構成は、IBM i 側から自分で行う必要があります。
まず、「V7R3-1」を構成します。
NETSTAT OPTION(*IFC)
プライベート・ネットワークで指定した IP アドレスは構成されていません。
先ほど新規資源として確認できた CMN06 に「172.16.1.11」を割り振ります。
CRTLINETH LIND(PRIVATE) RSRCNAME(CMN06)
VRYCFG CFGOBJ(PRIVATE) CFGTYPE(*LIN) STATUS(*ON)
ADDTCPIFC INTNETADR('172.16.1.11') LIND(PRIVATE) SUBNETMASK('255.255.255.0')
STRTCPIFC INTNETADR('172.16.1.11')
回線記述を確認します。
DSPLIND LIND(PRIVATE)
MAC アドレスが、先ほどポータルで表示されたものと一致しています。
正しい通信資源を使うことができたようです。
TCP/IP Iインターフェースの状況を確認します。
NETSTAT OPTION(*IFC)
活動中になっています。
同様に「V7R3-2」で「172.16.1.12」を構成します。
CRTLINETH LIND(PRIVATE) RSRCNAME(CMN06)
VRYCFG CFGOBJ(PRIVATE) CFGTYPE(*LIN) STATUS(*ON)
ADDTCPIFC INTNETADR('172.16.1.12') LIND(PRIVATE) SUBNETMASK('255.255.255.0')
STRTCPIFC INTNETADR('172.16.1.12')
実は、このままではインスタンス間の通信は行えません。
デフォルトではプライベート・ネットワークを経由したインスタンス間の通信は許可されていません。そのため、CASE をオープンしてプライベート・ネットワークを経由したインスタンス間の通信を許可してもらう必要があります。
許可に必要な情報は、下記とのことでした。
- Name:
- Type: Private
- CIDR:
- VLAN ID:
- Location:
- Service Instance:
CASE で設定完了の回答があったら、互いに通信できることを確認します。
「V7R3-1」より。
PING RMTSYS('172.16.1.12')
「V7R3-2」より。
PING RMTSYS('172.16.1.11')
ホスト・テーブルに IP アドレスの登録
TCP/IP として ホスト名 - IP アドレスの解決ができるようにします。
今回の環境では独自の DNS を用意していないので、ホスト・テーブルに登録します。
IBM i のシステム名は「V7R3#n」ですが、TCP/IP のホスト名に「#」は使えないので「V7R3_n」としました。
(ポータル上の名称と同じ「V7R3-n」はパブリック・ネットワーク用の IP に対して登録済みでした。)
この登録を両方のインスタンスで行います。
ADDTCPHTE INTNETADR('172.16.1.11') HOSTNAME((V7R3_1))
ADDTCPHTE INTNETADR('172.16.1.12') HOSTNAME((V7R3_2))
Power HA の事前準備
事前準備として下記を両方のインスタンスで実行します。
INETD の起動
クラスターに参加するノードではINETDが起動している必要があります。
INETD を開始します。
STRTCPSVR SERVER(*INETD)
「STRSQL」から、下記の SQL を実行して、INETD が自動起動するように構成します。
update QUSRSYS/QATOCSTART set AUTOSTART = '*YES' where SERVER = '*INETD'
ネットワーク属性「クラスターへの追加可能」の変更
相手システムから、クラスターへの追加を許すように、ネットワーク属性の「クラスターへの追加可能 (ALWADDCLU)」を変更します。
今回はテストのため、認証が不要な「*ANY」を指定しました。
「*RQSAUT」を選択した場合は、IBM i クラスター・セキュリティー・サーバー・アプリケーションの認証局信頼リストを正しく設定する必要があります。 このサーバー・アプリケーションの ID は QIBM_QCST_CLUSTER_SECURITY です。
CHGNETA ALWADDCLU(*ANY)
Power HA の構成
プライマリー「V7R3-1」で作業を行います。
クラスターを作成します。
CRTCLU CLUSTER(MYCLU) NODE((V7R3#1 ('172.16.1.11')) (V7R3#2 ('172.16.1.12')))
両方のクラスター・ノードを開始します。
STRCLUNOD CLUSTER(MYCLU) NODE(V7R3#1)
STRCLUNOD CLUSTER(MYCLU) NODE(V7R3#2)
デバイス・ドメインへノードを追加します。
ADDDEVDMNE CLUSTER(MYCLU) DEVDMN(MYDEVDMN) NODE(V7R3#1)
ADDDEVDMNE CLUSTER(MYCLU) DEVDMN(MYDEVDMN) NODE(V7R3#2)
地域的ミラーに使う 独立 ASP を構成します。
CFGDEVASP ASPDEV(MYIASP) ACTION(*CREATE)
TYPE(*PRIMARY) がデフォルト値になっています。
また、UNITS(*SELECT) がデフォルト値になっているため、ディスクの選択画面が現れます。
非構成のディスクの一覧が表示されるので、追加した 10GB のボリュームを選択します。
構成にしばらく時間がかかります。
セカンダリー「V7R3-2」に移動して、セカンダリー側でも独立 ASP を構成します。
プライマリーの場合と構成コマンドが異なることに注意してください。
CRTDEVASP DEVD(MYIASP) RSRCNAME(MYIASP)
プライマリー「V7R3-1」に戻ります。
クラスター・リソース・グループを作ります。サイト名の指定は、TCP/IP のホスト名です。
CRTCRG CLUSTER(MYCLU) CRG(MYCRG) CRGTYPE(*DEV) EXITPGM(*NONE) USRPRF(*NONE) RCYDMN((V7R3#1 *PRIMARY *LAST V7R3_1 ('172.16.1.11')) (V7R3#2 *BACKUP *LAST V7R3_2 ('172.16.1.12'))) CFGOBJ((MYIASP))
地理的ミラーを構成します。
ここでも、UNITS(*SELECT) がデフォルトです。
セッション名を「GEOSSN」としました。
CFGGEOMIR ASPDEV(MYIASP) ACTION(*CREATE) SRCSITE(V7R3_1) TGTSITE(V7R3_2) SSN(V7R3#2/V7R3#1/GEOSSN)
セカンダリー「V7R3-2」側の非構成ディスクが表示されます。追加した 10GB のボリュームを指定します。
地理的ミラーリングの構成が進行します。
クラスター資源グループを開始します。
STRCRG CLUSTER(MYCLU) CRG(MYCRG)
独立 ASP をオンに構成変更します。
VRYCFG CFGOBJ(MYIASP) CFGTYPE(*DEV) STATUS(*ON)
ASP セッションを確認します。
DSPASPSSN SSN(GEOSSN)
「*SUSPENDED」の状態です。
「*RESUME」に変更します。
CHGASPSSN SSN(GEOSSN) OPTION(*RESUME) ASPCPY((V7R3#1 V7R3#2)) ASPDEV(MYIASP)
ASP セッションを、もう一度、確認します。
DSPASPSSN SSN(GEOSSN)
「ACTIVE」 になりました。
Power HA の動作確認
プライマリー「V7R3-1」側で作業を行います。
独立 ASP の中にテスト用ライブラリーとファイルを作成します。
SETASPGRP ASPGRP(MYIASP)
CRTLIB LIB(HATESTLIB) ASPDEV(MYIASP)
CRTPF FILE(HATESTLIB/PF) RCDLEN(132)
ASP セッションを「*DETACH」にし、地域的ミラーを切り離します。
これで、セカンダリー「V7R3-2」で、独立 ASP にアクセスできるようになります。
CHGASPSSN SSN(GEOSSN) OPTION(*DETACH) ASPCPY((V7R3#1 V7R3#2))
状況を確認します。
DSPASPSSN SSN(GEOSSN)
「DETACHED」になっています。
セカンダリー「V7R3-2」に移動します。
独立 ASP をオンに構成変更します。
VRYCFG CFGOBJ(MYIASP) CFGTYPE(*DEV) STATUS(*ON)
独立 ASP へのアクセスを可能にし、プライマリー「V7R3-1」で作成したライブラリー HATESTLIB を確認します。
SETASPGRP ASPGRP(MYIASP)
WRKOBJAMT LIB(HATESTLIB)
内容が確認できました。
ASP セッションを「*DETACH」することで、セカンダリー側から地域的ミラーでコピーされた独立 ASP にアクセスできます。
プライマリー側では業務を継続しながら、セカンダリー側でバックアップを行うなどの処理が可能になります。
独立 ASP へのアクセスを解放し、独立 ASP をオフに構成変更します。
SETASPGRP ASPGRP(*NONE)
VRYCFG CFGOBJ(MYIASP) CFGTYPE(*DEV) STATUS(*OFF)
ASP セッションを「*REATTACH」し、地域的ミラーでのコピーを再開します。
CHGASPSSN SSN(GEOSSN) OPTION(*REATTACH)
「F16= 確認」の処理をします。
「*DETACH」中にプライマリー側で行われた更新は、セカンダリーに同期されます。
状況を確認します。
DSPASPSSN SSN(GEOSSN)
状態が「ACTIVE」に戻りました。
当日記のIndexはこちらです。
許可の無い転載を禁じます。
この記事は筆者の個人的な責任で無保証で提供しています。
当記事に関してIBMやビジネスパートナーに問い合わせることは、固くお断りします。