« この製品のインストール環境が破損しています。 | メイン | 11年目最終日 »
2012年9月28日
しもブロ移転
カテゴリ：サーバ移転/下北沢ブ口イラーえすえぬえっす しもブロのサーバを下北沢から大阪のどこかに移転しました。今まで、下北沢の社内サーバでこっそり運営していましたがハードがぶっ壊れそうな予感があったので、うちが使ってるVPSに移転。まー、サーバの電気代だけで5000円くらい、夏の間はエアコンつけっぱなしで1万円弱かかっていたからねー。移転先のVPSなんて月額1480円でスペックも遙かに上。もう、自宅自社サーバの時代は終わりました、、、。
折角なので移転の流れでも書いてみよう。
0.新サーバでテストする、ちゃんと動いてるねー
1.DNSのTTLを短くするよ
2.旧サーバをメンテナンス表示
3.旧サーバのDBをdumpするよ
4.旧サーバから新サーバにコンテンツやらDBdumpデータを移動させるよ（rsync一発）
5.新サーバでDBをrestoreするよ
6.新サーバに仮のホスト名をつけてテストするよ
7.DNSのレコードを書き換えるよ、この瞬間から新サーバにトラフィックが流れはじめるよ。DNSの浸透言うな！ 適切なTTLにしておけば問題ナッシング。アホなbotは延々旧サーバにトラフィック流してるけどな
8.旧サーバ停止もしくは爆破
と、まあ、こんな感じ。ポイントは事前テストでコンテンツとかは持って行っておいて、最後はdumpデータを移行するだけって感じかな。実作業は1時間もかからない、簡単簡単。CentOS5系からCentOS6系への移行だったからちょっとびびってたけど大丈夫だった。新サーバでAPCが悪さをしてエラーが出てたけど、APC自体eraseしちゃえ。
で、同じタイミングで俺の地元の地域SNSが盛大にやらかしていたので(9/19-25までサーバストップ)、バックアップから復旧の流れについても書き留めておく。いや、それにしても大変な復旧作業だったみたいだねーーー。
今回移転したVPSはさくらインターネットのサービスですが、過去にハード障害でVPSごと吹っ飛んだことがあり、フォーマットせざるを得ない状況に合ったので自分たちでバックアップを1日2回取っています、使ってるツールはrsyncで1日2回自動で。ちなみに、バックアップ用のサーバはカゴヤのVPSです。みんなー、Diskのコスパを考えると、カゴヤのVPSがナイスだぜーしかも京都だぜー、おいでやす。ただし、カゴヤは転送量制限が一定量でかかるので、初回のフルバックアップでいきなり転送制限がかかり1Mbpsとかに制限されちゃうから要注意だ。今は、解除されてるけどね。
そして、実際に今のサーバに障害が出たときの対応の話し。
サーバがぶっ壊れたりしたらすぐに監視システム（xymon）からアラートが俺の携帯にメールで届く。内容を確認して、こちらで復旧できるものは復旧作業を行うけど、俺ではどうにもならない場合（bootしない）はさくらインターネットのサポートに連絡して復旧を待ちます。そこで、データが飛んでしまったとか、なんか諸事情で時間がかかるみたいな話になったら、ソッコー代替サーバを準備します。
まずは障害が出ている旨表示するサーバを準備。まー、VPSたくさん借りてるのでそのくらいの表示ならすぐ出来る。そして、新サーバの準備、今借りてる他のサーバを使ってもイイし、VPS・クラウド系で新たにサーバを立ててもいいし。そうだねー、障害のひどさにもよるかなその辺りは。1日くらいで復旧するんだったらメンテナンス表示で乗り切ってもいいけど、なんかもうどうにも埒があかないパターンは新サーバ移行を前提で動くだろうな。で、サーバを準備しつつ平行してデータを京都から新サーバに持ってくる、アクセスログとか無駄にでかいファイルは後回しだぜ、あふぁーん。
そして、最後の判断。バックアップデータは1日2回だから、12時間分のデータは無くなる可能性がある。新サーバを動かしはじめたらそちらにも新たにデータがたまりはじめちゃうので、元のサーバには戻せない。そこはクライアントさんも含めて慎重に検討しちゃおう、まー、クライアントさんも判断できないから俺が判断しちゃうことも多いけどねー。
新サーバ移行を決断したらDNSのレコードを更新して（あ、障害が発生したらそのドメインのTTLはすぐに短めにするんだよー）、新サーバの稼働開始です、あー疲れた、何が疲れるってクライアントさんからバカみたいにたくさん電話がかかってくるからだよ、もー、全力で復旧してるから邪魔にしかならないし実際にその電話に対応していると作業が遅れるからホントにやめてください。
実際にはサーバ復旧が早まったりだとか、いくつかの解決経路があるけど、その経路は複数あっていい。とにかくWebサイトが見れない時間をいかに短縮できるか、サーバエンジニアはそこに全てをかけるわけです。クライアントさんのためにも、そのページを見てくれるコンシューマーの皆さんのためにも、自分のためにも。
実際のサーバ構成はそのサイトそれぞれで違うわけだし、自社でサーバ設備を持っているパターンでは代替サーバがなければメーカーのサポート待ちになっちゃうことも多い。ただ、専用サーバのコストパフォーマンスが劇的に改善している今、自社でサーバを用意することの優位性は薄れつつあると思う。某社の専用サーバが飛んでも、同じハードをいくつも用意しているので1時間くらいでサーバ自体復旧できちゃうからね、凄い時代になったもんだよ。それでも、規模の問題があるだろうから、複数台構成を遙かに超えるパターンは自社で用意した方がいろいろいいんだろうけどね。
で、例のサイトがなんであんな復旧に時間がかかったのか。最初の一報が9月19日17時、そして復旧が25日20時なので実に6日越え147時間近く復旧にかかったんだよね。最初は翌20日に復旧予定だったけど、それが24日に伸びて、22日に旧サーバからのデータの抽出完了と書かれている、、、ん？ 抽出？？ ということは、HDD自体がぶっ飛んでしまったのか？？ でもって、24日から25日に予定が変更されて、夜に復旧したんだよね。
状況から推測する限り、ハードウェアがぶっ壊れた上にHDDもなんかやばいことになった。そして、なんとかデータは取り出せたけど、今度はそのデータが多すぎで新サーバ側への移行に時間がかかった、って感じかな。俺もあのサイト使ってるからよくわかるけど、すんげーデータ量だと思う。フツーにrestoreとか出来ないレベルで、、、。いやー、大変だったんだろうな、ホントにお疲れ様でした。
ファース○サーバでデータが消えちゃった問題とか、俺もさくらに限らずいろいろなサーバで障害によりデータが消えちゃった経験をしているけど、まずはバックアップ、ホントにバックアップ。サーバは壊れる、自社のものでも専用サーバサービスでも、そしてデータが消えることもある。その前提でやらないと絶対ダメだよね、うんうん。
投稿者 ymkx : 2012年9月28日 09:56 |
