サービスを止めずにサーバを別のラックへ移動することに成功したので振り返る

こんにちは。lorentzcaです。 ⛺

先日データセンターにある20台ほどのサーバを別のラックに移し替えるという作業を行いました。無事サービスを止めずに作業を完了出来たので、どうやってサービスを止めずに作業を完了できたのか振り返ってみようと思います。

そもそもなぜサーバを別のラックに移動する必要があったのか

5月末に弊社の RSSSuite というサービスが終了しました。

その結果、ラック内に未使用のサーバがけっこうな数発生しました。そこで使っていないサーバや機器を整理して、可能なら契約しているラック数を減らそうという話になり、今回の作業を行う運びとなりました。

だいたい以下のような段取りで進めました。全体を通して2ヶ月ほどかかりました。

それぞれ振り返ってみます。

以下の項目について調査しました。

特にスイッチのポート数は重要でした。スイッチを移動する際は全てのポートが空いている状態で移動しなければならないので、 使えるスイッチ数 = 全スイッチ数 - 移動中のスイッチ数 となるためです。

調査後は調査結果とざっくりとした移行プランの候補を何個かまとめました。

理論上ラックの縮小が可能であることがわかったので、チームメンバーを集めて具体的な移行プランを詰めていきます。

今回焦点となったのは、「サーバやその他の機器をどのラックに集約するか」でした。以下の方針を元に話し合いました。

サービスに影響を出さない(ダウンタイムを発生させない)
なるべく作業を楽にしたい
ファイアウォールやスイッチなど、データセンターから借りている機器の移動はなるべく少ないほうが良い
- こちらでコントロールできる要素が多いほうが手順がシンプルで済みそう＆依頼して作業を待つという時間を削れるので

話し合った結果、移行プランは「ファイアウォールとL3スイッチがあるラックに集約する」ことにしました。

ファイアウォールとL3スイッチがあるラックにまとめた理由は以下の懸念があったためです。

L2スイッチと約20台の稼働中のサーバが移動対象となりますが、以前サーバの構成を大幅に変更し今回のような変化に強い構成にしたので、20台のサーバを移動することになってもサービスのダウンタイムは起こさないでいけるだろうと判断しました。

サーバの構成改善は例えば以下のようなことをしていました。

サーバの構成改善が無ければかなり厳しい作業になっていたと思います…。

ここまでで移行プランが具体的になってきました。このプランをデータセンターと共有していきます。

データセンターから借りている機器の移動が必要なので、データセンターとの連携が必要です。

データセンターの方をお招きして、移行プランの共有と事前に用意してあった「データセンターに聞きたいことリスト」を元に話し合いを進めました。インフラチームのリーダーにも同席してもらいました(心強い)。

データセンターに聞きたいことは以下のような内容でした。

また、データセンター側からはマネジメント機器のメンテナンスの都合上、どこどこのユニットに格納したい、といった意見も貰えました。

データセンターとの打ち合わせで不明点が全て洗い出せたので、具体的な作業手順書の作成が可能になりました。

下記のような内容の手順書を作成しました。

ロール単位(DBサーバ、LBサーバ等)で手順書を作成
どのスイッチの何番のポートに差し替えるかといった細かいことも書く
移動先のスペースに未使用サーバがある場合はどのように移動するか
ラックレールの取り外しはラックレールが上下に存在していると困難なので移動の順番も重要
- ラックレールに互換性がある場合はレールは外さないでサーバだけ取り外すパターンもありけり

ロール単位で手順書を分けたのは、ロールによって冗長化の仕組みが異なるためです。例えばLBサーバは keepalived で冗長化されているが、DBサーバは MHA で冗長化されている等。

基本的にはスレーブを先に移しマスターへ昇格させ、元マスターのスレーブを移動するといった流れです。クラスタリングされているロールはロードバランシング先から外して移動していきます。

この具体的な手順書の作成が一番時間がかかりました。検証環境で手順を検証したり、検証で新たな課題が見つかったり…。単純にロールが多くて大変というのもありました。

ロールによっては手順が大分長くなるので、社内メンバーが行う作業は作業者のアイコンをつけたり、問題が起きた場合のロールバック手順には 💉 絵文字をつけたりしました。意外にわかりやすくなるのでオヌヌメ。

f:id:lorentzca:20171026161108p:plain