5種類のサーバー仮想化を理解する

仮想化により、ネットワーク、ストレージ、コンピューティング リソースが抽象化され、アプリケーション、サービス、機能の物理ハードウェアへの依存度が低下します。 IT 管理者は、同じ基盤リソース上で実行されている他のワークロードによる問題の影響を受けにくい独自の環境 (オペレーティング システム、サポート ソフトウェア、ネットワーク、ストレージ リソースを含む) でアプリケーション、サービス、機能を提供できます。あるいは、リソースを共有してコストを削減し、全体的な使用率とパフォーマンスを向上させることもできます。

[[402411]]

標準的なサーバーベースの仮想化 (IBM の長年のメインフレーム仮想化機能を除く) の初期の頃から、管理者は、オペレーティング システムの完全なコピー、すべてのサポート ソフトウェア、ネットワーク インターフェイス カードなどのエミュレートされたシステムなど、ワークロードを実行するために必要なすべてのものを含む仮想マシンを作成してきました。一部の IT 部門は、コンテナ化などの小規模なアプローチに移行しています。コンテナ化では、ワークロードが単一のパッケージに最小化され、仮想化されたリソース上に配置され、オペレーティング システムの機能を共有します。

コンピューティング リソースの仮想化は、ハードウェア ベースの仮想化、ハイパーバイザー、ソフトウェア ベースの仮想化など、さまざまな方法で行われます。したがって、管理者は仮想化アプローチを慎重に選択する必要があります。

ハードウェア仮想化

この場合、システムは CPU の一部をさまざまなワークロードに割り当てることで仮想化を実現します。これは IBM Power アーキテクチャの重要な側面であり、コアの一部または全体を分割してワークロード専用のプラットフォームを作成し、必要に応じて追加のリソースを動的に割り当てることができます。この方法では、さまざまなワークロードに、ワークロードの必要に応じてスケールアップおよびスケールダウンできる専用の環境を提供できるため、単一のワークロードの誤動作が他のワークロードに影響を与えることはありません。

ハードウェア仮想化は、他のワークロードがアクセスできない専用リソースを提供することで、より高い可用性を必要とするワークロード (仮想プライベート ネットワークやウイルス対策エンジンなど) もサポートします。 Intel と AMD は、完全なハードウェア仮想化よりも、それぞれ Intel Virtualization Technology と AMD Virtualization によるハードウェア支援アプローチに重点を置いています。

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

ハードウェア支援による仮想化では、オペレーティング システムやその他のソフトウェアが大きな処理を実行しますが、パフォーマンスの低下を最小限に抑えながら最適化された仮想化を提供するには、ソフトウェアにハードウェア機能が必要です。 API は、アプリケーション層からの呼び出しをハードウェアに渡し、コード実行パスでの侵入的なエミュレーションと呼び出し処理の多くをバイパスします。

ハードウェア支援による仮想化は、一般的に、基盤となる利用可能な CPU と組み合わせたハイパーバイザベースの仮想化の機能であると考えられています。

ハイパーバイザベースの仮想化

ハイパーバイザーベースの仮想化は、エンタープライズ データ センターで最も一般的な仮想化形式です。タイプ 1 ハイパーバイザー (ベアメタル ハイパーバイザーとも呼ばれます) には、VMware vSphere/ESXi、Microsoft Hyper-V、Linux KVM などがあります。タイプ 1 ハイパーバイザーを使用すると、オペレーティング システムが実際に起動する前に仮想化が実行され、ホスト オペレーティング システムの複数のインスタンスがこのハイパーバイザー レイヤーを介して対話できる仮想化ハードウェア プラットフォームが作成されます。

タイプ 2 ハイパーバイザーは、ホスト型ハイパーバイザーとも呼ばれ、ホスト オペレーティング システムの上に配置されます。通常、サーバー仮想化方式とは対照的に、デスクトップでゲスト オペレーティング システムをサポートするために使用されます。タイプ 2 ハイパーバイザーの例には、Oracle VM VirtualBox、Parallels Desktop、VMware Fusion などがあります。

準仮想化

完全仮想化とは、仮想化環境内のワークロードが物理プラットフォーム上で直接実行されていないことを認識しないことを意味します。準仮想化では、少し異なるアプローチが採用されます。準仮想化ではハードウェア環境はエミュレートされません。各ワークロードは独自の分離されたドメインで実行されます。

Xen などの製品は完全仮想化と準仮想化の両方をサポートしており、Oracle VM for x86 および IBM LPAR は準仮想化レイヤーを認識し、ワークロードからハードウェアへの特権呼び出しなどの機能を最適化する修正されたオペレーティング システムを使用します。

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

オペレーティング システム レベルの仮想化 (コンテナ化とも呼ばれます) は、ここ数年で非常に人気が高まっています。コンテナ化により、異なるワークロードが相互に信頼しない方法で同じ基盤リソースを共有できるようになります。つまり、1 つのワークロードによって発生した問題は、同じ基盤リソースを共有する他のワークロードには影響しません。しかし、必ずしもそうとは限りません。 Docker の初期のインスタンスでは、1 つのコンテナからの特権呼び出しが物理環境に干渉し、コンテナ破損のドミノ効果を引き起こしていました。保護された基礎リソースへの特権呼び出しは、デフォルトで無効になりました。

ハードウェア支援による仮想化と同様に、エミュレーションなしで基盤となるオペレーティング システムに直接呼び出しが行われるため、パフォーマンスが最適化されます。 Docker の登場により、仮想化を提供するために使用されるリソースの量を最小限に抑えながら、ワークロードを簡単に作成して、あるプラットフォームから別のプラットフォームに移動できるようになりました。オペレーティング システム レベルの仮想化は多くのクラウド プラットフォームに組み込まれており、ほとんどの DevOps システムでサポートされています。オペレーティング システム レベルの仮想化を提供するその他のプラットフォームには、Linux Containers や IBM Workload Partitions for AIX などがあります。

クラウド プラットフォームでは、ハイパーバイザー ベースまたは OS レベルの仮想化を使用するか、ハイパーバイザー ベースのプラットフォーム上に OS レベルの仮想化機能をレイヤー化する傾向があります。

仮想化タイプの選択は、ゲスト OS をサポートする必要性、インストールおよび管理するワークロードの数、必要な全体的なパフォーマンス、および全体的なコストによって異なります。数百のオペレーティング システムで構成されるプラットフォーム全体を仮想化しようとすると、ライセンス料金が高額になる可能性があります。