・講演内容       PDF版 はじめに 既存システムについて サーバ更新計画 これからのサーバ環境 まとめ 　　　　　　　 参考文献 ・プレゼンテーション資料

東京電機大学 総合メディアセンター 橋本 明人

　TCO削減は常に重要な命題である。サーバの台数・設置環境はTCOに対し大きな影響を及ぼす。要求されるサービスの増加および、冗長構成によるサーバ多重化によりサーバ数は増加の一途をたどる傾向にある。サーバ仮想化技術をこれらの環境に適用することにより物理サーバの削減が行えると考え、東京電機大学ではVMware ESX Serverを用い約40機のサーバを12機に削減することに成功した。
　本稿では、あまり実例のなかったサーバ仮想化技術導入までの道のりからその移行手段、そしてサーバ仮想化技術の実用性について実例を交え紹介を行う。

サーバ仮想化、サーバ集約、導入計画、TCO削減

1.はじめに

　サーバを取り巻く環境は時代とともに変化している。メインフレームによる集中型計算環境からワークステーションをネットワークにより相互接続した分散型環境への移行が急激に進んだことは記憶に新しい。しかしながら、分散型環境では業務ごとにサーバを設置することが多くサーバが乱立する傾向にある。サーバそのもののコストは低下したが、台数が多くなりすぎたため保守や管理のためのコストが増加した。メインフレームへ回帰すれば良いのかもしれないが依然高価であり、またそれそのものの文化が異なり、回帰する組織は限定的である。
　サーバに目を向けてみると、CPUやメモリなどの計算機資源が十分に使用されることは希で資源が余っていることが多い。サーバアプリケーションではサーバ全能力の5%程度しか使われていないケースも多い。低負荷のサーバアプリケーションをまとめ1台のサーバで動作させることができれば計算機資源の利用率向上が期待できる。
　約30年前にメインフレームで実装された計算機仮想化技術[1]があるが、近年一般的に使用されているサーバ*1でこれら計算機仮想化を実現する技術が開発され、実業務に使用可能な品質を持つに至った。計算機仮想化技術を用いることにより1台のサーバ上で複数のサーバOSを動作させることが可能となり、その結果として資源利用率の向上が現実的になった。
　本稿では、計算機仮想化技術を実現するVMware ESX Serverを実際の業務に使用し約40機のサーバを12機へと削減した事例について、移行の計画立案を中心として解説する。
-----
*1 Intelのx86やx86_64アーキテクチャのサーバ

2.既存システムについて

　本稿はサーバ集約・サーバ仮想化技術が主要なテーマである。これらは2006年度に行われた定期的なシステム更新において用いられた技術である。
　2006年度のシステム更新計画は、2001年度導入システムの運用結果から導き出されているため、本節では2001年度導入のシステムについて概要を説明する。

2.1 2001年度サーバ基本構成
　2001年度に更新したサーバはアクセス・サーバ・ストレージの3層で構成されていた。Server Load Balancer(以下SLB) を用いユーザアクセスが仮想化されていた(詳細は2.1.2 節)。
　1台のサーバが持つ演算・I/O 能力はサーバプロセスが必要とする能力と比較し十分大きかったため、1台のサーバ上で複数のサーバアプリケーションを実行した。

2.1.1 2001年度サーバの種類と台数
　実機台数では全37機。これらの計算機上で表1に示されるようなサービスを行っていた。

表1 サービスの内訳

　実機よりサービス数が多い理由は、図1に示す通り、1台のサーバでサービス範囲の異なる複数のサーバアプリケーションを実行しているためである。

図1 単一サーバ複数プロセス

　1台のサーバ能力が1サーバアプリケーションの能力よりはるかに大きいと判断したためこのような構成とした。サーバリソースを適切に使用するための考え方であり、仮想化につながる考え方となっている。ただし、サーバアプリケーション間の分離が不十分であるため*2不特定多数でサーバを使用した場合などセキュリティ面での課題が存在した。
-----
*2 当時サーバでのOS 仮想化技術は一般的でなかった

2.1.2 2001年度サーバ構成の特徴
　それぞれのキャンパスに図2に示される構成のサーバ群が配置されていた。図2はユーザからのアクセスはすべてSLBが受け取り、設定に基づき実サーバへ通信をディスパッチする構造となっている。SLBは負荷分散装置として用いられるケースが一般的であるが、本学の構成では負荷分散・冗長性確保および特にディスパッチャとして捕らえている点が重要である。

図2 サーバ構成の模式図

　本構成を採用することによりユーザからのアクセスとサーバを切り分けが可能となった．このことはアクセス層の仮想化と言っても過言ではないと考える。

2.2 2001年度サーバの問題点
　2.1で述べたように現システムへ継承される特徴をもったサーバシステムであったが、いくつかの問題点が存在した。

機材が多い

　図2に示す形の機器が3拠点に設置されていた。SLBやストレージ、バックアップ機構は高価ですべての拠点で同じような使用方法をとっているため1つに集約するメリットが高い。サーバに関してもDNSキャッシュのようなサーバは3拠点で共用が可能と考えられた。

