仮想化すべきでない10の理由(via Trend Cloud Security Blog)

Trend Cloud Security Blogの昨年末の連載記事で、「システムを仮想化しない理由」がまとめられていました。

内容は、仮想化するかしないかの参考にするというよりも、「システムを仮想化しようと考えたときに対応を検討する必要があるもの」という観点で見た方がよい感じでした。

覚書きを兼ねてメモしておきます。

導入

仮想化とプライベートクラウドによって、サーバの集約、より柔軟な環境の作成、多額の費用削減が成し遂げられてきました。

仮想化は素晴らしいものです。

とはいえ、仮想化は万能薬ではありません。トレンドマイクロが最近実施した、500人以上の従業員を抱える1200社に対する調査では、59%のサーバがプロダクション環境あるいはパイロット環境で仮想化されていました。しかし、私(※ブログ執筆者)は、あなたがアプリケーションを「仮想化しない」ことを考えてみるべき10の状況を、この連載で解説します。この話は、大企業とサービスプロバイダでの10年間の仮想化の経験と、2大仮想化ベンダーの1社のために戦略計画を実行してきた経験に基づいています。

10の状況

1. コンピューティングリソースのニーズが静的で予測可能である場合

この場合、おそらくすでに管理され安定している環境を仮想化することになり、得られる利益は少ないでしょう。複雑さとダウンタイムを新たに持ち込むだけです。ただし、その安定した環境が古く、すでにサポートされないOSを要求している場合は別です。その場合は、移行コストと複雑さを受け容れ、何としてでも仮想化するしかないでしょう。

これはどうでしょう。コンピューティングリソースがelasticであることの他にも仮想化のメリットは存在するので、全体のバランス次第だと思います。

まあ、この文章から読み取るべきは、「古いOSを使っていて、かつハードが近々リース切れするシステムを狙い撃ちで仮想化せよ」というメッセージかもしれませんが。:-P

2. 仮想化と親和性の高いライセンスを利用できない場合

仮想マシンでのサポートがない特殊なソフトウェアを使っている場合は難問です。ベンダーに告げずに仮想化することはできても、不便な上に、おそらく違法です。何にせよリスクを冒すことを意味します。(後略)

この項目は、10の状況の中で最も分かりやすく妥当だと思いました。

商用のソフトウェアの場合、仮想環境でのライセンス体系が整備されていないと、使いたくても使いようがありません。ライセンスは重要なポイントです。

もっとも、開発者のレベル次第では、OSSかつ無償のものを使う戦略もあるのかもしれませんね。

3. アプリケーションが上手く稼動しない場合
  • データベースのようにI/Oが多いアプリケーション、あるいは、下層のハードウェアで動くことをチューニングを要求するもの。
  • ディスク集約的なワークロード(これらの1つを仮想化する場合は、パススルーディスクを仮想ハードディスクの代わりに利用してください)
  • グリッドあるいは分散SMPでいくつかのカタマリに分かれており、高速な相互接続が必要なアプリケーション
  • 仮想ドライバでないハードウェアカードを必要とするアプリケーション、あるいは、違法コピーを防止する特殊な装置との接続を必要とするアプリケーション
  • グラフィックスを集中的に必要とするアプリケーション(特に、ハイエンドのビデオカードを必要とするもの)

上の3つは程度問題で、下の2つは物理的に無理という話ですね。

4. time driftがアプリケーションに悪影響を及ぼす場合

VMは物理的なホストと同一の時刻を格納しません。それはつまりtime drift(物理的なクロックから徐々に乖離するVMクロック)が起きることを意味します。これがほんの少し起きただけでもアプリケーションに不具合が出る場合、仮想化すべきではありません。たとえば、それは、金融のリアルタイムトレーディングのアプリケーションや、産業用制御システムまわりに関するシステムです。

分散環境でのVM間の時刻同期も、仮想化する際に留意する点の1つですね。

5. あなたがケチな人のために働いている場合

!?

Sorry、有益なITプロジェクト同様に、仮想化には予算が必要です。代価を支払えない場合は、仮想化を始めないでください。適切なツールのない中途半端な仮想化は、今手元にあるものよりも悪いです。

おまえは何を言っているんだ

そりゃそうです。

