test

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

第 2 章 配備の計画

Application Server を配備する前に、まずパフォーマンスと可用性の目標を決定したあと、それに応じてハードウェア、ネットワーク、およびストレージの要件に関する決定を行います。

この章で説明する内容は次のとおりです。

パフォーマンス目標の確立

高パフォーマンスのもっとも単純な意味は、スループットを最大化し、応答時間を短縮することです。これらの基本的な目標を超えて特定の目標を確立するには、次の内容を決定します。

これらのメトリックスの一部は、リモートブラウザエミュレータ (RBE) ツールか、または予測されるアプリケーションアクティビティーのシミュレーションを行う Web サイトのパフォーマンスおよびベンチマークソフトウェアを使用して計算できます。一般に、RBE やベンチマーク製品は並行 HTTP 要求を生成し、次に 1 分あたりの特定数の要求に対する応答時間を報告します。これらの数値を使用することによって、サーバーアクティビティーを計算できます。

この章で説明されている計算の結果は絶対ではありません。Application Server や独自のアプリケーションのパフォーマンスを微調整するときに照合するための参照点として扱ってください。

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

スループットの見積もり

広義では、スループットは Application Server によって実行された作業の量を測定します。Application Server の場合、スループットは、サーバーインスタンスあたり、1 分あたりに処理された要求の数として定義できます。また、高可用性アプリケーションでは、セッション状態データが定期的に保存されるため、HADB にもスループット要件が課せられます。HADB の場合、スループットは、1 分あたりに格納されるセッションデータの量として定義できます。これは、1 分あたりの HADB 要求の数と、1 要求あたりの平均セッションサイズの積です。

次の節で説明するように、Application Server のスループットは、ユーザー要求の性質やサイズ、ユーザーの数、Application Server インスタンスやバックエンドデータベースのパフォーマンスを含む、多くの要因から成る関数です。シミュレートされた作業負荷のベンチマークによって、1 台のマシンでのスループットを見積もることができます。

高可用性アプリケーションでは、データが HADB に定期的に保存されるため、追加のオーバーヘッドが発生します。このオーバーヘッドの量は、データの量、データが変更される頻度、およびデータの保存頻度によって異なります。最初の 2 つの要因は対象のアプリケーションによって異なり、さらに後者はサーバー設定によっても影響されます。

HADB のスループットは、1 分あたりの HADB 要求の数に、1 要求あたりの平均データ量を掛けた値として定義できます。HADB のスループットを向上させるには、より多くの HADB ノードと、より大きいストアサイズが必要になります。

Application Server インスタンスへの負荷の見積もり

Application Server インスタンスへの負荷を見積もるには、次の要因を考慮してください。

並行ユーザーの最大数

ユーザーは、Web ブラウザや Java プログラムなどのクライアントを介してアプリケーションと対話します。ユーザーのアクションに基づいて、クライアントは Application Server に要求を定期的に送信します。ユーザーは、そのユーザーのセッションが期限切れでなく、終了されてもいないかぎり、アクティブと見なされます。並行ユーザーの数を見積もる場合は、すべてのアクティブユーザーを含めてください。

次の図は、ユーザーの数に対する、1 分あたりに処理される要求の数 (スループット) の標準的なグラフを示しています。最初は、ユーザーの数が増えると、それに対応してスループットが増加します。ただし、並行要求の数が増えるにつれてサーバーパフォーマンスが飽和し始めるため、スループットは低下し始めます。

並行ユーザーを追加した場合に 1 分あたりに処理できる要求の数が減る点を特定します。この点は、最適なパフォーマンスに達しており、それを超えるとスループットが低下し始める時点を示します。一般には、システムをできるだけ最適なスループットで動作させるようにしてください。追加の負荷を処理し、スループットを向上させるには、処理能力の追加が必要になる場合があります。

思考時間

ユーザーが要求を連続して送信することはありません。ユーザーが要求を送信すると、サーバーがその要求を受信し、処理したあと、結果を返します。ユーザーはその時点で、新しい要求を送信する前に一定の時間を費やします。ある要求から次の要求までの時間を、思考時間と呼びます。

思考時間は、ユーザーの種類に依存します。たとえば、Web サービスの場合のようなマシン同士の対話では一般に、思考時間は人間同士の対話より短くなります。思考時間を見積もるために、マシンと人間の対話の混在を考慮することが必要な場合があります。

平均思考時間の特定は重要です。この所要時間を使用すると、1 分あたりに完了する必要のある要求の数や、システムでサポートできる並行ユーザーの数を計算できます。

平均応答時間

応答時間とは、Application Server が、要求の結果をユーザーに返すために費やす時間のことを指します。応答時間は、ネットワーク帯域幅、ユーザーの数、送信される要求の数とタイプ、平均思考時間などの要因によって影響されます。

ここでは、応答時間は平均の応答時間を指します。要求のタイプごとに、独自の最小応答時間があります。ただし、システム性能を評価する場合は、すべての要求の平均応答時間に基づいて分析します。

応答時間が速ければ速いほど、1 分あたりに処理される要求が増えます。ただし、次の図に示すように、システム上のユーザーの数が増えるにつれ、1 分あたりの要求の数が低下するにもかかわらず応答時間も増え始めます。

申し訳ございません: このバージョンのマニュアルでは、図が用意できておりません。

