test

Sun Java Enterprise System 2005Q4 配備計画ガイド

可用性戦略の決定

可用性要件のための戦略を策定する際は、コンポーネントのインタラクションと使用パターンの分析に基づいて、検討する可用性ソリューションを決定します。コンポーネントごとに分析を行い、可用性とフェイルオーバーの要件に最も適したソリューションを決定します。

次に、可用性戦略の決定に役立つ情報の例を示します。

可用性戦略は、「リソースの最適な使用方法の設計」で説明する保守性要件も考慮した上で選択する必要があります。膨大な管理や保守を必要とする複雑なソリューションは避けます。

可用性戦略

Java Enterprise System 配備の可用性戦略には、次のものがあります。

以降の各節では、さまざまなレベルのロードバランス、フェイルオーバー、およびサービスのレプリケーションを提供する可用性ソリューションの例をいくつか示します。

シングルサーバーシステム

サービスのすべてのコンピュータリソースを 1 つのサーバーに配置します。サーバーに障害が発生した場合、サービス全体が失敗します。

図 5–2 シングルサーバーシステム

パフォーマンス要件を満たすために 10 CPU を搭載したシングルサーバーを示しています。

Sun は、次の利点を提供するハイエンドサーバーを提供しています。

通常、ハイエンドサーバーは、同等の機能を持つマルチサーバーシステムより高価になります。ただしシングルサーバーでは、管理、監視、データセンターでのサーバーのホスティング費用が軽減されます。ロードバランス、フェイルオーバー、障害シングルポイントの除去は、マルチサーバーシステムのほうが柔軟に対応できます。

水平方向の冗長システム

ロードバランスとフェイルオーバーの両方を提供する平行冗長サーバーを使用することで、いくつかの方法で可用性を向上できます。次の図は、N+1 フェイルオーバーシステムを構成する 2 つのレプリカサーバーを示しています。N+1 システムには、1 つのサーバーで障害が発生した場合に、その処理能力の 100% を提供するための追加サーバーが含まれます。

図 5–3 2 つのサーバーで構成される N+1 フェイルオーバーシステム

10 CPU のパフォーマンス要件を満たすために、それぞれが 10 の CPU を搭載した 2 つのレプリカサーバーを示しています。

上の「水平方向の冗長システム」に示される各サーバーは、同一処理能力を持ちます。1 つのサーバーが単独でパフォーマンス要件を満たします。もう一方のサーバーは、バックアップとしてサービスに適用された場合に 100% のパフォーマンスを提供します。

N+1 フェイルオーバー設計の利点は、フェイルオーバー状況でも 100% の処理能力を提供できることです。欠点には、1 つのサーバーはフェイルオーバー状況でだけ使用されるスタンバイであるため、パフォーマンス全体の向上なしにハードウェアコストが上昇することが挙げられます。

次の図は、2 つのサーバーの間でパフォーマンスを分散するロードバランスとフェイルオーバーを実装するシステムを示しています。

図 5–4 2 つのサーバー間のロードバランスとフェイルオーバー

10 CPU のパフォーマンス要件を満たすために、それぞれが 6 CPU を搭載した 2 つのサーバーを示しています。

上の「水平方向の冗長システム」で示されているシステムでは、一方のサーバーに障害が発生した場合に、処理能力は低下しますが、すべてのサービスを利用できます。残ったサーバーは 6 CPU の処理能力を提供します。 これは、10 CPU という要件の 60% に相当します。

この設計の利点は、両方のサーバーを利用可能な状態では、2 CPU の潜在処理能力を追加されることです。

次の図は、パフォーマンス向上とロードバランス用に、多数のサーバーの間でパフォーマンスを分散する例を示しています。

図 5–5 n サーバー間での負荷の分散

10 CPU のパフォーマンス要件を満たすために、それぞれが 2 CPU を搭載した 5 つのサーバーを示しています。

「水平方向の冗長システム」に示される設計では 5 つのサーバーが使用されるため、1 つのサーバーに障害が発生した場合に、残りのサーバーが 8 CPU の処理能力を提供します。 これは、10 CPU のパフォーマンス要件の 80% に相当します。この設計に 2 CPU の処理能力を持つサーバーを追加すると、効率的に N+1 設計を実現できます。1 つのサーバーに障害が発生しても、残りのサーバーによってパフォーマンス要件は 100% 満たされます。

この設計には、次のような利点があります。

ただし、サーバーを追加することで、管理と保守のコストは大きく上昇します。データセンターでのサーバーのホスティング費用も考慮する必要があります。サーバーの追加投入によるメリットは、ある時点から減少に転じます。

Sun Cluster ソフトウェア

高い可用性 (4 ナインまたは 5 ナインなど) が必要となる状況では、可用性設計の一部として Sun Cluster ソフトウェアの利用を検討することができます。クラスタシステムは、冗長サーバーとストレージやその他のネットワークリソースを結合したものです。クラスタ内のサーバーは、継続的に相互通信します。1 つのサーバーがダウンした場合、クラスタ内の残りのデバイスはそのサーバーを分離し、障害のあるノードから別のノードにアプリケーションまたはデータをフェイルオーバーします。このフェイルオーバープロセスは、比較的迅速に行われるため、システムの利用者がサービスの中断を感じることはほとんどありません。

