test

Sun Java System Portal Server 7.1 配備計画ガイド

第 4 章 論理アーキテクチャーの設計

ソリューションライフサイクルの論理設計段階では、論理アーキテクチャーを作成します。論理アーキテクチャーでは、ソリューションの実装に必要なソフトウェアコンポーネント間の関係を識別します。

この章で説明する内容は次のとおりです。

論理アーキテクチャーの分析

高レベルの論理アーキテクチャーは、低レベルの論理アーキテクチャーの基になります。高レベルの論理アーキテクチャーは、事前に確定した業務および技術上の要件を満たす必要があります。論理アーキテクチャーは、システム全体を構成するさまざまなアプリケーションに従って、またユーザーがシステムと対話する方法に従って分解されます。一般に、論理アーキテクチャーには、Portal Server Secure Remote Access、高可用性、セキュリティー (Access Manager を含む)、および Directory Server アーキテクチャーコンポーネントが含まれます。

高レベルおよび低レベルのアーキテクチャーでは、ポータルの制御を超える要素、つまりネットワーク、ハードウェアの障害、不適切なチャネルの設計なども考慮する必要があります。

低レベルの設計では、物理アーキテクチャー、ネットワークインフラストラクチャー、ポータルデスクトップのチャネルおよびコンテナの設計、実際のハードウェアおよびソフトウェアのコンポーネントなどのアイテムを指定します。

高レベルの論理アーキテクチャー

高レベルの論理アーキテクチャーは、業務の要件と技術要件の両方をサポートします。高レベルの論理アーキテクチャーでは、次のような問いに答えます。

低レベルの論理アーキテクチャー

低レベルのアーキテクチャーでは、ポータルソリューションを構築するために使用するプロセスおよび標準の指定、また次のものを含む実際のハードウェアおよびソフトウェアコンポーネントの指定に焦点を合わせます。

Portal Server コンポーネント

Portal Server の配備は、次のコンポーネントで構成されます。

注 –

Portal Server でサポートされる製品の特定のバージョンについては、最新の Portal Server リリースノートを参照してください。

設計には、ポータルを構成するコンポーネントだけでなく、次のものを含めるようにしてください (ただし、次のものに限定されません)。

また、次の 3 つのネットワークゾーンがどのように設計に適合するかを考慮する必要があります。

論理アーキテクチャーは、また次のようなものを含む、ポータルデスクトップの見た目と使い心地を記述します。

サイトが必要とする場合、キャッシングの方針も論理アーキテクチャーに含めます。ユーザーに返されるページに多数のイメージへの参照が含まれる場合、Portal Server がそれらのイメージをすべてのユーザーに配信できます。ただし、それらのタイプの要求を逆プロキシタイプのキャッシング装置にオフロードできる場合、Portal Server が他のユーザーにサービスを提供できるようにシステムリソースを解放できます。また、キャッシング装置をエンドユーザーの近くに配置することによって、それらのイメージをエンドユーザーにいくらか速く配信することができるので、エンドユーザーの使い勝手がよくなります。

Secure Remote Access コンポーネント

このセクションでは、次の Secure Remote Access コンポーネントについて説明します。

Secure Remote Access ゲートウェイ

Secure Remote Access ゲートウェイはスタンドアロン Java プロセスです。状態情報をエンドユーザーにとって透過的に再構築することができるので、ステートレスと考えることができます。SRA ゲートウェイは、設定されたポートで待機し、HTTP 要求と HTTPS 要求を受け入れます。要求を受け取ると、セッションの有効性とヘッダー情報を確認して、要求のタイプを判別します。SRA ゲートウェイは要求のタイプに応じて次の処理を実行します。

すべてのゲートウェイ設定情報は、Access Manager の LDAP データベースにプロファイルとして保管されます。ゲートウェイプロファイルは、ゲートウェイに関連するすべての設定情報を含んでいます。

ホスト名や IP アドレスなどのマシン固有の情報は、ゲートウェイがインストールされているローカルファイルシステムの設定ファイルに保管されます。この情報により、複数のマシンで動作するゲートウェイどうしの間で 1 つのゲートウェイプロファイルを共有できます。

上述のとおり、SRA ゲートウェイは、HTTP モードと HTTPS モードの両方で同時に稼働するように設定できます。この設定により、イントラネットとエクストラネットの両方のユーザーが同じゲートウェイにアクセスできます。エクストラネットのユーザーは HTTPS を使用し、イントラネットのユーザーは SSL オーバーヘッドのない HTTP を使用します。

複数のゲートウェイインスタンス

必要に応じて、1 台のマシンで複数のゲートウェイインスタンスを実行できます。それぞれのゲートウェイインスタンスは、別々のポートで待機します。ゲートウェイインスタンスを設定して、同じ Portal Server インスタンスまたは異なる Portal Server インスタンスと通信できます。同じマシンのゲートウェイで複数インスタンスを実行する場合は、個別の証明書データベースをゲートウェイの各インスタンスに関連付け、そのゲートウェイをドメインにバインドすることができます。これにより各ドメインで異なるゲートウェイサーバーの証明書を使用でき、柔軟性が高まります。

複数の Portal Server インスタンス

注 –

ゲートウェイの前では、Netlet を使用しているのでないかぎりセッション固定は不要です。パフォーマンスは、セッション固定により向上します。一方、Portal Server インスタンスへのセッション固定は Secure Remote Access によって維持されます。

プロキシ

ゲートウェイは、ゲートウェイのプロファイルで指定されたプロキシを使用して、イントラネットとエクストラネット内部のさまざまな Web サーバーからコンテンツを取得します。プロキシは、ホストおよび DNS のサブドメインとドメインの専用にすることができます。ゲートウェイは、プロキシ設定に応じて適切なプロキシを使用し、要求されたコンテンツを取得します。プロキシで認証が要求される場合は、プロキシ名がゲートウェイプロファイルの一部として保管され、ゲートウェイはプロキシに接続する際にその名前を自動的に使用します。

ゲートウェイと HTTP 基本認証

ゲートウェイは基本認証をサポートするので、ユーザー ID とパスワードの入力を求めるプロンプトを表示しますが、ユーザーのコンピュータからサイトの Web サーバーまでの送信時にそれらの資格を保護しません送信する資格を保護するには、セキュリティー保護された HTTP 接続を確立する必要があり、通常はSSL を使用します。

Web サーバーが基本認証を要求する場合、クライアントはユーザー名とパスワードの入力を求めてプロンプトを表示し、要求しているサーバーに情報を送信します。HTTP 基本認証が有効なゲートウェイは、ユーザー名とパスワードの情報を捕捉し、その後に行われる認証とログインに備えて、それらの情報のコピーを Access Manager のユーザープロファイルに保存します。元のデータはゲートウェイから宛先 Web サーバーに送信され、基本認証が実行されます。Web サーバーはユーザー名とパスワードを検証します。

