Windows Azure IaaSのホストOSアップデートの解説

Posted: 2013/12/05 カテゴリー: Uncategorized
タグ:, , , , ,

Windows Azure仮想マシンでは、2013年12月6日から8日にメンテナンスをスケジュールしています。Windows Azure仮想マシンのスケジュールされたメンテナンスの通知は、1インスタンスの仮想マシンをデプロイしているお客様にだけ送信されています。このメンテナンスの間に、お客様の仮想マシンが一度だけ再起動されます。VMをダウンさせるわけにはいかず、99.95%の稼働時間SLAの対象になりたい場合は、可用性セット (Availability Set、AS) を作成し、AS内に少なくとも2つのVMを配置することを推奨します。

このポストでは、次のことを見ていきます:

  • なぜ、Windows AzureはホストOSをアップデートするのか?
  • ホストOSアップデートは、どのように行われるのか?
  • 可用性セットとは何か?
  • 可用性セット作成によって、どのようにアプリケーションの可用性が高くなるか?
  • Windows Azure仮想マシンでの、可用性の高いアプリケーションの作成と管理に役立つリソース

なぜ、Windows AzureはホストOSをアップデートするのか?

Windows Azureは、およそ月に1回、ホストOSに対するアップデートをデプロイしています。これによって、Windows Azureが、お客様のアプリケーションをホストするための信頼性があり効率的でセキュアなプラットフォームを提供することが保証されます。

ホストOSアップデートは、どのように行われるのか?

Windows AzureプラットフォームにおけるホストOSアップデートは、Windows OSが動作するPCやサーバーのアップデート方法とは異なります。Windows Azureの場合、最新のすべてのアップデートと修正が含まれている新しいイメージがすべてのサーバーにデプロイされ、ファブリック コントローラーがこれらのサーバーに、再起動して新たにデプロイされたイメージから起動するよう指示します。なので、完了までかなりの時間がかかる可能性もあるWindows Updateとは異なり、Windows AzureのホストOSアップデートには新規イメージからの起動が伴うだけです。典型的には、このホストOSアップデートのプロセスは、完了まで15分から20分かかります。

可用性セットとは何か?

同じタスクを実行する2つ以上のVM (たとえば、2つ以上のWebサーバー) がある場合、これらのVMで可用性セットを作成します。可用性セットの作成によって、アプリケーションの可用性が高くなり、また、99.95%の稼働時間SLAの対象になります。

可用性セット作成によって、どのようにアプリケーションの可用性が高くなるか?

可用性セットを作成すると、ファブリック コントローラーに、可用性セット内のすべてのVMが同じ機能を実行しており、スケジュールされたメンテナンスの間に同時に停止されてはいけないと、知らせていることになります。舞台裏では、ファブリック コントローラー (FC) が、これらのVMをインテリジェントに異なるアップデート ドメイン (UD) に配置します。これらのUDは、FCが、同じAS内のすべてのVMがスケジュールされたメンテナンスの間に同時に停止されないことを保証するのに役立つ、論理的な分類です。これによって、リクエストを処理するために利用可能なVMが、常に存在することが保証されます。

:

  1. 計画メンテナンス中に1つ以上のVMが利用不可能になっている間に自分のサービスが悪影響を受けないように、ワークロードを実行するVM数が減少しても十分なパフォーマンスが提供されることを確認するために、テストと監視を行ってください。
  2. 外界からの受信トラフィックを許可するエンドポイントを使っている場合は、そのエンドポイントが負荷分散されていることを確認してください。(次の「Windows Azureでの可用性の高いワークロードの作成」をご覧ください。)

Windows Azure仮想マシンでの、可用性の高いアプリケーションの作成と管理に役立つリソース

関連情報

コメント
  1. ぱろん より:

    Windows Azureの場合、最新のすべてのアップデートと修正が含まれている新しいイメージがすべて
    のサーバーにデプロイされ、ファブリック コントローラーがこれらのサーバーに、再起動して新たにデプ
    ロイされたイメージから起動するよう指示します。

    この場合、対象の仮想サーバで特に意識せずCドライブにOfficeなどセットアップしてあった場合には、新しいデプロイされたイメージでは、綺麗なくなってしまうんですかね。
    あとはオンプレのHyper-Vで作成したイメージをAzureにアップロードした場合、このあたりの挙動はどうなるでしょうかね。

    • Windows仮想マシンの場合、システム ドライブであるCドライブは、OSディスクとなります。このディスクの実体は、BLOBストレージに格納されたVHDファイルであり、ドライブへの変更はすべてBLOBストレージに永続化されています。

      ですので、メンテナンスによる自動再起動でも、手動の再起動でも、Cドライブの内容はなくなることはなく、再起動直前の状態が残っています。

      これは、管理ポータルやAPIでAzure上の既存イメージを使う場合でも、オンプレミスHyper-VのVHDをアップロードする場合でも、同じです。

      http://msdn.microsoft.com/ja-jp/library/windowsazure/jj672979.aspx

      • ぱろん より:

        ご丁寧にありがとうございました。

        まだAzureの仮想サーバについて、まだまだ初心者で、いろいろと触っているところです。
        今回の話はあくまでもAzureのホスト側の話であって、ユーザー側のゲストOSの話ではなかったですね。勘違いしていました。すみませんでした。

        高可用性セットを組みばよいですが、コストは2倍になりますし、クラサバのアプリケーションだと、そもそもデータベースの部分など、仮想サーバに合わせて作り直ししなければならない部分が以外とあり、中小企業には結構きつい所があります。メンテナンス時間にサービス止めてしまうという考えもあるのでしょうが、ビジネスタイムに被る判断が難しい部分があります。

        ちなみに、イメージはともかく、ゲストOSに対してマイクロソフトから何かメンテナンスされることはないのでしょうか?→通常はWindowsUpdate等になるので、従来通りユーザー側のタイミングで実施することになるのでしょうか?

  2. PaaS型のWindows Azureクラウド サービスでは、ゲストOSのアップデートもMicrosoftに任せることができますが、IaaS型のWindows Azure仮想マシンでは、ゲストOSのアップデート/メンテナンスは、ユーザー側の責任になります。MicrosoftはゲストOSを触りません。

    ですので、Windows Serverの仮想マシンの場合、ゲストOS上でWindows Updateを適用するのは、ユーザーです。

    Windows Azure仮想マシンのメンテナンスは、データセンターがある場所のタイムゾーンで、業務時間を避け、夜間になるように設定されています。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中