サーバーとデスクトップを同時並行で仮想化、成功の秘訣は？

システム企画グループ 第2システム部 部長の土屋雅春氏

プロジェクトの全体概要

　ネットワンシステムズ株式会社（以下、ネットワン）は、業務基盤の改革に向けて、全社を挙げて社内IT基盤の仮想化プロジェクトに取り組んでいる。通常、仮想化プロジェクトは、サーバーの統合から着手し、デスクトップ仮想化へと段階的に行われるケースが多いが、同社の事例では、サーバー・ストレージの仮想化・統合と仮想デスクトップ環境の構築、さらには統合運用管理システムの導入をほぼ同時並行で進め、大きなトラブルなく本番稼働を実現した点に注目される。

　システム企画グループ 第2システム部 部長の土屋雅春氏は、今回の仮想化プロジェクトの背景について、「いつでも、どこでも、誰とでもコミュニケーションや情報共有ができる、新たな業務基盤の実現に向けて、社内システムインフラの仮想化は大きな課題となっていた。当初は、サーバー仮想化とデスクトップ仮想化を同時に進める計画ではなかったが、業務基盤の改革という目標の下で、2008年ごろからそれぞれのプロジェクトが動き始め、全社的な仮想化プロジェクトとして、自然発生的に同じタイミングで立ち上がった」と話す。

　では、まずはサーバー・ストレージの仮想化・統合への取り組みから詳しく見ていこう。

　サーバー統合前の同社のシステム環境は、本社、各拠点、データセンターそれぞれに物理サーバーや人材が分散しており、さまざまな問題を抱えるようになっていたという。「特に本社のサーバールームは、サーバー台数の増加に電源容量が間に合わなくなり、セキュリティ強化の意味も含めて、順次データセンターへの移設を進めていた。しかし、その移設先のデータセンターでもラック数に限界が近づきつつあり、物理サーバーをさらに増やすことは難しい状況になっていた」と土屋氏は当時を振り返る。

　そこで、同社の進める仮想化プロジェクトの一環として、増大し続ける物理サーバー・ストレージを仮想統合し、現在利用しているデータセンターのラック数にすべて集約することを目指した。2008年後半からサーバー・ストレージ仮想化に向けたグランドデザインに着手し、2009年4月からフェーズ1、2010年4月からフェーズ2という2段階で構築が進められた。

サーバー仮想化の背景と目的	実施スケジュール

　仮想化システムの構築にあたっては、販売システムや物流システムなどを含む業務系と、認証システムやポータルシステムを含む情報系、そしてメール系の3つの用途別に、完全にシステムを切り分けたという。

　業務系と情報系では、それぞれサーバー「HP BladeSystem C7000」1台、ストレージ「EMC CLARiX CX4」1台で構成される仮想化システムを構築。一方、メール系の仮想化システムは、サーバー「HP Proliant DL380 G6」4台、ストレージ「NetApp 3170」2台で構成され、ストレージはシンクロミラーリングが行われているという。本番稼働のタイミングは、業務系システムが2010年1月、情報系システムが2010年2月、メール系システムが2010年4月となっている。

業務系と情報系の仮想化システム構成	メール系の仮想化システム構成

　土屋氏は、システム実装時のポイントについて、「従来のシステムでは、各システムごとにOracleデータベース環境を用意し、契約形態もバラバラだったが、新システムでは分散されていたサーバーを集約することで、統合データベース環境を実現した。また、ストレージに関しては、従来は統合ストレージ利用システムと、独自に用意したシステムが混在していたため、ストレージの使用率がアンバランスだった。新システムでは、ストレージ統合の推進とシンプロビジョニングの活用によって、全体の使用率に合わせて動的なボリューム拡張が可能になった」と説明している。

　さらに、システム実装において、一度にすべてのサーバーを移行するのではなく、段階的な移行を行うことで、サーバー集約率の向上を実現している点も見逃せない。「まずは、設計時点の半分程度のシステムを移行し、稼働させた。この際、規模が大きい割にトランザクション数が少ないシステムを優先的に移行させたのがポイント。その後、3カ月程度かけて、リソースの利用状況を見ながら、残ったシステムを移行していくことでサーバー集約率の確保に成功した」（土屋氏）という。

サーバー仮想化に合わせて統合データベース環境も実現	各システムのデータも統合ストレージへ移行

　同社では、今回のサーバー仮想化によって、統合前のシステムと比較（2011年3月末時点）して、ラック本数を16本相当から6本相当（62％削減）、ラックユニットサイズを328ユニット相当から83ユニット相当（86％削減）、DBサーバーを12台から2台（83％削減）、消費電力を7万w相当から1万3500w相当（81％削減、カタログ値から推測）へと、大幅な削減を実現した。また、データセンターの空き容量が増加したことで、システムのリプレースも新たなデータセンターを使わずに行うことが可能となった。

　このほか、統合前に比べて、システム基盤環境の引き渡しまでのリードタイムも短縮。「これまでは引き渡しまで2～3カ月は必要だったが、統合後は1～2週間程度で引き渡しが可能になった。実際に、システム基盤の依頼を受けてから、わずか8営業日で引き渡しをした実績もある」（土屋氏）と、すでにビジネス面でもサーバー仮想化の効果が発揮されているようだ。

サーバー仮想化による削減効果	システム基盤環境引き渡しまでのリードタイム短縮効果

　大きなトラブルなく、順調に進められたように見えるサーバー・ストレージ仮想化プロジェクトだが、「計画と実際の実行段階では、いくつかのギャップも出てきた」と土屋氏はいう。例えば、計画段階では、業務系システムの移行は検証サーバーを一通り実施した後、本番系の移行を行う予定だったが、OS環境の変更（SolarisからRHELへ）によりソースコードの二重管理が発生し、運用に大きな負荷がかかるため、システム単位で本番・検証を同時に移行することになったという。

　また、当初、業務系システムの移行は2009年11月を予定していたが、データベース障害の発生によって2010年1月にずれ込むことになった。「これは、新しいアーキテクチャを採用した製品を使用したことによる、ファームウェアの不適合が原因だった。今後はファームウェアなどの制御関係のソフトウェアについても精査し、適用することでリスク低減を図る必要がある」（土屋氏）としている。

計画と実際の実行段階でのギャップ。OS環境の変更によりソースコードの二重管理などが発生しかねなかった	新しいアーキテクチャを採用した製品を使用したことによる、ファームウェアの不適合なども発生

　今後の課題については、「リソース効率化のためのクラスタの集約」と「担当者連携の重要性と、仮想化環境のコーディネータの必要性」の2点を挙げる。土屋氏は、「できるだけクラスタリングの構成を大きくして、業務グループを集約することでリソースの効率化を図ることができる。また、統合後は、仮想化独特の運用課題が発生するため、仮想化環境全体を見ることができる“コーディネーター”を新たに設置する必要があるだろう」との考えを述べた。

今後の対応。クラスタを集約することで、クラスタごとに用意する障害用予備サーバーの台数を減らし、有効活用できるようにする	仮想化環境のコーディネーターの必要性にも気がついた

　次回は、デスクトップ仮想化への取り組みなどを紹介する。こちらも全社展開に向けて、段階的に進める大規模な事例だ。ここでさまざまなメリットと足りない点が見えてきたという。それらを紹介するとともに、仮想化に対応した統合管理環境の整備の話にも触れていく。