AzureのクラシックVMからARMへのマイグレーション機能がGAしてました
記事が出たり引っ込んだりしてたみたいですが、ちゃんと上半期中にGAしたみたいですね。 首を長く長く伸ばしながら待っていてどうにかなりそうなところでした。
▼General availability of IaaS migration from classic to resource manager | ブログ | Microsoft Azure
手組のスクリプトで引っ越すことと比べて、ダウンタイム無しで移行できるのが最大のメリットですかね。
リンク先のドキュメントも、「Updated:」の日付は古いですが、内容は最新化されています(英語版のみ)。 PowerShell, Azure CLI の両方ともちゃんと更新されていましたので安心ですね。
マイグレーションできるもの、出来ないものがありますので、こちらのページから事前によく確認して移行計画を検討しましょう。
[(追記) 補足記事を書きました: 2016/7/5]
<主なポイント>
- IPアドレスやDNS名(クラウドサービスのURL)はそのまま引き継がれます。
- GAのタイミングでストレージアカウントのマイグレーションに対応しました。
- VMとVNETだけARMに移してVHDはクラシックのストレージアカウントに残していくこともできます(v2VMからクラシックのストレージアカウントに繋がるようにしたみたいですね)。
- 移行後は「<cloud-service-name>-migrated」というリソースグループが新たに作られます。
- 「mycloudservice」であれば「mycloudservice-migrated」ですね。
- ただし、DNS名はそのまま移行されますので、「mycloudservice.cloudapp.net」となります。
- クラウドサービスに付いていた暗黙のロードバランサーはARMのロードバランサーが明示的に作成され、エンドポイントは受信NAT規則に置き換えられます。ただし、エンドポイントACLは引き継がれないということなので、NSGは手作業を作ることになりそうです。
- クラシックVMのイメージとディスクはARMのストレージアカウントにマイグレーションできないのであらかじめ削除して下さい。
- VNETもマイグレーションされるので、旧ポータルで作って暗黙のリソースグループが割り当てられているVNETは、やっぱり別リソースグループのままマイグレーションされます(ので、もともと長い暗黙のリソースグループ名に-migrated」が付けられて更に長く)。
さて、ここから移行作業です。 といってもコマンド自体はいたってシンプルで、このあたりに書いてあるとおりです。 この記事ではPowerShellで書いていきますが、CLIでも同じような手順です。
Migrate IaaS resources from classic to Azure Resource Manager by using Azure CLI | Microsoft Azure
事前準備
アカウントにログインし、マイグレーションリソースプロバイダーを登録します。
# ARMのアカウントにログイン Login-AzureRmAccount # ARMのサブスクリプションを選択 Select-AzureRmSubscription -SubscriptionId [サブスクリプションID] # マイグレーションリソースプロバイダーを登録する Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate # ASMのアカウントにログイン Add-AzureAccount # ASMのサブスクリプションを選択 Select-AzureSubscription -SubscriptionId [サブスクリプションID]
移行作業(VNETに接続している仮想マシンの場合)
この場合、VNETをまるっと移行させるイメージになります。実質2行のスクリプト。エラーが出たらロールバック出来ます。
# VNETを指定して移行準備 Move-AzureVirtualNetwork -Prepare -VirtualNetworkName [VNET名] # エラーが出なければコミット Move-AzureVirtualNetwork -Commit -VirtualNetworkName [VNET名] # prepareでエラーが出た場合はロールバック Move-AzureVirtualNetwork -Abort -VirtualNetworkName [VNET名]
移行作業(VNETに接続していない仮想マシンの場合)
この場合は、クラウドサービスを指定して移行させるイメージになります。 また、ARMのVMはVNET必須なので、VNETを新規に自動作成して移行するか、ARMに既存のVNETに移行するということになります。
▼新規にVNETを作って移行する場合
$serviceName = "[クラウドサービス名]" $deploymentName = (Get-AzureDeployment -ServiceName $serviceName).DeploymentName # 移行準備 Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName -CreateNewVirtualNetwork # エラーが出なければコミット Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName # prepareでエラーが出た場合はロールバック Move-AzureService -Abort -ServiceName $serviceName -DeploymentName $deploymentName
▼ARM環境に既存のVNETに移行する場合
$serviceName = "[クラウドサービス名]" $deploymentName = (Get-AzureDeployment -ServiceName $serviceName).DeploymentName # 移行準備 Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName -UseExistingVirtualNetwork -VirtualNetworkResourceGroupName "[既存VNETのリソースグループ名]" -VirtualNetworkName "[VNET名]" -SubnetName "[サブネット名]" # エラーが出なければコミット Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName # prepareでエラーが出た場合はロールバック Move-AzureService -Abort -ServiceName $serviceName -DeploymentName $deploymentName
▼マイグレーション状況の確認
(Get-AzureVM -ServiceName "[クラウドサービス名]" -Name "[VM名]").VM.MigrationState
ストレージアカウントのマイグレーション
ストレージアカウントだけクラシックのままで構わない、とか事情があって移行できない、という場合にはこの手順は不要です。今回、ARMのVMからクラシックのストレージアカウントにあるVHDに接続できるようになったみたいですね。 マイグレーションにあたって、VMのイメージやディスクはARMに移行できませんので、あらかじめ削除しておかないとエラーが出ます。 あと、同じストレージアカウントに、ASMのVMが載っていてもエラーになりますので、先にVMを全て移行しておきましょう。
$storageAccountName = "[ストレージアカウント名]" # 事前準備 Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName # エラーが出なければコミット Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName # prepareでエラーが出た場合はロールバック Move-AzureStorageAccount -Abort -StorageAccountName $storageAccountName
手順はここまでです。 基本的に prepare → commit と繰り返すだけなので作業そのものは簡単ですね。 制約事項を事前によく確認して移行計画をきちんと考えておけば、さほど困るところは無いかと思います。 検証中に「Internal Error」が1回出ましたが、再実行で解決できました。逆ににっちもさっちもという状態になった場合はサポートに頼るしか無いかもしれません。