はじめに
「AVDが朝起動しない？！」と思った方、AVDが起動しない事象に陥った方、あるいはこれからAVD構築をされる方向けの記事です。
AVDを使用する際の留意点としてエラー（AllocationFailed）について説明する機会がよくあったので、文章にしようと思いました。
特にスケーリングプランと可用性ゾーンを使用している場合は注意が必要です。
また、本記事の内容≒こちらのLearnの話です。↓↓↓
Azure で VM を作成またはサイズ変更するときの割り当てエラーのトラブルシューティング
私が疑問に思った点と、それを払拭するために行った検証内容も最後に掲載していますので、ぜひご一読ください。
AllocationFailedとは？
AVDに限らずVM共通で起きる事象です。
エラーコード
AllocationFailed
というものが存在します。
エラーメッセージは以下のようなものになります。
「割り当てに失敗しました。 このリージョンには、要求された VM サイズに対して十分な容量がありません。 割り当てが成功する可能性を向上させる方法については、https://aka.ms/allocation-guidance” をご覧ください。
つまり、Azureのリージョン自体のリソースが不足している場合に、VMの起動時にリソースが割り当てられず、起動が失敗するエラーのことを指します。
スケーリングプラン
以下のようにスケーリングプランを使用しているAVD環境があるとします。
図の例では毎朝９時にセッションホストを起動することになります。
この時、毎朝９時起動時にAzure上のリソースを探しにいき、リソースが不足していた場合「AllocationFailed」を起こす可能性があります。
AVD環境ではこのようにスケーリングプランを使用して「夜は停止⇒朝起動」という動きをするケースは珍しくないような気がします。
可用性ゾーン
可用性ゾーンを使用するとゾーン障害対策が可能です。特定ゾーンで停電や障害が起きても他のゾーンでシステムを継続できるように設定します。
設定方法は主に２つあります。
１. ゾーン冗長デプロイ
仮想マシンを複数のゾーンに分散配置し、1箇所に障害が起きても影響を受けにくくします。
２. ゾーンデプロイ
単一の可用性ゾーンにデプロイしたVMを配置します。
ゾーン障害が発生した場合、冗長性がないためユーザー自身で復旧対応を行う必要があります。
ゾーンを指定すると、VM起動時に指定したゾーンのリソースしか利用できなくなります。
そのためゾーンデプロイでは例えばゾーン１を指定したVMはゾーン１にあるリソースを選択して起動しようとするため、AllocationFailedのリスクが高くなります。
可用性ゾーン × AVD
可用性ゾーンのパートでご紹介した通りですが、セッションホストをゾーンデプロイするパターンではAllcationFailedが懸念されます。
AllocationFailedの回避策
もし可用性ゾーン内の VM の割り当てエラーが発生した場合は以下の回避策があります。
１. 割り当てを再試行する
たまたまリソースが足りない瞬間に起動してエラーが発生し、すぐにリソース不足が解消されていた場合はこちらで解消しそうです。
２. VMのサイズを変更する
サイズ変更で解消することがあるようです。
人気のシリーズを使用していたりすると発生することもあるように思います。
３. リージョンまたはゾーンを変更する
解消できる可能性が高いのはこの方法ではないかと思います。
リージョン変更＞ゾーン変更の順に解消確率が高いと思われます。
また、Learnには「３．リージョンまたはゾーンを変更する」の派生として以下のような記載があります。
OS ディスクのコピーを使用して、別のゾーンまたはゾーン制約なしで新しい VM を作成します。 ゾーン制約を削除すると、割り当てオプションが単一のゾーンに限定されるのではなく、リージョン全体に拡張されます。
つまりVM（セッションホスト）はゾーン制約なしにしておくと１つのゾーンだけでなく、リージョン全体のリソースを使用することができるようになります。
↓↓Azure portal上の仮想マシン作成時 設定画面↓↓
ゾーン制約なし
ゾーン制約なし（インフラストラクチャ冗長は必要ありませんを選択）した場合
割り当て解除⇒起動をした際に適宜必要に応じてゾーンを変えてくれるようです。
以下の記事（2023年のもの）にこのような記載があります。
■ポイント①
VM 割り当て解除をして起動することでゾーンが変更となることもございます。
■ポイント②
なお、可用性ゾーンを未指定の場合はゾーン 1 ～ 3 いずれかのゾーンで VM が起動されますが、どのゾーンで VM が起動されるかは把握することは叶いません。
VM 割り当て解除をして起動することでゾーンが変更となることもございます。
加えて現在どのゾーンで VM が起動しているかといったことも確認をすることが叶いません。
特定ゾーンでの稼働が必要な場合は、可用性ゾーンを指定して VM をデプロイいただくようにお願いいたします。
ゾーン未指定時の VM 起動ゾーン、およびサブスクリプション毎のゾーン番号指す物理ゾーンについて
ゾーン制約なしに関する考察
ここで１つ疑問が残りました。
Managed Diskは一度デプロイされた時、例えばゾーン制約なしにしていてもゾーン１～３どれかに属していそうです。
それでいてAzure側でVM本体のゾーンを変更することができるのでしょうか？
つまり、VMとdiskのゾーンが異なっていても問題ないのでしょうか？
簡単に確かめてみました。
結論としては以下のようになりました。
※()が可用性ゾーンの所属を表しています。
検証例１（ゾーンの異なるVMにdiskをアタッチ可能かどうか）
ゾーン２のVMにゾーン１のdiskをアタッチしてみる
■VMをゾーン１指定でデプロイ
そして、disk以外を削除
ゾーン１に存在するdiskが出来上がりました。
■VMをゾーン２指定でデプロイ
■zone2-vmにてdiskスワップ
ゾーンを固定したVMとdisk間では接続できない
検証例２（ゾーン２のVMとゾーン制限なしのdisk）
■インフラストラクチャ冗長は必要ありませんdisk
■zone2-vmにてdiskスワップ
diskがゾーン制限なしだとしても、VMと同じゾーンになければ接続できない
検証例３（ゾーン制限なしのVMとゾーン制限なしのdisk）
■zone-freeなvm作成
■diskスワップ
どちらもゾーン制限なしだとスワップ可能
まとめ
ということで結論に記載した結果を見て疑問は払しょくできました。
ゾーンを指定しなかった場合「VM起動時にどういう割り振りをしているか」までは不明ですが、ゾーンは跨っていても問題ないことは分かりました。
もちろん、VMとdiskセットでゾーンが変更になっている可能性もあります。
備考
本件を検証するにあたり拝見した記事です。
ゾーンは物理と論理があります。
仮にサブスクリプションの異なるリソースを扱う場合、見かけ上ゾーンが一致していても物理ゾーンの異なる可能性があります。
ご自身のゾーンが物理的にどこと紐づいているか確認する方法も述べられているので、気になる方はチェックしてみてください！
最後に
AllocationFailedについてのあれこれを私なりに整理してみました。
少しでも参考になれば幸いです。
「参考になった」コメントや「リンクを貼って紹介してくださる」など励みになります。
また、間違えている部分等があれば是非優しめにコメントいただけますと嬉しいです。
参考文献
Views: 0
