ハードウェア仮想化とは、コンピュータを完全なハードウェアプラットフォーム、その構成要素の特定の論理的抽象化、またはさまざまなオペレーティングシステムを実行するために必要な機能のみとして仮想化することです。仮想化はホストアーキテクチャのハードウェア環境をエミュレートし、複数の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 ]
- サーバーの統合は、機器のメンテナンスに関連する機器および人件費を削減するだけでなく、エネルギー消費量と環境・生態学分野における地球規模の負荷を削減するという利点ももたらします。たとえば、一般的なサーバーは 425 Wで動作し[ 6 ]、VMware はハードウェア削減率が最大 15:1 になると推定しています[ 7 ] 。
- 仮想マシン(VM)は、物理マシンよりもリモートサイトから簡単に制御および検査でき、VM の構成はより柔軟です。これは、カーネル開発やオペレーティングシステムのコースの教育、最新のハードウェアをサポートしていないレガシー オペレーティングシステムの実行などに非常に役立ちます。[ 8 ]
- 必要に応じて新しい仮想マシンをプロビジョニングできるため、事前にハードウェアを購入する必要はありません。
- 仮想マシンは、必要に応じて物理マシン間で簡単に移動できます。例えば、顧客を訪問する営業担当者は、デモ用ソフトウェアをインストールした仮想マシンを自分のノートパソコンにコピーできるため、物理コンピュータを持ち運ぶ必要がありません。同様に、仮想マシン内のエラーはホストシステムに影響を与えないため、ノートパソコンのOSがクラッシュするリスクもありません。
- このように容易に移転できるため、仮想マシンは、改修されたり故障したりした電源の影響を心配することなく、災害復旧シナリオで容易に利用できます。
しかし、複数の仮想マシンが同じ物理ホスト上で同時に稼働している場合、各仮想マシンのパフォーマンスは変動し不安定になる可能性があり、これは他の仮想マシンによってシステムに課されるワークロードに大きく依存します。この問題は、仮想マシン間の時間的分離のための適切なインストール手法を用いることで解決できます。
プラットフォーム仮想化にはいくつかの手法がある。
仮想化のユースケースの例:
- ホストOSでサポートされていないアプリケーションを1つ以上実行する: 必要なゲストOSを実行する仮想マシンを使用することで、ホストOSを変更することなく、目的のアプリケーションを実行できるようになります。
- 代替オペレーティングシステムの評価:新しいOSは、ホストOSを変更することなく、仮想マシン内で実行できます。
- サーバー仮想化:物理サーバーのハードウェアリソースをより有効活用するために、1台の物理サーバー上で複数の仮想サーバーを実行できる。
- 特定の環境の複製:使用する仮想化ソフトウェアによっては、仮想マシンを複製して複数のホストにインストールしたり、以前にバックアップしたシステム状態に復元したりすることができます。
- 保護された環境の作成: VM 上で実行されているゲスト OS が、マルウェアの研究や不正なソフトウェアのインストール時などに、修復に費用対効果がない方法で破損した場合、ホスト システムに影響を与えることなく VM を破棄し、ゲストを再起動する際にクリーンなコピーを使用できます。
準仮想化
準仮想化では、仮想マシンは必ずしもハードウェアをシミュレートするのではなく、代わりに(またはそれに加えて)「ゲスト」OSを変更することによってのみ使用できる特別なAPIを提供します。これを実現するには、「ゲスト」OSのソースコードが利用可能である必要があります。ソースコードが利用可能な場合は、機密性の高い命令をVMM APIへの呼び出し(例:「cli」を「vm_handle_cli()」)に置き換え、OSを再コンパイルして新しいバイナリを使用するだけで十分です。このハイパーバイザへのシステムコールは、TRANGOおよびXenでは「ハイパーコール」と呼ばれ、IBMのCMSのVM (ハイパーバイザという用語の起源)ではDIAG(「診断」)ハードウェア命令を介して実装されています。
ハードウェア支援型仮想化
ハードウェア支援仮想化では、ハードウェアが仮想マシンモニタの構築を容易にし、ゲストOSを分離して実行できるようにするアーキテクチャサポートを提供します。[ 9 ]これは、完全仮想化または準仮想化のどちらにも使用できます。ハードウェア支援仮想化は、 1980年にIBM 308Xプロセッサで初めて導入され、Start Interpretive Execution (SIE)命令が使用されました。[ 10 ]
2005年と2006年に、インテルとAMDは、自社プラットフォーム上で動作する仮想化をサポートする追加ハードウェアを開発した。サン・マイクロシステムズ(現オラクル社)は、2005年にUltraSPARC Tシリーズプロセッサに同様の機能を追加した。
2006年には、第一世代の32ビットおよび64ビットx86ハードウェアサポートは、ソフトウェア仮想化に比べてパフォーマンス上の利点をほとんど提供しないことが判明した。[ 11 ]
オペレーティングシステムレベルの仮想化
オペレーティングシステムレベルの仮想化では、物理サーバーがオペレーティングシステムレベルで仮想化され、単一の物理サーバー上で複数の分離された安全な仮想サーバーを実行できます。「ゲスト」オペレーティングシステム環境は、ホストシステムと同じオペレーティングシステムの実行インスタンスを共有します。したがって、「ゲスト」環境の実装にも同じオペレーティングシステムカーネルが使用され、特定の「ゲスト」環境で実行されているアプリケーションは、それを独立したシステムとして認識します。
ハードウェア仮想化による災害復旧
ハードウェア仮想化プラットフォームでは、災害復旧(DR)計画がしばしば良い実践とみなされます。仮想化環境のDRは、通常の業務を中断させるさまざまな状況下で高い可用性を確保できます。ハードウェア仮想化プラットフォームの継続的な運用が重要な状況では、災害復旧計画によってハードウェアのパフォーマンスとメンテナンスの要件が満たされることが保証されます。ハードウェア仮想化の災害復旧計画には、以下で説明する方法を含むさまざまな方法によるハードウェアとソフトウェアの両方の保護が含まれます。[ 12 ] [ 13 ]
- ソフトウェアデータの長期保存ニーズに対応するテープバックアップ
- この一般的な方法は、データをオフサイトに保存するために使用できますが、データ復旧は困難で時間のかかるプロセスになる可能性があります。テープバックアップデータは、保存されている最新のコピーの精度に依存します。テープバックアップ方式では、バックアップデバイスと継続的なストレージ媒体が必要になります。
- ファイル全体およびアプリケーションのレプリケーション
- この方法を導入するには、制御ソフトウェアと、アプリケーションおよびデータファイルのストレージレプリケーション用のストレージ容量が必要となります。これらのストレージは通常、同一サイト上に設置されます。データは別のディスクパーティションまたは別のディスクデバイスに複製され、ほとんどのサーバーではスケジュールされた処理として実行可能であり、データベースタイプのアプリケーションでより多く採用されています。
- ハードウェアとソフトウェアの冗長性
- この方法は、ハードウェア仮想化ソリューションに対して最高レベルの災害復旧保護を保証するものであり、2つの異なる地理的領域にハードウェアとソフトウェアの複製を提供する。[ 14 ]
参考文献
- 1 2 Creasy, RJ (1981). 「VM/370 タイムシェアリングシステムの起源」(PDF) . IBM . 2013 年2 月 26 日取得.
- ↑ Thomson, Julian (2018年5月23日). 「仮想マシン: プラットフォーム仮想化入門」 . Performance Software . 2023年7月8日取得。
- ↑ 「サーバー仮想化とは?」
- 1 2 Bugnion, Edouard; Nieh, Jason; Tsafrir, Dan (2017).仮想化のためのハードウェアとソフトウェアのサポート. サンラファエル、カリフォルニア州: Morgan & Claypool Publishers. ISBN 9781627056939。
- ↑ 「チップの劣化が加速」。2018年2月14日。
- ↑ Rajesh Chheda; Dan Shookowsky; Steve Stefanovich; Joe Toscano (2009年1月14日) 「効率的な消費のためのエネルギー使用状況のプロファイリング」。
- ↑ 「VMwareサーバー統合の概要」。2022年1月8日にオリジナルからアーカイブされました。
- ↑ Jason Nieh ; Ozgur Can Leonard (2000 年 8 月) 「VMware の検証」 Dr. Dobb's Journal 2019 年 11 月 22 日時点のオリジナルよりアーカイブ。
- ↑ 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 .
- ↑ IBM System/370 Extended Architecture Interpretive Execution (PDF) (初版). IBM. 1984年1月. SA22-7095-0 . 2022年10月27日取得.
- ↑ Keith Adams; Ole Agesen (2006 年 10 月 21 ~ 25 日). x86 仮想化のためのソフトウェアとハードウェア技術の比較(PDF) . ASPLOS'06. 米国カリフォルニア州サンノゼ。2022年 1 月 8 日にオリジナル(PDF)からアーカイブ済み。
驚くべきことに、第一世代のハードウェア サポートは、既存のソフトウェア技術に比べてパフォーマンス上の利点をほとんど提供しないことがわかりました。この状況は、VMM/ゲストの移行コストが高いことと、これらの移行の頻度やコストを管理するソフトウェアの柔軟性をほとんど残さない厳格なプログラミング モデルに起因すると考えられます。
- ↑ 「災害復旧のための必須ガイド:ITと事業継続性を確保する方法」(PDF) 。Vision Solutions, Inc. 2010年。2011年5月16日にオリジナル(PDF)からアーカイブ済み。
- ↑ Wold, G (2008). "災害復旧計画プロセス" . 2012年8月15日にオリジナルからアーカイブ済み。
- ↑ 「VMware Virtual InfrastructureとDouble-Takeを使用した災害復旧仮想化による本番システムの保護」(PDF)。VMware。2010年。 2010年9月23日にオリジナル(PDF)からアーカイブ済み。
外部リンク
- 仮想化入門( 2020年10月22日、 Wayback Machineにアーカイブ済み) 、著者:Amit Singh
- Xenと仮想化の芸術、ACM、2003年、著者グループによる
- Linux仮想化ソフトウェア
- Zoppis, Bruno (2007年8月27日) [初出 LinuxDevices:2007]. 「ハイパーバイザを使用してGPLと独自の組み込みコードを調和させる」 . Linux Gizmos . 2013年12月24日のオリジナルからアーカイブ済み。