久しぶりとは？/ セントラルファイナンス
[ 355] さくらインターネット移行記#5 久しぶりの移転作業 - naoyaのはてなダイアリー
[引用サイト] http://d.hatena.ne.jp/naoya/20071120/1195552548
|
完全移行もぼちぼちゴールが見えて来た今日この頃ですが、先日もサーバーの移行作業を行いました。はてなアンテナの巡回システム周り一式、はてなカウンター、はてな検索などをまとめて移行しました。今回の移行も深夜作業。夜の 2:00 に集合して作業開始です。上の写真は僕のメンテナンス時の作業着です。 ぎっしりサーバーが詰まっていた旧サーバールームも、だいぶ閑散としてきました。まだ 70 台近くのサーバーが残っていますが、開発機などを除くと残り 40 台程度になりました。年内には全部移行できるのではないかと思います。 アンテナやカウンターともなるとはてなの中では古いサービスなので、使っているハードも古い。移転にあたって古いサーバーはハードウェアを交換します。ある程度使えるハードは電源など交換すべき箇所を絞って交換しそのまま流用します。 データセンターに到着したら、手分け作業。1U サーバーをラッキングする人、サービス停止の機会を見計らってデータ移行の作業をする人、電流を測定する人、など。今回の移転作業は 4 人で行いました。 完成するとこんな感じに。なかなか壮観です。この手の作業も数ヶ月前のド素人状態だった頃に比べてだいぶ効率良くこなせるようになってきました。 上記はデータ移行中の様子。今回の移転にあたってはてなカウンターの古いハードを新しいサーバーに入れ替え。古いカーネルを使っていたので OS ごと入れ替えました。この入れ替えに際して、100GB 超のデータを移動する必要がありました。まともにファイルシステムレベルで rsync や scp ではメンテナンス時間にデータのコピーが終わりません。細かいファイルがたくさんあると、読み取り側のディスクドライブへのアクセスがランダムアクセス中心になってスピードが出ないためです。 そこで、旧サーバーからディスクドライブを外して新サーバーに接続、dd でパーティションごと先頭から末尾まで丸ごとコピーします。こうするとディスクの読み出しがシーケンシャルになるため、回転部品で出来ているハードディスクの性能を十分に出し切った状態でコピーを行うことができます。 いまどきはパーティションはすべて LVM で管理していますので、ボリュームサイズの拡大縮小は論理的に行うことができます。物理的にはサイズの違う二つのディスクを丸ごとコピーしたわけですが、160GB 程度の領域を 400GB 超の論理ボリュームへ移して、その後ファイルシステムを拡張して無事移行完了。 ラックの設置、データ移行などが完了したらソフトウェア側の設定変更など地道な作業が続きます。IP アドレスやゲートウェイなどのネットワーク設定を切り替えたり、ロードバランサの設定を切り替えたり、などなど。 データセンターではハードウェアを扱う都合上、突然ハードを分解するためにドライバが必要になったり、長いイーサネットケーブルが必要になったりということが珍しくありません。そこでラックの空いた箇所に工具類や替えのパーツなどを置きっぱなしにしておきます。 工具箱には鋏やケーブル類、変わったところでは色付きシールなど。例えば L2 スイッチのある特定のポートだけが故障する、なんてことが稀にありますが、壊れた箇所にはシールを貼り付けておけば、誤って壊れた箇所にまた配線してしまうミスを防ぐことができます。何かと目印用に役に立ちます。 これはブラザーの P-touch。サーバーのラベル用シールを作成します。サーバーには必ずアドレスやホスト名をラベリングをします。これをやっておかないと、外からみてそのサーバーが何者かがわかりません。さくらインターネットのデータセンターでは、サーバーがハングアップしたときなど電話で再起動をお願いできるのですが、そのためにもラベリングは必須です。 変えのパーツ。壊れやすいハードウェアであるハードディスクはもちろん、増設用のメモリなどもある程度確保しておきます。サーバーがハングアップして様子を見に来たら、メモリが不足しているのが原因だった、なんてことも多いです。また、意外とメモリは壊れるもので、交換の頻度はそこそこあります。 電流計。ラックあたりの供給電力には限りがあるので、上限を超えないようにこまめに電流を計測しながらサーバーを追加していきます。さくらさんのデータセンターを借りて間もないころ、適当にやっていたらブレーカーを落として大騒ぎになった(館内に警報がなって何事かと思ったら原因が自分だったという...)こともあり、KYORITSU の業務用の計測器でなるべく誤差なく計測するよう努めています。 データセンターのラックや電力を無駄なく有効活用するには、サーバーの性能あたりに必要な物理的な面積と消費電力をいかに少なくするかが鍵になってきます。はてなのように数百台もサーバーがある環境ではクリティカルな問題です。 最近はハードウェア側、ソフトウェア側共に仮想化の技術がすごい勢いで進歩していて、仮想化することによるオーバーヘッドはある程度無視できる程のレベルになってきています。最近 Xen を使いはじめて徐々にプロダクションでも使いはじめていますが、いまのところ Xen のオーバーヘッドが問題になったケースもありません。 いまはてなのサーバーは古いものも併せるとおそらく 300 〜 400 台程度になります。さすがにこのぐらいの台数になると、サーバーの情報を整理するだけでもひと仕事です。どこにどのサーバーが入っていて、どういう用途で使われていて、どういうスペックになっていて、どの程度負荷がかかっているか。 こんな感じで。データベース上にすべて情報を格納して、負荷状況やサーバーのスペック、用途などを一覧できるようにしてあります。多くの情報はシステムが自動で収集するので、構成変更時もコマンド一発で更新がかけられます。また負荷のグラフはネットワーク上のノードを自動で検出して収集するようになっており、MRTG の設定を手作業で追加していく作業からも解放されました。快適です。 ところでこのツール、ちょっと欲しい機能があったので自分で追加してしまおう、と思ってソースを開いたら Ruby で書かれていた...というオチがついてきました。いつの間に。 データセンターからオフィスに戻る頃にはすっかり朝でした。深夜から早朝までの作業でも快く対応してくださったさくらインターネットのスタッフのみなさま、ありがとうございました。 はてなのインフラスタッフはこんな感じで働いています。はてなはインフラエンジニア、アプリケーション開発エンジニアを絶賛募集中なので興味のある方は 求人情報 を是非ご覧ください。 おお、ありがとうございます。なるほどー、そういえばこないだブレーカー落としたときは一気に OS インストールしてて電力普段より使ってる状態でした。一応その反省で、ある程度余裕を持たせるようにはしてますが度の程度余裕があれば大丈夫か、というのが結構適当なんですよね。参考になります。ケーブリングはプロにあやかりたい!# なぜかこんな時間に DC にいる私ｗ プロのケーブリングの美しさは、ほんっとうに素晴らしい物ですよね。ま近で見てると勉強になるですが、あのケーブリングは見よう見まねでなかなか真似出来ない＞＜ おつかれさまです。こういった苦労があり私達ユーザが無料ではてなのサービスを使える訳ですね。感謝！！ところで、はてなのインフラスタッフって・・現在何人くらいいらっしゃるのですか？？ |
セントラルファイナンスのサイトです。
