どの企業でも起こり得る「仮想化」を巡る5つの課題 対処方法は？：「仮想化は完璧ではない」

仮想化には共通して発生する一般的な5つの問題がある。その効果的な対処方法を解説する。

[Stephen J. Bigelow，TechTarget]

　IT管理者は仮想化に伴う問題に対処しなければならないことが多い。仮想化に伴ってよく起きる問題には、仮想マシン（VM）のスプロール（無秩序な増加）、ネットワークの混雑、VMのパフォーマンス低下、サーバハードウェアの障害、ソフトウェアライセンスによる制限の問題などがある。

　サーバ仮想化は、システム使用率の大幅な向上、ワークロードの柔軟性向上などのメリットをデータセンターにもたらす。だが、そうしたメリットがあるとしても、完璧ではない。ハイパーバイザー自体に問題がなくても、仮想化に伴う問題によりリソースが浪費され、管理者が限界に追い込まれることもあり得る。

　仮想化で起こりやすい6つの問題を取り上げ、その効果的な対処方法を解説する。

1. 貴重なコンピューティングリソースを浪費するVMスプロール

　一定数のワークロードの仮想化を実現した後、新たなワークロードを追加するためにサーバの追加購入を余儀なくされることはあり得る。それは、VMの作成を計画または管理するためのビジネスポリシーを用意していないために起こる。

　仮想化が登場するまで、新たなソフトウェアシステムを立ち上げるには、まずサーバの予算を確保し、導入を調整する必要があった。新しいハードウェアを導入するまでには数カ月とはいわないまでも数週間の期間を要した。新たなワークロードをオンラインにすることは、当時のIT担当者やIT管理者が精査しなければならない大きな課題だった。

　仮想化環境では、ハイパーバイザーが数分で新しいVMを立ち上げることが可能になった。ハイパーバイザーには「Microsoft Hyper-V」や「VMware vSphere」などの製品に加え、十分な実績を誇るオープンソースの製品もある。

　とはいえ、VMが運用環境に導入されても、そのVMを誰が必要とし、誰が使用しているかを確認するデフォルトのプロセスはなく、監視も行われていないことがある。そのため、使用されなくなったVMが放置される可能性がある。放置されたVMが時間の経過とともに蓄積され、コンピューティング、バックアップ、障害復旧のリソースを消費し続ける。これは、未使用のVMに運用コストとオーバーヘッドがかかる「VMスプロール」という現象で、ビジネスに具体的な価値はもたらさない。

　VMは作成も破棄も簡単にできる。そのため、新しいVMが必要となる時点を把握し、VMを存続させる期間を定め、そのVMが新たなサーバとして妥当であることを正当化するためのポリシーと手順を用意する必要がある。ライフサイクル管理ツールを利用してVMを追跡することも検討すべきだ。VMを存続させるか破棄するかを決定できるよう、判断する日程と削除する期日を明確にすることも欠かせない。インフラ全体で稼働しているワークロードの使用率やパフォーマンスなどの指標を収集するアプリケーションパフォーマンス管理（APM）プラットフォームなどのツールも役立つ可能性がある。

　こうした取り組みは全て、稼働しているVMとそれを使用する部門、部署などの関係者を結び付けるのに役立ち、業務に必要なIT環境の量と、ITインフラの利用方法を正確に把握できるようになる。一部の企業では、利用したコンピューティングリソースに応じて事業部門に請求するチャージバック手法を採用している。VM料金の負担を求められる部門は、自部門のワークロードを細かく注意するようになるだろう。

2. 多数のVMが招く可能性のあるネットワークトラフィックの混雑

　ネットワークの混雑もよく起きる問題の一つだ。システム上の数値を定期的に監視している組織なら、例えばある1台のサーバが、25個のVMをホストするのに十分なメモリとCPUコアを持っていることが分かっているだろう。だが、25個のVMをサーバに読み込むと、サーバにネットワークポートが1つしかない場合、飽和状態になる可能性がある。飽和状態になれば、VMの通信に問題が生じ、ネットワークエラーを報告するVMや、パフォーマンスが低下するVMが生じかねない。

