test

Sun GlassFish Enterprise Server 2.1 配備計画ガイド

高可用性データベース

この節では、次の項目について説明します。

概要

「セッション持続性」では、Java EE アプリケーションでのセッション持続性の必要性について説明しました。Application Server では、高可用性セッションストアとして高可用性データベース (HADB) を使用します。HADB は Sun GlassFish Enterprise Server with HADB に含まれますが、配備では独立したホストで実行できます。HADB は、HTTP セッションおよびステートフルセッション Bean データの高可用性データストアを提供します。

この分離型アーキテクチャーには、次のような利点があります。

注 –

HADB は Application Server による使用のために最適化されており、汎用データベースなどのアプリケーションによる使用は想定されていません。

HADB のハードウェアおよびネットワークシステムの要件については、『Sun GlassFish Enterprise Server 2.1 リリースノート』の「ハードウェアとソフトウェアの要件」を参照してください。HADB で必要なその他のシステム設定手順については、『Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド』の第 10 章「高可用性 (HA) データベースのインストールと設定」を参照してください。

システム要件

HADB ホストのシステム要件は次のとおりです。

ネットワーク構成の要件については、『Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド』の第 10 章「高可用性 (HA) データベースのインストールと設定」を参照してください。さらに高度な可用性を実現するための追加要件については、「二重障害の防止」を参照してください。

HADB のアーキテクチャー

HADB は、「ノード」のペアで構成される分散システムです。「データ冗長ユニット」で示すように、ノードは 2 つのデータ冗長ユニット (DRU) に分割され、1 つのノードは各 DRU 内の各ペアに属します。

各ノードは次の要素で構成されます。

HADB ノードの 1 つのセットが、1 つ以上の「セッションデータベース」をホストすることができます。各セッションデータベースは、個別のアプリケーションサーバークラスタと関連付けられます。クラスタを削除すると、関連付けられたセッションデータベースも削除されます。

HADB ハードウェアの要件については、『Sun GlassFish Enterprise Server 2.1 リリースノート』の「ハードウェアとソフトウェアの要件」を参照してください。

ノードとノードプロセス

HADB ノードには、次の 2 種類があります。

各ノードには、1 つの親プロセスと複数の子プロセスがあります。ノードスーパーバイザー (NSUP) と呼ばれる親プロセスは、管理エージェントによって起動されます。このプロセスは、子プロセスの作成とその実行の継続の役割を果たします。

子プロセスには次のものがあります。

データ冗長ユニット

すでに説明したように、1 つの HADB インスタンスには DRU のペアが 1 つ含まれます。各 DRU には、もう一対の DRU と同数のアクティブノードとスペアノードが存在します。DRU 内の各アクティブノードに対し、もう一方の DRU 内に「ミラーノード」が存在します。ミラーリングにより、各 DRU がデータベースの完全なコピーを保持します。

次の図は、6 つのノードが存在するサンプルの HADB アーキテクチャーを示したものです。 4 つのアクティブノードと 2 つのスペアノードが存在します。ノード 0 とノード 1 はミラーペアです。ノード 2 とノード 3 も同様です。この例では、各ホストにあるノードは 1 つです。一般に、ホストに十分なシステムリソースがあれば、複数のノードを 1 つのホストに共存させることができます (「システム要件」を参照)。

注 –

HADB ノードをホストするマシンは、ペアで (各 DRU に 1 台ずつ) 追加する必要があります。

HADB では、データおよびサービスをレプリケートすることによって高可用性を実現します。ミラーノード上のデータレプリカは、「プライマリレプリカ」および「ホットスタンバイレプリカ」として指定されます。プライマリレプリカは、挿入、削除、更新、読み取りなどの操作を実行します。ホットスタンバイレプリカは、プライマリレプリカの操作のログレコードを受信し、トランザクションの寿命内にそれらの操作を再実行します。読み取り操作はプライマリレプリカによってのみ実行されるため、ログに記録されません。各ノードにはプライマリレプリカとホットスタンバイレプリカの両方が含まれ、同じ役割を果たします。データベースは、DRU 内のアクティブノード間で断片化および分散されます。ミラーペア内の各ノードには、データフラグメントの同じ集合が含まれます。ミラーノードにデータを複製することを「レプリケーション」と呼びます。レプリケーションにより、HADB で高可用性を提供できます。 あるノードで障害が発生した場合、ほとんど即時 (数秒以内) にそのミラーノードへの引き継ぎが行われます。レプリケーションにより可用性が保証され、データやサービスを失うことなくノードまたは DRU の障害が隠蔽されます。

障害が発生したノードの機能を引き継ぐとき、ミラーノードでは 2 つの作業を実行する必要があります。 ミラーノード自体の作業と、障害が発生したノードの作業です。ミラーノードに十分なリソースがない場合、過負荷によってミラーノードのパフォーマンスが低下し、ミラーノードの障害の可能性も高まります。あるノードで障害が発生すると、HADB はそのノードの再起動を試みます。ハードウェアの故障などが原因で、障害が発生したノードが再起動しない場合、システムは動作を続けますが可用性は低下します。