Sun Cluster ソフトウェアは、専用ハードウェアの追加と、設定、管理、維持のための特別なスキルを必要とします。

可用性設計の例

ここでは、「アイデンティティーベースの通信の例」で説明されている、1,000 〜 5,000 人の従業員を持つ中規模企業用の、アイデンティティーベースの通信ソリューションに基づいた、可用性戦略の 2 つの例を示します。1 つ目の可用性戦略では、Messaging Server のロードバランスについて説明します。2 つ目では、Sun Cluster ソフトウェアを使用するフェイルオーバーソリューションについて説明します。

Messaging Server のロードバランスの例

次の表は、論理アーキテクチャー内の論理 Messaging Server コンポーネントの CPU 能力の見積もり値を示しています。この表は、「CPU 見積もりの更新」の節で計算した最終見積もり値を再掲しています。

表 5–6 サポートするコンポーネントのための CPU 見積もりの調整

コンポーネント 

CPU の数 

メモリ 

Messaging Server (MTA、着信) 

2 

4G バイト 

Messaging Server (MTA、発信) 

2 

4G バイト 

Messaging Server (MMP) 

2 

4G バイト 

Messaging Server (メッセージストア) 

2 

4G バイト 

たとえば、技術要件フェーズで、次のサービス品質要件が指定されたとします。

可用性要件を満たすには、各 Messaging Server コンポーネントについてインスタンスを 2 つずつ、それぞれを異なるハードウェアサーバーに提供します。一方のコンポーネントのサーバーに障害が発生した場合、もう一方がサービスを提供します。次の図は、この可用性戦略のネットワーク図です。

Messaging Server MMP および MTA の各コンポーネントの可用性を示すアーキテクチャー図。

上の図では、CPU の数は元の見積もりの 2 倍になっています。CPU の数は、次の理由から 2 倍になりました。

Sun Cluster ソフトウェアを使用したフェイルオーバーの例

次の図は、Calendar Server バックエンドおよび Messaging Server メッセージストアのフェイルオーバー戦略の例を示しています。Calendar Server バックエンドおよびメッセージストアは、別個のハードウェアサーバーにレプリケートされ、Sun Cluster ソフトウェアを使用してフェイルオーバー用に設定されます。CPU の数および対応するメモリは、Sun Cluster で各サーバー上にレプリケートされます。

図 5–6 Sun Cluster ソフトウェアを使用したフェイルオーバー設計

Sun Cluster ソフトウェアを使用して配備した、フェイルオーバー用の Calendar Server および Message Server ストレージを示すアーキテクチャー図。

ディレクトリサービスのレプリケーションの例

ディレクトリサービスをレプリケートして複数のサーバーにトランザクションを分散すると、高い可用性が得られます。Directory Server により、サービスのレプリケーションためのさまざまな戦略が提供されます。これには、次の戦略が含まれます。

Directory Server の可用性戦略は複雑な事項であり、このマニュアルの範囲に含まれません。以降の各節、「シングルマスターレプリケーション」および 「マルチマスターレプリケーション」では、基本的なレプリケーション戦略の概要を説明します。詳細については、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』の第 12 章「Designing a Highly Available Deployment」を参照してください。

シングルマスターレプリケーション

次の図は、基本的なレプリケーション概念を表すシングルマスターレプリケーションを示しています。

図 5–7 単一マスター複製の例

シングルマスターレプリケーション戦略のデータフローを示す図。

シングルマスターレプリケーションでは、Directory Server の 1 つのインスタンスがマスターディレクトリデータベースを管理し、すべての変更を記録します。マスターデータベースは、任意の数のコンシューマデータベースにレプリケートされます。Directory Server のコンシューマインスタンスは、読み取り操作および検索操作用に最適化されています。コンシューマに対する書き込みは、マスターに反映されます。マスターは、定期的にコンシューマデータベースを更新します。

シングルマスターレプリケーションには、次の利点があります。

マルチマスターレプリケーション

次の図は、ディレクトリアクセスをグローバル規模で分散するために使用される可能性のあるマルチマスターレプリケーション戦略を示しています。

マルチマスターレプリケーションでは、Directory Server の 1 つ以上のインスタンスがマスターディレクトリデータベースを管理します。各マスターは、マスターデータベースの同期手順を規定するレプリケーションアグリーメントを持ちます。各マスターは、任意の数のコンシューマデータベースに対してレプリケートを行います。シングルマスターレプリケーションの場合と同様に、Directory Server のコンシューマインスタンスは、読み取りアクセスおよび検索アクセス用に最適化されています。コンシューマに対する書き込みは、マスターに反映されます。マスターは、定期的にコンシューマデータベースを更新します。

図 5–8 マルチマスターレプリケーションの例

マルチマスターレプリケーション戦略のデータフローを示す図。

マルチマスターレプリケーション戦略では、シングルマスターレプリケーションのすべての利点が提供されることに加えて、マスターに対する更新にロードバランスを実行できる可用性戦略が提供されます。また、ディレクトリ操作のローカル制御を提供する可用性戦略も実装できます。 このことは、グローバル規模で分散しているデータセンターを持つ企業にとって重要な考慮事項です。