ハードウェア仮想化

この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "ハードウェア仮想化" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2023年8月)

|

ハードウェア仮想化（ハードウェアかそうか、英: hardware virtualization）とは、ソフトウェアを使用して、コンピューターのリソースを仮想マシンと呼ばれる個別の分離されたエンティティに分割することである。つまり、完全なハードウェアプラットフォーム、コンポーネントの特定の論理的抽象化、またはさまざまなオペレーティングシステムの実行に必要な機能のみとしてのコンピューターの仮想化である。ハードウェア仮想化により、同一または異なるオペレーティングシステムの複数のコピーをコンピューター上で実行することができ、異なる仮想マシンのアプリケーションが互いに干渉し合うのを防ぐことができる[1]。仮想化は、コンピューティングプラットフォームの物理的特性をユーザーから隠し、代わりに抽象的なコンピューティングプラットフォームを提示する。[2][3]当初、仮想化を制御するソフトウェアは「制御プログラム」と呼ばれていたが、「ハイパーバイザー」または「仮想マシンモニター」という用語が徐々に好まれるようになった。[4]

## 概念

[編集]

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

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

仮想化は、ハイパーバイザーの実行に必要なリソースと、物理マシンでネイティブに実行する場合と比較して仮想マシンでのパフォーマンスの低下の両方で、パフォーマンスの低下を招くことがよくある。

## 仮想化の理由

[編集]

* サーバー統合の場合、CPUやハードドライブなどのより多くの（コストのかかる）ハードウェアリソースの必要性を減らすために、多くの小さな物理サーバーが1つの大きな物理サーバーに置き換えられる。ハードウェアは仮想環境に統合されているが、通常、OSは統合されていない。代わりに、物理サーバーで実行されている各OSは、仮想マシン内で実行されている個別のOSに変換される。これにより、大規模サーバーはそのような多くの「ゲスト」仮想マシンを「ホスト」できる。これは、物理から仮想（P2V）への変換として知られている。
* サーバーの統合は、機器のメンテナンスに関連する機器と人件費の削減に加えて、エネルギー消費とテクノロジーの環境生態学的セクターにおける世界的なフットプリントを削減するという追加の利点もある。たとえば、一般的なサーバーは425で実行される W [5]とVMwareは、最大15：1のハードウェア削減率を見積もっている。[6]
* 仮想マシン（VM）は、物理マシンよりもリモートサイトから簡単に制御および検査でき、VMの構成はより柔軟である。これは、カーネル開発や、最新のハードウェアをサポートしていないレガシーオペレーティングシステムの実行など、オペレーティングシステムコースの指導に非常に役立つ。[7]
* 事前にハードウェアを購入しなくても、必要に応じて新しい仮想マシンをプロビジョニングできる。
* 仮想マシンは、必要に応じて、ある物理マシンから別の物理マシンに簡単に再配置できる。たとえば、顧客に行く営業担当者は、物理コンピュータを輸送することなく、デモソフトウェアを備えた仮想マシンをラップトップにコピーできる。同様に、仮想マシン内のエラーはホストシステムに害を及ぼさないため、ラップトップでOSがクラッシュするリスクはない。
* この再配置の容易さにより、仮想マシンは、再生されたエネルギー源や障害のあるエネルギー源の影響を心配することなく、災害復旧シナリオで簡単に使用できる。

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

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

仮想化のユースケースの例：

* ホストOSでサポートされていない1つ以上のアプリケーションの実行：必要なゲストOSを実行している仮想マシンは、ホストOSを変更せずに、目的のアプリケーションの実行を許可できる。
* 代替オペレーティングシステムの評価：ホストOSを変更せずに、新しいOSをVM内で実行できる。
* サーバーの仮想化：物理サーバーのハードウェアリソースをより完全に活用するために、単一の物理サーバーで複数の仮想サーバーを実行できる。
* 特定の環境の複製：仮想マシンは、使用する仮想化ソフトウェアに応じて、複製して複数のホストにインストールするか、以前にバックアップしたシステム状態に復元することができる。
* 保護された環境の作成：マルウェアの調査や動作の悪いソフトウェアのインストールなど、VMで実行されているゲストOSが修復に費用効果の低い方法で損傷した場合、VMは害を及ぼすことなく単純に破棄される可能性がある。ホストシステム、およびゲストの再起動時に使用されるクリーンコピー。

## 完全仮想化

[編集]

完全仮想化の論理図。