この図のようなシステム性能のグラフは、特定の点を過ぎると、1 分あたりの要求数が応答時間に反比例することを示しています。点線の矢印で表されているように、1 分あたりの要求数の低下が激しければ激しいほど、応答時間の増加も急になります。

この図の場合、ピーク負荷の点は、1 分あたりの要求数が低下し始める時点になります。この点より前は、数式にピークの数値が使用されていないため、応答時間の計算は必ずしも正確ではありません。この点よりあとは、1 分あたりの要求数と応答時間の間に反比例の関係があるため、管理者は、ユーザーの最大数と 1 分あたりの要求数を使用して応答時間をより正確に計算できます。

ピーク負荷時の応答時間 (秒単位) である Tresponse を特定するには、次の数式を使用します。

Tresponse = n/r - Tthink

次に、各引数について説明します。

例 2–1 応答時間の計算

次の条件が存在する場合、

平均思考時間 (Tthink) は 1 要求あたり 3 秒。

応答時間の計算は次のようになります。

Tresponse = n/r - Tthink = (5000/1000) - 3 秒= 5 - 3 秒

したがって、応答時間は 2 秒です。

システムの (特に、ピーク負荷時の) 応答時間を計算したら、それを、アプリケーションで許容可能な応答時間と比較します。応答時間は、スループットとともに、Application Server のパフォーマンスにとって重要な主要要因の 1 つです。

1 分あたりの要求数

任意の時点での並行ユーザーの数、その要求の応答時間、およびユーザーの平均思考時間がわかっている場合は、1 分あたりの要求数を計算できます。一般には、システム上に存在する並行ユーザーの数の見積もりから始めます。

たとえば、管理者が Web サイトのパフォーマンスソフトウェアを実行したあと、オンラインバンキング Web サイトで要求を送信している並行ユーザーの平均数は 3,000 であるとの結論を出したとします。この数字は、オンライン銀行のメンバーになるためにサインアップしたユーザーの数、それらのユーザーのバンキングトランザクションの行い方、それらのユーザーが要求を送信するために選んだ日または週の時間帯などに依存します。

したがって、これらの情報がわかれば、この節で説明した 1 分あたりの要求数の数式を使用して、このユーザーベースに対してシステムが処理できる 1 分あたりの要求数を計算できます。ピーク負荷時には 1 分あたりの要求数と応答時間が反比例関係になるため、より優れた応答時間を得るためのトレードオフとして 1 分あたりの要求数を減らすことが許容可能かどうか、あるいは、1 分あたりの要求数を増やすためのトレードオフとして応答時間を遅くすることが許容可能かどうかを判断してください。

システム性能を微調整するための開始点として許容可能な 1 分あたりの要求数と応答時間のしきい値で試してください。そのあと、システムのどの領域に調整が必要かを判断してください。

前の節の式で r を求めると、次のようになります。

r = n/(Tresponse + Tthink)

例 2–2 1 秒あたりの要求数の計算

次の値の場合、

1 秒あたりの要求の数の計算は次のようになります。

r = 2800 / (1+3) = 700

したがって、1 秒あたりの要求の数は 700、1 分あたりの要求の数は 42000 です。

HADB への負荷の見積もり

HADB への負荷を計算するには、次の要因を考慮します。

セッション持続性を設定する手順については、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 9 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。

HTTP セッション持続性の頻度

HADB で受信される 1 分あたりの要求の数は、持続性の頻度に依存します。持続性の頻度によって、Application Server が HTTP セッションデータを HADB に保存する頻度が決定されます。

持続性の頻度オプションを次に示します。

次の表は、持続性の頻度オプションの長所と短所を要約しています。

表 2–1 持続性の頻度オプションの比較

持続性の頻度オプション 

長所 

短所 

web-method 

最新のセッション情報を使用できることが保証されます。 

応答時間が長くなり、スループットが低下する可能性があります。 

time-based 

応答時間が短縮されるとともに、スループットが向上する可能性もあります。 

アプリケーションサーバーインスタンスの障害が発生したあと、最新のセッション情報を使用できる保証は低くなります。 

HTTP セッションサイズと範囲

1 要求あたりのセッションサイズは、セッション内に格納されているセッション情報の量に依存します。

ヒント –

全体的なパフォーマンスを向上させるには、セッション内の情報の量をできるだけ削減します。

「持続性の範囲」の設定を使用して、1 要求あたりのセッションサイズを微調整することができます。HTTP セッション持続性の範囲を、次のオプションから選択します。

このオプションを使用するには、アプリケーションが次の処理を行う必要があります。

表 2–2 持続性の範囲オプションの比較

持続性の範囲オプション 

長所 

短所 

modified-session 

セッション状態を変更しない要求の応答時間が向上します。 

Web メソッド (一般には、doGet() または doPost()) の実行中、アプリケーションは次のセッションメソッドを呼び出す必要があります。

  • 属性が変更された場合は、setAttribute()

  • 属性が削除された場合は、removeAttribute()

session 

アプリケーションに制約はありません。 

modified-session および modified-attribute オプションに比べて、スループットや応答時間が低下する可能性があります。

modified-attribute 

変更されたセッション状態の割合が低い要求のスループットや応答時間が向上します。 

特定の要求に対する変更されたセッション状態の割合が 60% に近づくと、スループットや応答時間は低下します。このような場合は、属性を個別のレコードに分割するためのオーバーヘッドにより、パフォーマンスはほかのオプションの場合よりも低下します。 

