データセンター移転に伴う基盤最適化

こんにちは!システム技術部 基盤Grの新貝です。

今回は当社が取り組むデータセンター移転プロジェクトで実施した内容、そこで得られた知見を紹介します。データセンター移転や、基盤の最適化などを検討されている方に少しでもお力添えできる情報となれば幸いです。

1. 初めに

突然ですが、皆さん、「お引越し」と聞いて、まず何をイメージされますか?
「色々家に置きっぱなしだけど、今は忙しいから引っ越し日が近くなったらやろう。。」
「これ、思い出の品だけど、捨てようかな。。とっておこうかな。。」
「引っ越し先に入るかな。。」
若干、私的な経験であることはさておき、引っ越しを経験されたことがある方は、形は違えど、似たような経験をされたのではないでしょうか?

 さて、上記は個人の内容ですが、こちらがデータセンター規模になるとどうでしょう? 身内の恥をさらすようですが、移転元のデータセンター内には一部、創業初期から置かれているような古い基盤も存在している状況でした。 これは良くも悪くも新規サービスを追求していくという当社チャレンジ精神の中、古いサービスを捨てきれずに残存してしまった基盤が存在していたという実情がございます。 その中で本プロジェクトでは高度なセキュリティ、災害対策がとれた新しいデータセンターへの移転を推進していくこととなりました。また、当社では移転先データセンターにおいてヒューレットパッカード(HPE)社製の統合仮想基盤(Synergy)を用いた従量課金サービス(GreenLake)を利用(※2)します。
※2 HPE Synergy, GreenLakeは下記サイトから参照可能です。
https://www.hpe.com/jp/ja/integrated-systems/synergy.html
https://www.hpe.com/jp/ja/services/flexible-capacity.html

2. 課題

 前述の仮想基盤(Synergy)に当社のオンプレミスシステムを可能な限り統合できれば、今後、オンプレミス拡張、クラウド連携、用途に合わせ、柔軟に拡張できるハイブリッド環境の構築ができると考えられます。しかし、移転先データセンターへ移転する上では下記の課題がありました。

・移転元データセンターに比べて移転先の利用フロアが狭い関係上、当社で利用可能なラック搭載スペースが少ない

 上記課題が存在する為に、プロジェクト開始時に存在した移転元データセンター内の機器を何も考えずに全て物理移設することは出来ない状況でした。また、移転元にある古い機器を今後も管理し続けることは運用や管理のコストが今後も発生し続けることからもメリットはありませんでした。

3. 対応

3-1. 対応の流れ

 前述の課題に対応していく為に、本プロジェクトではまず、移転元にある全ての物理/仮想サーバの整理を行いました。その上で不要なサーバは廃止し、Synergy上に統合できる仮想サーバは統合していき、統合が不可と判断された機器はラック収容可能数の範囲内で物理移設をしていくこととしました。流れとしては下記の流れになります。
  (1) 移転元にある全ての物理/仮想サーバの整理
  (2) 不要サーバの廃止
  (3) Synergy上に統合できる仮想サーバの移行
  (4) 上記で対応できないような機器(パッケージシステム/アプライアンス製品など)は物理移設

3-2. 対応内容

前述「3-1. 対応の流れ」の内、このプロジェクトにおいてキーポイントであった上記(2), (4)で実施した対応を紹介します。

3-2-1. 【対応1】不要サーバ廃止の為の通信確認~廃止まで

 移転元の仮想基盤や、Windows ADなどを調べあげた結果、当社には物理/仮想サーバ全体で約2000台のサーバが存在することが判明しました。しかし、その全てが必要かというと不明瞭な状況でした。なぜならば、既に別のシステムへリプレースされたと聞いている機器もあれば、それは利用しているのでは?という人もいる状況。まだ有識者がいればマシな方で、かつて担当していた担当者が既に社内にいない為に利用状況が不明なサーバも存在しました。そこで不要サーバかどうかを判断する為に現在の利用状況を基盤観点で調べようという話になりました。
 ここで少し技術的な話をします。といっても、OS上で通信確認をされたことがある方ならば一度は触れたことがあるコマンドと思います。それは「netstat」コマンドです。このnetstatコマンド、案外便利なコマンドで、対象端末で実行することでどのような通信、プロセス利用が発生しているか調べることができます。これを対象サーバ内で確立している通信のみを抽出する場合、Windows系であれば下記のようなコマンドで確認可能です。
netstat -ano|findstr ESTABLISHED
 このコマンド出力結果は、その時点での通信状況になります。こちらをさらに、csv整形、DBインポートするように5分間隔で定期処理を行うことにより、複数日をまたぐ通信状況のサマリ結果を確認できる状態にしました。 概要図としては下記内容です。

