データベース可用性グループ (DAG): 可用性の詳しい解説

Artikel
11/16/2011

原文の記事の投稿日: 2011 年 9 月 16 日 (金曜日)

定義

Microsoft Exchange の世界では DAG が "データベース可用性グループ" (Database Availability Group) を表すことは、きっとご存知でしょう。

データベース - 可用性の高い Exchange 2010 メールボックスサーバー上にあることから、データベース (サーバーではありません) は可用性の単位になっています。データベースは、同じ DAG 内にある複数のサーバー間でフェールオーバーや切り替えができます。この概念をデータベースのモビリティといいます。

グループ - 可用性のスコープは、フェールオーバークラスター内で結合され、グループとして連携して動作する、同じ DAG 内にあるメールボックスサーバー群によって決定されます。

可用性 - ここで最も不明瞭でわかりにくいのがこの用語です (上の 2 つの用語の説明にも出てきます)。ただし、数学的には明確な定義があり、Exchange の全体的な設計原理を理解するうえで重要な役割を果たします。

Wikipedia の定義によれば、"可用性" は次のどちらかを意味します。

システム、サブシステム、または機器が、未知、つまりランダムなタイミングで実行が指示されるミッションの開始時点で、操作可能かつ作業を委ねることができる特定の状態にある度合い。簡単にいうと、可用性とはシステムが正常に機能する状態にある時間の割合である。ミッション遂行可能率とも呼ばれる。数学的には、1 - 非可用性 (英語)と表せる。
(a) 機能ユニットが使用可能な状態にある時間の合計と (b) 全体の時間の比。

確率論の用語を使用すると、これらの定義はどちらも同じ意味になり、次のように表現できます。システムまたはコンポーネントが任意の時点で (テスト実施時に) "操作可能" または "使用可能な状態" にある (つまり使用できる) 確率。

数学的には、統計的に十分に長い期間 (たとえば 1 年) をとってシステムが使用可能な状態にある時間 (アップタイム) の合計値を計算し、その値を期間全体の長さで割ることで、可用性を計測できます。広く採用されている用語である平均故障間隔 (MTBF、システムの可用性に関する指標 / システムが故障してから次に故障するまでのアップタイム) と平均修復時間 (MTTR、システムが故障した場合のダウンタイム) を使用すると、可用性 A は次のように表せます。

これと反対の数学的特性として障害の発生率があります ("使用可能でない度合い" と見なせます)。

次の表に示すように、可用性は "9 の桁数" として表されることがよくあります。

可用性のレベル	可用性の値	障害の発生率	1 年あたりの許容ダウンタイム
トゥーナインズ	99%	1%	5256 分 = 3.65 日
スリーナインズ	99.9%	0.1%	525.6 分 = 8.76 時間
フォーナインズ	99.99%	0.01%	52.56 分
ファイブナインズ	99.999%	0.001%	5.26 分

もちろん、可用性の値は、スケジュールされた (計画された) ダウンタイムとスケジュールされていない (計画されていない) ダウンタイムの両方を考慮するか、スケジュールされていないダウンタイムのみを考慮するかによって変わってきます。企業の可用性についての要件を表すサービスレベルアグリーメントは、可用性に関して非常に具体的なものでなくてはなりません。しかし、どのような場合でもシステムやコンポーネントの可用性は多数の要因に依存しているので、こうした依存関係と可用性に対するそれらの影響を明らかにして理解することがきわめて重要です。

サービスの依存関係が可用性に与える影響

Exchange メールボックスデータベースは、他の多くのサービスやコンポーネントの可用性に依存しています。そうしたコンポーネントの例として、データベースをホストする記憶域サブシステム、このデータベースを運用するサーバー、このサーバーへのネットワーク接続などがあります。これらはすべて重要なコンポーネントであり、どれか 1 つでも障害が発生すると、たとえデータベースそのものが完全に正常な状態であってもサービスは立ち行かなくなります。つまり、データベースをサービスとして利用できるようにするには、データベースの依存関係もすべて使用可能でなければなりません。依存関係のあるコンポーネント群を適切に特定して分離すれば、それらが Exchange データベース自体の最終的な可用性にどのように影響するかを数学的に計算できます。

