高可用性戦略

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2007-08-31

このトピックでは、Microsoft Exchange Server 2007 での高可用性について広範な概要を示します。また、組織に適した可用性ソリューションを選択するときの推奨される決定プロセスについて説明します。

可用性および高可用性という言葉は、使われている状況や関係するユーザーによって、さまざまな意味を持ちます。これらの言葉は、ハードウェアのみの可用性目標から、メッセージング サービス全体のミッション クリティカルな目標まで、さまざまなビジネスの目標や技術的な要件を説明するために使用されます。

一般的に、多くの人々は比較的容易に、可用性目標に関して誤った期待を抱きます。また、コストへの影響を理解していないうちは、実際に支払おうとしているよりも高いレベルの可用性を容易に要求します。

ほとんどの可用性ソリューションのコストへの影響には、次の影響が含まれます (ただしこれらに限定されません)。

• ハードウェア
• ソフトウェア
• ネットワーク インフラストラクチャ
• トレーニング
• サービス性
• 運用コスト

サービス性は、IT サービスまたは IT コンポーネントを提供または保守するために、サード パーティのサービス プロバイダと結んだ契約上の取り決め、または組織内の IT 部門との間で取り決めた運用レベルの合意事項を指します。

可用性

アプリケーション、サービス、またはシステムにより提供されるサービスのレベル。高可用性を備えたシステムでは、計画したダウンタイムと計画されていないダウンタイムの両方が最小限に抑えられます。可用性は通常、サービスまたはシステムが使用可能な時間の比率として表されます。たとえば、1 年で 8.75 時間使用不可能なサービスの可用性は 99.9% になります。

可用性を向上させるには、フォールト トレランス機構を実装して、コンポーネントに発生したエラーとサービスの依存関係の影響をマスクするか、最小限に抑える必要があります。フォールト トレランスは、単一障害点となるコンポーネントを冗長化することによって実現されます。

Microsoft Exchange の可用性について計画する場合は、メッセージング インフラストラクチャに属するすべてのコンポーネントについて考慮してください。コンポーネントの中には、サブコンポーネントを持つ別のサービスになることもできるコンポーネントもあります。メッセージング サービスの可用性は、インフラストラクチャに含まれる各コンポーネントの可用性によって決まります。

可用性に対する要件の定義

サービスの可用性は、多くの管理業務にまたがる複雑な問題です。必要な可用性レベルを提供するために、さまざまな方法をとることができ、それぞれコストへの影響が異なります。

ただし、可用性に対する要件はしばしば、顧客によって影響を十分に理解されることなく、比較的単純化された言葉で表現されることがあります。このような状況の結果として、顧客と IT 組織の間の誤解、不適切なレベルの投資、および最終的には、設定した期待が不適切だったことによる顧客満足度の低下がもたらされることがあります。

99.5% の可用性に対して表される 1 つの要件は、99.5% の可用性に対する別の要件とは異なる可能性があります。ある要件はハードウェア プラットフォーム単体の可用性について説明し、別の要件はエンド ツー エンドのサービス全体の可用性について説明していることがあります。エンド ツー エンドのサービス全体の可用性の定義でさえも、大幅に異なる可能性があります。可用性に対する要件を測定する方法を正しく理解することが重要です。以下に例を示します。

• プライマリ サーバー上のハードウェアとソフトウェアがすべて正常に動作していて、アプリケーションによるユーザー接続の受け入れ準備ができている場合は、そのソリューションを 100% 使用可能と見なしますか。
• 100 人のユーザーがいて、そのうち 25% はローカル ネットワーク障害によって接続できない場合でも、そのソリューションを 100% 使用可能と見なしますか。
• 100 人のユーザーのうち 1 人だけ接続して作業を行うことができた場合、そのソリューションを 1% だけ使用可能と見なしますか。
• 100 人のユーザー全員が接続できますが、3 つのうち 2 つの顧客トランザクションしか使用できない状態でサービスが低下しているか、パフォーマンスが低下しているとすると、これは可用性の測定にどのように影響しますか。

可用性を測定している期間も可用性の定義に重要な影響を与えます。1 年間の可用性に対する要件が 99.9% の場合は、8.75 時間のダウンタイムが許容されます。定期的な 4 週間という期間内の可用性に対する要件が 99.9% の場合は、各期間に許容されるダウンタイムは 40 分だけです。

