test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

第 6 章 サービスの可用性の設計

論理アーキテクチャーを決定したら、次はサイトに適したサービスの可用性レベルを特定します。サービスの可用性レベルは、選択したハードウェア、ソフトウェアインフラストラクチャー、使用する保守方法が関係しています。この章では、いくつかの選択肢とそのメリットおよびコストについて説明します。

この章には、次の節があります。

高可用性ソリューションの概要

Communications Services の高可用性ソリューションは、製品ごとに異なります。

たとえば、Messaging Server は、2 つの異なる高可用性ソリューションである Sun Cluster と Veritas Cluster Server (VCS) をサポートします。Messaging Server は、これら各ソリューションに対するエージェントを提供します。

Messaging Server と Calendar Server は、異なるクラスタトポロジをサポートしています。詳細については、対応するクラスタ製品のマニュアルを参照してください。

Application Server を Web コンテナとして使用する場合は、その高可用性、負荷分散、およびクラスタ管理機能を利用できます。

Instant Messaging は Sun Cluster エージェントも提供しますが、VCS はサポートしません。冗長性のある Instant Messaging マルチプレクサの配備によって、さらに可用性の高い配備を実現できます。そのような配備では、あるマルチプレクサで障害が発生しても、それとは別の利用可能なマルチプレクサ経由で、Instant Messaging クライアントはバックエンドサーバーと通信できます。

また、Directory Server などのインフラストラクチャーコンポーネントの可用性を高くすることで、Communications Services 配備の可用性をさらに高めることができます。

この章の次の節では、各コンポーネントで使用できるオプションについて説明します。

システムの自動再設定 (ASR)

単に高可用性 (HA) ソリューションを評価するだけでなく、ASR を可能にするハードウェアの配備についても検討する必要があります。

ASR は停止時間に関連するハードウェア障害を最小限にするためのプロセスです。サーバーに ASR 機能がある場合は、ハードウェアの個別のコンポーネントに障害が発生しても、停止時間を最小限にとどめることが可能になります。ASR により、サーバーの自動再起動と、障害の発生したコンポーネントが交換されるまでそれを停止しておくことが可能になります。欠点は、障害の発生したコンポーネントがサービスから排除される結果、システムのパフォーマンスが低下することです。たとえば、CPU に障害が発生すると、マシンは残りの CPU を使用して再起動されます。システムの I/O ボードまたはチップに障害が発生した場合は、システムの I/O ボードが減少するか、代わりの I/O パスが使用されます。

さまざまな Sun SPARC システムが、さまざまなレベルの ASR をサポートしています。ASR をまったくサポートしていないシステムもあれば、非常に高レベルの ASR をサポートしているシステムもあります。当然ながら、高い ASR 機能を持つサーバーはその分コストも高くつきます。ソフトウェアに高可用性がない場合、コストには制約がないものとすれば、データ格納用にはハードウェアに高い冗長性と ASR 機能を持たせたマシンを選択します。

Directory Server と高可用性

Communications Services の見地からみると、ディレクトリサービスを計画する際の最も重要な要素は可用性です。インフラストラクチャーサービスとして、ディレクトリは認証、アクセス、電子メールのルーティングなどの高レベルのアプリケーションに対して、可能なかぎり継続的なサービスを提供する必要があります。

高可用性を提供する Directory Server の重要な機能は「レプリケーション」です。レプリケーションは、ある Directory Server から別の Directory Server にディレクトリデータを自動的にコピーするメカニズムです。レプリケーションによって、可用性の高いディレクトリサービスを提供し、データを地理的に分散することが可能になります。実際的には、レプリケーションは次の利点を提供します。

下表は、可用性のあるディレクトリを設計する方法を示します。

表 6–1 高可用性 Directory Server の設計

手法 

説明 

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

サプライヤとして機能するサーバーが 1 つまたは複数のコンシューマサーバーにマスターのレプリカを直接コピーします。この構成では、すべてのディレクトリの変更がサプライヤに格納されたマスターのレプリカに対して行われ、コンシューマには読み取り専用のデータのコピーが含まれます。 

双方向、マルチマスターレプリケーション 

同一データの共有を担当する 2 つのサプライヤ間のマルチマスター環境で、2 つのレプリケーションアグリーメントを作成します。サプライヤ A とサプライヤ B がそれぞれ同一データのマスターのレプリカを保持し、このマルチマスター構成のレプリケーションフローを制御する 2 つのレプリケーションアグリーメントが存在します。 