HADB は 1 つのノード、DRU 全体、または複数のノードの障害に対する耐性を備えますが、ノードおよびそのミラーで障害が発生したときの「二重障害」への耐性はありません。二重障害の可能性を下げる方法の詳細は、「二重障害の防止」を参照してください。

スペアノード

あるノードで障害が発生すると、そのミラーノードが元のノードの役割を引き継ぎます。障害が発生したノードにスペアノードがない場合、この時点で、障害が発生したノードにミラーがないことになります。スペアノードは、障害が発生したノードのミラーを自動的に置き換えます。スペアノードを用意しておくことにより、ミラーノードのない状態でシステムを運用する時間を短縮できます。

スペアノードは通常時はデータを保持しませんが、DRU 内のアクティブノードの障害を常に監視しています。ノードで障害が発生し、指定された期間内に復旧しない場合、スペアノードはミラーノードからデータをコピーし、ミラーノードとの同期を行います。この処理にかかる時間は、コピーされるデータの量と、システムおよびネットワークの能力によって異なります。同期後は、手動操作なしで、スペアノードによって自動的にミラーノードが置き換えられます。その結果、ミラーノードの過負荷が防止され、ミラー上の負荷が分散されます。この処理のことを「フェイルバック」または「自己修復」と呼びます。

障害が発生したホストが、ハードウェアの切り替えまたはソフトウェアのアップグレードによって復旧および再起動した場合、元のスペアノードがこの時点でアクティブノードになっているため、そのホストで実行中の 1 つ以上のノードがスペアノードとしてシステムに参加します。

スペアノードは必須ではありませんが、1 台のマシンで障害が発生した場合でも、システムが全体的なサービスレベルを維持できるようにする効果があります。また、スペアノードを用意しておくことにより、アクティブノードのホストマシン上で計画的な保守を実施しやすくなります。スペアマシンの役割を果たす 1 台のマシンを各 DRU に割り当てて、マシンのうち 1 台で障害が発生した場合でも、HADB システムがパフォーマンスと可用性を低下させることなく運用を継続できるようにします。

注 –

原則として、十分な Application Server インスタンス数および HADB ノード数を持つスペアマシンが、使用不能になったマシンを代替するようにします。

スペアノード構成の例

HADB 配備でのスペアノードの使用例を次に示します。使用できる配備トポロジは 2 種類あります。「共存」トポロジでは HADB と Application Server を同じホストに配置し、「独立層」トポロジでは両者を別々のホストに配置します。配備トポロジの詳細は、第 3 章トポロジの選択を参照してください。

例: 共存構成

スペアノード構成の例として、4 台の Sun FireTM V480 サーバーを使用し、各サーバーに 1 つの Application Server インスタンスと 2 つの HADB データノードを配置する共存トポロジを考えます。

スペアノード用に、さらに 2 台のサーバーを割り当てます (各 DRU に 1 台ずつ)。各スペアマシンでは、1 つの Application Server インスタンスと 2 つのスペア HADB ノードを実行します。

例: 独立層構成

HADB 層に 2 台の Sun FireTM 280R サーバーを配置し、それぞれが 2 つの HADB データノードを実行する個別層トポロジを考えます。1 台のマシンが使用不能になった場合でもこのシステムの完全な能力を維持するには、Application Server インスタンス層と HADB 層のそれぞれに 1 台のスペアマシンを設定します。

Application Server インスタンス層のスペアマシンには、この層内のほかのマシンと同数のインスタンスが必要です。同様に、HADB 層用のスペアマシンには、この層内のほかのマシンと同数の HADB ノードが必要です。

二重障害の防止

HADB の組み込み型のデータレプリケーションにより、単一ノードまたは DRU 全体の障害に対する耐性を HADB に持たせることができます。デフォルトでは、HADB はミラーノードペアまたは両方の DRU で障害が発生した状況を指す「二重障害」を許容できません。そのような場合、HADB は使用不能になります。

前の節で説明したスペアノードの使用に加えて、次の手順に従うことにより、二重障害の可能性を最小化できます。

これらの手順は任意ですが、HADB インスタンスの全体的な可用性を高めます。

HADB 管理システム

HADB 管理システムは、組み込み型のセキュリティーを提供し、マルチプラットフォーム管理を促進します。次の図で示すように、HADB 管理アーキテクチャーには次のコンポーネントが含まれます。

図で示すように、HADB サービスを実行するすべてのマシン上で 1 つの HADB 管理エージェントが実行されます。各マシンは通常、1 つ以上の HADB ノードをホストします。Application Server ドメインと同様に、HADB 管理ドメインには多数のマシンが含まれます。データベースに耐障害性を持たせるには、ドメイン内に最低 2 台のマシンが必要であり、一般的には、DRU ペアを形成するために偶数のマシンを用意する必要があります。そのため、ドメインには多数の管理エージェントが含まれます。

