Azure IaaS クラシック仮想マシンv1から、リソースマネージャー環境(ARM)仮想マシンv2への移行(migration)

シェアする

、久々の投稿です♪

Azure ARM環境への移行

昔からあるポータル(https://manage.windowsazure.com)がクラシックと呼ばれるようになり、従来のASM(クラシック・デプロイ)環境で作成して使っていた仮想マシン(Ver1)を、ARM(リソース・マネージャー)な環境の仮想マシン(Ver2)に、移行(引越し)をしたくなり、試してみました。

試行錯誤した結果、なんとか乗り越えたところがあるので、オフィシャルに推奨される方式かは?ですが、参考まで公開します

Specializedイメージと、Generarizedイメージで、それぞれ対応が異なることが分かりましたので、記事を更新しました(2016/2/22


移行前の環境(クラシック・デプロイ)

ごくシンプルな、1台の仮想マシンが動いているだけの環境です。 (リモートデスクトップして、Windows Serverの確認作業などに利用しているもの)

  • ストレージ・アカウント(クラシック)
  • 仮想ネットワーク(クラシック)
  • 仮想マシン(クラシック) 1台 Windows Server 2012R2を、日本語環境追加、Office2013追加
  • ロードバランサーは、無し
  • 可用性セットは、無し

手順1 移行先のARMベースの環境作成

新ポータル(https://portal.azure.com)を開き、以下必要なリソースを順番に作成します。

  • リソースグループの作成
  • ストレージアカウントとコンテナー(/vhds)
  • 仮想ネットワーク
  • パブリックIP
  • NSG(ネットワークセキュリティグループ)
  • 仮想NIC

1-1 リソースグループ

移行先として使いたいリージョンを決めて、任意の名前でリソースグループを作成します。 今後作成するリソースは、すべてこのリソースに所属させます 例)リソースグループ名 res-yukiusagi

1-2 ストレージ

任意の名前でストレージアカウントを作成します。 その後、そのストレージアカウント→「BLOB」という順で開き、コンテナーを任意の名前で、アクセス許可は「プライベート」にて作成します 例)ストレージ名 yukiusagi001jpeast コンテナー名 vhds ※コンテナー名は任意ですが、一般的なデフォルトの「vhds」にしておく方が分かりやすいと思います

1-3 仮想ネットワーク

任意の名前とアドレス範囲で、仮想ネットワークを作成し、さらにその一部を任意のサブネットとして指定します 例)仮想ネットワーク名 nw-yukiusagi アドレス 10.0.0.0/16 サブネット名 subnet-service アドレス範囲 10.0.0.0/24

1-4 パブリックIP

任意の名前を決め、パブリックIPを作成します。 今回は、特にIPアドレスが固定されている必要はなく、費用を抑えたいので「動的」を指定します また、後でリモートデスクトップ接続するときに分かりやすい名前を、DNS name labelへ指定します 例)パブリックIP名 pip-mypc01 DNSラベル yukiusagi-mypc01 実際にアクセスするときは、 yukiusagi-mypc01.japaneast.cloudapp.azure.com になります。

1-5 NSG(ネットワーク・セキュリティ・グループ)

レイヤー4(tcp/udp)レベルでの、in/outフィルタリング設定を作成します。 割当先は、仮想ネットワークもしくは仮想マシンを選べますが、今回は仮想マシンに割り当てるつもりで作成します まず任意の名前を決め、一旦NSGを作成します。 例)NSG名 nsg-mypc01 次に、作成されたnsgを開き、受信規則を追加します。 デフォルトの埋め込みルールで、すでに仮想マシンからインターネットへアクセスはすべて許可され、逆にインターネットから仮想マシンへのアクセスはすべて拒否されています 今回はリモートデスクトップで接続できればよいので以下を追加します。 一つ目のルール追加

  • 番号 100
  • 送信元IP ALL
  • プロトコル udp
  • 送信元ポート ALL
  • 送信先ポート 3389
  • 動作 許可

二つ目のルール追加

  • 番号 200
  • 送信元IP ALL
  • プロトコル tcp
  • 送信元ポート ALL
  • 送信先ポート 3389
  • 動作 許可

1-6 仮想NIC

仮想マシンに紐ずく仮想NICを、任意の名前で一旦作成します 例)仮想NIC名 vnic1-mypc01 その後、その仮想NICを開き、先ほど作成した「パブリックIP」および「NSG」を割り当てます。

手順2 仮想ハードディスクのコピー

既存の仮想マシン(Ver1)の仮想ハードディスクファイル(VHDファイル)を、先ほど作成したストレージ・アカウントのvhdsコンテナーへコピーします。 コピー方法は色々ありますが、個人的にWindowsマシンでするなら、以下のどれかです

2-1 フリーのツール

操作が簡単でいいですが、作業用PCを経由してコピーされます。 例 Cerebrata の Azure Explorerとか

2-2 Azcopyコマンド

作業用PCを経由してコピーされます。 ただ、複数のtcpセッションを使っているみたいで、 ネットワークの速度が恵まれているならスループットいいです ※オプションを指定しないとページBLOBにならないので注意

2-3 Azure Powershell の Start-AzureStorageBlobCopy コマンドレット

Azureストレージ内での処理なので、作業用PCを経由せずコピーされます。 ※作業用PCを経由してコピーされる場合は、元のストレージアカウントから、outbound方向で課金が発生することになります。 OSディスク128GBで、約1300円の課金になりますから、同一リージョンに立てた作業用の仮想マシンから作業した方がよいと思います。


手順3a 仮想マシン作成(Specialized Image)

コピー前に、事前にsysprepを実行していない状態のVHDの場合

3a-1 情報の用意

