クラスタ環境

「クラスタ」とは複数のノードにまたがって存在する、複数のサーバーインスタンスのグループのことであり、それらすべてのインスタンスで同一の構成が実行されます。クラスタ内のすべてのインスタンスが連携して動作することで、高い可用性、信頼性、およびスケーラビリティーが実現されます。

クラスタで負荷分散を使えば、フェイルオーバーとセッションレプリケーションによって、中断されることのないサービスとセッションデータの持続性が実現されます。

ハードウェアとソフトウェアの要件

この節で説明するユースケースでは、Web Server クラスタは次のエンティティーから構成されます。

クラスタを設定するには、同じバージョンのオペレーティングシステムとパッチがインストールされた 2 つ以上の同一ノードが必要となります。たとえば、Solaris® 9 SPARC® オペレーティングシステムを含むマシンを選択した場合、クラスタ内のほかのマシンにも Solaris 9 SPARC をインストールする必要があります。

サポートされているプラットフォームやパッチの要件については、『Sun Java System Web Server 7.0 Update 3 リリースノート』を参照してください。

次の図は、クラスタ環境を記述したものです。

図 4–2 クラスタ設定

この図では、ノードは非武装地帯 (DMZ) に構成されています。管理サーバーは、一般的なアクセスから制限/保護するために、ファイアウォールの背後にある武装地帯に構成されています。別のノードが逆プロキシサーバーとして構成されています。逆プロキシサーバーは、セキュリティーを強化する目的で DMZ の内側に存在しています。

Solaris のゾーン機能は、Solaris 10 オペレーティングシステム上でしかサポートされていません。

クラスタの設定

この節では、クラスタを設定し、逆プロキシを有効にして HTTP 要求の負荷分散をサポートする手順について説明します。

次のフローチャートは、クラスタの設定手順を示したものです。

図 4–3 クラスタの設定を示すフローチャート

1. ノードの 1 つに、クラスタ内の管理サーバーとして機能する Web Server をインストールします。

2. ほかの 3 つのノードに Web Server をインストールします。Web Server を管理ノードとしてインストールするオプションを選択します。インストール時に、サーバーにノードを登録するオプションを選択します。

3. 管理サーバーが通信時に SSL ポートを使用していることを確認します。なぜなら、セキュリティー保護されたモードでしか、管理ノードをサーバーに登録できないからです。

4. 管理サーバーと管理ノードがインストールされているすべてのノードのシステム日時が、同一であることを確認します。サーバーに関連付けられる証明書は、管理サーバーがインストールされたノードのシステム日時に基づいて作成されます。管理ノードのシステム日時が管理サーバーの日時よりも遅れていると、管理サーバーの証明書がまだ有効になっていないため、登録が失敗します。必然的に、その証明書は、有効期限が切れたあとも有効であるとみなされる可能性があります。

5. install_dir/admin-server/bin/ ディレクトリから管理サーバーを起動します。

   install_dir/admin-server/bin>./startserv

6. 管理ノードから wadm コマンド行ツールを起動します。wadm コマンド行ツールは、install_dir/bin ディレクトリに格納されています。

   install_dir/bin>./wadm

7. 各管理ノードを管理サーバーに登録しますregister-node コマンドを使って各ノードをサーバーに登録します。

   例:

   ./wadm register-node -user=admin --host=abc.sfbay.sun.com --port=8989

   説明:

   abc.sfbay.sun.com

   ノードの登録先となる管理サーバーのホスト名です。

   port

   管理サーバーの SSL ポート番号です。

8. 管理パスワードの入力を求められます。管理サーバーの管理パスワードを入力します。

   管理サーバーが管理ノードのサーバー証明書を信頼し、管理ノードが管理サーバーから提示されたクライアント証明書を信頼することによって、管理サーバーの相互認証が実現されます。ある管理ノードを登録するときに、管理サーバーによってその管理ノードのサーバー証明書が生成され、続いてその証明書がその管理ノードにダウンロードおよびインストールされます。管理ノードには、サーバー証明書の発行者の情報もインストールされます。

   ---

   注 –

   登録は SSL 経由でしか行えません。

   ---

   ノードの登録方法については、『Sun Java System Web Server 7.0 Update 3 Installation and Migration Guide』の「Registering the Administration Node From the Command-Line」を参照してください。

