第1回 仮想化サーバー統合への道

ネットワンシステムズ株式会社
ビジネス推進グループ技術本部
プラットフォームシステム技術部 PFチーム
宮下 徹

仮想化は難しい?

仮想化という言葉がずいぶんと浸透してきました。書籍やWebでも仮想化に関するものが多く見られます。ところが、実際に仮想化を利用してサーバー統合を実施したいと考えた際に、「1台のサーバーにどのぐらい仮想サーバーを立てることができるのか」、「既存のサーバーは仮想化環境でも動作するのか」などと悩む管理者も多いのではないでしょうか。

対象となるサーバーを把握することが、仮想化によるサーバー統合計画を遂行するうえで重要です。この一方、全社規模でサーバー統合を実施する場合、各部門に導入されているサーバーの情報を収集するのは非常に大変です。

また、どういった情報を収集するべきかも、悩ましい問題です。実装されているデバイスやインストールされているアプリケーション、さらには各種パフォーマンス情報など、あらゆる情報を収集すれば間違いないかもしれませんが、これらの調査が完了するまでに膨大な時間を費やします。最悪の場合、途中で挫折してしまう可能性も考えられます。

一方、収集する情報をしぼりすぎてしまうと、本当は必要な情報が取得できない恐れがあります。再調査を余儀なくされ、2度3度と繰り返し調査することにもなりかねません。何度も調査を依頼することになれば、各部門のサーバー担当者の負担はその分増えますし、反発も大きくなります。結果、統合計画が頓挫してしまうことも考えられます。

さらに、サーバーの情報がせっかく集まったとしても、「1台の物理サーバーにいったいどのぐらいの仮想サーバーを作っていいのか」、「仮想サーバーの組み合わせは適切なのかどうか」など、考慮すべき点はたくさんあります。
このように、仮想化によってサーバー統合を実施したいと考えていても、どのように進めればいいか分からず迷っている人も多いのではないでしょうか。
そこで、第1回では、上記のような悩みを解決する方策であるキャパシティ・プランニングと、実際にサーバーを移行する際の方法について解説します。

キャパシティプランニングとは?

まず、上述したキャパシティ・プランニングについて、簡単に説明します。キャパシティ・プランニングとは、既存のサーバー環境の情報を把握し、統合先となるサーバーのスペックに合わせて統合率を決定していくプロセスです。特に、既存のサーバー環境の情報をきちんと把握することが、もっとも重要になります。
簡単な例を以下に示します。

例: 過剰投資の防止

以下のような4台のサーバーがあると仮定します。

  • サーバーA: 3000MHz
  • サーバーB: 1500MHz
  • サーバーC: 500MHz
  • サーバーD: 200MHz

これらをそのまま統合して、単純に足し算してしまうと、合計5200MHzのCPUスペックが必要という計算になります。
ところが、既存のパフォーマンス情報を取得し、CPUの使用率が判明したら、どうなるでしょうか。仮にCPU使用率が以下のような場合、合計で830MHzあれば足りるという計算になります。

サーバーA: 3000MHz CPU使用率: 10% 必要MHz: 300MHz
サーバーB: 1500MHz CPU使用率: 20% 必要MHz: 300MHz
サーバーC: 500MHz CPU使用率: 30% 必要MHz: 150MHz
サーバーD: 200MHz CPU使用率: 40% 必要MHz: 80MHz

このように、現状分析をしておけば、過剰な投資を防止することができ、サーバー統合をより有効に実施することが可能になります。

現状把握は難しい?

複数のサーバーを仮想化で統合しようとした場合、それぞれの仮想サーバーに対してリソースをどのように割り当てていくかを検討する必要があります。上述した通り、現状分析は非常に大切ですが、実際にはどのような情報を取得すればよいのでしょうか。
基本的には、CPUの種類、スペック、搭載数、そしてメモリー量やディスク容量などといったインベントリ情報に加えて、CPU使用率、メモリー使用量、ページング数、ディスクやネットワークのI/Oパフォーマンスといった、稼働しているサーバーの性能を採取していくことになります。
したがって、サーバーの状況を手動で把握しようとなると、いくつものウインドウを立ち上げて確認する必要があります。

図1: 複数のウインドウを立ち上げてサーバーの状況を把握する

拡大表示

さらに、性能情報は、ある一定期間、できれば業務のピーク時に合わせて採取するのが理想です。最低でも2週間程度は取得し、平均とピークを見る必要があります。また、すべての性能情報を取得しようとすると情報量が莫大(ばくだい)になるため、サーバー統合に必要な部分を選出して採取する必要があります。
このような作業を、100台、あるいは1000台といった規模で実施するのは、非常に多くの工数がかかり、現実的ではありません。

