Managed Service Column ＜システム運用コラム＞OSレベルの仮想化環境からクラウドサービスに移行する

クラウドサービスの利用について、弊社でもよくご相談をいただきます。よくある話として、物理サーバーの中身をそのまま移行する P2V、複数の基盤に分散している仮想サーバーを集約するための V2V 移行があります。そのような中で最近、OS レベルの仮想化環境からの V2V という変わったパターンに遭遇しました。

簡単に概要をまとめると、以下のような内容です。

• 移行元は OpenVZ ベースの VPS サービス
• 移行先は Altus Basic (GMO クラウドが提供する XenServer ベースのパブリッククラウドサービス)
• 移行する仮想マシンの OS は Linux (CentOS)

この条件下でどうやって移行したのかご紹介します。

どこが変わっているのか？

V2V の移行をする場合には、

• 移行前後の環境に適合したコンバータツールを利用する
• 移行前後の環境が共通して export/import ができる形式を介して仮想マシンのデータを移動する

といった方法をとることが多いと思います。ただし、これらの方法は仮想化基盤へのアクセスが必要であり、利用しているクラウドサービス/VPS サービスによっては対応していないことがあります。そういった場合、弊社では移行元の仮想マシンデータをディスクダンプによって丸々取り出し、移行先のブロックデバイスに書き出す、といった方法をとります。移行前後の環境で特殊なドライバが使われていたりしなければ、概ねこの方法でうまく移行できます。

今回の場合も、移行前後とも仮想化基盤へのアクセスはサービスとして提供されていないため、同様の手法が必要でした。しかし、OpenVZ は OS レベルの仮想化環境であり、カーネルが基盤のホスト OS と共有される、いわゆるコンテナ型の仮想化方式です。この方式では仮想マシン (=ゲスト OS) 上で認識できるファイルシステム上にはそもそもカーネルに関するファイル群が存在せず、ディスクダンプを移行先で書き出しても、OS が起動するために必要なファイルが不足するため、そもそも OS が起動しません。このことが、移行の障害となりました。

どうやって移行するのか？

ファイルが不足しているのであれば、どこかから調達すればいい、ということで、以下のような流れを計画しました。

1. 移行先で同じバージョンの OS がインストールされた状態を作成
2. 移行元のファイルシステム上で認識されているすべてのファイル (/dev, /tmp を除く) を取得
3. 移行先マシンをインストールメディア等でブートし、上記データをディスクに展開
4. 移行先マシンをディスクから起動し、微調整

もっと具体的なお話

まずは、移行先で同じバージョンの OS がインストールされた仮想マシンを作ります。Altus Basic では、仮想マシンの新規作成用に、あらかじめいくつかのテンプレートが用意されています。この中に目的のバージョンの OS があればそのまま利用できますが、今回の場合は移行元マシンと同じバージョンのCentOS がテンプレートにありませんでした。こういった場合は、インストールメディアの ISO イメージをアップロードして利用します。

アップロードした ISO イメージを使って仮想マシンを作成します。仮想マシンのスペックは、移行完了時にそのまま引き継がれるため、完了時に必要となるリソースを割り当てます。なお、OS インストール時の構成は minimal で十分です。

作成した仮想マシンは、作ったばかりでなんですが、すぐにシャットダウンします。シャットダウン後、停止中の仮想マシンの設定を開き、ISO イメージを Attach します。Attach するイメージは、仮想マシン作成時に使用したインストールメディアです。

ここまでやれば、このまま仮想マシンを起動すれば ISO イメージから起動できそうに見えますが、起動するためにはもう一工夫必要です。このまま起動すると、基盤である XenServer に対応していないカーネルでは起動できないため、一般的なインストールメディアではブート処理の途中でフリーズします。Altus ではこういった場合、仮想マシンの OS タイプを「Other」に変更することで、XenServer に対応していないカーネルでも起動することが可能です。今回の作業を実施していた時には、このことに気付かず、だいぶ回り道をしました。

これでイメージからブート可能な状態となったため、仮想マシンを起動します。仮想マシンを起動したら、レスキューモードに入り、システムディスクをマウントします。ここまでくれば、特別なことはありません。あとはシステムディスクのマウントポイントを / と見立てて、移行元のデータを展開するだけです。移行元のファイルを tar で固めて転送、もしくはインターネット越しに rsync するなど、よくある方法でできます。展開が終わったら、仮想マシンを一度停止し、OS タイプを戻し、ISO イメージを Detach してから再度起動させます。これで OS が無事に起動してきたら完了です。

気をつけるべきこと

ここまで少し具体的な方法を書いてきましたが、この方法を実施するに当たってはいくつか気をつけるべきことがあります。

グローバルアドレスの変化

クラウドサービスや VPS サービスで、グローバル IP アドレスをサービス間で引き継げる場合は多くないと思います。困るのは、アクセス制限や外部の SaaS サービスを利用している場合に、それらの設定はサーバー上にあるものではないため、IP アドレスが変わっても変更後のアドレスに追従しません。DNS はアクセスのために使うことが多いため、事前にチェックリストに挙がることが比較的多いと思いますが、インターネット越しにデータ転送をしていたり、サーバーから外部のメールサーバーにメールをリレーしたりすると、移行完了後に時間差で気付く場合もあります。そのため、移行するサーバー以外の、関連する外部サービスについても事前に確認をしておき、可能であれば事前にテストを実施するのが安全だと思います。

データ展開時の差分

全領域を rsync で同期する場合は問題ないかもしれませんが、移行元で OS インストール時にデフォルトで配置されるファイルが削除されているような場合には注意が必要です。実際の作業時に、移行元環境では iptables が無効化されていたにも関わらず、移行先環境では有効になっていて、ネットワークアクセスがすべて拒否される事態が一度発生しました。これは、/etc/rcX.d 以下の起動スクリプトの移行時に、移行先にのみ存在するものを削除しなかったことが原因でした。システム動作に大きな影響がなければ問題にはなりませんが、場合によっては大きな問題となりますので、特に仮想マシンの再起動を移行後初めて行う際には、十分に確認することをお勧めします。

ディスクに書き込まれる前のデータ

MySQL の InnoDB など、パフォーマンスのためにメモリ上にキャッシュをもっているようなプロセスは、移行元マシン上で稼動している状態でにデータを抜き出すと、ディスクにデータが書き込まれておらず、移行後に不整合が出る場合があります。理想的には、このようなプロセスを停止した状態を作って作業した方がいいのですが、それが難しい場合には、MySQL であれば flush tables のクエリを実行するなど、メモリ上のデータを書き出してからデータを抽出する必要があります。

まとめ

実際にあった、少し工夫が必要な V2V サーバー移行についてご紹介しました。流れとしては、言われてみればそうだ、という内容になっているかと思いますが、実環境では思いもよらない罠が待っている場合もあるため、実際にやってみると、やはり実態に合わせて試行錯誤が必要になります。今回の事例は、ちょうどいいツールが提供されていなかったり、一般的な方法が実施できなかったりする場合にも、工夫次第で (力技ですが) 移行できる場合がある、という例としてみていただければと思います。