ステートフルセッション Bean のチェックポイント設定

SFSB セッション持続性の場合、HADB への負荷は次の要素に依存します。

チェックポイント設定は一般に、その SFSB を含む任意のトランザクションが完了したあとに (そのトランザクションがロールバックした場合でも) 発生します。

パフォーマンスを向上させるには、チェックポイント設定に指定するメソッドのセットを小さくします。チェックポイントを設定するデータのサイズと、チェックポイント設定の頻度によって、特定のクライアント対話の応答時間で発生する追加のオーバーヘッドが決定されます。

ネットワーク構成の計画

Application Server をネットワークに統合する方法を計画する場合は、帯域幅の要件を見積もり、ユーザーのパフォーマンス要件を満たすような方法でネットワークを計画します。

ここで説明する内容は次のとおりです。

帯域幅の要件の見積もり

ネットワークの望ましいサイズと帯域幅を決定するには、まずネットワークトラフィックを特定し、そのピークを識別します。全体の量がピークになる特定の時間、曜日、または月の特定の日が存在するかどうかを確認したあと、そのピークの所要時間を特定します。

ピーク負荷の時間帯に、ネットワーク内のパケットの数はもっとも高いレベルに達します。一般に、ピーク負荷の設計を行う場合は、ピーク量の 100 パーセントを処理するという目標でシステムを拡張させます。ただし、どのようなネットワークでも予期しない動作をすること、またどれだけ拡張したとしても、必ずしもピーク量の 100 パーセントを処理できるとは限らないことを念頭においてください。

たとえば、ピーク負荷時に、ユーザーの 5 パーセントが Application Server 上に配備されているアプリケーションへのアクセス中にネットワークに直接アクセスできない場合があるとします。その 5 パーセントのうち、最初の試行のあとにアクセスを再試行するユーザーがどれだけいるかを見積もってください。ここでも、それらのユーザーがすべて実行するとは限らず、その失敗したユーザーのうちの一定の割合が再試行します。その結果、ユーザーがアクセスを試行し続けるに伴って徐々にピーク使用が拡大するため、ピークが現れる時間は長くなります。

必要な帯域幅の計算

「パフォーマンス目標の確立」で行なった計算に基づいて、サイトに Application Server を配備するために必要な追加の帯域幅を決定します。

アクセス方法 (T-1 回線、ADSL、ケーブルモデム、その他) に応じて、見積もった負荷を処理するために必要な増加した帯域幅の量を計算します。たとえば、サイトで T-1 回線または高速な T-3 回線を使用しているとします。回線の帯域幅がわかったら、サイトで 1 秒あたりに生成される要求の平均数および最大ピーク負荷に基づいて、ネットワークに必要な回線数を見積もります。Web サイトの分析および監視ツールを使用して、これらの数値を計算します。

例 2–3 必要な帯域幅の計算

1 本の T-1 回線は、1.544 Mbps を処理できます。したがって、T-1 回線 4 本から成るネットワークは約 6 Mbps のデータを処理できます。クライアントに送り返される平均的な HTML ページが 30K バイトであると仮定すると、T-1 回線 4 本から成るこのネットワークは 1 秒あたり次のトラフィックを処理できます。

6,176,000 ビット/8 ビット = 1 秒あたり 772,000 バイト

1 秒あたり 772,000 バイト/30K バイト = 1 秒あたり約 25 の並行応答ページ

1 秒あたり 25 ページのトラフィックとすると、このシステムは 1 時間あたり 90,000 ページ (25 × 60 秒× 60 分) を処理できるため、負荷が 1 日中均一であると仮定した場合、1 日あたり最大 2,160,000 ページになります。最大ピーク負荷がこれより高い場合は、それに応じて帯域幅を増やします。

ピーク負荷の見積もり

負荷を 1 日中均一にすることは、おそらく現実的ではありません。ピーク負荷がいつ発生し、どれだけ持続するか、および負荷全体の何パーセントがピーク負荷になるかを特定する必要があります。

例 2–4 ピーク負荷の計算

ピーク負荷が 2 時間持続し、2,160,000 ページの負荷全体の 30 パーセントに相当する場合は、1 日のうちの 2 時間の間に T-1 回線上で 648,000 ページを処理する必要があることを示します。

したがって、この 2 時間の間にピーク負荷に対応するには、T-1 回線の数を次の計算に従って増やします。

648,000 ページ/120 分 = 1 分あたり 5,400 ページ

1 分あたり 5,400 ページ/60 秒 = 1 秒あたり 90 ページ

4 回線で 1 秒あたり 25 ページを処理できるとすると、その約 4 倍のページにはその 4 倍の回線 (この場合は 16 回線) が必要になります。この 16 回線は、30 パーセントのピーク負荷という現実的な最大量の処理を考慮したものです。明らかに、これらの多数の回線を使用すれば、その他の 70 パーセントの負荷を 1 日の残り時間にわたって処理できます。

サブネットの設定

アプリケーションサーバーインスタンスと HADB ノードが個別のホストマシン上に存在する分離層トポロジを使用すると、すべての HADB ノードを個別のサブネット上に配置することによってパフォーマンスを向上させることができます。これは、HADB がユーザーデータグラムプロトコル (UDP) を使用しているためです。個別のサブネットを使用すると、そのサブネットの外側にあるマシン上の UDP トラフィックが削減されます。ただし、すべての HADB ノードが同じサブネット上に存在する必要があることに注意してください。

