AzureクラシックVMからARMへのマイグレーションにおける注意点
以前の記事では無停止で綺麗に移行できるケースを紹介しましたが、少なくとも現時点で完璧なツールというわけでもなく、いくつかの注意点があります。 ということで、今回は公式ドキュメントから注意点をいくつか拾っていきたいと思います。 経験上から「引っかかりそうだな-」というところを抜粋していますので、こちらで雰囲気を掴んだら、ドキュメントの方も読んでみて下さいね。
ベースはこちら。
仮想ネットワークに含まれないVMのマイグレーション時
- ARMモデルのVMは必ずVNETに所属する必要があるということから、マイグレーションの際に停止・起動が発生します。
- 具体的に書かれていない気がしますが、試した限りでは「Prepare」時にシャットダウンまで行われ(割り当て解除済み状態)、「Commit」完了後に起動されます。
仮想ネットワークに含まれるVMのマイグレーション時
- ストレージアカウントに関する制限
「Unsupported features」からの抜粋
- ネットワーク関連が厄介そうです
- クラウドサービスやVMに割り当てていない予約IPアドレス。 マイグレーションに使うコマンドの対象がVNETかクラウドサービスなので、まあ当然というか、割り当てておかなければASMに残されるということになります。マイグレーション後に再利用予定のあるIPアドレスであれば、とりあえずでもいいので割り当ててから持っていきましょうということですね。
- エンドポイントのACLも対象外です (Prepareの段階でエラーが出ます)。暗黙のロードバランサーはARMの明示的なリソースとしてのロードバランサーに移行され、エンドポイントは受信NAT規則に置き換えられますが、受信NAT規則にはACLが存在しないため、必然的に移行対象外となる、ということですね(NSGを作ってくれても良さそうな気はしますが)。
- VNETのGateway(サイト対サイト、ExpressRoute、ポイント対サイト)もサポート外 とのこと。これは結構つらいですね…
「Unsupported configurations」からの抜粋
- クラシックリソースに対するRBAC。 これもリソースのURIが変更になるためある意味仕方が無いですね。移行後に手動で再設定する必要があります。
- 複数サブネットに接続されたVM。 これは困るケースも多そうです。
- Web/Workerロールを含むクラウドサービスやVNET。そりゃそうなんですが、ちょっと惜しいですね。同様に、App Service Environment や HDInsight を含むVNETもサポート対象外とのこと。
移行のワークフローにおける注意点
- まず基本として、移行は「Prepare」→「Check」→「Commit / Abort」の流れで行います。
- Prepareはコマンド、Checkは人手による確認、Commit / Abort はコマンドで行います。
- サポート対象外の構成が存在した場合は「Prepare」の工程でエラーが出ます。試した限りでは自動的に削除されるものは無さそうなので、それなりに配慮されているようです。
- Prepareが成功してからCommitもしくはAbortが完了するまでは、管理系の操作がブロックされます。試しにPrepareしたあとのVMに対して、キャプチャやエンドポイントの構成などをポータルから行ったところ、「HostedService xxxx 内の展開 xxxx は、移行処理中であるため変更できません。」というエラーが出ました。台数によっては数時間かかる場合もあるようなので、その辺の考慮も必要になりそうです。
- クオータにも注意。ARMはARMのクオータがあるので、必要に応じてあらかじめ増やしておきましょう。移行中にクオータ制限にかかった場合はrollbackしましょうと書いてありますね。