Zenn
🤘

オンプレミスのサーバーを Google Cloud へクラウドリフトする ～クライアント Hyper-V で試してみよう編～

2024/09/30に公開
Google Cloud
hyperv
サーバー移行
移行
クラウド移行
tech

こんにちは。クラウドエース株式会社で Google Cloud 認定トレーナーをしている廣瀬 隆博です。みなさんは思い通りにいかなくて嘆いた経験はありますか？

私はコロナ禍の前に苦労してチケットを取ったヘヴィメタルの来日公演がコロナによって中止され、とても悔しい思いをしたことがあります。
あれから数年が経ち、再び来日公演が開催されることになりましたが、物価上昇により 5,000 円も値上がりしており「思い通りにはいかないなぁ」と嘆いているところです。

あ、ライブは超楽しみです。この記事が公開されるころには、大阪城ホールでテンションが上がっていることでしょう。

さて、今回はそんな 思い通りにいかない記事 です。

本来試したかったのは、サーバー仮想化基盤である Hyper-V で稼働する仮想マシンを Veeam Backup & Replication で Google Cloud へ移行するといったものでした。
著名な VMware から Google Cloud への移行方法を解説する記事は数多くあるのですが、Hyper-V はあまり存在しないようなので解説したかったという感じですね。
私自身は Windows Server 2008 R2 時代に Hyper-V を導入した機器が 100 台以上稼働する環境をお世話していたこともあって、Hyper-V には割と慣れているというのもありますね。

本来試したかったこと

ところが、いろんな制約にハマってしまい、最終的には オンプレミスの物理マシン（を想定した仮想マシン）を Google Cloud へクラウドリフトする といった形での検証となりました。
右往左往した点もお伝えしつつ、物理マシンをクラウドリフトする方法を解説してまいります。

実際に試せたこと

用語解説

初めに、用語を解説していきましょう。
オンプレミスの経験が豊富なエンジニアなら既にご存じの内容が多いかもしれませんので、そういった方は読み飛ばしても構わない内容だと思います。

オンプレミス

オンプレミス（on-premises） とは、ハードウェアやソフトウェアを自身で管理・運用することを指します。
プレミス（premises）は施設や建物の意味であり、その上で動作させるからオンプレミスといった表現ですね。
私は英語が得意ではないので、間違っていたらごめんなさい。

クラウドリフト・クラウドシフト

クラウドリフト とは、オンプレミスで稼働するシステムを そのままクラウドへ移行する ことを指します。
一方 クラウドシフト とは、システムを クラウド用に改修して移行する ことを指します。

今回の解説は前者であり、ハードウェアの保守期限満了などによって サーバーの中身は変更せずクラウド上で引き続き動作させたい場合 に選択します。
オンプレミスからクラウドへの第一歩とも言えるでしょう。

Hyper-V

Windows で使用可能なサーバー仮想化技術が Hyper-V です。同じジャンルでは VMware が有名だったりしますね。
1 台のハードウェアに複数台の仮想マシンを稼働させることで、コストの最適化を図ったりするものです。
用途は多岐にわたるのですが、本記事の主題ではないので割愛いたします。

https://learn.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/about/

クライアント Hyper-V

記事タイトルにも記載した クライアント Hyper-V は、どうやら公式な用語ではないようです。
簡単に経緯を記載すると、Hyper-V 自体は Windows Server 2008 で初登場した機能です。
その後、Windows 8 にも搭載されるのですが、クライアント Operating System（以下、OS） ということもあって機能に制限があります。
そういった観点から、各種記事では クライアント Hyper-V と記載されることになりました。

前述のマイクロソフト公式ドキュメントでは「Windows での Hyper-V と Windows Server での Hyper-V の違い」といった形で記載されているのですが、一瞬悩んでしまう表記だと感じているので、この記事でもクライアント Hyper-V を使っていこうと思います。

Hyper-V Server 2019

実は Hyper-V、無償で試せます。
Hyper-V を試すだけなら Windows Server の試用版を使うことで 180 日は動作するのですが、Hyper-V Server 2019 なら公式サイトにも 無料製品 と明記されており、コンプライアンスにも優しいですね。
手元にちょっとした検証環境が欲しい時にも活躍します。

