Azure Managed Service Column <Azure運用コラム>

Azure Migrate

Category: 実践編

2020.09.11

はじめに

2020年になってから、オンプレ環境から Azure 環境への移行の相談を多く頂いております。 移行の方法は様々ありますが、今回は最も容易に、かつ、安全に移行を行える Azure Migrate を紹介します。

Azure Migrate とは

クラウドへの環境移行というと、P2V や V2V、もしくは、新規構築してアプリケーションやデータを移すといった方法が考えられますが、 長時間のダウンタイムが発生したり、移行による環境の変化に対する調整がうまくいかずにシステムが動かなかったりと、ハードルが高いものとお考えの方も多くいらしゃると思います。

ここ数年、AWS や Azure などのクラウドプロバイダが移行のためのサービスを提供するようになり、以前よりずっと容易に、安全に、移行できるようになりました。特に、オンプレ環境をそのまま移す (リフト) する場合は、「オンプレ環境とクラウド環境を継続的にレプリケートし」「切り替え前に移行先環境で動作確認を行い」「あるタイミングで切り替える」といった手法が有効です。継続的にレプリケートをするのでダウンタイムを最小に出来ますし、切り替え前に実際にシステムの動作確認ができるので移行を行ったら動かなかったというトラブルも回避できます。

Azure では、Azure Migrate というサービスによって、オンプレ環境上で稼働している仮想マシンを Azure 環境に移行することをサポートしています。(注1: Azure Migrate と Azure Site Recovery の違い)

Azure Migrate は「評価」と「移行」の2つの機能により、移行に当たって必要なタスクをサポートしています。

「評価」機能では、以下のような要素の検討を行うことができます。
  • Azure Migrate による移行に対応しているか
  • 推奨されるインスタンスサイズ、ディスクサイズの提示
「移行」機能では、以下の2フェーズにより、移行作業を実施します。
  • オンプレ環境の仮想マシンイメージを Azure のストレージに格納 (レプリケート)
  • ストレージの仮想マシンイメージからテスト用仮想マシンを起動 (テスト移行)
  • ストレージの仮想マシンイメージから本番用仮想マシンを起動 (本番移行)

サポートしている OS バージョンなどは、以下の公式ドキュメントを御覧ください。
(評価と移行とでサポートしているバージョンが異なりますので、ご注意ください)
https://docs.microsoft.com/ja-jp/azure/migrate/migrate-support-matrix

本記事では、実際に Hyper-V 上の仮想マシンを Azure 上に移行してみたいと思います。

Hyper-V 環境から Azure 環境に移行

概要

実際に、Azure Migrate を使ってみることにします。 以下の準備が出来ているものとします。
  • Hyper-V 環境があり、1台以上の Windows Server が稼働している
  • Azure のアカウントを持っている
  • オンプレ環境から Azure 環境(ストレージアカウント)に対して、インターネット経由、もしくは、ExpressRoute によるアクセスができる

全体のコンポーネントとしては、以下の通りです。

上記コンポーネントを用意したあと、「評価」→「レプリケート」→「テスト移行」→「本番移行」という流れで移行を行います。

Azure 側の準備

まず、VM イメージの格納先となるストレージアカウントを作成します。 できました。 次に、移行先となる VNet を作成します。 今回は、移行元の IP アドレス範囲と VNet、及び、サブネットを全て同じ値にしますが、移行後の環境のネットワーク設計に合わせて、適切に設定を行ってください。 VNet、サブネット、ともに 172.31.10.0/24 で作成します。 これで、準備完了です。

Azure Migrate プロジェクトの作成

Azure Migrate の画面を開きます。 Azure Migrate プロジェクトと呼ばれる、移行に関する設定セットを作成します。 「評価」「移行」に関してそれぞれツールを選ぶ必要があるのですが、基本的に Microsoft が用意しているもので問題ありません。 必要に応じて、様々な機能を持ったベンダツールを選択することもできます。 初期設定を行っていきます。 評価ツールは Microsoft が用意している無料のものを選択します。 移行ツールも Microsoft が用意している無料のものを選択します。 この内容で作成します。 右側に小さく表示されていますが、”RworksBlogMigrate” という「移行プロジェクト」が作成されました。

Azure Migrate による評価

先述の通り、移行を行う前に移行対象の評価を行うことが出来ます。

ただ、評価を行うにはアプライアンスサーバを Hyper-V 上に作成するか、テンプレート CSV に手動で情報を入力する必要があること、 また、移行を行うにあたって必須項目ではないことから、今回はスキップします。

Azure Migrate 移行ツールでの検出

移行対象となる仮想マシンを Azure 上から参照できるようにします。 [移行ツール] にある [検出] をクリックします。 移行元と移行先の情報を入力します。 以下の通り、移行に必要な .exe ファイルとクレデンシャルファイルが提供されました。 これをダウンロードして、Hyper-V サーバに配置します。 Hyper-V サーバにて .exe を実行すると、Windows Update を求められたあと、インストールが行われます。 インストールが完了したら、[登録] ボタンをクリックしましょう。 ここで、.exe と一緒にダウンロードしたクレデンシャルファイルを登録します。 これが、コンテナにアクセスするための認証情報となります。 合わせて、Azure へのアクセスにプロキシを経由するかどうかを聞かれます。ここはご自身の環境に合わせてください。 最後に、Azure に対して登録した認証情報でアクセスできるかのチェックが行われます。 無事に完了すると、以下の表示となります。 ここで再度、Azure ポータルに戻ると、[登録の最終処理] というボタンが押せるようになっています。 これをクリックして、登録を完了させましょう。 10分ほど待つと、登録が完了します。

Azure Migrate レプリケートの開始

