環境の計画

配備作業における最初の段階の 1 つとして、環境の計画を行います。この段階では、まず、必要なパフォーマンスと可用性を決定します。次に、ハードウェア、ネットワーク、記憶領域の要件について決定します。

この段階の主な目的は、ビジネス要件に最適な環境を確定することです。

HADB について

Sun^TM Open Net Environment (Sun ONE) Application Server 7, Enterprise Edition では、HTTP セッションの持続性がサポートされます。Sun ONE Application Server 付属の高可用性データベース (HADB) は、高可用性アプリケーションを実現する持続性ストアとして機能します。

HADB ノードは、複数のプロセスのセット、専用の共有メモリ領域、いくつかの二次記憶デバイスで構成され、セッションデータの格納および更新に使用されます。HADB ノードには、次の 2 種類があります。

各アクティブノードにはミラーノードが必要です。このため、アクティブノードはペアになっています。さらに、HADB の可用性を最大化するには、各ペアにスペアノードを 2 つずつ設けます。これにより、アクティブノードに障害が発生しても、障害の修復中にスペアノードで処理を引き継ぐことができます。

冗長データユニット

HADB ノードは、相互にミラー化を行う 2 つの冗長データユニット (DRU) で構成されています。各 DRU は、アクティブノードの半数とスペアノードで構成され、データの完全なコピーが 1 組、含まれています。耐障害性を確保するためには、DRU をサポートするコンピュータの電力、処理装置、記憶領域を、完全に自立させる必要があります。なお、電力の確保には、無停電電源装置が必要になります。こうしておけば、DRU で電源障害が発生しても、電力が回復するまでその他の DRU のノードで要求処理を続行することができます。

HADB ノードのホストマシンは、各 DRU のマシンとともにペアで追加する必要があります。

スペアノード

スペアノードは、DRU に接続された追加の HADB ノードです。最初の段階ではデータは格納されていませんが、DRU のアクティブノードの障害を常に監視し、障害が発生した場合は、そのノードが修復されるまで処理を引き継ぎます。

スペアノードを使用しない場合、マシンの停止時にはミラーノードの一方が処理を引き継ぎます。ただし、停止したマシンではサービス要求を処理することができないため、処理能力は低減します。あるマシンが停止したときの影響が大きければ、別のマシンが過負荷状態になるため、システムは事実上使用不能状態になります。また、データを複製するミラーノードが存在しないので、停止したマシンを修復しない限り、システムの耐障害性は得られません。高可用性の実現のためには、システムがシングルノードで動作する時間をなるべく短くする必要があります。

スペアノードを使用すれば、1 台のマシンが停止しても全体的なサービスレベルを停止前の状態に保つことができます。スペアノードは必須ではありませんが、高可用性を実現したい場合は導入するべきでしょう。マシンが停止しても過負荷状態に陥ることなくシステムを継続動作させるには、各 DRU にスペアマシンを 1 台ずつ割り当ててください。スペアノードを導入すれば、アクティブノードのホストマシンでの計画的な保守作業も実施しやすくなります。

一般的に、どのマシンが使用不能状態になっても対応できるように、スペアマシンには十分な数のアプリケーションサーバーインスタンスおよび HADB ノードを準備する必要があります。

たとえば、それぞれアプリケーションサーバーインスタンス 1 個と HADB データノード 2 個で構成される 4 台の Sun Fire^TM V480 サーバーを同じ場所に配備 (co-located) した場合、2 台のサーバーをスペアマシンにします (DRU 1 個につき 1 台)。各スペアマシンは、アプリケーションサーバーインスタンス 1 個とスペアの HADB ノードを 2 個実行します。

