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

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

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

この図では、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 インスタンス。Web コンテナのコンテキストで実行されます。インスタンスに含まれるコンポーネントは、Java API を使用して JVM を介して通信します。インスタンスは、完全修飾ドメイン名と TCP ポート番号です。Portal Server サービスは、サーブレットまたは JSP^TM ファイルとして実装される Web アプリケーションです。

  Portal Server は、認証シングルサイオン (セッション) 管理、ポリシー、およびプロファイルデータベースアクセスのために Access Manager 上に構築されます。したがって、Portal Server は可用性と障害許容性に関して Access Manager のすべての利点 (および制約) を継承します。

  設計により、Access Manager のサービスは、ステートレス、またはサービスがコンテキストデータを共有できるのどちらかになります。サービスは、サービスに障害が発生した場合に前の状態に戻ることができます。

  Portal Server では、ポータルデスクトップはインスタンス間で状態データを共有しません。これは、インスタンスのリダイレクトによって、有効になったサービスに対してユーザーコンテキストが再作成されることを意味します。通常、リダイレクトされたユーザーはこれに気がつきません。これは、Portal Server サービスがユーザーコンテキストをユーザーのプロファイルから、また要求に格納されたコンテキストデータを使用することによって再作成できるためです。これは一般にインストール後即使用可能なサービスに当てはまりますが、チャネルやカスタムコードには当てはまらないことがあります。開発者は、インスタンスのフェイルオーバー時にコンテキストを失うのを避けるためにステートフルチャネルを設計しないように注意する必要があります。

• プロファイルデータベースサーバー 。プロファイルデータベースサーバーは、Directory Server ソフトウェアによって実装されます。このサーバーは厳密には Portal Server の一部ではありませんが、このサーバーの可用性とデータベースの完全性はシステムの可用性に欠かせません。

• 認証サーバー 。これは LDAP 認証のためのディレクトリサーバーです (通常、プロファイルデータベースサーバーと同じサーバー)。このサーバーには、プロファイルデータベースサーバーと同じ高可用性技術を適用できます。

• Secure Remote Access ゲートウェイとプロキシ 。Secure Remote Access ゲートウェイは、状態情報をエンドユーザーに透過に再作成できるため、ステートレスとみなすことのできるスタンドアロンの Java テクノロジプロセスです。ゲートウェイプロファイルは、Portal Server インスタンスのリストを維持し、ゲートウェイインスタンス間でラウンドロビン方式のロードバランスを行います。ゲートウェイの前ではセッション固定の必要はありませんが、セッションが固定されると、パフォーマンスが向上します。一方、Portal Server インスタンスに対するセッション固定は Secure Remote Access によって実施されます。

  Secure Remote Access には、Netlet プロキシとリライタプロキシと呼ばれるほかの Java テクノロジプロセスも含まれます。これらのプロキシを使用して、ファイアウォールの背後からセキュリティーの適用範囲を拡張し、DMZ の穴の数を制限できます。これらのプロキシは、別々のノードにインストールできます。