すべてのノードと管理エージェントが同じサブネット上に存在するかぎり、管理クライアントを別のサブネットから引き続き実行できます。すべてのホストとポートをすべてのノードエージェント内でアクセス可能にするとともに、ノードをファイアウォール、UDP のブロックなどでブロックしないでください。

HADB は UDP マルチキャストを使用するため、HADB ノードを含むサブネットはすべてマルチキャスト用に設定してください。

ネットワークカードの選択

帯域幅を増やし、ネットワークパフォーマンスを最適化するために、Application Server をホストしているサーバーと HADB ノードの間に少なくとも 100 Mbps の Ethernet カード、できれば 1 Gbps の Ethernet カードを使用してください。

HADB のためのネットワーク設定

注 –

HADB は UDP マルチキャストを使用するため、システムのルーターとホストのネットワークインタフェースカード上でマルチキャストを有効にしてください。HADB が複数のサブネットワークにまたがっている場合は、それらのサブネットワーク間のルーター上でもマルチキャストを有効にしてください。最適な結果を得るには、HADB ノードをすべて同じネットワーク上に配置します。アプリケーションサーバーインスタンスは、異なるサブネットワーク上に配置できます。

次の提案を採用すると、HADB をネットワーク内で最適な状態で動作させることができます。

可用性のための計画

ここでは、次の内容について説明します。

可用性の規模の適正化

システムやアプリケーションの可用性を計画するには、異なるアプリケーションにアクセスするユーザーグループの可用性ニーズを評価します。たとえば、料金を支払う外部のユーザーやビジネスパートナーはたいてい、サービスの品質 (QoS) に内部のユーザーより高い期待を持っています。そのため、アプリケーション機能、アプリケーション、サーバーなどが使用不可になっても、支払いを行う外部の顧客に比べて内部のユーザーの方が許容性が高い可能性があります。

次の図は、発生確率が低い出来事ほど、影響を軽減するためのコストと複雑さが増加するようすを示しています。この連続曲線の一端では、単純な負荷分散クラスタを使用して、ローカライズされたアプリケーション、ミドルウェア、およびハードウェアの障害に耐えることができます。曲線のもう一方の端では、地理的に孤立したクラスタを使用することにより、データセンター全体に影響する大災害を軽減できます。

高い投資収益率を実現するには、多くの場合、アプリケーション内の機能の可用性の要件を特定することが有効です。たとえば、保険見積もりシステムが使用不可になることは許容されない (それによって新しい企業を失う) 可能性がありますが、既存の顧客が現在の対象範囲を表示できるアカウント管理機能が短期間使用不可になっても、既存の顧客を失うことはほとんどありません。

可用性を向上させるためのクラスタの使用

もっとも基本的なレベルで言えば、クラスタとは、クライアントには 1 つのインスタンスとして見えるアプリケーションサーバーインスタンスのグループであり、たいていは複数の物理サーバー上にホストされています。これにより、水平方向のスケーラビリティーや、1 台のマシン上の 1 つのインスタンスより高い可用性が提供されます。この基本的なレベルのクラスタ分布が Application Server の HTTP ロードバランサプラグインと連携して動作します。このプラグインは、HTTP および HTTPS 要求を受け付け、それをクラスタ内のアプリケーションサーバーインスタンスの 1 つに転送します。また、ORB や、統合されている JMS ブローカも、アプリケーションサーバークラスタへの負荷分散を実行します。ネットワーク障害のためにインスタンスが失敗して使用不可になるか、または応答しなくなると、要求は既存の使用可能なマシンにのみリダイレクトされます。ロードバランサはまた、失敗したインスタンスが復旧したことを認識し、それに応じて負荷を再配分することもできます。

HTTP ロードバランサにはまた、サーバーや特定の URL を監視してそれらが使用可能かどうかを判定できる診断プログラムも用意されています。診断プログラムのオーバーヘッドを、それ自体が処理の大きな負荷にならないように慎重に管理してください。

状態を持たないアプリケーションや、低い値の単純なユーザートランザクションのみが含まれるアプリケーションには、たいてい、負荷分散された単純なクラスタがあれば十分です。状態のあるミッションクリティカルなアプリケーションに対しては、セッション持続性のために HADB を使用することを考慮してください。HADB の概要については、『Application Server 管理ガイド』の第 1 章「製品概念」にある 「高可用性データベース」を参照してください。

アプリケーションのオンラインアップグレードを実行するには、アプリケーションサーバーインスタンスを複数のクラスタにグループ化する方法が最適です。Application Server には、アプリケーションとインスタンスの両方を休止する機能があります。休止とは、インスタンス (またはインスタンスのグループ) あるいは特定のアプリケーションを、現在そのインスタンスまたはアプリケーションからサービスを受けているユーザーに影響を与えることなく、制御された方法でオフラインにする機能です。あるインスタンスが休止されると、新しいユーザーは、別のインスタンス上のアップグレードされたアプリケーションからサービスを受けます。この種類のアプリケーションアップグレードは、順次アップグレードと呼ばれます。生存中のアプリケーションのアップグレードの詳細については、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の「可用性を低下させないアプリケーションのアップグレード」を参照してください。