分離度が低い

　図1で示したように、複数のサービスを供給するサーバアプリケーションが1つのOS上で動作している。あるサーバアプリケーションに対する設定の影響がその他のサーバアプリケーションに影響を及ぼす可能性がある。

構成の自由度が低い

　新規サービスを開始させる場合、サーバアプリケーションが他に与える影響を考える必要がある。また新規サービスの導入作業が他のサーバアプリケーションに影響及ぼす可能性もある。

　これらの問題点を解消すべく「サーバ集約」「サーバ仮想化技術」について検討を行うことになった。

3. サーバ更新計画

　2006年度に基幹ネットワーク設備の更新を実施した。これは、5年周期で実施している定常的な更新である。設計方針として、2001 年度に更新されたシステムのブラッシュアップという位置づけをとった。
　2001年度の更新は主に大学全体のネットワークトポロジをリング形状のものからスター形状の物へ変更したということもあり、ネットワークに更新が重点的に行われた。しかしながら、サーバシステムに関してもSLBを主要箇所に用いたサーバ構成を行う等、サーバ設備に関しても新しい試みを実践している。
　2006年度更新は、重点事項として次のような項目が挙げられた。

システム機能毎独立性の強化

　キャンパス内のネットワーク、キャンパス間のネットワーク、対インターネットのネットワークなど複数の構成要素が互いに干渉しないようなトポロジ・機材構成を目指した。

データセンタ機能の仮想化・集中化

　複数拠点に分散設置されていたサーバを1拠点へ統合し、さらにサーバ仮想化技術を用いることによりサーバ台数の削減を狙った。

マネジメント機能の強化

　機器設置場所に関係せずどこからでもそれら機器の状況を把握しコントロールできることを狙った。

二重化の促進

　既にサーバは冗長構成であったが、ネットワークの重要部分に位置する装置が冗長構成ではなかった。これら装置の故障や作業による停止での影響範囲が非常に大きかった。これらを改善する事を狙った。

DoS 対策

　機器の故障などよりもDoS に該当する通信による障害率が高かったため、これらを自動的に排除する方法を検討した。

　将来的にサーバ設備を大学外に設置することを考えている。今回の更新においてサーバシステムをパッケージとしてとらえた構造*3を取った。サーバ設備を大学外に設置した場合と近い状態を作り出すことができ、将来的に必要となると思われる運用技術の蓄積が出来ていると感じられる。
-----
*3 電源とネットワークを接続することで機能する。

3.1 サーバ集約
　サーバ集約を行うことにより2.2 節で述べた「機材が多い」という問題が解消された。SLB、ストレージ、バックアップ機構、サーバ接続用スイッチに費やす機材が約1/3 になる。サーバ接続用スイッチは2重化されていなかったが、集約により機材取得コストが圧縮されたことにより全ての部分の2重化が可能となった*4。
　サーバ集約はキャンパス間の接続環境が高信頼高速化されたことによる。キャンパス間の接続は表2で示すように時代と共に様々な方式を採り入れ接続速度が増加されている。

表2 キャンパス間接続帯域推移

　2001年度の時点では現在と比較し十分な帯域を確保できずサーバを1拠点に集約することなど考えられなかったが、2006年度では十分な帯域が確保できたためサーバ集約を実施することとなった。
-----
*4 バックアップ機構は1重である。

3.1.1 集約でのネットワーク
　一部のサーバ*5はIPアドレスが変更されると望ましくないことがある。ユーザに対する周知や変更されたアドレスを設定し直すといった作業が必要になる。ユーザにかかる負担が高くなるし、間違えた設定をされて結果ネットワークが使えなくなったというクレームも発生しうる。
　3拠点ではそれぞれ拠点に割り当てられたアドレスにサーバが配置されていた(図3)。

図3 移行前のサーバネットワーク

　サーバ専用ネットワークだったため、1拠点にサーバを集約する際ルーティングを適切に行うことでそれらサーバ専用ネットワークをすべてデータセンタへそのまま移動をした(図4)。

図4 移行後のサーバネットワーク

その結果、特にユーザに対する通知を行うことなく*6集約が完了した。
-----
*5 特にDNS サーバ。
*6 tracerouteなどを行うユーザは気づいていると思われるが。

3.2 サーバ仮想化技術の選択
　機材更新は5年周期で実施される。その間機材の更新は行わないという前提がある。システムが陳腐化しないよう導入時に次の更新時期のトレンドを予測しシステムを設計する必要がある。設計を行うにあたり、5年後に標準となると思われるサーバ環境を予測した。
　Web2.0というキーワードの一般化でわかるように、今後新しいサービスが次から次へ登場することが考えられる。これはサーバ数の増加につながると考えられ、増加するサーバ設置要求に対し柔軟に対応できるソリューションが必要であるとされた。
　2.2 節に挙げられている「分離度が低い」という問題はそれぞれのサービスが別のOS上で動作することで解決可能であると思われた。
　1台のサーバを任意の台数に見せる技術が理想的であると判断し、結果サーバ仮想化技術製品を採用することとした。