また、計画的な保守処理、Service Pack の更新プログラム、およびソフトウェア更新プログラムのためのダウンタイム期間を特定したり、交渉したりすることも必要です。計画的な許容ダウンタイムの期間は、可用性に対する要件の定義に重大な影響を及ぼします。

Microsoft Exchange Server 2007 の RTM (Release To Manufacturing) には、コストを削減し、稼働時間を増やすことができる新しい機能があります。

• ローカル連続レプリケーション   ローカル連続レプリケーション (LCR) は、運用ストレージ グループと同じサーバーに接続される 2 番目のディスク セット上でストレージ グループのコピーを作成および保持するための組み込みのテクノロジを使用するシングルサーバー ソリューションです。LCR では、非同期のログ配布、ログの再生、およびデータのコピーへの手動による迅速な切り替えが可能です。LCR の詳細については、「ローカル連続レプリケーション」を参照してください。
• クラスタ連続レプリケーション   クラスタ連続レプリケーション (CCR) は、Exchange 2007 のレプリケーションと再生の機能と Microsoft クラスタ サービスのフェールオーバー機能を統合します。CCR は、単独のデータセンター内または 2 か所のデータセンター間で単一障害点を生じることなく展開できるソリューションです。CCR の詳細については、「クラスタ連続レプリケーション」を参照してください。クラスタ連続レプリケーション (CCR) には、以前のバージョンの Exchange Server のクラスタ化および Exchange 2007 のシングル コピー クラスタより優れたいくつかの利点があります。これらの利点の詳細については、「シングル コピー クラスタに対するクラスタ連続レプリケーションの利点」を参照してください。
• シングル コピー クラスタ   Exchange 2007 には、以前のバージョンの Exchange Server では共有記憶域クラスタと呼ばれていたシングル コピー クラスタがあり、大幅な変更と機能強化が行われています。SCC の詳細については、「シングル コピー クラスタ」を参照してください。

Microsoft Exchange Server 2007 Service Pack 1 (SP1) には、サイトの復元性を提供するために設計された以下の機能が追加されています。

• スタンバイ連続レプリケーション   スタンバイ連続レプリケーション (SCR) は、Exchange 2007 SP1 で導入された新しい機能です。名前が示すとおり、SCR は、待機している (スタンバイ) 回復用サーバーを使用する、またはその使用を可能にするシナリオのために設計されています。SCR は既存の連続レプリケーション機能を拡張し、Exchange 2007 メールボックス サーバーに対して、新しいデータ可用性シナリオを有効化します。SCR は、LCR および CCR で使用されるのと同じログ配布および再生テクノロジを使用して、追加の展開オプションと構成を提供します。SCR はスタンドアロン メールボックス サーバーおよびクラスタ化メールボックス サーバーからのデータのレプリケートに使用できます。SCR の詳細については、「スタンバイ連続レプリケーション」を参照してください。

これらの機能によって回復の可能性が強化され、さまざまな可用性要件を満たします。次の表に、さまざまな可用性要件と、Exchange 2007 ソリューションと Exchange Server 2003 で提供されていた障害回復ソリューションとの比較を示します。Exchange 2007 の高可用性の構成の詳細については、「高可用性展開」を参照してください。

可用性要件に基づく高可用性ソリューションの比較

適切な可用性ソリューションの選択

Exchange 2007 の展開では、可用性向上のために複数の構成を使用できます。適切な可用性ソリューションを選択するには、いくつかの選択肢を分析して、ビジネスの目標および可用性要件にとって最適なソリューションを判断する必要があります。そのための 1 つの方法として、障害の種類ごとにまとめた表を作成する方法が挙げられます。表の各行には、障害に対する可用性要件に合致する回復戦略のソリューションをまとめます。ソリューションの重要な要素を各列に記述します。一般的な要素としては、以下のものがあります。

• 回復時間
• 回復におけるデータの重要度
• 関連するハードウェアおよびソフトウェアのコスト
• 関連するリソース コスト
• 発生する確率
• ビジネスに対する影響
• 複合的なリスク
• サード パーティのソリューション
• 長所
• 短所