ゲートウェイにより、個々のホストでこの機能を拒否および許可する設定を細かく制御することもできます。

ゲートウェイと SSL サポート

SRA ゲートウェイは、HTTPS モードで動作するとき、SSL v2 と SSL v3 の両方の暗号化をサポートします。Portal Server 管理コンソールを使用して、特定の暗号化機能を有効または無効にできます。ゲートウェイは Transport Layer Security (TLS) もサポートします。

SSL v3 には、2 つの認証モードがあります。

Personal Digital Certificate (PDC) 認証は、SSL クライアント認証によってユーザーを認証するメカニズムです。ゲートウェイは、Access Manager 認証モジュールをサポートすることによって PDC 認証をサポートします。SSL クライアント認証を使用して、SSL ハンドシェークがゲートウェイで終了します。この PDC ベースの認証は、Access Manager の証明書ベースの認証とともに統合されます。したがってクライアント認証は、ゲートウェイによってではなく Access Manager によって処理されます。

セッション情報が HTTP または HTTPS 要求の一部として検出されない場合、ゲートウェイは、Access Manager からログイン URL を取得して、ユーザーを直接認証ページに誘導します。同様に、セッションが要求の一部として無効であることを検出すると、ゲートウェイはユーザーをログイン URL に誘導し、ログインが正常に行われるとユーザーを要求された宛先に誘導します。

SSL セッションが確立されると、ゲートウェイは送信されてくる要求を受信し続け、セッションの有効性を確認し、宛先の Web サーバーに要求を転送します。

ゲートウェイサーバーはすべての Netlet トラフィックを処理します。送信されてくるクライアント要求が Netlet トラフィックの場合、ゲートウェイはセッションの有効性を確認し、トラフィックを復号化して、アプリケーションサーバーに転送します。Netlet プロキシが有効な場合、ゲートウェイはセッションの有効性を確認して、Netlet プロキシに転送します。Netlet プロキシはトラフィックを復号化してアプリケーションサーバーに転送します。

注 –

40 ビットの暗号化は安全性が低いので、ゲートウェイには、40 ビット暗号化ブラウザからの接続を拒否するためのオプションが用意されています。

ゲートウェイのアクセス制御

ゲートウェイは、許可される URL リストと拒否される URL リストを使用してアクセス制御を実施します。URL のアクセスが許可されている場合でも、ゲートウェイは、Access Manager セッションサーバーと照会してセッションの有効性を確認します。許可される URL リストと拒否される URL リストと同様、非認証 URL リストにある URL はセッション検証を省略します。拒否される URL リストのエントリは、許可される URL リストのエントリよりも優先されます。特定の URL がいずれかのリストに記載されていない場合、その URL に対するアクセスは拒否されます。許可される URL リストと拒否される URL リストのどちらの場合でも、URL の一部としてワイルドカード文字 * も使用できます。

ゲートウェイのロギング

ゲートウェイでのロギングを有効にすることにより、ユーザーの動作をすべて監視できます。ゲートウェイは Portal Server ロギング API を使用してログを作成します。

ゲートウェイでのアクセラレータの使用

専用ハードウェアコプロセッサであるアクセラレータを設定して、サーバーの CPU から SSL 機能の負荷を取り除くことができます。アクセラレータを使用すると、CPU をほかのタスクに振り分けられるようになり、SSL トランザクションの処理速度が向上します。

Netlet

Netlet により、イントラネットで使用可能な固定ポートアプリケーションと一部の動的ポートアプリケーションに対するイントラネットの外部からのアクセスをセキュリティー保護します。クライアントは、リモートファイアウォールと SSL プロキシの背後に配置することも、直接インターネットに接続することもできます。Netlet を介して、イントラネットの外部からイントラネットアプリケーションにセキュリティー保護して確立される接続は、Netlet ルールに従って制御されます。

ブラウザで動作する Netlet アプレットにより、リモートクライアントマシンとリモートホストのイントラネットアプリケーションの間で、暗号化された TCP/IP トンネルが設定されます。Netlet は事前設定されたポートで待機して接続を受け入れ、クライアントと宛先サーバーの間で送受信されるトラフィックを経路指定します。送受信される両方のトラフィックは、ユーザーが選択した、または管理者によって設定された暗号化アルゴリズムによって暗号化されます。Netlet ルールには、接続で使用されるすべてのサーバー、ポート、および暗号化アルゴリズムに関する詳細が記述されています。管理者は、Portal Server 管理コンソールを使用して Netlet ルールを作成します。

静的および動的なポートアプリケーション

静的ポートアプリケーションは、既知つまり静的ポートで動作します。たとえば、IMAP や POP サーバー、Telnet デーモン、jCIFS などがあります。静的ポートアプリケーションの場合は、Netlet ルールに宛先サーバーポートが記述されているので、要求を直接宛先に経路指定できます。

動的アプリケーションは、ハンドシェークの一部で通信用ポートについて同意します。宛先サーバーポートを Netlet ルールの一部にすることもできます。Netlet は、プロトコルを理解し、データを調べて、クライアントとサーバーの間で使用されるポートを検出する必要があります。FTP は動的ポートアプリケーションです。FTP の場合、クライアントとサーバー間の実際のデータ転送用ポートは、PORT コマンドによって指定されます。この場合、Netlet はトラフィックをパースして、動的にデータチャネルポートを取得します。

現行では、FTP と Microsoft Exchange だけが、Portal Server によってサポートされる動的ポートアプリケーションです。

注 –

Microsoft Exchange 2000 は Netlet によってサポートされていますが、以下の制約があります。

Netlet とアプリケーション統合

Netlet は、Graphon、Citrix、pcAnywhere などの多くのサードパーティー製品で動作します。それらの各製品は、リモートマシンからユーザーのポータルデスクトップへのアクセスを Netlet を使用してセキュリティー保護します。

スプリットトンネリング

スプリットトンネリングにより、VPN クライアントは、VPN に接続または VPN から切断することなく、セキュリティー保護されたサイトおよびセキュリティー保護されていないサイトの両方に接続できます。この場合の VPN は Netlet です。クライアントは、暗号化パスを通して情報を送信するか、または非暗号化パスを使用して送信するかどうかを判別します。スプリットトンネリングの問題点は、セキュリティー保護されていないインターネットから、クライアントを介して VPN によるセキュリティー保護ネットワークに直接接続が可能であることです。スプリットトンネリングをオフにすると両方の接続が同時に許可されることがなくなり、インターネット侵入に対する VPN 接続 (この場合は Netlet 接続) の脆弱性が低減します。

