IDCFクラウド西日本リージョンがリリースされました。
このブログでも既にレイテンシについて取り上げました。
http://cloudyarouze.blogspot.jp/2015/11/idcf.html
今回はオールフラッシュというDisk性能について迫ってみました。
結論から言うと、速すぎ。爆速とか言っててごめんなさい。神速でした。
これを500円で提供してしまうのは本当にクラウド業界にとって良い事なのだろうか？
と余計な心配をユーザにさせてしまうくらい速いです。
これが出来るし、やってしまうのがIDCFクラウドなんですよね。
ほんと他のクラウドと違っていて尖ってて面白いです。
今回はread性能をhdparmで確認する簡易的な性能測定しかしていないです。
なのでこの記事を鵜呑みにせず、是非ご自身で反証をして頂きたい。
クーポンもついてきて無料で試せますし、触った事無い方は是非触って確認してほしいです。
また、writeも確認出来るような形で是非性能測定をしてみてほしいです。（丸投げ）
各クラウドでインスタンスはミニマムなものを選択しています。
比較はhdparm -tを5回で行いました。（間にioctlしてません）
その結果、read速度は以下のようになりました。
GCP（標準） 12.8MB/sec
GCP（SSD） 233.39MB/sec
GMO ALTUS 67.428MB/sec
AWS（汎用SSD） 81.17MB/sec
IDCFクラウド東日本リージョン 209.786MB/sec
IDCFクラウド西日本リージョン 609.334MB/sec
元々東日本リージョンでもGCPのSSDと同じくらいの性能は出てたんですが、
西日本リージョンでは影すら踏めない値が出てしまいました。
何度も時間を変えて繰り返しやりましたが、ばらつきがあるものの、
IDCFクラウドの西日本リージョンは最低でも300MB/secは出てました。
なので、本当にこれだけの速度差があるのだと思います。
GCPの標準Diskは冗長してるので速さ比較して判断するものではないですが
しかし、想像以上に遅いですね。みんなLocalSSDを使いたがる理由がわかります。
この部分だけで単純比較してもクラウドの優位性は影響しないと思っています。
例えばAWSで言えば暖機させる事でさらに性能が出ますし、GCPはcpuがボトルネックでDisk性能が上がりきってないと思います。
bufferだけでなく実際に-Tオプションを使用してcache補正する事でも変わる事もあるかと思います。
そのクラウドにとって最適な状態で行わず、あくまでインスタンス立ち上げ直後のデフォルトの状態を使っています。
また負荷のピークタイムもクラウドによって違うので一概に言えません。
なので、是非ご自身のやり方で、そしてご自身の目でもご確認頂くのが良いと思います。
新規アカウント登録すれば500円のクーポンがついてきますので、是非試してみてください。
http://www.idcf.jp/cloud/
それでは、よいクラウド構築を。
2015年11月12日木曜日
2015年11月10日火曜日
東京からIDCFクラウド西日本リージョンを触ってみた
久々のエントリーです。
IDCFクラウドに待望の西日本リージョンが誕生しました！
先週から触れていた（ステルステスト？）んですが、本日公式発表がありました。
これでやっとIDCFクラウド内でディザスタリカバリ環境を構築したり、
ロケーションを分けて対応をするといった事ができるようになりました。
注目なのは西日本リージョンはDiskが爆速でオールフラッシュ仕様との事。
これは結果によっては東で作るより西で作った方が速くなる可能性がありそうです。
というわけで、やはり気になるのは東京からのレイテンシ。
簡易的ですが早速測ってみました。
AWSの東京リージョンから64byteのpingを100回打って応答速度をみてみました。
東日本リージョン 平均 5.67msec
西日本リージョン 平均15.247msec
東日本→西日本 平均 22.969msec
ちなみに千葉のローカル環境からpingを打った応答速度も殆ど変わりませんでした。
なので、東京からだと約10ミリ秒程度差があるようです。
ちなみに、AWSの東京リージョンから他のロケーションだと、
GCP アジアパシフィック 平均35.315msec
GMO ALTUS東京リージョン 平均2.899msec
という感じですので、さすがに東京と比べると地理的にレイテンシが高くなりますが、
それでも10ミリ秒程度。逆にGCPで気にならない方は全く気にならないと思います。
AWSのシンガポールリージョンからだと東日本の方が早い結果になりました。
地理的に近いから～的な話よりも経路の問題が大きいようですね。
東日本リージョン→シンガポール 平均71.217msec
西日本リージョン→シンガポール 平均80.635msec
ちなみに他のロケーションからですと、
GCP アジアパシフィック→シンガポール 平均217.345msec
GMO ALTUS東京リージョン→シンガポール 平均78.094msec
という感じで、シンガポールに対しては東日本リージョンが1番早い結果になりました。
10ミリ秒程度の差であれば、Diskの速度を考えると
西日本で作った方が早くなりそうですね。
今は未だオープンしたてで人が増えたらどうなるかわかりませんが、
この感じだとかなり期待出来るんじゃないでしょうか。
あ、ちなみに起動はIDCFクラウドですので勿論20秒仕様で爆速でした。
現在、DRに必要な機能がIDCF内では殆ど完結しないので、
DR設計にはRoute53等、別の何かを考える必要がありそうです。
早くDNSにFailover機能や重みづけでのバランシング機能が付くと良いですね。
IDCFクラウドに待望の西日本リージョンが誕生しました！
先週から触れていた（ステルステスト？）んですが、本日公式発表がありました。
これでやっとIDCFクラウド内でディザスタリカバリ環境を構築したり、
ロケーションを分けて対応をするといった事ができるようになりました。
注目なのは西日本リージョンはDiskが爆速でオールフラッシュ仕様との事。
これは結果によっては東で作るより西で作った方が速くなる可能性がありそうです。
というわけで、やはり気になるのは東京からのレイテンシ。
簡易的ですが早速測ってみました。
AWSの東京リージョンから64byteのpingを100回打って応答速度をみてみました。
東日本リージョン 平均 5.67msec
西日本リージョン 平均15.247msec
東日本→西日本 平均 22.969msec
ちなみに千葉のローカル環境からpingを打った応答速度も殆ど変わりませんでした。
なので、東京からだと約10ミリ秒程度差があるようです。
ちなみに、AWSの東京リージョンから他のロケーションだと、
GCP アジアパシフィック 平均35.315msec
GMO ALTUS東京リージョン 平均2.899msec
という感じですので、さすがに東京と比べると地理的にレイテンシが高くなりますが、
それでも10ミリ秒程度。逆にGCPで気にならない方は全く気にならないと思います。
AWSのシンガポールリージョンからだと東日本の方が早い結果になりました。
地理的に近いから～的な話よりも経路の問題が大きいようですね。
東日本リージョン→シンガポール 平均71.217msec
西日本リージョン→シンガポール 平均80.635msec
ちなみに他のロケーションからですと、
GCP アジアパシフィック→シンガポール 平均217.345msec
GMO ALTUS東京リージョン→シンガポール 平均78.094msec
という感じで、シンガポールに対しては東日本リージョンが1番早い結果になりました。
10ミリ秒程度の差であれば、Diskの速度を考えると
西日本で作った方が早くなりそうですね。
今は未だオープンしたてで人が増えたらどうなるかわかりませんが、
この感じだとかなり期待出来るんじゃないでしょうか。
あ、ちなみに起動はIDCFクラウドですので勿論20秒仕様で爆速でした。
現在、DRに必要な機能がIDCF内では殆ど完結しないので、
DR設計にはRoute53等、別の何かを考える必要がありそうです。
早くDNSにFailover機能や重みづけでのバランシング機能が付くと良いですね。
あと、オブジェクトストレージのエンドポイントが西日本には無いようです。
S3との互換性は高いので当分はS3が良い感じでしょうか。
もしくは無料枠もありますし、東日本リージョンで我慢ですね。
次は西日本リージョン噂の爆速ディスクに迫る検証をしてみたいと思います。
それでは、よいクラウド構築を。
2015年8月10日月曜日
Googleを怒らせると仕事にならない
こんにちは。
今回のテーマはクラウドというよりも検索といった方が良いかもしれませんね。
皆さん、普段ググッてますよね。
googleで検索をする事をググる（ggr）などというのは周知のことかと。
先日とある環境でgoogleから検索拒否を食らって検索出来なくなる自体が発生しました。
どうやら同じサブネット内にgoogleへロボットアクセスをしている人が居たらしく、
googleさんから人間のアクセスではないやろ？的な注意をされました。
最初の注意としては人とロボットを区別する為に、表示されるコードを入力させるというもの。
表示されるコードを入力すると普通に検索出来るように戻ります。
これを何回も繰り返すと、どうやら検索拒否となるようです。
で、実際に検索拒否になったときのメッセージがこちら。
まぁ、Yahoo!も同じエンジン使っているので、Yahoo!で検索をすれば良いのですが、
普段からググッている人は、もう完全にしみこんでるわけですね。
従って、Yahoo!で検索すればよくない？といいながら、Yahooをググッてるわけで。
この瞬間に気付きましたね。（あ、こりゃ仕事にならないな。）と。
普段ググれる事が当たり前な分、ありがたみもなく普通に使っていましたが、
ググれなかった時の対応というのも、検討しておかないといけないかもなぁ。
と、ふと思いました。
一応、google、Yahoo、bingでブラウザを分けるというやり方を導入しました。
googleはchrome、YahooはFirefox、bingはIEという感じで。
同様のことが発生した際にはブラウザを変更して検索、対応することに。
え？検索プロバイダを変更するというやり方がスマート？
確かにそうなんですが、実際にこの局面になると、検索プロバイダの変更をググるという事態になったので、
やり方を知ってる人は良いんですが、パッと思いつかない人はブラウザ分けておけばいいと思います。
ちょっとした小ねたでした。
それでは、よいクラウド構築を。
今回のテーマはクラウドというよりも検索といった方が良いかもしれませんね。
皆さん、普段ググッてますよね。
googleで検索をする事をググる（ggr）などというのは周知のことかと。
先日とある環境でgoogleから検索拒否を食らって検索出来なくなる自体が発生しました。
どうやら同じサブネット内にgoogleへロボットアクセスをしている人が居たらしく、
googleさんから人間のアクセスではないやろ？的な注意をされました。
最初の注意としては人とロボットを区別する為に、表示されるコードを入力させるというもの。
表示されるコードを入力すると普通に検索出来るように戻ります。
これを何回も繰り返すと、どうやら検索拒否となるようです。
で、実際に検索拒否になったときのメッセージがこちら。
まぁ、Yahoo!も同じエンジン使っているので、Yahoo!で検索をすれば良いのですが、
普段からググッている人は、もう完全にしみこんでるわけですね。
従って、Yahoo!で検索すればよくない？といいながら、Yahooをググッてるわけで。
この瞬間に気付きましたね。（あ、こりゃ仕事にならないな。）と。
普段ググれる事が当たり前な分、ありがたみもなく普通に使っていましたが、
ググれなかった時の対応というのも、検討しておかないといけないかもなぁ。
と、ふと思いました。
一応、google、Yahoo、bingでブラウザを分けるというやり方を導入しました。
googleはchrome、YahooはFirefox、bingはIEという感じで。
同様のことが発生した際にはブラウザを変更して検索、対応することに。
え？検索プロバイダを変更するというやり方がスマート？
確かにそうなんですが、実際にこの局面になると、検索プロバイダの変更をググるという事態になったので、
やり方を知ってる人は良いんですが、パッと思いつかない人はブラウザ分けておけばいいと思います。
ちょっとした小ねたでした。
それでは、よいクラウド構築を。
2015年8月7日金曜日
S3へFailoverさせてソーリーページを表示させる
運用しているとsorry pageを表示させたいという時があると思います。
S3をWebsite Hostingさせていればソーリーページの運用も出来ます。
ソーリーページであればそこまで大きなファイルにならないでしょうし、
静的なものだと思いますので、S3のWebsite Hostingは使い勝手が良くなります。
料金の計算方法やWebsite Hostingのやり方は以下のエントリーをご覧下さい。
"S3でWebページを作る（Website Hosting）"
http://cloudyarouze.blogspot.com/2015/08/s3webwebsite-hosting.html
方法として今回はAWSのRoute53を使用します。
Route53にはFailoverの機能がついている為、この機能を使えば簡単に実装出来ます。
今回は以下のような図を想定しています。
メインで稼動しているのはEC2のインスタンスですが、何かしら障害があった際には、
DNSFailoverでDNSをS3へ向かせるというシナリオになります。
切り替えには1分～3分程度掛かりますので、こちらが許容である必要があります。
今回の設定の前提条件としては、indexに対してヘルスチェックを行って、
コードの200が返ってきている状態で設定しています。
別途ヘルスチェック用のページ等を用意する場合は読み替えて下さい。
また、EC2instanceとS3は既に設定済みの状態で進めます。
ドメインは以下を想定して作成しています。
EC2instance用：test.pc-bto.info
サービス用（Failoverさせるドメイン）：failover.pc-bto.info
※通常、静的ウェブホスティングではindex documentにindexファイル、
error documentにはエラー時のファイルを指定して表示させますが、
ソーリーページはどのページへリクエストが来ても表示させるようにしたいため、
S3のWebsite Hostingの設定でerror documentとindex document両方に
同じファイルを指定します。これでどのようなパスでリクエストが来てもソーリーページが表示されます。
今回のチェックポイントとしては、
１．Route53でヘルスチェックの設定をする
２．Route53でEC2インスタンスのAレコードを設定する
３．Route53でEC2インスタンスのCNAMEレコードをFailover(primary)で設定する
４．Route53でS3のエンドポイントのCNAMEレコードをFailover(secondary)で設定する
CNAMEとAレコードを同名で登録することは出来ません。
S3はAレコードで登録する事は出来ませんので、EC2instance側をCNAMEに合わせる形にします。
従って、EC2instanceは1度Aレコードを登録する必要があります。
それでは、実際にやっていきます。
まずはヘルスチェックを作成します。
Nameには適当に名前を入れます。
今回はEC2instance側は1台の想定でやっているため、IPAddressでInstanceのIPを指定。
ELBの場合は、一旦CNAMEで別のドメイン名にした後、Domain Nameで登録することで対応可能。
pathは省略してもindexがあれば問題ありません。
今回は確認を早くしたいので、ルールはちょっと厳しめにしました。
10秒毎(fast)にヘルスチェックを行い、2回失敗したらNGという形にしています。
全部出来たらCreateをクリックして作成します。
追加したルールが表示されていることを確認します。
次にAレコードを登録します。
Hosted ZonesからCreate Record Setでレコード追加していきます。
Nameにはサーバ用のドメインを付けます。
ValueにはEC2instanceのIPを記載し、createボタンでレコードを確定します。
次に実際のサービス用ドメインをCNAMEレコードで登録します。
Nameにはサービス用ドメイン名(Failoverさせたドメイン名)を入力します。
TypeはCNAMEを選択。TTLはフェイルオーバー用のレコードになりますので60にします。
Valueには先ほど登録したAレコードのドメイン名を入力。
RoutingPolicyをFailoverに変更 。
Associate with Health CheckをYesにして、先ほど作成したヘルスチェック名を選択します。
この設定でPrimary側で問題が発生した際に検知できるようになります。
次はFailover先、Secondaryの設定をします。
NameとTypeはPrimaryと一緒です。
TTLを60秒にしてValueにはs3のエンドポイントを指定します。
Routing PolicyにFailoverを指定して、Secondaryにチェックを入れます。
SecondaryにはHealth Checkは不要です。この状態でCreateします。
これでS3へのフェイルオーバーの設定が完了しました。
切り替えの時間がそこまでタイトでなければ、良い方法ではないでしょうか。
それでは、よいクラウド構築を。
2015年8月6日木曜日
S3でWebページを作る（Website Hosting）
今更（2015/08/06現在）ですがS3のWebsite Hostingです。
静的なページであればS3だけでWebサイトを公開可能（ウェブサイトホスティング）です。
そもそもS3って何？という方は以下を参照願います。
http://aws.amazon.com/jp/s3/
AWSは勝手にどんどん値下げしてくれるので、知らないうちにどんどん安くなっていきます。
リリース当時は10円でウェブホスティングとか謳っていた記憶がありますが、
もはや1GBで4.2円程度。（1$125円で計算）
たとえドル円レートが1$150円になっても5円を切ってます。
S3にはリクエスト課金があります。
たとえばHTMLと画像が4点で構成した合計1MB程度のペラ１のページを作った場合、
ファイルが全てS3に置いてあれば1回の表示にHTML+画像4点で5リクエスト必要となります。
月間アクセス数が100万程度であれば、500万リクエストです。
この記事を書いている段階で1万リクエストで$0.0037なので、$1.85で231.25円となります。
トラフィックがこのケースだと100万x1MBで約977GBになります。
無料分の1GBを抜いて976GBとした場合、$136.64で17080円となります。
このケースでは、単純計算で17080+231.25+4.2＝17316円かかる形となります。
やはりAWSはトラフィック次第で高くなるんですよね。
Cloudfrontを使っても同じくらいの価格です。
月間1万リクエストくらいで300KB位のページであれば、60円程度です。
ここまで落ちると最適なサイトパターンは大体読めてくると思います。
イメージとしては以下。簡単ですが・・・。（Route53は使わなくてもok）
実施方法は下記に公式ドキュメントがあります。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html
肝心の実施方法ですが、注意する点は３つです。
１．ドメイン名でS3バケットを作る
２．Website Hostingの設定をする
３．バケットポリシーを設定する
それではS3にバケットを作ります。
バケット名はHTTPアクセスさせたいドメイン名(FQDNの最後のドットを抜いたもの)です。
作成したらWebsite Hostingの設定をします。
ここで青線のエンドポイントをコピーしておきます。（後でDNSに登録します。）
indexのファイルを指定します。また、エラー時に特定ファイルを表示させたい場合は、
error documentの指定もします。設定しない場合はS3のエラーページが出ます。
次はVirtualHost出来るようにバケットポリシーを設定します。
バケットポリシーは公式に記載されている通りで問題ありません。
青線部分を今回作成したバケット名（要するにドメイン名）に変更します。
あとはこのバケットにindex.htmlをアップロードすればS3側の準備は完了。
さきほどコピーしたエンドポイントをCNAMEとしてレコード登録すればアクセス出来ます。
それでは、よいクラウド構築を。
静的なページであればS3だけでWebサイトを公開可能（ウェブサイトホスティング）です。
そもそもS3って何？という方は以下を参照願います。
http://aws.amazon.com/jp/s3/
AWSは勝手にどんどん値下げしてくれるので、知らないうちにどんどん安くなっていきます。
リリース当時は10円でウェブホスティングとか謳っていた記憶がありますが、
もはや1GBで4.2円程度。（1$125円で計算）
たとえドル円レートが1$150円になっても5円を切ってます。
S3にはリクエスト課金があります。
たとえばHTMLと画像が4点で構成した合計1MB程度のペラ１のページを作った場合、
ファイルが全てS3に置いてあれば1回の表示にHTML+画像4点で5リクエスト必要となります。
月間アクセス数が100万程度であれば、500万リクエストです。
この記事を書いている段階で1万リクエストで$0.0037なので、$1.85で231.25円となります。
トラフィックがこのケースだと100万x1MBで約977GBになります。
無料分の1GBを抜いて976GBとした場合、$136.64で17080円となります。
このケースでは、単純計算で17080+231.25+4.2＝17316円かかる形となります。
やはりAWSはトラフィック次第で高くなるんですよね。
Cloudfrontを使っても同じくらいの価格です。
月間1万リクエストくらいで300KB位のページであれば、60円程度です。
ここまで落ちると最適なサイトパターンは大体読めてくると思います。
イメージとしては以下。簡単ですが・・・。（Route53は使わなくてもok）
実施方法は下記に公式ドキュメントがあります。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html
肝心の実施方法ですが、注意する点は３つです。
１．ドメイン名でS3バケットを作る
２．Website Hostingの設定をする
３．バケットポリシーを設定する
それではS3にバケットを作ります。
バケット名はHTTPアクセスさせたいドメイン名(FQDNの最後のドットを抜いたもの)です。
作成したらWebsite Hostingの設定をします。
ここで青線のエンドポイントをコピーしておきます。（後でDNSに登録します。）
indexのファイルを指定します。また、エラー時に特定ファイルを表示させたい場合は、
error documentの指定もします。設定しない場合はS3のエラーページが出ます。
次はVirtualHost出来るようにバケットポリシーを設定します。
バケットポリシーは公式に記載されている通りで問題ありません。
青線部分を今回作成したバケット名（要するにドメイン名）に変更します。
あとはこのバケットにindex.htmlをアップロードすればS3側の準備は完了。
さきほどコピーしたエンドポイントをCNAMEとしてレコード登録すればアクセス出来ます。
それでは、よいクラウド構築を。
2015年8月5日水曜日
IDCFクラウドでGitLabを構築
久しぶりにブログを書きます。
今回は500円でGitLabを構築します。
今回は500円でGitLabを構築します。
今更ですが、IDCFさんが連休前に宿題として出されていたものですねｗ
IDCFクラウドのLight.S1を用意します。
ubuntuが楽なのでubuntuで作りましょう。
ファイアウォール等の設定はめちゃ楽ガイドを見て頂ければ。
http://www.idcf.jp/cloud/pdf/IDCFCloud_installation_guide.pdf
ちなみにめちゃ楽ガイドではCentOS6.5で記載されています。
今回この記事で使用しているのはubuntu14.04です。
gitlabの以下URLでOSを選択する画面になりますので選択します。
https://about.gitlab.com/downloads/
あとは記載通りです。（約10分）
IDCFクラウドはrootログインなのでsudoの部分は消して良いでしょう。
apt-get install openssh-server ca-certificates postfix
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash
apt-get install gitlab-ce
gitlab-ctl reconfigure
※自動的にミドルウェアも全部入れてくれます。
※2015/05/12時点で「GitLab 7.10.4」がインストールされます。
ちょっとmemoryが足りなくなるのでswapを1G位積んどきましょう。
dd if=/dev/zero of=/swap bs=1024 count=1048576
mkswap /swap
swapon /swap
echo "/swap swap swap defaults 0 0" >> /etc/fstab
※swap積まないとrails側で処理出来ず、500エラーになります。
あとはブラウザでアクセスします。
※Passwordを変更する為に直ぐにアクセスして変更しましょう。
http://IPアドレス/
Username: root
Password: 5iveL!fe
はい。これで500円gitlabが出来ました。
それでは、よいクラウド構築を。
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のスペック
移設候補としてはAWSのt2.microや新しいGMOクラウド等を視野に入れてましたが、
最終的にコストパフォーマンスが最も優れたIDCFクラウドのlight.S1に移設する事にしました。
light.S1のスペック（標準）
全部で500円(税込)です。
元々1000円弱使っていたので、その予算であれば2台冗長も可能です。
スナップショットも1GB30円程度なので、どちらの運用でも1000円以内で収まります。
今回はオブジェクトストレージを使ってバックアップをする形で、
500円以内に収めてしまおうとおもいます。
今回は検証や自分のドメインのWebサイトなので2時間程度停止して行う事にしました。
（メールについてはセカンダリのサーバが無い場合建てた方が良いです。）
今回の作業の順番としては以下のとおり。
今回はVPS側はCentOS6.2だったのですが、IDCFクラウドにはCentOS6.5からしか
テンプレートがないので、強引に実行する事にしました。
（本来、バージョンを合わせないと後々面倒になります。）
先ずは移行先サーバの準備をします。
詳しいことはめちゃ楽ガイドに書いてありますので省きます。
http://www.idcf.jp/cloud/pdf/IDCFCloud_installation_guide.pdf
サーバを作ってネットワークの設定をしてsshで接続出来れば完了。
あとはコンテンツの移設です。ミドルウェアを停止していきます。
うちの場合は、以下を停止しました。
停止したら一気にrsyncでもってきます。
/etc領域にクラウド毎に必要なファイルが結構あったりするので、deleteオプションを入れてません。
その移設先のクラウド特有の変更してはいけないファイルが解っていれば、
事前にrsyncのexcludeに追加しておきましょう。
コンソール操作が出来るクラウドであれば何とかなりますが（まさに今回救済されましたｗ）、
出来ない場合は致命的になり再起動後に上がってこなくなります。
以下は移設先から実行する例です。
これで実行して後は待つだけです。簡単ですね。
容量的には8GB程度くらいでしたが、Global越しに30分くらいで終わりました。
移設先でミドルウェアを起動して確認を行います。
ここで起動しなかったり、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からの移設ついでに簡単にサーバ移設する方法をご紹介しました。
それでは、よいクラウド構築を。
今回はその時に移設した方法をご紹介します。
尚、今回は試しにいつもと違うエディタ使ったら見にくくなりました。ご了承下さい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からの移設ついでに簡単にサーバ移設する方法をご紹介しました。
それでは、よいクラウド構築を。
登録:
投稿 (Atom)