さくらインターネット移行記#5 久しぶりの移転作業

だいぶ間が空いてしまいましたが、久しぶりのデータセンター移行記です。

アンテナ、カウンター、検索を移転

完全移行もぼちぼちゴールが見えて来た今日この頃ですが、先日もサーバーの移行作業を行いました。はてなアンテナの巡回システム周り一式、はてなカウンター、はてな検索などをまとめて移行しました。今回の移行も深夜作業。夜の 2:00 に集合して作業開始です。上の写真は僕のメンテナンス時の作業着です。

サーバールームからサーバーを運び出します。台車が大活躍です。

ぎっしりサーバーが詰まっていた旧サーバールームも、だいぶ閑散としてきました。まだ 70 台近くのサーバーが残っていますが、開発機などを除くと残り 40 台程度になりました。年内には全部移行できるのではないかと思います。

アンテナやカウンターともなるとはてなの中では古いサービスなので、使っているハードも古い。移転にあたって古いサーバーはハードウェアを交換します。ある程度使えるハードは電源など交換すべき箇所を絞って交換しそのまま流用します。

社用車のインプレッサに詰め込んで、いざ出発。マニュアルなので AT 限定の僕には運転できません。ペーパードライバーの id:maoe がこの日のために練習しました。

データセンターに到着したら、手分け作業。1U サーバーをラッキングする人、サービス停止の機会を見計らってデータ移行の作業をする人、電流を測定する人、など。今回の移転作業は 4 人で行いました。

ラッキングの様子。レールを両脇に取り付けて前からスライドしてはめ込みます。

完成するとこんな感じに。なかなか壮観です。この手の作業も数ヶ月前のド素人状態だった頃に比べてだいぶ効率良くこなせるようになってきました。

大量のデータの移行

上記はデータ移行中の様子。今回の移転にあたってはてなカウンターの古いハードを新しいサーバーに入れ替え。古いカーネルを使っていたので OS ごと入れ替えました。この入れ替えに際して、100GB 超のデータを移動する必要がありました。まともにファイルシステムレベルで rsync や scp ではメンテナンス時間にデータのコピーが終わりません。細かいファイルがたくさんあると、読み取り側のディスクドライブへのアクセスがランダムアクセス中心になってスピードが出ないためです。

そこで、旧サーバーからディスクドライブを外して新サーバーに接続、dd でパーティションごと先頭から末尾まで丸ごとコピーします。こうするとディスクの読み出しがシーケンシャルになるため、回転部品で出来ているハードディスクの性能を十分に出し切った状態でコピーを行うことができます。

いまどきはパーティションはすべて LVM で管理していますので、ボリュームサイズの拡大縮小は論理的に行うことができます。物理的にはサイズの違う二つのディスクを丸ごとコピーしたわけですが、160GB 程度の領域を 400GB 超の論理ボリュームへ移して、その後ファイルシステムを拡張して無事移行完了。

以前に rsync でコピーしたときは 3 〜 4 時間で 20GB 程度しかコピーできなかったところ、今回は 1時間弱で 160GB のコピーが完了しました。物理的なディスクの付け替えなどの作業があるので面倒ですが、大量のデータをコピーするのには悪くない方法です。

ラックの設置、データ移行などが完了したらソフトウェア側の設定変更など地道な作業が続きます。IP アドレスやゲートウェイなどのネットワーク設定を切り替えたり、ロードバランサの設定を切り替えたり、などなど。

データセンターで役に立つ物品

ここで話は変わって、データセンター運用に当たっての小話を。

データセンターではハードウェアを扱う都合上、突然ハードを分解するためにドライバが必要になったり、長いイーサネットケーブルが必要になったりということが珍しくありません。そこでラックの空いた箇所に工具類や替えのパーツなどを置きっぱなしにしておきます。

自作サーバーを扱っているはてなにはマストアイテムのドライバー類。

工具箱には鋏やケーブル類、変わったところでは色付きシールなど。例えば L2 スイッチのある特定のポートだけが故障する、なんてことが稀にありますが、壊れた箇所にはシールを貼り付けておけば、誤って壊れた箇所にまた配線してしまうミスを防ぐことができます。何かと目印用に役に立ちます。