Portal Server は、ポータルサイトに接続されている間、複数のネットワーク接続を禁止したりシャットダウンしたりしませんが、権限のないユーザーが他のユーザーのセッションに便乗 (piggybacking) する行為を次の方法で阻止します。

Netlet プロキシ

Netlet プロキシは、ゲートウェイと宛先ホストを接続するために、ファイアウォールで開く必要のあるポート数を少なくするのに役立ちます。

たとえば、イントラネット内部で多数の Telnet、FTP、および Microsoft Exchange サーバーを接続するために、Netlet を必要とする設定について考えてみます。ゲートウェイは DMZ 内にあると仮定します。ゲートウェイがトラフィックをすべての宛先サーバー向けて経路指定する場合は、第 2 ファイアウォールでかなりの数のポートを開いておく必要があります。この問題を軽減するため、第 2 ファイアウォールの背後に Netlet プロキシを配置し、Netlet プロキシにトラフィックを転送するようにゲートウェイを設定できます。その後、Netlet プロキシがすべてのトラフィックをイントラネット内のすべての宛先サーバーに経路指定するので、第 2 ファイアウォールで開く必要のあるポート数を減らすことができます。また、第 2 ファイアウォールの背後に複数の Netlet プロキシを配置して、シングルポイント障害を回避することもできます。

サードパーティーのプロキシを使用して第 2 ファイアウォールのポートを 1 つだけ使用することも可能です。

注 –

Netlet プロキシを別のノードにインストールすると、Netlet トラフィックの負荷が別のノードに分散されるので、Portal Server の応答時間を短くすることができます。

NetFile

NetFile により、企業のイントラネット内部にセキュリティー保護されて常駐するファイルシステムに、リモートアクセスして操作することができます。

NetFile は、NFS、jCIFS、および FTP などの標準プロトコルを使用して、ユーザーがアクセス権を持つすべての UNIX または Microsoft Windows ファイルシステムに接続します。NetFile を使用して、ファイル管理アプリケーションで一般的なほとんどのファイル操作を実行できます。

コンポーネント

さまざまなファイルシステムにアクセスするため、NetFile には 3 つのコンポーネントが組み込まれています。

NetFile は国際化されているので、ロケール (文字エンコード) に関係なくファイルシステムにアクセスできます。

NetFile は、Access Manager を使用して、NetFile 自体のプロファイル、ユーザー設定、および優先設定を保存します。NetFile は、Portal Server 管理コンソールを使用して管理します。

初期化

Portal Server デスクトップでユーザーが NetFile リンクを選択すると、NetFile サーブレットは、ユーザーが有効な SSO トークンを持ち、NetFile を実行する権限を持っているかどうかを確認します。有効なトークンと権限を確認できると、アプレットがブラウザにレンダリングされます。NetFile アプレットは、もう一度サーブレットに接続して、サイズ、ロケール、リソースバンドル、およびユーザー設定と優先設定など、それ自体の設定情報を取得します。NetFile は、ユーザーの SSO トークンを使用して、ロケール情報と、ユーザー名、メール ID、およびメールサーバーなどの他のユーザー情報を取得します。ユーザー設定には、ユーザーが組織またはロールから継承した設定、ユーザーによってカスタマイズされた設定、および前の NetFile セッションを終了するときにユーザーが保存した設定などがあります。

資格の検証

NetFile は、ユーザーによって入力される資格を使用して、ファイルシステムへのアクセスを許可する前にユーザーを認証します。

資格には、ユーザー名、パスワード、および Microsoft Windows または Novell のどちらか該当するドメインなどがあります。それぞれの共有では独立パスワードを使用するので、ユーザーは共通ホストを除き、すべての追加する共有ごとに自分の資格を入力する必要があります。

NetFile は、Access Manager から UNIX 認証を使用して、NFS ファイルシステムへのアクセス権を与えます。FTP プロトコルと jCIFS プロトコルに従ってアクセスするファイルシステムの場合は、プロトコル自体が備える手法を使用して資格を検証します。

アクセス制御

NetFile は、さまざまな方法でファイルシステムのアクセス制御を行います。プロトコルに基づいて、特定のファイルシステムへのユーザーのアクセスを拒否できます。たとえば、NFS によってのみアクセス可能なファイルシステムへの特定のユーザー、ロール、または組織のアクセスを拒否できます。

NetFile を設定し、組織からサブ組織、およびユーザーにいたるまでのすべてのレベルで、ファイルシステムへのアクセスを許可または拒否できます。また、特定のサーバーへのアクセスを許可または拒否することも可能です。ユーザーのファイルシステムへのアクセスは、Microsoft Windows、FTP、NFS、および NetWare を介した FTP などのホストのタイプに応じて許可または拒否できます。たとえば、組織のすべてのユーザーに対し Microsoft Windows ホストへのアクセスを拒否できます。また、組織またはロールのレベルで共通ホストのセットを指定し、その組織またはロールのすべてのユーザーが共通ホストにアクセスできるようにして、ユーザーが各組織またはロールのすべてに自分を追加する必要をなくすこともできます。

NetFile サービスの一部として、許可される URL リストまたは拒否される URL リストを設定し、組織、ロール、またはユーザーのレベルでサーバーへのアクセスを許可または拒否できます。拒否される URL リストは、許可される URL リストよりも優先されます。許可される URL リストと拒否される URL リストには、ワイルドカード文字 * を使用して、同一ドメインまたはサブドメイン内のサーバーセットへのアクセスを許可または拒否できます。

セキュリティー

SSL 対応の Secure Remote Access を有効にして NetFile を使用すると、NetFile アプレットから背後のファイルシステムへのすべての接続は、ゲートウェイとブラウザの間に確立された SSL 接続を使用して実行されます。通常は、ゲートウェイを DMZ に設置し、第 2 ファイルウォールで開くポートの数を制限する (通常は 1 つのみ) ので、ファイルシステムへのアクセスを許可してもセキュリティーは低下しません。

特殊操作

NetFile は、一般的なファイル管理アプリケーションと同様、リモートファイル管理アプリケーションに適した機能セットを備えています。NetFile によりユーザーは、ローカルとリモートのファイルシステムの間でファイルをアップロードまたはダウンロードできます (共有)。ローカルからリモートファイルシステムにアップロードするファイルのサイズは、Portal Server 管理コンソールを使用して制限できます。

またユーザーは、複数のファイルを選択し、GZIP および ZIP で圧縮することも可能です。複数のファイルを選択し、複数の添付ファイルとして 1 通の電子メールで送信できます。NetFile は、Access Manager の SSO トークンを使用し、IMAP サーバー、ユーザー名、パスワード、および返信アドレスなどのユーザーの電子メール設定にアクセスして、電子メールを送信します。