そこで薦めたいのが、キャパシティ・プランニングに特化したツールです。市場には、さまざまなツールがあるので、要件に応じて選びましょう。有名なところでは、米VMwareの「Capacity Planner」、米Novellの「PlateSpin Recon」、米Microsoftの「Assessment and Planning Toolkit(MAP)」などがあります。
これらのツールは、基本的には既存サーバーに手を加えることなく情報を収集できます。エージェントのインストールや設定の変更、再起動といったプロセスは必要ありません。情報収集時に与える影響が最小限で済みます。また、キャパシティ・プランニングに特化して作られているため、サーバー統合に必要な情報を正確に収集することが可能です。

キャパシティ・プランニングに必要な情報を自動で収集する。
右図は、VMware Capacity Plannerを使用した場合の例

拡大表示

VMware Capacity Plannerとは?

本記事では、上記のうち、Capacity Plannerの有用性を解説します。

Data Manager

Data Managerは、実際に統合対象となるサーバーの情報を収集するソフトです。対象サーバーがWindows OSであればWMI(Windows Management Instrumentation)、Remote Registry、Performance Monitorを利用し、Linux OSであればSSHログイン経由で情報を取得します。いずれもOS標準の機能を使うため、対象サーバーに特別なエージェントをインストールする必要はありません。

Web Dashboard

Web Dashboardは、米VMwareがWeb上で提供しているDWH(データ・ウエアハウス)です。Data Managerが収集した情報が定期的にDWHにアップロードされるので、Web Dashboardを用いて、データを分析し、サーバー統合シナリオを作成します。
Web上のDWHですが、情報が漏えいするリスクは低いです。Data Managerは、SSL(https)を用いてDWHにデータをアップロードします。また、ログイン情報などのセキュリティ情報は、アップロード対象としては含まれません。

図3: Web上にあるVMwareのDWH「Web Dashboard」の仕組み

拡大表示

データ分析図

サーバーのデータを収集し終えたら、次は、そのデータをもとにサーバー統合のシナリオを作成します。具体的には、サーバーのスペックやOS、アプリケーション、パフォーマンスの情報を見極めながら、「1台のサーバーにどのぐらい統合していくか」を決定していきます。
理想は、それぞれピークの異なるサーバーを組み合わせ、ハードウエア・リソースをより有効に活用できるようにすることです。その際には、CPUやメモリーだけでなく、ディスク性能やネットワークの性能も考慮して、ボトルネックが発生しないように組み合わせを考えていきます。

図4: 異なるピーク時を組み合わせるのが理想

拡大表示

図5: 各種リソースを組み合わせて統合率を高める

拡大表示

これらを机上計算でやると、複数のサーバーの性能情報を見比べる必要があるので、大変な労力を要します。また、机上計算の場合、検討を実施するSEの経験やスキルによって、性能に対する見解や、どの程度の余裕を持たせるべきかの考え方などがバラバラになりがちです。
一方、キャパシティ・プランニング・ツールを用いると、情報収集ツール(VMwareの例ではData Manager)で採取したデータを基に、最適な組み合わせがどうなるのかを自動的に算出することが可能です。

引き続き、Web Dashboardの使い方を解説します。
Web Dashboardから参照できるDWHには、米VMwareが蓄積した大量のナレッジ(知識)がためこまれています。このため、最適な統合モデルを生成できるようになっています。

図6: Web Dashboardに蓄積されたナレッジを活用する

拡大表示

既存サーバー群のパフォーマンス特性やピーク時間、ピーク・リソース(CPU、メモリー、ディスク、ネットワーク)の違いを考慮して、どのように仮想サーバーを配置するかを適切に決定できます。ツールによってキャパシティ・プランニングが容易になるため、SEのスキルによる見解の違いも最小限に抑えられます。
実際にプランを作成する際には、ウィザードを利用します。ウィザードにしたがうだけで、どのぐらいのスペックのサーバーを何台用意すれば統合できるかを判別できるようになっています。おおまかな手順は以下のとおりです。

Step1.統合シナリオ名の入力

統合シナリオに対する任意の名前を入力します。

Step2.シナリオ・ルールの指定

x86、IA64などのアーキテクチャの違いを超えて統合するかどうか、既存サーバーを統合後に再利用させるかどうかなどのルールを決定します。

Step3.サーバー・スペックの指定

本シナリオで使用する移行先サーバーを指定します。Cisco UCSやDell Power Edge、HP ProLiantなど、各種のサーバーを指定することができます。また、それらを任意のスペックに編集することも可能です。例えば、あるベンダーのサーバーを選択した後、シナリオに合わせて搭載メモリー量を増加させることが可能です。

