第1章 仮想化の概要
この章では、仮想化の概要について説明します。 仮想化を使用する理由、利用できるテクノロジ、およびOracle VMを使用して仮想化ソリューションを実装する利点について説明します。
1.1 仮想化の歴史
仮想化の概念は、IBM社が堅牢なタイムシェアリング・ソリューションの開発に長い時間と労力を投じた1960年代後半から1970年代初頭のメインフレーム時代にその起源があると一般的に考えられています。 タイムシェアリングとは、多人数のユーザー間でのコンピュータ・リソースの共有使用を指し、ユーザーとユーザーが共有する高価なコンピュータ・リソースの両方の効率の向上を目指したものです。 このモデルはコンピュータ・テクノロジにおける飛躍的な進歩となり、演算処理能力の利用コストは激減し、企業、さらには個人が、コンピュータを実際に所有することなく使用できるようになりました。 単一のサーバーの処理容量が非常に大きいために大部分のワークロードではサーバーを効率的に使用することがほとんど不可能な現在の業界標準の演算処理に対して仮想化が推進されているのは、同様の理由によります。 リソース使用率を向上させるのと同時にデータ・センター管理を簡略化する最適な方法は、仮想化の使用です。
現在のデータ・センターは、物理ハードウェアを抽象化する仮想化技術を使用して、CPU、メモリー、ディスク、ファイル記憶域、アプリケーション、ネットワークからなる論理リソースの大規模な集約プールを作成し、これらのリソースをアジャイルかつスケーラブルな、統合された仮想マシンの形式でユーザーまたは顧客に提供します。 テクノロジと使用事例が進化を遂げても、コンピューティング環境で同時に複数の独立したシステムの実行を可能にするという、仮想化の中心的な意味は変わっていません。
1.2 仮想化を使用する理由
今日、企業や組織が仮想化に投資することには多くの様々な正当な理由がありますが、経済的理由がその1番の動機付けになっていると言ってもおそらく過言ではないほど、仮想化によって多額のコストを節約できます。 次に、仮想化の主な利点の概要を示します。
|
項目 |
説明 |
|---|---|
|
リソースの最適化 |
今日の企業レベルのコンピュータ・リソースは非常に強力であり、多くの場合、過剰な処理能力を抱えています。 ハードウェアを仮想化し、ユーザーやアプリケーションによる実際の必要性に基づいて個々の仮想化ハードウェアを割り当てることによって、利用可能な計算能力、記憶域、およびネットワーク帯域幅を従来よりもかなり効率的に使用できます。 接続ユーザー数が減少したために、または、ホストされたアプリケーションの要求がサーバーの処理可能量よりも偶然少なかったために、コンピュータがアイドル状態になったり、処理能力以下で動作する必要はなくなります。 仮想マシンによって、ソフトウェア開発者に、制約のある、分離されたテスト環境が提供されます。 専用の物理ハードウェアを購入するのではなく、仮想マシンを既存のハードウェア上に作成できます。 各仮想マシンは独立していて、他のすべてのサーバーから分離されているため、プログラマは、ソフトウェアが他のアプリケーションに影響したり、外部コンポーネントがアプリケーションのコードの実行に影響することを気にせずに、ソフトウェアを実行できます。 |
|
統合 |
慣例では、単一のアプリケーションに個別のコンピュータが割り当てられます。 いくつかのアプリケーションで少量の処理能力しか使用しない場合、管理者は複数の仮想環境を実行する1つのサーバーにいくつかのコンピュータを統合できます。 数百または数千のサーバーを所有する組織では、統合により、フロア・スペース、暖房、換気、空調、AC電源、およびコロケーション・リソースの必要性を激減させることができます。 これは、所有コストが激減することを意味し、物理サーバー数やフロアおよびラックのスペースの必要量が減少することで、熱および電力の消費が減少し、最終的には二酸化炭素排出量が減少します。 |
|
稼働時間の最大化 |
できる限り迅速かつ柔軟に要件の変更に対応できるようにするには、アジリティがすべてです。 仮想化はデータ・センター管理に新しい機会をもたらし、ユーザーは次の利点を享受できます。
|
|
サーバー障害からのアプリケーションの自動保護 |
サーバー仮想化は、追加のハードウェアを購入することなく冗長性を実現する1つの方法です。 複数のサーバーで同じアプリケーションを実行するという意味において、冗長性は安全対策であり、なんらかの理由でサーバーに障害が発生した場合、同じアプリケーションを実行している別のサーバーが引き継ぐことによってサービスの中断を最小限にします。 この種の冗長性は、仮想マシンに適用される場合に、次の2つの方法で機能します。
|
|
必要性の変更に応じたワークロードの簡単な移行 |
移行とは、サーバー環境を1つの場所から別の場所に移動することを指します。 ほとんどの仮想化ソリューションでは、仮想マシンを環境内の1つの物理マシンから別のマシンに移動できます。 物理サーバーでは、これは当初は、両方の物理マシンが同じハードウェア、オペレーティング・システム、およびプロセッサで動作していた場合のみ可能でした。 仮想世界では、サーバーをまったく異なるハードウェア構成の物理ホスト間で移行できます。 通常、移行は、信頼性と可用性を向上させるために使用し、ハードウェア障害の発生時に、ゲスト・システムを、停止時間が制限されている正常なサーバーに移動できます(存在する場合)。 また、仮想マシンが現在のホストの物理機能を超えて拡張する必要があり、よりパフォーマンスの高い物理ハードウェアへ再配置する必要がある場合にも役に立ちます。 |
|
既存のレガシー・システムへの投資保護 |
サーバー・ハードウェアは最終的には使用されなくなりますが、1つのシステムから別のシステムへの切り替えが困難な場合があります。 このようなレガシー・システムで提供されていたサービスを提供し続けるには、これを最新のハードウェア上で仮想マシンとして実行することで、レガシー・システム自体が同じレガシー・ハードウェアで動作しているかのように引き続き動作させることができます。 アプリケーションの観点からは何も変更されていません。 実際、そのパフォーマンスは、より新しい基礎となるハードウェアから、十分な恩恵を受けることになります。 これによって組織は、ハードウェアの問題、特にレガシー・ハードウェアのメーカーがもう存在しないか、故障した機器を修理できない状況について気にすることなく、新しいプロセスに移行する時間が得られます。 |
1.3 ハイパーバイザとは
仮想化の定義を、単一の ホスト・コンピュータで複数のオペレーティング・システムを実行可能にすることとした場合、仮想化スタックの必須コンポーネントはハイパーバイザです。 このハイパーバイザは、仮想マシン・モニター(VMM)とも呼ばれ、複数のゲスト・オペレーティング・システムが実行および監視される仮想プラットフォームをホスト・コンピュータ上に作成します。 このように、複数のオペレーティング・システムは、同じオペレーティング・システムの複数のインスタンス、または異なるオペレーティング・システムのいずれの場合でも、ホストによって提供されるハードウェア・リソースを共有できます。
表1.2「ハイパーバイザのタイプ」に示すように、通常、ハイパーバイザはこれら2つのタイプのいずれかに分類されます。
|
分類 |
特徴と説明 |
|---|---|
|
タイプ1: ネイティブまたはベア・メタル |
ネイティブのハイパーバイザは、ホストのハードウェアで直接動作するソフトウェア・システムであり、ハードウェアを制御したり、ゲスト・オペレーティング・システムを監視します。 したがって、ゲスト・オペレーティング・システムは、ハイパーバイザより上の別のレベルで動作します。 仮想マシン・アーキテクチャのこの従来の実装の例は、Oracle VM、Microsoft Hyper-V、VMware ESX、およびXenです。 |
|
タイプ2: ホスト型 |
ホスト型ハイパーバイザは、従来のオペレーティング・システム内で動作するように設計されています。 つまり、ホスト型ハイパーバイザはホスト・オペレーティング・システムの上部に個別のソフトウェア・レイヤーを追加し、ゲスト・オペレーティング・システムはハードウェア上の第3のソフトウェア・レベルになります。 ホスト型ハイパーバイザの有名な例は、Oracle VM VirtualBoxです。 他に、VMware Server、VMware Workstation、Microsoft Virtual PC、KVM、QEMU、Parallelsなどがあります。 |