第 1 章 Sun Java System Application Server 7, Enterprise Edition の概要

Sun Java^TM System Application Server 7, Enterprise Edition は、アプリケーションサービスや Web サービスを広く配備する場合に適した高性能な Java^TM 2 Platform, Enterprise Edition (J2EE^TM) プラットフォームを提供します。Sun ONE Application Server 7 は、検証済みの HTTP サーバーインフラストラクチャ、Java Message Service (JMS) をはじめとする業界標準コンポーネントと、Java Web Services Developer Pack ソフトウェアに付属の J2EE バージョン 1.3、Java 2 Platform, Standard Edition バージョン 1.4、Java API for XML (JAX) による最新の J2EE および Web サービス仕様を基盤としたモジュールアーキテクチャを採用しています。

さらに、Sun Java System Application Server は、HTTP/S 要求および RMI/IIOP 要求のロードバランスと、リモート EJB 参照および HTTP セッションの高可用性をもたらします。機能の詳細については、『Sun Java System Application Server 製品の概要』を参照してください。

Application Server インスタンスについて

Application Server インスタンスは、Application Server の配備の基本となります。各インスタンスには、それぞれに専用のディレクトリ構造、設定、配備アプリケーションがあります。各サーバーインスタンスには、J2EE プラットフォームの Web および EJB コンテナも組み込まれています。Sun Java System Application Server には、検証済みの高性能な HTTP サーバーも組み込まれています。オブジェクトリクエストブローカ (Object Request Broker (ORB)) モジュールにより、RMI-IIOP を使って EJB を呼び出すことができます。

アプリケーションは、バックエンドシステムにアクセスするため、J2EE コネクタアーキテクチャに対応したリソースアダプタ、サードパーティのリソースアダプタ、組み込みの JMS プロバイダまたはサードパーティのプロバイダに加えて、一般的なサードパーティ JDBC ドライバを組み合わせて使用します。分散トランザクションの範囲内であれば、バックエンドシステムへのアクセスは、すべて Java で記述された内蔵のトランザクションマネージャを使って管理できます。

管理サーバーは、コア管理アプリケーションと SNMP エージェントを実行する、特殊なサーバーインスタンスです。リモート管理は、すべて管理サーバー経由で行われます。管理サーバーには、コマンド行や Web ブラウザベースの管理クライアントから HTTP を使用するか、セキュリティ保護された HTTPS を使って安全に直接アクセスします。

Web サーバーのプラグイン (ロードバランサプラグインなど) を使用すると、1 つ以上のファイアウォール層によって保護された非武装地帯 (DMZ) に置かれた 1 つまたは複数の Web サーバーの背後に、Application Server を配備できます。フロントエンドの Web サーバー層は、このプラグインを使って、インターネットから受信した HTTP/HTTPS トラフィックをバックエンドのアプリケーションサーバー層にある Application Server (複数可) に送信します。

さまざまなクライアントアプリケーションが、Application Server に配備されたビジネスサービスにアクセスできます。Web サービスクライアントとブラウザベースのクライアントは、HTTP または HTTPS を使って、Web サービス、サーバー側の終点、および J2EE Web アプリケーションにアクセスできます。

図 1-1 に、Application Server インスタンスの詳細を示します。Application Server インスタンスは、「Enterprise Edition 機能について」に記載されているクラスタリング、ロードバランス、およびセッション持続性機能の基本的要素です。

管理ドメインについて

管理ドメインを使用すると、同じインストールイメージを再使用する、複数の完全に別個の Application Server の実行時設定を定義できます。それぞれの管理ドメインには管理サーバーがあり、この管理サーバーが 1 つまたは複数の Application Server インスタンスを制御します。図 1-1 では、単一の管理ドメインを示しています。

このチュートリアルでは、製品のインストール時に設定される単一の管理ドメインと、クラスタ内の複数のサーバーインスタンスを扱います。

Enterprise Edition 機能について