NetFile ウィンドウのファイルをダブルクリックすると、MIME タイプに対応したアプリケーションが起動し、ファイルが開きます。NetFile には、一般的なほとんどのファイルタイプ (拡張子) をマッピングしたデフォルトの MIME タイプ設定ファイルと、編集して新規マッピングを追加できる MIME タイプがあります。

NetFile を使用してファイルを検索し、別のウィンドウにリストを表示できます。各検索結果は、以前の検索結果のウィンドウを表示した状態で、新規ウィンドウに表示されます。特定の共有で使用される文字エンコードのタイプはユーザーが設定でき、共有の設定項目の一部になっています。文字エンコード方法を指定しないと、共有機能で動作する間、NetFile は ISO-8859-1 を使用します。ISO-8859-1 エンコードは、ほとんどの共通言語を処理することができます。ISO-8859-1 エンコードにより、NetFile は任意の言語でファイルのリストを作成し、内容を破壊せずに任意の言語でファイルを変換できます。

NetFile は、ファイルを電子メールで送信する場合にのみ、NetFile Java 1 と Java 2 の両方で一時ファイルを作成します。一時ファイルは、Microsoft Windows ファイルシステムとローカルシステムファイルの間で、jCIFS プロトコルによってファイルをアップロードおよびダウンロードする時には作成されません。

注 –

NetFile は、ディレクトリとリモートファイルの削除をサポートします。リモートディレクトリ内のすべての内容は、再帰的に削除されます。

NetFile とマルチスレッド化

NetFile では、マルチスレッドを使用して、複数の操作を同時に実行する際の柔軟性を高めています。たとえば、ユーザーは検索操作を行い、ファイルのアップロードを開始して、電子メールでファイルを送信できます。NetFile はこれら 3 つの操作を同時に実行し、さらにユーザーがファイルのリストを参照することを許可します。

リライタ

リライタは、HTML と JavaScript コードの両方ですべての URI を変換し、イントラネットのコンテンツを常にゲートウェイを通して取得できるようにする独立コンポーネントです。ルールの集合であるルールセットを定義し、ページにリライトする必要のあるすべての URL を特定します。ルールセットは、Document Type Definition (DTD) に従って記述される XML コードです。リライタに付属する一般ルールセットを使用すれば、ルールを追加せずにほとんどの URL をリライトできます。ルールセットをドメインに関連付け、ドメインベースの変換も実行できます。

外部ルールセットはコンテンツの URI を識別します。Secure Remote Access によるサービスを必要とする要求はすべて、次の経路で処理されます。

ProcedureSecure Remote Access 要求の経路を指定する

  1. Secure Remote Access は、サービスを必要とするイントラネットページまたはインターネットページの URI を要求から特定します。

  2. Secure Remote Access は、プロキシ設定を使用して特定された URI に接続します。

  3. URI のドメインは、このコンテンツをリライトするために使用するルールセットを特定するために使用されます。

  4. コンテンツとルールセットを取得すると、Secure Remote Access はそれらの情報をリライタに入力し、特定された URI はそこで変換されます。

  5. 元の URI はリライトされた URI によって置き換えられます。

  6. このプロセスがドキュメントの最後まで繰り返されます。

  7. 生成されたリライタ出力は、ブラウザに経路指定されます。

リライタプロキシ

ファイアウォールで開くポート数を最小限に抑えるには、リライタプロキシを使用します。リライタプロキシをインストールすると、HTTP 要求は、宛先ホストに直接送信される代わりに、リライタプロキシにリダイレクトされます。次にリライタプロキシは、受け取った要求を宛先サーバーに送信します。

リライタプロキシを使用すると、ゲートウェイとイントラネットコンピュータの間の HTTP トラフィックをセキュリティー保護し、次の 2 つの利点を生かすことができます。

注 –

複数のリライタプロキシを稼働させれば、シングルポイント障害を防止し、ロードバランスを実現できます。

プロキシレット

プロキシレットは、クライアントマシン上で稼働する動的なプロキシサーバーです。プロキシレットは URL をゲートウェイにリダイレクトします。プロキシレットは、この機能を実現するために、クライアントマシン上のブラウザのプロキシ設定を読み込んでから、その設定がローカルプロキシサーバー ( プロキシレット) をポイントするように変更します。

プロキシレットでは、HTTP および SSL がサポートされ、ゲートウェイのトランスポートモードが継承されます。ゲートウェイが SSL に基づいて動作するように設定されている場合には、クライアントマシンとゲートウェイ間のチャネルのセキュリティーが確保されます。クライアントの JVM が 1.4 以降の場合または必要な jar ファイルがクライアントマシン上にある場合には、Java 2 Enterprise Edition API が使用されます。それ以外の場合には、KSSL API が使用されます。

プロキシレットは、クライアントの IP アドレスとポートが指定されている Portal Server 管理コンソールから有効にします。

プロキシレットは、リライタと異なり、インストール後の変更をほとんどまたはまったく必要としません。また、プロキシレットは Web コンテンツを処理しないので、ゲートウェイのパフォーマンスが向上します。

Portal Server ノード

必ずではありませんが、通常は、以下のさまざまなポータルノード (サーバー) Portal Server ソフトウェアを配備して、連携動作することによってポータルを実装します。

異なるノードにある Portal Server と Access Manager

Portal Server と Access Manager は異なるノードに置くことができます。このタイプの配備には、次の利点があります。

注 –

Portal Server と Access Manager を異なるノードに置く場合、Access Manager SDK は Portal Server と同じノードに存在する必要があります。Web アプリケーションとサポートする認証デーモンは、Portal Server インスタンスとは別のノードに置くことができます。

Access Manager SDK は、次のコンポーネントから構成されています。

Portal Server システムの通信リンク

図 4–1 は、ソリューションの可用性に重要な Portal Server システムのプロセスおよび通信リンクを示しています。

図 4–1 Portal Server の通信リンク

この図では、Portal Server インスタンスに 5 つのサーブレットと 3 つの SDK が含まれており、それらが相互に通信する様子が示されています。

この図では、Web Server 技術で稼働する Portal Server インスタンスがボックスで囲まれています。このインスタンスには、5 つのサーブレット (認証、Portal Server 管理コンソール、ポータルデスクトップ、通信チャネル、および検索) と 3 つの SDK (Access Manager SSO、Access Manager ロギング、および Access Manager 管理) が含まれています。認証サービスサーブレットは、LDAP サービスプロバイダモジュールも利用します。

ユーザートラフィックは、適切なサーブレットにダイレクトされます。通信は、認証サービスの LDAP モジュールと LDAP 認証サーバー間、通信チャネルサーブレットと SMTP/IMAP メッセージングサーバー間、Access Manager SSO SDK と LDAP サーバー間、Access Manager 管理 SDK と LDAP サーバー間で行われます。

