高可用性の要因について

  • [アーティクル]

ここでは、メールボックス サーバー アーキテクチャ全体に影響する高可用性の要因について説明します。

メールボックスの復元

Exchange Server 2010 の場合、メールボックス サーバー インフラストラクチャをスタンドアロン実装で展開するか、メールボックスの復元で展開するか、いずれかを選択できます。Exchange 2010 は、メールボックスの復元という概念に基づいて再設計され、サーバー レベルでなく、個々のメールボックス データベース レベルで自動フェールオーバー保護機能が提供されるようにアーキテクチャが変更されました。

メールボックスの復元を活用するソリューションを選択する場合、アーキテクチャの点でいくつかの選択肢があります。

  • 複数のデータベース コピーを展開することによって、以下が可能になります。
    • バックアップ使用の最も一般的な原因を減らすソリューションを設計します。データベース コピーはハードウェア、ソフトウェア、およびデータ センターの障害に対する保護を提供します。
    • 回復機構は別のデータベース コピーであり、バックアップからの復元ではないため、データベース サイズを最大 2 テラバイトまで増やします。
    • 3 つ以上のデータベース コピーを展開する場合は、JBOD (Just a Bunch of Disks) などの別のストレージ アーキテクチャの検討が可能です。
  • データベース可用性グループ (DAG) 内に参加するすべてのサーバーにアクティブ データベースを配布することによって、ハードウェアの効率を最大限に高めることができます。詳細については、このトピックの次のセクションを参照してください。

詳細については、「高可用性とサイト復元の計画」および「バックアップ、復元、および障害復旧について」を参照してください。

同じサーバー上でのアクティブ データベース コピーとパッシブ データベース コピーのホスティング

Exchange 2010 メールボックス容量を計画する上で重要な点は、サーバーをメールボックスの復元用に構成する場合に、サーバー 1 台ごとにアクティブにするデータベース コピーの数を決定することです。さまざまな設計が可能ですが、以下のモデルを推奨します。

すべてのデータベース コピーをアクティブにする設計

この容量計画モデルでは、アクティブになるホスト済みデータベース コピーすべてを 100 % 処理するようにサーバー アーキテクチャを設計します。たとえば、サーバーが 35 個のデータベース コピーをホストする場合、ピーク時間中にアクティブになる 35 個のデータベースすべてを収容するようにプロセッサおよびメモリを設計します。

本トピックに記載する 2 つのモデルのうち、このモデルは高い可用性と共に、高いクライアント パフォーマンス特性を実現します。ただし、このモデルではサーバーの資本コストが高くなります。

対象とする障害シナリオ用の設計

このモデルでは、対応を計画する最悪の障害例においてアクティブなメールボックス負荷を処理するようにサーバー アーキテクチャを設計します。このモデルでは、サイトの復元、RAID ストレージと JBODのどちらを採用するか、データベース可用性グループ (DAG) のサイズ、データベース コピーの数など多くの要素を考慮します。

単純なルールは、次のように設計することです。

  • 2 ノード構成での自動の単一ノード障害
  • 3 サーバー構成での二重ノード障害 (2 番目の障害で手動によるアクティブ化)
  • DAG にノードが 4 つ以上ある場合の自動の二重ノード障害

上記のシナリオではそれぞれ適切な数のデータベース コピーが必要となり、それらのコピーは無作為かつ均等に配布される必要があります。

この容量計画モデルを選択する場合、サーバーがサービスを提供するように設計されているアクティブ データベースの数を超える (その結果、クライアントエクスペリエンスが低下する) ことがないように、サーバーごとにアクティブ化できるデータベースの数を制限することを強くお勧めします。

データベースの数を制限するには、最大アクティブ データベース設定を構成します。この設定は Exchange 管理シェルで Set-MailboxServer -MaximumActiveDatabases を実行することによって構成できます。サーバーの展開において想定している最大アクティブ データベースに一致するように、DAG 内の各サーバー上でこの制限を構成します。詳細については、「Set-MailboxServer」を参照してください。

この容量計画モデルでは、資本コスト、可用性、およびクライアント パフォーマンス特性のバランスを実現します。

詳細については、「データベース可用性グループの設計例」を参照してください。