構築モジュールと高可用性のシナリオ (Sun Java System Portal Server 7.1 配備計画ガイド)

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

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

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