この表が完成したら、コスト分析用にいくつかのソリューションを選択します。選択した各ソリューションについて、メールボックスあたりの予測コストを算出し、これについても表を作成します。コスト表の行には、ソリューションの性能とビジネスの目標を対比させた説明を記述します。複数の選択肢を評価することが重要です。少なくとも 1 つは、要件を満たしながらも、自組織で通常選択されるソリューションとは性質の異なるソリューションを選択するようにします。

最後に、ビジネス目標、可用性要件、選択可能なソリューション、およびコスト分析を検討して、ソリューションを選択します。このプロセスで適切な決定を行うために、以下の重要な点を考慮してください。

• 優先順位が設定された一連の明確なビジネス目標を設定する   異なる目標は両立が難しいため、優先順位を付けることが重要です。
• 現状には適合しない可能性がある従来の手法を疑う   設計および評価段階では、Exchange 2007 の可能性を完全に活用するようにしてください。これまでの経験によれば、最も費用対効果が高いソリューションを確立するには、バックアップ、ストレージ、および運用に対して、新しいアプローチをとることが要求されます。
• メッセージ システムの単一障害点を調べる   単一の記憶域ネットワーク (SAN) にメールボックス データの単一のコピーを格納したのでは、データは破損と障害から完全には保護されません。SAN で用意されている冗長性の程度にかかわらず、単一のデータのコピーでは、破損または障害が発生する要因がいくつもあります。SCC では、SAN に障害が発生すると、何時間ものデータ損失や何日ものサービス中断が生ずることがあります。CCR の可用性ソリューションでは、サーバー障害が発生すると一部のデータが損失することがありますが、データのコピーが 2 つ保持されます。CCR では、トランスポート収集と呼ばれるハブ トランスポート サーバーの機能を使用することによって、サーバー障害発生時のデータ消失の大部分が軽減されます。その結果、ほとんどのハードウェア障害においてメールボックス データが保持されます。
• 各ソリューションで使用できるさまざまなストレージ オプションを検討する   CCR を使用することによって、直接接続型記憶域など、より多くのストレージ ソリューションの選択肢が利用できるようになります。CCR は SAN ファブリックを必要としないため、関連する複雑さやコストが削減されます。直接接続型記憶域は、SAN または低価格のストレージ ソリューションのどちらであっても、展開および運用が容易です。
• CCR および LCR によって、一般的な毎日の完全バックアップ戦略から、頻度の低い完全バックアップおよび毎日の増分バックアップ戦略へとバックアップ戦略を転換できることを考慮する   CCR および LCR は、初期障害からの回復に関して、より短期のサービス レベル契約 (SLA) にも対応できます。二重障害 (両方のコピーに障害が発生するか破損する) からの回復では、現行の復元 SLA よりも長期の SLA が必要になることがあります。一般的にはバックアップ コストが TCO の大きな部分を占めているため、このような変更によって、総保有コスト (TCO) が劇的に削減されます。さらに、ディスクベースのバックアップ戦略に切り替えることによっても、バックアップ コストを削減できます。
• Exchange 2007 での連続レプリケーション テクノロジの利用について調査し、ソリューションを作成する   CCR により、サード パーティのテクノロジが不要になります。現在、CCR は 2 ノード クラスタをサポートしており、このクラスタでは、各ノードにデータのコピーが 1 つずつ保持されます。このテクノロジに基づくサイト復元ソリューションには、次のようないくつかの利点があります。
  • バックアップ データセンターのメールボックス データをクライアントが確実に使用できるようになります。
  • 連続レプリケーションでは、ほとんどのサード パーティのソリューションに比べ、データの移動が少なくなります。
  • サイト復元ソリューションの構築で必要な統合作業が少なくて済みます。
• さまざまな選択肢について回復動作およびコストを記述した表を作成する   コスト表には、既存の手法とは異なる選択肢をいくつか含めるようにします。作成した表の事項を使用して、次のようなソリューションを構築します。
  • ビジネス要件に対応する最良のソリューションである。
  • コスト要件を満たす。
  • 展開および運用の複雑性が、組織でサポート可能なレベルである。

基本的な製品とコンポーネント