図で示すように、ドメインには 1 つ以上のデータベースインスタンスを含めることができます。1 台のマシンに、1 つ以上のデータベースインスタンスに属する 1 つ以上のノードを含めることができます。

管理クライアント

HADB の「管理クライアント」はコマンド行ユーティリティー hadbm であり、HADB ドメインとそのデータベースインスタンスを管理するためのものです。HADB サービスは、関連付けられた Application Server クラスタが停止しているときでも実行を継続できますが、サービスを削除する場合は注意深くサービスをシャットダウンする必要があります。hadbm の使用法の詳細は、『Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド』の第 11 章「高可用性データベースの管理」を参照してください。

asadmin コマンド行ユーティリティーを使用して、高可用性クラスタと関連付けられた HADB インスタンスを作成および削除できます。詳細は、『Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド』の第 7 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。

管理エージェント

HADB の管理エージェントは、ホスト上のリソースにアクセスできる ma という名前のサーバープロセスです。たとえば、このプロセスはデバイスの作成やデータベースプロセスの起動を実行できます。管理エージェントは、データベースインスタンスの起動や停止などの管理クライアントコマンドを調整および実行します。

管理クライアントは、エージェントのアドレスおよびポート番号を指定することによって管理エージェントに接続します。接続したあとは、管理クライアントは管理エージェントを通して HADB にコマンドを送信します。エージェントは要求を受け取って実行します。したがって、ホストに対して hadbm 管理コマンドを発行する前に、そのホスト上で管理エージェントが実行されている必要があります。管理エージェントは、自動的に起動するシステムサービスとして設定できます。

管理エージェントの可用性の保証

HADB ノードスーパーバイザープロセスに障害が起きると、管理エージェントプロセスを再起動して、その可用性を確保します。そのため、配備目的では、HADB の全体的な可用性を維持するために、ma プロセスの可用性を保証する必要があります。再起動のあと、管理エージェントはドメイン内のほかのエージェントからドメインおよびデータベースの設定データを復旧します。

管理エージェントの可用性を保証するには、ホストのオペレーティングシステム (OS) を使用します。Solaris または Linux では、プロセスの障害またはオペレーティングシステムの再起動のあと、init.d が ma プロセスの可用性を保証します。Windows では、管理エージェントは Windows サービスとして動作します。そのため、エージェントで障害が発生した場合や OS が再起動する場合、OS が管理エージェントを再起動します。

管理ドメイン

HADB の管理ドメインはホストの集合であり、各ホストでは同じポート番号で管理エージェントが実行されています。ドメイン内のホストには、1 つ以上の HADB データベースインスタンスを含めることができます。管理ドメインは、エージェントが使用する共通のポート番号と、ドメインを作成したりエージェントをドメインに追加したときに生成される「ドメインキー」と呼ばれる ID によって定義されます。管理エージェントはマルチキャストを使用して通信するため、ドメインの一意 ID を提供するドメインキーの役割は重要です。Application Server ドメインと一致するように、HADB 管理ドメインを設定できます。

複数のデータベースインスタンスを 1 つのドメインに含めると、複数の開発者グループが個別のデータベースインスタンスを使用できるため、この構成は開発環境で役立ちます。場合によっては、この構成は本番環境でも役立つことがあります。

エージェントの管理操作は、ドメインに属するすべてのエージェント間で協調されます。hadbm コマンドを使用してデータベース設定を変更すると、すべてのエージェントがそれに従って設定を変更します。ノードのホスト上の管理エージェントが実行されていない場合、ノードを停止または再起動できません。ただし、一部のエージェントが使用不能な場合でも、HADB 状態または設定変数の値を読み取る hadbm コマンドを実行できます。

管理ドメインを操作するには、次の管理クライアントコマンドを使用します。

リポジトリ

管理エージェントは、データベース設定を HADB の「リポジトリ」に格納します。リポジトリはすべての管理エージェント間でレプリケートされるため、高い耐障害性を備えています。サーバー上に設定を保持することにより、管理クライアントがインストールされている任意のコンピュータから管理操作を実行できるようになります。

リポジトリに対して何らかの変更を実行するには、ドメイン内の管理エージェントの大半が実行中である必要があります。したがって、ドメイン内に M 個のエージェントがある場合、リポジトリに変更を行うには、少なくとも M/2 + 1 (端数を切り捨てた整数値) 個のエージェントが実行中である必要があります。

ハードウェアの故障などが原因でドメイン内の一部のホストが使用不能であり、エージェント数不足のため一部の管理コマンドを実行できない場合は、hadbm disablehost コマンドを使用して、障害が発生したホストをドメインから削除します。