*

手軽にオンプレからGCEに移行できる、VM-Migration Serviceの解説と検証!(2/3)

公開日: : 投稿者: GCE

~詳しい移行設計ポイントと手順~

みなさん、こんにちは。@prsdnt_hanage です。
さて、本編は3回に分けて、
第1回 / まずはとりあえずやってみよう
第2回 / 詳しい移行設計ポイントと手順
第3回 / 移行時のパフォーマンスと懸念点
でお送りします。
前回は第一回として3ステップでとりあえずやってみる体験をしました。
今回は “VM-Migration の解説と検証!”の第2回目「詳しい移行設計ポイントと手順」について紹介していきます。

1.VM-Migrationによる移行設計をする

~5つのポイント~
VM-Migrationの移行で考えるべきポイントは

  • 移行先 GCE インスタンスをどのゾーンに配置するか
  • 移行先 GCE インスタンスをどのネットワークに配置するか
  • 移行元マシンにあるどのデバイスを移行するのか
  • 移行元マシンスペックを GCE のどのマシンタイプにするかの対応表
  • 移行元マシンで有償ライセンスOSを使用している場合のライセンス移行

になります。
では、順を追ってひとつづつ解説していきます。

この検証での移行設計は以下の通りとしました。
ゾーン: Asia-East
ネットワーク: Default

移行元マシン名 移行デバイス GCE Machine Type ライセンス移行
host1 /dev/sda n1-standard-1 無償

~どのゾーンに配置するか~

  • US Central(アイオワ州カウンシル ブラフス)
  • US West(オレゴン州ザ・ダレス)
  • US East(サウス カロライナ州バークレー郡)
  • EU West(ベルギー、サン・ギスラン)
  • Asia-East(台湾、彰化県)
  • Asia Northeast(東京、日本)

のいずれかを選択できます。どの地域にコンテンツ配信するかに応じて近い場所を選択しましょう。

~どこのネットワークに配置するか~

こちらは GCP コンソール上の「ネットワーキング」→「ネットワーク」で作成されているものから選択できます。自前のネットワークを構築することも可能ですが、解らない方は ‘Default’ でかまいません。

~GCE のどのマシンタイプにするか~

マシンタイプの一覧は[こちら]で参照できます。移行元マシンスペックのCPUの数とメモリ容量を把握し、そのスペックに応じたものを選択します。

~ライセンス移行~

ライセンスが必要なOSを使用している場合には注意が必要です。SUSE、RHEL、およびOracle Linuxの場合は既存のライセンスが必要です。Windowsの場合、既存のライセンスはGCPのPay-As-Goライセンスに変換されます。

2.オンプレからの移行準備をする

さて、移行設計が終わりましたのでいよいよ移行を実施していきます。
その前に、移行準備としてGCP 上で Account / Credential の設定をします。

まずは、認証情報(Credential)の取得を行います。

「IAMと管理」→「API認証情報」→「認証情報を作成」→「サービスアカウントキー」を選択します。

ご自分の”サービスアカウント”を選択し”JSON形式”を選択して”作成”を実行します。

自動的に密鍵のダウンロードが行われますので、大事に保管しておいてください。

続いて、この秘密鍵を使ってVM-Migrationサービスにサインインしてサービスを利用するための準備をしていきます。

「Compute Engine」→「VMインスタンス」→「VMのインポート」を選択します。

以下の通り、Google VM Migration Serviceの画面が開きます。

「Account」 → 「GCP Credential」 で、プロジェクトIDと秘密鍵を指定します。

「Replication Settings」タブで移行先のゾーンとネットワークを選択します。

これで、利用準備が整いました。

3.移行元(オンプレ側)マシンのデバイス内容の転送を開始する

さて、いよいよ移行に入っていきます。
移行元マシンのデバイス内容をGCEに転送するために、vm-migration-agent をインストールします。
vm-migration-agent は、デバイス内容を定期的にGCEに自動的に転送しますので、
vm-migration-agent をインストールしたあとに、デバイス内容に変更があっても定期的に転送を行い、同期を取り続けてくれる仕組みです。これを”Live Migration”といいます。

「VM Migration Service」→「Live Migration」ページの “Download the Installer” と “Then run the installer and follow the instructions” に vm-migation-agent をインストールするためのコマンドが記述されていますので実行します。

※ {{Agentトークン}}は執筆の都合上見えないようにマスクしていますが、実際はページに記述されていますので、コピペで実行してしまってOKです。

Agent のインストールが完了すると、自動的にVM-Migrationサービスが移行を実施するためのインスタンスやディスク生成などが行われます。
※ここで生成されるのは移行先マシンとなるわけではないのでご注意ください。

転送を実施するためのファイアウォールルールが追加されます。

転送を実施するためのインスタンスが生成されます。

移行元マシンから転送されてきたデバイスイメージがスナップショットに追加されます。

※私の環境では終了するまで約3分かかりました。

“Continuous Data Protection” と表示されればデバイス内容の”1回目”のスナップショットが作成されました。
移行元マシン上にデバイス内容に変更がおきたとしても、自動的にGCEに転送して
GCP上のスナップショットが定期的に(2回目移行の同期として)増えていきます。