本当はコレを使って検証したかったのですが、手元には家族共用のノートパソコンしかなく断念しました。
正確にはもっと古いデスクトップ パソコンはあったのですが、メモリ 4GB では流石に厳しいですね。

https://www.microsoft.com/ja-jp/evalcenter/evaluate-hyper-v-server-2019

仮想マシン

仮想化基盤上に作成したサーバーを 仮想マシン と表記します。Google Cloud では Virtual Machine と表記されるものですね。

物理マシン

仮想化技術は使用せず、機器に Windows や Linux を直接導入する方式をここでは 物理マシン と表記します。
この言葉はやや紛らわしいので避けたい気持ちもあるのですが、非仮想マシンを示す適切な言葉が思い当たらず、一般的には物理マシンと表記される事が多いためですね。

ホストサーバー

仮想化基盤を構成するサーバー機器を ホストサーバー と表記します。
この表現が適切なのかはいつも悩むのですが、後ほど出てくる用語でもホストといった言葉が用いられているため、ここでは表記を揃えることにしました。

Veeam Backup & Replication

今回の主役とも言える Veeam Backup & Replication（以下、VBR） とは、文字通りサーバーのバックアップとレプリケーション用に作られたソフトウェアです。
何故コレを採用したのかと言えば、無償の Community Edition が存在するためです。
保護対象が 10 台に制限されています が、今回のようにクラウドリフトで一時的に利用するだけなら影響の無い制約ですね。

私は有償版も多少触ったことがあるのですが、Community Edition もほとんど同じ作りであり、お試し版のような目的で提供されているのかもしれないですね。
公式サイトにも Veeam からの無償のプレゼント と書かれていますが、ほんとにプレゼントのようなありがたい存在です。

https://www.veeam.com/jp/products/free/backup-recovery.html

右往左往して主題にたどり着くまで

最初は面白おかしく右往左往した経緯を書きながら解説していこうと思っていましたが、本題の内容を求めて閲覧してくださった方にはノイズになるかもしれません。
そう考えた結果、この項目にザックリとハマった経緯を書いておくことにしました。
「そんなことより物理マシンをクラウドリフトしたいんだ！」という方は、この項目も読み飛ばしていただいても良いかと思います。

クライアント Hyper-V 上の仮想マシンで Hyper-V が稼働できなかった

Hyper-V 上の仮想マシンで Hyper-V を稼働させることを 入れ子になった仮想化（Nested Virtualization） と呼びます。
これを使えば、私の業務用パソコンでも Hyper-V Server 2019 を動作させられるのではないかと期待していました。
ところがこの機能、CPU に AMD Ryzen を搭載した Windows 10 では動作せず、Windows 11 が必須要件でした。
CPU として仮想化支援技術には対応しているので、まさか OS が原因になるとは思いませんでしたね。

入れ子にできなかったエラー

https://learn.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/user-guide/enable-nested-virtualization

クライアント Hyper-V は VBR のホストベース バックアップに非対応

ネイティブな Hyper-V Server 2019 を使用する案は、上記の事象や機器の問題で早々に諦めました。
そこで、クライアント Hyper-V で動作する仮想マシンをクラウドリフトすれば良いんじゃないか と考えました。

クライアント Hyper-V のクラウドリフト

ところで、仮想マシンのバックアップ方式は主に二種類あります。

  • 仮想マシンの OS にバックアップ ソフトウェアを導入してデータを取得
  • 仮想化基盤から仮想マシンのデータを取得

前者は物理マシンで用いられることの多い手法です。
バックアップ ソフトウェア が対応している OS なら何でもデータを取得できる一方、個別にソフトウェアを導入するのが手間ですね。

後者は仮想化基盤の特徴を活かし、ホストサーバーから 仮想マシンを構成する要素も含めて丸ごとバックアップする 手法です。
クラウド上でのバックアップ機能と近しいのはこちらでしょう。
個別にソフトウェアを導入する手間が省けるので、仮想マシンをバックアップするならこの方式がおススメです。

