7.4 IBM Db2 Mirror for i とは？
一言で言うと（アーキテクチャー的には異なりますが）Oracle RACと同様な完全二重化（冗長化）されたRDBを実現する機能です。2つのDb2 for i 間でデータを（非同期モードでは無く）同期的に複製します。
Db2 for i の高速同期レプリケーション といういい方も発表資料中にはありました。
・「アクティブ – アクティブ」構成の実現
・アプリケーション可用性の実現
・2つのノード（Db2 for i）が同じ DB ファイルを読み書きする（同じDBテーブル（PF）が2つのDb2 for i 上にあり同期されている）
・計画的なメンテナンスやノード障害時、すべての作業をすばやく別ノードに移動可能
Db2 Mirro for i の概要・メリット
・2つのノードは異なる OS リリースでも可
・2つのノードは異なるCPUモデル（POWER10とPOWER9など）のハードウェアでも可
・OSバージョンアップ等でシステム停止を回避
・停止時間なしのローリング・アップグレードにも適用可
・アクティブ/アクティブ・アプリケーションがデプロイされている場合、ノードのリリースを最小限の影響でロールバック
・2つのノード間で(DDSで作成した）ネイティブ・データベース・オブジェクトとSQLデータベース・オブジェクトの両方の同期が可能
・いずれかのノードでデータが変更されると、Db2 Mirrorは自動的に同期レプリケーションを使用して、2つのインスタンスを同一に保ちます。（Active-Active構成の場合）
・一方のノードが使用できない場合、Db2 Mirrorはアクティブ・ノード上の複製されたオブジェクトへのすべての変更を追跡します。ミラーリングされたペアが再接続されると、Db2 Mirrorはすべての変更を同期し、両方のデータベースが再び同一になります
・SYSBASまたはIASPの両方をサポート
・RDMAでの接続は近距離に制約されるため基本的にはローカル（同一データセンター内）のHAソリューション（DR・遠隔災対ソリューションではない）
Db2 Mirror for i の前提
・POWER8 以降をサポート
・IBM i 7.4 以降をサポート
・IBM i ライセンス・プログラム: 5770-DBM IBM Db2 Mirror for i が必要
・リモート・ダイレクト・メモリー・アクセス（RDMA）ネットワーク・プロトコルとそれをサポートするハードウェア（ネットワークアダプター）を使用して接続された2つのIBM i LPARが必要
Db2 Mirror for i 前提PTF
ソースノードに必要なグループPTF
| PTFグループ | IBM i 7.6 PTF番号 | コメント |
|---|---|---|
| CUM PTF | SF99760 | |
| Db2 Mirror Group | SF99961 | |
| Db2 for i | SF99960 |
GUI管理ノードに必要なグループPTF
| PTFグループ | IBM i 7.6 PTF番号 | コメント |
|---|---|---|
| Db2 Mirror Group | SF99961 | |
| HTTP Server Group | SF99962 | |
| Java PTF Group | SF99965 |
Db2 Mirror for iの管理GUI
プライマリーノード、セカンダリーノード、または別な第3のノード（IBM i）上で管理GUI機能を実行する事が出来ます。
**最新レベルのPTFグループについては、IBM i 予防保守計画へのロードマップを参照してください。
自社システムのPTFレベルを確認するIBM i サービスサンプル
以下のサンプルをACS SQLスクリプト実行画面その他SQLインターフェースから実行することで必要なPTFレベルを確認できます。
WITH ILEVEL (IVERSION, IRELEASE) AS (
SELECT OS_VERSION, OS_RELEASE
FROM SYSIBMADM.ENV_SYS_INFO
)
SELECT P.*
FROM ILEVEL, SYSTOOLS.GROUP_PTF_CURRENCY P
WHERE PTF_GROUP_RELEASE = 'R' CONCAT IVERSION CONCAT IRELEASE CONCAT '0'
ORDER BY PTF_GROUP_LEVEL_AVAILABLE - PTF_GROUP_LEVEL_INSTALLED DESC;
実行結果例です。
上記のようにDb2 Mirror for i で必要なグループPTFについて一覧を取得できます。
一番左列をみると UPDATE_AVAILABLE とある行はより新しいレベルのPTFがダウンロード可能です。（このサンプルでは全行…(^^;）
Db2 Mirror for i のIBM i 7.6でのアップデート
・単一の複製オブジェクトとその複製依存オブジェクトを、ある Db2 Mirror ノードから別の Db2 Mirror ノードに手動で再クローンする新しいプロセスが追加されました。
詳細は、単一の複製オブジェクトの再クローンを参照
・管理GUI が更新され、IBM i ファミリーの他のGUIインターフェースと調和した最新のエクスペリエンスに変更されました。
・一方のノードがIBM i 7.4 または 7.5 で、もう一方のノードが IBM i 7.6 となる混合リリースの Db2 Mirror 環境をサポートします。詳細は混合リリースの Db2 Mirror 環境、混合リリース環境で実行する場合のアプリケーションの動作、およびシステム管理のベスト・プラクティスを参照してください。
ソフトウェア要件の更新。
パフォーマンス強化、新規サービスと更新サービス、および権限の変更等の拡張・変更もあります。すべての変更点を確認するには、IBM i 7.6 の新機能 - IBM ドキュメントを参照してください。
Db2 Mirror for i のノード構成パターン
2つのDB2 Mirror for i ノードの役割にはいくつかバリエーションがあります。
1.Db2 Mirror アクティブ/パッシブ構成
一方のノードをアクティブ＝アプリケーションを実行し、もう一方をアクティブ・スタンバイ・モードに構成します。
この構成のユースケース例としてはアクティブ・スタンバイ・モードをBIやパフォーマンスの要求されるリアルタイムクエリーの実行用としても有用です。この構成では本番ノードのパフォーマンスに影響を与えることはありません。
2.Db2 Mirror アクティブ/リードオンリー構成
Db2 Mirror では、あるノードから複製オブジェクトへの変更を開始できないように構成することもできます。
この設定は読み取り専用環境と呼ばれ、Db2 Mirror によって強制されるアクティブ/パッシブ構成です。この設定では、プライマリノードのみが複製オブジェクトへの変更を開始できます。セカンダリノードはプライマリノードからの変更と同期された状態を維持します。セカンダリノード上のアプリケーションとユーザーは、本番環境のデータを読み取ることはできますが、変更することはできません。
下図ではNode2が読み取り専用状態で、Node1とNode2間の同期を示しています。
3.Db2 Mirror アクティブ/アクティブ構成
負荷分散のために、ユーザーとアプリケーションを両方のノードに分散する事を目的とします。
複製されたデータへの更新は同期されるため、両方のノードのユーザーは同じデータを参照できます。IBM i OSは、クロスノード・ロックを使用してデータ整合性を確保します。1つのノードが使用できなくなった場合、ユーザーとアプリケーションをアクティブ・ノードにリダイレクトできます。
上記1～3いずれの環境でもアプリケーションを変更することなく、実稼働のダウンタイムを削減できます。
Db2 Mirror for i の目的
実稼働環境における一般的な課題の 1 つは、システムまたはアプリケーションの保守のためのダウンタイムです。Db2 Mirror for i は IPL や更新によって発生する計画停止を削減 (場合によっては完全に排除) できます。レプリケーションを一時的に中断して、一方のノードでトランザクション処理を継続しながら、もう一方のノードで IPL または更新を実行できます。IPL が終了し、通信が再開されると、Db2 Mirror は追跡された変更を 2 番目のノードにプッシュし、データベースを再同期します。その後、レプリケーションを再度中断し、最初のノードで IPL または更新を実行することで、このプロセスを元に戻すことができます。
同様のローリング アップグレード戦略を使用して、サーバーまたはストレージ ハードウェアを更新できます。
レプリケーションを中断しながら 1 つのノードをアップグレードし、もう一方のノードで実動を継続できます。レプリケーションを再開して、アップグレードされたノードのデータを最新にすることができます。
その後、レプリケーションを再度中断して、2 番目のノードをアップグレードできます。
同期的に複製されたデータベース・アーキテクチャーを使用することで、スイッチオーバー時間を短縮し、計画外停止時のデータ損失を最小限に抑えることができます。Db2 Mirrorは、データセンター内でこの目標を達成するのに役立ち、既存のほとんどの災害復旧戦略と連携します。
データはノード間で同期的に複製されるため、目標復旧ポイント（RPO）と目標復旧時間（RTO）をほぼゼロにまで短縮できます。実稼働停止時間を短縮するためにアプリケーションを変更する必要はありません。アプリケーションが継続的な可用性を実現するように設計されている場合は、RTOがさらに大幅に改善されます。