Windows Azureのホスト アップデート

Windows Azureのコンピューティング プラットフォーム (Webロール、ワーカー ロール、仮想マシン) は、マシン仮想化に基づいています。基になるOSへの深いアクセスによって、Windows AzureのPaaS (Platform as a Service) が、多数の既存のソフトウェア コンポーネント、ランタイム、言語と他に類を見ないほど互換性を持ちます。そしてもちろん、(独自のOSイメージを持ち込む機能も含む) この深いアクセスなしには、Windows Azure仮想マシンはIaaS (Infrastructure as a Service) には分類できません。

ホストOSとホスト エージェント

マシン仮想化は、もちろん (PaaSワーカー ロールにデプロイされているにせよ、IaaS仮想マシンにデプロイされているにせよ) 自分のコードがWindows Server Hyper-V仮想マシン上で実行されることを意味しています。(物理ノードやホストとも呼ばれる) それぞれのWindows Azureサーバーは、(「インスタンス」と呼ばれる) 1つ以上の仮想マシンをホストし、物理CPUコア上で仮想マシンをスケジューリングし、仮想マシンに占有RAMを割り当て、ローカル ディスクやネットワークI/Oへのアクセスを与えて制御します。

次の図は、サーバーのソフトウェア アーキテクチャの簡素化されたビューを示しています。(ルート パーティションとも呼ばれる) ホスト パーティションは、ホストOSとしてWindows ServerのServer Coreプロファイルを実行しています。この図とHyper-Vの標準アーキテクチャ図との唯一の違いは、ホスト パーティションにあるWindows Azureファブリック コントローラー (FC) ホスト エージェント (HA)と、ゲスト パーティションにあるゲスト エージェント (GA) の存在であることが分かるでしょう。FCは、Windows Azureコンピューティング プラットフォームの「頭脳」です。HAはFCへのプロキシであり、FCが (Windows Azureクラウド サービスを構成する) 仮想マシンをデプロイ、監視、管理できるようにするために、サーバーをプラットフォームに統合します。PaaSロールだけが、(FCへのランタイム サポートを提供し、ロールの健全性を監視するための) FCへのプロキシであるGAを持っています。

ホスト アップデートの理由

Windows Azureが、アプリケーションに対して信頼性があり効率的でセキュアなプラットフォームを提供していることを保証するためには、ホストOSとHAへの、セキュリティ、信頼性、パフォーマンスのアップデートのパッチ適用が必要です。自分のWindowsのWindows Updateによる再起動の頻度を基に推測できる通り、我々は、およそ月に1回、ホストOSにアップデートをデプロイします。HAは、(仮想マシンのVLANを管理する) ネットワーク エージェント (NA)、(仮想マシン ディスクを、データが含まれているWindows AzureストレージのBLOBに接続する) 仮想マシン仮想ディスク ドライバーといった、複数のサブ コンポーネントで構成されています。そのため、我々は、修正や新機能の準備がいつ整うかによって、HAとそのサブ コンポーネントを異なる間隔でアップデートしています。

アップデートをデプロイするために我々が取れる手順は、アップデートの種類に依存します。たとえば、ほぼすべてのHA関連のアップデートは、サーバー再起動なしで適用されます。ですが、Windows OSのアップデートでは、再起動を必要とするパッチが、ほぼ常に少なくとも1つはあり、通常は複数あります。そのため、我々は、FCに各サーバー上で (VHDとしてデプロイされる) OSの新バージョンを「ステージング」させ、それから、FCが、新イメージでサーバーを再起動するようにHAに指示します。

PaaSアップデートの調整

Windows Azureの主要な特性は、PaaSのスケール アウト コンピューティング モデルです。クラウド サービスでステートレスな仮想マシン (Webロール、またはワーカー ロール) を使う場合、クラウド サービス構成のロール インスタンス数を更新するだけで、簡単にロールをスケール アウト/スケール インできます。FCが、スケール アウトの際の仮想マシン作成、スケール インの際の仮想マシンのシャット ダウン/削除といった作業のすべてを自動的に行います。

ですが、Windows Azureのスケール アウト モデルが独特なのは、高可用性をモデルの中核部分にしている点です。FCは、アップデート ドメイン (UD) と呼ばれる概念を定義しています。FCは、UDを使って、アップデートが (ロール コードのアップデートのような) クラウド サービス所有者が適用するロールへのアップデートか、(ホストOSのアップデートのような) サーバー再起動を伴うホストへのアップデートかに関わらず、インスタンスの再起動を引き起こす計画アップデート中ずっと、ロールの可用性を保証します。FCは、計画アップデートが、異なるUDのインスタンスを同時にオフラインにすることがないことを保証します。ロールは既定で5つのUDを持ちますが、クラウド サービスはサービス定義ファイルで最大20のUDをリクエストできます。次の図は、FCが、3つのUDにわたってクラウド サービスの2つのロールのインスタンスをどのように展開するかを示しています。

ロール インスタンスは、ランタイムAPIを呼び出して自らのUDを取得できます。また、管理ポータルも、ロール インスタンスとUDとのマッピングを表示します。次の図は、それぞれ2インスタンスを持つ、2つのロールが含まれるクラウド サービスなので、各UDには各ロールの1インスタンスがあります:

UDに関するFCの動作は、クラウド サービスのアップデートと、ホスト アップデートで異なります。クラウド サービスが適用するアップデートの場合、FCは順に各UDのすべてのインスタンスをアップデートします。FCは、前のUDのすべてのインスタンスが再起動し自身の健全性をGAにレポートするか、または、クラウド サービス所有者がサービス管理APIを介して次のUDに移るようFCに依頼したときにだけ、次のUDに移ります。

ホスト アップデートの間は、一度に1つのUDに進むのではなく、同時に再起動されるロール インスタンスの順序と数は可変です。これは、サーバーへのインスタンスの配置のために、FCが、UDのすべてのインスタンスがホストされているサーバーを、同時に、あるいはUD順でさえも再起動できないからです。次の図に示した、インスタンスのサーバーへの配置を考えてみましょう。サービスAのロールのインスタンス1はサーバー1にあり、インスタンス2はサーバー2にあります。一方、サービスBのインスタンスは、反対に配置されてます。FCがどの順序でサーバーを再起動したとしても、1つのサービスでは、UDとは逆の順序でインスタンスが再起動されます。FCの割り当てアルゴリズムは、(どのサービスに属しているかに関係なく) 同じUDのインスタンスを同じサーバーに配置しようと試みることで最適化されているので、ここに示した割り当ては比較的稀です。ですが、FCは、(1つのサービスの) 同じロールの異なるUDのインスタンスが同時にオフラインにしないという約束を破ることなく、サーバーを再起動できるので、これは有効な割り当てです。

ホスト アップデートとクラウド サービスのアップデートとのもう1つの違いは、ホスト アップデートの場合は、FCが、1つのインスタンスがデータセンター全体のサーバー アップデートの進展を無期限に行き詰らせることがないようにしなければならない点です。そのため、FCは、新ホストOSでのサーバー再起動に進む前に、インスタンスのシャットダウンのために最大5分を割り当てます。また、ロール インスタンスが再起動時に自身の健全性をレポートするために、最大15分を割り当てます。ホストを再起動するのに数分かかり、それから、VM、GA、そして最後にロール インスタンス コードを再起動するので、(そのインスタンスや、サーバーを共有している他のインスタンスのシャットダウンや再起動にかかる時間によって) 通常、インスタンスは15分から30分の間オフラインになります。ホストOSアップデート中の、Web/ワーカー ロールの期待される状態変化のさらなる詳細については、こちら (英語 / 日本語) をご覧ください。PaaSサービスに対しては、FCが、ゲストに対するOSアップデートも管理していることに注意してください。ですので、(自動アップデートを選択したPaaSサービスに対しては) ホストOSアップデートの後には、通常、(他のクラウド サービスのアップデートと同様に、UDによって調整される) 対応するゲストOSアップデートがあります。

IaaSとホスト アップデート

ここまでの議論は、スケール アウト時に自動的にUDの利点を享受する、PaaSロールに関するものでした。一方、IaaSの仮想マシンは、本質的には、スケール アウト機能を持たない単一インスタンスのロールです。IaaS機能の重要な目標は、ホスト アップデートやハードウェア障害の際に、仮想マシンも高可用性を実現できるようにすることでした。そして、可用性セット機能が、まさにそれを行うものです。PowerShellコマンドやWindows Azure管理ポータルを使って、仮想マシンを可用性セットに追加できます。これが、可用性セットに割り当てられた仮想マシンを持つ、クラウド サービスの例です:

ロールと同様に、可用性セットは既定で5つのUDを持ち、最大20のUDをサポートしています。次の図に示すように、FCは、可用性セットに割り当てられたインスタンスを、UDにわたって展開します。これによって、お客様は、高可用性のために設計された仮想マシン、たとえば、SQL Serverミラーリングが構成された2つの仮想マシンを、可用性セットにデプロイできます。こちら (英語 / 日本語 (機械翻訳)) で説明しているように、可用性セットは、ホスト アップデートが同時にミラーの片方の再起動しか引き起こさないことを保証します (ここでは議論しませんが、FCは、フォールト ドメイン (障害ドメイン) と呼ばれる機能を使って、データセンターの単一のハードウェア障害がインスタンスの高々半分にしか影響を与えないように、ロールや可用性セットのインスタンスを複数のサーバーにわたって自動的に展開します)。

さらなる情報

アップデート ドメイン、フォールト ドメイン、可用性セットのさらなる詳細については、私のWindows Azureカンファレンス セッションをご確認ください。「Mark’s Webcasts」ページ (英語 / 日本語 (機械翻訳)) で、セッションの動画を確認できます。Windows AzureのMSDNドキュメントが、ホストOSアップデート (英語 / 日本語) と、アップデート ドメインのサービス定義スキーマ (英語 / 日本語) を説明しています。

関連情報

• Mark Russinovich’s Blog > Windows Azure Host Updates: Why, When, and How (2012/08/22)
• http://blogs.technet.com/b/markrussinovich/archive/2012/08/22/3515679.aspx