完全仮想化では、仮想マシンは十分なハードウェアをシミュレートして、同じ命令セット用に設計された変更されていない「ゲスト」OSを分離して実行できるようにする。このアプローチは、VMファミリの前身であるIBM CP-40およびCP-67で1966年に開拓された。

## ハードウェア支援仮想化

[編集]

ハードウェア支援仮想化では、ハードウェアは、仮想マシンモニターの構築を容易にし、ゲストOSを分離して実行できるようにするアーキテクチャサポートを提供する。[8]ハードウェア支援仮想化は、最初の仮想マシンオペレーティングシステムであるVM / 370で使用するために、1972年にIBM System / 370に最初に導入された。

2005年と2006年に、IntelとAMDは仮想化をサポートするための追加のハードウェアを提供した。Sun Microsystems（現在のOracle Corporation）は、2005年にUltraSPARCTシリーズプロセッサに同様の機能を追加した。

2006年、第1世代の32ビットおよび64ビットのx86ハードウェアサポートが、ソフトウェア仮想化よりもパフォーマンス上の利点を提供することはめったになかった。[9]

## 準仮想化

[編集]

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

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

[編集]

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

## ハードウェア仮想化ディザスタリカバリ

[編集]

ディザスタリカバリ（DR）計画は、ハードウェア仮想化プラットフォームの優れた方法と見なされることがよくある。仮想化環境のDRは、通常のビジネス運用を混乱させるさまざまな状況で高い可用性を確保できる。ハードウェア仮想化プラットフォームの継続的な運用が重要な状況では、ディザスタリカバリ計画により、ハードウェアのパフォーマンスとメンテナンスの要件を確実に満たすことができる。ハードウェア仮想化ディザスタリカバリ計画には、以下に説明する方法を含むさまざまな方法によるハードウェアとソフトウェアの両方の保護が含まれる。[10][11]

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

## 脚注

[編集]

[脚注の使い方]

1. ^ Stallings, William,. Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud. Agboma, Florence,, Jelassi, Sofiene,. Indianapolis, Indiana. ISBN 978-0-13-417547-8. OCLC 927715441. https://www.worldcat.org/oclc/927715441
2. ^ Turban, E; King, D.; Lee, J.; Viehland, D. (2008). “19”. Electronic Commerce A Managerial Perspective (5th ed.). Prentice-Hall. pp. 27. http://wps.prenhall.com/wps/media/objects/5073/5195381/pdf/Online_Chapter_19.pdf
3. ^ “Virtualization in education”. IBM (2007年10月). 2010年7月6日閲覧。
4. ^ Creasy (1981年). “The Origin of the VM/370 Time-sharing System”. IBM. 2013年2月26日閲覧。
5. ^ [1] Profiling Energy Usage for Efficient Consumption; Rajesh Chheda, Dan Shookowsky, Steve Stefanovich, and Joe Toscano
6. ^ VMware server consolidation overview
7. ^ Examining VMware Dr. Dobb’s Journal August 2000 By Jason Nieh and Ozgur Can Leonard
8. ^ Uhlig, R. et al.; "Intel virtualization technology," Computer, vol.38, no.5, pp. 48-56, May 2005
9. ^ A Comparison of Software and Hardware Techniques for x86 Virtualization, Keith Adams and Ole Agesen, VMware, ASPLOS’06 21–25 October 2006, San Jose, California, USA "Surprisingly, we find that the first-generation hardware support rarely offers performance advantages over existing software techniques. We ascribe this situation to high VMM/guest transition costs and a rigid programming model that leaves little room for software flexibility in managing either the frequency or cost of these transitions."
10. ^ “The One Essential Guide to Disaster Recovery: How to Ensure IT and Business Continuity”. Vision Solutions, Inc. (2010年). 2011年5月16日時点のオリジナルよりアーカイブ。2010年11月14日閲覧。
11. ^ Wold (2008年). “Disaster Recovery Planning Process”. 2012年8月15日時点のオリジナルよりアーカイブ。2010年11月14日閲覧。
12. ^ “Disaster Recovery Virtualization Protecting Production Systems Using VMware Virtual Infrastructure and Double-Take”. VMware (2010年). 2010年9月23日時点のオリジナルよりアーカイブ。2010年11月14日閲覧。

## 外部リンク

[編集]

* 仮想化の概要
* Xen and the Art of Virtualization 、ACM、2003、著者グループによる
* Linux仮想化ソフトウェア