ラベル サーバー移設 の投稿を表示しています。 すべての投稿を表示
ラベル サーバー移設 の投稿を表示しています。 すべての投稿を表示

2015年12月14日月曜日

IDCFクラウドで東日本リージョンのWordPress環境を西日本リージョンに移して性能アップしてみる

#この投稿はIDCF Cloud Advent Calendar 2015に寄稿しています。

本ブログではIDCFクラウドの西日本リージョンを2回にわたってフォーカスしてみました。
東京からIDCFクラウド西日本リージョンを触ってみた
IDCFクラウド西日本リージョンがオールフラッシュだと言うので検証してみたら神速だった

今回は3回目という事で西日本リージョンに移して性能アップするんかい!?
というのを実際に検証プロセスを共有しながらやってみたいと思います。

東日本リージョン上にWordpressを構築します。
Light.S1でCentOS6.6を使用してインスタンスを立ち上げます。
Wordpressは最近のだと負荷あんまりないので、ver3.0をインストールしてみます。
ちなみにWordpressは全部デフォルトでやると2分で終わります。こんな感じ。

[root@wordpress ~]# yum -y install httpd mysql-server php php-mysql
[root@wordpress ~]# wget http://ja.wordpress.org/wordpress-3.0-ja.tar.gz
[root@wordpress ~]# tar xzvf wordpress-3.0-ja.tar.gz
[root@wordpress ~]# mv wordpress/wp-config-sample.php wordpress/wp-config.php
[root@wordpress ~]# mv wordpress /var/www/html/
[root@wordpress ~]# service mysqld start
[root@wordpress ~]# mysql -uroot -hlocalhost -e "create database database_name_here"
[root@wordpress ~]# mysql -uroot -hlocalhost -e "grant all privileges on *.* to username_here@localhost identified by 'password_here'"
[root@wordpress ~]# service httpd start

以上!

この状態でIPアドレスでWebアクセスすれば見れるんですが、
リージョン間で移動した時にリンクの解決やらで色々と面倒な事になるので、
面倒ですけどDNSを設定してドメインでアクセスする事をお勧めします。。

http://[ドメイン名]/wordpress/

って感じでアクセスしてサイトの初期設定をします。
初期設定したら再度上記のアドレスでWordpressコンテンツが見れる事を確認。
これで一旦計測してみます。
今回はteslaにサーバを立てました。そして同じteslaに居るマシンから計測するという、
東日本リージョンに超絶ハンデを与えて確認してみます。

確認のコマンドは以下。
ab -n 10 -c 10 http://[ドメイン名]/wordpress/