そんなわけで仮想マシンをバックアップしようとしたところ、なんと VBR は クライアント Hyper-V のホストベース バックアップには未対応でした。
意気揚々と準備を進めていて画像のメッセージが表示された際には愕然としましたね。

ホストベース バックアップ 未対応メッセージ

サービス アカウント キー必須

VBR が Google Cloud とやり取りする際には、サービス アカウント キーを用いた認証が必要となります。
ところが、弊社は組織ポリシーでサービス アカウント キーの発行を禁止しています。
これはセキュリティを考慮した一般的な対処なのですが、いつも失念していて「あっ！」と声を上げることになります。今回もなりました。
結局、社内の情シスにキー発行を申請し、数日待つことになってしまいました。

ホストベース バックアップ 未対応メッセージ

Cloud Build のサービス アカウント仕様変更

最近 Cloud Build のサービス アカウントに仕様変更がありました。
詳細は公式ドキュメントに譲りますが、要は VBR の公式ドキュメント通りに設定するとハマるという状況ですね。
仕様変更は事前に把握していたので驚きは少なかったのですが、「あーそれなー」って声が出ました。

https://cloud.google.com/build/docs/cloud-build-service-account-updates?hl=ja

物理マシンのクラウドリフト手順

さて、そういった右往左往もありましたが、以下の手順でクラウドリフトに成功しました。
あくまで一例であり成功を保証するものではありませんが、理屈もあっているので間違いない手順だとは思います。

本記事は基本的に VBR の公式ドキュメントに従っていますので、こちらも合わせてご参照ください。

https://helpcenter.veeam.com/docs/backup/hyperv/restore_google.html

クラウドリフト対象環境の準備

まずは、クライアント Hyper-V に対してクラウドリフト対象の仮想マシンを準備しましょう。
これは、検証のための事前準備であり、実際のクラウドリフトにおいては不要な手順ですね。

クラウドリフト対象環境の準備

クライアント Hyper-V の有効化

まずは Windows のクライアント Hyper-V を有効にします。
特筆することのない一般的な手順ですので、画像の通りに操作いただければ有効化できるはずです。

Windows の機能の有効化または無効化

クライアント Hyper-V 有効化

Windows Server ダウンロード

続いて、マイクロソフトから Windows Server をダウンロードしましょう。
VBR の対応 OS は Windows Server なので、今回はクラウドリフト対象サーバーも同じものを使用しました。
今どきは Virtual Hard Disk（以下、VHD）が配布されているので、これをダウンロードして起動するだけという良い時代になりました。

なお、今回は試用版として 180 日間だけ使用可能な状態で検証します。
本格的にクラウドリフト環境を用意する場合は、ライセンスの購入などご検討ください。

Windows Server ダウンロード

https://www.microsoft.com/ja-jp/evalcenter/download-windows-server-2022

クラウドリフト対象の仮想マシン作成

それでは、ダウンロードした VHD を使って 仮想マシンを作成しましょう。
なお、この VHD は後で VBR の作成にも使用しますので、操作端末内でコピーしておきましょう。
注意点としては、入手したVHD の制約により第 2 世代の仮想マシンは作成できない ことですね。

あと、このタイミングで IP アドレスをメモ しておくと良いですね。
今回の手順通りに進めると クラウドリフト対象の仮想マシンは停止や再起動によって IP アドレスが変わってしまうので、そういった操作をした場合は再確認するようにしてください。
IP アドレスの調べ方は Google 検索ですぐ見つけられると思うので、今回は割愛いたします。

  • クラウドリフト対象仮想マシン パラメータ
    • 名前
      • hyper-v_target_vm
    • 世代
      • 第 1 世代
    • メモリ
      • 2048 MB 以上
    • ネットワーク
      • Default Switch
    • VHD
      • ダウンロードした VHD ファイルのコピー
    • 国
      • （任意）
    • 言語
      • （任意）
    • 管理者パスワード
      • （任意）

クライアント Hyper-V 起動

