ハードウェア仮想化

ハードウェア仮想化とは、コンピュータを完全なハードウェアプラットフォーム、コンポーネントの特定の論理抽象化、あるいは様々なオペレーティングシステムの実行に必要な機能のみとして仮想化することです。仮想化はホストアーキテクチャのハードウェア環境をエミュレートすることで、複数のOSを変更せずに独立して実行することを可能にします。当初、仮想化を制御するソフトウェアは「制御プログラム」と呼ばれていましたが、時が経つにつれて「ハイパーバイザー」または「仮想マシンモニター」という用語が好まれるようになりました。[ 1 ]

コンセプト

「仮想化」という用語は、1960年代に仮想マシン(「疑似マシン」と呼ばれることもある)を指すために造語された。この用語自体は、実験的なIBM M44/44Xシステムに由来する。[ 1 ]仮想マシンの作成と管理は、最近では「プラットフォーム仮想化」または「サーバー仮想化」とも呼ばれている。[ 2 ] [ 3 ]

プラットフォーム仮想化は、特定のハードウェア プラットフォーム上でホストソフトウェア (制御プログラム)によって実行され、ゲストソフトウェア用にシミュレートされたコンピュータ環境である仮想マシン(VM) を作成します。ゲスト ソフトウェアはユーザー アプリケーションに限定されず、多くのホストでは完全なオペレーティング システムの実行が許可されています。ゲスト ソフトウェアは、いくつかの注目すべき注意事項はあるものの、物理ハードウェア上で直接実行されているかのように実行されます。物理システム リソース (ネットワーク アクセス、ディスプレイ、キーボード、ディスク ストレージなど) へのアクセスは、通常、ホストプロセッサやシステム メモリよりも制限の厳しいレベルで管理されます。ゲストは、仮想化ホストによって実装されたハードウェア アクセス ポリシーに応じて、特定の周辺機器へのアクセスが制限されることが多く、デバイスのネイティブ機能のサブセットに制限されることもあります。[ 4 ] :5,13

仮想化は、ハイパーバイザーを実行するために必要なリソースと、物理マシン上でネイティブに実行する場合に比べて仮想マシンのパフォーマンスが低下するという点で、パフォーマンスの低下を招くことがよくあります。[ 4 ]:35、67-68

ハードウェア仮想化の理由

  • サーバー統合の場合、多数の小型物理サーバーを1台の大型物理サーバーに置き換えることで、CPUやハードドライブといった(高価な)ハードウェアリソースの必要性を減らすことができます。仮想環境ではハードウェアは統合されますが、通常OSは統合されません。その代わりに、物理サーバー上で稼働する各OSは、仮想マシン内で稼働する個別のOSに変換されます。これにより、大型サーバーは多数の「ゲスト」仮想マシンを「ホスト」できるようになります。これは、物理サーバーから仮想サーバーへの(P2V)変換として知られています。2000年代初頭のサーバーの平均利用率は5~15%でしたが、仮想化の導入に伴い、この数値は上昇し始め、必要なサーバー数が削減されました。[ 5 ]
  • サーバーの統合は、機器の保守に関連する設備費や人件費の削減に加え、エネルギー消費量と環境・生態学的な技術分野における地球規模のフットプリントの削減という付加的なメリットももたらします。例えば、一般的なサーバーは425Wで動作します[ 6 ]。VMwareはハードウェア削減率を最大15:1と見積もっています[ 7 ] 。
  • 仮想マシン(VM)は、物理マシンよりもリモートサイトから容易に制御・検査でき、構成もより柔軟です。これは、カーネル開発やオペレーティングシステムのコース教育、特に最新のハードウェアをサポートしていないレガシーオペレーティングシステムの実行に非常に役立ちます。[ 8 ]
  • 事前にハードウェアを購入する必要がなく、必要に応じて新しい仮想マシンをプロビジョニングできます。
  • 仮想マシンは、必要に応じて物理マシン間で簡単に移動できます。例えば、顧客を訪問する営業担当者は、デモソフトウェアをインストールした仮想マシンをラップトップにコピーするだけで、物理コンピュータを移動させる必要はありません。同様に、仮想マシン内でエラーが発生してもホストシステムに悪影響が及ばないため、ラップトップでOSがクラッシュするリスクもありません。
  • このように簡単に再配置できるため、仮想マシンは、改修されたエネルギー源や故障したエネルギー源の影響を心配することなく、災害復旧シナリオですぐに使用できます。

