Azure Managed Service Column ＜Azure運用コラム＞Azure Migrateでオンプレ環境からAzureに移行する方法を解説

はじめに

マイグレーションとは、オンプレミスからクラウドなど、システムが稼働する基盤を変えるために実施する移行作業のことを指します。近年、オンプレミスからクラウドへ基盤を移行する企業が増えており、大手クラウドサービスである Microsoft Azure では、Azure Migrate というマイグレーションツールを提供しています。

Azure へのマイグレーションは様々な方法がありますが、この記事では最も容易に、かつ安全にマイグレーションを行える Azure Migrate を用いた具体的な実例も交えて活用方法を紹介します。

1. システムマイグレーションの流れと課題

システムマイグレーションを実施するにあたり、まず重要なことは上司や経営層の理解です。理解を得るためには、システムマイグレーションの全体像や、綿密な計画が必要となります。ここでは、システムマイグレーションの流れと課題について解説します。

1.1 システムマイグレーションの流れ

システムマイグレーションの大まかな流れは以下の通りです。

ステップ 1 ：ゴールの設定

まずは、達成すべきゴールを決めることが必要です。大きなゴール（ KGI ）を設定することで、達成度を明確化することが可能です。KGI としては、IT システムの運用コスト削減や、システムのリプレースといった、マイグレーションすることで何を達成したいのか、ということを設定するとよいでしょう。

ステップ 2 ：PoCの実施

マイグレーションの実施が決まったら、いきなりシステムをマイグレーションするのではなく、PoC （実証実験）を行います。PoC を行うことで、マイグレーションをするにあたっての課題や注意点についての洗い出しができ、本番の精度を高められます。

ステップ 3 ：実機の調査

マイグレーション対象の IT システムの状況を把握します。具体的には、実際にマイグレーションを行うシステムのドキュメント、ハードウェア資産、ソフトウェア資産（ OS ・ミドルウェア）、ログイン情報などを把握します。保有している IT システムに関する資産の状況を把握することで、事前に定めた KGI を達成するための道筋が立てやすくなり、Azure Migration などのマイグレーションツールを使う上で制約がないかどうかも確認できます。

ステップ 4 ：マイグレーション計画の立案と実施

システムマイグレーションの計画を立案しましょう。具体的には、スケジュールとステークホルダ（システムのオーナーやエンドユーザーの洗い出し）の整理を行います。そして、計画に沿ってマイグレーションを実施します。

1.2 システムマイグレーションの課題

システムマイグレーションの大きな課題は、実行する人材とプロセスにあります。システムマイグレーションには、マイグレーション元のサーバに関する知識と、マイグレーション先のクラウドや仮想化技術に関する知識を併せ持つ人材が必要です。また、外部連携をしているシステムなどは、連携しているシステムの運用を理解していることも重要になります。このように、技術とビジネス両面について理解がある人材をアサインできるかが成功のカギとなります。

また、マイグレーションプロセスを実施していくにあたり、手順や連絡先の整理をしておかないと、万が一の際に失敗を招くことになります。洗い出したステークホルダへの綿密な連絡計画や、リハーサルによるマイグレーション手順の確認・確立をしておくといいでしょう。近年では、各クラウドベンダーからマイグレーションツールが提供されていますので、ツール利用を前提として計画を立てると良いでしょう。

次章では、Azure Migrateを使った具体的なマイグレーション方法を解説していきます。

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

3.2 Azure 側の準備

まず、VM イメージの格納先となるストレージアカウントを作成します。

できました。

次に、移行先となる VNet を作成します。
今回は、移行元の IP アドレス範囲と VNet、及び、サブネットを全て同じ値にしますが、移行後の環境のネットワーク設計に合わせて、適切に設定を行ってください。

VNet、サブネット、ともに 172.31.10.0/24 で作成します。

これで、準備完了です。

3.3 Azure Migrate プロジェクトの作成

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

初期設定を行っていきます。

評価ツールは Microsoft が用意している無料のものを選択します。

移行ツールも Microsoft が用意している無料のものを選択します。

この内容で作成します。

右側に小さく表示されていますが、”RworksBlogMigrate” という「移行プロジェクト」が作成されました。

3.4 Azure Migrate による評価

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

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

