Azure VM のメンテナンス FAQ


こんにちは、 Azure サポートチーム高橋です。今回は、定期メンテナンスについての説明と、特にお問い合わせが多かったご質問をご紹介します。今後の参考にしていただければ幸いです。

メンテナンスについて

VM の再起動が伴う大規模なメンテナンスは、マルチ インスタンスを対象にしたものとシングル インスタンスを対象にしたもの、大きく二つに分けることができます。マルチ インスタンスへのメンテナンスは、可用性セットを組んでいる VM が対象となります。実施時間は約 72 時間になります。

一方、シングル インスタンスへのメンテナンスは、可用性セットを組んでいない単一の VM が対象となります。実施時間は約 12 時間になります。

ただし、メンテナンスの内容によっては時間が延びる可能性もございます。
VM の再起動を伴うメンテナンスを実施する際には、事前に対象の VM をご利用のお客様に対して、メンテナンス実施の通知メールを送付させていただいております。翻訳等の兼ね合いで少々前後する場合もございますが、マルチ インスタンス、シングル インスタンス共に 1 週間前を目途に通知されます。
また、数百台のノードの状態を見て、メンテナンスを実施するので、 必ずしも VM が再起動するとは限りません。

 

maintenanceE

参考

 

メンテナンスの方法

数千台のサーバー群 (クラスター) は、物理ブレードサーバー (以下ノード) を保有しています。仮想マシンが動作しているノードは、以下の 2 種類のグループに分けられます。

  • マルチ インスタンス (クラウドサービス、および可用性セット内の VM が稼働)
  • シングル インスタンス (可用性セットに入っていない VM が稼働)

上記の通り、マルチ インスタンスとシングル インスタンスは、別々のグループに分けれられています。

ホスト OS のアップデート時には、マルチ インスタンスとシングルインスタンスのノード群のメンテナンスは別々に行われます。マルチインスタンスの場合は、可用性セットを組んでいる VM を対象としているので、ダウンタイムは発生しません。シングル インスタンスのアップデートでは、可用性セットがないため、VM の再起動の時間 (約 15 分) がダウンタイムとなります。

次に、定期メンテナンスについて、特にお問い合わせが多かったご質問をご紹介します。
尚、FAQに記載の内容は 2016 年 3 月時点の情報によるもので、今後変更になる可能性がありますので、ご留意下さい。

 

FAQ

Q. メンテナンスの詳細な日時を教えて下さい。

A. メンテナンスのアナウンス時における期間よりも絞り込んでの厳密な実施時刻は、ワールドワイドの全ユーザー様の展開状況を踏まえて順次実施してまいります仕組み上、大変恐縮ながら推測することが出来かねます。短い期間で実施できるよう改善を続けている状況ではございますが、お伝えした期間以上につきましては不定でございます。

 

Q. メンテナンスの通知では、いつ何時に再起動が発生するのか分かりますか。

A. メンテナンスの事前通知では実施期間のみのご案内となり、個々の仮想マシンの再起動時刻までは個別にご案内を差し上げておりません。これはメンテナンスを実施する瞬間の各ユーザー様の構成状況に応じて、メンテナンスの適用順序が左右されることによるものであり、大変恐縮ながらご案内差し上げた期間内のいずれかの時刻にメンテナンスが行われる形となります。実際に再起動が発生した時刻につきましては、個々の仮想マシン内のイベントログや、管理ポータルの機能等でご確認ください。

以下に管理ポータルからの確認方法を紹介します。

 

ASM