別の例として、それぞれ HADB データノードを 2 個ずつ実行する Sun Fire^TM 280R サーバー 2 台を別々の層に配備 (separate tier) した場合について考えてみましょう。1 台のマシンが停止しても、このシステムの完全な処理能力を確保するには、インスタンス層と HADB 層にそれぞれ 1 台ずつスペアマシンを設置する必要があります。インスタンス層のスペアマシンには、インスタンス層のその他のマシンと同数のインスタンスを持たせます。HADB 層のスペアマシンには、HADB 層のその他のマシンと同数の HADB ノードを持たせます。

サンプル HADB アーキテクチャ

次の図に、アクティブノード 4 個とスペアノード 2 個を備えたデータベースアーキテクチャを示します。ノード 0 とノード 1、ノード 2 とノード 3 は、それぞれミラーノードペアです。

図 2-1 アクティブノード 4 個とスペアノード 2 個を備えた HADB アーキテクチャ

パフォーマンス要件の確立

第 1 章「配備の概要」で説明していますとおり、この製品の配備における重要な目標の 1 つは、パフォーマンスの最大化です。これは、スループットの最大化と応答時間の短縮によって達成が可能です。

これらの主要な目標に加え、次の項目を決定し、それぞれの到達目標を設定することも必要となります。

これらの要素には相互関係があります。上記のうち、いずれか 3 つの項目が明確であれば、残り 1 つの項目は必ず計算できます。

この章で説明するメトリックの一部は、リモートブラウザエミュレータ (RBE) ツールや、エンタープライズ Web アプリケーションの稼働率をシミュレートする Web サイトのパフォーマンスおよびベンチマークソフトウェアで計算できます。通常、RBE やベンチマーク製品は、同時 HTTP 要求を生成し、応答時間と 1 分間あたりの要求数を報告します。ユーザーは、この値からサーバーの稼働率を計算できます。

以下の節で示す計算結果は、絶対的なものではありません。Sun ONE Application Server のパフォーマンスを微調整するための参考値とお考えください。

スループットの見積もり

スループットの意味は、アプリケーションサーバーインスタンスと HADB で異なります。

アプリケーションサーバーインスタンスのスループットは、1 分間に処理される要求数で表されます。

同様に、HADB のスループットは、HADB が 1 分間に処理する要求数と要求ごとのセッションサイズで表されます。格納されるセッションデータの量が要求ごとに異なるため、要求ごとのセッションサイズは重要です。

アプリケーションサーバーインスタンスの負荷の見積もり

アプリケーションサーバーインスタンスの負荷を見積もる際には、次の要素を考慮します。

最大同時ユーザー数

ユーザーが、Web ブラウザなどを使ってプロセスを実行すると、プロセスはクライアントマシンから Sun ONE Application Server 7, Enterprise Edition に定期的に要求を送信します。同時ユーザー数を見積もるときは、現在アクティブであるすべてのユーザーを考慮します。ユーザーセッションが期限切れ、または停止することなくアクティブな状態を保っていれば、そのユーザーを「アクティブユーザー」と見なします。

また、システム上で要求を送信するプロセスを実行したり、サーバーから応答を受信したり、要求の結果を表示したりしているユーザーを、「同時ユーザー」と見なします。

つまり、要求を送信する同時ユーザーの数が増えれば、1 分間に処理される要求の数が少なくなり、結果的に応答時間が長くなることになります。次の図は、この状態を表しています。

同時ユーザーを追加していった場合、1 分間に処理される要求の数がどの時点から低減し始めるのかを特定する必要があります。なぜなら、この情報から、パフォーマンスの低減が始まるポイントがわかるからです。

思考時間

ユーザーは常に要求を送信しているわけではありません。送信した要求がサーバーに受信され、処理されて応答が返された後、ユーザーはしばらくの間結果を分析し、その後で新しい要求を送信します。このようにユーザーが要求の応答内容を確認する時間を「思考時間」と呼びます。

通常の思考時間を特定することで、1 分間あたりの要求数や、システムによってサポートされる同時ユーザー数をより正確に計算することができます。基本的に、システム上のあるユーザーが要求を送信していない期間、システムの負荷を変更することなく、ほかのユーザーに要求を送信する機会が与えられます。このため、より多くの同時ユーザーをサポートすることができます。