図 4–1 は、次のプロセスまたは通信リンクに障害が発生すると、エンドユーザーがポータルソリューションを利用できなくなることを示しています。

Portal Server 論理アーキテクチャーの例

このセクションでは、Portal Server の論理アーキテクチャー例をいくつか説明します。

標準的な Portal Server のインストール

図 4–2 は、ポータル配備のコンポーネントをいくつか図示していますが、実際の物理ネットワーク設計、シングルポイント障害、または高可用性については説明していません。

この図は、企業サイトにインストールされた標準的な企業対社員用ポータルの高レベルアーキテクチャーを示しています。この図では、プロキシ/キャッシュサーバー、Web サーバー、メールゲートウェイなどのインターネットからアクセス可能なほかのシステムと一緒に、ゲートウェイが企業の非武装ゾーン (DMZ) に配置されています。ポータルノード、ポータル検索ノード、およびディレクトリサーバーは、個々の社員のデスクトップシステムから旧バージョンのシステムにいたるまで、ユーザーがアクセス可能なシステムやサービスが存在する内部ネットワークに配置されています。

注 –

独自のポータルを希望するビジネスの顧客ごとに別々の Portal Server インスタンスをホストする ISP ホスティングの配備を設計している場合は、Sun Java System の担当者にご連絡ください。Portal Server は、ISP ホスティング機能を提供するためにカスタマイズする必要があります。

図 4–2 では、インターネットのユーザーがブラウザからゲートウェイにアクセスします。ゲートウェイは、ユーザーがアクセスしようとしているポータルの IP アドレスとポートにユーザーを接続します。たとえば、B2B ポータルは通常、HTTPS ポートである 443 番ポートにのみアクセスを許可します。ゲートウェイは、認証された使用法に応じて、要求をポータルノードに転送するか、企業の内部ネットワークのサービスに直接転送します。

図 4–2 企業対社員用ポータルの高レベルアーキテクチャー

この図は、Secure Remote Access サービスを使用した Portal Server の配備を示しています。

図 4–3 は、Secure Remote Access サービスを使用した Portal Server の配備を示しています。

図 4–3 Secure Remote Access の配備

プロキシレット、ゲートウェイ、Netlet、Netlet プロキシ、リライタプロキシなどのSecure Remote Access サービスを使用した Portal Server の配備を示しています。

Portal Server の構築モジュール

Portal Server の配備は多くの他のシステムも関係する複雑な処理であるため、ここでは最高のパフォーマンスと水平方向のスケーラビリティーを提供する特定の構成について説明します。この構成は、Portal Server 構築モジュールと呼ばれます。

Portal Server 構築モジュールは、共有サービスに限定的に依存、またはまったく依存しないハードウェアおよびソフトウェアの構成です。一般的な配備では、複数の構築モジュールを使用して、最高のパフォーマンスと水平方向のスケーラビリティーを実現します。図 4–4 は、構築モジュールのアーキテクチャーを示しています。

図 4–4 Portal Server 構築モジュールのアーキテクチャー

この図は、Portal Server インスタンス、Directory Server マスターレプリカ、および検索エンジンで構成される構築モジュールアーキテクチャーを示しています。

注 –

Portal Server 構築モジュールは、単なる推奨構成です。場合によっては、別の構成のほうがスループットが若干よくなることがあります。この場合、一般的に構成はより複雑になります。たとえば、4 CPU システムに Portal Server の別のインスタンスを追加すると、スループットが最高 10 % 向上する可能性がありますが、単一システムのみを使用する場合でもロードバランサを追加する必要があるという代償を払う必要があります。

構築モジュールと高可用性のシナリオ

Portal Server は、高可用性に関して次の 3 つのシナリオを提供します。

サポート可能なアーキテクチャーを次に示します。

ここでは、高可用性の観点から、これらのアーキテクチャーの実装方法について、また構築モジュール概念を活用する方法について説明します。

表 4–1 は、これらの高可用性シナリオと、シナリオをサポートする技術の要約です。

表 4–1 Portal Server 高可用性シナリオ

コンポーネントの要件 

ベストエフォート配備に必要ですか ? 

NSPOF 配備に必要ですか ? 

透過フェイルオーバー配備に必要ですか ?  

冗長ハードウェア

はい 

はい 

はい 

Portal Server の構築モジュール 

いいえ 

はい 

はい 

マルチマスター構成

いいえ 

はい 

はい 

ロードバランス 

はい 

はい 

はい 

ステートレスなアプリケーションとチェックポイントメカニズム

いいえ 

いいえ 

はい 

セッションのフェイルオーバー

いいえ 

いいえ 

はい

Directory Server クラスタ

いいえ 

いいえ 

はい 

注 –

ロードバランスは、Sun JavaTM System Web Server 製品では出荷時の状態では提供されていません。

ベストエフォート

このシナリオでは、可用性が続くように、Sun Fire UltraSPARCTM III マシンなどの、ハードウェアが保護された単一ノードに Portal Server と Directory Server をインストールします。SolarisTM オペレーティング環境システムを保護するには、デフォルトの設定を変更する必要があります。

このタイプのサーバーではハードウェアが完全に冗長であり、次のものを備えています。冗長電源、冗長ファン、冗長システムコントローラ、動的再構成、CPU ホットプラグ、オンラインアップグレード、および RAID 0+1 (ストラインピングにミラーリングもプラス) またはボリューム管理システムを使用する RAID 5 で構成できるディスクラック (ディスククラッシュ発生時にデータが失われるのを防止する)。図 4–5 は、構築モジュールのアーキテクチャーを使用する、小規模のベストエフォート配備を示しています。

図 4–5 ベストエフォートのシナリオ

この図は、4 CPU 構成のベストエフォートシナリオを示しています。

このシナリオでは、1 つの構築モジュールには、メモリーの割り当ては 4 CPU × 8G バイト RAM (4 × 8) で十分です。Portal Server コンソールは、ほかのリソースと共有できるように構築モジュールの外にあります。実際のサイズの計算結果は、これとは異なる割り当て量になる場合があります。

このシナリオは、タスククリティカルな要件には十分です。このシナリオの主な弱点は、システムのシャットダウンが必要な保守作業によってサービスが中断されるということです。

Secure Remote Access を使用している場合に、ソフトウェアのクラッシュが発生すると、watchdog プロセスがゲートウェイ、Netlet プロキシ、およびリライタプロキシを自動的に再起動します。

ノーシングルポイント障害

Portal Server は、ノーシングルポイント障害 (NSPOF) シナリオを基本機能としてサポートしています。NSPOF は、ベストエフォートシナリオをベースにし、それに加えてレプリケーションとロードバランスを採り入れています。