製品とコンポーネントの展開は、可用性と信頼性の厳しい要件を満たす機能に基づく必要があります。これらの要件を、可用性設計の基礎として検討します。このような基本的な製品とコンポーネントの信頼性が低く、故障しやすいと、さらに高いレベルの可用性を実現するために必要な追加投資は無駄になり、可用性レベルは満たされません。

サービス管理プロセス

効果的なサービス管理プロセスは、高レベルの可用性に寄与します。可用性管理、事故管理、問題管理、変更管理などのプロセスは、メッセージング サービスの全体的な管理において重要な役割を果たします。

システム管理

システム管理では、監視、診断、自動エラー回復の機能を提供し、潜在的および現実の障害をすばやく検出して解決できるようにする必要があります。

完全な冗長性を備えた特殊なソリューション

100% の連続可用性を実現するには、完全な冗長性を組み込んだ高価なソリューションが必要です。冗長性とは、重複したコンポーネントを使用することで可用性を高める技法です。厳しい可用性要件を満たすためには、このようなコンポーネントが並行して自律的に動作する必要があります。

可用性の目標および SLA 要件の設定

高水準の可用性を実現するための第一歩は、優れた品質の製品とコンポーネントを展開することです。しかし、このような製品とコンポーネントだけでは、要求されるレベルの可用性を持続的に提供することはできません。開発プロセスの可能な限り早い段階で、設計プロセスにおける可用性の目標を検討する必要があります。このようにすることで、再作業、必要な可用性を満たすために必要な予定外のアップグレード、インフラストラクチャを監視するための予定外のツール、インフラストラクチャの単一障害点を除去するための予定外の出費、保守性、サービス性などに関連するコストの増加を防ぐことができます。

高可用性の実現に向けて最初に実行する必要があることの 1 つは、組織に設定されている SLA を確認することです。SLA を設定した後は、その契約に最も適した Exchange 2007 の展開とサーバー構成を決定できます。

障害回復時の高可用性に関する重要な考慮事項を以下はとおりです。

• 許容ダウンタイム   Exchange サービスの可用性に関する組織の定義に基づき、組織が許容できる最大ダウンタイムを検討してください。ダウンタイムに関する組織の定義によっては、メッセージング ダイヤル トーン回復戦略を用いて組織の SLA に適合させることができます。メッセージング ダイヤル トーン回復戦略には、障害の直後に一時的なメールボックスをユーザーに提供してメッセージの送受信を可能にすることも含まれます。この方法では、通常のメールボックスのデータを回復する前に、電子メール サービスが迅速に復元されます。一般に、通常のメールボックスと一時メールボックスのデータを最終的に結合することで、回復が完了します。
• 許容回復時間   障害回復操作の種類ごとに許容できる最大時間を検討してください。たとえば、メールボックス、単一データベース、または Exchange 2007 を稼働しているサーバー全体を回復するのにかかる目安期間を指定する必要があります。
• データ損失の許容度   Exchange データの一時的または永続的な損失に対する組織の許容度を検討してください。たとえば、ユーザーがメッセージの送受信を 4 時間以内に行えるのであれば、組織は前回のバックアップ以降 24 時間分のメールボックス データの一時的な損失を許容できるでしょう。これに対し、エラー発生時までのすべての Exchange データを 4 時間以内に復元するなど、より厳しい要件を検討することが必要な場合もあります。

ダウンタイムによる組織への影響を考慮し、メッセージング環境で実現を目指す稼働時間のレベルを決定した後は、SLA を確立できます。SLA 要件により、記憶域、クラスタ、バックアップ、回復などの要因を組織に取り入れる方法が決定されます。

SLA を評価するときは、まず、通常の運用時間と、計画したダウンタイムに関する要望を特定します。次に、メッセージの配信時間、サーバー稼働時間の比率、必要な記憶域の容量、Exchange データベースを回復するための時間など、可用性、パフォーマンス、および回復性に関する企業の要望を決定します。

さらに、適切なレベルのフォールト トレランスをメッセージング システムに割り当てることができるように、計画されていないダウンタイムのコストを見積もります。

Exchange 2007 および Windows Server 2003 の機能が、SLA に適合する組織を設計する方法に影響することがあります。たとえば、LCR、CCR、SCC、ボリューム シャドウ コピー サービス (VSS)、回復用ストレージ グループ、データベースの移植性、ダイヤル トーンの移植性の機能を使用すれば、SLA によってこれまで課されていた制限を超えることも可能です。