平均応答時間

応答時間とは、要求の結果がユーザーに返されるまでの時間を指します。応答時間は、ネットワーク帯域幅、ユーザー数、送信される要求の数と種類、平均思考時間など、さまざまな要素によって決まります。この節では、平均応答時間を「応答時間」と呼びます。最小応答時間は、要求の種類によって決まっていますが、システムのパフォーマンスを評価するときは、すべての要求の平均応答時間を元に分析する必要があります。

応答時間が短ければ、1 分間に処理される要求数が多くなります。ただし、システム上のユーザー数が増加すれば、1 分間あたりの要求数が減少しても、応答時間は長くなります。次の図は、その状態を示しています。

このシステムパフォーマンスグラフを分析すると、ある時点 (このグラフの場合、ポイント A) から、1 分間あたりの要求数と応答時間が反比例の関係になることがわかります。1 分間あたりの要求数の減少に伴って、応答時間 (破線矢印線) は急速に増加していきます。

1 分間あたりの要求数は、このグラフのポイント A (ピーク負荷) から減少し始めます。このポイント以前では、計算式にピーク負荷時の値が反映されないので、応答時間を計算しても、必ずしも正確な結果は得られません。一方、このポイント以降では、1 分間あたりの要求数と応答時間の間に反比例の関係が成立するので、最大ユーザー数と 1 分間あたりの要求数に基づいて、より正確に応答時間を計算することができます。

応答時間を正確に計算するには、計算式に思考時間を必ず含めてください。

システムの応答時間、特にピーク負荷時の応答時間を計算後、次に許容応答時間を決定します。応答時間は、スループットと同様に、Sun ONE Application Server のパフォーマンスに影響する重要要素です。そのため応答時間の改善は常に目標の 1 つとなります。応答時間が許容待ち時間より長く、パフォーマンスのレベルを超える場合は、応答時間を改善するか、応答時間のしきい値を再定義します。

1 分間あたりの要求数

ある時間の同時ユーザー数、これらのユーザーの要求に対する応答時間、この時点での平均ユーザー思考時間がわかっていれば、1 分間あたりの要求数を特定できます。通常は、システム上の同時ユーザー数を調べるところから始めます。

たとえば、ある Web サイトのパフォーマンスソフトウェアを実行後、オンラインバンキング Web サイトに要求を送信するユーザー数の平均値を計算した結果が 3,000 であったと想定します。この値は、オンラインバンクのメンバーとして登録しているユーザーの数、バンキングトランザクションの内容、オンラインバンクのメンバーが要求送信を実行した日または週などによって決定します。したがって、この情報から、この節で紹介した 1 分間あたりの要求数の計算式を使って、このユーザーベースに対してシステムが 1 分間に処理できる要求数を計算することができます。続いて、応答時間の短縮を優先して 1 分間あたりの要求数を減らすか、1 分間あたりの要求数の増加を優先して応答時間を減らすかを選択します。1 分間あたりの要求数と応答時間はピーク負荷時から反比例の関係になります。

基本的に、システムのパフォーマンスの微調整は、1 分間あたりの要求数と許容できる応答時間のしきい値を決定するところから始めます。続いて、調整するシステムの領域を決定します。

ここから、1 秒あたりの要求数 700 と、1 分間の要求数 42,000 を計算できます。

HADB の負荷の見積もり

HADB の負荷は、ユーザーが指定したセッション持続性の設定に影響を受けます。セッション持続性の詳しい使用方法については、『Sun ONE Application Server 管理者ガイド』を参照してください。

セッション持続性について