さて、移行元マシンにAgentをインストールした後はここまですべて自動で行ってくれました。※約40分かかりました。

4.移行先マシン(GCE)生成のテストをする

いよいよ移行先GCE インスタンスを立ち上げてみます。

「VM Migration Service」→「Live Migration」ページで”移行元マシン名”を選択し、「TEST」ボタンを押します。
前章で説明した”GCP上のスナップショットが定期的に(2回目移行の同期として)増えていく”状態は続いており、「TEST」ボタンを押した時点での“最新のスナップショット”をもとに、インスタンス生成が行われます。
しばらくすると、

{{ 移行元マシン名 }}-xxxxxxxx という名前でインスタンスが生成されています。
ssh ログインできるか確かめます。
 ssh -l {{ 移行元マシンにログインするユーザ名 }} {{ 移行先GCEインスタンスの外部IP }}
ログインできたらこれで移行がひとます安心です。

移行テストに関しては、

  • 立ち上がっているプロセスに不備がないか
  • MySQL などデータベースは壊れていないかなど

さまざまあり、ここでは割愛します。
移行実施は何回も繰り返すことができます。
「TEST」ボタンを押すたびに、移行先の古いインスタンスを削除し、“最新のスナップショット”で、インスタンス生成が行われます。

5.移行先マシン(GCE)生成の最終実施をする

移行元マシンでサービスを止めるなど、デバイス上に変化が起きないような状態にします。
「Cutover」ボタンを押して“最新のスナップショット”をもとにインスタンス生成が行われます。しばらくするとGCEインスタンスが生成されて完了になります。

6.移行完了後の後片付け


「VM Migration Service」→「Live Migration」ページで「Disconnect machines from CloudEndure」を選択すると、移行元マシンからのデバイス内容の転送および、転送データからのスナップショット生成が終了します。
3章で説明した“転送を実施するためのファイアウォールルール”、”転送を実施するためのインスタンス”、”移行元マシンから転送されてきたデバイスイメージのスナップショット”が残っていますので、気になる方は削除してしまいましょう。

これでオンプレ → GCEの移行が完了しました!

総括・感想

人が作業することをまとめると

  • 移行設計をする
  • 移行元マシンに Agent をインストールする
  • ボタンひとつで任意のGCEインスタンス生成をする
  • CloudEndure Management Server から切断する

実に簡単ですね!

注意するべき点として

あくまでデバイスのコピーなので、

  • ランタイムでしか有効にならないサーバ設定は移行されない
  • インメモリにしか無いデータは移行されない

この対策としては、

  • サービス自動起動設定をきちんとする
  • (データベースなど)メモリの内容をデバイスにフラッシュ(シャットダウンなど)させてから移行作業を開始する

など、移行前の状態をきちんと確認する必要があります。
これがどれだけできているかによって 「手順4.移行実施&テスト」に費やす時間が変わってきます。

さて今回は、「オンプレからGCEへの移行における詳しい移行設計ポイントと手順」について紹介しました。
みなさんも是非、挑戦してみてください!
次回は「移行時のパフォーマンスと懸念点」を紹介します。
それでは良いインフラライフを!

関連記事

GCEはどこまでディスクを拡張できるのか?手順は?

GCEではディスク容量を自由に設定することができますが、どこまで容量が増やすことができるのか

記事を読む

[GoogleAPI千本ノック] Google Compute Engine API を試してみた

こんにちは。GoogleのAPIを隔週で片っ端から紹介する、GoogleAPI千本ノック 第二回目

記事を読む

2016/07/26 GCE vs AWS vs Azure ベンチマーク

2016/07/26 GCE vs EC2 vs Azureベンチマーク 本シリ

記事を読む

GCEディスクのオンライン拡張を試してみた

GCEではなんと、ディスクを割り当てしたまま拡張することが可能です。 通常良くあるクラウド等では一

記事を読む

GCEのファイアウォールで日本のIP限定化

ファイアウォールで日本に対してのみサービスをしたくないですか? 表記の通りですがそんな声に

記事を読む

GCE VPNの検証

GCE VPNのα版が公開されました。α版のためGoogleに申請し許可制ですが、取り急ぎ性能テスト

記事を読む

2016/05/25 GCE vs AWS vs Azure ベンチマーク

2016/05/25 GCE vs EC2 vs Azureベンチマーク 本シリー

記事を読む

15分でできる!GCE上でGO言語を動作させるための手順

GCP上でGO言語を動かす場合、一番最初に思い浮かぶのはGAE/GOだと思いますが、中にはGCE上で

記事を読む

2014/12/04 GCE vs AWS ベンチマーク

2014/12/04 GCE vs AWS ベンチマーク 本シリーズでは定期的にGCEとEC2のベ

記事を読む

GCP東京リージョン開設記念!東京リージョンでGCE1000コア立ち上げてみた!

GCP東京リージョンが遂に発表になりました。サイレントリリースとして2週間前くらいから一応使える

記事を読む

PAGE TOP ↑