図 4–6 は、Portal Server インスタンス、プロファイルの読み込みのための Directory Server レプリカ、および検索エンジンのデータベースから構成されている構築モジュールを示しています。そのため、NSPOF を実現するには少なくとも 2 つの構築モジュールが必要であり、それによって構築モジュールのどちらかに障害が発生した場合のバックアップを提供します。これらの構築モジュールは、4 CPU × 8G バイト RAM で構成されます。

図 4–6 ノーシングルポイント障害の例

この図は、Portal Server インスタンス、Directory Server レプリカ、および検索エンジンで構成される 2 つの構築モジュールを示しています。

ロードバランサが Portal Server の障害を検出すると、ユーザーの要求をバックアップ構築モジュールにリダイレクトします。障害検出の正確さは、ロードバランス製品によって異なります。一部の製品は、サーバーのいくつかの機能領域に関係するサービス、たとえばサーブレットエンジンや JVM を検索することによってシステムの可用性を確認できます。特に、Resonate、Cisco、Alteon、およびその他のほとんどのベンダーソリューションを使用する場合は、ユーザーがサーバーの可用性のためのスクリプトを任意に作成できます。ロードバランサは Portal Server ソフトウェアの一部ではないので、サードパーティーベンダーから個別に入手する必要があります。

注 –

Access Manager は、セッション固定を実施するためにロードバランス を設定することを要求します。これは、特定のインスタンスに対するセッションを確立すると、ロードバランサはそのセッションのために常に同じインスタンスに戻る必要があります。ロードバランサは、セッション cookie にインスタンスの識別名をバインドすることによってこれを実現します。原則としては、障害が発生したインスタンスを終了したときに、そのバインドは再設定されます。セッション固定は、パフォーマンス上の理由からも推奨します。

マルチマスターレプリケーション (Multi-master replication、MMR) は、構築モジュール間で行われます。各ディレクトリで発生する変更は他のディレクトリにレプリケートされます。つまり、各ディレクトリがサプライヤとコンシューマの両方の役割を果たします。MMR の詳細については、『Sun Java System Directory Server 配備計画ガイド』を参照してください。

注 –

一般に、各構築モジュール内の Directory Server インスタンスは、ほかの場所で実行されるマスターディレクトリのレプリカとして構成されます。ただし、マスターディレクトリを構築モジュールの一部として使用するのを妨げるものはありません。専用ノードでマスターを使用しても、ソリューションの可用性は向上しません。専用マスターは、パフォーマンスのために使用します。

構築モジュール間でのコンシューマレプリケーションを伴う、管理コンソールまたはポータルデスクトップを使用したプロファイルの変更を常に維持できるように、冗長性もディレクトリマスターにとって同じように重要です。Portal Server と Access Manager は、MMR をサポートします。NSPOF シナリオは、マルチマスター構成を使用します。この構成では、2 つのサプライヤが更新を受け入れること、互いに同期をとること、またすべてのコンシューマを更新することが可能です。コンシューマは、更新要求を両方のマスターに任せることができます。

Secure Remote Access は、NSPOF を実現するために Portal Server と同様にレプリケーションとロードバランスを採用します。そのため、このシナリオでは 2 つの Secure Remote Access ゲートウェイとプロキシのペアが必要になります。Secure Remote Access ゲートウェイは、特定のタイムアウト値後、要求に対して Portal Server インスタンスが応答しない場合に、Portal Server インスタンスの障害を検出します。これが発生すると、HTTPS 要求はバックアップサーバーにルーティングされます。Secure Remote Access ゲートウェイは、最初の Portal Server インスタンスが再び稼働するまで定期的に可用性を確認します。

NSPOF の高可用性シナリオは、ビジネスクリティカルな配備に適しています。しかし、このシナリオの高可用性の制限の一部は、ミッションクリティカルな配備の要件を満たさない場合があります。

透過フェイルオーバー

透過フェイルオーバーは、NSPOF シナリオと同じレプリケーションモデルを使用しますが、追加の高可用性機能があり、これによってエンドユーザーに透過なバックアップサーバーにフェイルオーバーが行われます。

図 4–7 は、透過フェイルオーバーのシナリオを示しています。4 CPU × 8G バイト RAM から構成される 2 つの構築モジュールを示しています。ロードバランスは、Portal Server の障害を検出し、構築モジュール内のバックアップ Portal Server に要求をリダイレクトする責任があります。構築モジュール 1 は、セッションをセッションリポジトリに格納します。クラッシュが発生した場合、アプリケーションサーバーは構築モジュール 1 が作成したセッションをセッションリポジトリから取得します。

図 4–7 透過フェイルオーバーの例のシナリオ

この図は、透過フェイルオーバーのシナリオを示しています。ロードバランサは、2 つの構築モジュールの前面にあります。

セッションリポジトリは、アプリケーションサーバーソフトウェアで提供されます。Portal Server は、アプリケーションサーバーで稼働します。Portal Server は、HttpSession フェイルオーバーをサポートするアプリケーションサーバーで透過フェイルオーバーをサポートします。詳細は、付録 A 「Portal Server とアプリケーションサーバーの理解」を参照してください。

セッションフェイルオーバーを使用すると、クラッシュ発生後にユーザーを再認証する必要はありません。また、ポータルアプリケーションは、セッションが固定されるという前提で、チェックポイントで使用するコンテキストデータを保存できます。AMConfig.properties ファイルで com.iplanet.am.session.failover.enabled property を true に設定することによって、セッションのフェイルオーバーを設定できます。

Netlet プロキシは、TCP プロトコルの制限により透過フェイルオーバーシナリオをサポートできません。Netlet プロキシは、TCP 接続をトンネルし、オープンな TCP 接続を別のサーバーに移すことはできません。Netlet プロキシのクラッシュによって、再確立する必要があるすべての未処理の接続がなくなります。

構築モジュールソリューションの推奨事項

ここでは、構築モジュールソリューションを配備するためのガイドラインを説明します。

構築モジュールの構築方法によってはパフォーマンスに影響します。

構築モジュールを適切に配備するためには、次に示す推奨事項を考慮してください。

Directory Server

構築モジュールを配備するための Directory Server の要件を確認します。Directory Server の配備の特定の情報は、『Directory Server 配備計画ガイド』を参照してください。

Portal Server の配備を計画する際には、次に示す Directory Server のガイドラインを考慮してください。

LDAP

構築モジュールのスケーラビリティーは、プロファイルの更新によって生じる LDAP の書き込みの数と LDAP データベースの最大サイズによります。

注 –

/tmp ディレクトリに _db ファイルがある場合に LDAP サーバーがクラッシュすると、サーバーが再起動するときにこのファイルは失われます。これはパフォーマンスを向上させますが、可用性にも影響します。

特定のサイトの分析結果が、LDAP の書き込み操作が実際に制約となっていることを示す場合は、この問題の解決策として、受信要求をポータルの適切なインスタンスに転送するディレクトリの特定の分岐とその前にある層のみをレプリケートする構築モジュールを作成することができます。