アプリケーションセッション中に、セッションの一部のデータが従来のデータベースに格納されないという現象が起こることがあります。こうしたデータの 1 つとして、ショッピングカートの中身があります。Sun ONE Application Server では、このセッションの状態をリポジトリに格納し、持続させることができます。このため、アプリケーションサーバーインスタンスに障害が発生しても、セッションの状態を復元し、情報を失うことなくセッションを続行することができます。

Sun ONE Application Server によって処理される要求の数以外に、ユーザーが指定したセッション持続性設定も、1 分間に HADB が受信する要求数と各要求のセッション情報に影響を及ぼします。

持続性の設定はアプリケーションサーバーインスタンスごとに定義できます。ただし、特定のクラスタ内のすべてのアプリケーションサーバーインスタンスで同一の設定にする必要があります。複数のクラスタがある場合、すべてのクラスタに同一の持続性設定を持たせる必要はありません。

HADB が 1 分間に受信する要求数

HADB が 1 分間に受信する要求数は、「持続間隔」によって決まります。持続間隔とは、セッション情報が HADB に格納される間隔です。この値は、持続間隔の設定によって定義されます。持続間隔のオプションは次のとおりです。


注	クラスタ内のすべてのインスタンスのセッション持続性設定を同一にするには、cladmin コマンドを使用します。cladmin コマンドの詳しい使用方法については、『Sun ONE Application Server 管理者ガイド』を参照してください。

web-method 持続間隔では、最新の持続性セッション情報を確保できる代わりに、HADB のトラフィックは多くなります。これは、web 要求があるたびに HADB に情報が格納されるからです。time-based 間隔では、HADB のトラフィックは少なくなりますが、最新のセッション情報を確保する機能は web-method 持続間隔より劣ります。

持続間隔オプションの比較

次の表に、持続間隔オプションの利点と欠点をまとめます。左の欄に持続間隔オプション、中央と右の欄にこのオプションの利点と欠点を示します。

表 2-1 持続間隔オプションの比較
持続間隔オプション	利点	欠点
web-method	最新のセッション情報を確保できる	応答時間の増加、スループットの減少を招く
time-based	応答時間の短縮とスループットの増加を期待できる	アプリケーションサーバーインスタンスに障害が発生したあと、最新のセッション情報を使用できる可能性が web-method 持続間隔に比べて低い

要求あたりのセッションサイズ

要求あたりのセッションサイズは、セッションに格納されるセッション情報の量によって決まります。

持続範囲設定によって、要求あたりのセッションサイズ数を微調整できます。次の持続範囲オプションを選択できます。


注	全体的なパフォーマンスを改善するには、セッション内の情報量を可能なかぎり少なくします。

session: セッション情報が HADB データベースに格納されるたびにセッション全体が保存される

modified-session: セッションは変更されたときにのみ保存される

modified-attribute: 前回セッションが格納された後に変更 (挿入、更新、または削除) された属性のみが保存される



注	持続範囲 modified-attribute は、本稼働環境で動作することが保証されていません。この持続範囲を使用する場合は、予想ピーク負荷条件での Sun ONE Application Server のパフォーマンスと安定性を評価してください。例外が記録された場合、または応答時間が許容時間を超える場合は、この持続範囲を本稼働環境では使用しないでください。

持続範囲オプションの比較

次の表に、持続範囲オプションの利点と欠点をまとめます。左の欄に持続範囲オプション、中央と右の欄にこのオプションの利点と欠点を示します。

表 2-2 持続範囲オプションの比較
持続間隔オプション	利点	欠点
modified-session	セッション状態を変更しない要求の応答時間が改善される	アプリケーションは、web メソッド (通常 doGet または doPost) の実行時、属性が変更された場合は setAttribute メソッド、属性が削除された場合は removeAttribute メソッドをセッション上に呼び出す必要がある
session	アプリケーションに対する制約はない	modified-session オプションまたは modified-attribute オプションに比べてスループットが低く応答時間が長い傾向がある
modified-attribute	セッションの状態の変更の割合が低い要求で、スループットの向上と応答時間の短縮を期待できる	1. セッションの状態の変更の割合がある要求のおよそ 60% に達すると、スループットが低下し、応答時間も長くなる。この場合、属性を複数のレコードに分割するためのオーバーヘッドによって、session 持続範囲や modified-session 持続範囲よりもパフォーマンスが低くなる 2. このモードでは、アプリケーションの作成時に次の制約が課される。セッションの状態を変更するたびに setAttribute または removeAttribute を呼び出す属性間にクロスリファレンスが存在しないことを確認する複数の属性、少なくとも読み取り専用属性と変更可能属性にセッションを分散させる