旧ポータルでの確認方法
———————————–

  1. クラシックポータル (https://manage.windowsazure.com) にログインします。
  2. 「クラウドサービス」より該当のクラウドサービスをクリックします。
  3. 「ダッシュボード」を選択し、の概要より、「再起動ログを表示」をクリックします。

ASM RestaLog

 

 

参考

 

 

Q. Azure の計画メンテナンスの通知では、その期間中に VM が再起動するとの記載がありますが、Windows OS 上の再起動と同一のものと考えてよろしいのでしょうか。または、強制終了されると考えたほうがよろしいのでしょうか。

A. メンテナンスによる VM の再起動は、強制終了の扱いではなく、OS 上の再起動と同様になります。管理ポータルの割り当て解除済みの状態にはなりません。ただし、シャットダウン命令を発行してから、概ね 10 分程度経過しても仮想マシンがシャットダウンされない場合、例外的に強制終了となることがございます。

これは、特定のお客様の環境が長時間シャットダウンされないように、メンテナンス全体の実施時刻に影響をきたさないための処理となりますのでご留意をいただければ幸いです。この場合にも、メンテナンスの完了後には自動で起動処理を行いますので、仮想マシンの電源投入までは確実に行われます。

しかしながら、強制終了に伴ってなんらかの復旧状態に陥った結果、OS が起動しないことも稀に起こりうる可能性がございます。多くの場合には問題なく起動してまいりますが、念のためご留意ください。

 

Q. メンテナンスの連絡は、サブスクリプションに登録されている管理者すべてに通知されるのでしょうか。

A. 通知メールの送信対象は、 Azure のサービス管理者、共同管理者でございます。当該管理者さまが、それぞれご登録されているメールアドレス宛に通知メールをご送付しております。

[— 2016/12/7 追記 —]
Azure ポータル (https://portal.azure.com/) における、“所有者・共同作成者・閲覧者” などといった権限は、ロールベースのアクセス制御 (RBAC) と呼ばれている、リソースごとに権限 (ロール) とユーザーを細かく設定が行える機能です。メンテナンス メールの送付先には利用されませんので、ご注意ください。
メンテナンス通知メールを受信するためには、クラシック ポータルからの共同管理者の追加が必要です。

“アカウント管理者・サービス管理者・共同管理者の変更方法について”
https://blogs.msdn.microsoft.com/dsazurejp/2013/10/02/293/
[— 2016/12/7 追記 —]

 

Q. VM が「停止済み (割り当て解除済み)」の状態である場合でも、メンテナンスの通知は送付されるのでしょうか。

A. VM が「停止済み (割り当て解除済み)」の状態である場合、全てのリソースと切り離されている為、メンテナンス通知は送付されません。また、メンテナンス実施前に起動された場合にも改めて、メンテナンス通知が送付されることはございませんので、ご了承ください。

 

Q. メンテナンス終了後に手動で VM を起動する必要はありますか。

A. メンテナンス終了後に手動で VM を起動する必要はありません。起動中であった VM は、メンテナンス終了後に Azure プラットフォームにより起動されます。

 

Q. OS 停止中のサーバーは、メンテナンス終了後も OS 停止状態のままでしょうか。

A. 上記起動状態にあった VM とは異なり、OS 停止中のサーバーにつきましては、次の二通りの状況が想定されます。

  1. VM 自体がシャットダウンされており、リソースが解放されている状態
  2. OS 内でシャットダウンし、Azure としてはリソースを確保し続けている状態

1. につきましては、Azure としても停止状態として検知・判断しておりますのでメンテナンス完了後も停止した状態のままとなります。メンテナンス後に自動で起動して費用が発生するなどの状況とはなりませんので、ご安心ください。

2. につきましては、 IP アドレスを解放させたくないなどの背景でご設定いただいているお客様もいらっしゃいます。こちらについては、 Azure としてはリソースを確保している、すなわち起動中として判断するかと存じますので、メンテナンス後に起動される可能性がございます。ただ、この場合には当初の Azure として起動中の状況であり、課金状態となりますことから、費用面での差異は生じないかと存じます。

なお、前述のような IP アドレスを変更されたくないといった理由により、リソース解放状態での仮想マシンの停止を避けている場合には、 “Reserved IP” といった機能によって、明示的に IP を固定することが可能です。当記事にて方法をご紹介しておりますので、ご参照ください。

 

Q. 再起動後に、「自動」としてあるサービスは自動開始しますか。

A. メンテナンス実施による仮想マシンの再起動は、OS を通常起動した際と同様となり、自動開始のサービスについても、通常通り起動いたします。Azure の物理サーバーは、弊社 Hyper-V の仮想化基盤をもとにしておりますので、起動はあくまでも仮想マシンの電源をオンする処理となり、通常の電源投入と相違ございません。

 

Q. Azure バックアップが起動中にメンテナンスで再起動が始まった場合、再び立ち上がってきた後の Azure  バックアップの挙動はどのようになるでしょうか。

A. メンテナンス時、 VM に対しては OS のシャットダウン・起動が行われます。このタイミングで、 Azure Backup サービス自体が停止しますので、その時に中断エラーとなるか、実行できないといったエラーとなる程度であり、取れたデータに不整合があったといったことにはならない見込みです。手動でバックアップを停止するほどではなく、メンテナンス後にバックアップの成否をご確認いただき、失敗したものは取り直していただくといった対応がよろしいのではないかと存じます。

 

Q. ひとつのラックにおいて 1 年間に何度メンテナンスが行われますか。また、可用性セットのマシンとそれ以外で回数が違う場合はそれぞれ教えてください。

A. Azure のメンテナンスについては、何か月に一度というようにスケジュールされているものではなく、セキュリティやパフォーマンスの向上に必要な更新がある場合に都度実施しております。そのため、事前にその年に何度メンテナンスが実施されるかについては予測ができない状況です。しかしながら、実績として、 2015 年は 4 回ほど VM の再起動を伴う大規模なメンテナンスが実施されておりました。

また、可用性セットの有無によってメンテナンス時期は分けて行っておりますが、回数自体は同等でございます。ただし、セキュリティの問題など、緊急メンテナンスにより急きょ実施される可能性もあります。

 

Q. メンテナンスの回避策を教えて下さい。

A. シングル インスタンスの場合は、可用性セットを組むことでメンテナンスを回避することができます。

可用性セットは、本来同一の役割を有する VM を複数台構成していただき、グループ化するための機能とはなりますが、一台のみの環境でも設定は可能です。複数台を異なるサーバーへ配置するという本来の効果はありませんが、シングル インスタンスのメンテナンス回避には有効な対処策となります。

しかしながら、可用性セットを設定することで、VM の再起動が必要になりますので、ご留意願います。また、リソースマネージャーモデルの VM を可用性セットに組み込むには、一度 VM を削除し、再度作成する必要がありますので、こちらも併せてご留意願います。

ASM と ARM 環境で可用性セットを組む手順が異なりますので、以下に記します。

ASM

旧ポータルでの手順
———————————–

  1. クラシックポータル (https://manage.windowsazure.com) にログインします。
  2. 「仮想マシン」より該当の仮想マシンをクリックします。
  3. 「構成」の「可用性セット」により、可用性セットの設定を行います。

 

参考

 

ARM

新ポータルでの手順
———————————–

  1. 新ポータル (https://portal.azure.com/) にログインします。
  2. [仮想マシン (クラシック)] より、対象の仮想マシンを選択します。
  3. [すべての設定] – [可用性セット] と選択します。
  4. 上部の [新規] より、任意の名称を設定して、[OK] を選択します。

 

ARM  リソースマネージャーモデル

新ポータルでの手順
———————————–

一度仮想マシンを削除し、既存環境からの再作成となります。Azure PowerShell 等で環境に合わせたコマンドの作成が必要になります。Azure PowerShell で外部公開されているものとしては、サンプルとしては下記のものがございますので、ご参考ください。

<2016/12/12 追記> 弊サポート チーム ブログから以下のサンプルをご用意しております。

リソース マネージャー (ARM) 環境で既存の VM を新規作成の可用性セットに追加する方法
https://blogs.technet.microsoft.com/jpaztech/2016/06/07/addnewavsetvmarm/ 

リソース マネージャー (ARM) 環境で既存の VM を既存の可用性セットに追加する方法
https://blogs.technet.microsoft.com/jpaztech/2016/06/08/addavasetvmarm/

<———–追記ここまで———–>

参考

 

Q. Azureメンテナンスによる再起動において、動的に設定しているパブリック IP が書き換わるようなことはないということでしょうか。

A. 原則として、メンテナンスにより VM を配置している物理サーバーの配置換えが行われることはありません。よって、メンテナンスに起因してパブリック IP が変更されることはない、ということを動作上の想定としております。

しかしながら、パブリック IP が変更されないことを 100 % 保証しているわけではございませんので、状況によってはパブリック IP が変更となる恐れもございます。例えば、メンテナンスの前後で何らかの問題が発生した場合などにて、 VM を配置している物理サーバーの変更が実施された場合には、パブリック IP が変更されることが想定されます。このため、ご利用のパブリック IP が変更となることによって支障のある環境につきましては、事前にパブリック IP の固定の実施を推奨いたします。Azure PowerShell によって、パブリック IP を固定することができます。下記コマンドの実行で、VM が再起動することはありません。

ASM

New-AzureReservedIP -ReservedIPName <作成する予約済み IP 名> -Location <リージョン名> -ServiceName <クラウドサービス名>

コマンド実行例

PS C:\> New-AzureReservedIP -ReservedIPName MyReservedIP -Location "Japan West" -ServiceName "ora64n1v1"
OperationDescription OperationId                         OperationStatus
-------------------- -----------                         ---------------
New-AzureReservedIP 1eb7c0c3-4673-86e5-8ff2-26be4adfe811 Succeeded

 

ARM

■ パブリック IP アドレス

$pip = Get-AzureRmPublicIpAddress -Name <パブリック IP アドレス名> -ResourceGroupName <リソースグループ名>
$pip.PublicIpAllocationMethod = "static"
Set-AzureRmPublicIpAddress -PublicIpAddress $pip

■ プライベート (内部) IP アドレス

$dip = Get-AzureRmNetworkInterface <ネットワークインターフェイス名> -ResourceGroupName <リソースグループ名>
$dip.IpConfigurations[0].PrivateIpAllocationMethod = "static"
Set-AzureRmNetworkInterface -NetworkInterface $dip

 

参考

 

Q. 可用性セット内のメンテナンス対象インスタンスを確認する方法について教えて下さい。

A. 原則として可用性セットを対象とするメンテナンスの場合には、可用性セットを構成した環境全てがメンテナンスの対象となります。実際のメンテナンス実施時には、各 VM に対して順番にメンテナンスを行いますので、同時に再起動されることはございません。メンテナンス対象のリージョン内で、全ユーザー様の構成を考慮して適用順を決定しておりますので、特定のお客様環境をメンテナンス対象から除外したりメンテナンスを回避するといったことは現時点では出来かねますが、その点は何卒ご容赦いただきたく存じます。

 

Q. 可用性セットを設定している仮想マシンの最低限保証されるタイムラグはありますか。

可用性セットを組んだ場合、更新ドメイン単位で 30 分の間隔が開けられることが保証されます。

抜粋: When Microsoft updates Azure, they’ll walk from one update-domain to the next. You can see what they are saying in this email – they’ll leave 30 minutes between updating each update domain.
抄訳: Microsoft にて Azure をアップデートする際には、更新ドメインごとに更新処理を行っていきます。

可用性セットを組んでいる VM のメンテナンスにあたっては、”マルチインスタンス構成の仮想マシン(Virtual Machine)と Cloud Services に対する計画メンテナンスのお知らせ” といったタイトルの通知メールをお送りしております。(タイトルは、メンテナンス通知事に若干変更がある場合があります。) 一例として、3 月上旬のアップデート通知メールからの抜粋となりますが、以下のようなご説明をしております。

“可用性セット内の仮想マシンに関して高可用性を維持するために、異なる更新ドメインに属するインスタンスは最低 30 分の間隔をおいてメンテナンスを実行します。これにより、インスタンス間のデータの整合性を保ちます。”

 

Q. 可用性セット内の VM はどの程度の間隔を空けて再起動されるのでしょうか。

A. 短時間に再起動が行われることによって VM の OS や各種サービスが起動完了する前に他の VM が再起動され、ダウンタイムが発生したという報告は頂戴しておりません。また、過去実績上は短くても 90 分程度の間隔をあけて実施されておりますので、ご安心ください。

 

Q. メンテナンス作業の中に、サーバーのセキュリティ パッチ適用があるというのは本当でしょうか。

A. メンテナンス作業に際しては、セキュリティ パッチの適用も実施しております。なお、セキュリティ パッチの適用は、 Azure 基盤 ( Hyper-V ホスト ) に対するものであり、ご利用の VM 内の OS に強制的にセキュリティ パッチを適用するものではございませんので、ご安心ください。

一方で、 Azure 基盤側に対するセキュリティ パッチ適用につきましては、 Azure をご利用いただく全ユーザー様に影響のあるものでございますので、必ず発生いたします。この点はパブリッククラウドの特性上、ワールドワイドでご利用いただくお客様の環境をセキュアに保つため必須となってまいりますので、何卒ご理解いただきますようお願いいたします。このほか、メンテナンス作業で実施される作業は概ね以下のようなものがございますので、ご参考までにご案内いたします。

  • 既知の不具合に対する修正
  • 機能追加に伴う修正
  • セキュリティ対策

 

Q. 計画メンテナンスには通知されないものはありますか?

A. Azure では、日々各種サービスに対してメンテナンスを実施していますが、PaaSなどマルチテナント形式のサービスや、仮想マシンの停止と接続の停止を伴わない更新については、通知が行われず、自動で更新が行われています。PaaS などマルチテナントで構成されるサービスは更新ドメインという仕組みを用いて、同時にインスタンスが落ちないように更新されます。また、物理的なホストマシンの更新では、影響の少ない「メモリ保護更新」が行われています。自動でメンテナンスが実施されています。「メモリ保護更新」とは、仮想マシンの起動イメージを一時的にメモリに保存し、一旦停止した後、ホストマシンに更新を施した後に、メモリから仮想マシンイメージを復帰する方法です。通常このメンテナンスではお客様に影響が極力出ないように 30 秒以内で復帰が行われます。

Comments (0)

Skip to main content