事前準備した以下の情報を用意しておきます

  • リソースグループ名
  • 仮想NIC名
  • 先ほど新しいストレージアカウントにコピーしたVHDファイルのフルパス (例 https://~.blob.core.windows.net/vhds/~.vhd

作成する仮想マシンについて、以下を決定しておきます

  • 仮想マシン名(ポータル上に表示されるもの)
  • 仮想マシンサイズ

3a-2 Powershell画面の起動と、ログイン

「Azure Powershell」を起動し、以下の順にコマンドで操作をします

Login-AzureRmAccount

ポップアップが表示されるので、サブスクリプションを管理できるアカウントを適宜入力します。

3a-3 仮想マシンのパラメーター指定

$AttachVhdUri = `先ほど新しいストレージアカウントにコピーしたVHDファイルのフルパス`
$vm = New-AzureRmVMConfig -VMName `mypc01` -VMSize `Basic_A3`
$nic = Get-AzureRmNetworkInterface -ResourceGroupName `res-yukiusagi` `
-Name `vnic1-mypc01`
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
$vm = Set-AzureRmVMOSDisk -VM $vm -Name `mypc01-osdisk`  `
-CreateOption attach -VhdUri $AttachVhdUri -Windows

※上記はWindowsマシンを想定しています。Linuxマシンの場合は、「-Windows」を 「-Linux」に変更します

3a-4 仮想マシンのデプロイ開始

New-AzureRmVM -ResourceGroupName `res-yukiusagi` -Location `Japan East` -VM $vm

手順3b 仮想マシン作成(Generarized Imageの場合)

コピー前に、事前にsysprepを実行している状態のVHDの場合です (クラシック・ポータルで、キャプチャーしてイメージを作成し、そこから仮想マシンを作成する動きとほぼ同じですね)

3b-1 情報の用意

事前準備した以下の情報を用意しておきます

  • リソースグループ名
  • 仮想NIC名
  • 先ほど新しいストレージアカウントにコピーしたVHDファイルのフルパス(A) (例 https://~.blob.core.windows.net/vhds/~.vhd

作成する仮想マシンについて、以下を決定しておきます

  • 仮想マシン名
  • 仮想マシンサイズ
  • コンピューター名(Windowsホスト名)
  • 仮想ハードディスクのフルパス(B) (例 https://~.blob.core.windows.net/vhds/mypc01-osdisk.vhd

3b-2 Powershell画面の起動と、ログイン

「Azure Powershell」を起動し、以下の順にコマンドで操作をします

Login-AzureRmAccount

ポップアップが表示されるので、サブスクリプションを管理できるアカウントを適宜入力します。

3b-3 仮想マシンのパラメーター指定

デプロイする仮想マシンのWindows Administratorアカウント入力します

$Cred = Get-Credential

例)ユーザー名 pcmaster パスワード ABcd567$

$osDiskSourceImageUri = `先ほど新しいストレージアカウントにコピーしたVHDファイルのフルパス(A)`
$osDiskUri = `仮想ハードディスクのフルパス(B)`
$vm = New-AzureRmVMConfig -VMName `mypc01` -VMSize `Basic_A3`
$vm = Set-AzureRmVMOperatingSystem -VM $vm -Windows -Credential $Cred `
-ComputerName `mypc01` -ProvisionVMAgent -EnableAutoUpdate
$nic = Get-AzureRmNetworkInterface -ResourceGroupName `res-yukiusagi` `
-Name `vnic1-mypc01`
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
$vm = Set-AzureRmVMOSDisk -VM $vm -Name `mypc01-osdisk` -VhdUri $osDiskUri `
-CreateOption fromImage -SourceImageUri $osDiskSourceImageUri -Windows

※上記はWindowsマシンを想定しています。Linuxマシンの場合は、「-Windows」を 「-Linux」に変更します

3b-4 仮想マシンのデプロイ開始

New-AzureRmVM -ResourceGroupName `res-yukiusagi` -Location `Japan East` -VM $vm

手順4 起動した仮想マシンへ追加設定

無事移行できた仮想マシンに、運用上メリットがある追加設定をします 仮想マシンを開き、モニタリングの「診断」を開き、有効化します。これで、CPU使用率などがポータルで確認できるようになります 情報を保存する先のストレージ・アカウントを尋ねられるので、これはVHDを保存しているストレージ・アカウントを選択します。 ※VMAgentについては、元の仮想マシン(Ver1)のときに導入済みであったので、今回は改めて追加導入はしていませんが、もしローカルHyper-V環境から持ち込んだ場合は、ここで追加になろうかと思います。以下のURLからダウンロードしてインストールします VMAgent(http://aka.ms/vmagentwin


補足(以前、ハマったところ)

sysprepを実行せずに、マスターイメージをコピーする方式で、仮想マシンを作成すると発生します

Set-AzureRmVMOSDisk -CreateOption fromImage

New-AzureRmVM コマンドレットで新しい仮想マシン作成開始されたあと、なかなか結果が帰ってきません。 新ポータルから確認すると、状態が「作成中」のままでした 「起動の診断」を開き、ローカルコンソールの画面コピーを確認したところ、Windowsは起動はしていたので、リモートデスクトップ接続をしてみると、元の仮想マシンに設定していたWindowsアカウントでログオンできました。 結局、そのリモートデスクトップ接続した画面で、sysprepコマンドを以下の要領で実行することで、解決しました。

  • OOBEする
  • 一般化(Generalise)する
  • 再起動する

その後、仮想マシン(Ver2)は無事再起動され、状態も「実行中」に変わりました。 コマンドレットも、Successが返ってきました。


参考情報

検証環境
  • Windows 7
  • Powershell 4.0(WMF4.0)
  • Azure Powershell 1.0.1