6. すでに高キャパシティでアプリケーションを動かしている場合

安定したサーバにハイパーバイザーを追加することは、パフォーマンス改善の助けになりません。この十年間で、ハイパーバイザーが引き起こすCPUオーバーヘッドの削減は大きく進歩しましたが、それはまだCPU上の余計な負荷です。この場合、ただハイパーバイザーにサイクルを提供するために、別のサーバを購入することは、良い投資ではありません。(後略)

これは、1.と似ていますね。

7. 暗号鍵を管理する方法がない場合

暗号鍵の管理は物理サーバ上で行うと簡単です。仮想化のためにセキュアなワークロードが稼動している時、物理サーバ用に設計された暗号鍵の管理は上手くいきません。この問題を解決するために、パスワードもしくは個々のVMに格納した証明書を使う方法がありますが、それは安全ではありません。ポリシーベースの暗号鍵管理は、アプリケーションをセキュアに実行することを要求します。

これは「仮想化しない理由」としては弱い…というか、IaaSレイヤーの設計・運用で解決すべき課題です。

8. ビルトインのフェイルオーバー機能で、クラスタアプリケーションを利用する場合

モダンな仮想化プラットフォームは、VMのHA(high availability: 高可用性)のために様々なフレーバーを提供します。不運にも、(特に、古く、ミッションクリティカルな)いくつかのアプリケーションもまた、HAの機能を用意しています。シェアードディスクでMicrosoft Cluster Servicesを実行するものなどが良い例です。これらは、VMが自動的に移動することを許すプライベートクラウドを破壊するでしょう。もし仮想プラットフォームがHAを提供しているなら、アプリケーションは仮想化するべきではありませんし、その逆も同様です。

アプリケーションレベルのHAの機能と、仮想基盤レベルのHAの機能が適合しないという話でしょうか。

自分はこのあたりが不勉強でよく分かりません。すみません。

9. すべてのデスクトップにかかる費用を仮想化で節約したい場合

サーバは安いデスクトップより高いです。(仮想化をしても)PC、タブレットシンクライアントを買い続けなければいけませんし、また、それらをセキュアに管理しなければいけません。仮想デスクトップはセキュリティとコンプライアンスに貢献しますが、すべての職種の従業員のための低価格オプションではありません。

はい。

10. 仮想化プラットフォームコンポーネントを実行している場合

仮想化プラットフォームとハイパーバイザーがアクティブディレクトリあるいはDNSサーバに依存しており、それらのサーバを仮想化した場合、絶体絶命な状況になるでしょう。実行するVMからのサービスを待つために、ハイパーバイザーを起動できないからです。あっちゃー。さらに、仮想化管理ソフト(vCenterなど)が、それが管理するサーバー上で実行できるか、また、実行されるべきかどうかをチェックする必要があります。

!? なにそれこわい。そんなことやろうとしたこともないっす。イメージできません。すいません。

ちなみに、通常のゲストOSをADやDNSに依存させることは、正しく構成すれば何の問題もありません(念のため…)。

まとめ

というわけで、「仮想化しないことを考えるべき10の状況」を勝手にまとめます。

技術寄りの課題になる状況
  • 1. コンピューティングリソースのニーズが静的で予測可能である場合
  • 3. アプリケーションが上手く稼動しない場合(のうち、物理的な障壁がある項目)
  • 4. time driftがアプリケーションに悪影響を及ぼす場合
  • 6. すでに高キャパシティでアプリケーションを動かしている場合
  • 7. 暗号鍵を管理する方法がない場合
  • 8. ビルトインのフェイルオーバー機能で、クラスタアプリケーションを利用する場合
  • 10. 仮想化プラットフォームコンポーネントを実行している場合

1と6は「仮想化しないことを考えるべき」状況としては微妙な気がしますが、ROIが問題になりそうです。

ビジネス寄りの課題になる状況
  • 2. 仮想化と親和性の高いライセンスを利用できない場合
単に仮想化への過剰な期待を戒めるもの
  • 5. あなたがケチな人のために働いている場合
  • 9. すべてのデスクトップにかかる費用を仮想化で節約したい場合

そんな感じでした。以上です。

# もし興味があればこちらもどうぞ。クラウドアーキテクチャパターン(via DoubleCloud.org) - 虎塚