しかし、複数のVMが同じ物理ホスト上で同時に動作している場合、各VMのパフォーマンスは、他のVMによってシステムに課せられるワークロードに大きく依存し、変動し不安定になる可能性があります。この問題は、仮想マシン間の時間的な分離を適切に行うための適切なインストール手法によって解決できます。

プラットフォーム仮想化にはいくつかのアプローチがあります。

仮想化の使用例:

  • ホスト OS でサポートされていない 1 つ以上のアプリケーションを実行する: 必要なゲスト OS を実行する仮想マシンでは、ホスト OS を変更せずに、必要なアプリケーションを実行できます。
  • 代替オペレーティング システムの評価: ホスト OS を変更することなく、新しい OS を VM 内で実行できます。
  • サーバー仮想化: 物理サーバーのハードウェア リソースをより有効に活用するために、単一の物理サーバー上で複数の仮想サーバーを実行できます。
  • 特定の環境の複製: 使用する仮想化ソフトウェアに応じて、仮想マシンを複製して複数のホストにインストールしたり、以前にバックアップしたシステム状態に復元したりできます。
  • 保護された環境の作成:マルウェアの調査や不正な動作をするソフトウェアのインストール時などに、VM 上で実行されているゲスト OS が修復に費用対効果の高くないほど損傷した場合、ホスト システムに悪影響を与えることなく VM を破棄し、ゲストを再起動してクリーンなコピーを使用できます。

完全仮想化

完全仮想化の論理図。

完全仮想化では、仮想マシンは十分なハードウェアをシミュレートし、同じ命令セット向けに設計された未修正の「ゲスト」OSを独立して実行できるようにします。このアプローチは、 VMファミリーの前身であるIBM CP-40CP-67で1966年に初めて導入されました。

準仮想化

