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

Azure Migrate

Category: 実践編

2020.09.11

はじめに

マイグレーションとは、オンプレミスからクラウドなど、システムが稼働する基盤を変えるために実施する移行作業のことを指します。近年、オンプレミスからクラウドへ基盤を移行する企業が増えており、大手クラウドサービスである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を使った具体的なマイグレーション方法を解説していきます。

2. 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 上にマイグレーションする流れについて記載していきます。
以下では、実際の画面を交えた具体的な操作を説明します。

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

3.1 概要

実際に、Azure Migrate を使ってみることにします。
以下の準備が出来ているものとします。

  • Hyper-V 環境があり、1台以上の Windows Server が稼働している
  • Azure のアカウントを持っている
  • オンプレ環境から Azure 環境(ストレージアカウント)に対して、インターネット経由、もしくは、ExpressRoute によるアクセスができる

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

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

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 の切り替え」「クライアント接続先の切り替え」「アプリケーションの調整」などが発生することもあります。

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

注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 の場合が最も簡単、ということになります。

本文へ戻る

Azure移行を任せたい

Azure移行サービス

Azure移行サービス

Azure移行を代行し、スムースなAzure運用開始をサポートいたします。移行を実施するにあたっては、ヒアリング、検証、要件定義、移行作業、稼働確認までを一貫した流れで実施してまいります。

Tag: Azure移行

Contactお問い合わせ

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

single.php