第3章
この章では、Novell exteNd Application Serverの基本的なハードウェア環境設定、およびWeb環境でのサーバの動作について説明します。この章は、次の項目の節で構成されます。
この節では、運用に推奨されるアプリケーションサーバ環境設定について説明します。簡略化するため、この説明では単一の(スタンドアロン)アプリケーションサーバを使用します。
運用環境では、アプリケーションサーバおよびデータベースサーバを個別のコンピュータに設定することが最適です(これを「複数ホストの環境設定」と呼びます)。
次の図は、2つのデータベースサーバ接続があるアプリケーションサーバに推奨される環境設定を示します。
(アプリケーションサーバとともに図に示された)SilverMasterデータベースは、システム全体のマスタデータベースです。SilverMasterの詳細については、SilverMaster機能を参照してください。
この環境設定にWebサーバをもう1つ置いたとしても、アプリケーションサーバへの影響はあまりありません。アプリケーションサーバのリスニングポートをデフォルト(ポート80)から別のポートに変更すれば、アプリケーションサーバをWebサーバと共存させることができます。詳細については、一般的なサーバのプロパティの指定を参照してください。
利点 アプリケーションサーバおよびデータベースサーバを個別のコンピュータに設定すると、次の利点があります。
各データベースサーバをホストするコンピュータは、そのアプリケーションサーバに必要なメモリ容量に一致するように設定できます。
アプリケーションサーバが実行されているオペレーティングシステムプラットフォーム以外のオペレーティングシステムプラットフォームで、データベースサーバを実行できます。たとえば、UNIXデータベースサーバおよびWindowsのアプリケーションサーバを実行できます。
難点 アプリケーションサーバおよびデータベースサーバを個別のコンピュータに設定すると、追加のコンピュータを管理しなければならないという難点があります。
運用アプリケーションサーバ環境に適した環境設定の詳細については、ネットワーク環境設定を参照してください。
ファイアウォールは、ネットワークアクセスの規制に重要です。ファイアウォールの使用方法、アプリケーションサーバによるデータベースサーバとの通信方法、およびファイアウォールを通して匿名のユーザのアクセスを許可する場合について、決定しなければならない項目が多数あります。
一般的な大規模Web環境では、スタティックトラフィックルーティングサービスは、ネットワークサービスプロバイダのルータと内部ネットワークの間に配置されます。トラフィックルーティングサービスは、ルータの審査規則を使用してIPレベルで、またはプロキシゲートウェイおよびプロキシサービスを使用してアプリケーションレベルで実装できます。
プロキシサーバについて 「プロキシサーバ」は、保護されているネットワークとインターネットの間のトラフィックを仲介するアプリケーションです。プロキシサーバは、主に、インターネット接続を統合し、(通常ブラウザからWebサーバに渡される情報を保護することによって)ユーザに一般的なレベルの匿名性を提供し、Webトラフィックにおいて強化されたセキュリティを実行する(ユーザによってアクセス可能なサイトなど)ために使用されます。
プロキシには、ユーザ認証の追加のログ機能またはサポートが含まれるものが多数あります。使用されているアプリケーションプロトコルがプロキシによって理解される必要があるため、プロトコル固有のセキュリティを実装することもできます。プロキシコンピュータによってより高レベルな監査およびセキュリティが提供されますが、プロキシは必要な各マシン用に開発される必要があるため、環境設定コストは高くなりサービスのレベルは低くなります。
注記: アプリケーションサーバとともに使用するプロキシサービスソフトウェアでは、Microsoft Proxy ServerまたはNetscape Proxy ServerなどのHTTP 1.1がサポートされます。
ファイアウォールについて 「ファイアウォール」は、ネットワークへのアクセスを規制するためのハードウェアまたはソフトウェアの機能です。ファイアウォールは、従来、会社のイントラネットを公共のインターネットトラフィックから保護するために使用されます。「ポリシー」がファイアウォールに設定され、特定のトラフィックのみが通過できるようになっています。 実際に関連するメカニズムはそれぞれ異なりますが、原則としてファイアウォールは、トラフィックのブロックおよびトラフィックの許可という2つのメカニズムとして考えられます。管理者は、ファイアウォールを設定して、セキュリティ侵害の通知を受けたり全体のトラフィックを監視したりすることができます。
アプリケーションサーバは、エクストラネットの顧客からアプリケーションサーバへの、ファイアウォールを通じて許可されるまたはプロキシされるHTTP要求とともに、サイトにあるファイアウォールの中で実行されます。これによって、データベース接続はファイアウォールを通過する必要がなくなります。次の図は、アプリケーションサーバのファイアウォールおよびプロキシサーバとの設定方法について示します。
この節では、アプリケーションの必要条件に基づいてネットワークを設定する複数の方法について説明します。構成内容は次のとおりです。
小規模企業、部署、および少人数の開発者チームには、単一のアプリケーションサーバを使用できます。次の図は、LAN (ローカルエリアネットワーク)のユーザに提供される簡単なWebアプリケーションをホストするアプリケーションサーバ(agsrv1)を使用した簡単なネットワーク環境設定の様子を示します。アプリケーションサーバは、ユーザ認証/アクセス制御および電子メールを通じたユーザへのアプリケーションデータの送信のために、既存のWindowsセキュリティドメイン(pdc1上)および電子メールサーバ(mailsrv1)を利用します。
サーバのSilverMasterは、ラインオブビジネスのデータベースが置かれているデータベースサーバコンピュータ(dbsrv1)上に置かれています。アプリケーションはSilverMasterに展開されます。
この環境設定に適した状況 このタイプの環境設定は、次の場合に適しています。
フェールオーバー機能は必要はありません。場合によっては、ハードウェアアップグレードまたはテープバックアップなどの不定期的な管理業務のためにサーバダウンできます。クラスタ化されたサーバ装置は必要ありません。
すべてのユーザは単一の既存のセキュリティモデルに対して認証されます。部署またはサイトには、ユーザおよびグループ(たとえばWindowsドメイン)の以前から存在するサーバリストがある場合があり、アプリケーションサーバはこのディレクトリを利用できます。
この環境設定の利点 この環境設定には、次のようないくつかの利点があります。
|
利点 |
説明 |
|---|---|
|
簡単な管理 |
単一のアプリケーションサーバマシンの管理は、サーバのクラスタをホストするコンピュータのグループを保持するよりも簡単です。 |
|
簡単なネットワークトポロジ |
ユーザ数が少なくアプリケーションが複雑ではないため、適切なTCP/IPのコネクティビティ以外に余分なネットワーク環境設定が必要ありません。 |
この環境設定の制限事項 この環境設定は小規模企業または部門アプリケーションに適していますが、この方法には次のような制限事項があります。
基本的な負荷分散およびフェールオーバーの機能を提供するため、アプリケーションサーバによって、ディスパッチャ、負荷マネージャ、およびキャッシュマネージャが提供されます。次の図は、アプリケーションサーバのソフトウェアディスパッチャ(dispatch1)により管理されるトラフィックがあるクラスタの、複数のアプリケーションサーバ(agsrv1、agsrv2、およびagsrv3)の一般的なネットワーク図を示します。キャッシュマネージャおよび負荷マネージャは、アプリケーションサーバのクラスタとして同じ物理的サブネット上に置くことがお勧めしますが、ネットワークの任意のマシンに置くことができます。
このシナリオでは、企業ワークステーションのブラウザは、SilverJ2EEClientコンテナで実行中のブラウザまたはJavaアプリケーションを使用するアプリケーションサーバのソフトウェアディスパッチャ(dispatch1)に接続することによって、アプリケーションにアクセスします。負荷計画に応じて、ディスパッチャによって、クラスタ内の使用可能なサーバへのHTTPリダイレクションが返されます。
接続を確立するには、クライアントは標準の方法を使用してターゲットサーバのTCP/IPホスト名を解決する必要があります。たとえば、Windowsのワークステーションでは、クライアントは、ターゲットサーバのTCP/IPアドレスをWINS (Windows Internet Naming Service)サーバまたはDNS (Domain Naming Service)サーバから要求するか、またはNBT (NetBIOS over TCP/IP)ブロードキャストを実行して名前およびアドレスを解決します。 解決したら、クライアントはサーバに直接アクセスします。それ以降はディスパッチャにはアクセスしません。
HTMLアプリケーションの例 企業ユーザは、ブラウザでhttp://dispatch1/Accounting/ default.htmlを開くと、会社のアカウントHTMLアプリケーションにログインできます。 ソフトウェアディスパッチャ(dispatch1)はHTTPリダイレクト信号をクライアントに返し、クライアントはhttp://agsrv2/Accounting/default.htmlへの直接接続を確立します。ブラウザがアプリケーションサーバ(agsrv2)にリダイレクトされるだけでなく、完全なURLアドレス情報(データベース名、アカウント、およびページ名)も渡されます。
負荷計画に従って、次にアプリケーションにアクセスするユーザは、次に使用可能なサーバにラウンドロビン式に転送されます。たとえば、http://dispatch1/Accounting/ default.htmlはhttp://agsrv3/Accounting/default.htmlにリダイレクトされます。
この環境設定の利点 この環境設定には、次のようないくつかの利点があります。
この環境設定の制限事項 この環境設定には、次のような制限事項があります。
保護なしのLANリソースへの不正アクセスを防止する、ファイアウォールおよび追加のセキュリティメカニズムは提供されません。
この環境設定はインターネットアプリケーションに使用できますが、より高度なディスパッチャを使用する場合などに必要なDNSのマスキングに対する設備はありません。これに関しては、すべてのアプリケーションサーバおよびディスパッチャがインターネットでDNS登録されている必要があります。
詳細情報 クラスタおよび負荷分散の詳細については、を参照してください。
次の図は、(SilverJ2EEClientを使用してJavaアプリケーションを実行する)内部ユーザおよび(インターネット上でHTMLアプリケーションにアクセスする)外部ビジネスパートナーの両方に、エクストラネットWebアプリケーション機能を提供するために単一のアプリケーションサーバを使用する方法を示します。
このシナリオでは、アプリケーションサーバ(agsrv1)によって、企業のWebサイトサービス(www1およびwww2)から提供される既存のスタティックコンテンツとともに、Webアプリケーションサービスが提供されます。このアプリケーションサーバ(agsrv1)はDNS登録されているため、エクストラネットユーザがWebサイトから(アプリケーションサーバでホストされる)アプリケーションログオンページに転送されると、ブラウザによって、アプリケーションサーバに接続するルートが認識されます。この場合、インターネットのクライアントは、アプリケーションサーバにアクセスするためには、ファイアウォール(gatekeeper1)を通過する必要があります。
この接続を容易にするため、ファイアウォール(gatekeeper1)は、TCP/IPポート80のHTTPトラフィックのみがアプリケーションサーバへ通過できるように設定されています。これによって、アプリケーションに応じたデータがエンドユーザ以外のユーザによって遮断されないこと、および受信トラフィックによって企業リソースがアクセスされるないことが、システム管理者に保証されます。
ユーザは、企業Webサイト(www1およびwww2)のリンクからアプリケーションにアクセスします。Webサービス統合(WSI)モジュールは、両方のWebサーバにインストールおよび設定され、agsrv1のログオンページへのリダイレクション機能を提供します。リダイレクトされると、ブラウザによってアプリケーションサーバへの接続が確立されます。
このプロセスは、次のように要約できます。
ファイアウォールを通じてアプリケーションサーバ(agsrv1)に接続すると、ユーザ認証のため、ユーザはアプリケーションにログオンするように要求されます。エクストラネットユーザのリストは、サーバのSilverMasterデータベースに維持されます。このデータベースは、eコマースアプリケーションが提供されるデータベースと同様に、dbsrv1で維持されます。ユーザは、ログオンのアカウント情報を入力してログオンし、アプリケーションを使用してビジネスを行うことができます。
会社の内部では、企業ユーザは、(SilverJ2EEClientコンテナを使用する)Javaアプリケーションを使用するエクストラネットユーザと通信します。管理のため、企業ITによってHTTPポート80のSMCが使用されます。
この環境設定の利点 この環境設定には、次のようないくつかの利点があります。
この環境設定の制限事項 この環境設定には次のような制限事項があります。
「負荷分散」および「フェールオーバー」 会社内のユーザおよび外部のビジネスパートナーの両方がこのアプリケーションを使用する場合、負荷分散およびフェールオーバー機能なしでは、サーバのダウンタイムによってユーザがアプリケーションにアクセスできなくなります。
詳細情報 WSIモジュールの詳細については、を参照してください。
大規模なeコマースアプリケーションには、通常、高度な機能、スループット、および可用性が必要とされます。これには、すでに説明したものよりも強固で複雑な、基盤となるシステムアーキテクチャが必要です。
アプリケーションサーバのクラスタから提供される大規模インターネットアプリケーションの例は、次のようになります。インターネットユーザは、ファイアウォール(gatekeeper1)の外に配置されている2つのWebサーバ(www1およびwww2)からのリンクを使用してアプリケーションにアクセスします。
トランスペアレントのセッションレベルフェールオーバーを実装し、全体的なDNSおよびファイアウォール管理を削減するため、システム管理者は、アプリケーションサーバのソフトウェアディスパッチャではなく、サードパーティのハードウェアディスパッチャをインストールします。これによって、すべてのアプリケーションサーバへのトラフィックは、イントラネット(www3)上の単一のTCP/IPアドレスおよびホスト名にローカライズされます。それに加えて、このタイプのデバイスでは、アプリケーションサーバのソフトウェアディスパッチャを使用した場合の4つのマシン(dispatch1、agsrv1、agsrv2、およびagsrv3)とは異なり、TCP/IPアドレスおよびホスト名を1つだけDNS登録する必要があります。
着信要求がWebアプリケーション自体(www3上)にリンクされている場合、ブラウザによって、ファイアウォールを通じてWebディスパッチャへの接続が確立されます。ハードウェアディスパッチャによって、独自の負荷計画に基づいて、クラスタ内の使用可能なサーバにブラウザが接続されます。アプリケーションサーバのソフトウェアディスパッチャとは異なり、すべてのHTTPトラフィックはハードウェアディスパッチャによって制御されます。サーバがダウンした場合には、ディスパッチャによって、自動的にクラスタ内の異なるサーバにブラウザセッションが転送されます。ディスパッチャによってDNSマスキングが使用されるため、エラーはエンドユーザに完全にトランスペアレントです。
詳細情報 クラスタおよび負荷分散の詳細については、を参照してください。
インターネットセキュリティおよびネットワークインフラストラクチャの複雑さは、会社のサイズに関係していることがよくあります。たとえば、複雑なeコマースのインターネットアプリケーションおよびエクストラネットアプリケーションを持つ大規模企業では、ファイアウォールセキュリティには2階層の方法が使用される場合があります。
次の図は、この例を示します。すべてのインターネットトラフィックは、インターネットファイアウォール(gatekeeper1)を通じて転送されます。このファイアウォールによって、Webトラフィックおよびインターネットメールのみが、2つのファイアウォール間の領域であるDMZ (Demilitarized Zone)まで許可されます。 セキュリティのために、すべてのWebサーバおよびアプリケーションサーバは、DMZに置かれています。
3つ目のネットワークカードをファイアウォールに追加して、インターネットトラフィックを保護することも可能でしたが、セキュリティ上の理由から、この会社では個別のデバイスを使用することが決定されました。
DNSマスキングハードウェアディスパッチャ(wwwおよびapps)は、トラフィックを負荷分散式に転送するために使用されます。 また、複数のTCP/IPアドレスに対して設定された1つのデバイスを使用して、両方のクラスタにトラフィックを転送することも可能ですが、冗長のため、2つの個別のデバイスが使用されています。
イントラネットファイアウォール(gatekeeper2)によって、アプリケーションサーバ(agsrv1およびagsrv2)からの電子メールトラフィックおよびデータベース接続の通過が許可されます。これによって、システム管理者は、保護されているDMZ(アプリケーションサーバ)からの電子メールトラフィックおよびデータベース呼び出しのみが企業情報にアクセスできることを確認できます。
外部ユーザは、証明書サーバ(cert1)からブラウザ証明書を取得することによって認証できます。アプリケーションサーバによって、証明書に基づいてこれらのユーザが認証され、ブラウザからアプリケーションサーバへのネットワークトラフィックが暗号化されます。
この環境設定の利点 この設定は、次のような必要条件がある場合に適しています。
このアーキテクチャは複雑で、一般的なイントラネットサイトよりも維持することが困難です。しかし、説明したような利点を確保するには、このタイプのアーキテクチャを設定する必要があります。ダウンタイムはビジネスの損失となることがよくあります。適切に設計されたネットワークインフラストラクチャを維持することにより、すぐに相当の成果を得ることができます。
詳細情報 クラスタおよび負荷分散の詳細については、を参照してください。
アプリケーションサーバは、各クライアント接続についての情報を「セッションオブジェクト」に保存します。セッションは、クライアントがサーバに最初に接続する際に開始します。セッションオブジェクトの情報には、ユーザ認証などの情報が含まれます。また、アプリケーションはアプリケーション固有のデータもセッションオブジェクトに保存します。サーブレットまたはJSPページを含むセッションは、アイドル状態が5分(デフォルト)を超えると終了します。SMCを使用すると、このセッションタイムアウト値を変更できます(［サーバ要求のタイムアウト］の値を設定します)。
［サーバ要求のタイムアウト］の値を設定する詳細については、パフォーマンスパラメータの設定を参照してください。
アプリケーションサーバはCookieまたはURLの再書き込みを使用して、複数のWebブラウザクライアントの状態を追跡できます。CookieおよびURL再書き込みの両方によって、セッションIDが使用されます。 ブラウザセッション内のサーバへのすべてのコールは、同じセッションIDの下で動作します。セキュアデータの場合、認証はユーザ認証が必要とされるセッションのアクティブセッションにつき1回実行されます。
「認証」とは、サーバおよびクライアントが互いの識別情報を検証するプロセスです。認証については、認証の有効化で説明されています。
ユーザのブラウザによってクッキーがサポートされている場合は、アプリケーションサーバによってクッキーが使用され、セッションが追跡されます。「cookie」は、WebサーバからWebブラウザに送信される情報です。ブラウザクライアントはcookieを保存し、サーバに追加の要求が出されるたびにcookieをサーバに返信します。 アプリケーションサーバは、クッキーをセッションIDとして使用します。サーバがCookieを含む要求をクライアントから受信すると、cookieに保存されている情報を使用してセッションに再接続できます。
重要: アプリケーションサーバのcookieはメモリに保存され、ディスクには書き込まれません。Cookieには、ユーザの個人情報および追跡情報は含まれていません。
Cookieのコンテンツが懸念される場合は、ブラウザによってcookieを使用できないように設定するか、またはcookieがある場合に警告が表示されるように設定できます。 Cookieの詳細については、ブラウザのマニュアルを参照してください。
Cookieの使用が許可されていないブラウザをサポートするため、アプリケーションサーバは(jsessionidパラメータを追加することによって)URLが要求をセッションに正しく関連付けるように再書き込みします。サーブレットまたはJSPページを作成するアプリケーション開発者は、URL再書き込みを使用してクッキーを使用できないクライアントをサポートする方法を理解する必要があります。
サーブレットおよびJSPページのURL再書き込みの詳細については、次のセッショントラッキングの仕組みを参照してください。
ユーザのブラウザでcookieがサポートされている場合は、アプリケーションサーバはcookieを使用し、サポートされていない場合はURL再書き込みを使用します。これは、各ユーザのランタイム時に決定されます。アプリケーションサーバが要求を初めて受信すると、cookieを設定し、URLに「jsessionid」を追加します(クライアントがcookieをサポートしているかどうか不明であるため)。
クライアントがクッキーをサポートしている場合、アプリケーションサーバは、(最初の要求受信時にURLは再書き込みされますが)セッショントラッキングにcookieを使用します。クライアントがcookieを返すと、サーバはこのセッションのクライアントに対するURL再書き込みを停止します。
注記: Cookieでは値「JSESSIONID」(すべて大文字)が使用され、URL再書き込みによって「jsessionid」(すべて小文字)が使用されます。
管理者のメモ クライアントがcookieをサポートしないことが判断された場合、ユーザがページ内のリンクをクリックするたびに、サーバはセショントラッキングのためにURLに「jsessionid」を追加します。
クライアントが初めてセッションを確立すると、URL「jsessionid」はURLに追加され、クライアントユーザに対して表示されます。サーバとクライアント間のそれ以降の通信では、URL再書き込みによってセッションIDが追跡され、「jsessionid」は、ユーザのマウスがページ内のリンク上に置かれているときにのみ表示されます。
ブラウザクライアントがcookieをサポートしない場合、HTMLリンクを使用するサーブレットおよびJSPページで2つの標準エンコード方法のいずれかを呼び出す必要があります(次の開発者のメモを参照)。
開発者のメモ 次のエンコード方法によって、サーバによるcookieまたは「jsessionid」の存在をチェックできます。
これらのエンコード方法の1つは、サーブレットまたはJSPページによって、明示的にURLが応答に作成されるまたは埋め込まれるときに必要です。
URLの「jsessionid」はパスパラメータであり、クエリパラメータではありません。「クエリパラメータ」は、通常URLの最後にあり、「?」で区切られます。「パスパラメータ」は、URLのコンポーネントの最後にあり、クエリパラメータより前にあります。次の例を参照してください。
http://server/db/foo;pparam=foo?qparam=bar&rparam=bar
この例では、「pparam」はパスパラメータで、「qparam」および「rparam」は両方ともクエリパラメータです。
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...