次の表は、SLA の分類と、SLA に含めることのできる要素の一覧を示しています。

一般的なエンタープライズ レベルの SLA の分類と要素

パフォーマンスを示すさまざまな数値を SLA に含めると、ユーザーの特定のパフォーマンス要件が満たされているかどうかを正しく確認できます。たとえば、クライアントとメールボックス サーバー間で待ち時間が長い、または使用可能な帯域幅が少ない場合、ユーザーとシステム管理者ではパフォーマンス レベルの認識が異なります。特に、システム管理者が適切なパフォーマンスと見なしても、ユーザーはパフォーマンス レベルが低いと見なす場合があります。このため、ディスク入出力 (I/O) の待ち時間レベルを必ず監視してください。

注 :
各 SLA 要素に対しては、可用性の目標だけでなく、パフォーマンスの測定に使用するベンチマークも決定する必要があります。さらに、IT 管理者や他の管理者に統計を提供する頻度も決定する必要があります。

ベンダとのサービス レベル契約の交渉および確立

高可用性を提供するソリューションを重要と考える多くの企業では、高可用性の目標を達成するためにサード パーティ ベンダを利用しています。このような場合、高可用性を備えたメッセージング システムを実現するためには、外部のハードウェア ベンダおよびソフトウェア ベンダのサービスが必要になります。ベンダの対応が遅い場合や、ベンダのスタッフのスキルが不足している場合、メッセージング システムの可用性が低下することがあります。

このため、必ず主要な各ベンダと SLA を交渉してください。ベンダとの間で SLA を確立すると、メッセージング システムが仕様に基づいて機能し、必要とされる拡張をサポートし、特定の標準に従って使用可能であることを保証する際に役立ちます。SLA を確立していないと、メッセージング システムが使用不可能な時間が大幅に増えることがあります。

重要 :
組織内のスタッフは各 SLA の条項を理解しておく必要があります。たとえば、ハードウェア ベンダの SLA には、ベンダ側のサポート スタッフまたは顧客側の認定されたスタッフのみがサーバーのケースを開けることができるという条項が一般に含まれています。この条項に従わないと、SLA 違反となり、ベンダに保証または責任を求めることができなくなる場合があります。

主要なベンダとの間で SLA を確立することに加えて、サポート要求を試験的に行ってエスカレーション手順を定期的にテストする必要もあります。最新の連絡先情報を入手しておくために、携帯電話や固定電話に登録した番号もテストしてください。

可用性に関する考慮事項

可用性の要件を決定するために、以下の問題について検討することをお勧めします。

• 提案されているインフラストラクチャ設計の障害に対する脆弱性を理解します。単一障害点がないことを確認する必要があります。単一障害点とは、冗長機能を持たず、故障するとユーザーに影響を与える可能性のある、メッセージング インフラストラクチャ内のコンポーネントです。ソリューションに対して提案されている技術的な設計は、エンドツーエンドの完全な構成をカバーしている必要があります。
• メッセージング サービスに対して業務が要求する最低限の可用性レベル、およびメッセージング インフラストラクチャの各コンポーネントに対する最低限のレベルの信頼性、保守性、およびサービス性を検討します。
• 新しいコンポーネントをテストまたはシミュレートして、指定されている要件に適合することを確認する機能を検討します。設計内の新しいコンポーネントが提示されている要件を満たすことができるかどうかを評価するには、使用するテスト方法によって、期待される可用性を確実に実現できることが重要です。コンポーネントを保守するときも、テストを行う必要があります。処理量が多く高負荷の状況においてコンポーネントが動作し続けることを確認するため、新しい情報技術サービスに対するユーザーの予想される要求を生成するシミュレーション ツールを、真剣に検討する必要があります。

高可用性に関する考慮事項

高可用性を備えたメッセージング ソリューションには、監視ソリューション、サービス管理プロセス、システム管理ツール、および冗長性を展開する必要があります。高可用性の展開では、このエンドツーエンド構成の中に単一障害点が存在していないことが重要です。高可用性のための設計では、単一障害点を除去すること、およびコンポーネントが故障した場合の業務の中断を最小限にするために代替コンポーネントを用意することを、検討する必要があります。また、設計では、インフラストラクチャに対する変更の実装などの保守作業を行うために通常必要となる計画的な停止が業務に与える影響を、除去または最小限にする必要があります。回復フェーズの設計における重要な目標として、回復条件では迅速な回復とサービスの復旧を定義する必要があります。