　仮想化が利用されるようになるまでは、通常、1台のサーバ上の1つのアプリケーションはサーバのネットワーク帯域幅のほんの一部しか使用しなかった。だが、仮想化が利用され、1台の仮想サーバ上に複数のVMが常駐するようになると、サーバ上の各VMがそれぞれネットワーク帯域幅の一部を必要とするようになる。

　ネットワークポートが1つしかないサーバなら、仮想サーバ上のネットワークトラフィックによってNICが飽和状態となりボトルネックが生じるまでにそれほど時間はかからない。ネットワークの遅れが直ちに影響を及ぼすワークロードでは、エラーが報告され、クラッシュが起きる可能性さえある。

　標準のギガビットイーサネットポートでは、複数のVMのトラフィックをサポートできる。だが、高度なVM統合を計画している場合は、適切なネットワーク接続を確保するため、サーバをアップグレードして、複数のNICポートを用意してNICとLANセグメントの帯域幅を増やす必要がある。トラフィック混雑の問題は、帯域幅を大量に使用するVMを複数のサーバに分散してワークロードのバランスを再調整すれば短期的に軽減できる場合がある。

　また、相互に通信することで帯域幅を大量に消費している2つのVMが別の物理サーバ上にあるならば、1台の物理サーバに同居させることでワークロードのバランスを再調整することも可能だ。そうすれば、VM同士の頻繁な通信が1台の物理サーバ内で行われることで事実上LANから取り除かれ、帯域幅を大量に利用するVMが引き起こすLANの混雑が緩和される。

　ただし、NICをアップグレードすることで、スイッチポートの追加やスイッチのアップグレードが必要になる可能性にも注意が必要だ。場合によっては、スイッチのバックプレーンが飽和状態になるのを避けるため、複数のNICのトラフィックの複数スイッチへの分散が必要になることもある。そのため、仮想化と統合への取り組みの初期段階からネットワークアーキテクトが関わり、監視する必要がある。

3. 統合によるハードウェア障害の拡大

　10個のVMが全て同じ物理サーバ上で運用されているとする。仮想化では、スナップショットなどのツールが用意され、VMが保護され、正常な状態での継続的な運用が確保される。だが、仮想化基盤となるハードウェアが保護されることはない。では、サーバ障害が起きるとどうなるだろう。これには「全部の卵を1つのカゴに入れるな」という昔からの格言が当てはまる。

　物理ハードウェアプラットフォームが単一障害点となり、そのプラットフォーム上で運用されている全てのワークロードに影響が及ぶ。統合レベルが高いほど、各サーバ上のワークロードが増え、サーバ障害で影響を受けるワークロードも多くなる。

　環境を適切に設計して展開すれば、影響を受けるワークロードをフェイルオーバーして他のサーバ上で稼働することは可能だ。だが、再起動中、ワークロードの可用性がある程度中断される。ストレージ内のスナップショットからワークロードを再起動するには、ディスクから利用可能なサーバのメモリにワークロードを移動しなければならない。

　移動するイメージのサイズとネットワーク上のトラフィック量によっては、復旧のプロセスに数分を要する場合もある。ネットワークが既に混雑していれば、別のサーバへのスナップショットの移動にさらに時間がかかるかもしれない。ネットワーク障害の状況によっては、全く復旧できないこともあり得る。

　サーバハードウェア障害とダウンタイムを減らす対策は幾つかある。短期的なら、重要なアプリケーションを1台のサーバに集中させないよう、ワークロードを複数のサーバ（場合によっては異なるLANセグメント）に分散できる。もしくは統合レベルを下げ、各物理システム上のワークロードの数を制限することも可能だ。

　長期的には、重要な統合プラットフォームを可用性の高いサーバに展開する。可用性の高いサーバとは、冗長電源や多数のメモリ保護テクノロジー（メモリスペアリングやメモリミラーリングなど）が搭載されているサーバを指す。

　可用性の高いサーバハードウェアのこうした機能は、障害を防いだり、少なくともその障害が致命的になるのを防ぐのに役立つ。最も重要なワークロードは、複数のコピーによって各ワークロードの同期が確保されるサーバクラスタ上に配置する。そうすれば、1台のサーバで障害が起きても、クラスタ内の別のノードがその処理を引き継ぎ、中断なく運用を継続できる。