Exchange メールボックスデータベースでは、以下のコンポーネントが重要な依存関係と考えられます。

データベースディスク/記憶域サブシステム - このコンポーネントの可用性を A₁ とします。
メールボックスサーバー (ハードウェアとソフトウェアの両方のコンポーネント) - このコンポーネントの可用性を A₂ とします。
クライアントアクセスサーバー (ハードウェアとソフトウェアの両方のコンポーネント) - Exchange 2010 では、すべてのクライアントがクライアントアクセスサーバー (CAS) のみを介してメールボックスデータベースに接続します。ここでは、CAS がメールボックスサーバーとは別の場所にインストールされていると仮定します。このコンポーネントの可用性を A₃ とします。
クライアントとクライアントアクセスサーバー間、およびクライアントアクセスサーバーとメールボックスサーバー間のネットワーク接続 - こうした接続の可用性を A₄ とします。
サーバーや記憶域が置かれているデータセンター内の電源 - このコンポーネントの可用性を A₅ とします。

このリストはまだ続くことがあります。たとえば、Active Directory や DNS も Exchange にとって重要な依存関係です。また、純粋にテクノロジに関する依存関係だけでなく、操作の成熟度といったプロセスの依存関係も可用性に影響します。ヒューマンエラー、適切に定義されていない操作、チームの連携不足はいずれもサービスのダウンタイム発生につながる可能性があります。ただし、ここでは依存関係の膨大なリストを作り上げようとしているわけではなく、それらがサービス全体の可用性にどのように影響するのかに注目します。

これらのコンポーネントそのものは互いに独立しているので、それぞれの可用性は個別の事象に対応しており、Exchange メールボックスデータベースの最終的な可用性はそれらの事象すべての組み合わせに対応しています (つまり、クライアントからメールボックスデータベースを利用できるためには、これらのコンポーネントのすべてが使用可能でなければなりません)。確率論によれば、個々の事象の組み合わせが生じる確率は各事象の確率の積となります。

たとえば、3 枚のコインを投げてそのすべてが表になる確率は、(1/2)*(1/2)*(1/2) = 1/8 です。

次の点を理解しておくことが重要です。個々の可用性の値が 1 (つまり 100%) を超えることはなく、結果として得られるサービスの可用性は単純に各コンポーネントの可用性の積になるので、最終的な可用性の値は、依存するコンポーネントのうちで最低の可用性の値を超えることはありません。

このことは、次の表に示す例で説明できます (以下の数値は例であり、現実的なものではありません)。

重要な依存コンポーネント	障害の発生率	可用性の値
メールボックスサーバーと記憶域	5%	95%
クライアントアクセスサーバー	1%	99%
ネットワーク	0.5%	99.5%
電源	0.1%	99.9%
サービス全体 (上記の全コンポーネントに依存)	6.51383%	95% x 99% x 99.5% x 99.9% = 93.48617%

この例から、サービスの依存関係がいかに重要であるかがわかります。絶対にメールボックスデータベースに障害が発生しない (決して破損したりウイルスに感染したりしない) 場合であっても、可用性はせいぜい 93.5% にしかならないのです。

結論: サービスの依存関係の数が多いと可用性は低下する。

サービスの依存関係の数または影響を減らすためにできることは何であれ、サービス全体の可用性にプラスの影響を与えます。たとえば、サーバー管理の簡素化、セキュリティ保護、操作手順の最適化により、操作の成熟度を向上できます。技術的な面では、設計を単純にすることでサービスの依存関係の削減を試みることができます。たとえば、HBA カード、ファイバースイッチ、アレイコントローラー、さらに RAID コントローラーを含む複雑な SAN ベースの記憶域設計を排除し、可動部分を最小限に抑えた単純な DAS 設計でそうした設計を置き換えるといった具合です。