システムへの冗長性の追加

高可用性を実現するための 1 つの方法は、システムにハードウェアやソフトウェアの冗長性を追加することです。あるユニットに障害が発生すると、冗長なユニットが引き継ぎます。これは、耐障害性とも呼ばれます。一般に、高可用性を最大化するには、システム内に存在する可能性のあるすべてのシングルポイント障害を特定して取り除きます。

障害クラスの識別

冗長性のレベルは、システムが耐える必要のある障害クラス (障害の種類) によって決定されます。障害クラスのいくつかの例を次に示します。

重複したシステムプロセスによって、単一のシステムプロセス障害や単一のマシン障害に耐えることができます。重複した、ミラー化された (ペアになった) マシンを異なる電源装置に接続することにより、単一の電源障害に耐えることができます。ミラー化されたマシンを個別のビル内に保持することにより、単一のビル火災に耐えることができます。ミラー化されたマシンを地理的に離れた場所に保持することにより、地震などの天災に耐えることができます。

可用性を向上させるための HADB 冗長ユニットの使用

「パフォーマンス目標の確立」で説明したように、可用性を向上させるために、HADB ノードは常にデータ冗長ユニット (DRU) で使用されます。

耐障害性を向上させるための HADB スペアノードの使用

スペアノードを使用すると、耐障害性が向上します。スペアノードは必須ではありませんが、最大限の可用性を実現します。

フェイルオーバー容量の計画

フェイルオーバー容量の計画では、サーバーまたはプロセスに障害が発生した場合にシステムがデータをシームレスに復元して処理を続行できるようにするには Application Server 配備にサーバーやプロセスをどれだけ追加する必要があるかを決定します。システムが過負荷になると、プロセスまたはサーバー障害が発生して、応答時間の低下や、場合によってはサービスの完全な停止を引き起す可能性があります。このような状況に対して準備することは、配備を成功させるために重要です。

容量 (特に、ピーク負荷時の容量) を維持するには、既存の配備に、Application Server インスタンスを実行しているスペアマシンを追加します。

たとえば、それぞれ 1 つの Application Server インスタンスを実行している 2 台のマシンから成るシステムを考えてみます。これらのマシンが合わせて、1 秒あたり 300 要求のピーク負荷を処理しています。これらのマシンの 1 つが使用不可になった場合は、マシン間の負荷分散が均一であると仮定すると、システムは 150 の要求しか処理できません。したがって、ピーク負荷時の要求の半分はサービスを受けられなくなります。

設計上の決定

設計上の決定には、ピーク負荷または通常状態負荷のどちらのためにシステムを設計するか、およびさまざまな役割にあるマシンの数とそれらのサイズが含まれます。

ピーク負荷または通常状態負荷のための設計

標準的な配備では、通常状態とピークの作業負荷の間に違いが存在します。

システムでピーク負荷をどれだけ頻繁に処理すると予測されるかによって、ピーク負荷または通常状態負荷のどちらのために設計するかが決定されます。

ピーク負荷が頻繁に、たとえば 1 日に数回発生する場合は、それを処理できるように容量を拡張するだけの価値があるかもしれません。システムが時間全体の 90 パーセントを通常状態で動作し、ピーク負荷での動作が 10 パーセントしかない場合は、通常状態負荷のために設計されたシステムを配備する方が望ましい可能性があります。これは、システムの応答時間が時間全体の 10 パーセントだけ低下することを示します。システムがピーク負荷で動作する頻度または所要時間によって、システムにリソースを追加する必要性が正当化されるかどうかを判断してください。

システムのサイジング

アプリケーションサーバーインスタンスへの負荷、HADB への負荷、およびフェイルオーバーの要件に基づいて、次の値を決定できます。

Application Server インスタンスの数

必要なアプリケーションサーバーインスタンス (ホスト) の数を決定するには、各インスタンスが複数の中央処理装置 (CPU) を使用できるとしても、「Application Server インスタンスへの負荷の見積もり」で説明した各アプリケーションサーバーインスタンスに対する要因に基づいて環境を評価します。

HADB ノードの数

一般的なガイドラインとして、システム内の各 CPU に 1 つの HADB ノードを割り当てるように計画します。たとえば、2 つの CPU を備えたマシンには 2 つの HADB ノードを使用します。

注 –

マシンあたりに複数の HADB ノードを割り当てている (たとえば、大型のマシンを使用している) 場合は、マシン上に十分な冗長性とスケーラビリティー (たとえば、複数の無停電電源装置や独立したディスク制御装置) が必ず存在するようにしてください。

あるいは、次の手順を使用します。

Procedure必要な HADB ノードの数を決定するには

  1. 次のパラメータを決定します。

    • 並行ユーザーの最大数、nusers。

    • 平均の BLOB サイズ、s。

    • NTPS と呼ばれる、ユーザーあたりの最大トランザクション比率。

  2. 最大プライマリデータ量の G バイトのサイズ、V data を決定します。

    次の数式を使用します。

    Vdata = nusers .s

  3. 最大 HADB データ転送速度、R dt を決定します。

    この値には、アプリケーション側から HADB に転送されるデータ量が反映されます。次の数式を使用します。

    Rdt = nusers .s .NTPS

  4. ノードの数、N NODES を決定します。

    次の数式を使用します。

    NNODES = Vdata /5GB

    ノードはペアで動作するため、この値を偶数に丸めます。

