| Sun ONE Application Server 7, Enterprise Edition 管理者ガイド |
第 17 章
クラスタの管理クラスタの適用によって、使用するアプリケーションの高可用性の達成に、効果が期待できます。この章では、ロードバランサを使用してクラスタを管理する方法について説明します。また、クラスタに関する重要な情報も記載されていて、これらの情報は SunTM Open Net Environment (Sun ONE) Application Server 7, Enterprise Edition のフェイルオーバー機能を十分に活用するために役立ちます。
この章には次の節が含まれます。
クラスタについてクラスタは、1 つの論理エンティティとして連動する複数のアプリケーションサーバーインスタンスのグループです。クラスタは、1 つまたは複数の J2EE アプリケーションの実行時環境を提供します。
Sun ONE Application Server でクラスタを使用すると、次のことを達成するうえで役立ちます。
- クラスタ内のアプリケーションサーバーインスタンスのフェイルオーバー保護を可能にすることで得られる高可用性。つまり、1 つのアプリケーションサーバーインスタンスが停止した場合に、停止したサーバーで処理されていた要求をほかのアプリケーションサーバーインスタンスが引き継ぎます。
- クラスタへのアプリケーションサーバーインスタンスの追加を可能にすることで得られるスケーラビリティ、およびこれに伴うシステムの能力の向上。Sun ONE Application Server のロードバランサは、要求をクラスタ内の利用可能なアプリケーションサーバーインスタンスに分散させます。つまり、クラスタにアプリケーションサーバーインスタンスを追加しても、必要なサービスの整合性は維持されます。
注
複数のクラスタを使用して、サービスを中断せずにオンラインアップグレードを実行できます。これについては、「サービスの中断を伴わないオンラインアップグレードへの複数クラスタの使用」で説明します。
Sun ONE Application Server のクラスタに関する重要事項
Sun ONE Application Server のクラスタに関し、次の重要事項に注意する必要があります。
HTTP セッションのフェイルオーバーの詳細は、第 18 章「セッション持続性の設定」を参照してください。
- Sun ONE Application Server のクラスタの各アプリケーションサーバーインスタンスは、均質である必要があります。つまり、次のように設定します。
これらのアプリケーションがフェイルオーバーをサポートするには、アプリケーションが分散可能であること、つまりアプリケーションのセッションの持続性を有効にする必要があります。
詳細は、第 18 章「セッション持続性の設定」を参照してください。
- すべてのインスタンスが同じセッションストアを指すように指定する必要があります。詳細は、「セッションストアの作成」を参照してください。
- すべてのアプリケーションサーバーインスタンスで、cluster-id プロパティの値が同じである必要があります。詳細は、「アプリケーションサーバーインスタンスのクラスタ名の指定」を参照してください。
- クラスタ内の各アプリケーションサーバーインスタンスは、複数のアプリケーションに対応できます。
- 複数のクラスタに同じアプリケーションサーバーインスタンスを追加することは可能ですが、管理が複雑になるので、お勧めできません。たとえば、このようにすると、複数のクラスタの一部であるインスタンスをどれか 1 つのクラスタから削除するときに問題が発生する可能性があります。
- アプリケーションサーバーインスタンスは、1 つのクラスタの一部である必要はありません。ただし、1 つのクラスタの一部ではないインスタンスは、インスタンス間でのセッション状態の転送による高可用性を利用できません。
- 1 つのクラスタ内の各アプリケーションサーバーインスタンスは、複数のマシンからも、または同一のマシンでも管理できます。つまり、複数のマシンに分散しているアプリケーションサーバーインスタンスを 1 つのクラスタにグループ化できます。
- 特定のロードバランサでは、要求を複数のクラスタのアプリケーションサーバーインスタンスに転送できます。このロードバランサの機能を使用することで、サービスを中断せずにオンラインアップグレードを実行できます。詳細は、「サービスの中断を伴わないオンラインアップグレードへの複数クラスタの使用」を参照してください。
- 1 つのクラスタは、複数のロードバランサから要求を受信できます。1 つのクラスタが複数のロードバランサに対応する場合、各ロードバランサの設定とまったく同じようにクラスタを設定する必要があります。つまり、各 loadbalancer.xml ファイル内のクラスタに対応するエントリが同一である必要があります。
- 各セッションは、特定のクラスタに結び付けられています。これはつまり、1 つのアプリケーションを複数のクラスタに配備できるが、セッションのフェイルオーバーは同じクラスタ内のアプリケーションサーバーインスタンスのみに適用されることを示しています。
したがって、クラスタは、そのクラスタ内のアプリケーションサーバーインスタンスのセッションフェイルオーバーに対する安全上の境界としての役割を果たします。これにより、ロードバランサを使用して、サービスを中断せずに Sun ONE Application Server 内のコンポーネントをアップグレードできます。詳細は、「サービスの中断を伴わないオンラインアップグレードへの複数クラスタの使用」を参照してください。
割り当て済みの要求と未割り当ての要求について要求がクライアントからロードバランサにはじめて着信したときには、新しいセッションの要求として扱われます。新しいセッションの要求は、未割り当ての要求と呼ばれます。ロードバランサは、ラウンドロビンアルゴリズムに従って、この要求をクラスタ内のアプリケーションサーバーインスタンスにルーティングします。詳細は、「ロードバランスのアルゴリズム」を参照してください。
1 つのアプリケーションサーバーインスタンス上でセッションが作成された後、ロードバランサはその特定のインスタンスのみに、そのセッションに関する後続のすべての要求をルーティングします。既存のセッションの要求は、割り当て済みの要求と呼ばれます。
クラスタの定義クラスタを定義するには、loadbalancer.xml ファイルにクラスタの名前を指定します。クラスタに関するその他のパラメータも設定します。
クラスタの名前を定義するには、cluster 要素の name 属性を使用します (cluster は、loadbalancer.xml ファイル内の要素 loadbalancer のサブ要素)。
新しいクラスタを定義するには、次の手順に従います。
- loadbalancer.xml ファイルで、loadbalancer 要素の新しいサブ要素 cluster を作成します。
- cluster の name 属性に一意の名前を指定します。
- クラスタのヘルスチェッカ用の URL を指定します。
アプリケーションサーバーインスタンスのリスナーの URL の末尾にヘルスチェッカの URL が追加されて、ヘルスチェックの要求をインスタンスに送信する際の URL が構成されます。たとえば、インスタンスのリスナーの URL が http://www.example.com:80 で、ヘルスチェッカの URL が /fortune である場合、そのインスタンスに対するヘルスチェックの要求はhttp://www.example.com:80/fortune に送信されます。
ヘルスチェックの要求は、HTTP 要求です。インスタンスからの応答は、100 〜 500 の範囲になります。
loadbalancer.xml ファイル内にある health-checker 要素の url 属性を使用して、ヘルスチェックの URL を指定します (health-checker 要素は cluster 要素のサブ要素)。
- health-checker 要素の interval-in-seconds 属性を使用して、このヘルスチェックが次に実行されるまでの時間間隔を秒単位で指定します。この値は数値で指定します。デフォルト値は 30 秒です。
- health-checker 要素の time-out-in-seconds 属性を使用して、ヘルスチェックの要求のタイムアウト値を秒単位で指定します。これは、ロードバランサから送信されたヘルスチェック要求に対する、アプリケーションサーバーインスタンスからの応答を待機する時間です。この時間内に応答がない場合は、そのアプリケーションサーバーインスタンスは使用できないとみなされます。デフォルト値は 10 秒です。
例 : クラスタの定義
クラスタへのアプリケーションサーバーインスタンスの追加について
クラスタにアプリケーションサーバーインスタンスを追加するには、loadbalancer.xml ファイル内にある cluster 要素の instance サブ要素を使用します。
次の表は、instance の属性について説明しています。左端の列には属性の名前、左から 2 番目の列には属性のデフォルト値、左から 3 番目の列には属性の指定が必須であるかどうかの区分、右端の列には属性の説明を示しています。
表 17-1 instance 要素の属性
属性名
デフォルト値
必須 (Yes または No)
説明
name
デフォルト値の指定なし
Yes
loadbalancer.xml ファイル内のアプリケーションサーバーインスタンスの名前を指定する。この名前は、インスタンスの作成時に指定したアプリケーションサーバーインスタンスの名前と同じである必要はない。この名前は、1 つのクラスタに対して一意である必要がある。つまり、1 つのクラスタ内にある 2 つのアプリケーションサーバーインスタンスに同じ名前を付けることはできない
enabled
true
No
アプリケーションサーバーインスタンスを有効にするか無効にするかを指定する
disable-timeout-in-minutes
31
No
アプリケーションサーバーインスタンスの静止時間を分単位で指定する。詳細は、「静止について」を参照
listeners
デフォルト値の指定なし
Yes
アプリケーションサーバーインスタンスの HTTP リスナーを指定する。リスナーの URL を空白文字で区切ることによって、1 つのアプリケーションサーバーインスタンスに複数のリスナーを指定できる
アプリケーションサーバーインスタンスの有効化と起動の違い
アプリケーションサーバーインスタンスの有効化は、アプリケーションサーバーインスタンスの起動とは異なります。アプリケーションサーバーインスタンスを起動して、これをクラスタの一部として定義しても、有効化しなければ、このアプリケーションサーバーインスタンスはロードバランサからの要求を受信しません。クラスタの一部であるアプリケーションサーバーインスタンスが有効化されると、ロードバランサはそのアプリケーションサーバーインスタンスに要求をルーティングします。つまり、有効化によって、アプリケーションサーバーインスタンスがクラスタの一部として有効になります。同様に、アプリケーションサーバーインスタンスの無効化は、アプリケーションサーバーインスタンスの停止とは異なります。
アプリケーションサーバーインスタンスの設定を変更する場合、アプリケーションサーバーインスタンスの再起動が必要になることがあります。このような場合には、アプリケーションサーバーインスタンスの無効化、停止、起動、有効化という正しい順序で実行する必要があります。このシナリオの詳細は、「クラスタ実行時のアプリケーションサーバーインスタンスの再設定」を参照してください。
注
loadbalancer.xml ファイルでアプリケーションサーバーインスタンスの有効化または無効化を指定すると、ロードバランサが次に loadbalancer.xml ファイルのポーリングを実行するときに、そのインスタンスが有効化または無効化されます。詳細は、「動的再設定について」を参照してください。
クラスタへのアプリケーションサーバーインスタンスの追加の要件
クラスタにアプリケーションサーバーインスタンスを追加するには、次の条件が満たされている必要があります。
- クラスタにアプリケーションサーバーインスタンスを追加する前に、管理インタフェースまたはコマンド行インタフェースを使ってインスタンスを作成しておく必要があります。アプリケーションサーバーインスタンスの作成方法の詳細は、「アプリケーションサーバーインスタンスの追加」を参照してください。
- クラスタに新しいアプリケーションサーバーインスタンスを追加する場合は、Sun ONE Administration Server のバージョンとパッチレベルが、クラスタ内にあるすべての既存のアプリケーションサーバーインスタンスと同じである必要があります。
- 必要なすべてのペリフェラル製品およびライブラリ (JDBC ドライバクラスなど) の可用性を正しい場所で確保し、必要なアクセス権を設定する必要があります。
- Sun ONE Application Server のクラスタのアプリケーションサーバーインスタンスは、均質である必要があります。つまり、次のように設定します。
- 任意のアプリケーションのセッション持続性の設定は、1 つのクラスタ内のすべてのインスタンスに対して同一である必要があります。一定の設定でアプリケーションをクラスタ内のインスタンスの 1 つのセグメントに配備して、別の設定でアプリケーションをクラスタ内のインスタンスの別のセグメントに配備しないでください。
- すべてのインスタンスが同じセッションストアを指すように指定する必要があります。詳細は、「セッションストアの作成」を参照してください。
- すべてのアプリケーションサーバーインスタンスで、cluster-id プロパティの値が同じである必要があります。詳細は、「アプリケーションサーバーインスタンスのクラスタ名の指定」を参照してください。
- クラスタに含まれているアプリケーションサーバーインスタンスは、それらが動作している全コンピューターで、システムクロックの同期が必要になります。
クラスタへのアプリケーションサーバーインスタンスの追加クラスタにアプリケーションサーバーインスタンスを追加するには、次の手順に従います。
- loadbalancer.xml ファイルで、cluster 要素の新しいサブ要素 instance を作成します。
- instance の name 属性を使用して、アプリケーションサーバーインスタンスに名前を指定します。この名前は、インスタンスの作成時に指定したアプリケーションサーバーインスタンスの名前と同じである必要はありません。この名前は、1 つのクラスタに対して一意である必要があります。つまり、1 つのクラスタ内にある 2 つのアプリケーションサーバーインスタンスに同じ名前を付けることはできません。
- instance の enabled 属性に true または false を指定することによって、アプリケーションサーバーインスタンスを有効化するか無効化するかを指定します。デフォルト値は true、つまり、アプリケーションサーバーインスタンスは有効化されます。アプリケーションサーバーインスタンスの有効化および無効化の詳細は、「アプリケーションサーバーインスタンスの有効化と起動の違い」を参照してください。
- instance の disable-timeout-in-minutes 属性を使用して、静止時間を分単位で指定します。この値は数値で指定します。デフォルト値は 31 です。つまり、session-idle-timeout のデフォルト値 (30 分) よりも 1 分長く設定されています。
アプリケーションサーバーインスタンスを無効化した場合、この時間は、割り当て済み要求のアプリケーションサーバーインスタンスへの送信をロードバランサが停止するまでの時間間隔になります。静止および静止時間の詳細は、「静止について」を参照してください。
- アプリケーションサーバーインスタンスに HTTP リスナーの URL を指定することによって、アプリケーションサーバーインスタンスのリスナーを指定します。
この情報は、loadbalancer.xml ファイル内にある instance 要素の listeners 属性を使用して指定します。アプリケーションサーバーインスタンスには、1 つまたは複数のリスナーを割り当てることができます。1 つのアプリケーションサーバーインスタンスに複数のリスナーを指定するには、リスナーの URL を空白文字で区切ります。たとえば、次のようになります。https://www.example.com:41 https://www.example.com:42
myinstance1 という名前のアプリケーションサーバーインスタンスが mycluster1 という名前のクラスタに追加された場合の例を次に示します。アプリケーションサーバーインスタンスに 2 つの リスナーが指定されています。このクラスタ用のヘルスチェッカも設定されています。
<cluster name="mycluster1">
<instance name="myinstance1" enabled="true" disable-timeout-in-minutes="36" listeners="http://www.example.com:41 https://www.example.com:42">
</instance>
<health-checker url="/" interval-in-seconds="10" time-out-in-seconds="15" />
</cluster>
複数のクラスタの設定1 つのロードバランサが複数のクラスタに対応するように設定できます。そのためには、各クラスタを「クラスタの定義」および「クラスタへのアプリケーションサーバーインスタンスの追加」の説明のとおりに設定します。
注
セッションの持続性を設定するときは、各クラスタに別々のセッションストアを作成します。クラスタにセッションストアを作成する方法については、「セッションストアの作成」を参照してください。
クラスタへの Web アプリケーションの配備クラスタに Web アプリケーションを配備するには、次の手順に従います。
- クラスタ内のすべてのアプリケーションサーバーインスタンスに Web アプリケーションを配備します。
クラスタ内のすべてのインスタンスに Web アプリケーションを配備するには、cladmin コマンドを次のように使用します。
./cladmin deploy [--instancefile instance_file_location] [--passwordfile password_file_location][--secure | -s] [--virtualservers virtual_servers] [--type application|ejb|web|connector] [--contextroot contextroot] [--force=true|false] [--precompilejsp=true|false] [--name component_name] [--upload=true|false] [--retrieve local_dirpath] [--instance instance_name] filepath
各変数の意味は次のとおりです。
- instance_file_location は、clinstance.conf ファイルの保存場所である
- password_file_location は、clpassword.conf ファイルの保存場所である
cladmin コマンドの詳細は、第 19 章「cladmin コマンドの使用」を参照してください。アプリケーションサーバーインスタンスへのアプリケーションの配備の詳細は、「配備ツール」を参照してください。
- loadbalancer.xml ファイルで、アプリケーションを配備するクラスタ用の cluster 要素の新しいサブ要素 web-module を作成します。
- web-module 要素の context-root 属性を使用して、クラスタに配備する Web モジュールのコンテキストルート URL を指定します。
- web-module の enabled 属性に true または false を指定することによって、Web アプリケーションを有効化するか無効化するかを指定します。デフォルト値は true、つまり、Web アプリケーションは有効化されます。
通常、クラスタにアプリケーションを配備するときに、アプリケーションを有効化します。クラスタ内のアプリケーションが有効化されると、ロードバランサはそのアプリケーションに要求をルーティングします。
- web-module の disable-timeout-in-minutes 属性の値を使用して、静止時間を分単位で指定します。この値は数値で指定します。デフォルト値は 31 です。つまり、session-idle-timeout のデフォルト値 (30 分) よりも 1 分長く設定されています。
Web アプリケーションを無効化した場合、この時間は、割り当て済み要求の Web アプリケーションへの送信をロードバランサが停止するまでの時間間隔になります。静止の詳細は、「静止について」を参照してください。
コンテキストルートが /fortune である Web アプリケーションを cluster1 という名前のクラスタに追加した場合の例を次に示します。
<cluster name="cluster1">
<web-module context-root="/fortune" enabled="true" />
</cluster>
loadbalancer.xml ファイルでのクラスタ設定の例loadbalancer.xml ファイルにおけるクラスタのエントリの例を次に示します。実際の loadbalancer.xml ファイルには、これ以外のエントリも存在します。たとえば、ロードバランサのポーリング間隔や HTTPS ルーティングの有効化に関連するエントリなどがあります。その他の使用可能なエントリの詳細は、「ロードバランサの設定ファイル」を参照してください。
<loadbalancer name="loadbalancer1">
<cluster name="cluster1">
<instance name="myinstance1" enabled="true" listeners="http://www.example.com:41 https://www.example.com:42">
</instance>
<instance name="myinstance2" enabled="true" listeners="http://www.example.com:43 https://www.example.com:44">
</instance>
<web-module context-root="/fortune" enabled="true" />
<web-module context-root="/shopping" enabled="true" />
<health-checker url="/" interval-in-seconds="10" />
</cluster>
</loadbalancer>
クラスタの起動クラスタを起動するには、次の手順に従います。
- クラスタ内のすべてのアプリケーションサーバーインスタンスを起動します。
クラスタ内のすべてのインスタンスを起動するには、cladmin コマンドを次のように使用します。
./cladmin [--instancefile instance_file_location] [--passwordfile password_file_location]start-instance
各変数の意味は次のとおりです。
- instance_file_location は、clinstance.conf ファイルの保存場所である
- password_file_location は、clpassword.conf ファイルの保存場所である
cladmin コマンドの詳細は、第 19 章「cladmin コマンドの使用」を参照してください。
- クラスタ内のすべてのアプリケーションサーバーインスタンスを有効化します。
静止についてクラスタ内のアプリケーションサーバーインスタンスが要求を受信し、これを処理中であるとします。何らかの理由で (たとえば、JDBC リソースを追加するために) このインスタンスを停止する場合、そのインスタンスでの要求の処理が完了した後に停止したいことがあります。また、クラスタから Web アプリケーションの配備を取り消す場合に、これらのアプリケーションに対する要求を処理しているクラスタ内のすべてのインスタンスが要求の処理を完了した後に Web アプリケーションの配備を取り消したいこともあります。静止は、このような場合に役立つプロセスです。
この節では、次のトピックを取り上げます。
クラスタ内のアプリケーションサーバーインスタンスの無効化と静止
アプリケーションサーバーインスタンスの静止は、アプリケーションサーバーインスタンスを段階的に停止するプロセスです。最初に、ロードバランサはインスタンスへの未割り当て要求の送信を停止し、代わりに、これらの未割り当て要求をクラスタ内の利用可能な別のインスタンスに転送します。
ただし、静止時間と呼ばれる時間間隔内には、ロードバランサは引き続き、処理中の割り当て済み要求をアプリケーションサーバーインスタンスに送信します。アプリケーションサーバーインスタンスの静止時間の指定方法の詳細は、「クラスタへのアプリケーションサーバーインスタンスの追加」を参照してください。
次に、静止時間の終了後、ロードバランサはインスタンスで処理中だった割り当て済み要求のアプリケーションサーバーインスタンスへの送信を停止し、これらの割り当て済み要求をクラスタ内の利用可能な別のインスタンスにフェイルオーバーします。
注
このような割り当て済み要求への対応は、該当する Web アプリケーションで高可用性が有効化されている場合にのみ実行されます。Web アプリケーションの高可用性の有効化の詳細は、「アプリケーションを分散可能にする」を参照してください。
静止時間の終了後でも、ロードバランサが静止時間内にインスタンスに振り分けた要求については、ロードバランサはインスタンスがこのようなすべての要求を処理することを許可します。このような要求については、ロードバランサは静止時間の終了後であってもクライアントに結果を返します。したがって、ユーザーは静止時間に加えて、アプリケーションサーバーインスタンスによる要求の処理が完了できるだけの十分な待機時間をとり、その後にアプリケーションサーバーインスタンスを停止する必要があります。
ただし、場合によっては、このような要求の処理の実行時間が非常に長くなり、アプリケーションサーバーインスタンスを停止したときにこのような要求の一部が処理されないことがあります。
loadbalancer.xml ファイルに変更を加えて、その変更を保存した後、ただちに静止が開始することはありません。ロードバランサは、定期的に loadbalancer.xml ファイルのポーリングを実行して、前回のポーリングの実行後にファイルのタイムスタンプが変更されていないかどうかを確認します。詳細は、「動的再設定について」を参照してください。ロードバランサは、前回のポーリング後にファイルのタイムスタンプが変更されていることを検出すると、loadbalancer.xml ファイルの設定全体を再読み込みします。したがって、アプリケーションサーバーインスタンスを無効化した場合、ロードバランサが次に loadbalancer.xml ファイルのポーリングを実行するときに、ロードバランサはそのアプリケーションサーバーインスタンスの静止を開始します。同様に、loadbalancer.xml ファイルでインスタンスの有効化を指定すると、ロードバランサが次に loadbalancer.xml ファイルのポーリングを実行するときに、そのインスタンスが有効化されます。
例として、静止時間が 31 分に設定されているアプリケーションサーバーインスタンスを取り上げます。静止時間の開始時に、ロードバランサはアプリケーションサーバーインスタンスへのすべての未割り当て要求の送信を停止しますが、アプリケーションサーバーインスタンスへの割り当て済み要求の送信は続行します。31 分後に、ロードバランサは割り当て済み要求についてもアプリケーションサーバーインスタンスへの送信を停止し、これらの割り当て済み要求をクラスタ内の利用可能な別のアプリケーションサーバーインスタンスにフェイルオーバーします。ただし、30 分 50 秒後の時点でロードバランサが割り当て済み要求をアプリケーションサーバーインスタンスに送信した場合、31 分を経過した後でも、そのアプリケーションサーバーインスタンスではこの割り当て済み要求を処理できます。
静止を有効化するには、loadbalancer.xml ファイル内にある instance 要素の enabled 属性を使用します。実行中のクラスタでは、該当する loadbalancer.xml ファイルでそのクラスタのアプリケーションサーバーインスタンスに対応する enabled の値を false に設定すると、(ロードバランサが次に loadbalancer.xml ファイルのポーリングを実行するときに) そのアプリケーションサーバーインスタンスの静止が開始します。
loadbalancer.xml ファイル内にある instance 要素の disable-timeout-in-minutes サブ要素を適切な値に指定することによって、静止時間を指定します。disable-timeout-in-minutes のデフォルト値は 31 分です。つまり、session-idle-timeout のデフォルト値 (30 分) よりも 1 分長く設定されています。
ロードバランサのログを参照すると、アプリケーションサーバーインスタンスが静止しているかどうかを確認できます。インスタンスが静止すると、このログには次のエントリが記述されます。
instance: instance_name quiesced successfully over the cluster: cluster_name
instance_name は、loadbalancer.xml ファイルでそのインスタンスに指定されている名前です。cluster_name は、そのインスタンスが置かれているクラスタの名前であり、loadbalancer.xml ファイルで指定されています。
クラスタ内の Web アプリケーションの無効化と静止
クラスタ上の Web アプリケーションを無効化すると、ロードバランサは、その Web アプリケーションに対するすべての未割り当て要求をクラスタ内のアプリケーションサーバーインスタンスに送信することを停止します。ロードバランサが処理を実行するほかのクラスタ上にこの Web アプリケーションが配備されている場合、これらの未割り当て要求はそのクラスタ内のアプリケーションサーバーインスタンスに送信されます。
ただし、この Web アプリケーションに対する割り当て済み要求のうち、そのクラスタ内のアプリケーションサーバーインスタンスによって処理されるものについては、静止時間が終了するまで処理が続行されます。静止時間の終了後、ロードバランサはこれらの割り当て済み要求についても、クラスタ内のアプリケーションサーバーインスタンスへの送信を停止します。
クラスタ内の Web アプリケーションを無効化するには、loadbalancer.xml ファイル内にある web-module 要素の enabled 属性を使用します。実行中のクラスタでは、そのクラスタ内の Web アプリケーションに対応する enabled の値を false に設定すると、そのクラスタ上の Web アプリケーションが無効化されます。アプリケーションサーバーインスタンスの場合と同様、ファイルに変更を加えて、その変更を保存した後、ただちに静止が開始することはありません。静止は、ロードバランサによるポーリングが次に実行された後で開始します。
loadbalancer.xml ファイル内にある web-module 要素の disable-timeout-in-minutes サブ要素を適切な値に指定することによって、静止時間を指定します。disable-timeout のデフォルト値は 31 分です。つまり、session-idle-timeout のデフォルト値 (30 分) よりも 1 分長く設定されています。
ロードバランサのログを参照すると、Web アプリケーションが静止しているかどうかを確認できます。Web アプリケーションが静止すると、このログには次のエントリが記述されます。
Application: application_name quiesced successfully over the cluster cluster_name
変数の意味は次のとおりです。
静止中における静止時間の変更
アプリケーションサーバーインスタンスまたは Web アプリケーションが静止中であり、静止時間がロードバランサのポーリング間隔よりも長い時間に設定されているとします。
ここで、ロードバランサの次のポーリング間隔が到来する前に、loadbalancer.xml ファイルにその他の変更を加えます。ロードバランサは、loadbalancer.xml ファイルのポーリングを次に実行するときに、そのファイルの前回のポーリング後にタイムスタンプが変更されていることを検出します。このとき、静止時間はロードバランサのポーリング時間よりも長いため、静止時間は終了していません。しかし、ロードバランサは設定全体を再読み込みして、静止プロセスを再び開始します。
この機能を使用すると、静止しているアプリケーションサーバーインスタンスまたは Web アプリケーションの静止時間を変更できます。例として、次のシナリオを検討します。
アプリケーションサーバーインスタンスの静止時間は 30 分で、ロードバランサのポーリング間隔は 1 秒です。ここで、アプリケーションサーバーインスタンスを無効化します。ロードバランサは、ポーリングを再び実行するときに、インスタンスの静止を開始します。
その 10 分後に、ユーザーが静止時間全体を 30 分から 15 分に短縮するとします。つまり、この時点から 5 分後に静止時間を終了させたいということです。そのためには、アプリケーションサーバーインスタンスの静止時間を 5 分に変更します。ロードバランサは、ポーリングを再び実行するときに、(まだ静止が終了していないため) 新たに設定した 5 分の静止時間でインスタンスを再び静止させます。
したがって、静止時間全体は 15 分になります (最初のサイクルの 10 分と 2 度目のサイクルの 5 分)。
言うまでもなく、この機能を使用するときに、静止時間をロードバランサのポーリング間隔よりも短い時間に短縮することはできません。
ロードバランサのポーリング間隔の設定の詳細は、「動的再設定について」を参照してください。
サービスの中断を伴わないオンラインアップグレードへの複数クラスタの使用ロードバランサおよび複数のクラスタを使用すると、サービスを中断せずに Sun ONE Application Server 内のコンポーネントをアップグレードできます。この場合のコンポーネントは、JVM、Sun ONE Application Server または Web アプリケーションなどです。
このアップグレードを実行するには、次の手順に従います。
1 つのクラスタ内のセッションが別のクラスタ内のセッションにフェイルオーバーされることはないので、あるバージョンのコンポーネントを実行中のアプリケーションサーバーインスタンスから、別のバージョンのコンポーネントを実行中の (別のクラスタ内にある) アプリケーションサーバーインスタンスにセッションがフェイルオーバーされてバージョンのミスマッチが発生するリスクはありません。この方法では個々のクラスタが、そのクラスタ内のアプリケーションサーバーインスタンスのセッションフェイルオーバーに対する安全上の境界としての役割を果たします。
注
この方法は、次の場合には実行できません。
- 高可用性データベース (HADB) のスキーマを変更する場合。詳細は、第 20 章「高可用性データベースの管理」を参照
- アプリケーションデータベースのスキーマの変更を伴うアプリケーションアップグレードを実行する場合
警告
1 つのクラスタ内のすべてのインスタンスを一括してアップグレードする必要があります。それ以外の場合、あるアプリケーションサーバーインスタンスから、別のバージョンのコンポーネントを実行中の別のアプリケーションサーバーインスタンスにセッションがフェイルオーバーされて、バージョンのミスマッチが発生するリスクが生じます。
クラスタ実行時のアプリケーションサーバーインスタンスの再設定(有効化されている) アプリケーションサーバーインスタンスの設定を変更する場合、アプリケーションサーバーインスタンスの再起動が必要になることがあります。たとえば、JDBC リソースをアプリケーションサーバーインスタンスに追加するときには、アプリケーションサーバーインスタンスの再起動が必要になります。このような場合には、次の手順に従います。
- (loadbalancer.xml ファイルで) instance 要素の enabled 属性の値を false に設定することによって、該当するクラスタのアプリケーションサーバーインスタンスを無効化します。
- 静止時間が終了し、さらにアプリケーションサーバーインスタンスによる要求の処理が完了できるだけの十分な待機時間をとった後で、アプリケーションサーバーインスタンスを再設定します。
- アプリケーションサーバーインスタンスを再起動します。
- (loadbalancer.xml ファイルで) instance 要素の enabled 属性の値を true に設定することによって、アプリケーションサーバーインスタンスを有効化します。
クラスタからの Web アプリケーションの配備取り消しクラスタから Web アプリケーションの配備を取り消すには、次の手順に従います。
- (loadbalancer.xml ファイルで) web-module 要素の enabled 属性の値を false に設定することによって、該当するクラスタ内の Web アプリケーションを無効化します。
- 静止時間の終了後、そのクラスタ内のすべてのアプリケーションサーバーインスタンスから Web アプリケーションの配備を取り消します。
クラスタ内のすべてのインスタンスから Web アプリケーションの配備を取り消すには、cladmin コマンドを次のように使用します。
./cladmin undeploy [--instancefile instance_file_location] [--passwordfile password_file_location][--secure | -s] [--type application|ejb|web|connector] [--instance instance_name] component_name
各変数の意味は次のとおりです。
cladmin コマンドの詳細は、第 19 章「cladmin コマンドの使用」を参照してください。アプリケーションサーバーインスタンスからのアプリケーションの配備取り消しの詳細は、「配備ツール」を参照してください。
既存の Web アプリケーションのクラスタへの再配備配備された Web アプリケーションに変更を加える場合、配備を取り消した後で再配備する必要性が生じることがあります。たとえば、アップグレードされたバージョンの Web アプリケーションを配備する場合などです。このような場合には、次の手順に従います。
クラスタ内のアプリケーションサーバーインスタンスの停止クラスタ内のアプリケーションサーバーインスタンスを停止するには、次の手順に従います。
クラスタの停止クラスタを停止するには、次の手順に従います。
- (loadbalancer.xml ファイルで) 該当する instance 要素の enabled 属性の値を false に設定することによって、そのクラスタのすべてのアプリケーションサーバーインスタンスを無効化します。
- 静止時間が終了し、さらにアプリケーションサーバーインスタンスによる要求の処理が完了できるだけの十分な待機時間をとった後で、そのクラスタに属するすべてのアプリケーションサーバーインスタンスを停止します。
クラスタ内のすべてのインスタンスを停止するには、cladmin コマンドを次のように使用します。
./cladmin [--instancefile instance_file_location] [--passwordfile password_file_location] stop-instance
クラスタからのアプリケーションサーバーインスタンスの削除クラスタから、1 つのアプリケーションサーバーインスタンスを削除する手順は、以下のとおりです。
- (loadbalancer.xml ファイルで) 該当する instance 要素の enabled 属性の値を false に設定することによって、アプリケーションサーバーインスタンスを無効化します。
- 静止時間が終了し、さらにアプリケーションサーバーインスタンスによる要求の処理が完了できるだけの十分な待機時間をとった後で、loadbalancer.xml ファイルでそのアプリケーションサーバーインスタンスに対応するエントリを削除します。
アプリケーションサーバーインスタンスがクラスタから削除されると、そのインスタンスに割り当てられている要求は、ラウンドロビンアルゴリズムの一部としてロードバランサによってほかのインスタンスにルーティングされます。要求のルーティング先となるアプリケーションサーバーインスタンスが同じクラスタの一部であり、セッションが無効化されていない場合は、そのセッションはフェイルオーバーされます。それ以外の場合、要求のルーティング先となるアプリケーションサーバーインスタンスではこのような要求を未割り当て要求として扱います。
クラスタの削除クラスタをロードバランサから削除するには、次の手順に従います。
- (loadbalancer.xml ファイルで) 該当するweb-module 要素の enabled 属性の値を false に設定することによって、そのクラスタ内のアプリケーションサーバーインスタンスに配備されている各 Web アプリケーションを無効化します。
- (省略可能) すべての Web アプリケーションが静止した後、そのクラスタ内のすべてのアプリケーションサーバーインスタンスから Web アプリケーションの配備を個別に取り消します。クラスタ内のすべてのインスタンスから各アプリケーションの配備を取り消すには、cladmin コマンドを使用します。この操作の詳細は、「クラスタからの Web アプリケーションの配備取り消し」を参照してください。
- loadbalancer.xml ファイルから、クラスタのすべてのエントリ (クラスタ内のアプリケーションサーバーインスタンスおよび Web アプリケーションのエントリを含む) を削除します。
複数のロードバランサの使用1 組のクラスタには、より多くのアプリケーションサーバーインスタンスの追加によってスケーラビリティを向上し、同時に耐障害性を向上させるため、複数のロードバランサを使用することができます。
このとき、すべてのロードバランサの設定および loadbalancer.xml ファイルが同一である必要があります。loadbalancer.xml ファイルのマスターコピーを作成し、このマスターコピーをシステム内のすべてのロードバランサに配布するスクリプトを使用することをお勧めします。これにより、運用されるすべてのロードバランサに対して設定の変更を同時に適用できるようになります。この方法は、複数のクラスタ、インスタンス、およびアプリケーションを有効化または無効化するときに特に役立ちます。
通常、要求は 1 つのソース (ハードウェアロードバランサまたは DNS ベースの負荷分散メカニズム) を介してこれらのロードバランサに送信されます。
複数のロードバランサを使用すると、重複しない 2 つのクラスタセットを処理することもできます。たとえば、あるロードバランサで安全な (HTTPS) アプリケーションを処理し、別のロードバランサでその他のアプリケーションを処理することができます。このような場合、これらの各ロードバランサの loadbalancer.xml ファイルは異なる内容になります。