3.2.1 仮想化ソフトウェアの選択
　本システムで動作させるサービスは十分安定して動く必要があり、仮想化ソフトウェア自体のサポートが必要不可欠である。
　動作するOSに関しては、ソースコードを入手できるとは限らないためOSに手を加えずとも動作させることが可能な完全仮想化のものが理想的であった。
　結果として2006年度に稼働させるシステムに適切な仮想化ソフトウェアの選択肢はVMware ESX Serverのみとなったため、それを採用した。

3.2.2 仮想サーバのサイジング
　想定しているサービスがサーバ仮想化環境で十分な性能で動作するため、ディスク容量や実計算機の台数を決定する必要がある。
　一般的にはベンダーはそのサイジングを適切に行い必要なハードウェア数量を決定した提案をすることをセールスポイントとしていることが多い。
　本システムの場合、実計算機の台数やディスク容量の設定は厳密に行っていない。必要と思われた台数*7より多くの実計算機を導入することとした。
　仮想化環境で動作させることが難しいアプリケーションを動作させる必要が発生した場合、該当アプリケーション用に仮想化ソフトウェアを取り外し使用すれば良いのでは無いかいう考えによる。
　新規サービスを投入しようという考え方もあるため、結果として十分余裕をもった実計算機とディスクを用意した。余裕を持たせた構成としたためリスクの回避も同時に行えたと評価できる。
-----
*7 8台で十分と想定したが、実計算機を12 台導入した。

3.3 導入後
　筆者の所属する総合メディアセンターでは2005年3月下旬から2005年9月上旬にわたり、システムの基本設計を行い、その後パートナーの選定を実施した。仮想計算機周辺の基本設計は、VMware Communities Web ページ[3]を、ネットワーク周辺の基本設計はCisco Systems Enterprise Data Center [2]でのWhite Paper、Design Guideをそれぞれ参考とした。
　システム構築は2006年5月上旬から選定されたパートナーによって行われ2006年9月に稼働開始した。
　現時点でシステム稼働開始から1年以上経過するが、仮想計算機上で動作しているサーバOSやアプリケーションの設定不備による障害は発生したものの、仮想計算機・集約が原因と思われるトラブルは発生していない。
　サーバ仮想化によってシステムを構築することによる運用効率向上の恩恵を受けている。運用者の感覚的な事項なので具体的かつ客観的な数字を示すことはできないが、サーバ管理に必要とされていた時間の20〜30%程度は削減できたのではないかと感じられる。
　しかしながら、仮想計算機上に新たにサーバを立ち上げることが比較的容易なため、サーバ台数*8は増加してしまい、これらのサーバ管理にかかるコストが増加することになった。
　サーバ仮想化は過去ハードウェアに関連していた管理項目の劇的な省力化を実現することは可能であるが、仮想計算機上で動作しているサーバ管理に関しては別手法をも併用する必要があるということに注意する必要があると考える。
-----
*8 仮想計算機上で動作しているサーバ、ゲストOS。

4.これからのサーバ環境

　1節で述べたように、以前は担当業務ごとにサーバハードウェアの導入が一般的であり、その結果サーバの乱立を招いた。
　サーバ仮想化技術を用いたサーバ環境の場合、仮想化技術により管理された大きい計算機資源を切り分けて業務ごとに充てる考え方になると思われる。つまり、「1システム=1ハードウェアシステム+ 業務アプリケーション」という図式は成り立たなくなると言える。
　著者らは、仮想計算機環境下である業務アプリケーション*9を稼働させることを計画したが、ソフトウェア供給会社からは技術的な理由*10の説明がないまま、サポートを拒否されるケースに遭遇している*11。
　昨今のトレンドでは、サーバ仮想化技術は今後一般化すると感じられる。サーバ仮想化技術を用いたサーバ環境が一般化した場合、旧来の「1システム=1 ハードウェアシステム+業務アプリケーション」という考え方から脱却できないベンダーは淘汰される危険性の可能性を感じずにはいられない。
-----
*9 富士Xerox 社のプリンティング総合管理ソフトウェア
*10 例えば「I/O性能が十分でないので製品品質を保証できない」といったような技術的な理由。
*11 「動作保証をしない。」ではなく「一切サポートしない。」といった内容。

5. まとめ

　本稿では、東京電機大学におけるVMware ESX Serverを用いたサーバ統合について説明した。当時あまり事例を見なかったサーバ仮想化技術を全面的に用いたサーバ統合であったが実際に行ってみると、非常に簡単かつ効果的であった。
　システム管理者の視点からみて、サーバ仮想化は単なる一時的な流行ではなくパラダイムシフトであると感じられる。

6.参考文献

[1]	VMware Inc. 仮想化の歴史. http://www.vmware.com/jp/overview/history.html (2008/1/18).
[2]	Cisco Systems Inc. Enterprise Data Center. http://www.cisco.com/en/US/netsol/ns340/ns394/ns224/networking solutions packages list.html(2008/1/18).
[3]	VMware Inc. Communities Overview. http://www.vmware.com/communities/content/ (2008/1/18).