ピーク負荷と通常負荷の設計

一般的な配備方法では、通常状態の負荷とピーク時の負荷の間には、ある程度の差異が発生します。

ピーク負荷向けに設定する場合は、応答時間の低下を避けながらユーザーと要求の予想最大負荷に対応できるシステムを配備する必要があります。つまり、最大予想システム負荷を処理できるシステムが必要です。ピーク負荷と通常負荷の差が大きい場合、ピーク負荷用の設計にすると、リソースはかなりの間アイドル状態になります。

通常負荷向けに設計するときは、サーバーの予想ピーク負荷の処理に必要なすべてのリソースを配備する必要はありません。ただし、通常負荷をサポートするシステムの場合、ピーク負荷時の応答時間が長くなります。

ピーク負荷の間隔と継続時間

ピーク負荷と通常負荷のどちらを対象に設定するかは、ピーク負荷を処理する頻度によって決まります。ピーク負荷が 1 日または 1 週間に何回も発生する場合は、この負荷を処理するために容量を拡張しなくてはならない可能性があります。一方、システムが稼動時間の 90% は安定した状態で、ピーク負荷が発生するのは残りの 10% のみの場合、通常負荷向けに設計されたシステムを配備できます。この場合、システムの応答時間の 10% は、残りの 90% の応答時間より長くなります。ピーク負荷に対応するためには、システムがピーク負荷状態で稼動する間隔または時間が、システムにリソースを追加する正当な理由になるかどうかを判断する必要があります。

設計上の決定

この段階での設計上の決定は、アプリケーションサーバーインスタンスの負荷、HADB の負荷、フェイルオーバーの要件を考慮して行います。

必要なアプリケーションサーバーインスタンスの数

必要なアプリケーションサーバーインスタンスの数を特定するには、「アプリケーションサーバーインスタンスの負荷の見積もり」で説明した要素に基づいて環境の評価を行います。各アプリケーションサーバーインスタンスは、1 個以上の CPU を使用できます。それぞれに 1 個以上の CPU を割り当てる必要があります。

必要な HADB ノード数

一般的なガイドラインとして、システムの CPU ごとに HADB ノードを 1 つずつ割り当てる計画を立てます。たとえば、CPU を 2 個持っているマシンには HADB ノードを 2 個割り当てます。

必要な HADB 記憶領域

ネットワーク容量がいっぱいになるまでノードを追加すると、HADB はほぼ線形のスケーリングを提供します。各ノードの専用ディスクまたはディスクに記憶デバイスを設定する必要があります。さらに、この記憶デバイスの割り当て容量をすべてのノードで統一します。記憶デバイスはローカルディスクに割り当ててください。

予想セッションデータ量が XM バイトであるとします。HADB はデータをミラーノードに複製するので、2XM バイトの記憶領域が必要になります。

さらに、HADB は、データへの高速アクセスのためインデックスを使用します。充填率 100% 未満の場合、インデックス用として、両方のノードの分を合わせてさらに 2XM バイトが必要です。結果的に、4XM バイトの記憶領域が必要になります。

したがって、HADB に必要な記憶領域は、予想データボリュームの 4 倍ということになります。