HADB ホストの数

データ転送の要件に基づいて、HADB ホストの数を決定します。この計算では、すべてのホストが同じハードウェア構成とオペレーティングシステムを備え、かつ実行するノードを格納するために必要なリソースを含んでいることを前提にしています。

Procedureホストの数を計算するには

  1. 最大ホストデータ転送速度、R max を決定します。

    この値はネットワークやホストのハードウェアによって異なるため、経験に基づいて決定します。この値は、前の節で決定した最大 HADB データ転送速度、R dt とは異なることに注意してください。

  2. このデータを格納するために必要なホストの数を決定します。

    ホストの数 N HOSTS に分散されるデータ量 V を更新すると、各ホストは約 4V/N HOSTS のデータを受信するようになります。次の数式を使用して、このデータ量を格納するために必要なホストの数を決定します。

    NHOSTS = 4 .Rdt / Rmax

    各 DRU に対するホストの数を同じにするために、この値をもっとも近い偶数に丸めます。

  3. スペアノードとして、各 DRU に 1 台のホストを追加します。

    ほかの各ホストが N データノードを実行する場合は、このホストで N スペアノードを実行するようにします。これにより、単一のマシン障害で N データノードがダウンするようになります。

    各ホストは少なくとも 1 つのノードを実行する必要があるため、ノードの数がホストの数より小さい場合 (NNODES < NHOSTS) は、NNODES を NHOSTS に等しくなるように調整します。ノードの数がホストの数より大きい場合 (NNODES \> NHOSTS) は、同じホスト上でいくつかのノードを実行できます。

HADB のストレージ容量

HADB では、ネットワークの容量を超えるまで、ノードの追加によってほぼリニアなスケーリングが得られます。各ノードでは、専用のディスク (1 台または複数台) 上にストレージデバイスが設定されている必要があります。すべてのノードで、ストレージデバイスに等しい容量が割り当てられている必要があります。ストレージデバイスは必ずローカルディスクに割り当ててください。

予測されるセッションデータサイズが x M バイトであるとします。HADB はミラーノード上のデータをレプリケートするため、2x M バイトのストレージが必要です。さらに、HADB は、データへの高速アクセスを可能にするためにインデックスを使用しています。2 つのノードにはインデックス用に追加の 2x M バイトが必要であり、必要な合計ストレージ容量は 4x となります。したがって、HADB の予測されるストレージ容量の要件は、予測されるデータ量の 4 倍です。

新しいノードを追加したあとにデータの再断片化が必要になる可能性があるため、HADB からデータが失われることなく将来も拡張できるようにするには、オンラインアップグレードのための追加のストレージ容量を用意してください。この場合は、データデバイス上に同じ量 (4x) の追加の領域が必要です。そのため、予測されるストレージ容量は、予測されるデータ量の 8 倍になります。

さらに、HADB はディスク容量を次のように使用します。

次の表は、x M バイトのセッションデータサイズのための HADB ストレージ領域の要件を要約しています。

表 2–3 x M バイトのセッションサイズのための HADB ストレージ領域の要件

条件 

必要な HADB ストレージ領域 

オンラインが必須でない場合の HADB ノードの追加または削除。

4x M バイト + (4 ×ログバッファーサイズ) + デバイスサイズの 1%

オンラインが必須な場合の HADB ノードの追加または削除。 

8x M バイト + (4 ×ログバッファーサイズ) + デバイスサイズの 1%

HADB のデバイス領域が不足すると、HADB は、データを挿入または更新するクライアント要求を受け付けません。ただし、削除操作は受け付けます。HADB のデバイス領域が不足した場合は、エラーコード 4593 または 4592 を返し、対応するエラーメッセージを履歴ファイルに書き込みます。これらのメッセージの詳細については、『Sun Java System Application Server 9.1 Error Message Reference』の第 14 章「HADB Error Messages」を参照してください。

Message Queue ブローカの配備の計画

Java Message Service (JMS) API は、Java EE アプリケーションおよびコンポーネントに対して、メッセージの作成、送信、受信、および読み取りを可能にするメッセージング標準です。この API によって、緩やかに結合され、信頼性が高く、非同期の分散通信が可能となります。Sun Java System Message Queue は JMS を実装し、Application Server と統合されているため、MQ を使用してメッセージ駆動型 Beans (MDB) などのコンポーネントを作成できます。

Sun Java System Message Queue (MQ) は、J2EE コネクタアーキテクチャー仕様 (JCA) 1.5 で規定されているように、コネクタモジュール (リソースアダプタともいう) を使用して Application Server に統合されています。コネクタモジュールは、Application Server に機能を追加するための標準化された方法です。Application Server に配備された Java EE コンポーネントは、コネクタモジュールによって統合された JMS プロバイダを使用して JMS メッセージを交換します。この JMS プロバイダは、デフォルトでは Sun Java System Message Queue ですが、JCA 1.5 が実装されているかぎり、必要に応じて別の JMS プロバイダを使用できます。

Application Server で JMS リソースを作成すると、バックグラウンドでコネクタリソースが作成されます。そのようにして、JMS 操作のたびにコネクタランタイムが呼び出され、バックグラウンドで MQ リソースアダプタが使用されます。

