test

Sun Java System Web Server 7.0 管理ガイド

第 4 章 配備シナリオ

この章では、Sun Java System Web Server 7.0 を単一ノード上およびクラスタ環境に配備する方法について説明します。この章の内容は次のとおりです。

配備アーキテクチャー

この節では、単一ノード配備アーキテクチャーについて説明します。

次の図は、単一ノード配備設定の Web Server を表現したものです。

単一ノード配備設定の Web Server。

この図の Web Server 配備設定は、次の各要素から構成されています。

配備の概要

単一ノードへの Web Server の配備は、次の目的の場合に検討できます。

次のフローチャートは、1 つのノード上に Web Server を配備する方法を大まかに表現したものです。

図 4–1 単一ノードへの Web Server の配備を表現したフローチャート

1 つのノード上に Web Server を配備する手順を示したフローチャート。

配備手順については、次の節で説明します。

配備前の要件

単一ノード上に Web Server を配備するには、次のタスクを実行してシステムの準備を整えます。

  1. 1 つのノード上に Web Server をインストールします。

    Web Server のインストール時に高速インストールオプションを選択した場合、次のデフォルトエンティティーが作成されます。

    • 管理サーバー。

    • HTTP リスナーと仮想サーバーを 1 つずつ含むデフォルト構成。構成と仮想サーバーの名前はホスト名と同じになります。

    • デフォルト構成のインスタンス。

    Web Server のインストール方法については、『Sun Java System Web Server 7.0 Installation and Migration Guide』の第 2 章「Installing the Web Server」を参照してください。

    サポートされているプラットフォームやシステム要件については、『Sun Java System Web Server 7.0 リリースノート (UNIX 版)』の「対応プラットフォーム」を参照してください。

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

    指定された SSL ポート上で管理サーバーの実行が開始されます。

Web Server の配備

1 つのノード上に Web Server を配備するには、次の手順を使用します。

  1. デフォルト構成を使用することも、新しい構成を作成することもできます。

    新しい構成を作成する場合は、構成の一意名を指定します。新しい構成は、仮想サーバーとデフォルト HTTP リスナーを 1 つずつ作成します。

    注 –

    管理コンソールを使って構成を作成する場合、ウィザードによって新しいインスタンスを作成するためのプロンプトが表示されます。CLI を使用する場合、create-instance コマンドを使って構成のインスタンスを明示的に作成する必要があります。

    <install_dir>/admin-server/ ディレクトリの下にある config-store ディレクトリ内に、すべての構成が格納されます。

    注意 – 注意 –

    config-store ディレクトリの下のファイルは一切編集しないでください。このディレクトリの下のファイルは、Sun Java System Web Server によって内部用として作成されます。

  2. 変更済みの構成を配備します。

クラスタ環境

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

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

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

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

1) 4 つのインスタンス (4 つの同一ノード上で稼働) 

2) 管理サーバー 

3) HTTP 要求を負荷分散するための逆プロキシ 

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

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

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

図 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 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 要求を負荷分散するための逆プロキシの構成が完了しました。

セッションレプリケーション

セッションレプリケーションとは、あるセッション内に格納されたデータを異なるインスタンス間でレプリケートするために使用される機構のことです。ただし、レプリケート対象インスタンスは、同じクラスタの一部になっている必要があります。クラスタ環境でセッションレプリケーションが有効になると、セッションデータの全体がレプリケート対象インスタンスにコピーされます。ただし、セッションレプリケーションの処理では、セッション内の直列化可能でない属性やインスタンスに固有のあらゆるデータはコピーされません。

セッションレプリケーションと負荷分散を組み合わせると、Web アプリケーションのフェイルオーバー機能を効率的に実現できます。

セッションレプリケーションとフェイルオーバーの動作

この節では、セッションレプリケーションの動作について詳しく説明します。

Web Server は Web 要求の終了時に、サーバー構成ファイル server.xml 内に格納されたセッションレプリケーション構成に基づいてセッションデータをコピーする必要があるかどうかを判定します。

ここで、4 つのインスタンスが 1 つのクラスタを形成しており、管理サーバー上でセッションレプリケーションが有効になっている、というユースケースを考えます。

4 つのインスタンス (A、B、C、および D) が 4 つのノード上で稼働している Web Server クラスタにおけるセッションレプリケーションの手順は、次のとおりです。

Web Server クラスタ環境におけるフェイルオーバーの手順は、次のとおりです。

Web Server 7.0 のセッションレプリケーションでサポートされていない機能は、次のとおりです。

セッションレプリケーションの有効化