将来的に、サイズの大きいディスクをノードに追加したり、システムに新しいノードを追加したりして、システムを拡張したい場合、HADB のデータを失わないためには、予想データボリュームの 8 倍の記憶領域を用意します。これは、オンラインアップグレードの場合、新しいノードを追加したあとにデータの再断片化が必要になることがあるためです。この場合、データデバイスの追加領域 (4X) と同量の空き領域が必要になります。合計記憶領域を 8X に増やすのはこのためです。

また、HADB は、ディスク領域を次のように内部使用します。

詳細については、『Sun ONE Application Server 管理者ガイド』と『Sun ONE Application Server パフォーマンスおよびチューニングガイド』を参照してください。

次の表に、XM バイトのセッションデータに必要な HADB 記憶領域を示します。左の欄は条件 (オンラインのとき HADB ノードの追加または削除が必要かどうか)、右の欄は必要な HADB 記憶領域です。


注	大規模なマシンを使用する場合など、マシン 1 台あたりに複数の HADB ノードが存在する場合は、マシンに十分な冗長性とスケーラビリティが必要になります。たとえば、複数の無停電電源装置や独立したディスクコントローラなどが必要です。


注	デフォルトの logBufferSize は 48M バイトです。

表 2-3 セッションサイズが XM バイトのとき必要な HADB 記憶領域
条件	必要な HADB 記憶領域
オンラインのとき HADB ノードの追加または削除が不要	(4XM バイト) + (4*logBufferSize) + (デバイスのサイズの 1%)
オンラインのとき HADB ノードの追加または削除が必要	(8XM バイト) + (4*logBufferSize) + (デバイスのサイズの 1%)

HADB のデバイス容量が不足した場合、エラーコード 4593 または 4592 が返され、履歴ファイルにエラーメッセージが書き込まれます。これらのメッセージの詳細については、『Sun ONE Application Server Error Message Reference』を参照してください。

HADB のデバイス容量が不足した場合、クライアントによるデータの挿入または更新要求は受理されません。ただし、削除操作は受理されます。

データデバイスのサイズの設定

HADB のデータデバイスのサイズを設定するには、次のコマンドを使用します。

hadbm コマンドは、変更内容を適用するため、すべてのノードを 1 つずつ再起動します。詳細については、『Sun ONE Application Server 管理者ガイド』を参照してください。

ピーク負荷用または通常負荷用の設計


注	最新版の hadbm コマンドは、稼動中の HADB データベースにデータデバイスを追加しません。

パフォーマンス要件を満たすネットワーク設定の計画

Sun ONE Application Server をネットワークに統合してパフォーマンスを最適化するためには、帯域幅の要件を見積もり、パフォーマンス要件に合ったネットワークを計画する必要があります。

帯域幅の要件の見積もり

必要となるネットワークの規模や帯域幅を決定するためには、最初に、ネットワークトラフィックとそのピークの特定が必要になります。特定の時刻や曜日、月内の日付など、全体のボリュームがピークに達する条件を確かめ、そのピークの持続性を特定します。

また、追加を計画しているネットワークコンポーネントの規模や種類については、常に、サイト内のネットワークの専門家から意見を求めることが必要です。

ピーク負荷時

負荷がピークに達している間、送信されるパケット数も最大になっています。通常、ピーク負荷用の設計では、ピークボリュームを 100% 処理できるようにシステムを拡張します。ただし、システムを拡張しても、ネットワークの予測不可能な動作などのため、ピークボリュームの 100% を常に処理できない場合があります。

たとえば、ピーク負荷時に、Sun ONE Application Server 7, Enterprise Edition 上のアプリケーションにただちにインターネットアクセスできないユーザーが 5% 存在するとします。この 5% のうち、アクセスを再試行するユーザーの数を特定します。それでも一部のユーザーがアクセスできない場合、そのうちの何パーセントかが再試行します。ユーザーがアクセスを試行している間はピーク使用の状態が継続するので、結果的にピーク時間が長くなったように見えます。