検索サービス

検索エンジンを構築モジュールソリューションの一環として配備するときには、次の点を考慮してください。

別々のノードに存在する Access Manager と Portal Server

図 4–8 は、別々のノードに存在する Access Manager と Portal Server を示しています。

図 4–8 別々のノードに存在する Access Manager と Portal Server

この図は、別々のノードに存在する Access Manager と Portal Server を示しています。

Portal Server と Access Manager を分けて実装すると、次の 3 つの図が示すようなポータルサービスアーキテクチャーの配備に対する他のトポロジの並びが可能になります。

2 つの Portal Server と 1 つの Access Manager

図 4–9 は、1 つの Access Manager および 2 つの Directory Server と機能するように構成された 2 つの Portal Server インスタンスを示しています。ここでは、Access Manager と Directory Server の両方が Java Enterprise System Sun Cluster 環境で動作します。この構成は、Access Manager インスタンスと Directory Server インスタンスが障害でない場合に理想的です。

図 4–9 2 つの Portal Server と 1 つの Access Manager

この図は、1 つの Access Manager および 2 つの Directory Server と機能するように構成された 2 つの Portal Server インスタンスを示しています。

2 つの Portal Server と 2 つの Access Manager

図 4–10 は、水平方向のサーバーファームによって実現された最大の水平方向のスケーラビリティーと、より高い可用性の構成を示しています。最大のスループットと高可用性の実現のために、2 つの Portal Server の前にロードバランサを置くことができます。

別のロードバランサを、Portal Server と Access Manager の間に置いて、認証プロセスとポリシープロセスが高可用性のための負荷の分散とフェイルオーバーの手段となるようにできます。

このシナリオでは、Portal サービスに Blade 1500s を利用して負荷を分散し、これと似た Blade を使用して Access Manager サービスと Directory サービスのそれぞれをホストできます。図 4–10 に示されたアーキテクチャーでは、製品スタックのそれぞれに冗長のサービスが存在するので、計画外の停止時間を最小限に、またはなくすことがで きます。

ただし、予定された停止時間は依然問題になります。アップグレードまたはパッチに Access Manager ソフトウェアが使用する Directory Server ソフトウェアスキーマの変更が含まれる場合、Directory Server に格納されたスキーマ情報を更新するためにこのソフトウェアのすべてのコンポーネントを停止する必要があります。ただし、スキーマ情報の更新は、ほとんどのパッチアップグレードではめったに発生しないとみなすことができます。

図 4–10 2 つの Portal Server と 2 つの Access Manager

この図は、水平方向のサーバーファームを示しています。最大のスループットと高可用性の実現のために、2 つの Portal Server の前にロードバランサを置きます。

1 つのロードバランサと 2 つの Access Manager

図 4–11 は、Portal Server からの認証スループットを 2 つの Access Manager にロードバランスすることを可能にする構成を示しています。

この構成は、Portal Server が広い帯域幅のネットワーク接続を備えたハイエンドの中規模から大規模のサーバー (つまり 1 〜 4 個のプロセッサ) に存在するときに実現できます。ポリシーサービスと認証サービスを提供する Access Manager は、2 つの中規模のサーバーに置くことができます。

図 4–11 2 つのアクセスマネージャーにロードバランスする

この図 は、2 つの Access Manager にロードバランスされる Portal Server からの認証スループットを示しています。

Secure Remote Access 論理アーキテクチャーの例

Secure Remote Access ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティーバリアとして機能します。ゲートウェイには、次の 2 つの主な機能があります。

インターネットアクセスの場合、128 ビット SSL を使用して、ユーザーのブラウザとPortal Server 間の最高のセキュリティー対策と暗号化、または通信を実現します。ゲートウェイ、Netlet、NetFile、Netlet プロキシ、リライタプロキシ、およびプロキシレットが Secure Remote Access の主なコンポーネントです。

ここでは、それらのコンポーネントの可能な構成をいくつか示します。このセクションでは、指針を示すだけで、完全な配備の参考情報を提供するわけではありません。業務のニーズに基づいて構成を選択してください。

ヒント –

authlessanonymous ページをゲートウェイ経由で表示するように設定するには、ゲートウェイプロファイルの非認証 URL に /portal/dt を追加します。ただし、これは、普通のユーザーの場合でも、ポータルページは認証を必要とせず、セッションの検証が実行されないことを意味します。

基本 Secure Remote Access 構成

図 4–12 は、Secure Remote Access のもっとも単純な構成を示しています。この図では、クライアントのブラウザが NetFile および Netlet を実行しています。ゲートウェイは、2 つのファイアウォールの間の DMZ 内の個別のマシンにインストールされています。Portal Server は、イントラネット内の 2 番目のファイアウォールの外側に置かれています。クライアントがアクセスする他のアプリケーションホストも、イントラネット内の 2 番目のファイアウォールの外側に置かれています。

ゲートウェイは、DMZ 内にあり、ファイアウォール内の開いた外部ポートを通してクライアントのブラウザがゲートウェイと通信します。2 番目のファイアウォールでは、HTTP または HTTPS トラフィックのために、ゲートウェイは内部ホストと直接通信できます。セキュリティーポリシーがこれを許可しない場合は、ゲートウェイと内部ホストとの間に Secure Remote Access プロキシを使用します。Netlet トラフィックの場合、ゲートウェイから目的のホストへの直接接続になります。

Secure Remote Access プロキシを使用しない場合、SSL トラフィックはゲートウェイに制限され、ゲートウェイと内部ホスト間ではトラフィックは暗号化されません (内部ホストが HTTPS モードで実行されていないかぎり)。内部ホストに対してゲートウェイが Netlet 接続を開始する必要がある内部ホストは、DMZ から直接アクセス可能である必要があります。これはセキュリティーの問題になる可能性があるので、この構成はもっとも単純なインストールにのみ推奨します。

図 4–12 基本 Secure Remote Access 構成

この図では、クライアントのブラウザが NetFile および Netlet を実行しています。ゲートウェイは、2 つのファイアウォールの間の DMZ 内の個別のマシンにインストールされています。

Netlet の無効化

図 4–13 は、Netlet が無効ということ以外は基本 Secure Remote Access 構成と同様のシナリオを示しています。クライアントの配備がイントラネットと通信する必要があるアプリケーションを安全に実行するために Netlet を使用しない場合は、パフォーマンス向上のためにこの構成を使用します。

この構成を拡張して、他の配備シナリオと組み合わせて、パフォーマンスを向上し、拡張可能なソリューションを提供できます。

図 4–13 Netlet の無効化

この図は、Netlet が無効な基本 Secure Remote Access 構成を示しています。

