今回はその時に移設した方法をご紹介します。
尚、今回は試しにいつもと違うエディタ使ったら見にくくなりました。ご了承下さいorz
今まで自分のメールやWebサイト的なものはVPS(KVM)で稼動していました。
超絶安定稼動していたので移設等は考えていなかったのですが、
オペミスやら何やらがあったらしく、極めつけはブロードキャストストーム。。
これは早めに解約しなければデータもなくなるんじゃないか？という危機感を抱き、
どこかに移設しようと思い立った訳であります。
ただわざわざミドルウェアを構築しなおしてやる程の話でもないので、
2時間停止のメンテ前提で一気にrsyncで移設しました。
使用用途：Web/Mailサーバ
apache + MySQLでCMSはConcrete5、Wordpressの2つをインストールしてありました。
Mailはpostfix + Dovecot を Webメーラーとpostfixadminで操作する感じでした。
それぞれ複数特に特殊な事もしてません。
VPSのスペック
| 価格 | 1000円弱 |
|---|---|
| Mem | 2GB (使用としてはほぼCacheでbufferも162MB程度) |
| Disk | 50G (常時使用領域は9GB程度) |
| CPU | 2core（共有） |
移設候補としてはAWSのt2.microや新しいGMOクラウド等を視野に入れてましたが、
最終的にコストパフォーマンスが最も優れたIDCFクラウドのlight.S1に移設する事にしました。
light.S1のスペック（標準）
| 価格 | 500円 |
|---|---|
| CPU | 1core |
| MEM | 1GB |
| Disk | 15GB |
| トラフィック | 3TBまで無料 |
| オブジェクトストレージ | 50GBまで無料 |
| 監視ツール | Mackerel ホスト数無制限 無料 |
全部で500円(税込)です。
元々1000円弱使っていたので、その予算であれば2台冗長も可能です。
スナップショットも1GB30円程度なので、どちらの運用でも1000円以内で収まります。
今回はオブジェクトストレージを使ってバックアップをする形で、
500円以内に収めてしまおうとおもいます。
今回は検証や自分のドメインのWebサイトなので2時間程度停止して行う事にしました。
（メールについてはセカンダリのサーバが無い場合建てた方が良いです。）
今回の作業の順番としては以下のとおり。
- 移行先サーバの準備
- コンテンツの移設
- DNSの変更
今回はVPS側はCentOS6.2だったのですが、IDCFクラウドにはCentOS6.5からしか
テンプレートがないので、強引に実行する事にしました。
（本来、バージョンを合わせないと後々面倒になります。）
先ずは移行先サーバの準備をします。
詳しいことはめちゃ楽ガイドに書いてありますので省きます。
http://www.idcf.jp/cloud/pdf/IDCFCloud_installation_guide.pdf
サーバを作ってネットワークの設定をしてsshで接続出来れば完了。
あとはコンテンツの移設です。ミドルウェアを停止していきます。
うちの場合は、以下を停止しました。
# /etc/init.d/httpd stop
# /etc/init.d/postfix stop
# /etc/init.d/dovecot stop
# /etc/init.d/mysqld stop停止したら一気にrsyncでもってきます。
/etc領域にクラウド毎に必要なファイルが結構あったりするので、deleteオプションを入れてません。
その移設先のクラウド特有の変更してはいけないファイルが解っていれば、
事前にrsyncのexcludeに追加しておきましょう。
コンソール操作が出来るクラウドであれば何とかなりますが（まさに今回救済されましたｗ）、
出来ない場合は致命的になり再起動後に上がってこなくなります。
以下は移設先から実行する例です。
rsync \
# システムディレクトリ
--exclude=/proc \
--exclude=/sys \
# デバイスファイル
--exclude=/dev\
# lost+found (破損しているファイル置き場。無ければ不要。）
--exclude=/boot/lost+found \
--exclude=/lost+found \
# リムーバブルメディア
--exclude=/media \
--exclude=/mnt \
# ネットワーク設定
--exclude=/etc/sysconfig/network \
--exclude=/etc/sysconfig/network-scripts \
# カーネル関連
--exclude=/boot \
--exclude=/etc/sysconfig/modprobe.conf \
--exclude=/lib/modules \
# テンポラリディレクトリ
--exclude=/tmp \
--exclude=/var/tmp \
# ファイルシステムの自動マウント設定
--exclude=/etc/fstab \
# DNSのresolv設定（自動で生成される場合が多い為）
--exclude=/etc/resolv.conf \
# ログファイル（上書きをしてはいけない場合のみ)
--exclude=/var/log \
-alze ssh [移行元]:/ /これで実行して後は待つだけです。簡単ですね。
容量的には8GB程度くらいでしたが、Global越しに30分くらいで終わりました。
移設先でミドルウェアを起動して確認を行います。
# /etc/init.d/httpd start
# /etc/init.d/postfix start
# /etc/init.d/dovecot start
# /etc/init.d/mysqld startここで起動しなかったり、Webが見えなかったり、メールが飛ばなかったりした場合は、
別の問題が発生している可能性が高いので切り戻しを考えて、作戦を練り直しましょう。
起動したらvirtualhostもしっかりクライアント側のhostsに書いて確認します。
問題なければ移設先のOSを再起動しますが、
問題がある場合は、大体、ここで死にます（微笑）
要するに上がってこないパターンですね。
上がってこないケースはカーネルパニックやネットワークトラブルです。
カーネルパニックの場合はgrubやfstab周りを確認してみましょう。
最近のクラウドはコンソールがついているのでコンソールから復帰させることが出来ます。
IDCFクラウドもコンソールを触れるので、何かあっても問題は確認可能です。
今回は再起動をしたところ、network疎通が出来なくなりました。
コンソールで確認したところ、eth0を認識しなくなり、dhcpが動作しなかった模様です。
今回はudevも持ってきてしまったのでそこが影響しました。
/etc/udev/rules.d/70-persistent-net.rules
上記から重複エントリーになってる部分を削除して、本来のデバイス(今回追加されているデバイス)をeth1からeth0へ元に戻します。
詳細は以下URLを参考にすると解り易いと思います。
http://qiita.com/tsumekoara/items/964182390a08b678d576
[VirtualBox 4.3] 複製したゲストOS (CentOS) がネットワークに繋がらない: Device eth0 does not seem to be present, delaying initialization が表示された際の対応(tsumekoara)
上記を変更してリブートをしたら正常に上がってきてくれました。
再度、問題ないかアクセスやサービスのチェックを行います。
問題がなければDNSを切り替えて終了になります。
全ての作業をあわせて約1時間程度でした。
全てのサービス停止が必要になりますが、1時間程度で移設出来れば十分ですね。
コンテンツが多い場合でも先にコンテンツを移行させて、
rsyncで同期を常にとっておいて、移設のタイミングの時の負荷を減らすことも可能です。
容量に合わせてプランニングすると良いと思います。
ちなみに今回のrsync移設ですが、稼働中のサーバをAWSに移設したい！
なんて時にloopbackにrsyncでコピーしてAMI化するなんて事もしてました。
中にはCDをマウントして事前に作った環境をrsyncで同様にコピーしておいて、
それをネット環境に繋げないデータセンターに持ち込んで展開する。
なんて方もいたので、色々汎用性があると思います。
移設のハードルを下げてくれると思いますので、ぜひ試してみて下さい。
取り急ぎ移設しましたがバックアップ等の設定は未だしていません。
そのうち色々と必要になると思うのでこのサーバの運用設定等について、
今後は書いていきたいと思います。
今回は自分のVPSからの移設ついでに簡単にサーバ移設する方法をご紹介しました。
それでは、よいクラウド構築を。