4 方向、マルチマスター 

通常、2 つの独立したデータセンターに Directory Server マスターのペアを提供します。この構成は、レプリケーションに 4 方向、マルチマスターレプリケーション (MMR) を使用します。4 方向マスターフェイルオーバー構成により、この完全に接続されたトポロジがデータの完全性を保証する高可用性ソリューションを提供しています。レプリケーショントポロジのハブとともに使用する場合、負荷分散を容易にし、各データセンターの 4 つのコンシューマが、読み取り (検索) 操作のためにこのトポロジのスケーリングを可能にします。 

Directory Server 用の Sun Cluster エージェント

Sun Cluster ソフトウェアの使用により、ディレクトリの設定に最高水準の可用性が提供されます。アクティブ Directory Server ノードの障害が発生した場合、Sun Cluster はバックアップノードにサービスの透過的なフェイルオーバーを提供します。ただし、クラスタのインストール、設定、保守などの管理 (およびハードウェア) コストは、通常 Directory Server のレプリケーション手法よりも高くなります。 

詳細については、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』を参照してください。

Application Server と高可用性

Communications Express は Web コンテナ (Web Server または Application Server) 内に配備されるため、Web コンテナの高可用性化を検討してください。

たとえば、Application Server Enterprise Edition はコアアプリケーションサーバープラットフォームの機能強化版であり、高可用性化機能、負荷分散機能、およびクラスタ管理機能を備えています。Enterprise Edition では、Platform Edition の管理機能が拡張されており、複数インスタンス、複数マシンの配備にも対応できるようになっています。

Application Server のクラスタリングサポートには、設定の容易なクローンアプリケーションサーバーインスタンスグループが含まれます。このグループを使えば、クライアント要求の負荷分散を実現できます。このエディションでは、外部ロードバランサと負荷分散機能を備えた Web 層ベースプロキシの両方が、サポートされています。Application Server EE は、HADB (高可用性データベース) を使って HTTP セッションとステートフルセッション Bean に対するフェイルオーバーを実現します。

詳細については、次の Application Server Enterprise Edition 8.1 2005Q2 のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1310.2

Messaging Server、Calendar Server と高可用性

クラスタソフトウェアを使用すると、Messaging Server および Calendar Server で高可用性が実現できるように設定できます。Messaging Server は、Sun Cluster および Veritas Cluster Server の両方のソフトウェアをサポートしています。Calendar Server は、Sun Cluster ソフトウェアをサポートしています。

フロントエンドとバックエンドコンポーネントが別々のマシンに分散された、Tier (層) Communications Services アーキテクチャーでは、バックエンドが持続的データを保持する「ストア」となるため、クラスタテクノロジを使用してバックエンドコンポーネントを高可用性化する場合があります。クラスタテクノロジは、持続的データを保持していないため、通常は Messaging Server または Calendar Server のフロントエンドでは保障されていません。通常、Messaging Server の MTA、MMP、MEM と Calendar Server のフロントエンドの可用性を高めるには、システムを冗長化します。つまり、複数のフロントエンドホストを配備します。また、RAID テクノロジによって MTA のディスクサブシステムを保護することで MTA を高可用性化することも可能です。

Sun Cluster トポロジの詳細については、『Sun Cluster Concepts Guide for Solaris OS』の第 2 章「Key Concepts for Hardware Service Providers」を参照してください。

Messaging Server の高可用性の設定について詳しくは、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 3 章「高可用性の構成」を参照してください。

Calendar Server の高可用性の設定について詳しくは、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』の第 7 章「Configuring for High Availability (Failover Service)」

Instant Messaging と高可用性

Instant Messaging は Sun Cluster エージェントを提供しますが、Veritas Cluster Service をサポートしていません。Instant Messaging マルチプレクサの配備を冗長化したり、Instant Messaging ウォッチドッグプロセスを活用したりすることで、より可用性の高い環境を実現できます。

Instant Messaging の高可用性の概要

Sun Cluster エージェントを使用して高可用性 (HA) を実現するために Instant Messaging を設定すると、ソフトウェアとハードウェアの障害の監視および復旧機能が提供されます。高可用性機能はスケーラブルサービスではなくフェイルオーバーデータサービスとして実装され、現時点では Solaris 上でのみサポートされています。