プロキシレット

図 4–14 で示すプロキシレットは、イントラネットのリソースをクライアントに公開しなくても、ユーザーがインターネットを使用してイントラネットのリソースに安全にアクセスできるようにします。

プロキシレットでは、ゲートウェイのトランスポートモード (HTTP または HTTPS のどちらか) が継承されます。

図 4–14 プロキシレット

これは、プロキシレットを使用した基本 Secure Remote Access 構成を示しています。

複数のゲートウェイインスタンス

図 4–15 は、Secure Remote Access の基本構成の拡張を示しています。複数のゲートウェイインスタンスが、同じマシンまたは複数のマシンで稼働します。別々のプロファイルで複数のゲートウェイインスタンスを起動できます。

図 4–15 複数のゲートウェイインスタンス

この図は、同じマシンまたは複数のマシンで稼働している複数のゲートウェイインスタンスを示しています。

注 –

図 4–15 はゲートウェイと Portal Server の 1 対 1 の対応を示していますが、実際の配備では必ずしもこのようになる必要はありません。複数のゲートウェイインスタンスや複数の Portal Server インスタンスを配備可能であり、また構成によってはどのゲートウェイも任意の Portal Server にアクセスできます。

この構成の欠点は、各接続要求のために 2 番目のファイアウォールで複数のポートを開く必要があるということです。これは、セキュリティーの問題になる可能性があります。

Netlet プロキシとリライタプロキシ

図 4–16 は、Netlet プロキシとリライタプロキシがある構成を示しています。これらのプロキシの場合、2 番目のファイアウォールではポートが 2 つだけ開いている必要があります。

この構成では、ゲートウェイはアプリケーションホストと直接やり取りする必要はありませんが、すべての Netlet トラフィックを Netlet プロキシへ、リライタトラフィックをリライタプロキシへ転送します。Netlet プロキシはイントラネット内にあるので、2 番目のファイアウォールで複数のポートを開かなくても、すべての必要なアプリケーションホストと直接やり取りできます。

DMZ 内のゲートウェイと Netlet プロキシとの間のトラフィックは暗号化され、Netlet プロキシでのみ復号化されるので、セキュリティーが向上します。

リライタプロキシが有効な場合、要求が Portal Server ノード宛てのものかどうかにかかわらず、すべてのトラフィックがリライタプロキシに転送されます。これによって、DMZ 内のゲートウェイからイントラネットへのトラフィックは常に暗号化されることが保証されます。

Netlet プロキシ、リライタプロキシ、および Portal Server がすべて同じノードで稼働するので、そのような配備シナリオではパフォーマンスの問題が発生する場合があります。この問題は、Portal Server ノードの負荷を軽減するためにプロキシを別々のノードにインストールすると解決できます。

図 4–16 Netlet プロキシとリライタプロキシ

この図は、Netlet プロキシとリライタプロキシがある構成を示しています。

別々のノードにある Netlet プロキシとリライタプロキシ

Portal Server ノードの負荷を軽減し、なおかつパフォーマンスを向上させて同じレベルのセキュリティーを提供するには、Netlet プロキシとリライタプロキシを別々のノードにインストールできます。この配備は、プロキシを使用して Portal Server を DMZ から保護できるというさらなる利点があります。これらのプロキシを実行するノードは、DMZ から直接アクセス可能である必要があります。

図 4–17 は、別々のノードにある Netlet プロキシとリライタプロキシを示しています。ゲートウェイからのトラフィックは別のノードに転送され、そのノードはトラフィックをプロキシ経由で、必要なイントラネットのホストに転送します。

Netlet プロキシとリライタプロキシの複数のインスタンスを持つことや複数の Netlet プロキシとリライタプロキシをインストールすることが可能です。各ゲートウェイを、可用性に応じてラウンドロビン方式でプロキシのさまざまなインスタンスとのやり取りを試みるように設定できます。

図 4–17 別々のノードにあるプロキシ

この図は、別々のノードにある Netlet プロキシとリライタプロキシを示しています。

2 つのゲートウェイと Netlet プロキシ

ロードバランサは、Portal Server および Access Manager の冗長サービスの高可用性のためのフェイルオーバーのメカニズムを提供します。

図 4–18 2 つのゲートウェイと Netlet プロキシ

この図は、ファイアウォール内にある 2 つのゲートウェイの前にあるロードバランサを示しています。

アクセラレータを使用するゲートウェイ

外部の SSL デバイスをオープンモードでゲートウェイの前で実行するように設定できます。これは、クライアントと Secure Remote Access の間に SSL リンクを提供します。アクセラレータの詳細は、Sun Java System Portal Server 7.1 Secure Remote Access 管理ガイドを参照してください。

図 4–19 外部のアクセラレータを使用する Secure Remote Access ゲートウェイ

この図は、クライアントブラウザとゲートウェイ用ファイアウォールとの間に配置されたアクセラレータを示しています。

サードパーティーのプロキシを使用する Netlet

図 4–20 は、サードパーティーのプロキシを使用して、2 番目のファイアウォールのポートの数を 1 つに制限する例を示しています。サードパーティーのプロキシを使用して、リライタプロキシまたは Netlet プロキシに到達するようにゲートウェイを設定できます。

図 4–20 Netlet とサードパーティーのプロキシ

この図は、2 番目のファイアウォールのポートの数を 1 つに制限するために使用されるサードパーティーのプロキシを示しています。

逆プロキシ

プロキシサーバーがインターネットのコンテンツをイントラネットに配信するのに対して、逆プロキシサーバーはイントラネットのコンテンツをインターネットに配信します。逆プロキシの特定の配備の際に、インターネットコンテンツのロードバランスおよびキャッシングが行われるように設定できます。

図 4–21 は、インターネットとイントラネットの両方のコンテンツを承認されたユーザーに配信するために、ゲートウェイの前に逆プロキシを配置する方法を示しています。ゲートウェイが Web コンテンツを配信するときには、このコンテンツに基づいた後続するブラウザの要求すべてがゲートウェイを通じてルーティングされるようにする必要があります。これは、このコンテンツ内のすべての URL を確認し、必要に応じて書き換えることによって実現します。

図 4–21 ゲートウェイの前に逆プロキシを使用

この図は、ファイアウォール内にあるゲートウェイの前にある逆プロキシを示しています。

配備のシナリオ

完成した論理アーキテクチャー設計それ自体は、ソリューションライフサイクルの配備設計段階に移るには不十分です。技術要件段階で、論理アーキテクチャーとサービス品質 (QoS) 要件とを組み合わせる必要があります。論理アーキテクチャーと QoS 要件を組み合わせることで、配備シナリオとなります。

第 5 章「配備設計の計画」の説明のとおり、配備アーキテクチャーの設計は配備シナリオから始めます。