9. install_dir/admin-server/bin/ ディレクトリの startserv コマンドを使って、すべての管理ノードを起動します。

10. 管理コンソールまたは CLI を使って、新しい構成を管理サーバー内に作成します。

    新しい構成の構成名、HTTP リスナーポート、サーバー名など、構成情報を入力します。

11. すべてのノード上で構成のインスタンスを作成します。

12. すべてのノード上でインスタンスを起動します。

    ---

    注 –

    Web Server では、クラスタを柔軟に拡張または縮小できるようになっています。クラスタに対するインスタンスの追加や削除は、任意のタイミングで行えます。

    ---

負荷分散のための逆プロキシの構成

Web Server 7.0 には、高度な組み込みロードバランサである逆プロキシが用意されています。逆プロキシは、サーバーファーム内の Web Server に対するゲートウェイになります。逆プロキシを構成すると、同じように構成された複数の Web サーバーに要求が転送されるようになります。

Web Server 7.0 で逆プロキシを有効にするには、次の手順を使用します。

1. 逆プロキシ構成用として使用するノードに、Web Server をインストールします。

2. 構成を作成します。例: rp。

3. 管理コンソールで「構成」>「仮想サーバー」>「コンテンツ処理」>「逆プロキシ」タブを選択します。「新規」ボタンをクリックします。

4. 逆プロキシの URI を入力するとともに、クラスタ内のすべてのマシンのサーバー URL をコンマで区切って入力します。

   サーバー URL の入力形式は、hostname: portnumber です。

5. 変更結果を保存します。

6. 変更済みの構成を配備することで、構成への変更内容を適用します。

7. この変更済みの構成のすべてのインスタンスを起動します。

これで、HTTP 要求を負荷分散するための逆プロキシの構成が完了しました。

クラスタ環境内で逆プロキシを構成するには、ワイルドカードサーバー証明書、または実際の元のサーバーホスト名に設定可能な代替サブジェクト名を発行します。サブジェクト名フィールドに元のサーバーのホスト名を指定するほかの方法では、クラスタのサイズが制限されるため、別のノードがクラスタに追加されるとクラスタが失敗する可能性があります。

ワイルドカードサーバー証明書は、管理インタフェースを使用して作成できます。サーバー証明書を作成したあとで、certutil を使用して base64 でエンコードされたバージョンの証明書を取得し、信頼される CA 証明書としてロードバランサ構成にインストールします。

次のコマンドを入力して、base64 でエンコードされた証明書 bash$./certutil -L -a -d instancedir/config を生成します。コマンドの出力をコピーし、証明書ウィザード内にペーストしてインストールします。

逆プロキシでのタイムアウトパラメータの構成

逆プロキシでタイムアウトパラメータを構成する

1. 管理コンソールにログインします。

2. リストから構成を選択します。

3. 「仮想サーバーを編集」ボタンをクリックします。

4. 「コンテンツ処理」タブをクリックします。

5. 「逆プロキシ」サブタブをクリックします。

6. 逆プロキシのリストで URI をクリックします。

   新しいウィンドウが表示されます。

7. 「HTTP クライアント設定」リンクをクリックします。

8. 「アイドルタイムアウト」パラメータを編集できます。デフォルト値は 300 です。

バックエンドインスタンスの監視

この節では、バックエンドインスタンスの状態確認について、詳しく説明します。

Web Server 7.0 の route_offline_thread は、バックエンドインスタンスの状態確認を実行します。これは、OPTIONS HTTP 要求を送信して、有効なバックエンドインスタンスを検出します。サーバーが応答した場合、バックエンドインスタンスが有効であると確認されたことになります。初期フェーズのあとで、スレッドによりオフラインのバックエンドインスタンスの状態が 60 秒ごとに確認されます (間隔は設定できない)。ここで、route_offline_thread によりオフラインインスタンスへの接続が試みられます。接続が成功すると、OPTIONS HTTP 要求が送信されます。インスタンスが応答する場合、ハングアップからの復旧後、 route_offline_thread はただちにそれをオンラインと識別します。このため、スレッドがシステムおよびバックエンドインスタンスのパフォーマンスに影響を及ぼすことはありません。

バックエンドインスタンスがオンラインと識別されたあとで停止またはクラッシュした場合、route_offline_thread が追跡することはできなくなります。要求を処理するために、この種のインスタンスが Web Server 逆プロキシパラメータにより選択された場合、読み取りエラーまたは送信エラーが発生し、インスタンスへの接続が壊れていることが示されます。

