こんにちはももクロクラスター構築屋です。
今回は去年行なったデータセンター移設について書かせていただきます。
去年までは物理サーバのみでサービスを稼動させておりました。
しかし1ラックが既にいっぱいな状態なため、サービスの新規立ち上げや
サーバの増強を行なうにはサーバが置けない弊害が出来てきたのと
サーバ自体の老朽化・OSなどが統一されていない点など数々の問題点が出てきました。
その為、サーバのリプレイスではなく今後を見通して移設することにしました。
移設前の問題点
- OSが統一されていない
- サーバの老朽化
- ラックにサーバ追加ができない
- 物理サーバの場合は管理コスト上に調達に時間がかかる
- IP追加やネットワーク周りの変更が容易ではない
など
これらの問題を解決する必要があり、
サービスによっては今後スケールするサーバについてはクラウドにし、
DBやNFSなど核となるサーバは既存のサーバを利用するハイブリット構成での設計を行ないました。
これを実現する為にはまず、クラウド環境と物理サーバ環境のネットワークが
相互通信できるサービスを提供しているインフラ会社の選定が必要でした。
選定先の企業様は今回控えさせていただきますが、
上記の設計通り行なっていただく企業様と契約することができました。
見て分かるとおりシンプルな構成になっていると思います。
では、今回移設するために必要だった作業のポイントを紹介します。
移設の準備
現状の各サーバで動作しているアプリやミドルウェアなど
すべて洗い出す作業を始めに行ないます。
cronの調査
全サーバのユーザごとのcron設定を調査しました。
crontabの確認だけではなく/etc/cron.dも確認する必要があります。
シェルスクリプトの書き換え
cronやバッチ処理などで動いているシェルスクリプトについては
OSなどが変わる場合、コマンドの差異や環境変数の違いなどで
既存のバッチが動作しないことがあります。
その為、新規サーバの環境に合わせた修正とテストを行ないました。
ミドルウェアの設定ファイルをバックアップ
apache,munin,nagios,mysql・・・・・などの設定ファイルをバックアップ。
ただ、新規サーバに導入するミドルウェアのバージョンとリソースが同じ場合はそのままの設定を利用でも問題はないが、
OS変更やミドルウェアのバージョンアップなどを行なう場合はチューニングが必要となります。
サーバのリソース見積もり
全サーバのmuninなどから現在のリソース使用量の計測とアプリケーションの動作状況を確認し、新規サーバに必要なリソースを再計算し、リソースを見積もりました。
各サービス依存の調査
各アプリケーションがどのように依存しているかを調査する必要がありました。
いくつかの要因で依存している場合があるので調査漏れもおきやすい項目なので注意をして行なったところです。
- アプリケーション間がAPIなどで依存がある
- メールサーバなど停止が出来ない物がある
- ネットワーク機器の依存がある
など
各サービス同士がAPIで依存している場合ではAPI側を残し
呼び出している各サービスをまず移動します。
そしてAPI側を新しいDCで作成し、APIの向き先を
新しいDCに変更するなど移設方法を工夫する必要があります。
移設を１度で移行できないこともあり移設方法の決定において
依存の調査は重要なファクターになります。
ハイブリット構成で行なう設定
いろいろと構成する上で必要な設定はありますが、
今回は代表的な2つの設定について記載します。
wwwサーバ
クラウド上で仮想バランサーの設定を出来る機能があります。
今はほとんどのクラウドサービスで利用できますがその場合、
wwwサーバ側でIPのログを取るなどした場合、バランサーのIPになり本来の接続元のIPが記録されません。
その為にwwwサーバの設定を変更する必要があります。
※ご利用のクラウドサービスによって違いがありますので確認が必要です。
仮想バランサーの仕様によりますがhaproxyやハードウェアのロードバランサにてバランシングしている場合、 HTTPのヘッダにRemort-IPを残します。
X-Forwarded-For:client1, proxy1, proxy2
このヘッダから接続元のIPとしてログや接続制御する必要があり、
各ミドルウェアに応じて複数のモジュールが用意されています。
弊社でApacheの場合はmod_extract_forwardedを利用してます。
サーバ側のネットワーク設定
ハイブリット構成の場合は、クラウド側のネットワークと
ハウジング側のネットワークを相互に通信する必要があります。
その為には、上記のサーバ構成図のようにクラウド側の各サーバに
仮想NICが2枚必要になります。
行ないたい設定は下記のようになります。
NIC-Aではクラウド側のネットワークへパケットを送信
NIC-Bではハウジングのネットワークへパケットを送信
上記の場合、NIC-Aをデフォルトのネットワーク設定のままにし、
ハウジングへのパケットのみNIC-Bのデフォルトゲートウェイを
ハウジング内にあるL3スイッチに設定することで実現できます。
NIC-Bのインターフェースの設定
$ vi /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255
コマンドによるネットワークの設定
$ route add -net 10.0.2.0/24 gw 192.168.1.254
再起動後も設定が維持されるようにします。
$ vi /etc/sysconfig/network-scripts/route-eth1 10.0.2.0/24 via 192.168.1.254
設定後は、クラウド側の別サーバとハウジング内のIPに対してpingを飛ばし確認しましょう。
補足ですがNIC2枚構成で別ネットワークへ通信を行なう方法はハイブリット構成以外にも利用価値があります。
良くある構成としてクラスタリングでレプリケーションなど激しいトラフィックが発生する場合に、
ミドルウェア内の通信を別ネットワークで組み帯域やアプリケーション側からの通信を分離できる為、この構成を作ることがあります。
※クラウド上では同一ネットワークで作成される場合があるので要確認のポイントです。
サーバサイドの設定を伴うこの作業はベテランのインフラエンジニア＋新人などのインフラ初心者エンジニアなどで行なうと教育の面でとてもいいと思います。
この作業を通して、
不明なアプリが出てきたり、
今までの不具合の原因が究明できたり、
実はリスクになりえるポイントが見つかったり
経験豊富なエンジニアの視点や改善をインフラから
アプリの構成まですべて学べるからです。
※しっかり管理されていれば起きない問題ですが・・・
めったにないDC移設なので機会は少ないですが、
サーバのリプレイスなどでは良く行われる作業化と思います。
移設してみて
移設してから数ヶ月が経ちましたが、すでに移行した恩恵を得られており
特にネットワーク周りはWeb上で操作し、IPの追加やバランサーの設定など
即時に対応が出来る為、ネットワークで必要な作業を最少人数で回すことができています。
（移行前はISPにIP追加を依頼したり、DCに直接行きルータの設定を変更したりと手間が・・・
また新規事業のサービス立ち上げに対しても最小のコストでインフラを作成できる為、
スモールスタートとコスト管理がとても行ないやすいメリットが出ています。
ただし共有インフラに仮想サーバが乗っている物が多くインフラのキャパシティについては
まだ各社さん共に上限が決まっている物があるので、大規模なサービスになっていくと
フロントもクラウドでは受けれないことも出てくるかもしれません。
我々もそれに達するぐらいトラフィックを生む大きなサービスを作っていくことを目標にしていきたいと思います！
