test

Sun Java System Portal Server 7.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 からの認証スループットを示しています。