WebSphere Extended Deployment, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS

データベースの区画化

DB2/390 などのデータベースには、標準装備の区画があり、アプリケーション内のデータベース区画化が不要になることがあります。

アプリケーションを実行するように高信頼性クラスターを構成することができますが、 クラスターで単一のデータベース・インスタンスを使用する場合には、 そのデータベースが Single Point of Failure になるほか、縦方向への拡大の限界になります。 データベースが Single Point of Failure になってしまうのは、そのデータベースが利用できなくなったときに、クラスターでなにも作業を実行できないからです。 通常のデータベースは縦方向にしか拡大縮小できないため、これは縦方向への拡大の問題となります。 例えば、処理速度を上げるには、大規模なマシンを購入する必要があります。

以下の図は、単一のデータベース・サーバー・アーキテクチャーを示したものです。 この図では、WebSphere Application Server が 2 台ありますが、データベース・サーバーは 1 台のみです。 アプリケーション・サーバーの数がさらに増えていくと、 データベースがパフォーマンスのボトルネックになります。

横方向に拡大縮小でき、なおかつ障害が発生してもアプリケーション・サーバー・クラスター全体 を停止させないデータベースが必要になる場合があります。 多くのアプリケーションでは非機能要件によって一時的な障害が発生する場合があり、 その影響がアプリケーションの一部に留まるならかまいませんが、完全に停止するのは許容できません。 このようなアーキテクチャーを実現するには、区画化データベース設計を使用します。

例えば、スタンドアロンの DB2 が稼働する 3 台のマシンを組み込む設計にします。 テーブル・スキーマとセキュリティー・システムは、3 つのすべてのデータベースで同じになります。 読み取り専用の参照データはすべて、普段から高い可用性を実現している マスター参照データ DB2 インスタンスから 3 つのすべてのデータベースに複製します。 このマスター参照 DB2 インスタンスは、通常の操作時には Single Point of Failure になりません。 アプリケーションから直接使用されることがないからです。

複数のサーバーを用意したら、次のステップでは、アプリケーション・データを区画化できるようにします。 簡単なハッシュ方式または範囲メカニズムを使用するか、あるいはデータベース内の複製テーブルを使用して、 特定の区画向けのデータを特定の DB2 インスタンスにマップします。 複製テーブルはアプリケーション・サーバー・クラスターによってキャッシュに入れられるテーブルであり、 ここで特定の区画向けのデータを保持する DB2 インスタンスが指定されます。 セットアップすることにより、アプリケーションの変更の必要なく、データベース間で重要なデータを移動できます。

アプリケーション・プロトコルは、区画をデータベース・インスタンスに 相関させるために必要です。 このタイプの相関により、横方向へのスケーラビリティーに使用さ れるデータベース・セットにデータベース・インスタンスを追加することができます。 独立した 3 つのデータベース・インスタンスを使用することの利点は、Oracle RAC や DB2 EEE などといった、通常の方法でクラスター化された データベースに比べて可用性が高くなるという点にあります。 各データベースはそれぞれ独立しているので、1 つのデータベースで 障害が発生した場合、そのデータベース内のデータ・セットは利用できなく なるものの、アプリケーションは、他のオンライン・データベース・インスタンスにあるデータへ のトランザクションを引き続き処理できます。

この状況の方が、障害が全体に及ぶより好ましいということです。 ただし、データベースが 3 つあるため、1 つしかない場合よりも管理が複雑になります。 アプリケーションは、有向トランザクション を使用して、次のトランザクションに必要なデータがどのデータベース・インスタンスに揃っているのかをアプリケーション・サーバーに指示します。 このパターンは、アプリケーションのデータベースからの観点での柔軟な管理を提供し、 特に、特定の区画向けのデータがどのデータベース・ノードにあるのかをアプリケーションに指示する MAPPER テーブルを使用する場合に有用です。

CMP Bean を使用するアプリケーションでは、その CMP Bean で使用するデータベースを 1 つだけ指定するのが一般的です。 ただしこの方法では、このパターンを使用する際に問題が生じます。 CMP Bean はデータベースごとに 1 回ずつ計 N 回デプロイできますが、 これは次の理由から柔軟性が低下します。

WebSphere Extended Deployment には、 トランザクションの開始前に、アプリケーションがどのデータベースを使用するかを指示できる、 プロキシー・データ・ソースという新機能があります。 クラスター・メンバーは、特定のアプリケーション区画への要求を受け取ると、 Bean がすでにデプロイされたデータ・ソースを無視し、次のトランザクション中に 特定のデータ・ソースを使用することを CMP ランタイムに対して指示できます。 有向トランザクション・パターンがアプリケーションで使用で きるようになり、アプリケーションの可用性を高めることができ、 ブレード・タイプ環境でのデータベース層の横方向への拡大縮小をサポートします。 アプリケーションはデータの管理および区画の移動に MAPPER テーブル・パターンを利用することもできます。

次の図は、この新しいアーキテクチャー全体を示しています。 このシステムの 2 つのデータベースでは、EJB1 は両方のサーバーにデプロイされています。 あるトランザクションでは、上のサーバーの EJB1 がデータベース 1 にアクセスします。 別のトランザクションでは、下のサーバーの EJB2 がデータベース 2 にアクセスします。 データベースの負荷は 1 つのサーバーに集まるのではなく、複数のデータベース・サーバーに分散されます。




Related concepts
J2EE 区画化機能

Concept topic    

Terms of Use | Feedback Last updated: Mar 20, 2006 12:35:11 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/WPF51/cwpfdb_pdf.html

© Copyright IBM 2005, 2006. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)