メッセージング ソリューションの展開計画の作成では、ソリューションの目標を明確にする必要があります。この点は、ソリューションの可用性の特性を設計する場合に特に重要です。ビジネスの各目標が矛盾する結果を招くことがよくあります。たとえば、可用性の目標に 100% の可用性が含まれていながら、同時に最新のセキュリティ アップグレードを入手後 1 週間以内に適用することが要求されている場合があります。コストも一般に、展開計画を困難にする別の要因になります。ビジネスに最適なソリューションを明確にするための最善の方法は、すべてのビジネス要件が識別され、これらの要件に対して使用可能なオプションが評価されるような計画の手法に従うことです。

高可用性の達成を成功させるには、組織の運用方法に常に、継続的に注目していることが必要です。停止の原因をすべて理解する必要があります。処理の変更によって回避できる停止については、その処理の変更に着手する必要があります。

可用性の最大化における別の重要な要素は、Exchange 環境の予防的な監視です。予防的に監視することにより、システムに内在する問題の領域を、それによって障害や停止が発生する前に識別することができます。さらに、監視を行うことにより、システムでは自動的に回復されない問題を運営スタッフに警告することも可能になります。このような状況では、すばやい対応によって停止期間を短縮し、それによって可用性を向上させることができます。

Exchange 2007 は、データセンター内のインフラストラクチャとの依存関係を持ちます。その結果、Exchange の可用性は、各依存関係で提供される可用性によって左右されます。組織で各依存関係に関する SLA を確立することをお勧めします。この SLA では、提供されるサービスの可用性と、障害が発生した場合の回復時間を指定する必要があります。たとえば、Active Directory ディレクトリ サービスは、Exchange の主要な依存関係です。Active Directory の可用性が Exchange の可用性の目標より低い場合は、Exchange の目標に達しない可能性があります。

Exchange 2007 の可用性は、情報テクノロジ インフラストラクチャ内の他のサービスの可用性に依存します。Exchange が機能するには、Active Directory やネットワークなどのサービスが機能している必要があります。これらのサービスの可用性は Exchange の可用性に直接影響します。したがって、Exchange の可用性要件が、その依存関係に対する可用性要件より高くならないようにしてください。標準的な依存関係には次のものがあります。

• Active Directory
• ドメイン ネーム システム
• TCP/IP ネットワーク
• 格納域サブシステム
• バックアップ サービス
• 監視サービス
• データセンター インフラストラクチャ (電源や空調)

ビジネス目標と、Exchange の依存関係に関する SLA を確立した後、メッセージング サービスに対する初期の可用性要件の一覧を作成することをお勧めします。この一覧には、障害の一般的なクラスや、予測される目標回復時間 (RTO) を含めてください。データ関連の障害の場合は、この一覧にデータへの障害の影響を示す指標を含めてください。これは、目標回復ポイント (RPO) を示すことにより指定できます。RPO は、回復後に使用可能になるデータのレベルを定義する時点を指定することによって、データへの影響を識別します。考慮する必要のある障害には、次のものがあります。

• 単一のメール アイテムの消失
• 単一のメールボックスの消失
• データベースの消失または破損
• ディスクの障害
• ディスク ボリュームの障害または破損
• 記憶域ユニットの障害
• サーバーの障害
• ネットワーク接続の消失
• データセンターの障害

多くの組織では、確立される可用性要件はユーザーの種類によって異なります。たとえば、メッセージング システムを使用して配送または販売を追跡しているユーザーもいれば、メッセージング システムを重要性の低いメッセージに使用しているユーザーもいます。メッセージング システムを重要な処理に使用しているユーザーの RTO と RPO は、できるだけ短くする必要があります。一方、メッセージング システムを重要性の低い処理に使用しているユーザーの場合は、RTO や RPO が多少長くても許容されます。

詳細情報

Exchange 2007 の復元性の詳細については、「Site Resilience Configurations」を参照してください。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。