仮想マシン作成開始

開始する前に

名前と場所の指定

世代の指定

メモリの割り当て

ネットワークの構成

仮想ハード ディスクの接続

仮想マシン作成 要約

仮想マシン起動

仮想マシン接続

仮想マシン言語設定

仮想マシン ライセンス確認

仮想マシン管理者パスワード設定

仮想マシンログイン画面

仮想マシン パスワード入力

仮想マシン デスクトップ表示

VBR の準備

続いて、VBR を準備しましょう。
これは本来、オンプレミス側、Google Cloud 側のどちらに配置しても良いものです。
しかし、Google Cloud 側に配置すると、オンプレミス側のグローバル IP アドレスを意識した設定が必要になったり、Cloud VPN を検討する必要があります。
ここでは、最も簡単な オンプレミス側に VBR を配置する形 とします。

VBR 用仮想マシン作成

まずは VBR 用仮想マシンを作成します。
手順は先ほどと変わりませんが、メモリ搭載量が異なる点にご注意ください。
なお、後述のチューニングが必要なので、この時点では仮想マシンを起動しないでください。

  • VBR 用仮想マシン パラメータ その 1
    • 名前
      • veeam
    • 世代
      • 第 1 世代
    • メモリ
      • 4096 MB 以上
        • 推奨値は 8192 MB 以上ですが、業務端末のメモリ量が足りず・・・
    • ネットワーク
      • Default Switch
    • VHD
      • ダウンロードした VHD ファイルのコピー

https://helpcenter.veeam.com/docs/backup/vsphere/system_requirements.html

VBR 用仮想マシン チューニング

チューニングというほど大それたものではありませんが、仮想マシンの作成後でないと変更できないパラメータを設定しましょう。
CPU とディスク容量が意外と必要になるんですよね。

  • VBR 用仮想マシン パラメータ その 2
    • ディスク容量
      • 100 GB 以上
        • 今回は多めの 200 GB にしましたが、最適な値は VBR の公式ドキュメントをご参照ください
    • 仮想プロセッサの数
      • 4 以上

仮想マシン設定変更画面起動

VHD 編集画面起動

ディスクの場所

操作の選択

ディスクの構成

VHD 編集要約

プロセッサ

VHD 拡張

仮想マシンを起動して VHD を拡張 しましょう。
提供されている VHD は 40 GB 設定となっていますので、増やした分をドライブに割り当てないと使用できません。

  • VBR 用仮想マシン パラメータ その 3
    • 国
      • （任意）
    • 言語
      • （任意）
    • 管理者パスワード
      • （任意）
    • C ドライブ
      • 200 GB 以上

ディスクの管理起動

C ドライブ拡張開始

ボリューム拡張開始画面

ディスク選択

ボリューム拡張要約

ボリューム拡張完了

VBR ダウンロード

VBR 用仮想マシンの Web ブラウザから VBR のインストーラーをダウンロード しましょう。
もちろん他の方法でダウンロードしてから仮想マシンに転送しても良いので、要は仮想マシン内に VBR のインストーラーが用意できれば OK です。

VBR ダウンロード

https://www.veeam.com/jp/products/free/backup-recovery.html

VBR インストール

ようやく VBR のインストール までたどり着きました。
ダウンロードしたファイルを実行するとインストーラーの実行ファイルが表示されるので、それを起動してください。
（「ISO をマウントしてインストーラーを起動」と書いた方が詳しい人には伝わるかもしれませんね）

こちらもチューニング要素はあるのですが、ひとまず検証ということで ほとんど既定値 で動作させています。

  • VBR インストール パラメーター
    • サービス アカウント（Windows）
      • LOCAL SYSTEM account
        • Google Cloud のサービス アカウントとは異なる のでご注意ください
    • データベース
      • PostgreSQL
        • 新規インスタンス導入
        • サービス アカウントにて Windows 認証
    • データ ロケーション
      • 全て C ドライブ配下の規定値
        • 性能に関わるので実運用ではしっかり設計しましょう

VBR インストーラー起動

VBR インストール開始