f:id:k-shg:20210119183658p:plain
Fig1. Netstatフロー

 この手法はシンプルな手法ですが、シンプルな分、数多くのサーバに適応可能です。当社では最終的にはWindows系のみではなく、Linux系にも同様の手法を適用することで、通信確認が必要な全廃止検討対象サーバの通信結果をDB上で一元的にサマリ化することが出来ました。サマリ化することで見えたこととしては当社の場合、下記内容でした。
  (1) 約1~2週間分の通信サマリ結果で基本的な利用状況&廃止可否が判断可能
  (2) 業務系通信が存在する場合はアプリ担当者など別担当者への確認が必要
 対象サーバ通信が基盤管理系の通信(Windows ADやバックアップサーバなど)のみであれば、廃止による影響はほぼなく、OS停止を行なうことができました。しかし、対象サーバでアプリを用いて別サーバに対して不明瞭な通信を行う場合、別担当者と調整して対象プロセス利用の廃止、もしくは移行を検討する必要がありました。そうした対応を行った後でも不安なサーバは複数営業日においてNICを無効化し、問い合わせがないかどうかの無影響確認を行いました。その確認によって無影響が確認されたサーバはOS停止を行いました。地道な作業でしたが、そうしたサーバも含めると、約200台の物理/仮想サーバをOS停止させることができました。特に物理サーバのOS停止は移転プロジェクトにおいては大きな成果でした。物理サーバが稼働している場合、サーバ単体の収納スペースのみではなく、サーバによってはストレージやSANスイッチなどの別機器による占有も発生していました。 廃止していくことで不要になった保守&管理コストが削減されたことも今後の運用を考えた際に得られたメリットといえます。

3-2-2. 【対応2】P2V, V2V

廃止によって不要なサーバを削減したとはいえ、業務で利用する物理/仮想サーバの移行は検討が必要な状況でした。そこで、移転プロジェクトではP2V, V2V(※3)という技術を用いて移行を実施しました。
※3 P2Vは「Physical to Virtual」の略で、既存の物理サーバを専用のツールを使って仮想環境上に移行することです。また、V2Vは「Virtual to Virtual」の略で、仮想化プラットフォーム間で仮想マシンを移行することです。P2V, V2Vについてさらに知りたい方は下記サイトで参照可能です。
https://blogs.vmware.com/vmware-japan/2014/02/vi-p2v-v2v-migration1.html
しかし、移転プロジェクトを進めて間もない頃は当社側にもノウハウがないことから、下記の流れで実施しました。
  (1) L2延伸(※4)によって移転元&移転先データセンター間を同一NWとする
  (2) 基盤管理系の仮想サーバ(監視サーバなど)からV2V
  (3) 業務系のシングル仮想サーバをV2V
  (4) 業務系のクラスタ仮想サーバをV2V
  (5) 業務系のシングル物理サーバをP2V(P2V成功後にV2Vも実施)
  (6) 業務系のクラスタ物理サーバをP2V(P2V成功後にV2Vも実施)
※4 V2Vを行う上では移転元と移転先のデータセンター間が同一NW内である必要がありました。そこで当社では協力会社のご支援も得ながら、移転期間中はデータセンター間をまたいだ場合でも同一NWで通信できる環境を構築する為にL2延伸という技術を用いました。L2延伸を用いた際のP2V、V2Vイメージ図は下記の通りです。

f:id:k-shg:20210121204057p:plain
Fig2. P2V-V2Vイメージ図

NW環境を整えた後、上記のように段階的な移行を進めていくことで、万一の影響が出た場合も影響範囲の特定をしやすい形で進めました。特に業務系サーバの場合はお客様影響を出さないことは必須である為、関係者と調整しながら、細心の注意をはらって事前検証や、切替後の無影響確認を進めました。その結果、当社オンプレミスにあった大部分のサーバをSynergyへ統合することに成功しました。

4. 終わりに

 今回は移転プロジェクトで実施した内容、そこで得られた知見を紹介しました。 少しでも本ブログを読まれた方のお役に立てれば光栄です。 また、当社に少しでもご興味をもった方がいましたら、ぜひ当社で一緒に働いてみませんか?auカブコム証券では一緒に働く仲間を募集しています。私が所属している システム技術部 基盤グループでは、システム基盤のモダナイゼーションをミッションとし、走攻守を掲げ、「走:スピードに拘る」、「攻:最新技術に拘る」、「守:品質に拘る」ことをモットーに、オンプレミス・クラウド両基盤を提供しています。

採用についてはこちら auカブコム証券株式会社の会社情報 - Wantedly
https://www.wantedly.com/companies/kabu2