クラスタのセッションレプリケーションの有効化は、管理コンソール、CLI のいずれかを使って行えます。セッションレプリケーションを有効化する前に、ブラウザの Cookie が有効になっていることを確認してください。

server.xml ファイルには、セッションレプリケーションに関する情報が含まれています。セッションレプリケーションが有効化されたサンプル server.xml ファイルを、次に示します。

<cluster>
		<local-host>hostA</local-host>
			<instance>
         <host>hostB</host>
      </instance>
      <instance>
          <host>hostC</host>
      </instance>
       <instance>
          <host>hostD</host>
      </instance>
      <instance>
           <host>hostA</host>
    <session-replication/>
</cluster>

次の各要素のデフォルト値を使用する場合、それらの要素のエントリは server.xml 構成ファイル内に含まれません。

Port number (デフォルトは 1099)

Protocol (デフォルトは jrmp)

Encrypted (デフォルトは false)

Getattribute Triggers Replication (デフォルトは true)

Replica Discovery MaxHopss (デフォルトは –1)

Startup Discovery Timeout (デフォルトは ?

) 

Cookie Name (デフォルトは CLUSTERSESSIONLOCATOR)

これらのセッションレプリケーションプロパティーの詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』を参照してください。

セッションレプリケーションのための Web アプリケーションの構成

サーバーがセッションをレプリケートできるようにするには、Web アプリケーションでもセッションレプリケーションを有効にする必要があります。

  1. Web アプリケーションのセッションレプリケーションを有効にするには、<web-application>/WEB-INF ディレクトリに格納された sun-web.xml 構成ファイルを変更します。

    sun-web.xml で次の変更を行う必要があります。

    要素 <session-manager/> を <session-manager persistence-type="replicated"> に変更します。

    セッションレプリケーションが有効化されたサンプル sun-web.xml ファイルを、次に示します。

    <sun-web-app>
		<session-config>
     <session-manager persistence-type="replicated">
     </session-manager>
  </session-config>
</sun-web-app>

  2. sun-web.xml ファイルを変更したあと、Web アプリケーションをビルドし直すかアプリケーションの JAR ファイルを作成し直すことで、Web アプリケーションアーカイブ (WAR ファイル) を作成します。

  3. すべてのインスタンスを再起動することで、その Web アプリケーションがすべてのインスタンスで利用可能になるようにします。

  4. Web アプリケーションには、クラスタ内のすべてのインスタンスからアクセスできます。Web アプリケーションにアクセスするには、ブラウザで次のように入力します。

    http://webserver-name/webapplication-name/

    注 –

    すべてのノードからアクセス可能なディレクトリが、配備用のアプリケーションを格納するための最良の方法です。ただし、このディレクトリには、管理サーバーからアクセスできる必要はありません。Web アプリケーションのサイズが 1M バイトを超える場合には、ディレクトリベースの配備を行うことをお勧めします。

    検索コレクションを作成する場合、すべてのノードからアクセス可能な共通ディレクトリ内に検索コレクションが存在していることを確認してください。

クラスタの監視

管理サーバーは、クラスタ内のすべてのインスタンスを監視できます。Web Server の監視機能は、実行時のコンポーネントやプロセスの状態に関する情報を提供します。その用途には次のものが考えられます。

 

Solaris ゾーン

Solaris ゾーンは、Solaris 10 のアプリケーションおよびリソース管理機能です。ゾーン環境は通常、プロセス管理、メモリー、ネットワーク構成ファイル、ファイルシステム、パッケージレジストリ、ユーザーアカウント、共有ライブラリなどのリソースから構成されますが、場合によってはインストールされたアプリケーションも含みます。ゾーンは、1 つの Solaris インスタンス内に仮想化されたオペレーティングシステム環境を作成する手段を提供します。このため、システム上のほかのアクティビティーから遮断して 1 つ以上のプロセスを実行することが可能となります。ゾーンは、物理デバイスパス、ネットワークインタフェース名、ネットワークルーティングテーブルなど、アプリケーションの配備先マシンの物理属性からアプリケーションを分離するための抽象層も提供します。この遮断により、ユーザー ID などの資格情報が何であれ、あるゾーン内で実行されているプロセスが、ほかのゾーン内で実行されているプロセスを監視したり影響を与えたりできなくなります。

ゾーンは、システムの残りの部分に影響を与えたりそうした部分と相互作用することなしに 1 つ以上のアプリケーションを実行することのできる「サンドボックス」です。

Solaris ゾーンの詳細については、『Solaris のシステム管理 (Solaris コンテナ: 資源管理と Solaris ゾーン)』(http://docs.sun.com/app/docs/doc/819-0385) を参照してください。