リソースアダプタ API の使用に加えて、Application Server は、MQ とのより緊密な統合を実現するために MQ API を使用します。この緊密な統合によって、コネクタのフェイルオーバー、アウトバウンド接続の負荷分散、MDB へのインバウンドメッセージの負荷分散などの機能が可能になります。これらの機能を使用すると、メッセージングトラフィックの耐障害性や高可用性を実現できます。

マルチブローカクラスタ

MQ Enterprise Edition は、ブローカクラスタと呼ばれる、複数の相互接続されたブローカインスタンスの使用をサポートしています。ブローカクラスタによって、クライアント接続はクラスタ内のすべてのブローカに分散されます。クラスタ化することで、水平方向のスケーラビリティーが提供され、可用性が向上します。

1 つのメッセージブローカは約 8 個の CPU まで拡大縮小し、標準的なアプリケーションのための十分なスループットを提供します。ブローカプロセスが異常終了した場合、そのプロセスは自動的に再起動されます。ただし、ブローカーに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカーは最終的に、ファイル記述子の数やメモリーなどの制限を超えてしまいます。

クラスタ内に 1 つのブローカではなく複数のブローカを配置すると、次のことが可能になります。

ただし、複数のブローカを配置しても、ブローカ障害の時点で進行中であったトランザクションが代替ブローカに引き継がれることは保証されません。MQ は、失敗した接続をクラスタ内の別のブローカを使用して再確立しますが、トランザクションメッセージングを失い、進行中のトランザクションをロールバックします。完了できなかったトランザクションを除き、ユーザーアプリケーションは影響されません。接続は引き続き使用可能であるため、サービスのフェイルオーバーは保証されます。

そのため、MQ はクラスタ内の高可用性持続メッセージをサポートしていません。障害のあとにブローカを再起動すると、ブローカは自動的に回復し、持続メッセージの配信を完了します。持続メッセージはデータベース内か、またはファイルシステムに格納される可能性があります。ただし、ブローカをホストしているマシンがハード障害から回復しない場合は、メッセージが失われる可能性があります。

Sun Cluster Data Service for Sun Message Queue を備えた Solaris プラットフォームは、持続メッセージの透過的なフェイルオーバーをサポートしています。この構成は、真の高可用性を実現するために Sun Cluster のグローバルファイルシステムと IP フェイルオーバーを利用しており、また Java Enterprise System にも含まれています。

マスターブローカとクライアントの同期

マルチブローカ構成では、各送信先がクラスタ内のすべてのブローカにレプリケートされます。各ブローカは、ほかのすべてのブローカ上の送信先として登録されているメッセージコンシューマを認識しています。そのため、各ブローカは、自身に直接接続されているメッセージプロデューサから遠隔メッセージコンシューマにメッセージを経路指定したり、遠隔プロデューサから自身に直接接続されているコンシューマにメッセージを配信したりすることができます。

クラスタ構成では、各メッセージプロデューサが直接接続されているブローカが、そのプロデューサから送信されるメッセージの経路指定を実行します。そのため、持続メッセージの格納と経路指定の両方を、そのメッセージのホームブローカが実行します。

管理者がブローカ上の送信先を作成または破棄した場合は常に、この情報がクラスタ内のほかのすべてのブローカに自動的に伝播されます。同様に、メッセージコンシューマがホームブローカに登録された場合、またはコンシューマがホームブローカから切り離された (明示的か、クライアントまたはネットワークの障害のためか、ホームブローカがダウンしたためかにかかわらず) 場合は常に、そのコンシューマに関連する情報がクラスタ全体にわたって伝播されます。同様の方法で、持続性サブスクリプションに関する情報もクラスタ内のすべてのブローカに伝播されます。

Message Queue ブローカを使用するための Application Server の設定

Application Server の Java Message Service は、Message Queue のコネクタモジュール (リソースアダプタ) を表します。Java Message Service は、管理コンソールまたは asadmin コマンド行ユーティリティーから管理することができます。

MQ ブローカ (JMS ホスト) は、Application Server プロセスとは別の JVM で動作します。これにより、複数の Application Server インスタンスまたはクラスタが MQ ブローカの同じセットを共有できます。

Application Server では、JMS ホストは MQ ブローカを指します。Application Server の Java Message Service 設定には、使用されるすべての JMS ホストを含む JMS ホストリスト (AddressList とも呼ばれる) が含まれています。

管理コンソールを使用した JMS の管理

管理コンソールでは、特定の構成の「Java メッセージサービス」ノードを使用して JMS プロパティーを設定できます。「再接続間隔」や「再接続試行」などのプロパティーを設定できます。詳細は、『Sun Java System Application Server 9.1 管理ガイド』の第 4 章「Java Message Service (JMS) リソースの設定」を参照してください。

「Java メッセージサービス」ノードの下の「JMS ホスト」ノードには、JMS ホストのリストが含まれています。リストにホストを追加することも、リストからホストを削除することもできます。ホストごとに、ホスト名、ポート番号、および管理ユーザーの名前とパスワードを設定できます。JMS ホストリストには、デフォルトで、Application Server に統合されたローカルの MQ ブローカを表す、"default_JMS_host" という 1 つの MQ ブローカが含まれています。

JMS ホストリストを、クラスタ内のすべての MQ ブローカを含むように設定します。たとえば、3 つの MQ ブローカを含むクラスタを設定するには、それぞれに対して Java Message Service 内に 1 つの JMS ホストを追加します。Message Queue クライアントは、Java Message Service 内の設定情報を使用して MQ ブローカと通信します。

