 |
|
管理ガイド 05/21/03 10:02:24 |
この章では、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)まで許可されます。すべてのWebサーバおよびアプリケーションサーバは、セキュリティのためにDMZに置かれています。
3つ目のネットワークカードをファイアウォールに追加して、インターネットトラフィックを保護することも可能でしたが、セキュリティ上の理由から、この会社では個別のデバイスを使用することが決定されました。
DNSマスキングハードウェアディスパッチャ(wwwおよびapps)は、トラフィックを負荷分散式に転送するために使用されます。また、複数のTCP/IPアドレスに対して設定された1つのデバイスを使用して、両方のクラスタにトラフィックを転送することも可能ですが、冗長のため、2つの個別のデバイスが使用されています。
イントラネットファイアウォール(gatekeeper2)によって、アプリケーションサーバ(agsrv1およびagsrv2)からの電子メールトラフィックおよびデータベース接続の通過が許可されます。これによって、システム管理者は、保護されているDMZ (アプリケーションサーバ)からの電子メールトラフィックおよびデータベース呼び出しのみが企業情報にアクセスできることを確認できます。
外部ユーザは、証明書サーバ(cert1)からブラウザ証明書を取得すると認証されることができます。アプリケーションサーバによって、証明書に基づいてこれらのユーザが認証され、ブラウザからアプリケーションサーバへのネットワークトラフィックが暗号化されます。
この環境設定の利点 この設定は、次のような必要条件がある場合に適しています。
このアーキテクチャは複雑で、一般的なイントラネットサイトよりも維持することが困難です。しかし、説明したような利点を確保するには、このタイプのアーキテクチャを設定する必要があります。ダウンタイムはビジネスの損失となることがよくあります。適切に設計されたネットワークインフラストラクチャを維持することにより、すぐに相当の成果を得ることができます。
詳細情報 クラスタおよび負荷分散の詳細については、 を参照してください。
アプリケーションサーバによって、各クライアント接続についての情報が「セッションオブジェクト」に保存されます。セッションは、クライアントがサーバに最初に接続するときに開始されます。セッションオブジェクトの情報には、ユーザ認証などの情報が含まれます。また、アプリケーションによって、アプリケーション固有のデータがセッションオブジェクトに保存されます。サーブレットまたはJSPページに含まれるセッションは、アイドル状態が5分(デフォルト)を超えると終了されます。SMCを使用してセッションタイムアウト値を変更します(［Timeout on server request］値を設定します)。
［Timeout on server request］値の設定の詳細については、
パフォーマンスパラメータの設定を参照してください。
アプリケーションサーバによって、クッキーまたはURL再書き込みが使用され、複数のWebブラウザクライアントの状態を追跡できます。クッキーおよびURL再書き込みの両方によって、セッションIDが使用されます。ブラウザセッション内のサーバのすべての呼び出しは、同じセッションIDの下で動作します。セキュアデータの場合、認証は、ユーザ認証が必要とされるセッションのアクティブセッションにつき1回実行されます。
「認証」とは、サーバおよびクライアントが互いの識別情報を検証するプロセスです。認証については、 認証の有効化で説明されています。
ユーザのブラウザによってクッキーがサポートされている場合は、アプリケーションサーバによってクッキーが使用され、セッションが追跡されます。「クッキー」は、WebサーバからWebブラウザに送信される情報です。ブラウザクライアントによってクッキーが保存され、サーバに追加のリクエストが出されるごとにサーバに返信されます。アプリケーションサーバでは、クッキーはセッションIDとして使用されます。クッキーが含まれるクライアントからのリクエストがサーバによって受信されると、クッキーに保存されている情報を使用してセッションに再接続できます。
重要: アプリケーションサーバクッキーは、メモリに保存され、ディスクには書き込まれません。クッキーには、ユーザの個人情報および追跡情報は含まれていません。
クッキーのコンテンツについて心配な場合は、ブラウザによってクッキーを使用できないように設定するか、またはクッキーがある場合に警告が表示されるように設定できます。クッキーの詳細については、ブラウザのマニュアルを参照してください。
クッキーの使用が許可されていないブラウザをサポートするため、アプリケーションサーバによって、(追加のjsessionidパラメータがある) URLがリクエストをセッションに正しく関連付けるように再書き込みされます。サーブレットまたはJSPページを作成するアプリケーション開発者は、URL再書き込みを使用してクッキーを使用できないクライアントをサポートする方法を理解する必要があります。
サーブレットおよびJSPページのURL再書き込みの詳細については、次の
セッショントラッキングの仕組みを参照してください。
ユーザのブラウザでクッキーがサポートされている場合は、アプリケーションサーバによって「クッキー」が使用され、サポートされない場合は「URL再書き込み」が使用されます。これは、各ユーザのランタイム時に決定されます。リクエストがアプリケーションサーバによって初めて受信されると、クッキーが設定され、URLに「jsessionid」が追加されます(クライアントがクッキーをサポートしているかどうかまだわからないため)。
クライアントがクッキーをサポートしている場合、アプリケーションサーバによって、(「最初の」リクエスト受信時にURLは再書き込みされますが)セッショントラッキングにクッキーが使用されます。クライアントがクッキーを返信すると、サーバによって、このセッションのクライアントのURL再書き込みが停止されます。
注記: クッキーによって値「JSESSIONID」(すべて大文字)が使用され、URLによって「jsessionid」(すべて小文字)が使用されます。
管理者のメモ クライアントがクッキーをサポートしないことが決定された場合、ユーザがページ内のリンクをクリックするたびに、サーバによって、セショントラッキングのためにURLに「jsessionid」が使用されます。
クライアントが初めてセッションを確立すると、URL「jsessionid」はURLに追加され、クライアントユーザから見えるようになります。サーバとクライアント間のそれ以降の通信では、URL再書き込みによってセッションIDが追跡され、「jsessionid」は、ユーザのマウスがページ内のリンク上に置かれているときにのみ表示されます。
ブラウザクライアントがクッキーをサポートしない場合、HTMLリンクが使用されるサーブレットおよびJSPページによって、URL再書き込みの2つの標準エンコード方法のどちらか1つが呼び出される必要があります(次の 開発者のメモを参照)。
開発者のメモ 次のエンコード方法によって、サーバによるクッキーまたは「jsessionid」の存在のチェックが可能になります。
これらのエンコード方法の1つは、サーブレットまたはJSPページによって、明示的にURLが応答に作成されるまたは埋め込まれるときに必要です。
URLの「jsessionid」はパスパラメータであり、クエリパラメータではありません。「クエリパラメータ」は、通常URLの最後にあり、「?」で区切られます。「パスパラメータ」は、URLのコンポーネントの最後にあり、クエリパラメータより前にあります。次の例を参照してください。
http://server/db/foo;pparam=foo?qparam=bar&rparam=bar
この例では、「pparam」はパスパラメータで、「qparam」および「rparam」は両方ともクエリパラメータです。
|
|
管理ガイド 05/21/03 10:02:24 |
Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.
