Db2 Mirror for i 概要と運用時の考慮点

 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である。

図表1 Db2 Mirror for i 概要

 
 図表2は、アプリケーションコンポーネントを追加したDb2 Mirror for iの構成図である。

図表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)。

図表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)など、わかりやすいインターフェースが提供されている。

 

図表4 Db2 Mirror for i の運用管理―オブジェクトレベルの状態管理
図表5 Db2 Mirror for i の運用管理―ノードの役割変更

 

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のオブジェクトタイプごとのサポート一覧である。

図表6 Db2 Mirror for i オブジェクトタイプごとのサポート一覧

 
 Db2 Mirror for iの複製対象オブジェクトはDB、SQL関連オブジェクトやプログラム、データエリア、システム値、ジョブ記述などで、主に実行中のジョブが変更する可能性の高いもの、もしくはジョブ実行に必須なオブジェクトに集中している。S/36環境やデバイスや通信の設定、外字テーブルなどは対象外である。

 ソフトウェア複製ソリューションがほぼすべてのオブジェクトタイプをカバーするのと異なり、「物理的に2つのデータベースをリアルタイム同期すること」が中心命題で、それ以外についてはユーザーサイドで補って構築する必要がある。
 
 それをより具体的に想定したのが、図表7である。

図表7 DB2 Mirror for i 運用上の考慮点

 

機能的な制約事項

 
 図表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)。

図表8 DB2 Mirror for i 出口点

 

 以上についての詳細情報は、以下の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]


 

特集|Db2 for i 最新Tips~多彩な角度からDb2 for iの高度活用にアプローチする
 
PART 1  Db2 for i の歴史と拡張の方向性
PART 2 Db2 for i サービスとIBM i サービスの機能拡張
PART 3 IBM i Access Client Solutions(ACS)のDb2 for i 関連機能
PART 4 Db2 for iの日常運用を見直す
PART 5 Node.js on IBM iのDb2 for i 関連機能
PART 6 Db2 Mirror for iの概要と運用時の考慮点
Column  SQLサンプルの活用法(IFSオブジェクトの管理)
関連リンク

More Posts