仮想マシンのメンテナンス作業に伴う一時停止について


みなさん、こんにちは。Windows Azureサポートチームです。今回のトピックは、比較的多くご質問をいただいている仮想マシンの計画メンテナンスに関連して、メンテナンスが実施される際に仮想マシンに何が起こるかについて技術的な観点から説明いたします。少しでも皆様の理解の一助となれば幸いです。

※本ドキュメントは 2013年10月時点の情報を基に作成しております。将来的なデータセンターの変更により細かな部分は変更になる可能性がありますので、あらかじめご了承ください。

仮想マシンのメンテナンス作業

データセンター内のブレードサーバー内では、仮想マシンをホストするためのWindows OSをベースとしたホスト環境が動作しています。そのホストの仮想化環境上で、仮想マシンは動作しています。以下のような定期的なメンテナンスのため、定期的な更新作業が必要になります。

  • セキュリティ更新プログラムの適用
  • Windows Azureの機能拡張・機能修正
  • ブレードサーバーのファームウェアアップデート (BIOS アップデートなど)
  • 必要モジュールの入れ替え

メンテナンスの際には、ホスト環境を再起動する必要がある場合がありますが、その際には、仮想マシンを動作させている仮想化環境(ハイパーバイザー)も一時停止する必要があります。したがって、ホスト環境の更新の際には、仮想化環境上の仮想マシンはシャットダウンされ一時停止し、ホスト環境の再起動後に、仮想マシンは再起動します。また、更新の内容によっては、ホスト環境の再起動が不要な場合もあります。

image

※ブレードサーバー イメージ:写真のような大量のブレードサーバーがデータセンター内部で動作しています。写真は古い世代のものですが、現在の世代はコンテナ型で配置されています。

動作の詳細

データセンターの動作

Windows Azureデータセンターは、世界各地に分散しています。データセンターは、複数のコンテナで構成され、膨大な数のブレードサーバー、電源ユニット、ルーター・スイッチ、ネットワークがまとまって構築されています。これらのリソース群は、データセンターの中で「ファブリック コントローラー」と呼ばれるサービスで自動管理されています。ファブリック コントローラーは、各ユニットを自動で管理していますが、物理的に異常が発生した場合などには、現在利用可能なリソースから自動で切り離したりします。データセンター内の Windows Azure システム自体は基本的には自律で動作していますが、何らかの作業をしなければいけない場合には、外部からリモートで実施しています。

各データセンターの内部は、「クラスタ」と呼ばれる単位でさらに分割されています。例えば、東アジア (香港) データセンターの場合を挙げると、コンピュートサービス用に数クラスタ、ストレージサービス用に数クラスタという形です。クラスタの内部には、1000台を超えるブレードサーバー(以下ノードと呼びます)で構成されており、これらはさらに障害ドメインで物理的に障害点を分割されています。各クラスタは、ファブリック コントローラーで自動管理されています。

image

※図中 FC: ファブリックコントローラー、FD: 障害ドメイン、Node: ノード(ブレードサーバー)

各ノードは、Windows Server の Hyper-V 技術をベースとしたホスト OS により管理されています。仮想マシンや、クラウドサービスの各インスタンスは、各ノードのホスト上で、インスタンス化され実行されます。仮想マシン・クラウドサービスの各インスタンスは、さらに論理的に更新ドメインに分割が行われています。

image

※図中 小さい□: インスタンス (仮想マシン。各FDに配置され、UDに割り当てられています)、Service: 仮想マシン/クラウドサービス

NOTE: 更新ドメインと障害ドメイン

更新ドメインは、クラウドサービス・仮想マシンのサービスの可用性を維持するための論理的な単位です。障害ドメインは障害時の可用性を維持のため、物理的にコンピュートリソースを分割する単位です。詳細については、以下でも説明していますので、ご参考ください。

Windows Azure の設定で利用される論理障害ドメインは現状 2 つ(0 or 1)ですが、データセンター内部の物理障害ドメインは、実際には複数個で構成されています。

更新作業

ノード自体の停止を伴う更新作業は、各地のデータセンターごとに更新作業が行われていきます。各地のデータセンターが更新パッケージを受け取ると、それを、データセンター内部の更新エンジンに渡し処理を実施します。更新エンジンは内部で指定されたクラスタに対して更新を実施していきます。この時に、更新ドメインを維持しつつ更新を実施します。

実際には、各ノードには、各お客様のサービスのインスタンスが配置されているため、更新時には最適なノード更新手順を特定のルールに基づき自動生成し、順番にノードを更新していきます。

例:修正にホストOSの更新が含まれていた場合
パッケージが更新としてアップロードされると、更新エンジンが更新手順に従って、各ノードに対して更新をかけていきます。この時に各サービスの更新ドメインの制約は維持しつつ作業します。対象のノードを「準備完了」から「更新中」にステータスを変え、外部から新しいインスタンスの作成などが行われないようにします。「更新中」に変更後は、ノード上で動作している仮想マシンを順次停止し、ホストOSのイメージを入れ替えたり修正を適用したりします。その後、ノードを再起動しホスト環境を起動した後で、環境に配置されていた仮想マシンを再起動します。この時に、別の更新ドメインに所属しているインスタンスが動作しているノードについては、更新はかかっていないため、可用性セットをセットしておくことで可用性が維持されます。

この更新作業については、更新する量にも依存するため、数時間で終わる場合もありますが、数日をかけて順番に実施する場合もあります。

可用性の確保

仮想マシンでは計画メンテナンスが実施されることがありますが、メンテナンス実施時には、上記の説明の通り一時的に停止します。それを抑制するためには、2個以上の仮想マシンを配置して、「可用性セット」をセットすることで、メンテナンス時に同時に各仮想マシンの停止を防ぐことが可能です。可用性セットを設定すると、その可用性セットに含まれる仮想マシンは、別々の更新ドメイン、障害ドメインに配置が行われるようになります。その結果、メンテナンス実施時でも同時に仮想マシンの停止が行われないようになります。

image

可用性セットの詳細については、以下をご参考ください。

補足

2013/10/16 – 一部古い情報で掲載していたため新しい情報にアップデートしました。


Windows Azureサポートチーム
平原

Comments (0)

Skip to main content