注 –

同じ SMTP サーバーを使用することで、1 つの HA 環境内に複数の Instant Messaging ノードを配置することができます。

Sun Cluster エージェントを使用して Instant Messaging の HA 環境を実装する前に、次のどの HA 配備がもっともニーズに適しているかを決定します。

複数の Instant Messaging マルチプレクサの使用

複数のマルチプレクサを含む Instant Messaging 配備では、あるマルチプレクサで障害が発生しても、それとは別の利用可能なマルチプレクサ経由で、Instant Messaging クライアントはバックエンドサーバーと通信できます。現時点では、複数のマルチプレクサが単一の Instant Messaging サーバーインスタンスと通信するようにしか設定できません。複数のマルチプレクサが複数の Instant Messaging インスタンスと通信するように設定することはできません。

Instant Messaging ウォッチドッグプロセスの使用

Instant Messaging にはウォッチドッグプロセスが含まれています。このプロセスは Sun Cluster エージェントを監視し、サーバーのロックアップやクラッシュなど、何らかの理由により利用不可能になったサービスを再開します。ウォッチドッグプロセスを設定した場合、ある Instant Messaging コンポーネントの機能が停止すると、ウォッチドッグプロセスが、そのコンポーネントをシャットダウンしてから再起動します。

有効化テクニックとテクノロジの使用

前節で説明した高可用性ソリューションのほかに、有効化テクニックとテクノロジを使用して可用性とパフォーマンスの両方を向上させます。これらのテクニックとテクノロジには、ロードバランサ、Sun Java System Directory Proxy Server 、レプリカロールプロモーションなどがあります。

ロードバランサの使用

ロードバランサを使用して、エンドツーエンドのシステム全体に高可用性を提供することにより、アーキテクチャーの各層の機能の可用性を保証することができます。ロードバランサは、専用のハードウェア機器または完全なソフトウェアソリューションです。

負荷分散は、単一のアプリケーションインスタンス、サーバー、またはネットワークが単一の障害ポイントになることを回避すると同時にサービスのパフォーマンスを向上させる最善の方法です。負荷分散の主な目的の 1 つは、サービスの水平方向の能力を拡大することです。たとえば、ディレクトリサービスの場合、ロードバランサは、ディレクトリサービスが処理可能な同時 LDAP 接続の総数および 1 秒あたり LDAP 操作の総数を増加させます。

Directory Proxy Server の使用

Sun Java System Directory Proxy Server (以前の SunTM ONE Directory Proxy Server) は多くのプロキシ形式の機能を提供します。これらの機能の 1 つに LDAP 負荷分散があります。Directory Proxy Server は専用ロードバランサと同じ機能を実行できませんが、フェイルオーバー、レフェラルのフォロー、セキュリティ、マッピング機能のために、この機能の使用を検討します。

詳細については、次の Web サイトの Directory Proxy Server のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1317.1

レプリカロールプロモーションの使用

Directory Server には、ディレクトリインスタンスのレプリカロールを昇格させたり、降格させる方法があります。この機能により、レプリカハブをマルチマスターサプライヤに昇格させる、またはその逆を行うことができます。コンシューマをレプリカハブのロールに昇格させる、またはその逆を行うこともできます。ただし、コンシューマを直接マルチマスターサプライヤとして昇格させること、またはその逆を行うことはできません。この場合には、コンシューマはまずレプリカハブとなり、次にハブからマルチマスターのレプリカとなることができます。逆の場合も同じように実行できます。

レプリカロールプロモーションは分散配備に役立ちます。地理的に分散した 6 箇所のサイトがある場合について考えてみます。マルチマスターサプライヤを各サイトに配置したいと思いますが、最大 4 つのサイトに、サイトごとに 1 つ配置するだけに制限されています。ほかの 2 つの各サイトに少なくとも 1 つのハブを配置する場合は、ほかのマルチマスターサプライヤの 1 つがオフラインになっているか、または何らかの理由で運用されていない場合に、それらを昇格させることができます。

詳細については、『Sun Java System Directory Server 5 2005Q1 Administration Guide』を参照してください。

高可用性製品の参照情報

高可用性モデルの詳細については、次の製品マニュアルを参照してください。

Sun Cluster

Veritas Cluster Server

リモートサイトフェイルオーバーの理解

