【できる IBM i 7.4 解剖】第1回「Db2 Mirror for i の概要」

Db2 Mirror for i の概要

2台のDb2 for i を10Gb N/で接続しマイクロコード層以下のレイヤーでリアルタイムで複製する技術
アプリ層への改変影響が少ない、2台のDb2 for i はアクティブ/アクティブ、アクティブ/スタンバイの構成が可能
ローカルサイトにおけるDb2 for i の冗長化・HAが目的、遠隔DR用途ではない

DB2 Mirror for i はIBM i 7.4と同時に発表された新しい機能です。目的はローカルサイトにおいて2つのDb2 for i を冗長構成しリアルタイムで複製するHA環境の実現です。計画停止や障害など非計画停止の双方においてゼロダウンタイムを実現するためのDB可用性実現を図る機能です。

上記の図でDB SVR1とDB SVR2は10Gbまたは100GbのPCIe NIC（RoCE）アダプターで接続されます。2つのDBサーバーはアクティブ/アクティブ、アクティブ/スタンバイの構成が可能です。片方のDb2 for i で更新が発生するとRoCE経由で更新情報が遅延なく他方のDb2 for i への更新が実行されます。この更新処理はすべてIBM i マイクロコード層より下層のレイヤーで実行されます。よってRPG, COBOL, Javaなどのアプリケーションレイヤーでのコード実装は基本的には不要です。計画停止や障害発生時には接続先を正常なDb2 for i のシステムに切り替えることでアプリケーションレベルでゼロダウンタイムを実現することを可能とします。切り替えの必須機能についてもDb2 Mirror for iで提供されています。

Db2 Mirror for i と Oracle RACの構成比較

DB2 Mirror for i はときどきOracle RACと比較されますが、下図のように実際には差異があります。

OracleではIBM i の物理ファイル（テーブル）等に相当するデータストアを基本は１台の共用ストレージ上に配置し、SQLなどを処理するDBサーバーとして複数のOracleインスタンスから共用ストレージ上のDBをアクセスする方式です。スケールアウトするn台のOracleインスタンスを想定した設計になっているといえるでしょう。一方、Db2 for iは基本的には2台のDb2 for i インスタンス（2台のIBM i）にストレージを接続しデータを冗長構成で持たせる構成です。スケールアップ型でおそらくは業界最大の拡張性を持ち単体サーバーとしてもおそらく業界最高峰のIBM iの特性を活かした実装になっているといえます。Db2 Mirror for iとOracle RACでは設計思想に差異がありますので一概にどちらが優れているという事はできませんが、Db2 Mirror for iに適した適用分野としては、ハイトランザクション環境、DBダウンタイムを極限まで削減したい、後述するようにシステムマイグレーション時もダウンタイムを最小化したい、といったケースが代表的だと考えられます。

Db2 Mirror for i の前提条件

Db2 Mirror for i の前提条件は以下のとおりです。

POWER8以降、IBM i 7.4以降のシステム　＊H/W型式、OSバージョンは異なっていても可
外部ストレージが必須（2020/03現在）
RoCE接続用の10Gbまたは100Gb NICアダプター
5770-DBM IBM Db2 Mirror for i とその前提ライセンスプログラム

特筆すべきは、プロセッサー型式やストレージ型式などH/WやIBM i OSバージョンが異なっても構成可能な点です。このことにより数年に一度のシステムマイグレーション時にシステムを極力無停止で移行する際の技術として利用可能です。またRoCE(Remote Direct Memory Access(RDMA) over Converged Ethernet)という高速なネットワークを介した2つのDb2 for iインスタンスの同期処理を行うため現状では最大ケーブル長は各々100メートルとなっています（RoCEスイッチ追加はオプション）。しがたって現在Db2 Mirror for i で構成された2つのDb2 for i のシステムを遠隔に配置することはできません。

Db2 Mirror for i の機能解説

Db2 Mirror for i では一方のDb2 for i の更新がRoCE経由で他方に同期されます。他方のメモリアクセスをミラーペアのシステムに同期複製する動作で、この処理はマイクロコード層以下の機能で実行されるためアプリケーション層などのロジック追加は基本的には不要です。アクティブ・アクティブの場合、双方向での更新同期がなされます。また、アクティブ・アクティブの場合、副次的効果としてDBサーバーの負荷分散メリットもあります。

