可用性設計の例

ここでは、「アイデンティティーベースの通信の例」で説明されている、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 バイト

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

• 可用性: システム全体の可用性は 99.99% (予定された停止時間は含めない) とする。個々のコンピュータシステムの障害によってサービス障害が発生してはならない。

• スケーラビリティー: 日々のピーク負荷時において、どのサーバーも 80% を超えて利用されてはならない。 また、システムは 1 年当たり 10% の長期成長に対応する必要がある。

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

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

• 一方のサーバーに障害が発生した場合、残りのサーバーが CPU 能力を提供して負荷を処理するため。

• ピーク負荷時にどのサーバーも 80% を超えて利用されてはならないとするというスケーラビリティー要件に基づき、追加分の CPU 能力でこの安全マージンを提供するため。

• 1 年当たり 10% の負荷増大に対応することというスケーラビリティー要件に基づき、追加分の CPU 能力により、さらなる拡張が必要とされるまで増大する負荷を処理できる潜在処理能力を高めるため。

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

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

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

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

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

• 複数データベース: 別個のデータベースに、ディレクトリツリーのさまざまな部分を保存します。

• 連鎖およびリフェラル: 分散されたデータを 1 つのディレクトリツリーにリンクします。

• シングルマスターレプリケーション: マスターデータベース用の中央ソースを提供します。これはその後、コンシューマレプリカに分散されます。

• マルチマスターレプリケーション: 複数のサーバーにマスターデータベースを分散します。これらのマスターはその後、それぞれのデータベースをコンシューマレプリカに分散します。

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 のシングルインスタンス

• 読み取り操作および検索操作用に最適化された、Directory Server の任意の数のコンシューマインスタンス

• Directory Server のコンシューマインスタンスの水平方向のスケーラビリティー

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

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

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

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

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