VBR インストールメニュー選択

VBR ライセンス確認

VBR ライセンス更新選択

VBR サービス アカウント選択

VBR データベース設定

VBR データ ロケーション設定

VBR インストール開始

VBR インストール完了

VBR 起動

このタイミングで必須の操作ではありませんが、せっかくインストールしたので起動してみましょう。
Community Edition で動作していること が確認できますね。

VBR 起動

VBR ライセンス表記

VBR 初期画面

Google Cloud の準備

オンプレミス側の準備は終わったので、Google Cloud 側を準備しましょう。
ここでは新しいプロジェクトを作成して一から設定する場合の手順となっています。

API 有効化

まずは、今回の仕組みに 必要な Application Programming Interface（API）を有効化 しましょう。
必要なものは Compute Engine API 、および Cloud Build API です。

https://console.cloud.google.com/marketplace/product/google/compute.googleapis.com

https://console.cloud.google.com/marketplace/product/google/cloudbuild.googleapis.com

サービス アカウント準備

続いて、サービス アカウントを準備 します。

https://helpcenter.veeam.com/docs/backup/hyperv/gcp_iam_permissions.html

新規サービス アカウント作成および権限付与

VBR を動作させるための 新規サービス アカウントを作成 します。

  • 新規サービス アカウント設定
    • サービス アカウント名
      • （任意）
    • サービス アカウント ID
      • （任意）
    • サービス アカウント 権限
      • Compute Admin role (roles/compute.admin)
      • Cloud Build Editor role (roles/cloudbuild.builds.editor)
      • Project IAM Admin role (roles/resourcemanager.projectIamAdmin)
      • Storage Admin role (roles/storage.admin)
      • Storage HMAC Key Admin (roles/storage.hmacKeyAdmin)
      • Viewer role (roles/viewer)
    • ユーザーへのアクセス許可
      • （任意）

サービス アカウント作成開始

サービス アカウント名称

サービス アカウント権限

サービス アカウント作成完了

サービス アカウント作成結果

新規サービス アカウント キー作成

作成した サービス アカウントの秘密鍵を作成 します。
みなさんも自身の組織での制約に引っ掛かって「あっ！」ってならないことを願います。

作成されたキーは操作端末にダウンロードされるので、VBR 仮想マシン内へ配置して使うことにご注意ください。
操作に不安がある場合、本操作を VBR 仮想マシンの Web ブラウザでやってしまうと楽ですね。

サービス アカウント キー管理画面起動

サービス アカウント キー作成開始

サービス アカウント キータイプ選択

Cloud Build サービス アカウント権限付与

VBR のリストアには Cloud Build が用いられる 為、こちらのサービス アカウントにも権限を付与します。

  • Cloud Build サービス アカウント設定
    • サービス アカウント名
    • サービス アカウント 権限
      • Compute Admin role (roles/compute.admin)
      • Service Account Token Creator role (roles/iam.serviceAccountTokenCreator)
      • Service Account User role (roles/iam.serviceAccountUser)

Cloud Build サービス アカウント権限付与

物理マシンのバックアップ

いよいよクラウドリフトを始めましょう。
まずは 物理マシン（を想定した仮想マシン）をバックアップ します。

動作確認用ファイル配置

やはりクラウドリフトが成功した証拠が欲しいですよね。
ここでは、デスクトップに新しいファイルを配置することにしました。
このファイルが Google Cloud 上で確認出来たら Yeah! となるわけですね。

動作確認用ファイル配置

VBR によるバックアップ

動作確認の準備も整ったので、VBR でバックアップしていきましょう。

  • VBR バックアップジョブ
    • ジョブモード
      • タイプ
        • Server
      • モード
        • Managed by backup server
    • ジョブ名
      • （任意）
    • コンピューター
      • クラウドリフト対象マシンの IP アドレス
      • 認証情報
        • 管理者権限を持つユーザーの名称およびパスワード
    • バックアップ モード
      • Entire Computer
    • バックアップ先
      • Local Storage
    • ローカル ストレージ
      • 場所
        • （任意）
    • ゲスト上での処理
      • Enable application-aware processing のみ有効化
        • Volume Shadow Copy Service による整合性のあるバックアップを取得する
    • スケジュール
      • スケジューリングしない
    • 要約
      • Run the job when I click Finish を有効化
        • ジョブを即時実行する