結果はこんな感じでした。
-----
Concurrency Level:      10
Time taken for tests:   1.441 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0
Total transferred:      71330 bytes
HTML transferred:       68760 bytes
Requests per second:    6.94 [#/sec] (mean)
Time per request:       1440.580 [ms] (mean)
Time per request:       144.058 [ms] (mean, across all concurrent requests)
Transfer rate:          48.35 [Kbytes/sec] received
-----

何回か実施しましたが、Requests per secondは6~7という感じでした。

さて、この子をそのまま西日本リージョンに持っていこうと思います。
先ずはnetworkの固有設定を削除してテンプレート化します。

[root@wordpress ~]# rm -f /etc/udev/rules.d/70-persistent-net.rules

「おまえ、syncしたのか?」と言われ続けた世代なので、一応儀式。

[root@wordpress ~]# sync

で、スナップショットとってテンプレートを作ってやります。ここが一番時間かかるかなー。3分くらい。
(安心してください。無停止ですよ。)
初めてやる人はこの辺は、詳しくドキュメントがあるのでこちらが参考になるかと。
http://www.idcf.jp/cloud/pdf/manual_005.pdf
ちなみにCentOS6.6がOSタイプに無いですけど6.4で大丈夫です。

作ったテンプレートを選択してエクスポートからURLを発行します。
発行したURLは後で使うのでメモ帳とかにコピーしておきます。

ここで西日本リージョンにコンパネを切り替えて作業に入ります。
さっき作ったテンプレートを移設するのでコンピューティングからテンプレートを選択します。
テンプレート作成でテンプレートを作っていくんですが、
URLのところにさっきエクスポートから発行したURLをhttpにして入れます。
発行した時はhttpsで発行されますが、ここでインポートするときはhttpに書き換えます。
OSタイプも似てるの選んだり、あとは適当でOKです。
これで西日本リージョンへテンプレートのコピーが始まります。楽勝。
ステータスがDownload Completeになれば完了。およそ2分程度。

で、そのテンプレートを使って仮想マシンを作成すればokです。
西日本リージョンが初の方はsshで入る鍵を作る必要があるのでご注意を。
作ったサーバにログインすればさきほど東日本で作成した見慣れた環境があるはず。
あれ?デジャヴ?と思ったらapacheとmysqlを起動してあげてください。

DNSを西日本リージョンのサーバに向けて浸透を待ちます。
(紛らわしいので東日本リージョンのサーバは落としておくと吉)
これで準備完了。
いよいよ西日本リージョンのサーバを計測します。
超絶ハンデで東日本リージョンのさっきのサーバから計測します。

ab -n 10 -c 10 http://[ドメイン名]/wordpress/

結果はこれ。
----
Concurrency Level:      10
Time taken for tests:   1.386 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0
Total transferred:      71330 bytes
HTML transferred:       68760 bytes
Requests per second:    7.21 [#/sec] (mean)
Time per request:       1386.119 [ms] (mean)
Time per request:       138.612 [ms] (mean, across all concurrent requests)
Transfer rate:          50.25 [Kbytes/sec] received
----

複数回実施しても平均的に6.5~7.5のスコアをマーク。
超絶ハンデを与えたのにすげーぜ!西日本リージョン!

とまぁ、ここまで書いてワクワクしている人には申し訳ないのですが、
恐らくはリリースしたてという事もあるのかなぁと。
この後、東日本リージョンと同じ負荷状況になった時にどうなるかは不明。
なので、ご利用は計画的に。

ただ、現時点では単純に性能アップが見込めるのは間違いなさそうです。
レイテンシの問題を気にされる方が結構居ますが、
日本内ですし、この程度であれば、大体のWebサイトは気にならない程度で済みます。
まぁ、GCP使ってる人であればレイテンシは気にしないでしょうし、
サーバ2~3台で運営しているのであれば、東日本から西日本に置き換えて性能見るのも、
まぁ、1つの手ではないかなーと個人的には思います。
画像が多いサイトは東日本のオブジェクトストレージに入れておけば、
ユーザ側からはそんなにストレス無いんじゃないすかね。

今回プロセスを共有してやってみましたが、DNSの浸透を抜かせば、
全工程は大体10分程度で完結しますので、小腹が空いたら是非お試しください。

それでは、よいクラウド構築を。

2015年3月12日木曜日

VPSからIDCFクラウドにrsyncだけで移設した話

先日、VPSからIDCFに個人的に借りていたサーバを移設しました。
今回はその時に移設した方法をご紹介します。

尚、今回は試しにいつもと違うエディタ使ったら見にくくなりました。ご了承下さい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時間程度停止して行う事にしました。
(メールについてはセカンダリのサーバが無い場合建てた方が良いです。)
今回の作業の順番としては以下のとおり。
  1. 移行先サーバの準備
  2. コンテンツの移設
  3. DNSの変更
ミドルウェア等を構築しなおすと色々と面倒臭いのでrsyncで丸ごと移設させます。
今回は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に追加しておきましょう。

コンソール操作が出来るクラウドであれば何とかなりますが(まさに今回救済されましたw)、
出来ない場合は致命的になり再起動後に上がってこなくなります。
以下は移設先から実行する例です。

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からの移設ついでに簡単にサーバ移設する方法をご紹介しました。

それでは、よいクラウド構築を。