これはブラザーの P-touch。サーバーのラベル用シールを作成します。サーバーには必ずアドレスやホスト名をラベリングをします。これをやっておかないと、外からみてそのサーバーが何者かがわかりません。さくらインターネットのデータセンターでは、サーバーがハングアップしたときなど電話で再起動をお願いできるのですが、そのためにもラベリングは必須です。

変えのパーツ。壊れやすいハードウェアであるハードディスクはもちろん、増設用のメモリなどもある程度確保しておきます。サーバーがハングアップして様子を見に来たら、メモリが不足しているのが原因だった、なんてことも多いです。また、意外とメモリは壊れるもので、交換の頻度はそこそこあります。

電流計。ラックあたりの供給電力には限りがあるので、上限を超えないようにこまめに電流を計測しながらサーバーを追加していきます。さくらさんのデータセンターを借りて間もないころ、適当にやっていたらブレーカーを落として大騒ぎになった(館内に警報がなって何事かと思ったら原因が自分だったという...)こともあり、KYORITSU の業務用の計測器でなるべく誤差なく計測するよう努めています。

Xen で仮想化

ところで、今回の移転にあたっては Xen を活用しています。

Xen はいわゆる仮想化プログラムで、これを使うことで一つの物理的なハードウェア上に複数の OS を稼動させることができます。

データセンターのラックや電力を無駄なく有効活用するには、サーバーの性能あたりに必要な物理的な面積と消費電力をいかに少なくするかが鍵になってきます。はてなのように数百台もサーバーがある環境ではクリティカルな問題です。

Xen を使うことで、データベースのような I/O バウンドな用途のサーバーとアプリケーションサーバーのような CPU バウンドなサーバーを同一ホストで動かして、リソースを無駄なく使うことができます。

最近はハードウェア側、ソフトウェア側共に仮想化の技術がすごい勢いで進歩していて、仮想化することによるオーバーヘッドはある程度無視できる程のレベルになってきています。最近 Xen を使いはじめて徐々にプロダクションでも使いはじめていますが、いまのところ Xen のオーバーヘッドが問題になったケースもありません。

Xen の中に仮想化された OS をインストールする作業がちょっと面倒だったのですが、そこはスクリプトを自分たちで自作して、5分で新しい仮想サーバーが用意できるようにしています。仮想化については ドクター id:stanaka が詳しいので、氏が解説してくれることを期待しましょう。

サーバー管理ツール

いまはてなのサーバーは古いものも併せるとおそらく 300 〜 400 台程度になります。さすがにこのぐらいの台数になると、サーバーの情報を整理するだけでもひと仕事です。どこにどのサーバーが入っていて、どういう用途で使われていて、どういうスペックになっていて、どの程度負荷がかかっているか。

ここ最近まではてなグループのキーワードでちまちま手作業でやってたのですが、あまりに面倒なので id:stanaka と id:hideoki が中心になって社内向けウェブアプリケーションを自作しました。

こんな感じで。データベース上にすべて情報を格納して、負荷状況やサーバーのスペック、用途などを一覧できるようにしてあります。多くの情報はシステムが自動で収集するので、構成変更時もコマンド一発で更新がかけられます。また負荷のグラフはネットワーク上のノードを自動で検出して収集するようになっており、MRTG の設定を手作業で追加していく作業からも解放されました。快適です。

今はまだただの Web + DB アプリケーションですが、いずれ負荷状況に応じて Xen のノードを動的に移動させたり、監視システムと連動させてそのあたりも手間要らずにする...なんてことを考えています。

ところでこのツール、ちょっと欲しい機能があったので自分で追加してしまおう、と思ってソースを開いたら Ruby で書かれていた...というオチがついてきました。いつの間に。

おまけ

徹夜でお疲れのようす。お疲れさま、移転完了もあと少しです。

データセンターからオフィスに戻る頃にはすっかり朝でした。深夜から早朝までの作業でも快く対応してくださったさくらインターネットのスタッフのみなさま、ありがとうございました。

宣伝: スタッフ募集中です!

はてなのインフラスタッフはこんな感じで働いています。はてなはインフラエンジニア、アプリケーション開発エンジニアを絶賛募集中なので興味のある方は 求人情報 を是非ご覧ください。