[Windows Azure] 更新ドメインと障害ドメインについて


こんにちは、Windows Azure デベロッパー サポート チームです。

今回は、時々ご質問として伺う「障害ドメイン(停止ドメイン)」と「更新ドメイン」の動作についてお伝えします。「障害ドメイン」については、下記のブログの情報が参考になりますが、英語で記載されておりますので担当者 (Toddy Mladenov) の許可をもらって翻訳しました。

Upgrade Domains and Fault Domains in Windows Azure
http://blog.toddysm.com/2010/04/upgrade-domains-and-fault-domains-in-windows-azure.html

※Fault Domain は、ドキュメントによって停止ドメインと記述されることもありますが、本文章では「障害ドメイン」に統一しています。


<以下翻訳>

Windows Azure の更新ドメインと障害ドメインについて

時々「障害ドメイン (Fault Domain) とは何か」という質問をWindows Azure フォーラムで目にします。この理由は Windows Azure SLA に以下のような記述があるためのようです。

コンピューティングにおいて複数のロール インスタンスを別々の障害ドメイン (Fault Domain) および更新ドメイン (Upgrade Domain) に展開した場合、インターネット用のロールの外部接続の稼働率が 99.95% 以上になることをマイクロソフトでは保証しています。…

更新ドメインは、Windows Azure ではかなり良く知られた概念ではありますが、その一方で障害ドメインはあまり目にしないものだと思います。そのため、定義について明確化しておく必要があります。

障害ドメインと更新ドメインの定義

障害ドメインと更新ドメインの簡単な定義をここに示しておきます。

  • 障害ドメインは、障害の物理的な単位であり、データセンター内の物理的なインフラにかなり関係しています。Windows Azure では、サーバーラックが障害ドメインと言えるでしょう。しかし、実際には障害ドメインとサーバーラックが完全に一対一対応しているわけではありません。
    Windows Azure Fabric は、異なる障害ドメインにアプリケーション インスタンスを配置する責任があります。現状、Fabric はあなたのアプリケーションに少なくとも 2 つの障害ドメインを割り当てるはずです。しかし、キャパシティと VM の可用性の考慮によっては、今後はそれ以上に膨らむ可能性もあります。
    また現時点では、開発者から直接障害ドメインの数をコントロールすることはできません。これは、もし構成ができてしまうと、アプリケーションの可用性に影響を及ぼす可能性があるからです。
  • 更新ドメインは、特定のサービスがどのようにアップグレードされるかを決定する論理ユニットです。配置したアプリケーションに設定される既定の更新ドメインの数は 5 です。いくつの更新ドメインを使うかについては、サービス定義ファイル (*.csdef) 内の upgradeDomain 構成で変更可能です。

障害ドメインと更新ドメインの動作について

Windows Azure 運用者にとって重要なことは、常にアプリケーションが立ち上がり、動作していることだと思いますが、インフラはかなり抽象化されているので、アプリケーションが構成されるときに、どのような動作をしているかについてほとんど分からないでしょう。

そのため、ここで簡単な例を挙げて、この 2 つの概念を説明しようと思います – Hello World サンプルです。Hello World サンプルは、1 つの Web ロールをもち、既定でたった 1 つのインスタンスを持っています。このような構成の場合は、99.95% の可用性は保証できません。なぜかというと、答えはとてもシンプルです。1 つのインスタンスしかないため、物理的にそれを2つの障害ドメインと更新ドメインに配置することができないからです。それゆえSLAは、「99.95%の可用性を保証するためには 2 つ以上のインスタンスを配置する必要があります」と記述しています。

もし、Hello World サンプルのインスタンスを2つにして再配置した場合には、アプリケーションが 2 つの障害ドメインに配置されるのがわかるでしょう。ここで、Hello World の2つのインスタンスがどのように配置されるか見てみます。

  障害ドメイン #1 障害ドメイン #2
更新ドメイン #1 インスタンス #1  
更新ドメイン #2   インスタンス #2

この場合、もし障害ドメイン #1 で障害発生したとしても、障害ドメイン #2 に存在するインスタンス #2 が継続して利用可能です。もちろん、Fabric がインスタンス #1 の反応がないことに気付いた場合には、アプリケーションを障害ドメイン #2 と異なる障害ドメインに新しい VM を配置するでしょう。

これはかなり簡単な例ですが、より興味深いものとしては、ロールに2つ以上のインスタンスを割り当てた時の動作があるでしょう。この場合、どのようにアプリケーションを配置するか決定するかは、Windows Azure Fabric アルゴリズム次第です。3 インスタンスを配置した場合の可能性として 2 つの選択肢があります。(更新ドメインの数は既定の 5 のままです)

