 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Microsoft Cluster Serverを使用したDB2 UDB for Windows高可用性サポート- 概要 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
要約
DB2 EEE はマシン間にリソース競合のないシェアード・ナッシング・ハードウェア・アーキテクチャーで稼動するように構成できます。各マシンはそれ自体のディスクとメモリーに対する排他的アクセスを持っています。この環境で稼動する場合、データベースは複数区画に分割され、各区画はデータベース区画サーバー (またはノード) によって管理されます。 データは複数のデータベース区画に分割されるため、複数の物理ノード上の複数のプロセッサーのパワーを使用して、情報要求を満たすことができます。データ検索と更新要求は、自動的にサブ要求に分解され、複数の適切なデータベース区画で並列に実行されます。データベースが複数データベース区画にわたって区分化されているという事実は、SQL ステートメントを発行するユーザーには透過的です。 ユーザー対話は、そのユーザーに対するコーディネーター・ノードとして知られる 1 つのデータベース区画を経由して行われます。コーディネーターはアプリケーションと同じデータベース区画か、リモート・アプリケーションの場合はアプリケーションが接続されたデータベース区画上で稼動します。 1 台のマシン上に複数のデータベース区画がある場合、これら区画はプロセッサーを共用することもあるので、論理データベース区画と呼ばれます。ただし、論理区画間ではデータとメモリーは共用されません。論理データベース区画を実行できるので、1 台のマシンに障害が発生したときに、EEE は相互テイクオーバー・シナリオでサポートされます。障害の発生したマシン上のデータベース区画は、1 つ以上のアクティブなデータベース区画をすでに持つ他のマシン上で再始動できます。 MSCS は DB2 EEE 製品の前提条件ではないことに注意してください。DB2 EEE は MSCS と統合して、高可用性をサポートします。
アーキテクチャーの概要 DB2 MSCS コンポーネント クラスターは、それぞれが独立したコンピューター・システムである複数のノードで構成されます。ネットワーク・クライアントには、クラスターは 1 台のサーバーとして映ります。 
図 1. DB2 MSCS 基本アーキテクチャー MSCS クラスター内のノードは、1 つ以上の共用ストレージ・バスと、物理的に独立した 1 つ以上のネットワークを使用して接続されます。サーバーしか接続せず、クライアントをクラスターに接続しないネットワークをプライベート・ネットワークといいます。クライアント接続をサポートするネットワークをパブリック・ネットワークといいます。 各ノードには 1 つ以上のローカル・ディスクがあります。各共用ストレージ・バスは 1 台以上のディスクに接続します。共用バス上のそれぞれのディスクを所有するのは、一時点で 1 つのクラスター・ノードだけです。DB2 ソフトウェアはローカル・ディスク上に存在します。DB2 データベース・ファイル (表、索引、ログ・ファイルなど) は共用ディスク上に存在します。 MSCS はクラスター内のロー区画の使用をサポートしないため、MSCS 環境でロー・デバイスを使用するように DB2 を構成することはできません。 DB2 リソース MSCS 環境では、リソースはクラスタリング・ソフトウェアによって管理されるエンティティーです。たとえば、ディスク、IP アドレス、あるいは汎用サービスは、リソースとして管理対象です。DB2 は「DB2」という独自のリソース・タイプを作成することで、MSCS と統合します。各 DB2 リソースは DB2 インスタンスを管理します。区分化データベース環境で稼動する場合は、各 DB2 リソースはデータベース区画を管理します。DB2 リソースの名前はインスタンス名です。ただし、区分化データベース環境の場合、DB2 リソースの名前は、インスタンス名と区画 (またはノード) 番号で構成されます。 例を次に示します。 リソース「DB2」は、シングル区画インスタンス「DB2」を管理します。 リソース「DB2MPP-0」は、区分化インスタンス「DB2MPP」の論理ノード 0 を管理します。 オンラインになる前後のスクリプト DB2 リソースがオンラインにされる前後に、スクリプトを実行できます。これらのスクリプトはそれぞれ、オンライン前およびオンライン後スクリプトといいます。オンライン前およびオンライン後スクリプトは .BAT ファイルであり、DB2 コマンドおよびシステム・コマンドを実行できます。 DB2 の複数のインスタンスが同一マシン上で稼動する状況では、オンライン前およびオンライン後スクリプトを使用して、両インスタンスを正常に起動できるように、構成を調整できます。フェイルオーバーが発生すると、オンライン後スクリプトを使用して、手動のデータベース・リカバリーを実施できます (後述のフェイルオーバーの説明を参照してください)。オンライン後スクリプトは、DB2 に依存する任意のアプリケーションやサービスの起動にも使用できます。 DB2 グループ 関連または従属リソースは、リソース・グループに整理されます。1 つのグループ内の全リソースがクラスター・ノード間で 1 つの単位として移動します。典型的な DB2 EE クラスター環境では、次のようなリソースを含む DB2 グループがあります。
DB2 リソースは同一グループ内の他のすべてのリソースに従属するように構成されるので、DB2 サーバーは他の全リソースがオンラインになった後でのみ、開始できることに注意してください。
2ノードの単一区画データベース (EE) ホット・スタンドバイ構成 この設定では、ワークグループ・エディション (WE) かエンタープライズ・エディション (EE) のいずれかが稼動する DB2 インスタンスは、2 ノード MSCS クラスター上で稼動するように構成されます。 1 次 DB2 ノードと呼ばれる 1 つのノードが全 DB2 クライアントをサポートする一方で、もう一方のノードはアイドル状態です。後者のノードは専用の「ホット・スペアー」で、フェイルオーバーが発生したときにいつでも使用可能な状態にあります。1 次ノードに障害が発生すると、ホット・スペアーは即座にリソース (ディスク、IP アドレス、ネットワーク名) を引き継ぎ、DB2 サーバーを再始動して、1 次ノードのパフォーマンスに非常に近いレベルか同等レベルで、クライアントにサービス提供を続けます。  図 3. 2ノードのホット・スタンドバイ構成 この構成では、可用性とパフォーマンスは最高になりますが、ほとんど使用されない状態にあるハードウェアへの投資が必要になります。したがって、これはマシン
(CPU、メモリー) 追加の経費を正当化できるような、組識の最重要アプリケーションに適しています。ディスクは共用されるため、ホット・スペアー・ノードにストレージ容量を追加する必要はないことに注意してください。
2ノードの EE 相互テイクオーバー構成 この設定では、DB2 ワークグループ・エディションか DB2 エンタープライズ・エディションのいずれかが稼動する 2 つの DB2 単一区画インスタンスは、2 ノードの MSCS クラスター上で稼動するように構成されます。 DB2 は同一マシン上で、データベース・サーバーの複数インスタンスの実行をサポートします。1 つのノードに障害が発生すると、そのノード上のインスタンスは、すでにアクティブなインスタンスのある他のノード上で再始動されます。フェイルオーバー後、DB2 の両インスタンスは、同一ノード上で並行稼動します。
たとえば人事データベースやマシン在庫管理データベースなど、2 つの独立したデータベースを使用する場合、この構成は便利です。
2ノードの EEE 相互テイクオーバー構成 DB2 EEE 製品は、複数区画のデータベース・インスタンスの稼動をサポートします。EEE インスタンスには、複数のマシンにわたって区分化されるデータベースを含みます。この環境では、MSCS クラスター内の各ノードが 1 つ以上のデータベース区画を管理する相互テイクオーバー構成を構成できます。1 つのノードに障害が発生すると、そのノード上のデータベース区画を他のノードがテイクオーバーし、同一データベース内の全区画を管理します。 各 DB2 インスタンスが別のデータベースを管理する EE 構成とは異なり、EEE 相互テイクオーバー構成では、データベースのシングル・イメージを提供します。  図 5. EEE 相互テイクオーバー構成 各論理区画は、他から独立してフェイルオーバー/フォールバックができるように、独自の DB2 グループの中に構成されます。 この構成では、DB2 の各区画が別ノードで稼動する場合は利用可能な全システム・リソースを使用し、DB2 の両区画が同一ノードで稼動する場合は両方とも正常に開始できるように、オンライン後スクリプトを使用して DB2 構成を調整する必要があります。
2ノードの EEE ホット・スタンドバイ構成 大量メモリー (4GB RAM 以上) と処理パワー (4 CPU 以上) を装備した大規模 SMP マシンについては、複数の論理ノードを使用して DB2 UDB EEE を稼動することをお勧めします。32 ビット・アドレス方式の制限のため、各区画がシステム上でアクセスできるメモリーは最大 3GB だけですが、使用する論理区画が 2 つになると、データベース・システム全体は最大 6GB のメモリーをアクセスでき、3 つになると 9GB … というように増えて行きます。 2 ノードの EEE ホット・スタンドバイ構成を図 6 に示すように構成できます。  図 6. EEE ホット・スタンドバイ構成 論理区画は両方とも、1 つの単位としてフェイルオーバーおよびフォールバックできるように、同一 DB2 グループに構成されます。
N+1 ホット・スタンドバイ構成 Windows 2000 DataCenter Server は、最大 4 ノードのクラスタリングをサポートします。この環境では、リソースはクラスター内の任意のマシンで稼動するように構成できます。N+1 のホット・スタンドバイ構成では、1 つのノードが専用のホット・スペアー・ノードになり、他の N ノードはアクティブな DB2 サーバーを持ちます。アクティブ・ノードの 1 つに障害が発生すると、ホット・スペアーがリソースをテイクオーバーし、DB2 はホット・スペアー上で再始動されます。 この構成では、即時フェイルバックを構成することが重要です。これにより、ワークロードは元の 1 次ノードへフェイルバックできます。こうすると、他のノードがダウンしたときに備えて、ホット・スペアー・ノードはいつでもテイクオーバーできる状態でいられます。 N+1 ホット・スタンドバイ構成は、EE および EEE 製品の両方用に構成できます。EE については、各 1 次 (アクティブ) ノードは、データベース・サーバーのインスタンスを管理します。EEE については、各 1 次ノードは 1 つ以上のデータベース区画を管理します。 この構成は、1 つのノードだけに障害が発生したときに、最高のパフォーマンスを提供します。複数のノードがダウンすると、マシン処理能力 (CPU、メモリー) 不足のために、パフォーマンスが低下します。  図 7. N+1 ホット・スタンドバイ構成
EEE のロード・バランシング構成 次の構成は、Windows 2000 DataCenter Server 上で稼動する DB2 EEE のみに有効です。この構成では、DB2 EEE データベースは、単一の MSCS クラスター内に構成された 4 台の物理マシン上で稼動する 12 の論理区画に分割されています。各論理区画は、論理区画のフェイルオーバーが他の区画に影響しないように、独自のディスクを持つ別々の MSCS グループに属するように構成されています。ノードに障害が発生したときに、ターゲットとなるテイクオーバー・ノードを制御するには、各論理区画の推奨所有者リストが使用されます。たとえば、マシン名が A、B、C、D の場合、論理区画の推奨所有者リストを次のように設定できます。
元々、各マシンは 3 つの区画をホストし、それら区画はすべてアクティブにアプリケーションにサービス提供しています。ノードの 1 つに障害が発生すると、そのノード上の区画のそれぞれは、残り 3 つのノードによってテイクオーバーされます。この例では、マシン D に障害が起きると、区画 10 は次の推奨所有者、すなわち A に移動し、区画 11 はその次の推奨所有者の B に移動、区画 12 はそのまた次の推奨所有者の C に移動します。その結果、障害が起きたノードのワークロードは、均等に分散されます。  図 8. EEE 平衡化されたワークロード・フェイルオーバー構成
複数の MSCS クラスターの例 DB2 UDB EEE 環境では、インスタンスは 1 つのクラスターでサポートできる台数を超える数のマシンにわたることができます。この場合、複数のクラスターは、EEE インスタンス全体の高可用性をサポートするように構成できます。各区画は、それが属するクラスター内の他のマシンへだけフェイルオーバーできます。各クラスターで使えるマシンが 1 台はある限り、EEE インスタンスを完全にオンラインにできます。ただし、特定のクラスター内の全マシンに障害が発生すると、そのクラスター内に構成されたすべての EEE 区画は使用できなくなります。次のケースでは、EEE インスタンスは 4 つの区画を含みます。区画 0 と区画 1 はクラスター MSCS-1 に、区画 3 と 4 はクラスター MSCS-2 に存在します。図 9 では、フェイルオーバー・オプションを矢印で示します。  図 9. 複数クラスターの例
フェイルオーバー フェイルオーバーは、使用不能に陥ったノードから使用可能なノードへクラスター・リソースを移動するプロセスです。関連プロセスのフォールバック (フェイルバックともいう) は、オンラインになった後で、オフラインだったノードにリソースが復元されたときに発生します。 フェイルオーバーは、MSCS がクラスター・ノードの 1 つで障害を検知したときに、MSCS によって自動的に開始されます。1 つのリソースに障害が起きると、MSCS はそのリソースが所属するグループ全体をフェイルオーバーします。たとえば、DB2 リソースに障害が起きると、MSCS は DB2 グループ全体をフェイルオーバーします。この DB2 グループも、IP アドレス、ネットワーク名、およびディスク・リソースを含んでいます。 障害検知 MSCS は定期的に各リソースを調べて、まだ活動状態かどうか確かめることで、リソースの障害を検知します。各リソースは、まだ活動状態であることを示すステータス・コードを返して、check-alive要求に応える必要があります。DB2 リソースについては、DB2 サービス (ウィンドウ・サービス) が稼動していれば、データベース・サーバーは活動状態にあると報告されます。データベース・マネージャーがクラッシュすると、DB2 サービスは停止し、これがリソース障害を知らせます。 DB2 UDB V7.2 では、ハングアップした状態は、リソース障害を知らせません。この場合、管理者は手動でシステム・コントローラー・プロセス (db2syscs.exe) を終了し、同一マシン上でサーバーを再始動するか、あるいはフェイルオーバーを開始します。 フェイルオーバー・プロセス クラスターを認識するアプリケーション
クラスタリング・テクノロジーについては、Microsoft
Windows Clustering テクノロジーのホームページを参照してください (URL は次のとおりです)。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
