Portal Server の構築モジュール (Sun Java System Portal Server 7.1 配備計画ガイド)

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

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 つのシナリオを提供します。

「ベストエフォート」

ハードウェアに障害が発生しないかぎり、また watchdog プロセスによって Portal Server プロセスを再起動できるかぎり、システムを利用できます。
「ノーシングルポイント障害」

ハードウェアとソフトウェアのレプリケーションにより、ノーシングルポイント障害 (No Single Point of Failure、NSPOF) の配備を構築します。コンポーネントの連鎖のどこかで連続的に複数の障害が発生しないかぎり、システムは常に利用可能です。ただし、障害が発生した場合は、ユーザーセッションは失われます。
「透過フェイルオーバー」

システムは常に利用可能ですが、NSPOF に加えて、バックアップインスタンスへのフェイルオーバーがエンドユーザーに透過に行われます。ほとんどの場合、ユーザーは別のノードまたはインスタンスにリダイレクトされたことに気がつきません。セッションは、ノード間にわたって維持されるので、ユーザーは再認証する必要がありません。Portal Server サービスは、ステートレス、またはチェックポイントメカニズムを使用して現在の実行コンテキストを特定の時点まで再構築します。Portal Server の高可用性とセッションのフェイルオーバーに関する設定情報の詳細については、『Sun Java System Portal Server 7.1 Configuration Guide 』を参照してください。

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

Sun Cluster エージェントをサポートするコンポーネントで Sun^TM Cluster ソフトウェアの使用
マルチマスター Directory Server 技術

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

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

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


コンポーネントの要件	ベストエフォート配備に必要ですか ?	NSPOF 配備に必要ですか ?	透過フェイルオーバー配備に必要ですか ?
冗長ハードウェア	はい	はい	はい
Portal Server の構築モジュール	いいえ	はい	はい
マルチマスター構成	いいえ	はい	はい
ロードバランス	はい	はい	はい
ステートレスなアプリケーションとチェックポイントメカニズム	いいえ	いいえ	はい
セッションのフェイルオーバー	いいえ	いいえ	はい
Directory Server クラスタ	いいえ	いいえ	はい

注 –

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

ベストエフォート

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

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

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

このシナリオでは、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 プロキシのクラッシュによって、再確立する必要があるすべての未処理の接続がなくなります。

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

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

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

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

1 台のマシンに 1 つの構築モジュールを配備します。
複数のマシンを使用する場合、または Portal Server マシンが多数のインスタンスを稼働させている場合は、高速ネットワークインターコネクトを使用します。
8 個を超える CPU が搭載されているサーバーでは、2 個または 4 個の CPU からなるプロセッサセットまたはドメインを作成します。たとえば、Portal Server の 2 つのインスタンスを 8 個の CPU が搭載されたサーバーにインストールする場合は、4 個の CPU からなる 2 つのプロセッサセットを作成します。

Directory Server

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

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

Directory Server コンシューマレプリカプロセッサセットに必要な CPU の量は、構築モジュールに含まれる Portal Server インスタンスの数、またパフォーマンスおよび容量の考慮事項によって決定されます。
可能であれば、1 つの Directory Server インスタンスを1 つの構築モジュール内の Portal Server インスタンス専用にします。
ディレクトリデータベースインデックス全体とメモリー内のキャッシュをマップして、ディスクの遅延に関する問題を防止します。
複数の構築モジュールを配備するときは、Directory Server サプライヤに対するプロファイルの更新とレプリケーションのオーバーヘッドによる障害を回避するためにマルチマスター構成を使用します。

LDAP

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

注 –

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

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

検索サービス

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

各構築モジュールでは、1 つの Portal Server インスタンスだけの検索エンジンデータベースにリソース記述 (RD) が含まれているようにします。残りの Portal Server インスタンスの検索エンジンデータベースは、デフォルトの空の状態であるようにします。
ポータルの検索データベースに構築モジュールを使用するかどうかに影響する要素には、同時並行検索の数に加えて、Portal Server 配備の検索活動の程度、検索のヒットの範囲、すべてのユーザーの検索ヒットの平均数があります。たとえば、検索エンジンによるサーバーへの負荷は、大きなインデックスや高負荷のクエリーの場合はメモリーと CPU の両方をかなり使用することがあります。
検索機能を Portal Server とは別のマシンにインストールして、主なサーバーをポータルの活動専用にすることができます。そのようにする場合、検索プロバイダの searchURL プロパティーを使用して、検索機能がインストールされた 2 番目のマシンを指すようにします。検索インスタンスは、通常のポータルインスタンスです。ポータルインスタンスをインストールするのと同様に検索インスタンスをインストールしますが、検索インスタンスは検索機能のみに使用します。