Sun Java System Application Server Enterprise Edition 7 2004Q2 は、高度なクラスタリングおよびフェイルオーバーテクノロジを備えています。これらの機能によって、拡張性と可用性の高い J2EE アプリケーションを実行できます。

このマニュアルには、次の節で説明する Enterprise Edition 機能の使用方法が記載されています。

クラスタリング

クラスタは、1 つの論理エンティティとして機能する、Application Server インスタンスの集まりです。クラスタ内のそれぞれの Application Server インスタンスには、同じ設定と同じアプリケーションが備えられています。Application Server クラスタの詳細については、第 2 章「クラスタリングのシナリオ」を参照してください。

クラスタ内の Application Server インスタンスは、異なるマシン上でも同じマシン上でも実行することができます。つまり、複数のマシン上にある Application Server インスタンスを、1 つの論理クラスタにグループ化できます。このマニュアルのデフォルトの設定は、同じマシン上の 2 つのインスタンス用に設定されています。

クラスタリングの詳細については、『Sun Java System Application Server Administration Guide』を参照してください。

Sun Java System Application Server のクラスタを使用すると、次の機能を実現できます。

高可用性

Sun Java System Application Server は、クラスタ内の Application Server インスタンスをフェイルオーバーによって保護することで、高可用性を実現します。ある Application Server インスタンスが停止しても、別の Application Server インスタンスが、その利用できなくなったサーバーに割り当てられていたセッションを引き継ぎます。

セッション情報は、Sun Java System Application Server Enterprise Edition に付属する高可用性データベース (HADB) に格納されます。HADB の詳細については、「高可用性データベース」を参照してください。

Sun Java System Application Server は、次の場合でのフェイルオーバーをサポートしています。

HTTP/S セッション

ロードバランサプラグインは、セッションを処理していた元の Application Server インスタンスが利用できなくなると、HTTP/S 接続と関連のセッション情報を、別の Application Server インスタンスへ引き継ぎます。高可用性を有効にしている場合、セッション情報は HADB に格納されます。

ロードバランサプラグインは、次の 2 つの方法で HTTP/S セッションを追跡します。

クラスタ設定は、loadbalancer.xml ファイルを作成する必要があります。このファイルは、ロードバランサプラグインとともにインストールされる loadbalancer.xml.example ファイルに基づいて、手動で作成する必要があります。デフォルトで、この設定例のファイルは、Web サーバーの config ディレクトリに格納されています。

HTTP セッション内の EJB 参照

HTTP セッションに格納された、java.io.Serializable インタフェースを実装する EJB 参照と J2EE オブジェクトのフェイルオーバーがサポートされます。詳細については、『Sun Java System Application Server Administration Guide』の「Configuring Session Persistence」を参照してください。

RMI/IIOP による、EJB および JNDI 初期コンテキストのリモート参照

RMI/IIOP アプリケーションの高可用性を有効にするには、IIOP クラスタに指定の IIOP エンドポイントを組み込むように設定する必要があります。IIOP クラスタに組み込まれた ORB リスナーは、IIOP エンドポイントと呼ばれます。IIOP エンドポイントは、管理コンソールまたは CLI を使用して設定します。

RMI/IIOP パスを介して要求を受信すると、Application Server は、クラスタ内の利用可能ないずれかの IIOP エンドポイントをランダムに、プライマリエンドポイントとして選択します。クラスタ内の他の IIOP エンドポイントは、代替エンドポイントとして指定されます。

プライマリエンドポイントが利用できなくなると、この接続に関連したリモート参照は、いずれかの代替エンドポイントに引き継がれます。

IIOP クラスタは、管理コンソールまたは CLI のどちらかを使用して設定できます。変更は、Application Server 設定ファイル、server.xml に登録されます。詳細については、「RMI/IIOP クラスタリングのシナリオ」を参照してください。

JMS 接続

Sun Java System Message Queue Enterprise Edition 3.5 SP1 では、JMS 接続によるフェイルオーバーに対応しています。

スケーラビリティ