準仮想化では、仮想マシンは必ずしもハードウェアをシミュレートするわけではなく、代わりに(またはそれに加えて)、ゲストOSを変更することによってのみ使用できる特別なAPIを提供します。これを実現するには、ゲストOSのソースコードが利用可能である必要があります。ソースコードが利用可能であれば、重要な命令をVMM API呼び出し(例:cliをvm_handle_cli()に置き換え、OSを再コンパイルして新しいバイナリを使用するだけで十分です。ハイパーバイザーへのこのシステムコールは、 TRANGOおよびXenでは「ハイパーコール」と呼ばれています。これは、 VM (ハイパーバイザーという用語の由来)上のIBM CMSではDIAG(診断)ハードウェア命令を介して実装されています。

ハードウェア支援による仮想化

ハードウェア支援型仮想化では、ハードウェアが仮想マシンモニターの構築を容易にし、ゲストOSを独立して実行できるようにするアーキテクチャサポートを提供します。[ 9 ]これは、完全仮想化または準仮想化のいずれかを支援するために使用できます。ハードウェア支援型仮想化は、 1980年にIBM 308XプロセッサでStart Interpretive Execution(SIE)命令とともに初めて導入されました。[ 10 ]

2005年と2006年に、IntelAMDは、自社プラットフォーム上で実行される仮想化をサポートする追加ハードウェアを開発しました。Sun Microsystems(現Oracle Corporation )は、2005年にUltraSPARC Tシリーズプロセッサに同様の機能を追加しました。

2006年には、第一世代の32ビットおよび64ビットx86ハードウェアサポートは、ソフトウェア仮想化に比べてパフォーマンス上の利点をほとんど提供しないことが判明しました。[ 11 ]

オペレーティングシステムレベルの仮想化

オペレーティングシステムレベルの仮想化では、物理サーバーがオペレーティングシステムレベルで仮想化され、複数の分離された安全な仮想サーバーを単一の物理サーバー上で実行できるようになります。「ゲスト」オペレーティングシステム環境は、ホストシステムと同じオペレーティングシステムの実行インスタンスを共有します。したがって、「ゲスト」環境の実装にも同じオペレーティングシステムカーネルが使用され、特定の「ゲスト」環境で実行されるアプリケーションは、その環境をスタンドアロンシステムとして認識します。

ハードウェア仮想化の災害復旧

ハードウェア仮想化プラットフォームにおいては、災害復旧(DR)計画が推奨されることが多い。仮想化環境のDRは、通常の業務運営を中断させるような様々な状況下においても、高い可用性を確保することができる。ハードウェア仮想化プラットフォームの継続的な運用が重要な状況においては、災害復旧計画によってハードウェアの性能と保守要件が満たされることを保証することができる。ハードウェア仮想化の災害復旧計画には、以下に説明する方法を含む様々な方法によるハードウェアとソフトウェアの両方の保護が含まれる。[ 12 ] [ 13 ]

ソフトウェアデータの長期アーカイブニーズのためのテープバックアップ
この一般的な方法はデータをオフサイトに保存するのに使用できますが、データの復旧は困難で時間のかかるプロセスになる可能性があります。テープバックアップデータは、保存されている最新のコピーと同等の信頼性しか持ちません。テープバックアップ方式では、バックアップデバイスと継続的なストレージ機器が必要になります。
ファイル全体とアプリケーションのレプリケーション
この方式を実装するには、通常、アプリケーションとデータファイルのストレージレプリケーション用の制御ソフトウェアとストレージ容量が同一サイト内で必要になります。データは別のディスクパーティションまたは別のディスクデバイスに複製され、ほとんどのサーバーではスケジュールされたアクティビティとして実行できますが、データベース型のアプリケーションではより多く実装されます。
ハードウェアとソフトウェアの冗長性
この方法は、2つの異なる地理的領域にハードウェアとソフトウェアの複製を提供することで、ハードウェア仮想化ソリューションの最高レベルの災害復旧保護を保証します。[ 14 ]

参照

参考文献

  1. ^ a b Creasy, RJ (1981). 「VM/370タイムシェアリングシステムの起源」(PDF) . IBM . 2013年2月26日閲覧
  2. ^ Thomson, Julian (2018年5月23日). 「仮想マシン:プラットフォーム仮想化入門」 .パフォーマンスソフトウェア. 2023年7月8日閲覧
  3. ^ 「サーバー仮想化とは何ですか?
  4. ^ a b Bugnion, Edouard; Nieh, Jason; Tsafrir, Dan (2017).仮想化のためのハードウェアとソフトウェアのサポート. サンラファエル, カリフォルニア州: Morgan & Claypool Publishers. ISBN 9781627056939
  5. ^ 「チップの老化が加速」 2018年2月14日。
  6. ^ Rajesh Chheda、Dan Shookowsky、Steve Stefanovich、Joe Toscano (2009年1月14日). 「効率的な消費のためのエネルギー使用のプロファイリング」 .
  7. ^ 「VMwareサーバー統合の概要」 。2022年1月8日時点のオリジナルよりアーカイブ
  8. ^ Jason Nieh、Ozgur Can Leonard (2000年8月). 「VMwareの検証」 . Dr. Dobb's Journal . 2019年11月22日時点のオリジナルよりアーカイブ
  9. ^ Smith, L.; Kägi, A.; Martins, FM; Neiger, G.; Leung, FH; Rodgers, D.; Santoni, AL; Bennett, SM; Uhlig, R.; Anderson, AV (2005年5月). 「Intel 仮想化テクノロジ」 . Computer . 38 (5): 48– 56. Bibcode : 2005Compr..38e..48U . doi : 10.1109/MC.2005.163 .
  10. ^ IBM System/370 Extended Architecture Interpretive Execution (PDF) (初版). IBM. 1984年1月. SA22-7095-0 . 2022年10月27日閲覧
  11. ^ Keith Adams; Ole Agesen (2006年10月21~25日). x86仮想化におけるソフトウェアとハ​​ードウェア技術の比較(PDF) . ASPLOS'06. 米国カリフォルニア州サンノゼ. 2022年1月8日時点のオリジナル(PDF)からのアーカイブ。驚くべきことに、第一世代のハードウェアサポートは、既存のソフトウェア技術に比べてパフォーマンス上の優位性を提供することはほとんどないことがわかりました。この状況は、VMM/ゲストの移行コストの高さと、これらの移行の頻度やコストを管理するソフトウェアの柔軟性をほとんど残さない、硬直したプログラミングモデルに起因すると考えられます。
  12. ^ 「災害復旧のための必須ガイド:ITと事業継続性を確保する方法」(PDF)。Vision Solutions, Inc. 2010年。 2011年5月16日時点のオリジナル(PDF)からアーカイブ。
  13. ^ Wold, G (2008). 「災害復旧計画プロセス」 . 2012年8月15日時点のオリジナルよりアーカイブ
  14. ^ 「Disaster Recovery Virtualization Protecting Production Systems Using VMware Virtual Infrastructure and Double-Take」(PDF) 。VMware、2010年。2010年9月23日時点のオリジナル(PDF)からのアーカイブ