サーバー仮想化でI/Oの問題が顕在化

ここ数年で、サーバー機の性能は、著しく向上しました。さらに、仮想化技術の進歩によって、1台のサーバー機の上で多数の仮想サーバーが稼働するようになりました。一方、サーバー環境のこうした変化によって、複数の仮想サーバーがI/O(データの入出力)を共有することによる、さまざまな課題が顕在化してきました。本

尾方 一成

2010年7月5日 20:00

ここ数年で、サーバー機の性能は、著しく向上しました。さらに、仮想化技術の進歩によって、1台のサーバー機の上で多数の仮想サーバーが稼働するようになりました。一方、サーバー環境のこうした変化によって、複数の仮想サーバーがI/O(データの入出力)を共有することによる、さまざまな課題が顕在化してきました。

本連載では、3回にわたって、仮想サーバー環境におけるI/Oの問題と、その解決策であるI/Oの仮想化について解説します。具体的には、(第1回)サーバー仮想化におけるI/Oの問題と、I/O仮想化が誕生した背景、(第2回)従来の物理I/OとI/O仮想化の違い、(第3回)Xsigo Systemsが提唱する、仮想I/Oによるクラウド型データ・センターの姿、について解説します。

ITシステムの歴史

まずは、ITシステムが現在のサーバー仮想化環境に至った背景をおさらいします。

1980年代は、メインフレームの全盛期でした。多くの企業が基幹業務にメインフレームを利用していました。メインフレームでは、マルチタスク処理のため、現在のサーバー仮想化のさきがけとなる仮想化OSを、複数同時に稼働させていました。さらに、論理パーティションと呼ぶ技術により、リソース(CPU、メモリー、I/O)を細かく柔軟に配分・変更できました。

1990年代に入ると、メインフレームよりも価格性能比で優れるということで、UNIXやWindowsといったオープン・システムが注目されるようになり、ダウン・サイジングの波が訪れました。これ以降は、オープン・システムを利用した分散システム、つまり、各拠点に分散設置したコンピュータが相互に連携するか、あるいは中央のコンピュータと処理を分担するC/S型(クライアント・サーバー型)の形態が主流となりました。

しかし、その後、長引く不況の影響でコスト削減要求が高まる中、分散化されたシステムにおいて、システム運用管理コストの大きさが問題視されるようになりました。分散システムでは、管理対象となるIT資源の数が増えてしまうので、必然的に運用コストがかさむのです。こうして、運用コストを削減するため、いったん分散化されたシステムは、再び統合化の道をたどることとなりました。

2000年代から2010年代と続くシステム統合化の流れの中で、CPUなどの進化により、サーバーが著しく高性能化していきました。かつてのサーバー機の数台から数十台に匹敵する性能が、たった1台のサーバーで得られるようになりました。こうして、余っているサーバー・リソースを有効に活用してサーバー利用率を高める手段として、再びサーバー仮想化の時代が訪れることになったのです。

図1: I/Oを取り巻く技術革新の流れ(クリックで拡大)

物理サーバー環境が抱える問題

以下では、現在におけるI/Oの問題を、サーバー仮想化以前の物理サーバーだけで構築されたシステム、および、サーバー仮想化技術を適用したシステム、それぞれについて見ていきます。

物理サーバーを用いた従来型のシステム環境は、多くの場合、図2に示すような3層型データ・センター・モデルで構築されています。Web層、アプリケーション層、データベース層です。

図2: 3層型のデータ・センター・アーキテクチャ(クリックで拡大)

こうした環境下では、個々のサーバー機は、サーバー機の役割に応じたアダプタ・カードを個別に搭載し、ネットワークに接続しています。例えば、データベース・サーバーであればSAN(ストレージ・エリア・ネットワーク)とアプリケーション層に、アプリケーション層のサーバーであればデータベース層とWeb層に接続しています。

このように、ネットワーク構成が物理的に分割されていると、セキュリティと可用性の面で有利です。なぜなら、ほかのサーバーが受けた不正侵入やDoS(サービス拒否)攻撃、アプリケーション障害などの影響を受けずに済むからです。

ところが、大・中規模のデータ・センターにおいては、このような3層型のモデルは「I/Oの問題」を増大させてしまいます。なぜなら、顧客やシステムごとにリソースを分離し、それぞれに対してパフォーマンスやセキュリティなどを確保しようとすると、何百から何千もの相互接続リンクを張る必要があるからです。

3層型のモデルを採用した従来型のデータ・センターでは、すべてのデータ・パスは、障害対策のために冗長構成をとっていなければなりません。ピーク時の負荷に対処できるだけの帯域幅を確保する必要もあります。この結果、莫大(ばくだい)な物理リソース、すなわちアダプタ・カードやネットワーク・スイッチ、ストレージ・スイッチ、加えて、絡み合ったケーブル配線が必要となります。

こうして、I/Oをとりまく環境には、以下のような問題が発生することとなりました。

融通が利かない
  • 各サーバー間の相互接続依存性が強く、構成変更が困難
  • 新しいI/Oリソースの割り当てに多くの時間を要する
  • ビジネス・ニーズの変化にシステム側が迅速に対応できない
コストが高い
  • I/Oインフラまわり(カード、スイッチ)のコストがサーバーのコストを上回る場合がある
  • システム・リソースの利用率が低い(アナリストの推定によると、業務で稼働しているサーバーとI/Oリソースの利用率は、平均15%以下)
管理が複雑
  • 単純な変更作業でも、複数チーム間で調整を図らなければならない

このように、ITシステムへのニーズが高まるとともに、サーバー環境にはさまざまな課題が生じ、抜本的な改革が必要になったのです。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30