Sun Java System Application Server では、Application Server インスタンスをクラスタに追加して、システム容量を拡張できるので、J2EE アプリケーションに高度なスケーラビリティがもたらされます。サービスを中断せずに、Application Server インスタンスをクラスタに追加できます。

HTTP および RMI/IIOP ロードバランスシステムにより、要求は、クラスタ内の Application Server インスタンスに適切に配分されます。

ロードバランス

ロードバランスの目的は、複数の Sun Java System Application Server インスタンスにかかる作業負荷を均等に分散させることです。ロードバランスは、HTTP/S と RMI/IIOP パスを介したアプリケーション要求に対して設定できます。

HTTP のロードバランス

Sun Java System Application Server は、着信 HTTP および HTTPS 要求を、クラスタ内に設定した Application Server インスタンスに分散させます。ロードバランスは、サポートする Web サーバーにインストールされた、付属のロードバランサプラグインによって行われます。

新しい HTTP 要求がロードバランサプラグインに送られると、その要求は、単純なラウンドロビンスキームに基づいて Application Server インスタンスに転送されます。同一のコンテキストルートを持つこのあとの要求は、Cookie または URL の明示的な書き換えに基づいて、最初に要求を処理した Application Server インスタンスに割り当てられます。


注	IIOP および HTTP クラスタは、同じ Application Server インスタンスから構成されている必要があります。

HTTP のロードバランスおよびフェイルオーバーを設定するには、Application Server クラスタをロードバランサプラグインに対して指定する必要があります。設定の変更は、loadbalancer.xml ファイルで行う必要があります。ロードバランサ設定ファイルの詳細については、「loadbalancer.xml ファイルの作成」を参照してください。

Sun Java System Application Server に付属のロードバランサプラグインを使用するか、サードパーティ製ハードウェアおよびソフトウェアのロードバランサを使用することができます。このマニュアルでは、付属の HTTP ロードバランサプラグインについて説明します。ロードバランスの詳細については、『Sun Java System Application Server Administration Guide』を参照してください。

RMI/IIOP のロードバランス

Sun Java System Application Server, Enterprise Edition 7 では、JNDI 初期コンテキストに基づいて、RMI/IIOP パスでのリモート EJB 参照のロードバランスを行います。新しい JNDI 初期コンテキストが開始されるたびに、新しいターゲット Application Server インスタンスが、設定された IIOP クラスタから選択されます。

RMI/IIOP ベースの要求のロードバランスを有効にするには、RMI/IIOP クライアントアプリケーションで、ロードバランスを有効にするように、若干のコード変更を行う必要があります。付属の ORB には、ロードバランスに必要な機能が備わっています。

次の RMI/IIOP クライアントについて、ロードバランスがサポートされています。

RMI/IIOP クライアントでロードバランスを有効にする設定は、クライアントの種類によって異なります。設定例については、「RMI/IIOP クラスタリングのシナリオ」を参照してください。さまざまな RMI/IIOP クライアントの設定に関する詳細については、『Sun Java System Application Server Developer's Guide to Clients』を参照してください。

セッション持続性

セッション持続性の機能によって、Sun Java System Application Server のインスタンスやマシンそのものに不具合が発生した場合でも、HTTP/S または EJB セッションは、別のサーバーインスタンスに引き継がれることが保証されます。Sun Java System Application Sever は次の持続性をサポートしています。

Sun Java System Application Server に付属の高可用性データベース (HADB) は、持続性ストアとして機能します。高可用性データベースの詳細については、「高可用性データベース」を参照してください。

セッション持続性のタイプについて

Sun Java System Application Server は、ha、file、および memory という、3 つのタイプの持続性をサポートしています。

管理インタフェースを使用して、HADB 持続性ストアを選択します。次の手順に従って、HADB を持続性ストアに設定します。

サーバーインスタンスの下の「可用性サービス」コンポーネントを開きます。

「可用性サービス」ページに移動します。

「インスタンスレベルの可用性」ボックスをチェックします。

「保存」ボタンをクリックします。