サービスの依存関係の削減だけでは、望ましいレベルの可用性が得られない場合があります。もう 1 つ、最終的な可用性を高めて重要なサービス依存関係の影響を最小化する非常に効果的な方法は、さまざまな冗長化手法を利用することです。たとえば、デュアル電源の使用、ネットワークカードの連携、複数のネットワークスイッチへのサーバーの接続、オペレーティングシステムの RAID 保護の使用、クライアントアクセスサーバー用の負荷分散装置と複数のメールボックスデータベースの展開などがあります。しかし、具体的にどのようにして冗長性が可用性の向上につながるのでしょうか。以下では、重要な例として、負荷分散と複数のデータベースコピーについて詳しく説明します。

冗長性が可用性に与える影響

概念的には、すべての冗長化手法のねらいは同じです。それは、他のインスタンスとの並列的使用 (負荷分散の場合) または代替使用 (データベース冗長化の場合) に利用できるコンポーネントのインスタンスを 2 つ以上用意することです。ここでは、あるコンポーネントのインスタンスが n 個あるとします (CAS アレイ内にある n 台のサーバー、DAG 内にある n 個のデータベースコピーなど)。たとえその 1 つに障害が発生しても、その他のインスタンスが使用できれば、可用性は維持されます。実際にダウンタイムが発生する唯一の状況は、すべてのインスタンスに障害が発生した場合です。

先ほど定義したように、特定のインスタンスで障害が発生する確率は、P = 1 - A です。すべてのインスタンスは統計的に互いに独立しているので、どのインスタンスの可用性や障害も他のインスタンスの可用性には影響しません。たとえば、データベースの特定のコピーの障害が、そのデータベースの別のコピーで障害が発生する確率に影響することはありません (最初のデータベースコピーの破損に起因した論理データベースの破損が他のすべてのコピーに伝播することはありますが、その可能性はきわめて低いのでここでは無視します。どちらにせよ、遅延を伴うデータベースコピーや従来の特定時点でのバックアップを使用すれば、この問題は必ず解決できます)。

前述の確率論の定理を再び使用すると、独立した n 個のコンポーネント群に障害が発生する確率は、各コンポーネントの障害発生確率の積になります。ここでは、すべてのコンポーネントがまったく同一のもの (同じオブジェクトから生成される別々のインスタンス) なので、この積は次のようなべき乗になります。

P < 1 なので、Pⁿ が P より小さいことは明らかです。つまり、障害が発生する確率は低下し、これに伴い可用性は向上します。

理解を深めるために現実的な例を考えましょう。たとえば、メールボックスデータベースの複数のコピーを展開するとします。各コピーは同じ SATA ドライブ上でホストされています。統計的に SATA ドライブの 1 年間の障害発生率は ~5% [1] なので、ここでは障害の発生する確率を 5% とします。つまり、P = 0.05 です (これは可用性が 95%、つまり A = 0.95 であることを意味します)。データベースのコピーを追加すると、可用性はどのように変化するでしょうか。次の表を見れば、その答えは明らかです。

データベースのコピーの数	障害の発生率	可用性の値
1	P₁ = P = 5%	A₁ = 1 - P₁ = 95%
2	P₂ = P² = 0.25%	A₂ = 1 - P₂ = 99.75%
3	P₃ = P³ = 0.0125%	A₃ = 1 - P₃ = 99.9875%
4	P₄ = P⁴ = 0.000625%	A₄ = 1 - P₄ = 99.9994%

とても興味深い結果です。基本的に、SATA ドライブ上にデータベースコピーを追加するたびに、5% つまり 1/20 の係数が掛けられるので、障害の発生確率はコピーが増えるたびに 1/20 になります (したがって、可用性は向上します)。信頼性の低い SATA ドライブの場合でさえ、データベースのコピーを 4 つ展開するだけでデータベースの可用性がファイブナインズのレベルに達することがわかります。

もうこれで十分といえますが、もっと良い結果を得るにはどうしたらよいでしょうか。また、(たとえば、データベースのコピーをこれ以上追加できないような場合に) アーキテクチャを変更せずに可用性をさらに高めることは可能でしょうか。

実はできます。依存関係のあるコンポーネントのそれぞれの可用性を高めれば、サービス全体の可用性は向上し、冗長なコンポーネントを追加することで、その効果はさらに増大します。たとえば、費用を抑えてこれを実行するために取り得る方法の 1 つは、SATA ドライブの代わりに Nearline SAS ドライブを使用することです。Nearline SAS ドライブの年間障害発生率 (AFR) は、SATA の場合の ~5% に対し、~2.75% です。これにより、先ほどの計算における記憶域コンポーネントの障害発生の確率は減少し、サービス全体の可用性が向上します。それでは、データベースコピーの追加による影響を比較してみましょう。

