7.2章 PowerHA SystemMirror for IBM i
PowerHA SystemMirror for IBM i は IBM i OSとは独立して開発されているため、新機能や更新機能は、IBM i OSバージョン毎にサポートされる機能について相違があります。このセクションでは、PowerHA の最近の更新内容をいくつか紹介します。
PowerHA SystemMirror for i バージョン 6.0.3 の拡張
PowerVSでの LUN レベルのスイッチングとFlashCopy サポートが含まれています。これらの新機能により、PowerHA はオンプレミス環境とほぼ同等の機能を実現できるようになりました。
LUN レベルのスイッチングと IBM PowerVS の FlashCopy サポート
この新機能により、PowerHA はオンプレミス環境とほぼ同等の機能レベルを実現しています。詳細については、IBM PowerHA SystemMirror for IBM iを参照。
マルチターゲット・ジオグラフィック・ミラーリング
この機能でPowerVSでシステム間でボリュームセット（ストレージLUN）を切り替えることができます。同じPower Virtual Serverワークスペース内（＝同一データセンター）内の2つのIBM iクラスターノード間で使用され、多くの場合、グローバルレプリケーションサービス（GRS）などのテクノロジーと組み合わせて使用されます。これらの機能を組み合わせることで、データセンター内のローカルな高可用性が実現されます
ASP ボリューム（LUN レベル）スイッチング
ボリュームスイッチングを使用すると、システム間でIASPとして定義されたストレージボリューム(LUN）を切り替えることができます。
このテクノロジーは、同じ PowerVSワークスペース（データセンター）内の 2 つの IBM i クラスターノード間で使用され、多くの場合、グローバルレプリケーションサービス（GRS）などのテクノロジーと組み合わせて使用されます。これらの機能を組み合わせることで、データセンター内のローカルな高可用性が実現され、GRS を使用してリモートサイトにデータを複製することで、障害からの保護が可能になります。
iASP FlashCopy
IBM PowerHA SystemMirror for i は、PowerVSのiASP でストレージ FlashCopy をサポートしています。この機能はバックアップ取得を別のノード(LPAR）にオフロードすることで業務稼働環境のバックアップウィンドウを最小化できます。通常バックアップはフラッシュコピーで取得した複製ボリュームに対して行います。オンプレミスの FlashCopy と同様の自動化と機能が提供されます。PowerVS の FlashCopy を、Geographic Mirroring や Global Replication Services (GRS) などのテクノロジーと組み合わせることで、オールクラウドおよびハイブリッドクラウドの導入が可能です。詳細は、PowerHA SystemMirror for i を参照。
Cloud Storage Solutions for i
IBM Cloud Storage Solutions for i (5733-ICC) は、AWS S3プロトコルを介して、多くのクラウドベースのストレージ・ソリューションへのネイティブ IBM i 接続を提供します。この機能により、IBM i はファイルやその他のオブジェクトをクラウドベースのストレージに直接保存できます。 IBM i のデータとファイルをクラウドに保存する手段を提供し、BRMS を使用すればより高度にオンプレバックアップ環境と同様な統合バックアップをクラウドベースで展開できます。Cloud Storage Solutions用のCLコマンドを使用してIBM i からクラウド上のICOSオブジェクトストレージなどを直接操作することも、アプリケーションから Cloud Storage Solutions API を介してアクセスすることも可能です。
現時点での最新バージョンは 1.2 です。このリリース以降、FTPS プロトコルはサポートされなくなりました。以前のバージョンでFTPSを使用していた場合、より安全なプロトコルに移行が必要です。
IBM Db2 Mirror for i (5770-DBM)
Oracle RACなどとは別なアーキテクチャーですが、データベースのリアルタイム冗長化構成を可能とします。結果ほぼゼロダウンタイムを実現でき計画停止時および計画外停止時の両方で業務を継続できます。
例としてPTF（グループPTF、テクノロジー・リフレッシュ (TR)、個別PTF）適用、OSリリース・アップグレードなどをダウンタイムなしで実行可能にできます。
下図のようにDb2 MirrorのIBM i 7.6 GUIは、最新のブラウザーベースUIに刷新されました。2つのDb2 Mirrorノードのいずれか、または別の3つ目のIBM iノード上で実行できます。 GUIはDb2 Mirror (5770-DBM *BASE) の基本構成に含まれており、ライセンスキーは不要です。3つ目のIBM i ノードでGUIを実行する場合、環境の管理にDb2 Mirror製品の追加オプションは必要ありません。
現時点で最新のソフトウェア要件
Db2 Mirror for i のIBM i 7.6リリース時点アップデート
単一の複製オブジェクトとその複製従属オブジェクトを手動で再クローンする新しいプロセスを追加
Db2 Mirror GUI はIBM i ファミリーの他のGUIインターフェースと調和した最新のUIに更新されました。
1つはIBM i 7.4 または IBM i 7.5、もう1つはIBM i 7.6 の混合リリースの Db2 Mirror 環境をサポート
詳細は以下を参照。
混合リリースの Db2 Mirror 環境
混合リリース環境で実行する場合のアプリケーションの動作
(システム管理のベスト・プラクティス)[https://www.ibm.com/docs/en/i/7.6.0?topic=outages-best-practices-system-management]
パフォーマンス強化、新規サービスと更新サービス、および権限の変更
IBM i 7.6 の Db2 mirror for i のすべての変更点を確認するには、IBM i 7.6 の新機能を参照。
Db2 Mirror for i がサポートするPOWERハードウェア
Db2 Mirror は、IBM Power8®、POWER9®、Power10、またはそれ以降のシステムをサポートします。リモート・ダイレクト・メモリー・アクセス (RDMA) ネットワーク・プロトコルとそれに関連するハードウェアを使用して接続された 2 つの IBM i LPAR が必要です。
Db2 Mirror for i の概要
下図は個別のDb2 for iインスタンスを持つ2つの IBM i LPARです。 (Db2 Mirror では各々のLPARをノードと呼ぶ）。Db2 Mirror for i により、IBM i OSは両方のノード間でDb2 for iのデータベースオブジェクト（DDSインターフェース作成、SQLベース作成を問わずすべて）を同期します。 いずれかのノードでデータが変更されると、Db2 Mirror は自動的に同期レプリケーションを使用して、2 つのインスタンスを同一に保ちます。
一方のノードが使用できない場合、Db2 Mirror はアクティブ・ノード上の複製オブジェクトへのすべての変更を追跡します。ミラーリングされたペアが再接続されると、Db2 Mirror はすべての変更を同期し、両方のデータベースが再び同一になります。 Db2 Mirror は、SYSBAS または IASP のいずれかに存在するライブラリーとオブジェクトをサポートします。
Db2 Mirror for i のアドバンテージ
ユーザーやアプリケーションは、同期レプリケーションによって2つのノードが同一に保たれていることを意識する必要はほとんどありません。両方のノードのデータが本番環境として使用できます。
2つのノードの役割（アクセス・同期方法）により以下の二種類の構成が可能です。
アクティブ/パッシブ環境
一方のノードでアプリケーションを実行し、もう一方のノードをアクティブ/スタンバイモードにして、本番環境のライブデータを準備しておくことができます。
ユースケース例としては、リアルタイムのデータ分析が必要な場合、スタンバイモードのノードを使用できます。1つのノードで本番環境を実行し、もう一方のノードでリアルタイムクエリーとビジネスインテリジェンスを実行できます。本番ノードのパフォーマンスに影響を与えることはありません。
アクティブ/読み取り専用環境
上記のアクティブ/パッシブ構成で、複製先ノードではオブジェクトへの変更を不可にした構成です。
この設定では、プライマリノードのみがレプリケートされたオブジェクトへの変更を開始できます。セカンダリノードはプライマリノードからの変更・同期状態を維持します。セカンダリノード上のアプリケーションとユーザーは本番環境のデータを読み取ることはできますが、変更することはできません。
アクティブ/アクティブ構成
負荷分散のために、ユーザーとアプリケーションを両方のノードに分散して実行できます。この設定はアクティブ/アクティブ環境と呼ばれます。複製されたデータへの更新は相互のLPAR間で同期されるため、両方のノードのユーザーは同じデータを参照できます。IBM i オペレーティング・システムは、クロスノード・ロックを使用してデータ整合性を確保します。1つのノードが使用できなくなった場合、ユーザーとアプリケーションをアクティブ・ノードにリダイレクトできます。
これらの環境すべてにおいて、アプリケーションを変更することなく、実稼働のダウンタイムを削減できます。
IBM i 混合リリース間での Db2 Mirror for i
実稼働環境における一般的な課題の 1 つは、システムまたはアプリケーションのメンテナンス・ダウンタイムです。Db2 Mirror for iを使用してIPL やPTF適用等の計画停止を削減、あるいは完全に排除できます。
レプリケーションを一時的に中断することで、一方のノードで IPL または更新が行われている間も、もう一方のノードでトランザクション処理を継続できます。IPL が終了し、通信が再開されると、Db2 Mirror は追跡された変更をもう一方のノードにプッシュし、データベースを再同期します。その後、レプリケーションを再度中断し、最初のノードで IPL または更新を行うことで、このプロセスを元に戻すことができます。
同様にローリング・アップグレード方式で、サーバーまたはストレージ・ハードウェアをシステム停止を最小化またはゼロ化して更新できます。
レプリケーションを中断している間に一方のノードをアップグレードし、もう一方のノードで実稼働を継続できます。レプリケーションを再開して、アップグレードされたノードのデータを最新の状態にすることができます。
その後、レプリケーションを再度中断して、もう一方のノードをアップグレードできます。
下図のようにIBM i OSおよび関連ソフトウェア製品のバージョン、リリース、PTFレベルは、Db2 Mirrorノード間で同一である必要はありません。ローリング・アップグレードのシナリオは、PTFレベルの違いだけでなく、異なるIBM i オペレーティング・システム・レベルでDb2 Mirrorノードを実行することもサポートします。
リアルタイムで複製された2つのデータベースを使用することで、切り替え時間を短縮し、計画外停止時のデータ損失を最小限に抑えることができます。Db2 Mirrorは、データセンター内でこの目標を達成するのに役立ち、既存のほとんどの災害復旧戦略と連携します。
データはノード間で同期的に複製されるため、目標復旧ポイント（RPO）と目標復旧時間（RTO）をほぼゼロにまで短縮できます。実稼働停止時間を短縮するためにアプリケーションを変更する必要はありません。アプリケーションが継続的な可用性を実現するように設計されている場合は、RTOがさらに大幅に改善されます。
Db2 Mirror for i のソフトウェア要件
IBM i 7.4 以降でサポートされます。
Db2 Mirror 環境を構成するためのセットアップ・プロセスを開始する前に、最新レベルの PTF グループをインストールして環境を準備することを推奨。
セットアップ・ソース・ノードに、以下に記載されている最新レベルの PTF グループをインストールを推奨。（以下はIBM i 7.6のPTF番号です）
CUM PTF SF99760
Db2 Mirror for i PTF Group SF99961
Db2 for i PTF Group SF99960
管理ノードには以下に記載されている最新レベルの PTF グループをインストールを推奨。（以下はIBM i 7.6のPTF番号です）
Db2 Mirror for i PTF Group SF99961
IBM HTTP Server for i PTF Group SF99962
Java PTF Group SF99965
PTFレベルを確認するための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;