WebLogic Server のコンフィグレーションと管理
|
 |
 |
|
以下の節では、WebLogic Server の Web サーバ コンポーネントをコンフィグレーションする方法について説明します。
WebLogic Server は、動的な Java ベース分散アプリケーションのホストとなる他にも、大容量 Web サイトを処理できる高機能 Web サーバとして、HTML ファイルや画像ファイルなどの静的ファイル、およびサーブレットと JavaServer Pages (JSP) を提供します。WebLogic Server では、HTTP 1.1 規格をサポートしています。
サーバ インスタンスまたは仮想ホストごとに、Administration Console を使用して HTTP 操作パラメータをコンフィグレーションします。
各 WebLogic Server が HTTP リクエストをリスンするポートを指定できます。任意の有効なポート番号を指定できますが、ポート 80 を指定した場合、HTTP を介してリソースにアクセスするために使用する HTTP リクエストからポート番号を省略できます。たとえば、リスン ポートとしてポート 80 を定義した場合、http://hostname:portnumber/myfile.html ではなく、http://hostname/myfile.html という形式を使用できます。
注意 : WebLogic Server をポート 80 でリスンするように設定する場合
後半の 4 つのプロパティは UNIX ユーザのみに適用されます。
UNIX システムでは、プロセスを 1025 より小さいポートにバインドする場合は、特権を持つユーザ (通常は root) で行う必要があります。したがって、WebLogic Server がポート 80 をリスンするようにするには、特権を持つユーザとして WebLogic Server を起動しなければなりません。しかし、セキュリティの観点からすると、WebLogic Server のように長時間にわたって実行するプロセスを、必要以上の特権で実行するのは望ましくありません。root 特権が必要なのは、ポートがバインドされるまでです。
weblogic.system.enableSetUID プロパティを (必要に応じて weblogic.system.enableSetGID プロパティも) true に設定することで、WebLogic Server がポート 80 にバインドした後に UNIX ユーザ ID (UID) を切り替えるための内部プロセスを有効にできます。これらに対応する weblogic.system.nonPrivUser プロパティと weblogic.system.nonPrivGroup プロパティには、WebLogic Server の起動後の実行に使用する特権のない UNIX ユーザ アカウント (必要に応じてグループ名) を指定します。
UNIX アカウントは、ほとんどの UNIX システムで特権が最も低い「nobody」に切り替えることができます。必要な場合は、WebLogic Server の実行専用の UNIX ユーザ アカウントを作成します。特権のないユーザは、WebLogic Server で必要になるファイル (ログ ファイル、WebLogic クラスなど) にアクセスできるように設定してください。WebLogic プロセスの所有権が特権のないユーザに切り替わると、WebLogic の読み込み、書き込み、および実行のパーミッションがそのユーザと同じになります。
リスン ポートは、通常のリクエストとセキュアな (SSL を使用した) リクエストで別個に定義します。通常のリスン ポートは Administration Console の [サーバ] ノードの [コンフィグレーション｜全般] タブで定義し、SSL リスン ポートは [接続｜SSL] タブで定義します。
HTTP アプリケーションと Web アプリケーションは、Sun Microsystems のサーブレット仕様 2.3 に従ってデプロイされます。この仕様では、Web アプリケーションとは Web ベース アプリケーションのコンポーネントを 1 つにまとめるための標準化された方法であると定義されています。これらのコンポーネントには、JSP ページ、HTTP サーブレット静的リソース (HTML ページや画像ファイルなど) が含まれます。また Web アプリケーションは、エンタープライズ EJB や JSP タグ ライブラリなどの外部リソースにアクセスすることもできます。各サーバは、任意の数の Web アプリケーションのホストになることができます。通常、Web アプリケーションの名前は、その Web アプリケーションのリソースを要求するために使う URI の一部として使用します。
JSP は、デフォルトではサーバの一時ディレクトリにコンパイルされます。たとえば、サーバが「myserver」で webapp が「mywebapp」である場合、一時ディレクトリは <domain_dir>\myserver\.wlnotdelete\appname_mywebapp_4344862 となります。
詳細については、『WebLogic Server Web アプリケーションの開発』を参照してください。
Web アプリケーションは、WebLogic Server のクラスタにデプロイできます。ユーザが Web アプリケーションのリソースを要求すると、そのリクエストはその Web アプリケーションがホストするクラスタの構成サーバの 1 つに転送されます。アプリケーションがセッション オブジェクトを使用する場合、そのセッションはクラスタ内の全サーバにレプリケートされなければなりません。セッションのレプリケートにはいくつかの方法があります。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
ドメイン内のすべてのサーバ インスタンスおよび仮想ホストで、デフォルト Web アプリケーションを宣言できます。デフォルト Web アプリケーションは、デプロイされている別の Web アプリケーションによって解決できない任意の HTTP リクエストに応答します。他のすべての Web アプリケーションとは異なり、デフォルト Web アプリケーションの名前は、URI の一部として使用されません。サーバまたは仮想ホストに割り当てられた Web アプリケーションを、デフォルト Web アプリケーションとして宣言することができます (Web アプリケーションの割り当てについては、この節で後述します。仮想ホストの詳細については、「仮想ホスティングのコンフィグレーション」を参照してください。
WebLogic Server に付属のサンプル ドメインでは、デフォルトの Web アプリケーションが既にコンフィグレーションされています。このドメインのデフォルト Web アプリケーションは、DefaultWebApp という名前でドメインの applications ディレクトリに配置されています。
正常にデプロイされていないデフォルト Web アプリケーションを宣言すると、エラーがログに記録されるとともに、そのデフォルト Web アプリケーションにアクセスしようとしたユーザに対して HTTP 400 エラー メッセージが表示されます。
たとえば、shopping という Web アプリケーションが存在する場合、その Web アプリケーションの cart.jsp という JSP にアクセスするには、次の URL を使用します。
http://host:port/shopping/cart.jsp
しかし、shopping をデフォルト Web アプリケーションとして指定した場合、cart.jsp にアクセスするには次の URL を使用します。
(host は WebLogic Server が稼働するマシンのホスト名、port は WebLogic Server がリクエストをリスンするポートの番号)
サーバまたは仮想ホストのデフォルト Web アプリケーションを指定するには、weblogic.xml ファイルのコンテキスト ルートを「/」に設定します。
仮想ディレクトリ マッピング機能を使用すると、複数の Web アプリケーションで画像などの静的ファイルを提供する 1 つのディレクトリを作成できます。たとえば、次のようなマッピングを作成します。
<local-path>c:/usr/gifs</local-path>
<url-pattern>/images/*</url-pattern>
HTTP:// localhost:7001/mywebapp/images/test.gif を要求すると、要求された画像が c:/usr/gifs/images/* から検索されます。
このディレクトリは、「/images/test.gif」のように相対 URI で指定する必要があります。
仮想ホスティングを使用すると、サーバまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、WebLogic Server インスタンスまたはクラスタの IP アドレスにマップする 1 つまたは複数のホスト名を、DNS を使って指定します。また、仮想ホストによって提供される Web アプリケーションを指定します。仮想ホスティングをクラスタ内で使用する場合、ロード バランシング機能により、DNS ホスト名の 1 つが他のホスト名より多くのリクエストを処理する場合でもハードウェアを最も効率的に使用できます。
たとえば、books という Web アプリケーションが仮想ホスト名 www.books.com のリクエストに応答し、これらのリクエストが WebLogic Server A、B、および C に向けられるよう指定し、一方、cars という Web アプリケーションが仮想ホスト名 www.autos.com に応答し、これらのリクエストが WebLogic Server D および E に向けられるよう指定できます。アプリケーションと Web サーバの条件に合わせて、仮想ホスト、WebLogic Server、クラスタ、および Web アプリケーションのさまざまな組み合わせをコンフィグレーションできます。
また、定義した各仮想ホストに対して、個別に HTTP パラメータと HTTP アクセス ログを定義できます。仮想ホストに対して設定された HTTP パラメータとアクセス ログは、サーバに対して設定された HTTP パラメータとアクセス ログをオーバーライドします。指定できる仮想ホストの数に制限はありません。
仮想ホスティングをアクティブ化するには、仮想ホストをサーバまたはサーバ クラスタに割り当てます。クラスタに割り当てられた仮想ホスティングは、そのクラスタ内のすべてのサーバに適用されます。
各仮想ホストに対して、デフォルト Web アプリケーションを指定することもできます。仮想ホストのデフォルト Web アプリケーションは、同じサーバまたはクラスタで仮想ホストとしてデプロイされている別の Web アプリケーションで解決できないすべてのリクエストに応答します。
他の Web アプリケーションとは異なり、デフォルト Web アプリケーションの名前 (コンテキスト パスとも言う) は、そのデフォルト Web アプリケーションのリソースにアクセスするために使う URI の一部として使用されません。
たとえば、www.mystore.com という仮想ホスト名を定義し、shopping という Web アプリケーションをデプロイしたサーバにその仮想ホストを割り当てた場合、shopping の cart.jsp という JSP にアクセスするには、次の URI を使用します。
http://www.mystore.com/shopping/cart.jsp
しかし、shopping をこの仮想ホスト www.mystore.com のデフォルト Web アプリケーションとして指定した場合は、次の URI を使用して cart.jsp にアクセスします。
http://www.mystore.com/cart.jsp
詳細については、「WebLogic Server による HTTP リクエストの解決方法」を参照してください。
複数の仮想ホストを別々のデフォルト Web アプリケーションで使用する場合は、シングル サインオンは使用できません。それぞれの Web アプリケーションが、それ以前に設定されていた JSESSIONID クッキーを上書きしてしまうためです。これは、すべてのデフォルト Web アプリケーションで CookieName、CookiePath、および CookieDomain をまったく同じにしても発生します。
特定の HTTP リクエストでの仮想ホストの解決は、受信する HOST ヘッダに基づいて行われます。HOST ヘッダが間違っているか、存在しない場合、Web アプリケーションはデフォルトの仮想ホスト (デフォルト Web サーバ) に解決します。
仮想ホストを定義するには、Administration Console を使用して次の手順を実行します。
仮想ホスト名を確実に解決できるように、サーバ上の etc/hosts ファイルに仮想ホストのネーミングの行を追加する必要があります。
WebLogic Server が HTTP リクエストを受信すると、WebLogic Server は、URL のさまざまな部分を解析し、その情報を利用してどの Web アプリケーションとサーバがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。以下の例では、Web アプリケーション、仮想ホスト、サーブレット、JSP、および静的ファイルのリクエストのさまざまな組み合わせとその応答を示します。
注意 : Web アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化する場合は、Web アプリケーションへのリクエストの解決に使用する代わりの名前を指定できます。詳細については、「エンタープライズ アプリケーションの一部としての Web アプリケーションのデプロイメント」を参照してください。
次の表に、WebLogic Server によって提供される URL とファイルのサンプルを示します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* 詳細については、「ウェルカム ページのコンフィグレーション」を参照してください。
WebLogic Server は、HTTP トランザクションのログを、共通ログ フォーマットまたは拡張ログ フォーマットのいずれかのフォーマットでテキスト ファイルに保存します。共通ログ フォーマットは、デフォルトの、標準規則に従った形式です。拡張ログ フォーマットでは、記録されている情報をカスタマイズできます。定義した各サーバまたは各仮想ホストに対して、HTTP アクセス ログの性質を定義する属性を設定できます。
サーバまたは仮想ホストに対する HTTP ログの設定については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
ログ ファイルは、そのファイルのサイズ、または指定した時間のいずれかに基づいてローテーションすることができます。これらの 2 つの条件のいずれかが満たされると、現在のアクセス ログ ファイルが閉鎖され、新しいログ ファイルが開始されます。ログ ローテーションを設定しないと、HTTP アクセス ログ ファイルは無限に大きくなります。アクセス ログ ファイルの名前は、いつファイルがローテーションされたのかを示す日付と時刻のスタンプが含まれるようにコンフィグレーションできます。タイムスタンプをコンフィグレーションしない場合、ローテーションされた各ファイルの名前にはローテーションごとにインクリメントされる数値が含まれます。HTTP アクセス ログは、定義した Web Server ごとに保存されます。
ログに記録される HTTP 情報のデフォルト フォーマットは、共通ログ フォーマットです。 この標準フォーマットのパターンは以下のとおりです。
host RFC931 auth_user [day/month/year:hour:minute:second
UTC_offset] "request" status bytes
WebLogic Server は、W3C によって定義された拡張ログ フォーマット、バージョン 1.0 もサポートしています。このフォーマットは新しく登場した規格で、WebLogic Server は W3C の草案仕様に準拠しています。最新バージョンは、「W3C Technical Reports and Publications」に公開されています。
拡張ログ フォーマットを使用すると、各 HTTP 通信に関する記録情報のタイプと順序を指定できます。拡張ログ フォーマットを有効にするには、Administration Console の [HTTP] タブで、[フォーマット] 属性を [Extended] に設定します (「カスタム フィールド識別子の作成」を参照)。
このフォーマットでは、ログ ファイルに記録される情報のタイプをディレクティブによって指定します。ディレクティブは、実際のログ ファイルに組み込まれます。 ディレクティブは、新しい行から「#」という記号で始まります。ログファイルが存在しない場合、デフォルト ディレクティブが記述された新しいログ ファイルが作成されます。しかし、サーバの起動時にログ ファイルがすでに存在する場合、そのファイルの先頭には有効なディレクティブが存在しなければなりません。
ログ ファイルの最初の行には、そのログ ファイル フォーマットのバージョン番号を示すディレクティブが存在しなければなりません。また、ファイルの先頭の近くには、Fields ディレクティブが存在しなければなりません。
#Version: 1.0
#Fields:xxxx xxxx xxxx...
ここで各 xxxx は、記録されるデータ フィールドを表します。フィールド タイプは、W3C 仕様に定義されているとおり、単純な識別子として指定されるか、またはプレフィックス-識別子というフォーマットを取ります。 次に例を示します。
#Fields: date time cs-method cs-uri
この識別子は、HTTP アクセスごとにトランザクションの日付と時間、クライアントが使用したリクエスト メソッド、およびリクエストの URI を記録するようサーバに指示します。各フィールドはスペースによって区切られ、各レコードは新しい行に書き込まれてログ ファイルに追加されます。
注意 : ログ ファイル内の #Fields ディレクティブの後には新しい行が続かなければなりません。これは、最初のログ メッセージがディレクティブと同じ行に追加されないようにするためです。
以下の識別子がサポートされています。プレフィックスは必要ありません。
W3C 仕様で定義されている cached フィールドは、WebLogic Server ではサポートされていません。
以下の識別子はプレフィックスを必要とし、単独では使用できません。ここでは、サポートされている個々のプレフィックスの組み合わせについて説明します。
拡張ログ フォーマットを使用する HTTP アクセス ログ ファイルに追加するために、ユーザ定義のフィールドを作成することもできます。カスタム フィールドを作成するには、ELF ログ ファイルで Fields ディレクティブを使用してフィールドを指定します。次に、そのフィールドに対応し、必要な出力が生成される Java クラスを作成します。フィールドごとに別々の Java クラスを作成することも、複数のフィールドを出力する Java クラスを作成することもできます。このようなクラスの Java ソースのサンプルをこのマニュアルの中で示します。「カスタム ELF フィールドを作成する Java クラス」を参照してください。
Fields ディレクティブの詳細については、「Fields ディレクティブの作成」を参照してください。
Fields ディレクティブで定義したカスタム フィールド (myCustomField など) と同じ完全修飾クラス名を持つ Java クラスを作成します。このクラスではカスタム フィールドにロギングする情報を定義します。Java クラスには次のインタフェースを実装する必要があります。weblogic.servlet.logging.CustomELFLogger
Java クラスでは、logField() メソッドを実装しなければなりません。このメソッドは、HttpAccountingInfo オブジェクトと FormatStringBuffer オブジェクトを引数として取ります。
HttpAccountingInfo オブジェクトを使用して、HTTP リクエストとカスタム フィールドに出力できる応答データにアクセスします。この情報にアクセスするためのゲッター メソッドが提供されています。get メソッドの完全なリストについては、「HttpAccountingInfo オブジェクトの get メソッド」を参照してください。 CLASSPATH 文にクラスを追加します。WebLogic Server の起動に使用するスクリプト内の CLASSPATH 文を変更する必要があります。注意 : このクラスを、展開形式または jar 形式で、Web アプリケーションまたはエンタープライズ アプリケーションの内部に配置しないでください。
注意 : カスタム フィールドを定義する Java クラスの記述では、システムの処理速度を低下させるようなコードは実行しないでください (たとえば、DBMS へのアクセス、大量の I/O、またはネットワークの呼び出しなど)。HTTP アクセス ログ ファイルのエントリは HTTP リクエストごとに作成されます。
注意 : 複数のフィールドを出力する場合は、タブでフィールドを区切ります。フィールドの区切り方およびその他の ELF フォーマットの詳細については、「Extended Log File Format」を参照してください。
次のメソッドは HTTP リクエストに関するさまざまなデータを返します。これらのメソッドは、javax.servlet.ServletRequest、javax.servlet.http.Http.ServletRequest、および javax.servlet.http.HttpServletResponse のさまざまなメソッドと似ています。
これらのメソッドの詳細については、次の表に示す Java インタフェースの対応するメソッドを参照するか、表内の特定の情報を参照してください。
コード リスト 8-1カスタム ELF フィールドを作成する Java クラス
importweblogic.servlet.logging.CustomELFLogger;
importweblogic.servlet.logging.FormatStringBuffer;
importweblogic.servlet.logging.HttpAccountingInfo;
/* この例は User-Agent フィールドを MyCustomField という
カスタム フィールドに出力する
*/
public class MyCustomField implements CustomELFLogger{
public void logField(HttpAccountingInfo metrics,
FormatStringBuffer buff) {
buff.appendValueOrDash(metrics.getHeader("User-Agent"));
}
}
サービス拒否攻撃とは、偽りのリクエストによってサーバを過負荷状態にしようとする悪意ある試みです。一般的な攻撃の 1 つは、HTTP POST メソッドで膨大な量のデータを送信するというものです。WebLogic Server では、3 つの属性を設定して、この種の攻撃を防くことができます。3 つの属性は、コンソールの [サーバ] または [仮想ホスト] で設定します。これらの属性を仮想ホストに対して設定した場合、その値は [サーバ] で設定した値をオーバーライドします。
WebLogic Server が POST データを受信するために費やす総時間数を制限します。この制限を超えた場合、PostTimeoutException が送出され、次のメッセージがサーバ ログに記録されます。
HTTP トンネリングとは、HTTP プロトコルしか使用できないときに、WebLogic Server と Java クライアントの間にステートフルなソケット接続をシミュレートするための手段です。HTTP トンネリングは、通常セキュリティ ファイアウォール内の HTTP ポートを「トンネリング」するために使用されます。HTTP はステートレスなプロトコルですが、WebLogic Server はトンネリング機能を提供して接続を通常の T3Connection のように見せかけます。しかし、通常のソケット接続に比べてパフォーマンスが若干低下する場合があります。
HTTP プロトコルでは、クライアントはリクエストを送信し、サーバから応答を受信することしかできません。一方、サーバも自主的にクライアントと通信できません。つまり、HTTP プロトコルはステートレスであり、連続的な双方向接続を行うことができません。
WebLogic HTTP トンネリングは、HTTP プロトコルを通して T3Connection をシミュレートすることによって、こうした制限を乗り越えます。トンネリング接続を調整してパフォーマンスを向上させるには、Administration Console で 2 つの属性を設定します。これらの属性にアクセスするには、[サーバ] の [接続｜プロトコル] タブを開きます。接続に関する問題が発生しない限り、これらの属性はデフォルトのままにしておくことをお勧めします。これらの属性は、クライアント接続が有効かどうか、またはクライアントが生存しているかどうかをサーバが調べるために使用されます。
HTTP トンネリング接続が設定されると、クライアントは自動的にリクエストをサーバに送信し、サーバは自主的にクライアントに応答できるようになります。また、クライアントはリクエストに指示を入れることができますが、この処理はクライアント アプリケーションがサーバと通信する必要があるかどうかに関係なく発生します。この属性で設定された秒数以内にサーバがクライアントのリクエストに (アプリケーション コードの一部として) 応答しない場合、クライアントはその処理を行います。クライアントは応答を受信し、自動的に別のリクエストを即座に送信します。
クライアントが WebLogic Server への接続を要求する場合、HTTP トンネリングを使用するために必要なことは URL に HTTP プロトコルを指定することだけです。次に例を示します。
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "http://wlhost:80");
Context ctx = new InitialContext(env);
クライアント側では、特殊なタグが http プロトコルに付加されます。このため WebLogic Server は、これが通常の HTTP リクエストではなくトンネリング接続であることを認識します。この処理では、アプリケーション コードを変更する必要はありません。
クライアントは、ポートが 80 の場合でも URL にポートを指定しなければなりません。WebLogic Server では HTTP リクエスト用のリスン ポートを任意に設定できますが、ポート 80 を使用するのが最も一般的です。通常、ファイアウォールを介したポート 80 へのリクエストは許可されるからです。
WebLogic Server 用のリスン ポートは、Administration Console の [サーバ] ノードの [ネットワーク] タブで指定します。
WebLogic Server を Windows NT/2000 で実行している場合は、HTML ファイル、テキスト ファイル、画像ファイルなどの静的ファイルを提供する際に、Java メソッドではなくネイティブ オペレーティング システム コール TransmitFile を使用するように指定できます。ネイティブ I/O を使用することで、サイズの大きい静的ファイルを提供する際のパフォーマンスが向上します。
ネイティブ I/O を使用するには、ネイティブ I/O を使用して提供するファイルを含んだ Web アプリケーションの web.xml デプロイメント記述子に 2 つのパラメータを追加します。1 つめのパラメータは weblogic.http.nativeIOEnabled です。これを TRUE に設定することで、ネイティブ I/O によるファイル提供が有効になります。2 つめのパラメータは、weblogic.http.minimumNativeFileSize です。このパラメータには、ネイティブ I/O を使用する際の最小ファイル サイズを指定します。提供するファイルのサイズがこの値より大きいと、ネイティブ I/O が使用されます。このパラメータを指定しない場合のデフォルト値は 4K です。
ネイティブ I/O を使用すると、通常であれば大きなファイルを提供する際のパフォーマンスが向上しますが、WebLogic Server を実行しているマシンへの負荷が増大するため、パフォーマンスがそれほど向上しない場合もあります。weblogic.http.minimumNativeFileSize の値を調節して、適切な値を見つける必要があります。
web.xml デプロイメント記述子に追加する必要のあるすべてのエントリの例を示します。これらのエントリは、web.xml ファイルの <distributable> 要素の後、<servlet> 要素の前に追加する必要があります。
<param-name>weblogic.http.nativeIOEnabled</param-name>
<param-value>TRUE</param-value>
<param-name>weblogic.http.minimumNativeFileSize</param-name>
<param-value>500</param-value>
weblogic.http.nativeIOEnabled も、FileServlet のコンテキスト パラメータとして設定できます。
|
|
|