test

Sun Java System Application Server 9.1 配備計画ガイド

HADB のアーキテクチャー

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

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

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

HADB ハードウェアの要件については、『Sun Java System Application Server 9.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 ノードが必要です。