はじめに
企業のITインフラをクラウドへ移行する際、オンプレミス環境から Microsoft Azure へのスムーズな移行は重要な課題のひとつです。Veeam Backup & Replication(以下、VBRと表記します)を活用することで、コストを抑えながら柔軟に環境を移行できます。
本記事では、VBRを利用した主な移行方法について紹介します。
移行方法の比較
VBRを用いたオンプレミス環境から Azure への移行には、大きく分けて以下の2つの方法があります。
1:バックアップ & リストアによる移行
VBRの「Restore to Azure」機能を活用することで、オンプレミス環境のバックアップを取得し、Azure環境へ復元できます。この方法は追加コストが不要で、比較的低コストかつ柔軟に移行が可能です。ただし、レプリケーションや即時フェイルオーバーといった機能は提供されていないため、移行に時間がかかる点には注意が必要です。また、DR(ディザスタリカバリ)用途には適していません。
2:レプリケーションによる移行
Veeam 社が提供する Veeam Cloud Connect Replication を利用することで、オンプレミス環境からクラウドベースの仮想化インフラ(例:vSphere や Hyper-V を使用した環境)へレプリケーションを実装できます。ただし、Azure 上のレプリケーションには制限があり、Veeam Cloud Connect Replication を利用する場合は「Azure VMware Solution(AVS)」の仮想化インフラを構築し、その環境へレプリケーションする必要があります。 そのため、Azure の ネイティブ VM(Azure VM)とオンプレミス VM の間で直接レプリケーションを行うことはできません。また、AVS の構築と運用には高額なコストがかかるため、特別な要件がない限り採用されるケースは限られるでしょう。
ここでは、パターン 1 のバックアップ & リストア方式で、オンプレミス環境から Azure への移行手順(リストア手順)を紹介します。
バックアップ & リストアによる移行手順
オンプレミス環境から、AzureへのVM移行手順は以下となります。
- VBRにAzureアカウント(Azure アプリ作成)を連携
(VBR を使用してオンプレミス環境のバックアップを取得) - Azureへのリストアを実行
- 環境の確認
移行前の確認事項
オンプレミス環境からの移行については、以下の項目について事前の確認が必要です。
カテゴリ | 検討項目 | 補足 |
VM仕様 | vCPU数、メモリ、ディスク構成 | AzureのVMサイズと合致するか確認(特にGen1/Gen2) |
OS/カーネル | 対応しているRHELバージョンか | Azure公式対応表 |
アプリ | アプリの構成依存 | IPやホスト名変更に弱いアプリは注意 |
ネットワーク | VNet設計とサブネット構成 | DNS設定、固定IPの有無、NSG(ファイアウォール)ルール |
認証 | SSHキー/アカウント/SELinux等 | Azure展開時にSSHキー設定が必要な場合あり |
ストレージ | Azure上でのディスク構成 | Managed Disk、I/O要件(Premium必要か) |
リストア方式 | Gen2イメージ or Gen1か | VMサイズとの組み合わせ制限あり |
ライセンス | RHELサブスクリプション移行 | ・BYOS(Bring Your Own Subscription)か、Azure Marketplace使用か ・アプリライセンスの移行可否(Windows ServerやSQLなど)も確認する |
事前準備
環境を構成する前に、以下の用意が必要です。
- 移行サーバを配置するAzure環境の登録
移行するAzureVMが格納される環境及び構成要素を用意します。
-
- サブスクリプション
- リージョン
- リソースグループ
- ストレージアカウント
- 仮想ネットワーク(VNet)
- NSG(VNet)
- VBRでアカウント設定を行う
VBR側で、以下のアカウント登録を行います。- Azureアカウント
- ストレージアカウント
以下に、実際の手順についてご紹介していきます。
VBRにAzureアカウント連携の設定(Azure ADアプリ作成)
最初に、VBRにてAzureアカウントの連携(Azure ADアプリ作成と登録)を行います。VNRのGUI画面から、メニューを開き、「Credenatials & Passwords」から「Cloud Credentials」をクリックします。
「Manage Cloud Credentials」にて「Add」をクリックして、「Microsoft Azure conpute account...」を選択します。
「Cpmpute Account」の名前と、説明を入力し、「Next」をクリックします。
連携するAzureの構成環境を「Microsot Azure」と「Microsot Azure stack」のどちらかから選択します。この例では「Microsot Azure」を選択します。Regionは一般的な環境の場合、「Global」を選択します。
Azureアカウント新規作成するか、既存のアカウントを利用するかの選択ができます。ここでは新規に作成するものとします。
Azure Deviceに接続するためのパスコードが表示されます。こちらをメモします。また、「Enable direct restore of Linux-based machines」にもチェックを入れます。
ブラウザから、「https://microsoft.com/devicelogin」に接続します。先程表示されたパスコードを入力します。
認証画面が表示されるので、Azure環境にログインします。
「アプリケーションにサインインしました」と表示されるので、VBRの画面に戻ります。
アカウントが作成され、このような「Summary」画面が表示されます。内容を確認し、「Finish」をクリックします。
Azure側では、以下のようなアプリケーションが構成されます。
Azureへのリストアを実行
リストア対象のVMをVBRから選択し、右クリックして、「Restore to Microsoft Azure...」を選択します
必要であれば、リストア対象のVMから、「Point」を選択し、リストアポイントを選択して「Next」をクリックします。
リストアポイントの個別選択が不要であれば、そのまま「Next」をクリックします。
「Subscription」画面で、リストア対象のサブスクリプション及びロケーションを選択します。「Next」をクリックします。
なお、ここではProxyサーバを指定できます。実はAzure環境にはVeeamProxyを構成できます。そちらを構成している場合であれば、この項目にチェックを入れて選択してもらえれば、リストアのパフォーマンスが向上します。
リストア対象がLinuxマシンの場合、Azure側の環境にヘルパーアプライアンスが必要になります。一度作成してしまえばそれ以上作成する必要はないですが、初回のリストア時に作成することができます。ここは「Yes」をクリックして、作成します。
「Add」をクリックします。
「ヘルパーアプライアンス」の構成について以下を設定します。
- サブスクリプション
- ロケーション
- ストレージアカウント
- リソースグループ(新規に作成も可能ですし、既存リソースグループへの配置も可能です)
- 仮想ネットワークとサブネット
登録されたら「Next」をクリックします。
自動的にアプライアンスが作成されます。「Next」をクリックします。
構成のサマリ画面が表示されます。「Finish」をクリックします。
Azure側では、以下のようなヘルパーアプライアンス(AzureVM)が作成されます。
リストアVM選択画面に戻ります。「Next」をクリックします。
リストア対象のVMの構成についての設定画面が表示されます。必要に応じ、この構成を変更します。
この構成を間違えると、リストアが失敗します。特に多いのが、ターゲットVMサイズの世代(Gen1/Gen2)の整合性確認です。
VMwareでデフォルトであるUEFIブートのVMはGen2となりますので、注意が必要です。
また、VMサイズによってはクォータ制限に抵触する可能性もあります。あらかじめ、事前確及び必要に応じ申請が必要です。
構成を変更したら、ディスクについても確認します。必要に応じ、設定を変更して、「Next」をクリックします。
リストア先のリソースグループを設定します。既存のリソースグループの指定もできますし、新規に作成することもできます。指定して、「Next」をクリックします。
リストア時に接続する仮想ネットワークとサブネット、PublicIPの付与またNetwork Security Groupを指定します。Network Security Groupは指定しない状態でも先に進められますが、セキュリティ上考えると設定がひつようかと思います。「Next」をクリックします。
リストアの理由及び目的について、必要であれば記載します。「Next」をクリックします。
サマリ画面が表示されるので確認します。リストア後に自動的にパワーオンにするためには「Power on target VM after restoring」にチェックを入れます。「Finish」をクリックします。
「Restore completed successfully」と表示されたらリストア完了となります。
Azure側では以下のようなVMが作成されています。
環境の確認
リストア完了後は、環境の調整が必要となります。リストア後の環境をリストア前と比較してみると、ネットワーク構成(NIC,DNS設定など)などで差異が発生しているのがわかります。IPアドレスなどネットワーク構成はAzure側で再設定が必要になる場合が多い
そのため、環境の確認は必要です。また、RHEL等の場合、サブスクリプションの再登録が必要になる可能性もあります。
おわりに
いかがでしたでしょうか。
VBRを活用することで、オンプレミス環境からAzureへの移行を柔軟かつ効率的に実現できます。ただし、移行方法の選定にあたっては、運用要件やコスト、セキュリティポリシーなどを踏まえ、最適なアプローチを見極めることが重要です。
今回はAzureを例に解説しましたが、AWSやGoogle Cloudなど他の主要クラウドサービスにも同様の手法で対応可能です。
なお、バックアップからのリストアによる移行作業は比較的シンプルですが、事前の設計・検証や移行後の動作確認など、考慮すべきポイントは多くあります。弊社では、移行先クラウド環境の設計・構築から、移行計画の立案・実施、そして移行後の運用まで、ワンストップでご支援しています。
クラウド移行をご検討の際は、ぜひお気軽にご相談ください。
RELATED SERVICES関連サービス
RELATED ARTICLE関連記事
2025.05.20
【Veeam backup & replication】ReplicationによるVMware環境間の仮想マシン移行
- Veeam Backup & Replication
- インフラ
- クラウド
- 仮想基盤
2025.05.21
VHRISOでVeeam強化リポジトリを作る(その2)
- Veeam Backup & Replication
2025.05.28
【OCVS Migration】オンプレミス環境の仮想マシンをOCVSへ移行してみた
- Oracle Cloud Infrastructure(OCI)
- Oracle Cloud VMware Solution(OCVS)
- Veeam Backup & Replication
- インフラ