DBサーバーが計画停止、非計画停止した際のアプリケーションのアクセス先の切替は、JDBCアクセスの場合は代替フェイルオーバーをサポートするJDBCドライバーが用意されており切り替えが可能です。ODBCやREST/SOAPなどでの外部アプリケーションからのアクセスの場合はそれぞれのアプリケーションレベルやN/Wレベルでの切替方法を検討しておく必要があります。また、RPGやCOBOLなどのDBサーバーローカルで実行されるアプリケーションについては切替時の再実行の方法等を検討しておく必要があります。機能の一例としてDb2 Mirror for i専用の出口点が用意されています。Db2 Mirror for iの同期開始時、終了時、ノードがスイッチした場合などいくつかの条件が用意されており其々に合致した際のユーザーロジックを実装できます。例えばアクティブ・スタンバイの構成でDBサーバーローカルで実行されるRPG, COBOLを障害発生時にスタンバイ側に切り替わった際起動させたい場合には出口点　QIBM_QMRDB_ROLE_CHG を使用してノードの役割変更をキャッチしそれをトリガーにRPG,COBOLプログラムを投入することが考えられます。

参考：Db2 Mirror for i 出口点

出口点	出口点形式	説明
QIBM_QMRDB_PRECLONE	PREC0100	登録された出口プログラムがDb2 Mirrorの複製開始前に呼び出される。ソースノードに登録されており、複製先ノードがアクセス可能かつ出口プログラムが登録されている場合、コピー先でも実行される。 SYSBASの場合複製前の検証ステップ中に呼び出される。IASPの場合,IASP複製前に呼び出される。
QIBM_QMRDB_POSTCLONE	PSTC0100	Db2 Mirror の複製終了後に呼び出される。ソースノードの登録が複製されるため、必ずコピー元、コピー先の両方で実行される。
QIBM_QMRDB_ROLE_CHG	RCHG0100	Db2 Mirror GUI または QSYS2.SWAP_MIRROR_ROLES プロシージャーのどちらかを使用して Db2 Mirror ノードの役割が変更されるたびに、出口プログラムが呼び出されます。
QIBM_QMRDB_STATE_CHG	SCHG0100	出口プログラムは、SYSBAS またはデータベース独立補助記憶域プール (IASP) の状態が変更されるたびに呼び出されます。システム・イベントによって、SYSBAS および複数のデータベース IASP に影響する状態変更が生じた場合、出口プログラムが複数回呼び出されることがあります。

Db2 Mirror for i の応用分野

IBM i (Db2 for i)のバージョンアップ時の停止時間無しでのローリングアップグレード
PowerHAやGlobal Mirror、ベンダー製レプリケーションS/Wと組み合わせたHA/DR構成

Db2 Mirror for i はデータベースサーバーの非常に高度なHA構成を実現することに主眼が置かれていますが、IBM i (Db2 for i)のバージョンアップ時の停止時間無しでシステム移行をしたい（ローリングアップグレードしたい）場合にも応用が可能です。現行システムをアクティブ、移行先システムをスタンバイとしたDb2 Mirror for i構成を作り、データの同期処理を行い、データ同期できた時点をもってDBサーバーの切替を行うことでほぼシステム停止無しでの切替が可能になります。

また、Db2 Mirror for i単体では遠隔DR構成は撮れませんが、他のソリューション（例えばGlobal Mirrorなどのストレージ複製機能やベンダー製のレプリケーションソリューションなど）を組み合わせれば遠隔地へのDR構成も可能です。

Db2 Mirror for i の制約事項

外部ストレージ構成必須　(*注)
Db2 Mirror for i での複製対象オブジェクトはDB関連オブジェクトに制限されている

Db2 Mirror for iはまだ1stバージョンでもありいくつかの制約事項が存在します。最もインパクトのある制約事項としては、現状ストレージ構成としてPower Systemsの内蔵ディスク構成がサポートされていないことが挙げられます。RoCEを経由したデータベース更新情報の同期処理の観点では内蔵ディスクがサポートされない決定的な要因はあまりないと筆者個人は考えており将来的には何らかの機能拡張を期待したいと思います。二番目の制約事項としては2つのシステム間での複製対象オブジェクトタイプがPF, LF,やトリガーなどDB関連オブジェクトとプログラムオブジェクトやOUTQ、スプール等、一部のセキュリティ権限やシステム値などに限定されていることです。これらも筆者個人としては今後継続的な機能拡張を期待したいと思います。現状ではPower HAやベンダー製HA/DRソリューションと組み合わせた方がシステム全体のHAやDR構成の構築は容易であるといえます。

*注：（編集部追記）

この情報は原稿執筆時（2020年3月時点）の機能に基づくものです。
IBMは4月15日にIBM i 7.4の新しいTechnology Refresh 2を発表しました。最新のTRでは、内蔵ストレージがサポートされるようになりましたが、サポートデバイスはSAS経由のSSDないしNVMeに限定されます。

筆者

日本アイ・ビー・エム株式会社
IBM Power Technical Sales　佐々木幹雄

多数の執筆記事を、iWorldに寄稿中。