ピーク時の最適なアクセスを保証するには、まず、インターネットサービスプロバイダ (ISP) がパフォーマンスの低下なしでインターネットのハブに到達できるような、バックボーンネットワークとの接続環境を保持していることを確認する必要があります。

帯域幅要件の計算

「パフォーマンス要件の確立」の計算内容を元に、Sun ONE Application Server をサイトに配備するために必要な追加帯域幅を特定します。

T1 回線、ISDNなどのアクセス方法に基づいて、予想負荷を処理するために必要な帯域幅容量を計算できます。たとえば、T1 またはそれ以上の速度の T3 リンクからインターネットにアクセスするサイトについて考慮してください。帯域幅を仮定し、サイトで 1 秒間に生成される平均要求数と最大ピーク負荷に基づいてネットワーク上に必要な回線数を見積もります。これらの値は、Web サイト分析監視ツールを使って計算できます。

1 本の T-1 回線では、1.544Mbps の処理が可能です。また、4 本の T-1 回線を持つネットワークでは、各回線が 1.544Mbps の処理能力なので、概算すると 6Mbps の処理が可能です。クライアントに返される HTML ページの平均サイズが 30K バイトだとした場合、T1 回線が 4 本あるネットワークで 1 秒間に処理できるトラフィックは、次の式のようになります。

1 秒あたり 772,000 バイト / 30K バイト = クライアントによる 1 秒間の同時ページ要求数約 25

1 秒あたり 25 ページのトラフィックが発生している場合、このシステムでは、1 時間あたり 90,000 ページ (25 × 60 秒× 60 分) を処理できます。したがって、1 日中一定の負荷が課されていると考えると、1 日あたり最大 2,160,000 ページを処理できることになります。最大ピーク負荷がこの値を超えると、帯域幅の増量が必要になります。

ピーク負荷

1 日中一定の負荷がかかるという想定は現実的ではありません。ピーク負荷がいつ発生し、どのくらい継続するか、また、ピーク負荷が合計負荷の何パーセントになるかを特定する必要があります。たとえば、このケースでは、ピーク負荷が 2 時間継続し、これが合計 2,160,000 ページの負荷の 30% を占めるとすると、T1 回線経由で 2 時間以内に伝送されなければならないデータ量は 648,000 ページになります。

したがって、この 2 時間のピーク負荷に対応するため、次の計算に従って T1 回線数を増やす必要があります。

4 本の回線で 1 秒あたり 25 ページを処理できるとすると、約 4 倍のページ数が 4 倍の回線を必要とするので、計 16 回線が必要になります。16 回線が、30% のピーク負荷の現実的な最大値を処理するために使用されます。これだけたくさんの回線があれば、残りの時間で 70% の負荷を十分に処理することができます。

サブネット

アプリケーションサーバーインスタンスノードと HADB ノードを別々の層に配置する separate tier トポロジを使用している場合、HADB ノードを別のサブネットに配置することでパフォーマンスを向上させることができます。これは、HADB が UDP (ユーザーデータグラムプロトコル) を使用するためです。別のサブネットを使用することで、このサブネット外のマシンの UDP トラフィックが削減されます。

ネットワークカード

帯域幅を増やし、ネットワークパフォーマンスを最適化するには、Sun ONE Application Server のホストサーバーと HADB ノード間、その他のマシン上でホストされている HADB データベースなどのリソース間で、100Mbps 以上、できれば 1Gbps の Ethernet カードを使用します。

HADB のネットワーク設定

以下に、ネットワークにおける HADB の動作を最適化するための要件および推奨条件を示します。

個々のネットワークインタフェースが専用の 100Mbps チャネルまたはそれ以上の Ethernet チャネルを使用できるようにスイッチルーターを使用する

4 個以上の HADB ノードをホストするマルチ CPU マシンを実行している場合は 1Gbps の Ethernet カードを使用する



注	平均セッションサイズが 50K バイトを超える場合は、マシンあたりの HADB ノード数が 4 個未満でも 1Gbps の Ethernet カードを使用してください。

