このドキュメントでは、同種の Db2 を Compute Engine に移行する際のベスト プラクティスについて説明します。Db2 環境を Google Cloud に移行するデータベース管理者、システム管理者、ソフトウェア エンジニア、データベース エンジニア、オペレーション エンジニアを対象としています。Db2 から他のタイプのデータベースへの移行については、このドキュメントでは取り扱いません。
用語
- IBM Db2
- レプリケーション機能とフェイルオーバー機能を備えたエンタープライズ クラスのリレーショナル データベース管理システム（RDBMS）。
- 高可用性障害復旧（HADR）
- データベースに記録されたアクティビティを使用して、プライマリ データベースからスタンバイ データベースにデータを複製する Db2 の機能。この機能により、手動でプライマリ データベースからスタンバイ データベースにフェイルオーバーできます。
- プライマリ
- Db2 をホストするマシンで、書き込みリクエストと読み取りリクエストを受け入れます。このマシンは、レプリケーションをスタンバイ マシンへ移行する際の移行元です。
- プリンシパル スタンバイ
- 読み取りリクエストのみを受け入れることができるスタンバイ マシン。このマシンは、Db2 で許可されている同期モードをサポートしており、HADR 用にフェイルバック インスタンスとして指定されています。IBM Db2 では、クラスタ内で 1 台のマシンのみが許可されます。
- 補助スタンバイ
- 読み取りリクエストのみを受け入れることができるスタンバイ マシン。このマシンは SUPERASYNC 同期モードのみをサポートしています。メイン データセンターに障害が発生した場合の手動フェイルオーバーに備えて、プライマリ マシン以外のデータセンターに配置されます。
- Tivoli System Automation for Multiplatforms（TSA/MP）
- プライマリ データベースからプライマリ スタンバイへの自動リソース フェイルオーバーを容易にするクラスタ管理ソフトウェア。このソフトウェアには、クラスタの一部として定義されているネットワーク、ストレージ、コンピューティング リソースが含まれています。Db2 エンタープライズ エディションには HADR の TSAMP エンタイトルメントが含まれています。
- 自動クライアント リルート（ACR）
- サーバーで障害が発生した際、別のサーバーにアプリをリダイレクトする Db2 の機能。この機能により、中断による影響を最小限に抑えて、アプリの動作を維持できます。
- 変更データ キャプチャ（CDC）
- 他のデータベースとのデータ同期や監査証跡の作成など、データベースの変更を検出するための一連の手法やツール。
アーキテクチャ
Db2 クラスタは通常、少なくともプライマリ スタンバイ ノードとプリンシパル スタンバイ ノードから構成され、それらの間に HADR があります。Db2 の新しいバージョンでは、DR 用に役立つ補助スタンバイ ノードを追加できます。
次の図は、移行元の環境を示しています。
この環境では、プライマリ スタンバイとプリンシパル スタンバイは、1 つのデータセンターにあり、補助スタンバイは、別のデータセンターにあります。
移行の目標は、次の図に示すように、Google Cloud でこの環境を再作成することです。
次の表は、各移行タイプの要素を比較したものです。
| Migrate to Virtual Machines | Q レプリケーション | SQL レプリケーション | HADR | |
|---|---|---|---|---|
| 移行元 | VMware、Amazon Web Services (AWS) VM | ライセンスに基づく任意の Db2 環境 | 任意の Db2 環境 | 任意の Db2 環境 |
| 複製対象 | ブロックレベルのディスク レプリケーション | データベース内のテーブル | データベース内のテーブル | データベース全体 |
| カットオーバー | VM が Google Cloud で起動するまでに数分必要 | アプリと DNS を Compute Engine インスタンスに指定する | アプリと DNS をクラウド インスタンスに指定する | アプリと DNS をクラウド インスタンスに指定する |
| DDL による変更レプリケーション | ○（ディスク書き込みを複製） | ○ | はい | ○ |
| データの同期レプリケーション | 該当なし | なし | ○ | ○ |
| データの非同期レプリケーション | 該当なし | ○ | ○ | ○ |
| ポイントインタイム データの複製 | × | ○ | はい | × |
上の表をガイドとして使用すると、システムの可用性要件とリソースの作業量レベルを一致させることができます。これにより、ターゲット システムの設定、レプリケーションの設定、レプリケーションの時系列での維持とテストを行うことができます。この表は、Migrate to VMs が、実装するのに最も簡単なアプローチであるが、システムの可用性の点では柔軟性が最も低いことを示していますHADR、Q レプリケーション、SQL レプリケーションでは、システムの可用性への影響が小さくなります。ただし、並列モデルでレプリケーションを設定して維持する必要があり、より高いレベルの作業量が必要になります。
移行タイプ
Db2 を Compute Engine に移行する方法は 2 つあります。
- 既存のクラスタ構成またはトポロジを変更することによる移行。
- データをまったく新しいクラスタに複製することによる移行。
既存のクラスタを変更する移行方法では、クラウド内でまったく新しいクラスタを起動する必要がなくなり、高速化が可能になります。もう 1 つの移行方法では、新しいクラスタを Google Cloud にデプロイする必要があります。ただし、レプリケーションが帯域外であるため、既存のクラスタにはあまり影響しません。この方法は、データベースの一部だけを複製する場合や、データが移行先に到達する前に変換する場合に便利です。
以下のセクションでは、Db2 インスタンスを Google Cloud に移行する前の検討事項について説明します。よく使用される機能の中には、Google Cloud でそのまま機能しないものや、構成変更が必要なものがあります。
フローティング（仮想）IP アドレス
高可用性 Db2 クラスタでは、TSA/MP は、プライマリ ノードに仮想 IP アドレスを割り当てることができます。このアドレスはフローティング IP アドレスとも呼ばれ、トラフィックはスタンバイ ノードではなく、常にプライマリ ノードにルーティングされます。
Compute Engine は Virtual Private Cloud（VPC）ネットワークで仮想化されたネットワーク スタックを使用します。そのため、一般的な実装メカニズムは機能しない可能性があります。たとえば、VPC ネットワークは、構成されたルーティング トポロジに基づいて Address Resolution Protocol（ARP）リクエストを処理し、Gratuitous ARP フレームを無視します。また、Open Shortest Path First Protocol（OSPF）や Border Gateway Protocol（BGP）などの標準ルーティング プロトコルを使用して、VPC ネットワーク ルーティング テーブルを直接変更することはできません。したがって、フローティング IP アドレスの代替アプローチを実装するか、ACR を使用する必要があります。
Db2 クラスタの一部またはすべてのノードを移行する場合は、クラスタのフローティング IP アドレスを無効にしてから、ノードを移行してください。
ACR
Db2 環境で ACR を使用する場合は、DNS 名が変更されたときや、クライアントが IP アドレスを使用して接続するときには、クライアントのカタログを変更する必要があります。
タイブレーカー
TSA/MP では、自動化操作を開始するために、大部分のクラスタノードがオンラインになっている必要があります。クラスタが偶数個のノードから構成されている場合、クラスタのちょうど半分のノードがオンラインになり、スプリット ブレインが生じる可能性があります。この場合、TSA/MP はタイブレーカーを使用して、クォーラム（過半数グループ）状態を決定し、自動化操作の開始の可否を判断します。
Db2 環境で使用される次のタイブレーカーを検討してください。
- ストレージまたはディスク タイブレーカー。Ibm Db2 はディスク予約を使用してスプリット ブレインの状態を解消します。Google Cloud では予約が利用できないため、他のタイプのタイブレーカーを選択する必要があります。
- ネットワーク タイブレーカー。（クラスタへの）外部 IP アドレスを使用してスプリット ブレインの状態を解消します。ハイブリッド デプロイでは、クラスタのノードからアクセス可能な限り、最初からネットワーク タイブレーカーを Google Cloud に移行する必要はありません。ただし、クラスタを Google Cloud で実行した後は、タイブレーカーを別のゾーンに作成するか、Google Cloud メタデータ サーバーをタイブレーカーとして使用することをおすすめします。
- NFS タイブレーカー。NFS タイブレーカーは、NFS v4 サーバーに格納されている予約ファイルに基づいてスプリット ブレインの状態を解消します。ネットワーク タイブレーカーと同様に、NFS タイブレーカーと NFS v4 サーバーもハイブリッド デプロイで移行元の場所に残すことができます。その後、NFS サーバーをデプロイするか、Elastifile のようなパートナーを Google Cloud で NFS タイブレーカーの対象として使用することをおすすめします。
Migrate to VMs を使用した移行
次の 2 つが使用中の環境に該当する場合は、Migrate to VMs の使用をおすすめします。
Amazon Elastic Compute Cloud（Amazon EC2）上に VMware vCenter 環境または仮想マシンがある。
Google Cloud から Cloud VPN や Cloud Interconnect などの環境へのプライベート接続がある。
Migrate to VMs は、仮想マシンをオンプレミス環境とクラウド環境から Google Cloud に移行するためのものです。それによって、Google Cloud に仮想マシンを数分で移行できます。データはバックグラウンドでコピーされますが、仮想マシンは完全に機能しています。移行元の環境と Google Cloud プロジェクト（Cloud VPN、Cloud Interconnect、Partner Interconnect など）との間にプライベート接続が必要です。
Migrate to VMs では、クラウド VM のデータベース構成を再評価する必要があります。レジストリ変数、バッファプール、データベース マネージャー構成、データベース構成など、Google Cloud 用に最適化されていない構成もあります。AUTOCONFIGURE ユーティリティを使用して、ベースラインから開始できます。
Migrate to VMs の運用方法については、VM Migration のライフサイクルをご覧ください。
次のセクションでは、この方法を Db2 環境に適用する方法について概説します。
テストクローン
テストクローンは、vCenter 環境でのみ使用できます。
Migrate to VMs は、VM のスナップショットをとり、そのスナップショットに基づいて Google Cloud 上にすぐに使えるコンピューティング インスタンスを作成できます。Google Cloud 上での Db2 環境の再作成、構成変更の試行、テスト、デプロイのベンチマークを、移行元の環境に影響を与えることなく行えます。
次の図は、Migrate to VMs のテストクローン作成後の Google Cloud 上の DB2 環境と Google Cloud 上の並列環境を示しています。
Google Cloud 上でテストクローンのベンチマークとテストをした後には、テストクローンを削除できます。
クラウド内実行
クラウド内実行を有効にすると、Migrate to VMs は移行元のクラスタをシャットダウンして、Google Cloud 上で VM を起動します。この際、ストレージ全体を Google Cloud にストリーミングすることはせず、必要なデータだけを取得します。クラウド内実行は書き戻しをサポートしており、デフォルトで有効になっています。Migrate to VMs は、ストレージを積極的にストリーミングする前に、環境をテストするのに役立ちます。切り戻し機能を使用して、VM を移行元の環境に戻すこともできます。クラウドからクラウドへの移行では、移行元に書き戻した内容を複製することはできません。
次の図は、すべてのノードをクラウドで実行するように設定した場合の、Run-in-cloud フェーズを示しています。一度にクラスタ全体を移行するのではなく、徐々にクラスタノードを移行することもできます。
移行
移行フェーズはクラウド内実行フェーズと似ていますが、Migrate to VMs でもストレージを Google Cloud に全面的にストリーミングします。クラウド内実行フェーズ中は、VM を完全に移行する準備ができたことを示されていないことから、Migrate to VMs は帯域幅を節約するためにオンデマンドでのみデータを送信します。
切断
このフェーズの間は、Migrate to VMs はキャッシュとオブジェクト ストアから Google Cloud 上のネイティブ データディスクにデータを同期してから、ディスクを VM にアタッチします。このフェーズでは、Google Cloud 上の VM をシャットダウンする必要があります。Db2 の場合、クラスタのノードを一度に 1 つずつ接続解除することをおすすめします。
レプリケーションの使用
Db2 の場合、レプリケーションとは、取得プログラムと呼ばれるプログラムを使用してトランザクション ログから変更をキャプチャし、適用プログラムを使用して別のクラスタに適用するプロセスのことを指します。取得プログラムが変更をキャプチャする方法と、適用プログラムへの変更の送信に使用される通信チャネルのタイプは、レプリケーション タイプによって異なります。
次の図は、Db2 レプリケーションにおける情報の論理的なフローを示しています。
取得アプリはデータベースから変更をキャプチャし、その変更を適用アプリに送信します。適用アプリは、これらの変更を移行先のデータベースに書き込みます。アプリはデータそのものに変換を加えることができます。取得アプリと適用アプリは、必ずしもデータベース サーバー上で実行する必要はありません。
SQL レプリケーション
SQL レプリケーションは、移行元のテーブルとビューに対する変更をキャプチャし、ステージング テーブルを使用して commit されたトランザクション データを格納します。変更はステージング テーブルから読み取られ、対応する移行先のテーブルに複製されます。このドキュメントの作成時点で、Db2 のインストール時に SQL レプリケーションを設定できます。
SQL レプリケーションを使用した移行プロセスは次のようになります。
- Db2 を Google Cloud 上にデプロイする。
- SQL レプリケーションを構成する。
- SQL レプリケーションを開始する。
- デプロイが同期していることを確認する。
- アプリを Google Cloud インスタンスに指定する。レプリケーションを停止する。
次の図は、SQL レプリケーションの例です。
本番環境は通常どおりに動作した状態で、Google Cloud 上に作成する新しいクラスタに SQL コマンドが複製されます。上の図では、レプリケーション プロセスはプライマリ インスタンス上で実行されますが、他にこのドキュメントでは扱わないデプロイ方法もあります。
Q レプリケーション
Q レプリケーションは、SQL レプリケーションよりも新しく、より効率的な方法で、ある Db2 インスタンスから別の Db2 インスタンスにデータを複製します。この方法では、IBM MQ を使用してデータ変更エントリを送ります。そのため、移行元の環境と移行先の環境に IBM MQ のインスタンスをデプロイする必要があります。このレプリケーション方法はメモリ内で行われるので、SQL レプリケーションより高速です。SQL レプリケーションはより低速ですが、通常 Q レプリケーションでは IBM MQ を設定する必要があり、設定がより難しくなります。Db2 ライセンスによっては、Q レプリケーション用のライセンスを取得する必要があります。
Db2 Q レプリケーションを開始するには、次の 2 つの方法があります。
自動読み込み。Q レプリケーション プロセスで初期読み込みを実施します。これにより、移行元のバックアップから移行先にデータベースが復元されます。
手動読み込み。初期読み込みを実施し、ログ内の特定の位置からレプリケーションを開始します。
移行プロセスは次のようになります。
- Google Cloud 上および移行元の環境で IBM MQ をデプロイする。
- Db2 を Google Cloud 上にデプロイする。
- Q レプリケーションを構成する。
- Q レプリケーションを開始する（手動読み込みまたは自動読み込みのいずれかを使用）。
- 2 つのデプロイが同期していることを確認する。
- アプリケーションを Google Cloud インスタンスに指定する。レプリケーションを停止する。
次の図に、Q レプリケーション ソリューションの一例を示します。
移行元の環境では、IBM Q レプリケーションを使用してデータベースの変更を IBM MQ と移行先の環境に送信し、Db2 クラスタを Compute Engine に拡張します。
このアプローチでは、既存の Db2 クラスタを徐々に Compute Engine に移行し、ノード間のデータ転送を HADR に委ねます。
このアプローチは、次の条件を満たす場合に使用してください。
- 新しいクラスタの全体を Compute Engine にデプロイしたくない場合。
- Migrate to VMs は利用できません。
- レプリケーションのオプションのいずれかが使用できない場合。
- （ライセンス、コスト、コンプライアンス上の理由などにより）パートナー プロダクトを使用しない、または使用できない場合。
Db2 バージョンが補助スタンバイをサポートしていない場合
以下の操作を行います。
- Db2 インスタンスを Compute Engine にデプロイする。
- プライマリ インスタンスからバックアップを取る。
- バックアップから Compute Engine 上の Db2 インスタンスを復元する。
- HADR セットアップからスタンバイ インスタンスを削除する。
- Compute Engine Db2 インスタンスをスタンバイとして接続する（同期モードを選択できますが、レイテンシが高くなる可能性があるため、
ASYNCまたはNEARASYNCが望ましい場合もあります）。 - Compute Engine Db2 インスタンスにフェイルオーバーし、それを HADR プライマリにする。
- 別の Compute Engine Db2 インスタンスを作成して、それをバックアップから復元し、HADR スタンバイとして設定する。
次の図の最初の手順は、Google Cloud 上に新たに Db2 インスタンスが作成され、移行元の Db2 プライマリのプリンシパル スタンバイとして設定された状態を示しています。
上の図では、Google Cloud インスタンスが HADR プライマリになります。次に、移行元のプリンシパル スタンバイを削除し、Compute Engine 上の別の Db2 インスタンスをプリンシパル スタンバイ インスタンスとして接続します。
Db2 バージョンが補助スタンバイをサポートしている場合
まず、Db2 バージョンが補助スタンバイをサポートしていない場合と同じ手順を実行し、最後に補助スタンバイ インスタンスを移行する方法があります。
もう 1 つのオプションは、補助レプリカを活用して、よりフォールト トレラントな状態で Google Cloud への移行を行うことです。これは、移行元の環境にはプライマリもプリンシパル スタンバイもなく、もう片方は Google Cloud 上にあるためです。この 2 つ目のオプションの手順の概要を次のリストで示します。
- Compute Engine 上の Db2 インスタンスをそれぞれのロケーションにデプロイします（必要に応じて、プライマリ、プリンシパル、補助インスタンスをデプロイします）。
- 移行元のクラスタから補助スタンバイ ノードを削除します。
- 移行元のクラスタの補助スタンバイのプライマリになるノードと、プリンシパルになるノードを構成します。
- Compute Engine インスタンスのテイクオーバーを実行します。このインスタンスはプライマリ インスタンスになります。他の Compute Engine インスタンスの 1 つをプライマリ インスタンスのプリンシパル スタンバイとして構成します。
次の図の最初の手順は、Compute Engine 上で新たに作成された 2 つの Db2 インスタンスを示しています。
これらのインスタンスは、移行元の環境の補助インスタンスではなく、移行元の Db2 プライマリ インスタンスの補助スタンバイとして設定されています。Compute Engine インスタンスのいずれかへのテイクオーバーが開始されると、そのインスタンスは HADR プライマリになり、もう一方のインスタンスがプリンシパル スタンバイとして構成されます。最後の手順では、補助スタンバイとして 2 つのインスタンスが構成されます。
パートナー プロダクト
Google には、このような移行に役立つプロダクトを提供するパートナーがいます。これらのプロダクトのほとんどは CDC を使用して、移行元の Db2 と移行先の Db2 との間でデータを複製します。これらのプロダクトは Google Cloud のプロダクトではないため、プロダクトやサービスごとにライセンスと料金を確認する必要があります。通常、このサービスは既存のクラスタのデータを Google Cloud 上に作成した別のクラスタに複製しますが、全体的なアプローチはこのドキュメントで説明する複製のシナリオと似ています。
パートナー プロダクトは次のとおりです。
次のステップ
- IBM Db2 for SAP プランニング ガイド。
- Google Cloud データベース移行センター。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。