「持続性ストアプロパティ」の下の「プロパティ」をクリックします。

「名前」フィールドに、store-pool-jndi-name と入力します。

「値」フィールドに、HADB JDBC リソースの JNDI 名を入力します。仮のデフォルト名は、jdbc/hastore です。

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

サーバーインスタンスページに移動します。

変更を適用し、サーバーを再起動します。

HADB を設定すると、server.xml ファイルでの要素階層は次のようになります。

...

<availability-service availability-enabled="true">

<persistence-store>

</persistence-store>

</availability-service>

...

</server>

HADB 持続性ストアの設定方法の詳細については、『Administration Guide』を参照してください。

file 持続性タイプでは、セッション情報を定期的にファイルに格納しますが、インスタンスが利用できなくなったときにデータが失われることがあります。file 持続性タイプは、フェイルオーバー機能を必要とする本稼働環境には対応していませんが、アプリケーションのテストのために開発環境で使われることがあります。

server.xml ファイルの session-store 属性は、SFSB 状態の持続性にローカルファイルシステムが使用されている場合に、SFSB 状態が格納されている場所を指定します。次に例を示します。

このマニュアルの例では、ha セッション持続性のみ説明しています。その他のタイプのセッション持続性の設定と使用の詳細については、『Sun Java System Application Server Administration Guide』を参照してください。

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

Sun Java System Application Server をインストールして、clsetup コマンドを実行すると、セッション持続性情報がデフォルト値に設定されます。ただし、パフォーマンス、信頼性、高可用性の特定のニーズに合うように、デフォルト値を変更することができます。これらのオプションについては、次の 2 つの項目で説明します。

持続性適用範囲の設定

HADB を持続性ストアとして使用する場合、持続性適用範囲を指定して、格納するセッション状態の容量を設定する必要があります。たとえば、データを保存するたびにセッション全体を格納することも、セッションが変更された場合にかぎりセッションを格納することもできます。また、セッションの変更された属性だけを格納するように、持続性を設定することもできます。

modified-session セッションは変更されたときにのみ格納されます。

session セッション状態が HADB に格納されるごとに、セッション全体が格納されます。

modified-attribute セッションの変更された属性だけが格納されます。

持続性頻度の設定

HADB を使用してセッション状態を格納する場合、HADB データベースにセッション状態を格納する頻度を設定できます。たとえば、それぞれの Web 要求のあとにセッションを格納するように選択して、更新されたセッション状態の高可用性と信頼性を提供したり、指定した時間間隔のあとにセッションを格納するように選択して、パフォーマンスを向上させることができます。

web-method の持続性頻度を使用すると、Web 要求が終了するごとにセッションを格納します。

time-based の持続性頻度を使用すると、server.xml ファイル (インスタンスレベル設定の場合) または sun-web.xml ファイル (アプリケーションレベル設定の場合) の manager-properties 要素の reapIntervalSeconds プロパティで定義した間隔で、セッション状態が格納されます。

セッション持続性のさまざまな設定オプションの詳細については、『Sun Java System Application Server Administration Guide』の「Configuring Session Persistence」を参照してください。

シングルサインオンセッション情報について

単一の Application Server インスタンスでは、Web アプリケーションで 1 度認証されると、同じインスタンス上で実行中のその他の Web アプリケーションに対して再度認証は要求しません。これを、シングルサインオンといいます。


注	ha 持続性タイプについてのみ、持続性頻度を選択できます。

この機能で、セッションがクラスタ内の別のインスタンスに引き継いだときでも動作を続けるためには、シングルサインオン情報が HADB に継続して置かれている必要があります。この持続性を使用できるのは、Application Server インスタンスの高可用性を有効にした場合であり、次のプロパティを server.xml の virtual-server 要素に追加する必要があります。

高可用性は、clsetup コマンドを実行すると、自動的に設定されます。

SFSB チェックポイントについて

SFSB の状態は、ライフサイクルにおける既定の時点で、持続性ストアに格納されます。