選択肢#1

  障害ドメイン #1 障害ドメイン #2 障害ドメイン #3
更新ドメイン #1 インスタンス #1    
更新ドメイン #2   インスタンス #2  
更新ドメイン #3     インスタンス #3

選択肢#2

  障害ドメイン #1 障害ドメイン #2
更新ドメイン #1 インスタンス #1  
更新ドメイン #2   インスタンス #2
更新ドメイン #3 インスタンス #3  

選択肢#1 はより良いように見えますが、利用可能でない場合があります。また、配置処理が動作するクラスタの状況にかなり依存してしまいます。割り当ての組み合わせは、1 つ以上のロール (Web、Worker もしくはその組み合わせ) を利用することを考えると、さらに多くの場合が考えられます。

障害ドメインと更新ドメインの情報取得

Windows Azure SDK は、障害ドメインと更新ドメインの情報を取得するためのプロパティを用意しています。RoleInstance クラスは FaultDomain と呼ばれるプロパティを持っています。このプロパティにより、ロール インスタンスが動作している障害ドメインを取得することが可能です。しかし注意点があり、FualtDomain プロパティを呼び出すことで、0か1のどちらかしか取得可能ではありません。これは、アプリケーションに対して 2 つの障害ドメインしか付与されていないためです。もし、アプリケーションがさらに多くの障害ドメインに配置されている場合には、FaultDomain プロパティを使って決定はできないでしょう。

同じクラスに、UpdateDomain があります。これを使うことで、ロールインスタンスがどの更新ドメインで動いているか確認することができます。上述の通り、障害ドメインについてはコントロールができませんが、*.csdef ファイル中の ServiceDefinition 要素の upgradeDomainCount 属性をつかって、更新ドメインの数を変更できます。

障害ドメインと更新ドメインのガイドライン

アプリケーションを構成する際に使える一般的なガイドラインについて紹介します。

  • Fabric のアルゴリズムを考慮に入れてください。
    1. あらゆる2つのロールインスタンスは、異なる障害ドメイン上にあることが必要なため、それらは異なるラック上のノード (もしくは物理的なマシン) 上に配置されています。
    2. あらゆる2 つのロールインスタンスは、異なる更新ドメイン上にあることが必要なため、それらは異なるノード(もしくはマシン)上に配置されています。
    3. もし、2 つのロールインスタンスが同じ障害ドメインにある場合は、それらは同じラック上に存在するかもしれないし、存在しないかもしれません。
  • 冗長化を考慮に入れて、常にアプリケーションを配置してください。これはすなわち、各ロール毎に少なくとも 2 インスタンスを設定することを意味しています。
  • アプリケーションを構成するときには、常にアプリケーションの性能と可用性の要件を考慮に入れて構成してください。

Update (2011/3/17)

このブログ ポストを記述した時点では、次の記述を「障害ドメインと更新ドメインの定義」の部分に記載していました:「Windows Azure Fabric は、特定の更新ドメインが単一の障害ドメインに存在しないことを保証しています (図を見てください)」Fabric チームとの議論の後で、図とともにこの記述の削除を決めました。というのも、この説明は、更新ドメインが常に障害ドメイン中にばらまかれる印象を与えかねないからです。更新ドメインと障害ドメインは、はっきりと異なる概念であり、単一の更新ドメインは複数の障害ドメインに及ぶ可能性がありますが (同じように、複数の更新ドメインは、単一の障害ドメインに生存する可能性があります)、単一の更新ドメインのすべてのインスタンスが異なる障害ドメインに配置されることを保証するものではありません。最適化の目的から、Fabricは更新ドメインに存在するすべてのインスタンスを、リソースが利用可能であれば、1つの障害ドメインに配置することがあります。


補足

以上が翻訳の内容です。「障害ドメインと更新ドメイン」についてよく質問をいただく内容を、少しだけ補足しておきます。

障害発生時や OS 更新時に、Windows Azure 管理ポータルで更新対象のインスタンスを含むロールの状態が、Ready から他の状態に変わっていることがあります (Updatingなど)。しかし、この時はロールが停止していて、すべてのインスタンスで障害発生していたりアップグレードされていたりするわけではありません。2つ以上のインスタンスが配置されている場合、Web Role の場合はロールの状態が Ready でなくても、接続することができます。また、Worker Role の場合も、生きているインスタンスが動作しています。

※この情報は 2011/6/10 時点での情報です。内部的なアップデートなどにより情報が変わる可能性もありますが、ご参考にしていただければ幸いです。


デベロッパー サポート
平原

Comments (0)

Skip to main content