Windows Azure の仮想マシンは HAVM

  • Article

まずは地上の話から

※ この記事での「仮想マシン」はIaaS機能としてのWindows Azure Virtual Machinesのことではなく、一般名詞としての「仮想マシン」です。

タイトルにある”HAVM”ってなんだよ？多くの方が思われるでしょうから、この用語から説明します。コンピューティングの一般用語ではなく、マイクロソフト用語です。

弊社の仮想化プラットフォーム Hyper-V では、Hyper-VホストをWSFCでクラスタ化し、その上に仮想マシンを載せることで、「物理サーバーの障害時に、クラスタ内の別ノード(Hyper-Vホスト)へ移動する仮想マシンを作ることができます。これを高可用仮想マシンとか、HAVMと呼んでいます。

また、このシステム構成を「Hyper-Vホストクラスタリング」と呼びます。他の仮想化製品でいうと、VMware HAのようなものです。仮想マシン自体はスタンドアロン構成でも、その土台となるホスト部分が冗長化されているので、単純な一台のサーバーよりは可用性が高まるという寸法です。しかもゲストOSやその上のアプリケーションは、自分がクラスタ上で動いていることを全く意識する必要がありません。お手軽高可用構成というわけです。

そしてクラウドへ

世界最大のHyper-V事例ともいえるWindows Azure上の仮想マシン群も、実は「別ノードへ移動できるVM」なのです。
サーバーのハードウェア障害が検出されると、仮想マシンは別のノードへ移行され、ハードウェア障害の回復を待たずに稼働を継続します。

しかしこの仕組み、我々は割と普通のことだと思ってあまり強調していなかったせいか、実は意外と知られていないのでは？と感じることが最近何度かありました。そこで、こうしてブログに書いてみたわけです。

そして、こういうのは私が一生懸命しゃべるより、Mark Russinovichの資料↓を見ていただく方が説得力があるというもの。

“Windows Azure Internals”
https://video.ch9.ms/teched/2012/eu/AZR302.pptx

2012年のTech Edで使われた資料です。ちょっと引用しながら説明を試みます。

「クラスタ」

imageスライド6: Datacenter Clusters

Windows Azureのデータセンターは「クラスタ」の集まりです。この「クラスタ」は、私の大好きなWSFC (Windows Server Failover Cluster) のことでも、これまた私の好物である Windows HPC によるクラスタのことでもありません。Windows Azure固有の概念です。1クラスタあたり約1000ノードあるというからなかなか大きいですね。このクラスタが、Windows Azureのデータセンターにはなんとｎ個も並んでいるというわけです。

「ファブリックコントローラ (FC)」

そして、これらクラスタを管理しているのが、ファブリックコントローラ (FC)というソフトウェアです。FCはクラスタ毎に存在します。では、クラスタの中をもう少し詳しく見ましょう。次のスライドは、データセンタ内に複数存在するクラスタのうち、一つを選んでその中を解説したものです。

image
スライド7: Inside a Cluster

クラスタは複数のサーバーラックからなっているのがわかります。そして、FCは各ラックの最上段のサーバーで稼働しています。そう、FCは一つだけじゃないんです。分散アプリケーションであり、単一のクラスタ構成情報を共有しています。WSFCと一緒ですね。複製の方法も、私は詳しくは知り得ませんが似ているようです。Paxosアルゴリズムを使っています。

※ ちなみに、Paxosアルゴリズムの提唱者は、LaTeXでおなじみレスリー・ランポートさんです。彼は今Microsoft Researchにいるんです。

各ラックには冗長化された電源とネットワーク機器が備わっており、ラックのハードウェア障害は別ラックまでは波及しないようになっています。Azureを使っているとたまにお目にかかる用語「障害ドメイン(fault domain)」というのは、このラックのことだと思って頂ければだいたいOKです。

※ なお、"TOR"というのはルーターです。"Top of Rack router"の略です。

では、次にこのクラスタを構成するノードの中身を見てみましょう。

クラスタのノード内

image

スライド18: Inside a Deployed Node

黄緑の四角が物理ノード、つまりラック内のブレードサーバーです。ここでWindows Azure用の特別なWindows Server (RDOS) とHyper-Vが動いているわけです。

そのホストOS部分(RDOS)には、ファブリックコントローラとのやりとりを担当する”FC Host Agent”が動いています。ロールインスタンスのデプロイや削除は、FCからの指令をこのホストエージェントが受け取って、処理するわけです。

 

障害時の動作

さて、ようやく本題です。このスライドがわかりやすいですね。

imageスライド30: Node and Role Health Maintenance

FCがサービスの可用性を見張っているわけです。肝心の部分を拡大してみましょう。表内の下部2行です。

image

“Host OS” or agent crashes というのは、仮想マシンのホストであるRDOSそのものや、FCのホストエージェントに障害があったことを意味しています。この場合、まずは当該ノード内でサービスの回復を試み、それでもダメなら”FC reallocates roles to other nodes”。つまり、ロールインスタンスが別のノードへ移行されるということです。

同様に、ノードのハードウェア障害が検出された(”Detected node hardware issue”)場合は、「FC migrates roles to other nodes Marks node “out for repair”」とあるので、ロールインスタンスがやはり別のノードへ移行され、かつ障害ノードには「要修理」印が付けられるというわけです。

「移行」ってどんな移行？

「別のノードへ移行」というのはもう少し具体的に表現するとどのような動作でしょうか。オンプレミスのHyper-Vホストクラスタでは、「移行」といえば次のような動作があり得ます。

  • ゲストOSが普通に動いたまま、仮想マシンが「ライブマイグレーション」する。
    • ただし、ノード障害時にこれは無理。(移行元、移行先で同時に仮想マシンが稼働して「メモリ内容の転送」ができなければならないので)
  • ゲストOSはいったん落ちて、仮想マシンが「フェールオーバー」する。
    • ノード障害時の移行はこちら。
    • フェールオーバー先でゲストOSは再起動される。

Windows Azure上での「別ノードへの移行」はこのどちらとも少し違います。

imageスライド33: Moving a Role Instance (Service Healing)

「別のノードにデプロイし直し」というのが一番正確な表現かもしれません。もちろん、ライブマイグレーションではないのでゲストOSの動作はいったん途切れます。

というわけで、オンプレミスのHyper-Vとは少々違う方式ではありますが、Windows Azureの仮想マシンも「別の物理ノードへ引っ越しできる仮想マシン」なのです。ノード障害ぐらいではへこたれませんよ！

なお、このMarkの資料は今回ご紹介した部分以外もいろいろ面白いので、是非一度じっくりとご覧ください。セッションのビデオも公開されています。

それでは。

__END__