AFR: 5% = 乗算係数: 1/20 = 新たなコピーを追加するたびにデータベースの障害発生の確率は 1/20 になる。
AFR: 2.75% = 乗算係数: 1/36 = 新たなコピーを追加するたびにデータベースの障害発生の確率は 1/36 になる。

また、データベースコピーの追加がデータベースの可用性に及ぼすこうした大きな影響力は、Exchange のネイティブデータ保護の使用に関する当社のガイダンスにある "十分な数 (3 つ以上) のデータベースコピーが展開されている場合は、それらのコピーが従来のバックアップの代替になり得る" という記述の根拠にもなっています。

同様の考え方は、1 つの CAS アレイ内に複数のクライアントアクセスサーバーを展開する場合や、複数のネットワークスイッチを用意する場合にも当てはまります。ここでは、4 つのデータベースコピーと 4 台のクライアントアクセスサーバーを展開していると仮定し、前に分析したコンポーネントの可用性の表について改めて考えてみましょう。

重要な依存コンポーネント	障害の発生率	可用性の値
メールボックスサーバーと記憶域 (4 つのコピー)	5% ^ 4 = 0.000625%	99.999375%
クライアントアクセスサーバー (個別に設置された 4 台のサーバー)	1% ^ 4 = 0.000001%	99.999999%
ネットワーク	0.5%	99.5%
電源	0.1%	99.9%
サービス全体 (上記の全コンポーネントに依存)	0.6%	99.399878%

4 台のクライアントアクセスサーバーと 4 つのデータベースコピーを展開しただけで、サービス全体の障害発生の確率が 1/10 (6.5% から 0.6%) になり、これに伴ってサービスの可用性が 93.5% から 99.4% というずっと良好な値になることがわかります。

結論: サービスの依存関係に冗長性を追加すると可用性は向上する。

手法の組み合わせ

これまでの結論から、ある興味深い疑問が生じます。サービス全体の可用性に対してそれぞれ違った形で影響を与える 2 つの異なる要因を分析し、次の 2 つの明確な結論が得られました。

システムの依存関係を増やすと可用性は低下する
システムの依存関係に冗長性を追加すると可用性は向上する

では、両方の要因を組み合わせて 1 つの解決策にするとどうなるでしょうか。どちらの傾向がより強く現れるのでしょうか。

次のシナリオを考えます。

2 台のメールボックスサーバーを 1 つの DAG 内に展開して 2 つのメールボックスデータベースコピーを用意し (各サーバーに 1 つのコピー)、2 台のクライアントアクセスサーバーを 1 つの負荷分散アレイ内に展開します (話を簡単にするために、クライアント接続用のメールボックスデータベースの可用性のみを考慮し、ここではハブトランスポートやユニファイドメッセージングを考慮しないことにします)。どのサーバーについても障害の発生する確率が P である場合、こうしたシステムの可用性は、メールボックスサーバーとクライアントアクセスサーバーの双方の役割が展開された 1 台のスタンドアロン Exchange サーバーの可用性よりも高くなるでしょうか、それとも低くなるでしょうか。

最初のシナリオでは、それぞれのメールボックスサーバーが独立しており、メールボックスサーバーが使用できなくなるのは両方のサーバーに障害が発生した場合のみです。2 台のメールボックスサーバーのセットに障害が発生する確率は、P × P = P² となります。したがって、その可用性は、A_MBX = 1 - P² となります。同様に、CAS サーバーが使用できなくなるのは両方のクライアントアクセスサーバーに障害が発生した場合に限られるため、2 台のクライアントアクセスサーバーのセットに障害が発生する確率もまた P × P = P² となり、その可用性は A_CAS = 1 - P² となります。

既におわかりの方もいるでしょうが、この場合は 2 台のメールボックスサーバーまたは 2 台のクライアントアクセスサーバーが冗長なシステムコンポーネントの例になっています。

