Application Server は、インストール時に server という名前のアプリケーションサーバーインスタンスを作成します。必要に応じて、サーバーインスタンスを削除して、異なる名前で新しいインスタンスを作成できます。
各 Application Server インスタンスには、固有の J2EE 設定、J2EE リソース、アプリケーションの配備領域、およびサーバー設定があります。1 つのアプリケーションサーバーインスタンスを変更しても、ほかのアプリケーションサーバーインスタンスへは影響しません。1 つの管理ドメイン内に多数のアプリケーションサーバーインスタンスを保有できます。
多くのユーザーに対して、1 つのアプリケーションサーバーインスタンスが、そのニーズを満たします。ただし、環境によっては、1 つ以上の追加のアプリケーションサーバーインスタンスを追加して作成する場合があります。たとえば、開発環境内で異なるアプリケーションサーバーインスタンスを使用して、異なる Application Server 設定でテストしたり、異なるアプリケーション配備を比較およびテストできます。アプリケーションサーバーインスタンスを簡単に追加または削除できるので、それを利用して、一時的な「サンドボックス」領域を作成して、開発中に実験できます。
さらに、各アプリケーションサーバーインスタンスに対して、仮想サーバーを作成することもできます。単一のインストールされているアプリケーションサーバーインスタンス内で、企業または個人のドメイン名、IP アドレス、いくつかの管理機能を提供できます。ユーザーにとっては、ハードウェアを持つことも、サーバーの基本的な保守を行うこともなく、自分の Web サーバーを所有しているのとほぼ同じです。このような仮想サーバーは、複数のアプリケーションサーバーインスタンスにまたがりません。仮想サーバーの詳細については、「JVM の一般設定を行う」を参照してください。
実践配備においては、複数のアプリケーションサーバーインスタンスの代わりに仮想サーバーをさまざまな用途に応じて使用できます。ただし、仮想サーバーがニーズを満たさない場合、複数のアプリケーションサーバーインスタンスを使用することも可能です。
Application Server インスタンスは、自動的には起動しません。一度インスタンスを起動すると、停止するまで、そのインスタンスは機能します。アプリケーションサーバーインスタンスを停止すると、そのアプリケーションサーバーインスタンスは新しい接続を受け付けなくなり、未完了の接続がすべて完了するまで待機します。マシンがクラッシュしたり、オフラインになったりすると、サーバーは終了して、処理中だった要求が失われる可能性があります。
アプリケーションサーバーインスタンスは、アプリケーション開発の基礎を形成します。各インスタンスは 1 つのドメインに属し、それぞれに固有のディレクトリ構造、設定、および配備されたアプリケーションが含まれます。各サーバーインスタンスには、J2EE プラットフォームの Web および EJB コンテナも含まれます。新しいサーバーインスタンスには必ず、インスタンスが置かれるマシンを定義するノードエージェント名に対する参照が含まれる必要があります。
作成可能なサーバーインスタンスには、次の 3 つのタイプがあります。個々のサーバーインスタンスは 1 つのタイプのみに該当します。
スタンドアロンサーバーインスタンスの場合、設定はほかのサーバーインスタンスやクラスタとは共有されません。
共有サーバーインスタンスの場合、設定はほかのインスタンスやクラスタと共有されます。
クラスタ化されたサーバーインスタンスの場合、設定はクラスタ内のほかのインスタンスと共有されます。
クラスタは、アプリケーション、リソース、および設定情報の同じセットを共有するサーバーインスタンスの集まりです。1 つのサーバーインスタンスは 1 つのクラスタにのみ属することが可能です。特に注目すべき点は、クラスタを使用すると、複数のマシン間で負荷が分散されることによってロードバランスが容易になり、インスタンスレベルのフェイルオーバーによって高可用性を実現できることです。
図 1–2 は、アプリケーションサーバーインスタンスの詳細を示しています。アプリケーションサーバーインスタンスは、Application Server Enterprise Edition のクラスタリング、ロードバランス、セッションの持続性といった各機能の基本を構成するものです。
Application Server インスタンスは、自動的には起動しません。一度インスタンスを起動すると、停止するまで、そのインスタンスは機能します。アプリケーションサーバーインスタンスを停止すると、そのアプリケーションサーバーインスタンスは新しい接続を受け付けなくなり、未完了の接続がすべて完了するまで待機します。マシンがクラッシュしたり、オフラインになったりすると、サーバーは終了して、処理中だった要求が失われる可能性があります。
関連項目
「一般」タブから、次のタスクを実行できます。
「インスタンスを起動」をクリックして、インスタンスを起動します。
「インスタンスの停止」をクリックして、インスタンスを停止します。
「ログファイルを表示」をクリックして、サーバーのログビューアを開きます。
「ログファイルをローテーション」をクリックして、インスタンスのログファイルをローテーションします。
このアクションは、ログファイルのローテーションをスケジュールします。実際のローテーションは、次にログファイルがエントリに書き込まれたときに行われます。ローテーションは、デフォルトのサーバー (DAS) に対してはただちに実行されますが、ほかのスタンドアロンサーバーに対しては遅れます。
「JNDI ブラウズ」をクリックして、実行中のインスタンスの JNDI ツリーをブラウズします。
「トランザクションの回復」をクリックして、未完了のトランザクションを回復します。
さらに、次のタブを選択して、追加のタスクを実行できます。
「アプリケーション」タブ: 選択したアプリケーションを配備します。
「リソース」タブ: 選択したリソースを管理します。
「プロパティー」タブ: インスタンス固有のプロパティーを設定します。
「監視」タブ: JVM、サーバー、スレッドプール、HTTP サービス、トランザクションサービスの監視データを表示します。
「詳細」タブ: アプリケーションを配備するための一般的なプロパティーを設定します。
「アプリケーション」タブでは、インスタンスと関連付けられたアプリケーションのうち選択したものを有効化または無効化したり、配備したりできます。
必要なアプリケーションのチェックボックスを選択します。
「配備」ドロップダウンメニューから、配備するアプリケーションモジュールのタイプを選択します。
エンタープライズアプリケーション: EAR (Enterprise Application Archive) ファイルまたはディレクトリ内の J2EE アプリケーション。
Web アプリケーション: WAR (Web アプリケーションアーカイブ) ファイルまたはディレクトリ内にパッケージ化されている JavaServer Pages (JSP)、サーブレット、HTML ページなどの Web リソースの集まり。
EJB モジュール: EJB JAR (Java Archive) ファイルまたはディレクトリに含まれる 1 つまたは複数の Enterprise JavaBeans (EJB コンポーネント)。
コネクタモジュール: エンタープライズ情報システム (EIS) に接続し、RAR (Resource Adapter Archive) ファイルまたはディレクトリにパッケージ化されます。
ライフサイクルモジュール: サーバーのライフサイクルの 1 つまたは複数のイベントによって起動されると、タスクを実行します。
アプリケーションクライアントモジュール: J2EE アプリケーションクライアント JAR ファイルとも呼ばれ、クライアントのサーバー側ルーチンを含んでいます。
「リソース」タブでは、リソースタイプを有効または無効にしたり、新規に作成してインスタンスと関連付けしたりできます。
必要なリソースのチェックボックスを選択します。
「新規」ドロップダウンメニューから、作成するリソースのタイプを選択し、該当するインスタンスと関連付けます。
JDBC: アプリケーションにデータベースへ接続する手段を提供します。
持続マネージャー: 下位互換性のために必要な、コンテナ管理による持続性 Beans を使用したアプリケーションのために必要です。
JMS 接続ファクトリ: アプリケーションがプログラムでほかの JMS オブジェクトを作成できるようにするオブジェクトです。
JMS 送信先: メールおよびメッセージングアプリケーションを構築するための、プラットフォームにもプロトコルにも依存しないフレームワークを提供する JavaMail API 内のメールセッションを表します。
JavaMail: メールおよびメッセージングアプリケーションを構築するための、プラットフォームにもプロトコルにも依存しないフレームワークを提供します。
カスタム: 定義済みの JNDI サブコンテキスト、リソースタイプ、およびファクトリクラスを含む、非標準のリソースを表します。
外部: LDAP (Lightweight Directory Access Protocol) リポジトリ内の外部リソースオブジェクトを検出するためのアプリケーションを有効にします。
コネクタ: アプリケーションにエンタープライズ情報システム (EIS) への接続を提供するプログラムオブジェクト。
管理オブジェクト: JSR-160 準拠のリモート JMX コネクタを設定します。
管理サーバーの詳細設定では、アプリケーションを配備するための一般プロパティーを設定できます。これらのプロパティーにより、配備されているアプリケーションに加えられた変更の検出や、変更されたクラスの再読み込みを確実に実行し、監視できます。
動的再読み込みを有効にすると、サーバーは配備されたアプリケーションのファイル内の変更を定期的にチェックし、変更のあるアプリケーションを自動的に再読み込みします。動的再読み込みは、変更したコードをすぐにテストできるため、開発環境で役に立ちます。しかし、本稼働環境では、動的再読み込みはパフォーマンスを低下させる可能性があります。
動的再読み込みは、開発環境を対象としています。この機能は、本稼働環境の機能であるセッションの持続性とは互換性がありません。動的な配備が有効になっている場合は、セッションの持続性を有効にしないでください。
動的再読み込みは、デフォルトのサーバーインスタンスにのみ利用可能です。
「アプリケーション設定」ページから動的再読み込みを設定するには、次を設定します。
再読み込み: 「有効」チェックボックスで動的再読み込みを有効または無効にします。
再読込のポーリング間隔: 配備されているアプリケーション内の変更をサーバーがチェックする頻度を指定します。
管理セッションタイムアウト: 管理セッションがタイムアウトし、再度ログインするまでの時間を指定します。
自動配備機能を使うと、事前にパッケージ化されたアプリケーションやモジュールを domain-dir/autodeploy ディレクトリにコピーすることで配備できます。
たとえば、hello.war という名前のファイルを domain-dir/autodeploy ディレクトリにコピーします。アプリケーションの配備を取り消すには、autodeploy ディレクトリから hello.war ファイルを削除します。
自動配備機能は、開発環境を対象としています。この機能は、本稼働環境の機能であるセッションの持続性とは互換性がありません。自動配備が有効になっている場合は、セッションの持続性を有効にしないでください。
自動配備は、デフォルトのサーバーインスタンスにのみ利用可能です。
「アプリケーション設定」ページに移動します。
「有効」チェックボックスを選択または選択解除して、自動配備を有効または無効にします。
「自動配備のポーリング間隔」フィールドで、アプリケーションやモジュールファイルの自動配備ディレクトリをサーバーが確認する頻度を指定します。
ポーリング間隔を変更しても、アプリケーションやモジュールの配備にかかる時間には影響ありません。
自動配備ディレクトリでアプリケーションを構築したディレクトリを指定してあれば、ファイルをデフォルトの自動配備ディレクトリにコピーする必要はありません。
デフォルトでは、複数のサーバーインスタンスのディレクトリを手動で変更する必要をなくすために、変数が使用されます。
配備の前にベリファイアを実行するには、「ベリファイアの有効化」チェックボックスにチェックマークを付けます。
ベリファイアはファイルの構造とコンテンツを調べます。大きなアプリケーションの検証は時間がかかる可能性があります。
JSP ページを事前にコンパイルするには、「JSP」チェックボックスにチェックマークを付けます。
このチェックボックスを選択しない場合、JSP ページは最初のアクセスの実行時にコンパイルされます。コンパイルは時間がかかる可能性があるので、本稼働環境ではこのチェックボックスにチェックマークを付けてください。
「プロパティーを追加」ボタンをクリックして、追加する設定値を指定します。
次のドメイン属性プロパティーが利用可能です。
表 1–1 ドメイン属性値
プロパティー |
定義 |
---|---|
com.sun.aas.installRoot |
アプリケーションサーバーがインストールされているディレクトリ |
com.sun.aas.instanceRoot |
サーバーインスタンス用のトップレベルディレクトリ |
com.sun.aas.hostName |
ホスト (マシン) の名前 |
com.sun.aas.javaRoot |
.J2SE インストールディレクトリ |
com.sun.aas.imqLib |
Sun Java System Message Queue ソフトウェアのライブラリディレクトリ |
com.sun.aas.configName |
サーバーインスタンスによって使用されている設定の名前 |
com.sun.aas.instanceName |
サーバーインスタンスの名前。このプロパティーは default-config には利用できませんが、カスタマイズされた設定には使用できます。 |
com.sun.aas.clusterName |
クラスタの名前。このプロパティーは、クラスタ化されたサーバーインスタンスにのみ設定されます。このプロパティーは default-config には利用できませんが、カスタマイズされた設定には使用できます。 |
com.sun.aas.domainName |
ドメインの名前。このプロパティーは default-config には利用できませんが、カスタマイズされた設定には使用できます。 |
インスタンス固有の設定プロパティーは、そのインスタンスの値をオーバーライドします。
デフォルト値は、インスタンスにバインドされている設定に定義されます。
「プロパティーを追加」ボタンをクリックして、追加する設定値を指定します。
リソースを設定するために、次のプロパティー属性名および値のペアを利用できます。
プロパティー |
定義 |
---|---|
HTTP_LISTENER_PORT |
このポートを使用して HTTP 要求を待機します。このプロパティーは、http-listener-1 のポート番号を指定します。有効な値は 1 〜 65535 です。UNIX では、ポート 1 〜 1024 で待機するソケットを作成するには、スーパーユーザー権限が必要です。 |
HTTP_SSL_LISTENER_PORT |
このポートを使用して HTTPS 要求を待機します。このプロパティーは、http-listener-2 のポート番号を指定します。有効な値は 1 〜 65535 です。UNIX では、ポート 1 〜 1024 で待機するソケットを作成するには、スーパーユーザー権限が必要です。 |
IIOP_LISTENER_PORT |
このプロパティーは、orb-listener-1 が待機する IIOP 接続の ORB リスナーポートを指定します。 |
IIOP_SSL_LISTENER_PORT |
このポートは、セキュアな IIOP 接続用に使用します。 |
JMX_SYSTEM_CONNECTOR_PORT |
このプロパティーは、JMX コネクタが待機するポート番号を指定します。有効な値は 1 〜 65535 です。UNIX では、ポート 1 〜 1024 で待機するソケットを作成するには、スーパーユーザー権限が必要です。 |
IIOP_SSL_MUTUALAUTH_PORT |
このプロパティーは、SSL_MUTUALAUTH と呼ばれる IIOP リスナーが待機する IIOP 接続の ORB リスナーポートを指定します。 |
ツリーコンポーネントで、「スタンドアロンインスタンス」ノードを選択します。
「スタンドアロンサーバーインスタンス」ページで、「新規」をクリックします。
「名前」フィールドで、新しいインスタンスの一意の名前を特定します。
「ノードエージェント」を選択します。
ノードエージェントの起動は、ノードエージェントのホストマシン上で asadmin start-node-agent コマンドを使用して行い、作成するサーバーインスタンスがそのノードエージェントと関連付けられるようにする必要があります。
必要な設定を選択します。
別の設定からコピーするには、新規インスタンスの作成時に設定値を指定します。
デフォルトでは、default-config 設定からコピーした設定を使用して新しいインスタンスが作成されます。
サーバーインスタンスの場合、新しい設定には instance-name-config という名前が付けられます。
default-config 設定はデフォルト設定であり、スタンドアロンサーバーインスタンスを作成するためのテンプレートとして機能します。クラスタ化されていないサーバーインスタンスまたはクラスタは、default-config 設定を参照できません。この設定は、新しい設定を作成するためにコピーできるだけです。デフォルト設定を編集して、コピーした新しい設定が正しく初期設定されているかどうか確認します。
create-instance
ツリーコンポーネントで、「スタンドアロンインスタンス」ノードを展開します。
起動したいインスタンスを選択します。
「一般」タブで、「インスタンスを起動」をクリックしてインスタンスを起動します。
インスタンスを正常に起動するには、asadmin start-node-agent コマンドを使用して、インスタンスと関連付けられているノードエージェントを起動する必要があります。
インスタンスが起動すると、「一般」タブから次のタスクが実行可能になります。
start-instance
トランザクションは、サーバークラッシュまたはリソースマネージャークラッシュのいずれかにより未完了になる可能性があります。これらの未完了トランザクションを完了させ、障害を回復させる必要があります。Application Server は、これらの障害を回復し、サーバーの起動時にそのトランザクションを完了するように設計されています。
選択されたサーバーが実行中の場合、回復は同じサーバーによって行われます。選択されたサーバーが実行中でない場合、選択した送信先サーバーが回復を実施します。
stop-instance