Ignite 2020 で発表になった Azure Resource Mover を利用して、東日本リージョンの仮想マシンを米国西部2リージョンに移動してみました。
参考:
前提
東日本リージョン内のリソースグループに存在する VNet に仮想マシンを用意します。
この仮想マシンを米国西部2リージョン内のリソースグループに存在する VNet に移動します。東日本リージョンのリソースグループと VNet はそのまま残しておきます。他の VM が残っている体で。
依存性のチェック
移動したいリソースを Resource Mover に登録すると、依存関係がチェックされます。
怒られました。デフォルトの設定では、リソースが関連しているリソースグループや VNet も一緒に移動しようとするようです。にもかかわらず、移動したいリソースの一覧にリソースグループと VNet が含まれていないので怒られたようです。Validate dependencies を選択すると、リソースグループと VNet を移動の対象に追加するように促されます。
ですが、リソースグループや VNet は他の仮想マシンが残っている体なので移動できません。要件を満たすべく、移動先の設定をカスタマイズします。各リソースの Destination configuration を開いて、米国西部2リージョンに存在している リソースグループと VNet を選択します。
準備
もれなく変更が終われば、依存関係のチェックが成功して準備に進めます。
準備を開始します。VM だけ準備に時間がかかります。裏で何をしているかというと 対象の仮想マシンに Azure Site Recovery を有効化して、初回のレプリケーションを実行しています。そりゃ時間かかるわ・・・
移動という名の複製
準備が終わると各リソースの状態が Intiate move pending になりますので、リソースを選択して Initiate move を実行します。
移動が終わると ステータスは Commit move pending になります。移動が終わったリソースは米国西部2リージョンに新しいリソースが作成されます。東日本リージョンのリソースは残ったままです。
仮想マシンの移動には時間がかかります。何をしているかというと、ASR のテストフェールオーバーが実行されています。
テストフェールオーバが完了すると、仮想マシンのステータスも Commit move pending になります。テストフェールオーバしたので、米国西部2リージョンに仮想マシンが起動して東日本リージョンの仮想マシンは停止した状態になっています。
コミット
すべてのリソースが Commit move pending になったら、最後にコミットします。
コミットが完了するとリソースのステータスが Delete source pending に変わります。東日本リージョンの仮想マシンも ASR が解除されて初期設定の画面が表示されるようになります。
お片付け
移動した仮想マシンには ASR に必要な Mobility Service がインストールされています。このサービスは自動で削除されませんので手作業で削除する必要があります。
参考:Configure settings after the move
裏で動いていた ASR で使われていた Recovery Service Vault と Storage Account も残ったままです。これらのリソースも自動で削除されませんので手作業で削除します。
参考:Delete additional resources created for move
Resource Mover に登録したリソースたちも自動的には削除されません。普段通りの方法で移動元のリソースを削除する必要があります。
さらに、移動元のリソース自体を削除しても Resource Mover 上での登録が削除されないようなので、Resource Mover 的にも移動元リソースを削除します。
振り返り
Azure Resource Mover で仮想マシンを別リージョンに移動してみました。仮想マシンの場合、Resource Mover は Azure Site Recovery のラッパーとして動作するようです。「素の ASR を使えばいいのでは?」と思いましたが、Resouce Mover を利用すると「シンプルな操作性」や「複数のリソースをまとめて動かす場合に一つの画面で全部の操作が済む」といったメリットを得られます。お掃除まで全自動でやってくれれば完璧なのですが・・・