3.5 Azure Migrate 移行ツールでの検出

移行対象となる仮想マシンを Azure 上から参照できるようにします。
[移行ツール] にある [検出] をクリックします。

移行元と移行先の情報を入力します。

以下の通り、移行に必要な .exe ファイルとクレデンシャルファイルが提供されました。
これをダウンロードして、Hyper-V サーバに配置します。

Hyper-V サーバにて .exe を実行すると、Windows Update を求められたあと、インストールが行われます。
インストールが完了したら、[登録] ボタンをクリックしましょう。

ここで、.exe と一緒にダウンロードしたクレデンシャルファイルを登録します。
これが、コンテナにアクセスするための認証情報となります。

合わせて、Azure へのアクセスにプロキシを経由するかどうかを聞かれます。ここはご自身の環境に合わせてください。
最後に、Azure に対して登録した認証情報でアクセスできるかのチェックが行われます。
無事に完了すると、以下の表示となります。

ここで再度、Azure ポータルに戻ると、[登録の最終処理] というボタンが押せるようになっています。
これをクリックして、登録を完了させましょう。

10分ほど待つと、登録が完了します。

3.6 Azure Migrate レプリケートの開始

次に、移行元から移行先へのレプリケートを行います。
[移行ツール] の [レプリケート] をクリックします。

ソース （移行元）の環境を指定します。

検出された Hyper-V 上の仮想マシンがリストアップされています。移行したい仮想マシンにチェックを入れましょう。

今度は、ターゲット （移行先） の指定です。事前準備で作成した「ストレージアカウント」「VNet」を指定します。

仮想マシンのインスタンスサイズを指定します。

仮想マシンのディスクサイズを指定します。

設定した内容を確認して、レプリケート開始です。

以下の通り、移行ツールの表示が変わります。

“サーバをレプリケートしています” をクリックすると、レプリケートの進捗状況が確認できます。

まず、初回レプリケートが行われたあとに、移行元仮想マシンで更新されたデータが差分レプリケートされていきます。
初回レプリケートは非常に時間がかかるので、気長に待ちましょう。
当然ですが、レプリケートは移行元システムに一切影響を与えません。
レプリケート完了まで時間はかかってしまいますが、そのあいだも、ユーザはいつもどおりシステムを利用することが出来ます。

3.7 Azure Migrate テスト移行

レプリケートが完了しました。
ちなみに、このタイミングでストレージアカウントの中を見てみると、VHD が保存されていることがわかります。

切り替えの前に、レプリケートされたデータから仮想マシンを起動し、動作確認をしてみます。

仮想マシンを起動する先の VNet を選択します。
今回は実際に移行先となる VNet を選択してしまいますが、本番運用の際はテスト用の VNet を用意することをオススメします。

仮想マシンの一覧を見てみると…ちゃんといました。

グローバル IP の割り当てや、ファイアウォールの調整などを行ったあと、RDP で接続してみましょう。
問題なく、ログインができました。

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

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

3.8 Azure Migrate 本番マイグレーション

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

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

[データの損失を最小限に抑えるため、移行前にマシンをシャットダウンしますか] を “はい” にすることで、移行先に仮想マシンが立ち上がると同時に、移行元の仮想マシンはシャットダウンされます。
これにより、移行元の新たなデータ更新は発生せず、シャットダウンされたタイミングでのデータを持った仮想マシンが起動するわけです。

シャットダウンからおおよそ、5分ほどで仮想マシンが立ち上がってきました。
今回は、ダウンタイムは5分ほど、ということになります。

もちろん、問題なく、ログインができました。

おわりに

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

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

切り替え当日にトラブルに見舞われないよう、先述の通り、事前にしっかりとマイグレーション計画を立てることが重要です。 弊社ではお客様のシステムやご要望に合わせて最適なマイグレーション計画の策定から、実際のシステムマイグレーションのサポートまで、システムマイグレーションに関する一貫したサービスを提供しています。お困りの際はお声掛けいただければと思います。

（本文へ戻る）

（本文へ戻る）

Tag： Azure Migrate Azure移行

• 

  VDIとは？メリットと導入時の注意点、VDI製品選定のポイントを解説

• 

  Azure Virtual Desktop（旧：Windows Virtual Desktop）とは？今こそ知りたい基本情報