～詳しい移行設計ポイントと手順～
みなさん、こんにちは。@prsdnt_hanage です。 さて、本編は3回に分けて、 第1回 / まずはとりあえずやってみよう 第2回 / 詳しい移行設計ポイントと手順 第3回 / 移行時のパフォーマンスと懸念点 でお送りします。 前回は第一回として3ステップでとりあえずやってみる体験をしました。 今回は “VM-Migration の解説と検証!”の第2回目「詳しい移行設計ポイントと手順」について紹介していきます。目次
1.VM-Migrationによる移行設計をする
～5つのポイント～ VM-Migrationの移行で考えるべきポイントは- 移行先 GCE インスタンスをどのゾーンに配置するか
- 移行先 GCE インスタンスをどのネットワークに配置するか
- 移行元マシンにあるどのデバイスを移行するのか
- 移行元マシンスペックを GCE のどのマシンタイプにするかの対応表
- 移行元マシンで有償ライセンスOSを使用している場合のライセンス移行
| 移行元マシン名 | 移行デバイス | 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 をインストールするためのコマンドが記述されていますので実行します。
# download
wget -O ./installer_linux.py https://gcp.cloudendure.com/installer_linux.py
# install
sudo python ./installer_linux.py \
--no-prompt \
--token={{Agentトークン}} \
--devices=/dev/sda
※ {{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 などデータベースは壊れていないかなど
5．移行先マシン（GCE）生成の最終実施をする
移行元マシンでサービスを止めるなど、デバイス上に変化が起きないような状態にします。 「Cutover」ボタンを押して“最新のスナップショット”をもとにインスタンス生成が行われます。しばらくするとGCEインスタンスが生成されて完了になります。6．移行完了後の後片付け
「VM Migration Service」→「Live Migration」ページで「Disconnect machines from CloudEndure」を選択すると、移行元マシンからのデバイス内容の転送および、転送データからのスナップショット生成が終了します。
3章で説明した“転送を実施するためのファイアウォールルール”、”転送を実施するためのインスタンス”、”移行元マシンから転送されてきたデバイスイメージのスナップショット”が残っていますので、気になる方は削除してしまいましょう。
これでオンプレ → GCEの移行が完了しました！
総括・感想
人が作業することをまとめると- 移行設計をする
- 移行元マシンに Agent をインストールする
- ボタンひとつで任意のGCEインスタンス生成をする
- CloudEndure Management Server から切断する
注意するべき点として
あくまでデバイスのコピーなので、- ランタイムでしか有効にならないサーバ設定は移行されない
- インメモリにしか無いデータは移行されない
- サービス自動起動設定をきちんとする
- (データベースなど)メモリの内容をデバイスにフラッシュ(シャットダウンなど)させてから移行作業を開始する