asadmin を使用した JMS の管理

管理コンソールに加えて、asadmin コマンド行ユーティリティーでも Java Message Service と JMS ホストを管理できます。次の asadmin コマンドを使用します。

Java Message Service タイプ

Application Server と MQ ブローカの間の統合には、ローカルとリモートの 2 つのタイプがあります。このタイプ属性は、管理コンソールの「Java メッセージサービス」ページで設定できます。

ローカルの Java Message Service

「タイプ」属性が LOCAL の場合は、Application Server が MQ ブローカを起動および停止します。Application Server は起動時に、デフォルト JMS ホストとして指定されている MQ ブローカを起動します。同様に、Application Server インスタンスは停止時に、MQ ブローカを停止します。LOCAL タイプはスタンドアロンの Application Server インスタンスに最適です。

LOCAL タイプでは、「起動引数」属性を使用して MQ ブローカの起動パラメータを指定します。

リモートの Java Message Service

「タイプ」属性が REMOTE の場合、Application Server は、外部に設定されているブローカまたはブローカクラスタを使用します。この場合、MQ ブローカの起動と停止は Application Server とは別個に行い、MQ ツールを使用してブローカまたはブローカクラスタを設定および調整する必要があります。REMOTE タイプは Application Server クラスタに最適です。

REMOTE タイプでは、MQ ツールを使用して MQ ブローカ起動パラメータを指定する必要があります。「起動引数」属性は無視されます。

デフォルト JMS ホスト

デフォルト JMS ホストは、管理コンソールの「Java メッセージサービス」ページで指定できます。Java Message Service タイプが LOCAL の場合、Application Server は、Application Server インスタンスが起動したときにデフォルト JMS ホストを起動します。

MQ ブローカクラスタを使用するには、デフォルト JMS ホストを削除したあと、クラスタ内のすべての MQ ブローカを JMS ホストとして追加します。この場合、デフォルト JMS ホストは JMS ホストリスト内の最初の JMS ホストになります。

また、デフォルト JMS ホストを、いずれかの JMS ホストに明示的に設定することもできます。Application Server が Message Queue クラスタを使用する場合、デフォルト JMS ホストは MQ 固有のコマンドを実行します。たとえば、MQ ブローカクラスタの物理送信先が作成される場合、デフォルト JMS ホストはその物理送信先を作成するためにコマンドを実行しますが、クラスタ内のすべてのブローカがその物理送信先を使用します。

配備シナリオの例

メッセージングのニーズに対応するには、Java Message Service と JMS ホストリストを、配備、パフォーマンス、および可用性のニーズを満たすように変更します。以降の節では、いくつかの標準的なシナリオについて説明します。

メッセージングのニーズの考慮対象が Application Server のみでない場合は、最高の可用性を得られるように、MQ ブローカと Application Server を別のマシンに配備します。別のオプションとして、十分なメッセージング容量が存在するようになるまで、Application Server インスタンスと MQ ブローカインスタンスを各マシンで実行する方法があります。

デフォルト配備

Application Server をインストールすると、ドメイン管理サーバー (DAS) が自動的に作成されます。デフォルトでは、DAS の Java Message Service タイプは LOCAL です。そのため、DAS を起動すると、そのデフォルト MQ ブローカも起動されます。

新しいドメインを作成すると、新しいブローカも作成されます。デフォルトでは、ドメインにスタンドアロンのサーバーインスタンスまたはクラスタを追加すると、その Java Message Service は REMOTE として設定され、デフォルト JMS ホストは DAS によって起動されるブローカになります。

「デフォルト配備」は、3 つのインスタンスを含む Application Server クラスタが含まれたデフォルト配備の例を示しています。

Application Server クラスタでの MQ ブローカクラスタの使用

MQ ブローカクラスタを使用するように Application Server クラスタを設定するには、Application Server の Java Message Service で、すべての MQ ブローカを JMS ホストとして追加します。それにより、作成された JMS 接続ファクトリや、配備された MDB はすべて、指定された JMS 設定を使用するようになります。

次の図は、ブローカクラスタ内に 3 つの MQ ブローカが含まれ、クラスタ内に 3 つの Application Server インスタンスが含まれる配備の例を示しています。

アプリケーション固有の MQ ブローカクラスタの指定

場合によっては、アプリケーションが、Application Server クラスタで使用されているものとは別の MQ ブローカクラスタを使用しなければならないことがあります。「アプリケーション固有の MQ ブローカクラスタの指定」は、このようなシナリオの例を示しています。これを行うには、JMS 接続ファクトリの AddressList プロパティー、または MDB 配備記述子内の activation-config 要素を使用して MQ ブローカクラスタを指定します。

接続ファクトリの設定の詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「JMS 接続ファクトリ」を参照してください。MDB の詳細については、『Sun Java System Application Server 9.1 Developer’s Guide』の「Using Message-Driven Beans」を参照してください。

アプリケーションクライアント

アプリケーションクライアントまたはスタンドアロンのアプリケーションが、JMS 管理によるオブジェクトにはじめてアクセスすると、クライアント JVM はサーバーから Java Message Service 設定を取得します。JMS サービスへのそれ以上の変更は、JMS サービスが再開されるまで、クライアント JVM には使用できません。