obj.conf ファイル内の http-client-config ObjectType 関数を使用して、応答タイムアウト値を定義できます。

ObjectType fn="http-client-config" timeout="400"

デフォルトのタイムアウト値は 300 秒です。

応答タイムアウト値を定義したあとで、接続のハングアップ時間が 400 秒を超え、オフラインと識別されると、逆プロキシパラメータによりバックエンドインスタンスへの接続が閉じられます。

接続の確立を試みるバックエンドインスタンスがハングアップまたはビジー状態にある場合、逆プロキシパラメータは接続応答を最大 5 秒間待機してから、そのインスタンスをオフラインとして識別します。

グラフィカルインタフェースでの逆プロキシとしての Web Server の使用

グラフィカルインタフェースで逆プロキシを構成する

1. 管理コンソールにログインします。

2. リストから構成を選択します。

3. 「仮想サーバーを編集」ボタンをクリックします。

4. 「コンテンツ処理」タブをクリックします。

5. 「逆プロキシ」サブタブをクリックします。

6. 「新規」ボタンをクリックします。

   新しいウィンドウが表示されます。

7. すべての要求を逆プロキシに設定する場合は、URI に「/」を入力します。それ以外の場合は、逆プロキシに設定する URI を入力します。

8. 逆プロキシに設定するサーバーの URL を入力します。

   例: http://<content server-hostname>:port

9. 「了解」ボタンをクリックします。

10. 画面右上の「配備保留中」リンクをクリックします。

11. 「配備」ボタンをクリックします。

    配備が成功したことを示すメッセージが表示されます。

12. 「構成」タブをクリックします。

13. インスタンスを起動します。

    逆プロキシとして構成した URI にアクセスします。

逆プロキシのカスタマイズ

条件付き要求処理を構成するには、仮想サーバー固有の obj.conf ファイルを手動で編集する必要があります。

たとえば、すべての .jsp、 .php 要求に対して逆プロキシを構成する場合です。次のテキストを obj.conf ファイルに含める必要があります。

<If $uri =~ '.jsp$' or $uri =~ '.php$'> 
NameTrans fn="map" from="/" to="http:/" name="custom_reverse_proxy"
</If>

上記のテキストをオブジェクト名 default の下に挿入します。obj.conf ファイルの最後に、次のテキストを追加します。

<Object name ="custom_reverse_proxy">
Route fn="set-origin-server" server="http://<hostname>:<port>"
</Object>

<Object name ppath="http:*"
Service fn="proxy-retrieve" method="*"
</Object>

CLI モードでの逆プロキシとしての Web Server の使用

次の手順に従って、CLI モードで逆プロキシを構成します。たとえば、構成 config1 を作成し、さらにインスタンス rp を逆プロキシとして作成する場合を例として考えます。

1. 管理サーバーを起動します。

   $ <install-dir>/admin-server/bin/startserv

2. CLI シェルを起動します。

   <install-dir> /admin-server/bin/wadm -user <username>

   これで、wadm シェルを表示できます。

3. config1 を作成します。

   wadm>create-config --http-port 8080 --server-name config1 --server-user root config1

4. config1 構成のインスタンスを作成します。

   wadm>create-instance --config config1 <host-name>

5. 作成した構成上で Web アプリケーションを追加します。

   wadm>add-webapp --config config1 -vs config1 --uri/test <warfile>

6. Web アプリケーションを配備します。

   wadm> deploy-config --user=admin --password-file=admin.pwd --host=serverhost --port=8989 config1

7. rp 構成を作成します。

   wadm>create-config --http-port 8081 --server-name rp --server-user root rp

   次のコマンドを使用して、逆プロキシに対して rp 構成を有効にします。

   wadm>create-reverse-proxy --config rp --vs rp --uri-prefix/--server http://<host-name>:8080

8. rp 構成のインスタンスを作成します。

   wadm>create-instance --config rp <host-name>

9. インスタンスを起動します。

   wadm>start-instance --config config1 <host-name>

   wadm>start-instance --config rp <hostname>

これで、config1 内に配備した Web アプリケーションを rp インスタンス経由で表示できます。

http://<rp instance hostname>:8081/test