リモートサイトフェイルオーバーは、プライマリサイトに致命的な障害が発生した場合に、そのプライマリサイトに WAN で接続されているサイトでサービスを開始する機能です。リモートサイトフェイルオーバーにはいくつかの形式があり、それぞれにコストが異なります。

リモートサイトフェイルオーバーでは、すべてのケースでサーバーとストレージを追加して、リモートサイトにインストールおよび設定された、サービスのユーザー負荷のすべてまたは一部を処理する能力を持つようにする必要があります。すべてまたは一部というのは、顧客によっては優先するユーザーとそうでないユーザーがいることを意味します。ISP でも企業でも、そのような状況が起こります。ISP には、この機能のために割増料金を支払うユーザーがいます。企業では、全従業員に電子メールの機能を提供している部門内で、ユーザーによってはそのサポートが高くついている場合があるかもしれません。たとえば、カスタマサポートに直接関わるユーザーのメールに対してリモートサイトフェイルオーバーを選択した場合でも、製造ラインで勤務する従業員には、リモートサイトフェイルオーバーを用意しないというケースが考えられます。リモートハードウェアは、このようにリモートサイトフェイルオーバーメールサーバーにアクセスを許可されたユーザーの負荷を処理できます。

ユーザーベースの使用率だけを制限すると、必要な冗長サーバーとストレージハードウェアの数を減らすことができますが、フェイルバックの設定と管理も複雑になります。そのようなポリシーはまた、長期的には予期しない別の影響をユーザーに与えます。たとえば、ドメインメールルーターが 48 時間にわたって利用不能になった場合、インターネット上の他の MTA ルーターがそのドメイン宛てのメールを保持します。ある時点でサーバーがオンラインに戻った際に、メールが配送されます。さらに、すべてのユーザーをフェイルオーバーリモートサイトに設定していない場合は、MTA が起動して設定されていないユーザーに対して永続的なエラー (バウンス) が返されます。最後に、すべてのユーザーを受け入れるようにメールを設定している場合は、すべてのユーザーをフェイルバックするか、フェイルオーバーがアクティブな間使用できないアカウント宛てのメールを保持し、フェイルバックが起こったらそれを本来の配信の流れに戻すように MTA ルーターを設定する必要があります。

考えられるリモートサイトフェイルオーバーのソリューションには、次のようなものがあります。

ハードウェアやソフトウェアをはじめ、管理コスト、電力費、光熱費、ネットワークコストまで、これらのソリューションでは、さまざまなコストが発生します。これらのコストはすべてそのまま計算に入れて、数字をはじき出します。そうしなければ、いくつかのコストを算出するのが困難になります。そのようなコストには、めったに実施しない一連の手順を実施するときのミスによるコスト、停止時間による直接のコスト、データ損失によるコストなどがあります。このような種類のコストを正確に算定するのは不可能です。顧客によっては、停止時間とデータの損失は代償が高くつくか、まったく受け入れられません。別の顧客にとっては、それは単なる不愉快にすぎないかもしれません。

リモートサイトフェイルオーバーを行う場合には、リモートディレクトリが少なくとも最新のもので、メッセージデータの復元が可能な状態にあることも必要です。リモートサイトにリストアメソッドを使用する場合は、ディレクトリが完全に復元されてからメッセージを復元する必要があります。また、ユーザーをシステムから削除した場合、ディレクトリ内でそのユーザーに無効のタグがつけられるだけなのはやむをえません。ユーザーのデータがあるメッセージバックアップテープが使用されるかぎり、それらのユーザーをディレクトリから削除してはなりません。

リモートサイトフェイルオーバーについての質問

次の質問を参考にして、リモートサイトフェイルオーバーの計画を立ててください。

注 –

ローカル HA 用の Sun Cluster とリモートサイトフェイルオーバー用の Veritas ソフトウェアを併用しないでください。Sun Cluster は現時点ではリモートサイトフェイルオーバーをサポートしていません。

また、プライマリサイトからバックアップサイトへの自動フェイルオーバーをソフトウェアに許可しないでください。その場合、セカンダリサイトからプライマリサイトの障害が誤って検出される可能性がかなり高くなります。このようなケースでは、ソフトウェアにプライマリサイトを監視させ、障害を検出したときに警告を出させるように設定します。次に、バックアップサイトへの自動フェイルオーバープロセスを開始する前に、障害が実際に発生していることを確認します。