引き続き、このシナリオについて考えます。システム全体が使用できるためには、両方のサーバーセット (メールボックスサーバーのセットとクライアントアクセスサーバーのセット) が共に使用可能でなければなりません。共に障害が発生している状態ではなく、共に使用可能な状態です。というのも、ここでは両セットが冗長なコンポーネントではなく、システムの依存関係に相当するからです。つまり、サービス全体の可用性はそれぞれのセットの可用性の積になります。

2 番目のシナリオでは、考慮すべきサーバーが 1 台しかないので話はもっと簡単で、その可用性は単純に A = 1 - P となります。

これで両方のシナリオについて可用性の値を計算できましたが、値がより大きいのは (1 - P²)² と 1 - P のどちらでしょうか。

両関数のグラフをプロットすると、次のように値が変化することがわかります。

(短時間で簡単にプロットを行うために、フリーの計算エンジンである Wolfram Alpha Mathematica Online を利用しました)。

P の値が小さい場合は、4 台のサーバーによる複雑なシステムの可用性が単一サーバーの可用性よりも低いことがわかります。これは意外でも何でもなく、予想どおりの結果です。しかし、P ~ 0.618 (正確には、) で 2 つのプロットは交差し、さらに P が大きくなると、単一サーバーシステムの可用性のほうが高くなります。もちろん、現実の世界では P の値がかなり 0 に近くなると予想されます。ただし、非常に信頼性の低いコンポーネントでソリューションを構築しようとする場合は、おそらく単一サーバー構成のほうが好ましいでしょう。

障害ドメインの影響

残念ながら、現実の世界での展開シナリオがこれまでに述べた状況のように単純なことはまれです。たとえば、複数の役割を持つサーバーを展開した場合、サービスの可用性はどのように変化するでしょうか。先ほどのシナリオでは、サーバーの役割を統合すると事実上サービスの依存関係の数が減少することがわかりましたが、これは好ましいことなのでしょうか。同じデータベースの 2 つのコピーを同じ SAN アレイまたは DAS エンクロージャ上に配置した場合はどうでしょうか。すべてのメールボックスサーバーが同じネットワークスイッチに接続されている場合はどうでしょうか。さらに、こうしたすべての条件を組み合わせた場合はどうなるのでしょうか。

これらの状況はすべて障害ドメインの概念に対処するものです。上記のそれぞれの例では、サーバーのハードウェア、SAN アレイ、およびネットワークスイッチが障害ドメインに相当します。障害ドメインにより、そのドメインで結合された各コンポーネントの独立性または冗長性は失われます。たとえば、複数の役割を持つサーバーのハードウェアに障害が発生すると、このサーバー上にある Exchange のすべての役割が使用できなくなります。また、ディスクエンクロージャまたは SAN アレイに障害が発生すると、そのエンクロージャ上でホストされているすべてのデータベースコピーが使用できなくなります。

障害ドメインは必ずしも悪いものではなりません。重要なのは、障害ドメインを構成するコンポーネントの種類の違いです。つまり、それらが別々のシステム依存関係なのか、それとも冗長なシステムコンポーネントなのかが重要になります。この違いを理解するために、以下では先ほどの 2 つの例を考えます。

複数の役割を持つサーバーのシナリオ

次の 2 種類のシステムの可用性を比較します。

ハードウェア障害の発生確率が P である 1 台のサーバーでメールボックスサーバーとクライアントアクセスサーバーの両方の役割をホストする場合
ハードウェア障害の発生確率が同じく P である 2 台のサーバーで上記の役割を別々にホストする場合

最初のケースでは、単一サーバーのハードウェアが障害ドメインに相当します。つまり、ホストされている役割は、すべてが使用できるか、すべてが使用できないかのどちらかです。この場合は単純で、そうしたシステムの全体的な可用性は、A = 1 - P となります。

2 番目のケースでは、サービス全体が使用できるのは、(それぞれの役割が重要な依存関係になっているので) 両方のサーバーがどちらも使用できる場合に限られます。したがって確率論により、サービスの可用性は、A × A = A² となります。

ここでも A < 1 なので、A² < A となり、2 番目のケースの可用性のほうが低くなります。

