標準パターンとしての仮想化
エンタープライズのコンセプトとしての仮想化は、ビジネスコンピューティングそのものとほぼ同じくらい古い歴史を持っています。コンピューティングをベアハードウェアから抽象化する価値は非常に早い段階で認識され、コンピューターが抽象化プロセスを管理できる能力を持つようになったほぼ同時に、今日私たちが知るような仮想化の実装に向けた取り組みが始まりました。
仮想化に関する最も古く広く受け入れられている取り組みは、1964年にIBM System/360メインフレーム向けのIBM CP-40オペレーティングシステム開発者によって始まりました。これが商業的な仮想化への本格的な最初の進出であり、この初期の仮想化プラットフォームのコードと設計は、1972年から継続して使用されているIBM VMプラットフォームに引き継がれ、数十年にわたってIBMメインフレームファミリーの仮想化レイヤーとして機能してきました。IBMが仮想化を最初に導入して以来、エンタープライズシステムがこのハードウェア抽象化のパターンをほぼ普遍的に採用してきたことが確認されています。多くの大規模コンピューティングシステム、ミニコンピューター、メインフレームが1970年代に仮想化へと移行し、残りのエンタープライズシステムの大部分も、技術と能力が利用可能になるにつれて、1980年代から1990年代にかけて移行しました。
エンタープライズコンピューティングにおける仮想化の唯一の顕著な例外は、Intel IA32（別名x86）プラットフォームでした。このプラットフォームは、拡張AMD64 64ビットプラットフォームの登場まで、効果的な仮想化を実装するために必要な高度なハードウェアリソースを欠いており、その場合でも特定の新しい技術が必要でした。これが導入されると、すべてのビジネスコンピューティングの主要プラットフォームにわたって、同等の高性能で高セキュリティの仮想化が利用可能となりました。
低コストのx86プラットフォームは、2000年代半ばまで意味のある仮想化を欠いていたため（一般的に低性能なソフトウェア仮想化とニッチな高性能パラ仮想化プラットフォームを除いて）、中小企業の大多数にとって仮想化はほぼ選択肢にありませんでした。これにより、SMBスペースに専念している多くの人が、仮想化がビジネスサーバーコンピューティングのデファクト標準として確立された、十分に確立された成熟した技術セットであることを認識していない状況となりました。ハードウェア抽象化の使用はエンタープライズコンピューティングでほぼ普遍的であり、最大かつ最も安定したプラットフォームの多くには、少なくとも公式にサポートされたオプションとして、システムを「ベアメタル」で実行するオプションがありません。
仮想化によるハードウェア抽象化を避けることが推奨されない特定のニッチな分野がありますが、これらは非常にまれであり、特にSMB市場においてはそうです。仮想化しない必要があるシステムの典型的な例としては、レイテンシに敏感なシステム（低レイテンシの取引プラットフォームなど）や、安定性とユーティリティよりもパフォーマンスを主目標とするHPCコンピュータークラスターのようなマルチサーバー複合ワークロードが挙げられます。これらはいずれもSMBには一般的ではありません。
仮想化には多くの利点があります。仮想化があまり期待されていないSMBでは、仮想化の目標は大規模なコスト削減が可能な統合や、高可用性を提供する新しい方法にあると思われがちです。これらは特定の組織や状況に役立つ優れたオプションですが、いずれも仮想化の根本的な正当性ではありません。必要であれば、統合や高可用性は他の手段でも達成できます。仮想化は単に、これらの特定分野での優れたオプションを提供してくれるだけです。
仮想化の用途の多くは、ライセンスコストの潜在的な削減などのエコシステムの成果物です。このような利点は仮想化固有の利点ではありませんが、存在しており、現実世界の評価においては見落とすことができません。すべての利点がすべてのハイパーバイザーや仮想化プラットフォームに適用されるわけではありませんが、ほぼすべてが幅広く適用されます。ハードウェア抽象化はコンセプトであり、実装ではないため、その活用方法は様々です。コンセプトとして、ストレージレイヤーやコンピューティングレイヤーなどでのハードウェア抽象化は、管理を簡素化し、信頼性を向上させ、開発を加速させるという点で非常に重要です。
以下は仮想化の利点の一部です。統合や高可用性などの特定のものを除いて、これらの利点のほぼすべては、単一の物理ノードでの仮想化だけでなく、そのノード上の単一ワークロードにも適用されることに注意することが重要です。
- ハードウェアの変更、障害、修正、拡張などに関連する人的労力と影響の削減
- 異なるハードウェアターゲットでも、シンプルなバックアップ/リストアプロセスのためのストレージのカプセル化
- 変更管理の保護のためのシステム全体のスナップショット
- 廃止や廃棄時のアーカイブの容易さ
- 監視機能の向上。ネイティブにこれを提供しないハードウェアプラットフォームでも帯域外管理を追加
- ハードウェア非依存性により、オペレーティングシステムがハードウェア自体ではなくハイパーバイザーをハードウェアと認識するため、ベンダーロックインなし
- 容易なワークロードセグメンテーション
- ワークロードのセグメンテーションを維持しながらの容易な統合
- リソース利用率の大幅な改善
- ハードウェア抽象化により、クライアントオペレーティングシステムのOSおよびドライバー開発者への要求を下げながら、システムのパフォーマンスと安定性を大幅に向上させる機会が実現
- 新規および多様なワークロードのデプロイの簡素化
- 単一プラットフォームからマルチプラットフォームのホスティング環境への簡単な移行。これにより、クラウドデプロイや高可用性プラットフォームシステムなどのオプションを追加可能
- 容易な物理スケーリングのためのワークロードの再デプロイ
今日のコンピューティング環境では、これらの理由からサーバーサイドのワークロードは普遍的に仮想化されるべきです。仮想化のメリットは非常に大きく、デメリットはわずかで軽微なものです。仮想化をまだ避ける必要がある2つの一般的なシナリオは、サーバーで直接使用する必要がある専用ハードウェアがある状況（これは今日では非常にまれになりましたが、まだ時折存在します）と、サブミリ秒のレイテンシが重要な超低レイテンシシステムです。後者は、低レイテンシの投資取引システムのような非常にニッチなビジネス状況においてのみ一般的です。このような要件を持つシステムは、取引フロアから5マイル以内の光ファイバーを使用した低レイテンシInfinibandなど、驚異的なネットワークおよび地理的要件も持ちます。
高性能コンピューティングクラスターが仮想化を使用しないと指摘する人もいますが、これはグレーゾーンです。あらゆる形式のクラスタリングは事実上、仮想化の一形態です。単に、システムレベルの仮想化ではなく、「スーパーシステム」レベルの仮想化であるだけです。
仮想化を使用すべきでないシナリオに自分が置かれている場合は、それを疑いの余地なく知ることができ、仮想化が物理的または実用的に不可能な理由を実証できると想定して差し支えありません。それ以外のすべてのケースでは、仮想化してください。物理サーバーが1台でワークロードが1つ、ユーザーが1人だけでも仮想化してください。Fortune 100企業で最も要求の厳しいワークロードを持つ場合も仮想化してください。そして、その間のすべての規模でも仮想化してください。規模は仮想化の要因ではありません。私たちが仮想化するのは、今日だけでなく将来にわたって、より効果的で安定したコンピューティング環境を望むからです。
広告