　ITインフラエンジニアは、仮想化環境におけるハードウェア障害が及ぼす可能性のある影響を考慮し、障害発生前にその障害の影響を緩和するのに必要なアーキテクチャ、ハードウェア、ポリシーを実装しなければならない。

4. VMでもアプリケーションのパフォーマンスが限界に達する可能性がある

　例えば25年前に独自に作成した社内データベースサーバをVMに移行しようとすると、データベースのパフォーマンスが当時よりも低下することがある。あるいは、モダンなアプリケーションを仮想化しても、不安定になったり、速度が遅くなったりすることもある。VMでこうしたパフォーマンスの問題が生じる可能性は幾つかある。

　古い社内アプリケーションや自作の独自アプリケーションでは、効率を最大限に高めるため、具体的なハードウェア呼び出しをするようにソフトウェアをコーディングすることが多かったためだ。こうしたレガシーアプリケーションの多くは、単純なリフト＆シフト移行を進めると不安定になることがある。

　ハードウェアが変わったり、ハートウェアがアプリケーションから抽象化されたりすると、アプリケーションが正しく動作しなくなる可能性があり、コーディングのやり直しが必要になるのが一般的だ。

　単に、古いアプリケーションと仮想化との間に互換性がない可能性もある。その場合は、アプリケーションを更新するか、同様の機能を実行できる他の商用ソフトウェア製品かSaaSに切り替える必要があるかもしれない。あるいは、旧形式のアプリケーションを運用していた古い物理システムの運用継続が必要になることもある。だが、どの選択肢も、予算に限りのあるIT部門にとっては魅力的でも実用的でもない。

　仮想化後にモダンなアプリケーションのパフォーマンスが低下する場合、ワークロードの運用に必要なコンピューティングリソース（メモリ領域、CPUサイクル、CPUコアなど）が不足している可能性がある。

　このような場合は、ベンチマークユーティリティーを実行して、不足しているリソースを見極めて、コンピューティングリソースを追加でプロビジョニングすることで、リソースに余裕を持たせるのが一般的だ。

　メモリが不足すると、ディスク領域へのスワッピングが行われる可能性がある。こうしたディスクスワッピングはパフォーマンスを低下する。この場合、十分なメモリを追加してディスクスワッピングを防げば、パフォーマンスが向上する。場合によっては、パフォーマンスが低下しているVMを別のサーバ（恐らく新しいサーバか使用率の低いサーバ）に移行すれば、問題の解決に役立つこともある。

　問題が起きるのがモダンなアプリケーションかレガシーアプリケーションかには関係なく、仮想化をする前に検証環境でテストすれば、アプリケーションの仮想化が問題を引き起こすかどうかを特定するのに役立ち、VMを運用環境に展開する前に問題点を見つけて、仮想化に伴う問題を解決する方法を探る機会を得られるはずだ。

5. 仮想化環境でつまずきやすいソフトウェアライセンス

　ソフトウェアライセンスは混乱を招き高額になることが多かった。だが、ソフトウェアのベンダーは仮想化テクノロジーによって生じる問題に即座に気付き、仮想化によって生じるVM、複数のCPUなどのリソースのプロビジョニングに関する抜け穴を考慮して自社のライセンスルールを更新している。重要なのは、各VMで実行されるOSやアプリケーションのライセンスを購入しない限り、そのVMをコピーすることはできないということだ。

　組織は、導入するソフトウェアのライセンスルールを常に確認し、理解しなければならない。大企業の中には、ライセンスコンプライアンスの責任者を雇用し、ソフトウェアのライセンスを追跡して、仮想化などのソフトウェアの導入に関するガイダンスを提供しているケースもある。そうした責任者がいるのなら、そうした専門家の関与を求める。最近のシステム監視ツールでは、ソフトウェアライセンスの追跡とレポートの機能が含まれるものも増えている。

　ライセンス違反は、訴訟や多額の罰金につながる可能性がある。大手ソフトウェアベンダーの多くは、導入先を監査し、自社のライセンスを確認する権利を留保している。大半のベンダーは、特に初犯の場合、訴訟に持ち込むよりも、ライセンス料を確保することを考える。それでも、1つのライセンスに数千ドルが必要だと考えれば、不用意にVMを増やすと財務上大打撃を受ける恐れがある。