バックアップ ジョブ開始

ジョブモード設定

ジョブ名設定

バックアップ対象追加操作

バックアップ対象 IP アドレス設定

バックアップ対象 認証情報設定

バックアップ対象 設定完了

バックアップ モード設定

バックアップ先選択

バックアップ ストレージ指定

バックアップ動作設定

バックアップ スケジュール設定

バックアップ ジョブ開始

バックアップ ジョブ実行中

バックアップ ジョブ完了

バックアップ データ確認

Google Cloud にリストア

これが最後の手順ですね。
バックアップしたサーバーを Google Cloud にリストア しましょう。

VBR サービス アカウント キー登録

まずは Google Cloud のサービス アカウント キーを VBR に登録 しましょう。
キーファイルはとても機密性の高いものなので、デスクトップに置きっ放しにして忘れたりしないように注意 してくださいね。

クラウド認証情報登録開始

Google Cloud サービス アカウント登録開始

サービス アカウント種別選択

サービス アカウント キー選択

キーファイル選択画面

キーファイル選択結果

サービス アカウント キー登録開始

サービス アカウント キー登録結果

サーバーのリストア

いよいよクラウドリフトですね。
サーバーのバックアップを Google Cloud へリストア します。

  • VBR リストアジョブ
    • 対象の仮想マシン
      • （自動選択済み）
    • アカウント
      • （登録したサービス アカウント キーを選択）
      • （任意のリージョンとゾーンを選択）
    • 名称
      • （Google Cloud上での仮想マシン名を指定）
    • インスタンス
      • （Google Cloud上でのインスタンス タイプを指定）
        • 改めて見てみると、バックアップ時より性能の高いインスタンスを指定していて変な感じですね
    • ネットワーク
      • （任意のネットワークを指定）
    • セキュア リストア
      • （スキャン動作は指定せず）
    • ヘルパー アプライアンス
      • e2-micro
        • 本記事ではヘルパー アプライアンスの詳細は割愛

リストアジョブ 開始

リストア対象サーバー確認

リストア アカウントとネットワーク設定

リストア時の VM 名指定開始

リストア時の VM 名指定結果

リストア時の インスタンス タイプ指定開始

リストア時の インスタンス タイプ指定結果

リストア時の ネットワーク指定開始

リストア時の ネットワーク指定結果

セキュア リストア

ヘルパー アプライアンス指定開始

ヘルパー アプライアンス指定結果

リストアジョブ要約

リストアジョブ結果

リストア ジョブログ

リストアされた仮想マシン

クラウドリフト結果

おわりに

そんなわけで右往左往しましたが、無事に物理マシン（を想定した仮想マシン）のクラウドリフトに成功しました。
仕組みや手順が分かってしまえば、意外と簡単にクラウドリフトができるということをお伝えできていれば幸いです。

これはこれで有用な記事にはなりましたが、やはり Hyper-V で稼働する仮想マシンをホストベースでバックアップしてクラウドリフトしたいですよね。
そんなわけで、来年には オンプレミスのサーバーを Google Cloud へクラウドリフトする ～Hyper-V Server 2019 で試してみよう編～ と題して再チャレンジを考えています。
なぜ来年なのかと言えば、来年度の予算で物理マシンを一台用意したいからですね。

また、VBR のヘルパー アプライアンスとか、リストア中の動作も次回の記事で解説したいところです。
これが何故次回なのかといえば、本記事のボリュームが増えすぎたというのもあります。
また、「試してみよう編」なので、あまり深く突っ込むのを控えようという思いもあります。

そういった狙いもありますので、無事に機器が用意できて続編が公開されることをお楽しみに！

クラウドエース株式会社 Google Cloud 認定トレーナーの廣瀬 隆博がお届けしました。また次の記事でお会いしましょう。

Discussion