もちろん、この考え方は、同じシナリオにその他の Exchange サーバーの役割 (必要に応じて、ハブトランスポート、ユニファイドメッセージングなど) を追加した場合にも当てはまります。

結論: Exchange サーバーの役割を併置して 1 台のサーバーに複数の役割を持たせるとサービス全体の可用性は向上する。

共有記憶域のシナリオ

ここでは、障害ドメインに関する別のシナリオ (同じ記憶域アレイを共有する 2 つのデータベースコピー) を検討し、次の 2 つのケースでデータベースの可用性を比較します。

障害の発生する確率が P である共有記憶域 (SAN アレイまたは DAS エンクロージャ) で 2 つのデータベースコピーをホストする場合
障害の発生する確率が同じく P である 2 つの記憶域システムで上記のデータベースコピーを別々にホストする場合

最初のケースでは、共有記憶域が障害ドメインに相当します。先ほどのシナリオと同様、両方のデータベースコピーが共に使用できるか、共に使用できないかのどちらかなので、やはり全体の可用性は、A = 1 - P となります。

2 番目のケースでは、少なくとも一方のシステムが使用可能であればサービス全体を使用でき、サービス全体が使用できなくなるのは両方のシステムに障害が発生した場合に限られます。問題の記憶域システムは互いに独立しているので、サービス全体としての障害が発生する確率は、P × P = P² です。よって、サービス全体の可用性は、A = 1 - P² となります。

やはり P < 1 なので、P² < P となります。したがって、1 - P² > 1 - P であり、これは 2 番目のケースの可用性のほうが高いことを意味します。

結論: データベースのコピーを同じ記憶域システム上に併置するとサービス全体の可用性は低下する。

それでは、この 2 つのシナリオの違いはどこにあるのでしょうか。また、障害ドメインの導入により、第 1 のシナリオでは可用性が向上し、第 2 のシナリオでは可用性が低下するのはなぜでしょうか。

その理由は、第 1 のシナリオの障害ドメインではサービス依存関係の結合によって事実上それらの数が減少し、結果として可用性が向上するのに対し、第 2 のシナリオの障害ドメインでは冗長なコンポーネントの結合によって冗長性が事実上低下し、結果として可用性も低下するからです。

これまでのすべての概念および結論は、おそらく次のように視覚的に表現できます。

(この図の描画には Wolfram Alpha を使用していません)。

まとめ

Exchange 2010 のアーキテクチャには、Exchange レベルで冗長性を追加したり (複数のデータベースコピーの展開、CAS アレイ内での複数のクライアントアクセスサーバーの展開など)、(1 台のサーバーへの Exchange サーバーの複数の役割の統合や、重要コンポーネントの数を抑制しながらの記憶域アーキテクチャの単純化によって) システムの依存関係の数を削減したりできるというすばらしい可能性があります。この記事で説明した簡単な規則と数式を使用すれば、展開するデータベースコピーの追加や Exchange サーバーの役割の統合によって可用性の値がどんな影響を受けるのかを計算できます。また、障害ドメインの影響も計算できます。重要なのは、可用性の厳密な値を求めることではなく、こうした単純な数学的モデルを使用して概念を説明しようとしたことです。現実の世界が単純で基本的なシナリオに当てはまることは滅多にないので、実際のシステムの可用性に対する妥当な推測値を得るにはもっと複雑な計算が必要になります。そのため、統計的な手法で可用性を単純に計測し、その結果が SLA 要件を満たすかどうかを検証したほうが簡単な場合があります。ただし、可用性に影響する要因と、複雑な工学的ソリューションにおけるそれらの相互作用を理解しておけば、そうしたソリューションを適切に設計し、サービス全体の可用性の大幅な向上によって非常に厳しいビジネス要件を達成するうえできっと役立つはずです。

Boris Lokhvitsky
デリバリーアーキテクト

[1] カーネギーメロン大学、Google、および Microsoft Research による調査によれば SATA ドライブの AFR は 5%。

https://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf (英語)

https://labs.google.com/papers/disk_failures.pdf (英語)

https://research.microsoft.com/apps/pubs/default.aspx?id=64599 (英語)