HADB 内にネットワークボトルネックが存在する疑いがある場合:

HADB コンピュータ上で監視ソフトウェアを実行して問題を診断する

ネットワーク内の 100Mbps の Ethernet カードを 1Gbps の Ethernet カードと交換する

最新リリースの HADB は、通常、複数のネットワークインタフェースカードを設置したコンピュータ上では動作しない。コンピュータあたり 1 枚のネットワークインタフェースカードで提供されるより多くのネットワーク帯域幅が必要な場合、Sun カスタマサポートに代替ソリューションをお問い合わせください。

可用性の計画

可用性の計画は、アプリケーション要件とカスタマ要件に従って行う必要があります。

システムに冗長性を追加

高可用性を実現する 1 つの方法として、システムに冗長性を追加することができます。たとえば、冗長ハードウェアと冗長ソフトウェアを追加します。この場合、ある装置に障害が発生しても、冗長装置で処理を引き継ぐことができます。これを「耐障害性」とも呼びます。

通常、高可用性を実現するためには、システム内の単一点障害を特定し、除去する必要があります。

障害クラス

冗長性のレベルは、システムが許容しなければならない障害クラス (障害の種類) によって決まります。たとえば、システムプロセス、マシン、電源、ディスク、ネットワークなどの障害、さらに火災その他の災害といった障害クラスがあります。

重複システムプロセスは、単一のシステムプロセスの障害を許容します。重複マシンは、単一マシンの障害を許容します。重複したミラー (ペア) マシンを別の電源装置に接続した場合、単一の電源障害が許容されます。ミラーマシンを別の建物に配置すれば、単一の火災が許容されます。また、こうしたミラーマシンを地理的に離れた場所に配置すれば、ある場所での地震などの自然災害も許容されます。

可用性の計画時には、システムが対応する障害クラスを特定する必要があります。

冗長ユニットによる可用性の改善

可用性を改善するためには、「冗長データユニット」の説明のように、HADB ノードを常に冗長データユニット (DRU) で使用します。

スペアノードによる耐障害性の改善

「スペアノード」の説明のようにスペアノードを使用することにより、耐障害性が改善されます。スペアノードは必須ではありませんが、最大の可用性を得たい場合は使用することをお勧めします。

フェイルオーバー機能の計画

フェイルオーバー機能の計画では、サーバー障害やプロセス障害が発生した場合にデータの回復と処理の継続をシームレスに行うために Sun ONE Application Server に追加するサーバーとプロセスの数を決定します。システムが過負荷状態になると、プロセスやサーバーの障害が発生し、応答時間が長くなったり、サービスが完全に停止したりする可能性があります。配備の成功のためには、こうした問題に備えて準備することが重要になります。

処理機能を保持するためには (特にピーク負荷時)、Sun ONE Application Server にアプリケーションサーバーインスタンスを実行するスペアマシンを追加することをお勧めします。たとえば、システム内に、アプリケーションサーバーを 1 台ずつ稼動する 2 台のマシンがあると想定します。これらのマシンは、ピーク負荷時の 1 秒あたり 300 の要求を処理できます。一方のマシンが使用不能状態になった場合、これらのマシンに均等な負荷がかかると仮定すると、システムによって処理される要求数は 150 になります。つまり、ピーク負荷時の要求の半分は処理されません。

複数のクラスタによる可用性の改善

可用性を改善するには、単一のクラスタを使用する代わりに、アプリケーションサーバーインスタンスを複数のクラスタ内にグループ化する必要があります。こうすることで、サービスを失うことなく、クラスタをオンラインで 1 個ずつアップグレードできます。

複数のクラスタをセットアップし、これらのクラスタを使ってサービスを失うことなくオンラインアップグレードを実行する方法については、『Sun ONE Application Server 管理者ガイド』を参照してください。

第 2 章 環境の計画