Db2 Mirror for iは、IBM i 7.4の発表と同時に公開された新しい機能である。
Db2 Mirror for i の目的は、ローカルサイトでのDbサーバーのHA化である。2つのDb2 for iデータベース（IBM i LPAR）をRoCEで高速接続し、2つのDb2 for i を同期的に更新する。
Db2 for iデータベースは、ストレージ上で物理的に2つ存在している。ここでは、まず簡単にDb2 Mirror for i の概要を解説してから、運用時の考慮点について考えてみる。
Db2 Mirror for iの概要
図表1は、Db2 Mirror for iの概要図である。下記のような特徴と機能を備えている。
・RoCE高速ネットワークで接続された2つのノードが、RDMA（リモートダイレクトメモリアクセス）で相互に DB ファイルを読み書きする。
・計画メンテナンスやノード障害時は、別ノードに移動可能である。
・ノードは異なる OS レベルでも対象となる
・ノードはPOWER8とPOWER9など異なるPOWERプロセッサでも可能である。
・停止時間なしのローリング・アップグレードにも適用できる。
・POWER8以降、IBM i7.4でサポートされる。
・ライセンスプログラム 5770-DBMが必要である。
・外部ディスクに加えて、内蔵ストレージ（SAS接続SSDとNVMe）をサポートする。
・2台のシステム間のRoCEケーブル長は最大100mまたは200mである。
図表2は、アプリケーションコンポーネントを追加したDb2 Mirror for iの構成図である。
ここではアプリケーション（AP）がIBM i 外部で動作するケースを記述している。
別の構造としては、アプリケーション（Webアプリケーションなど）が2つのIBM i上で稼働しているケースも考えられる。その場合、ネットワーク装置でロードバランシングをする構成が一般的と思われる。
2つのIBM i は、アクティブーアクティブ（ロードバランシング）構成でも、アクティブースタンバイ構成も可能である。
5250アプリケーションはIBM iローカルで実行される必要があるため、どちらかのIBM iがダウンした場合は、もう片方のIBM iで（再）起動が必要になる。
また代替フェイルオーバー機能をもつJDBCドライバを利用したJavaアプリケーションの場合は、ノードダウン時にもJDBC接続先DBをJDBCドライバレベルで動的に切り替えて処理を継続できる。最新のToolbox for JavaやJTOpenのJDBCドライバは代替フェイルオーバーをサポートしている。
なおIFSオブジェクトについては、Db2 for iの複製方式とは異なる方式で実装される。具体的にはIASP上に配置したIFSオブジェクトのみが対象となり、IASPはPowerHAのクラスタ・リソース・グループ（CRG）に含める必要がある。
また、1つの1ASPにDb2 for iのオブジェクトとIFSオブジェクトを混在させて両方を複製することはできない。
このためDb2 MirrorでDb2 for iオブジェクトを複製する場合、IFSオブジェクトは別にIASPに配置し直す必要がある。
IFSが保管されたIASPは、片方のIBM iシステムに接続され、Db2 Mirror の構成に追加される。そしてもう一方のIBM iシステムが、RoCE経由でリモートアクセス可能になる（図表3）。
この方式はミュータブル・ファイルシステム（可変ファイルシステム）と呼ばれ、IFS IASPを物理的に接続する側にIFSサーバー・ファイルシステム、他方にIFSクライアント・ファイルシステムが動作する。
IFS IASPでは、物理的に1つのIASP内のすべてのIFSオブジェクトが、2つのIBM i システムから同時アクセス可能である。この点が、Db2 for iオブジェクト（Db2 for i用のIASPとSYSBASに存在）とは異なる。
仮にIFS IASPとして、Db2 Mirrorに登録されているIASP内にDb2 for iのオブジェクト（ライブラリーや物理ファイル等）が存在したとしても、Db2 for iオブジェクトはDb2 Mirrorの複製対象とはならない。
図表3では、IFS IASPは左側のシステムに存在するが、ストレージの複製機能を使用して他方のシステムに複製できる。ストレージが切り替わる場合、自動的にIFSサーバー・ファイルシステムとIFSクライアント・ファイルシステムが切り替わる。
Db2 Mirror for i の基本的な運用管理
Db2 Mirror for i の運用管理はすべてGUIで操作できる。
オブジェクトレベルの複製設定や状態管理（図表4）、システム全体の複製開始・停止、ノードの役割変更（図表5）など、わかりやすいインターフェースが提供されている。
Db2 Mirror for i の運用上の考慮点
Db2 Mirror for iは、物理的に2つのデータベース（およびIFSオブジェクトやアプリケーションが利用する一部のシステムオブジェクト等）をリアルタイムに保持できている点で、非常に高い可用性やRTOゼロのHA構築にメリットがある。
しかし、従来からあるHA／DRソリューションであるソフトウェア複製（MIMIX、Quick-EDD、Maxava HAなど）やストレージ複製（Grobal Mirror、Metro Mirror）とは運用上、異なる考慮点が考えられる。
複製対象のオブジェクトタイプ
図表6は、Db2 Mirror for iのオブジェクトタイプごとのサポート一覧である。
Db2 Mirror for iの複製対象オブジェクトはDB、SQL関連オブジェクトやプログラム、データエリア、システム値、ジョブ記述などで、主に実行中のジョブが変更する可能性の高いもの、もしくはジョブ実行に必須なオブジェクトに集中している。S/36環境やデバイスや通信の設定、外字テーブルなどは対象外である。
ソフトウェア複製ソリューションがほぼすべてのオブジェクトタイプをカバーするのと異なり、「物理的に2つのデータベースをリアルタイム同期すること」が中心命題で、それ以外についてはユーザーサイドで補って構築する必要がある。
それをより具体的に想定したのが、図表7である。
機能的な制約事項
図表7ではまず、「機能的な制約事項」を見てほしい。実行中のジョブが生成するDBオブジェクト以外のデータについては、複製されないものが複数存在する。
たとえば実行中の5250ジョブ、バッチジョブは同期されない。JOBQオブジェクトは複製されるが、その中のジョブキューエントリーは複製されない。また、ジョブスケジュールも複製されない。
OUTQについては、OUTQ単位で複製する／しないが指定でき、複製すると指定したOUTQに存在するスプールは複製される（複製対象に指定していないOUTQ内のスプールは複製されない）。
Db2のトリガーもOUTQと同様で、同期YESに指定したものは複製され、同期NOのものは複製されない。MQは同期対象だが、アクティブーアクティブでの同期は不可である（アクティブーパッシブのみ可能）。DB・SQL関連でもSQLプランキャッシュは複製されない。
以上の特性を理解した上で、アプリケーション設計や同期設計を検討してほしい。
運用上の注意点
次に、「運用上の注意点」について解説する（本稿で触れていないDb2 for iの実装も踏まえて記述している点に注意してほしい。それについては、末尾のマニュアル等に記載があるので参照いただきたい）。
Db2 Mirrorの複製状態がACTIVEで、複製の詳細がREPLICATINGの場合、2つの物理データは同一に保たれている。
このとき、どちらかのノードでデータが照会またはREADされる場合、データはローカルから読み出されるためDb2 Mirrorは関与しない。
Db2 Mirrorの複製状態がBLOCKEDの場合、2次ノードで実行しており、Db2 Mirror複製は中断されている。この状態でもデータを読み取れるが、プライマリーノードのデータと完全には一致しなくなる可能性がある。
データベースのトリガーについては、デフォルトではSQLとネイティブのすべてのトリガープログラムはソースノードでのみ実行される。
Db2 MirrorはINSERT、UPDATE、DELETEに関連するトリガーイベントを同期レプリケーションの一部として両方のノードで発生させる。
トリガープログラムがソースまたは開始ノードでのみ起動する場合は、トリガーはMIRRORNOとして処理される。MIRRORYESとして構成すれば、ソースノードとターゲットノードの両方でトリガー実行できる。
ただし一般的にはソース側で処理が完了すると、トリガー処理は完了しているはずなので、ターゲット側で再度トリガー処理を起動する必要はないと思われる。
またBEFOREトリガーとして作成し、MIRRORYESを設定したトリガーはターゲットノードでレコードイメージを変更できない。AFTERトリガーとして作成し、MIRRORYESを設定したトリガーは、挿入または更新した直後のデータを更新できない。どちらもデータの同期を破壊する可能性があるからだ。
このような処理が実行されると、SQLCODE＝-7061およびSQLSTATE＝55019のエラーで、操作が失敗する。ジョブログにはSQL7061 理由コード76が記録される。
Db2 Mirror for i の出口点
DB2 Mirrorの同期開始直前、同期終了直後をモニターしてユーザー制御を実行する方法、もしくはノードの役割が切り替わるタイミングをモニターしてユーザー操作を実行する方法が、出口点として提供されている（図表8）。
以上についての詳細情報は、以下のIBM Knowledge Center、およびPDFで提供されている。
可用性 Db2 Mirror
https://www.ibm.com/support/knowledgecenter/ja/ssw_ibm_i_74/db2mi/db2mintro.htm
https://www.ibm.com/support/knowledgecenter/ja/ssw_ibm_i_74/db2mi/db2mipdf.pdf?view=kc
著者
佐々木 幹雄氏
日本アイ・ビー・エム株式会社
パワーシステムテクニカルセールス
シニアITスペシャリスト
AS/400利用のお客様担当SEから出発し、さまざまなテクニカル職種を担当。現在はPower Systemsはじめインフラ提案・アーキテクチャ設計を主に担当している。
［i Magazine・IS magazine］