SFSB チェックポイントは、次の 5 つの異なるレベルで有効にできます。

SFSB チェックポイントを所定のレベルで有効にするには、それより高いレベルでも有効にする必要があります。たとえば、SFSB チェックポイントをアプリケーションレベルで有効にするには、サーバーインスタンスレベルと EJB コンテナレベルでも有効にする必要があります。

SFSB チェックポイントの設定方法の詳細については、『Sun Java System Application Server 7 Developer's Guide to Enterprise JavaBeans Technology』を参照してください。

高可用性データベース

高可用性データベース (HADB) は、HTTP と SFSB セッション情報の格納に使用されます。高可用性は、ハードウェアやソフトウェアの障害によって予定外の停止があっても、引き続きシステムを使用できることを意味します。HADB は JDBC 準拠のデータベースであり、「Always-On (常時配信)」テクノロジに基づいており、99.999% を超えるデータの可用性を実現できます。このため、高い負荷が継続するアプリケーションサーバーの商用環境において、すべての種類のセッション状態を持続的に処理するための、理想的なプラットフォームになります。

HADB は、データの分割とレプリケーションによって、このようなデータの可用性を提供します。このデータベース内のすべてのテーブルは、フラグメントというほぼ同じサイズのサブセットを作成するように区切られています。この分割のプロセスは、データベースのノード間のデータを分割して均等に分散させる、ハッシュ機能に基づいています。それぞれのフラグメントは、データベースのミラーノードに、2 回格納されます。これにより、データの耐障害性と高速回復が保証されます。また、ノードが使用不能になるか、あるいはシャットダウンした場合は、そのノードが再度アクティブになるまで、予備のノードが代行します。

HADB では、分割されているが確実に統合されている持続性ストレージ層の中で、すべての状態情報の格納や検索が可能だからです。HADB のセットアップと設定の詳細については、『Sun Java System Application Server インストールガイド』の「HADB の設定準備」を参照してください。

Application Server の設定と管理に使用するツール

Sun Java System Application Server には、設定と管理に使用できる以下のツールが用意されています。これらのツールを使って、サーバーの起動と停止や、さまざまなその他の機能を実行できます。特定の設定作業を行うために使用する一部のツールについては、その使用方法がチュートリアルに記載されています。

asadmin の詳細については、『Sun Java System Application Server Administration Guide』の「Appendix A, Using the Command Line Interface」を参照してください。

cladmin コマンド : cladmin コマンドにより、クラスタ内のすべての Application Server インスタンスで、特定の asadmin コマンドが同時に実行されます。cladmin コマンドを使用すれば、クラスタ内のすべてのインスタンスが同じように設定されます。このため、可能なかぎり、asadmin ではなく cladmin を使用してください。cladmin はすべての asadmin コマンドをサポートしているわけではありません。

cladmin の詳細については、『Sun Java System Application Server Administration Guide』の「Appendix F, Using the cladmin Script for Administration」を参照してください。

管理コンソールの詳細については、『Sun Java System Application Server Administration Guide』の「Part 1, Server Basics and Administering Global Settings」を参照してください。

clsetup コマンド: clsetup コマンドにより、HADB データベースの初期設定など、クラスタを簡単に設定することができます。clsetup コマンドの詳細については、『Sun Java System Application Server インストールガイド』を参照してください。さらに、clsetup で提供されるマニュアルページも参照してください。



注	いくつかのサーバー設定とその対応するインタフェースは、現在も開発が進んでいます。不確定なインタフェースは、次期製品リリースでより安全で安定したものに置き換えられる可能性があります。ほとんどのサーバー設定および管理インタフェースがそのまま残るか互換性を持ったまま変更されますが、いくつかの点で互換性が保たれない場合もあります。互換性のない機能の変更内容については、製品の以降のリリースで変更が発生した場合に、ドキュメントに明確に記述することを予定しています。

前へ目次索引次へ
Sun Java System Application Server Enterprise Edition 7 2004Q2 入門ガイド