論理アーキテクチャーを決定したら、次はサイトに適したサービスの可用性レベルを特定します。サービスの可用性レベルは、選択したハードウェア、ソフトウェアインフラストラクチャー、使用する保守方法が関係しています。この章では、いくつかの選択肢とそのメリットおよびコストについて説明します。
この章には、次の節があります。
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 配備の可用性をさらに高めることができます。
この章の次の節では、各コンポーネントで使用できるオプションについて説明します。
単に高可用性 (HA) ソリューションを評価するだけでなく、ASR を可能にするハードウェアの配備についても検討する必要があります。
ASR は停止時間に関連するハードウェア障害を最小限にするためのプロセスです。サーバーに ASR 機能がある場合は、ハードウェアの個別のコンポーネントに障害が発生しても、停止時間を最小限にとどめることが可能になります。ASR により、サーバーの自動再起動と、障害の発生したコンポーネントが交換されるまでそれを停止しておくことが可能になります。欠点は、障害の発生したコンポーネントがサービスから排除される結果、システムのパフォーマンスが低下することです。たとえば、CPU に障害が発生すると、マシンは残りの CPU を使用して再起動されます。システムの I/O ボードまたはチップに障害が発生した場合は、システムの I/O ボードが減少するか、代わりの I/O パスが使用されます。
さまざまな Sun SPARC システムが、さまざまなレベルの ASR をサポートしています。ASR をまったくサポートしていないシステムもあれば、非常に高レベルの ASR をサポートしているシステムもあります。当然ながら、高い ASR 機能を持つサーバーはその分コストも高くつきます。ソフトウェアに高可用性がない場合、コストには制約がないものとすれば、データ格納用にはハードウェアに高い冗長性と ASR 機能を持たせたマシンを選択します。
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 つのコンシューマが、読み取り (検索) 操作のためにこのトポロジのスケーリングを可能にします。 |
Sun Cluster ソフトウェアの使用により、ディレクトリの設定に最高水準の可用性が提供されます。アクティブ Directory Server ノードの障害が発生した場合、Sun Cluster はバックアップノードにサービスの透過的なフェイルオーバーを提供します。ただし、クラスタのインストール、設定、保守などの管理 (およびハードウェア) コストは、通常 Directory Server のレプリケーション手法よりも高くなります。 |
詳細については、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』を参照してください。
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 は、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 は Sun Cluster エージェントを提供しますが、Veritas Cluster Service をサポートしていません。Instant Messaging マルチプレクサの配備を冗長化したり、Instant Messaging ウォッチドッグプロセスを活用したりすることで、より可用性の高い環境を実現できます。
Sun Cluster エージェントを使用して高可用性 (HA) を実現するために Instant Messaging を設定すると、ソフトウェアとハードウェアの障害の監視および復旧機能が提供されます。高可用性機能はスケーラブルサービスではなくフェイルオーバーデータサービスとして実装され、現時点では Solaris 上でのみサポートされています。
同じ SMTP サーバーを使用することで、1 つの HA 環境内に複数の Instant Messaging ノードを配置することができます。
Sun Cluster エージェントを使用して Instant Messaging の HA 環境を実装する前に、次のどの HA 配備がもっともニーズに適しているかを決定します。
混合 HA 環境: この配備はローカル設定とバイナリ、およびグローバル実行時ファイルから構成されます。この設定の利点は、Instant Messaging がオフラインであるノード上でアップグレードを行えることにより、最小限の停止時間で Instant Messaging をアップグレードできることです。欠点は、クラスタ内のすべてのノード上で Instant Messaging の設定とバージョンの統一を保証しなければならないことです。加えて、このオプションを選択する場合、グローバル実行時ファイル用に HAStoragePlus またはクラスタファイルシステムのどちらを使用するのかを決定する必要があります。
グローバル HA 環境: この配備はグローバル設定、バイナリ、および実行時ファイルから構成されます。この設定は管理が容易ですが、アップグレードの前に、クラスタ内のすべてのノード上で 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 操作の総数を増加させます。
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
『Veritas Cluster Server User’s Guide』http://seer.support.veritas.com/docs/275725.htm
リモートサイトフェイルオーバーは、プライマリサイトに致命的な障害が発生した場合に、そのプライマリサイトに WAN で接続されているサイトでサービスを開始する機能です。リモートサイトフェイルオーバーにはいくつかの形式があり、それぞれにコストが異なります。
リモートサイトフェイルオーバーでは、すべてのケースでサーバーとストレージを追加して、リモートサイトにインストールおよび設定された、サービスのユーザー負荷のすべてまたは一部を処理する能力を持つようにする必要があります。すべてまたは一部というのは、顧客によっては優先するユーザーとそうでないユーザーがいることを意味します。ISP でも企業でも、そのような状況が起こります。ISP には、この機能のために割増料金を支払うユーザーがいます。企業では、全従業員に電子メールの機能を提供している部門内で、ユーザーによってはそのサポートが高くついている場合があるかもしれません。たとえば、カスタマサポートに直接関わるユーザーのメールに対してリモートサイトフェイルオーバーを選択した場合でも、製造ラインで勤務する従業員には、リモートサイトフェイルオーバーを用意しないというケースが考えられます。リモートハードウェアは、このようにリモートサイトフェイルオーバーメールサーバーにアクセスを許可されたユーザーの負荷を処理できます。
ユーザーベースの使用率だけを制限すると、必要な冗長サーバーとストレージハードウェアの数を減らすことができますが、フェイルバックの設定と管理も複雑になります。そのようなポリシーはまた、長期的には予期しない別の影響をユーザーに与えます。たとえば、ドメインメールルーターが 48 時間にわたって利用不能になった場合、インターネット上の他の MTA ルーターがそのドメイン宛てのメールを保持します。ある時点でサーバーがオンラインに戻った際に、メールが配送されます。さらに、すべてのユーザーをフェイルオーバーリモートサイトに設定していない場合は、MTA が起動して設定されていないユーザーに対して永続的なエラー (バウンス) が返されます。最後に、すべてのユーザーを受け入れるようにメールを設定している場合は、すべてのユーザーをフェイルバックするか、フェイルオーバーがアクティブな間使用できないアカウント宛てのメールを保持し、フェイルバックが起こったらそれを本来の配信の流れに戻すように MTA ルーターを設定する必要があります。
考えられるリモートサイトフェイルオーバーのソリューションには、次のようなものがあります。
単純でコストのかからないシナリオ: リモートサイトの接続に広帯域幅の大規模ネットワークを使用しません。十分な規模のハードウェアを必ずしも使用する必要はありません。実際のところ、ハードウェアは当面の間はほかの目的に使用できます。プライマリサイトからのバックアップがリモートサイトに対して定期的に提供されますが、必ずしも復元の必要はありません。予想される問題点としては、古いデータをオンラインに戻す際に重要なデータが失われたり、かなりの遅れが生じることです。プライマリサイトで障害が発生したときには、手動でネットワークを変更してサービスを開始します。サービスを開始したら、続いて imsrestore プロセスを開始します。最後にファイルシステムの復元が開始されると、続いてサービスが開始されます。
より複雑で、よりコストのかかるソリューション: Veritas および Sun の市販ソフトウェアソリューションでは、ローカル (プライマリ) ボリュームで発生するすべての書き込みがリモートサイトにも書き込まれます。通常の製品では、リモートサイトはプライマリサイトとともにロックステップかそれに近い状態になります。プライマリサイトで障害が発生した場合は、セカンダリサイトがネットワーク設定をリセットし、データをほとんど失うことなくサービスを提供できます。このシナリオでは、テープから復元する意味はありません。プライマリサイトの障害の前に切り替えられなかったデータは、少なくともフェイルバックが起きるか、MTA キューデータの場合には手動による介入が行われるまで、失われることになります。Veritas Site HA ソフトウェアは、プライマリサイトの障害を検出し、ネットワークをリセットしてサービスを起動する用途でよく使われますが、これはより高いレベルのデータ保管には必要ありません。サーバーがデータをコピーするための負荷と待ち時間が大きく増加するため、このソリューションでは、プライマリサイトで必要なハードウェアの台数が大幅に増加します。
最も実現性の高いソリューション: このソリューションは、データのコピーがメッセージストアサーバーで行われることを除いて、ソフトウェアによるリアルタイムデータコピーソリューションと本質的には同じものです。Message Store サーバーが、リモートのレプリケーションをサポートするストレージアレイに接続されている場合、リモートサイトに対するデータコピーはストレージアレイのコントローラそれ自体によって処理されます。リモートのレプリケーション機能を提供するストレージアレイは大容量になりがちなため、このソリューションを導入するための基本コストは、ローエンドストレージ製品を使用する場合よりも高くつきます。
ハードウェアやソフトウェアをはじめ、管理コスト、電力費、光熱費、ネットワークコストまで、これらのソリューションでは、さまざまなコストが発生します。これらのコストはすべてそのまま計算に入れて、数字をはじき出します。そうしなければ、いくつかのコストを算出するのが困難になります。そのようなコストには、めったに実施しない一連の手順を実施するときのミスによるコスト、停止時間による直接のコスト、データ損失によるコストなどがあります。このような種類のコストを正確に算定するのは不可能です。顧客によっては、停止時間とデータの損失は代償が高くつくか、まったく受け入れられません。別の顧客にとっては、それは単なる不愉快にすぎないかもしれません。
リモートサイトフェイルオーバーを行う場合には、リモートディレクトリが少なくとも最新のもので、メッセージデータの復元が可能な状態にあることも必要です。リモートサイトにリストアメソッドを使用する場合は、ディレクトリが完全に復元されてからメッセージを復元する必要があります。また、ユーザーをシステムから削除した場合、ディレクトリ内でそのユーザーに無効のタグがつけられるだけなのはやむをえません。ユーザーのデータがあるメッセージバックアップテープが使用されるかぎり、それらのユーザーをディレクトリから削除してはなりません。
次の質問を参考にして、リモートサイトフェイルオーバーの計画を立ててください。
サイトで必要とする応答性のレベルはどの程度か
組織によっては、プライマリサイトで障害が発生したときに、手動処理のスクリプトセットで十分対応可能な場合もあります。短時間 (数分間) のうちにリモートサイトがアクティブになる必要がある組織もあります。そのような組織では、Veritas リモートサイトフェイルオーバーソフトウェアかそれに相当する機能を持ったその他のソフトウェアが必要です。
ローカル HA 用の Sun Cluster とリモートサイトフェイルオーバー用の Veritas ソフトウェアを併用しないでください。Sun Cluster は現時点ではリモートサイトフェイルオーバーをサポートしていません。
また、プライマリサイトからバックアップサイトへの自動フェイルオーバーをソフトウェアに許可しないでください。その場合、セカンダリサイトからプライマリサイトの障害が誤って検出される可能性がかなり高くなります。このようなケースでは、ソフトウェアにプライマリサイトを監視させ、障害を検出したときに警告を出させるように設定します。次に、バックアップサイトへの自動フェイルオーバープロセスを開始する前に、障害が実際に発生していることを確認します。
どれぐらいのデータを保存し、どの程度の速さで利用可能にする必要があるか
これは単純な質問のようですが、細分化されて回答の幅は広くなります。シナリオには、簡単なものからほとんど完全なものまであり、ハードウェア、ネットワークデータインフラストラクチャー、保守のコストの面でも大きな違いがあります。