Step4.しきい値の指定

移行先サーバーのリソースに対して、しきい値を設定することができます。ここで設定したしきい値を必ず超えない範囲で統合シナリオは作成されます。例えば、CPU使用率を60%に設定した場合、1台のサーバーあたり60%未満になるように統合されます。
このように、ウィザードにしたがって各種パラメータを入力すると、移行先のサーバーに対して既存のサーバーをどのような組み合わせで仮想化して統合すれば良いかを判断し、統合シナリオを作成してくれます。
また、サーバー統合後の移行先サーバーがどのような性能状況になるのかを、現状の性能情報と、統合するサーバーのスペックを基にシミュレーションすることが可能です。これにより、サーバー統合後の負荷を視覚的に把握でき、業務や運用形態に合わせて統合シナリオを作成することが容易になります。

図7: サーバー統合後の、移行先サーバーの性能状況

拡大表示

また、CPUやI/Oの利用率が激しいといった理由で仮想化に向かないサーバーは、統合シナリオから外されます。

図8: 仮想化に向かないサーバーを排除する

拡大表示

サーバーの移行

サーバーのキャパシティ・プランニングが完了した後、最後に実施するのが移行作業です。このフェーズでも、専用の移行ツールを使用することによって、既存のアプリケーション環境を変更することなく、仮想サーバーへと移行できます。
移行ツールを使用することにより、短期間で既存の環境をそのまま移行できます。このメリットがある一方、移行が必ずしも保証されるわけではない(失敗する可能性もある)という課題もあります。このため、新規に仮想サーバーを作成し、そこに既存サーバーのデータを移行するという選択も視野に入れる必要があるでしょう。
具体例として、筆者が所属するネットワンシステムズが実施している、VMware vSphere環境への移行方法を紹介します。VMware Converterという移行ツールを使用して、2種類の移行方法を採用しています。(1)Converter Boot CDを使用したオフライン・クローニングと、(2)Acronis Backup & Recoveryを使用したクローニングです。

図9: VMware vSphere環境への移行方法

拡大表示

実施する環境によって変更することもありますが、基本的には以下のような手順で移行を行います。

Step1.

キャパシティ・プランニングの結果などから、仮想化に向かないデバイスやアプリケーションがないかを事前に確認します。

Step2.

VMware vShpere環境を構築します。

Step3.

移行対象サーバーをシャットダウンし、既存のLAN環境から移行用のLAN環境に切り替えます。

Step4.

移行対象サーバーにConverter BootCDを挿入し、起動します。起動後は、移行ウィザードにしたがって、Step1で構築したvSphere環境に仮想サーバーとして移行します。環境によっては失敗する可能性があるので、その際にはAcronisを使用した方法を実施します。

Step5.

移行が完了した後、必要に応じて仮想サーバーに対して作業を実施します。

  • 仮想CPUの割り当て数の変更
  • 仮想メモリーの割り当て量の変更
  • 仮想NICの割り当て、VLANの設定
  • ゲストOS固有の情報の変更
    ・IPアドレス
    ・コンピュータ名
    ・SID
  • VMware Toolsのインストール
  • 使用ドライバの確認
  • ログ(イベントログなど)にエラーがないか確認
  • 新旧サーバーのデータを同期

まとめ

サーバー統合の際にキャパシティ・プランニングが重要になる点を理解いただけましたでしょうか。キャパシティ・プランニングによって既存環境の棚卸しができるため、サーバー統合を最適なかたちで実施できるほか、統合後の運用も効率良く行えるようになります。
ただし、実際にサーバー統合を実施する時には、場合によってはネットワークの統合やストレージの統合も合わせて考えていく必要があります。仮想化製品だけでなく、ネットワークやストレージにも強いSIパートナと協力してプロジェクトを進めていくことを勧めます。

Webからのお問い合わせ、ご質問はこちらから
お問い合わせ窓口へ

関連イベント・セミナー

10/10-12 EMC Forum 2012出展のお知らせ
この度弊社では、10月10日(水)~12日(金)、東京ビックサイトにて開催される「IT Pro Expo 2012」のEMC FORUM 2012に、ゴール
11/6-7 vForum2012出展のご案内
この度弊社では、11月6日(火)~7日(木)、ザ・プリンスパークタワー東京にて開催される「vForum2012」にプラチナスポンサーとして出展する運
10/24~26 「Cloud Computing EXPO 2012」出展のご案内(EMCブース内出展)
この度弊社では、10月24日(水)~26日(金)、幕張メッセで開催される「Cloud Computing EXPO 2012」内EMCブースにて、スポンサー

イベント/レポート

pagetop