次に、移行元から移行先へのレプリケートを行います。 [移行ツール] の [レプリケート] をクリックします。 ソース (移行元) の環境を指定します。 検出された Hyper-V 上の仮想マシンがリストアップされています。移行したい仮想マシンにチェックを入れましょう。 今度は、ターゲット (移行先) の指定です。事前準備で作成した「ストレージアカウント」「VNet」を指定します。 仮想マシンのインスタンスサイズを指定します。 仮想マシンのディスクサイズを指定します。 設定した内容を確認して、レプリケート開始です。 以下の通り、移行ツールの表示が変わります。 “サーバをレプリケートしています” をクリックすると、レプリケートの進捗状況が確認できます。 まず、初回レプリケートが行われたあとに、移行元仮想マシンで更新されたデータが差分レプリケートされていきます。 初回レプリケートは非常に時間がかかるので、気長に待ちましょう。 当然ですが、レプリケートは移行元システムに一切影響を与えません。 レプリケート完了まで時間はかかってしまいますが、そのあいだも、ユーザはいつもどおりシステムを利用することが出来ます。

Azure Migrate テスト移行

レプリケートが完了しました。 ちなみに、このタイミングでストレージアカウントの中を見てみると、VHD が保存されていることがわかります。 切り替えの前に、レプリケートされたデータから仮想マシンを起動し、動作確認をしてみます。 仮想マシンを起動する先の VNet を選択します。 今回は実際に移行先となる VNet を選択してしまいますが、本番運用の際はテスト用の VNet を用意することをオススメします。 仮想マシンの一覧を見てみると…ちゃんといました。 グローバル IP の割り当てや、ファイアウォールの調整などを行ったあと、RDP で接続してみましょう。 問題なく、ログインができました。

今回は何もアプリケーションを入れていないサーバですので、ログイン確認しかしませんが、 本番運用であれば、このように移行元の環境を今まで通り利用しつつ、移行先でアプリケーションの動作確認を行うことができます。

テストが完了したら、サーバは削除してしまいます。 [テスト移行のクリーンアップ] をクリックしましょう。

Azure Migrate 本番移行

さて、アプリケーションの動作確認が済んだら、いよいよ本番移行です。

[マシンのレプリケート] 画面に戻り、[移行] をクリックします。

[データの損失を最小限に抑えるため、移行前にマシンをシャットダウンしますか] を “はい” にすることで、移行先に仮想マシンが立ち上がると同時に、移行元の仮想マシンはシャットダウンされます。 これにより、移行元の新たなデータ更新は発生せず、シャットダウンされたタイミングでのデータを持った仮想マシンが起動するわけです。 シャットダウンからおおよそ、5分ほどで仮想マシンが立ち上がってきました。 今回は、ダウンタイムは5分ほど、ということになります。 もちろん、問題なく、ログインができました。

さいごに

Azure Migrate を利用すると、事前にアプリケーションの動作確認を行えるうえに、最小のダウンタイムで Azure 環境に移行できることが分かりました。 特に、Hyper-V 環境からの移行であれば事前準備もほとんどいらないので、かなりオススメです。

ただ、仮想マシンの移行自体は簡単に行えましたが、デプロイ時にネットワークや参照 DNS など OS 周りの調整が必要なケースもあります。 また、移行対象のシステムによっては、「DNS の切り替え」「クライアント接続先の切り替え」「アプリケーションの調整」などが発生することもあります。

切り替え当日にトラブルに見舞われないよう、事前にしっかりと移行計画を立てることが重要です。 弊社ではお客様のシステムやご要望に合わせて最適な移行計画の策定を行います。お困りの際はお声掛けいただければと思います。

注1: Azure Migrate と Azure Site Recovery の違い

オンプレ環境から Azure 環境への移行について、以前は、Azure Site Recovery というサービスが用いられていました。 このサービスは、DR 対策のために提供されているサービスですが、移行用途としても使われることが多かったのです。

2019/07 以降は本記事のとおり、Azure Migrate が推奨されています。 とはいえ、Azure Migrate はバックグラウンドで Azure Site Recovery のコンポーネントを使利用しているので、動作原理は殆ど同じです。(明示的に移行サービスというものを用意したかったのかな、と推測しています。)

ちなみに、Azure Migrate プロジェクトの作成後、Recovery Service コンテナーの画面を見てみると、以下の通り、コンテナが勝手に作成されていることがわかります。 このコンテナは Azure Backup や Azure Site Recovery に使われるものと全く同じです。 このことからも、Azure Migrate のバックグラウンドでは Azure Site Recovery が動作していることがわかります。

本文へ戻る

注2 : 移行元環境ごとの準備内容の違い

本記事では、移行元環境が Hyper-V の場合を取り上げましたが、移行元の環境によって準備するものが異なります。

移行元環境によっては、専用アプライアンスサーバを構築したり、移行対象となる仮想マシンにエージェントをインストールする必要があります。 以下に、移行に関しての各パターンをまとめてみました。(評価は別途、アプライアンスが必要になります。)

  • VMWare の場合は、アプライアンスサーバを構築する必要があります。また、要件に合わせて、「エージェントレス」もしくは「エージェントベース」のどちらかのオプションを選択します。 エージェントベースを選択した場合は、アプライアンスによって移行対象のサーバに Mobility Service エージェントがインストールされます。
    https://docs.microsoft.com/ja-jp/azure/migrate/server-migrate-overview
  • Hyper-V の場合は、サーバ上で移行ツールを実行するだけです。
  • 物理サーバ、その他のパブリッククラウドは、アプライアンスサーバを構築する必要があります。また、移行対象のサーバに Mobility Service エージェントをインストールする必要があります。
Hyper-V の場合が最も簡単、ということになります。

本文へ戻る

Tag: Azure移行

Contactお問い合わせ

お見積もり・ご相談など、お気軽にお問い合わせください。

single.php