可用性に対するサイト復元構成の影響


(この記事は 2014 年 6 月 7  日に The Exchange Team Blog に掲載された記事 Site Resilience Impact on Availability の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

この記事は、以前私が執筆した「データベース可用性グループ (DAG): 可用性の詳しい解説」という記事で行った分析の続編です。

優秀なテクノロジ ソリューションには高レベルの可用性が必須であることは、周知の事実です。そして、ソリューションの可用性を向上させる主要な要素として、簡潔性冗長性の 2 つがあります。これを言い換えると、次のようになります。

  • ソリューションが簡潔な (独立した重要コンポーネントの数が少ない) ほど、ソリューションの可用性は高くなる
  • ソリューションの冗長性が高い (互いに複製可能で冗長な機能を提供する同等のコンポーネントがより多く存在する) ほど、ソリューションの可用性は高くなる

前回の記事では、特定の設計における「計画された」可用性を表す数式をご紹介しました。この分析はデータ センター (サイト) が 1 つの場合について考察したものでしたが、その後、「Exchange の設計にサイト復元構成を導入すると、ソリューション全体の可用性にどのように影響するのか」というご質問をいただいたことがありました。そこでこの記事では、サイト復元構成で Exchange を展開した場合、ソリューション全体の可用性は向上するのか、向上するとしたらどの程度の効果があるのか、またサイト復元構成を採用する価値があるのかどうかについて検討します。

 

データ センターが 1 つの場合のソリューションの可用性

まず、サイトまたはデータ センターが 1 つの場合の重要なポイントについて再度説明します。データ センター内にはソリューションの重要コンポーネントが複数存在し、ソリューション全体の可用性は、「データベース可用性グループ (DAG): 可用性の詳しい解説」で説明した原理により、ソリューションのコンポーネント個々の可用性および冗長性のレベルに基づいて決まります。

ここで最も注目したいことは、可用性は展開されている冗長なデータベース コピーの数に依存するということです。ある単一のデータベース コピーの可用性を A とすると、A = 1–P となります (これにはデータベース コピー、およびそれをホストしているサーバーやディスクの可用性が含まれます)。このとき、データベース コピーの N 個のセットの可用性を A(N) とすると、A(N) = 1–PN = 1–(1–A)N となります。コピーの数が多いほど可用性は向上し、コピーの数が少ないほど可用性は低下します。この式で表される N と A(N) の関係をグラフにすると、次のようになります。

 

Boris1

図 1: 冗長なコピーの数が変化したときの可用性の変化

注: この記事のグラフは、すべてオンライン数学計算エンジンである Wolfram Alpha (英語) を使用して作成しています。

たとえば、A = 90% (上のグラフで使用した値)、N=4 とすると、A(4) = 99.99% となります。

ただし、ソリューション全体には冗長なデータベース コピーのみではなく、Active Directory、DNS、負荷分散、ネットワーク、電源などのさまざまな重要コンポーネントも含まれます。ここでは、展開されるデータベース コピーの数によってこれらのコンポーネントの可用性が変化することはないと仮定して考えます。あるデータ センターにおけるこれらのコンポーネントすべてを含んだ全体の可用性を Ainfra とします。このとき、単一のデータ センターに展開されている N 個のデータベース コピーを持つソリューション全体の可用性を A1(N) とすると、A1(N) = Ainfra×A(N) となります。

たとえば、Ainfra = 99.9%、A = 90%、N=4 の場合、A1(4) = 99.89% となります。

 

サイト復元の追加

データ センターが 1 つの場合のソリューションの可用性を A1 (たとえば、A1 = 99.9% = 0.999) とすると、このときのデータ センターの障害発生率は P1 = 1–A1 (P1 = 0.1% = 0.001) となります。

ここで、2 つ目のサイトまたはデータ センターの可用性を A2 とします (この値は、サイトの構成により、A1 と同じ場合と異なる場合の両方があります)。このとき、障害発生率は、P2 = 1–A2 となります。

サイト復元とは、1 つ目のデータ センターでソリューションに障害が発生した場合に 2 つ目のデータ センターに処理を引き継ぎ、ユーザーへのサービス提供を継続する能力のことです。このため、サイト復元構成のソリューションは、両方のデータ センターに障害が発生した場合にのみサービスを停止します。

両方のデータ センターが互いに完全に独立し、障害の原因となる要素をまったく共有していない場合 (同一の電源やネットワーク コア スイッチなどを使用していないなどの場合)、両方のデータ センターで障害が発生する確率は、P = P1×P2 となります。このとき、2 つのデータ センターに展開されたサイト復元構成ソリューションの可用性は、A = 1–P = 1–(1–A1)×(1–A2) となります。

P1 と P2  はどちらも非常に小さいため、サイト復元構成ソリューションの可用性は、実質的に両方のデータ センターの「9 の数」を足した値となります。つまり、DC1 の可用性がスリー ナイン (99.9%) で DC2 の可用性がツー ナイン (99%) の場合、これを組み合わせたサイト復元構成ソリューションの可用性はファイブ ナイン (99.999%) となります。

これは非常におもしろい結果です。それではここで、ANSI/TIA (Standard TIA-942、英語) および Uptime Institute (英語) によるデータ センター階層の定義をご紹介します。これは、可用性の高さによってデータ センターを 4 つの階層に分類するものです。

データ センター階層の定義

可用性 (%)

階層 1: 基本

99.671%

階層 2: 冗長コンポーネント

99.741%

階層 3: 同時に維持可能

99.982%

階層 4: フォールト トレラント

99.995%

ここまでの説明から考えると、比較的安価な階層 2 のデータ センターを 2 つ展開した場合の方が、高価な階層 4 のデータ センターを 1 つ展開した場合よりもソリューションの可用性が高くなることがわかります。

 

可用性 (%)

データ センター 1 (DC1)

99.741%

データ センター 2 (DC2)

99.741%

サイト復元構成ソリューション (DC1 + DC2)

99.9993%

もちろん、この理論はデータ センター以外にも冗長性コンポーネントに関連するあらゆるソリューションに当てはまります。非常に高い可用性を持つ高価なコンポーネント (ディスク、サーバー、SAN、スイッチなど) を 1 つだけ展開するよりも、適切に冗長性を実装した比較的安価なコンポーネントを 2 ~ 3 個展開した方が、コストを削減しつつより高い可用性が得られることがあります。これが、マイクロソフトが商用のサーバーやストレージで冗長な Exchange 推奨アーキテクチャ (英語) モデルを使用することを推奨する理由の 1 つです。

 

サイト復元の実用上の影響

同一設計のデータ センター 2 つがそれぞれ冗長なデータ センターとして実装されているサイト復元構成ソリューションについて考えます。サイト復元構成の 2 つのデータ センターが存在する場合、データ センターが 1 つのみの場合と比較して優れていることは自明です。では、1 つのサイトに 2 つのデータベース コピーがある場合と、2 つのサイトにそれぞれ 2 つのデータベース コピーがある場合について考えると、この場合後者の方が、可用性が大幅に高いことは自明ですが、それはサイト復元構成よりも、データベース コピーの数が前者の 2 つよりも多い 4 つであることの方が影響しています。

ただし、これでは公平な比較とは言えません。そこで、データベース コピーの合計数が同じであるとして、単一データ センター ソリューションとサイト復元構成ソリューションを比較し、サイト復元構成自体の効果について考えたいと思います。たとえば、1 つのデータ センターに 4 つのデータベース コピーが存在するソリューションと、2 つのサイトにそれぞれ 2 つずつのデータベース コピーが存在するサイト復元構成ソリューション、というような比較です。データベース コピーの合計数は両方とも同じ 4 つになります。このように比較する場合、計算は複雑になります。

ここまでの説明に従って、M 個のデータベース コピーを持つ単一サイト ソリューションの可用性を A1(M) とします (たとえば、A1(4) = 99.9% = 0.999)。このとき、データベース コピーの数が少ない同一ソリューションでは可用性が低くなることは自明です (たとえば、A1(2) = 90% = 0.9)。

2 つ目のサイトも同様とします。データベース コピーの数を N 個とし、可用性を A2(N) とします。

そうすると、次の値を比較する必要があります。

    • (M+N) 個のデータベース コピーを持つ単一サイトのソリューションの可用性: AS = A1(M+N)
    • 1 つ目のサイトに M 個、2 つ目のサイトに N 個のデータベース コピーを持つサイト復元構成ソリューションの可用性:
      ASR = 1–(1–A1(M))×(1–A2(N))

計算を簡単にするために、両方のデータ センターは同等 (A1 = A2) であり、データベース コピーの数も同一である (M=N) とします。そうすると次のようになります。

AS = A1(2N)

ASR = 1–(1–A1(N))2

ここで、A1 = Ainfra×A(N)、A(N) = 1–PN = 1–(1–A)N であり、また各データ センターは同等であるとするため Ainfra の値は同じとなり、次のようになります。

AS = Ainfra×(1–(1–A)2N)

ASR = 1–(1–Ainfra×(1–(1–A)N))2

これら 2 つの値は、Ainfra、A、N の 3 つの変数により決定されます。

これを比較するため、このうちの 2 つの値を固定して、3 つ目の変数の値が変化したときの結果を調べます。

まず、Ainfra と N を固定した場合に、A の変化に応じて可用性がどのように変化するかについて調べます。ここでは、Ainfra= 99% = 0.99、N=2 とします。

 

Boris2

図 2: 単一サイトとサイト復元構成のシナリオでの、冗長なコピーの可用性が変化したときの可用性の変化

青線 (下の曲線) は単一データ センター ソリューションの場合、紫の線 (上の曲線) はサイト復元構成ソリューションの場合を示しています。この図から、サイト復元構成ソリューションは常に、より高い可用性があることがわかります。また、それぞれのデータベース コピーの可用性が 1 に近付いても一定の差があることが見て取れます。これは、別の重要な要素 (Ainfra) が 1 ではないためです。Ainfra の値が高いほど (1 に近いほど)、2 つのソリューションの差は小さくなります。

これに加えて、A と N を固定した場合の Ainfra の変化に応じて可用性がどう変化するかついて調べ、そこから最終的な結論を導きます。A = 0.9、N=2 とします。

 

Boris3

図 3: 単一サイトとサイト復元構成のシナリオでの、データ センターのインフラストラクチャの可用性が変化したときの可用性の変化

この結果からも、サイト復元構成ソリューションは常に、より高い可用性を示すことがわかります。ただし、この 2 つの可用性の差は 1–Ainfra の値に比例し、Ainfra が限りなく 1 に近付くとその差はなくなります。これにより、すぐに結論が出せます。

つまり、100% の可用性を持つ単一のデータ センターが存在する場合、サイト復元構成ソリューションは不要ということです。実際に計算を行わなくても、おわかりいただけるかと思います。

以下の表に、可用性を比較した計算結果を示します。

1 つのコピーの可用性

90.000%

データ センターのインフラストラクチャの可用性 (Ainfra)

99.900%

 

サイト復元構成の影響

コピーの数/サイト

可用性 (%)

データ センターが 1 つ

4

99.890010%

データ センターが 2 つ

2

99.987922%

(1-Ainfra) による差

0.100%

0.097912%

こちらの簡単な Excel スプレッドシート (英語) では、Ainfra、A、および N (赤字になっています) の値を変化させると可用性がどのように変化するかをご確認いただけます。

まとめ

サイト復元設計の展開によりソリューションの可用性は向上しますが、単一のデータ センターそれ自体の可用性が高い場合、サイト復元構成のメリットは小さくなります。

前述の Excel シートの数式に適切な値を入力すると、特定のシナリオにおける正確な可用性を計算できます。

: 誤解のないように記しておきますが、ここまでに説明した内容は、すべて計画された可用性に関するものです。この説明の理論値は、特定のソリューションにおける期待値を表しています。一方、実際に観察される可用性は統計的な結果であり、この説明における可用性の理論値と異なる場合があります。ただし、長期間監視を続けると、その平均値は理論値に近付きます。

謝辞: マイクロソフトの世界的メッセージング コミュニティでディレクターを務める Ramon Infante と、ソリューション アーキテクト兼米国メッセージング コミュニティ リードを務める Jeffrey Rosen との刺激的な議論が参考になりましたことを、ここに感謝いたします。

Boris Lokhvitsky
デリバリ アーキテクト
マイクロソフト コンサルティング サービス

Skip to main content