今日の仮想化は重要な役割を果たしています。消費者レベルのデスクトップの使用からエンタープライズレベルのクラウドサービスまで、さまざまなアプリケーションがあります。
このガイドは、包括的な方法で仮想化を開始するのに役立ちます。これにより、学生、エンジニア、さらにはCTOとして、さまざまな種類の仮想化と、それが今日の業界でどのように使用されているかを理解するのに十分な基本的な知識が得られます。
これは巨大な記事なので、ここで話したいことを要約しましょう。
- 最初のパートでは、ホストOS、仮想マシン（VM）、ハイパーバイザーについて紹介します
- 第2部では、仮想化の重要なコンポーネントであるCPU、RAM、ネットワーク、ストレージについて説明します
- 第3部では、仮想化のメリットに光を当てます
始めましょう！
仮想マシン、ホスト、ハイパーバイザー
仮想マシン、ホスト、ハイパーバイザーをよりよく理解するには、ハードウェアの基礎から始めることが不可欠です。
まず、システム全体を構成する次のコンポーネントを含む物理マシン/サーバーが必要です。
- 電源ユニット（PSU）
- マザーボード
- 中央処理装置（CPU）
- ランダムアクセスメモリ（RAM）
- ネットワークインターフェイスカード（NIC）
- ストレージ-ハードディスクドライブ（HDD）またはソリッドステートドライブ（SSD）
これらのコンポーネントはすべて一緒に組み立てられ、単一のコンピューティングユニットとして同期して独自のパーソナルコンピュータ（PC）またはサーバーになります。待ってください、パーソナルサーバーは面白そうですね！
オペレーティングシステム（OS）とは何ですか？
オペレーティングシステムは、グラフィカルユーザーインターフェイスの有無にかかわらず、さまざまなアプリケーションを実行するためのユーザーとコンピューター間のインターフェイスとして機能するシステムソフトウェアです。これらのアプリケーションの1つは、たとえばVirtualBoxなどの専用の仮想化プログラムにすることができます。
ハイパーバイザーとは何ですか？
ハイパーバイザーは、コンピューターのハードウェアと仮想マシンの間の仲介役として機能するシステムソフトウェアです。物理ホスト上で個別に動作するそれぞれの仮想マシンで使用されるハードウェアリソースを効果的に割り当てて利用する責任があります。このため、ハイパーバイザーは仮想マシンマネージャーとも呼ばれます。
このシステムソフトウェアは、グラフィカルユーザーインターフェイスの有無にかかわらず、仮想化を唯一の目的として、ユーザーとコンピューター間のインターフェイスとして機能します。そのようなハイパーバイザーの例は、VMwareFXIです。
ハイパーバイザーは、次の3つの主要モジュールで構成されています。
ディスパッチャ —モニターのエントリポイントを構成し、仮想マシンインスタンスによって発行された命令を、以下で説明するアロケータモジュールまたはインタプリタモジュールのいずれかに再ルーティングします。
アロケータ —仮想マシンが、関連付けられたマシンリソースを変更する命令を実行しようとすると、ディスパッチャによってアロケータが呼び出され、ディスパッチャは、仮想マシンに提供されるシステムリソースを割り当てます。
通訳 —仮想マシンが特権命令を実行するたびに実行されるインタプリタルーチンで構成されます。これは、ディスパッチャによっても呼び出されます。
物理ホストサーバー/コンピューターと対話するためのインターフェイスとして機能するオペレーティングシステムまたはハイパーバイザーのいずれかをインストールする必要があります。
さまざまなアプリケーションをホストまたは実行できるUbuntuサーバーであると仮定しましょう。サーバー上のこれらのアプリケーションは、オペレーティングシステム内で実行されます。
ハードウェアを利用することで、Ubuntuはハードウェアとアクセスできるリソースの量を制御できます。
したがって、オペレーティングシステムまたはハイパーバイザーは、アプリケーションとハードウェア自体の間の仲介役になります。
仮想マシン（VM）とは何ですか？
仮想マシンは、物理サーバーのすべての機能をエミュレートし、ホストオペレーティングシステムまたはハイパーバイザー上で実行されるソフトウェアです。
したがって、物理システム上でアプリケーションを直接実行することはありません。これらは、それぞれが独自の独立したオペレーティングシステムを備えた仮想マシンで実行されます。このようにして、仮想マシンは同じ物理システム内で個別に異なるオペレーティングシステムを実行できます。
このようなすべてのVMは、物理ハードウェアの共通セットを共有でき、物理コンピューターと同じように、仮想ネットワークを介して相互に対話することもできます。
それぞれが独自の独立したオペレーティングシステムを備え、前述と同じ物理コンポーネントを共有および利用する多数の仮想マシンを使用できます。
ハイパーバイザー、またはオペレーティングシステム上で実行されている仮想化ソフトウェアは、実際には物理リソースを制御しているものです。
ハイパーバイザーは物理ハードウェアに直接アクセスでき、仮想マシンがアクセスできるリソースを制御します。
これには以下が含まれます：
- 割り当てられるメモリ（RAM）の量
- 取得する物理CPUアクセスの量
- ネットワークへのアクセス方法
- ストレージへのアクセス方法
OS仮想化ソフトウェア（OSVSに切り詰めましょう）またはハイパーバイザーで作成される仮想マシンが増えるにつれて、それらはまったく同じ物理リソースのセットも共有します。
したがって、OSVSまたはハイパーバイザーは以下を制御します：
- リソースが個々の仮想マシンに共有される方法
- リソースが個々の仮想マシンにどのように提示されるか
それでは、ハイパーバイザーの種類とそれらの違いを見てみましょう。
物理ホストにネイティブにインストールして直接実行できるハイパーバイザーは、タイプ1ハイパーバイザーと呼ばれます。
キーポインタ
- タイプ1ハイパーバイザーは、ベアメタルシステムまたは物理ホストに直接インストールできます。
- サーバーに自身をデプロイするために、最初にオペレーティングシステム（OS）をインストールしたり利用したりする必要はありません。
- CPU、メモリ、ネットワーク、物理ストレージへの直接アクセス。
- ハードウェアの利用はより効率的で、最高のパフォーマンスを提供します。
- ハードウェアアクセス用の追加レイヤーがないため、セキュリティが向上します。
- 各タイプ1ハイパーバイザーには、常に専用の物理マシンが必要です。
- より多くの費用がかかり、エンタープライズグレードのソリューションに適しています。
- VMware ESXi、Citrixハイパーバイザー、およびMicrosoft Hyper-Vは、タイプ1ハイパーバイザーの例です。
ネイティブにインストールできず、オペレーティングシステムを物理ホストで実行する必要があるハイパーバイザーは、タイプ2ハイパーバイザーと呼ばれます。
キーポインタ
- タイプ2ハイパーバイザーは、ベアメタルシステムまたは物理ホストに直接インストールすることはできません。
- それ自体を展開するには、最初にオペレーティングシステムをインストールするか利用可能にする必要があります。
- CPU、メモリ、ネットワーク、物理ストレージへの間接アクセス。
- リソースにアクセスするための余分なレイヤー（OS）があるため、ハードウェアの使用率が低下し、パフォーマンスが低下する可能性があります。
- ホストオペレーティングシステムの可用性による潜在的なセキュリティリスク。
- 各タイプ2ハイパーバイザーは、専用の物理マシンを必要としません。 1つのホストに多数存在する可能性があります。
- コストを抑え、中小企業向けソリューションに適しています。
- VMware Workstation Player、VMware Workstation Pro、VirtualBoxは、タイプ2ハイパーバイザーの例です。
ここで、仮想マシンを構成するファイルと、それらが共有ストレージをどのように活用するかを理解しましょう。
仮想マシンは、物理ホストのメモリ、CPU、ネットワーク、およびストレージハードウェアを活用します。どのように行われていますか？
ハイパーバイザーを介して。
仮想マシンが実行されているとき、メモリ内に特定の情報があります。この情報は、VMのライブ状態の一部です。
したがって、VMは実際にはホスト上で動作しています。ビデオを再生したり、VMでWebブラウザーを開いたりするたびに、これらのランタイム操作はVMのメモリで発生します。しかし、これらは実際にはすべて物理ホストで発生しています。これは、仮想マシンのライブ状態です。
仮想マシンのライブ状態は、CPUですべてのランタイム実行を処理するため、ホストで実行されます。
ブラウザを開いてWebサイトをロードすると、ネットワーク帯域幅は、物理ホストの一部でもあるNICを通過します。これはすべて、ストレージアダプターを利用してデータトラフィックをストレージデバイスに送信するVMのライブ状態の一部です。繰り返しになりますが、ホスト上でリアルタイムにライブで発生します。
仮想マシンには物理ハードディスクはありません。 Linuxを仮想マシンで実行している場合は、物理ドライブとの間でデータを読み書きする機能が必要です。
これは、物理ディスクへのアクセスが必要であることを意味します。 VMは、仮想的に割り当てられたドライブとの間で読み取りと実行を行っています。しかし、操作は実際にはどこかの物理ストレージデバイスにリダイレクトされています。ファイバチャネルネットワーク、イーサネットネットワーク、またはローカルディスク自体にまたがって、ハイパーバイザーまたはオペレーティングシステム仮想化ソフトウェアの内部にある可能性があります。
仮想マシンは、仮想化管理のために一連のファイルを使用する必要があります。これらのファイルの1つは、仮想的に割り当てられたドライブまたは仮想ディスクを表します。 VMは、これらのファイルを介して仮想ディスクからの読み取りまたは仮想ディスクへの書き込みを行う必要があります。データトラフィックは、それを実現するためにストレージアダプタを通過します。
明らかな理由で、ハードディスク上の同じ物理的な場所に保存されている他の仮想マシンに対応するそのようなファイルの多くが存在する可能性があります。
次に、仮想マシンをシャットダウンして再起動する方法について説明します。
これを実行できるようにするには、VMには、主にライブ状態で構成される構成情報が必要です。
- VMはどのくらいのメモリを取得することになっていますか？
- どのくらいのCPUを取得する必要がありますか？
- 割り当てられたディスクサイズはどれくらいですか？
- VMはどのようにネットワークにアクセスしますか？
繰り返しになりますが、この情報はすべてファイルに保存されます。
完全な機能を確保するために、仮想マシンファイルに保存されているすべての種類の情報を登録します。
- 静的または動的ストレージ
- 構成情報
- BIOS情報
- 撮影したスナップショット
したがって、仮想マシンは2種類の状態を格納します。
ライブ状態は、リアルタイムで起こっていることであり、先ほど説明したように、次のようになります。
- 現在使用されているメモリの量
- 使用されているCPUの量
- 現在使用されているアプリケーション
- ネットワーク帯域幅がどのように使用またはトラバースされているか
物理ホストまたはその中の仮想マシンに障害が発生すると、上記のリアルタイム情報がすべて失われます。これは、コンピューターのプラグを抜くのと似ています。
永続状態は、永続的に保存されるその仮想マシンのファイルです。それは次の方法で可能になります：
- ストレージファイル
- 構成ファイル
- スナップショットファイル
永続状態に関連するファイルがVMを構成します。
私たち人間が適切な栄養なしでは生き残れないように、仮想マシンも一貫してリソースを適切に割り当てる必要があります。これらのリソースが不足しているということは、仮想マシンが最高のパフォーマンスを発揮できないことを意味します。
VMが最高のパフォーマンスを達成できない4つの重要事項は次のとおりです。
- CPU
- RAM
- ネットワーク
- ストレージ
CPU仮想化
仮想マシンはどのようにして物理ホストのCPUリソースにアクセスしますか？
物理ホストには物理CPUがあります。たとえば、4つの物理コアを備えたCPUがあるとします。これらの物理コアを2つ割り当てる場合は、仮想マシンの作成を開始するときに、2つの仮想CPUを割り当てることになります。つまり、仮想マシンは、2つの仮想CPUでVMを作成することにより、メインCPUから2つの物理プロセッサコアにアクセスできます。
ただし、この割り当ては、他の仮想マシンがこれらのコアを活用できないことを意味するわけではありません。つまり、4つのコアすべてを別の仮想マシンに割り当てることができます。したがって、最終的に、これらのリソースは、ハイパーバイザーまたはオペレーティングシステム仮想化ソフトウェア上のすべての仮想マシンで共有できます。
ワークロードのタイプに応じて、仮想マシンの必要性に基づいてCPUコアを割り当てる必要があります。もちろん、VMに25％のCPU使用率で問題がない場合は、残りのリソースを他のVMに割り当てることができます。
したがって、特にCPUリソースに関しては、アプリケーション要件に基づいて仮想マシンのサイズを常に適切に設定するように常に努力する必要があります。
ここで、仮想マシンがハイパーバイザーのメモリリソースをどのように利用できるかを理解しましょう。
仮想マシンに割り当てることができるメモリの量は、物理サーバーにある物理メモリ（RAM）に基づいています。
たとえば、サーバーに8 GBのRAMがある場合、4 GBを割り当てて、仮想マシンで本格的なUbuntuデスクトップを実行できます。 Ubuntuデスクトップは、4GBの物理メモリがあると「考え」ています。しかし実際に起こることは、この割り当てられたメモリが実際の8GBの物理メモリ自体からマップされることです。
4 GBをVMに割り当てると、割り当てられた量を超えるメモリを使用できなくなります。
CPUと同様に、この4GBが常にVM専用であることを意味するわけではありません。このVMで実行されているアプリケーションが現在これほど多くのメモリを必要としない場合、別のVMが必要に応じて同じリソースを使用できます。
アプリケーションがVMで実行されると、（VM上の）オペレーティングシステムは独自のメモリテーブルに基づいてメモリを割り当て、VMで閉じられると、OSはそれらのメモリページを空きとしてマークします。ただし、ハイパーバイザーや仮想化ソフトウェアの存在を「認識」することはないため、この割り当て解除について物理サーバーに通知することはありません。
したがって、ハイパーバイザーまたは仮想化ソフトウェアの仕事は、VMのオペレーティングシステムの内部を監視し続けて、これらの割り当てを監視し、メモリの未使用部分を他のVMに時々割り当てることです。
仮想マシン間でのメモリ割り当てのこの共有された側面とは対照的に、特定のVMにメモリ予約を適用して、物理メモリの特定の部分を使用することもできます。つまり、他のVMは、メモリ予約済みVMによって使用されていなくても、予約済みメモリを使用できません。一般的に、メモリを共有することで1日の終わりにリソースを効果的に利用できるため、この手順は避けるのが最善です。
これを、Linodeを介して提供される共有サーバーと専用サーバーに関連付けることができます。日常のシステム管理者の実践と本番環境でサーバーを共有する方が経済的です。
Ubuntu VMは、ハイパーバイザーまたは仮想化ソフトウェア上のホスト上で実行されます。この仮想マシンには、仮想NICV-NICと呼ばれるものがあります。これは、仮想ネットワークインターフェイスカードにまで拡張されます。
オペレーティングシステム（Ubuntu）は、仮想マシン内で実行されていることを認識していません。したがって、物理サーバーで実行されている場合と同じ種類のハードウェアがすべて表示されることを期待しています。
ネットワーク仮想化に関しては、仮想マシン、仮想ネットワークインターフェイスカードを提供する必要があります。
Ubuntuは実際にネットワークインターフェイスカード用のドライバーを実装しようとしています。ゲストオペレーティングシステムとして、それが実際には物理的なNICではないことはわかりません。
これは、仮想マシンに本物のように提示される偽のハードウェアである仮想NICです。したがって、物理NICを備えた物理サーバーがある場合は、イーサネットケーブルをイーサネットポートから物理スイッチに接続します。
仮想NICを備えた仮想マシンがある場合は、物理マシンで行うのと同じように、仮想スイッチのポートに接続します。
したがって、ハイパーバイザーまたは仮想化ソフトウェアの内部には、仮想スイッチと呼ばれるものがあります。この仮想スイッチに複数の仮想マシンを接続して、相互に通信することができます。
それらを同じVLAN（仮想ローカルエリアネットワーク）に配置する限り、他のタイプの物理スイッチを介して通信できるのと同じように、仮想スイッチを介して通信できるようになります。
したがって、単一のVMが仮想スイッチに接続されている場合は、2番目のVMを接続できます。これにより、あるVMから別のVMにその仮想スイッチ内で直接トラフィックを送信できます。これらの仮想マシンが同じVLAN上にある限り、このトラフィックはホストを離れる必要はありません。これらのVMが同じVLAN上にある限り、VMは通信でき、トラフィックが物理ネットワークを通過する必要はありません。
しかし、ここに重要なポイントがあります。一部のネットワークトラフィックは物理ネットワークを通過する必要があるため、仮想スイッチにはアップリンクが必要になります。
物理スイッチに上位レベルの物理スイッチまたは物理ルーターへのアップリンクがあるのと同様に、仮想スイッチにもアップリンクが必要です。これらのアップリンクは、ホスト上の実際の物理アダプターです。これらの物理アダプターは、P-NICまたは物理NICまたはVMNICと呼ばれます。
物理ネットワークインターフェイスカードまたはNICは、常にサーバー上の最新のマザーボードに統合されています。
ただし、必要に応じて、マザーボードに接続してネットワークを追加する専用のNICを選択することもできます。
ホスト上にハイパーバイザーを作成すると、他のサーバーと同じように、そのホストには1つ以上のネットワークインターフェイスカードがあります。
ホスト上のこれらの物理ネットワークインターフェイスカードは、物理スイッチに接続し、その物理スイッチはルーターに接続します。これは、インターネットにトラフィックを送る方法です。
このメカニズムにより、同じデータセンター内にある他の物理サーバーに接続することもできます。
したがって、仮想マシンは、同じ物理サーバー内または同じ物理サーバー内でこれらすべてのコンポーネントと通信できます。
トラフィックが実際にホストを離れてホストの外部と通信し、ルーターに到達して別のVLANまたは別のネットワークに到達する必要がある場合、そのトラフィックはVMから流出します。
仮想スイッチを介して、仮想スイッチの1つが物理ネットワークに向かってアップリンクします。
そのトラフィックが物理スイッチに到着すると、MACテーブルルックアップ（一意の物理アドレスのレコード）を実行します。
それは、そのパケットが行く必要がある適切な宛先に向けて適切なポートを提供します。インターネットまたはローカルネットワーク上の物理ホストに向かう可能性があります。
ただし、このメカニズムにより、すべての仮想マシンが物理ネットワーク上のすべてのデバイスと通信できるようになります。これは、仮想スイッチが行うことです。
ここでの基本的な考え方は、VM上のゲストオペレーティングシステムをだまして、物理ネットワークインターフェイスカードを持っていると「考えさせる」ことです。したがって、Ubuntuに同じドライバーを提供すると、実際のハードウェアデバイスがあると見なされます。
データパケットが送信されると、トラフィックは実際にハイパーバイザーによってフェッチされ、指示に従って適切な仮想スイッチに向けられます。
VMがCPU、メモリ、ネットワークをどのように活用するかについて学習したので、最後のリソースであるストレージに進みましょう。
繰り返しになりますが、ゲストオペレーティングシステムは、仮想マシン内で実行されていることを認識していません。 VMには専用の物理ハードウェアがなく、ストレージディスクが含まれています。 VMには専用の物理ディスクがありません。
ネットワーキングでは、仮想NICがありました。
ストレージの仮想化では、物理サーバーが内蔵ハードドライブとどのように連携するかを考えると、仮想SCSIコントローラーが必要になります。オペレーティングシステムが何らかのデータをディスクに書き込む必要がある場合、オペレーティングシステムはSCSIコマンドを生成します。
ディスクからデータを読み取る必要がある場合は、SCSIコマンドを生成し、そのコマンドを物理ディスクとインターフェイスするSCSIコントローラーに送信します。これがUbuntuがストレージを操作する方法であり、ここで仮想マシン内で実行されていることを認識していません。
したがって、ストレージメカニズムのゲストオペレーティングシステムについても、その幻想を維持する必要があります。
したがって、Linux（VM上で実行）に仮想SCSIコントローラーを提供します。実際の物理ディスクを実行しているかのようにエミュレートします。
したがって、Ubuntuが何らかのストレージコマンドを実行する必要がある場合、実際のSCSIコントローラーがあると見なされます。
ストレージコマンドがSCSIコントローラーに送信されると、実際に発生するのは、仮想SCSIコントローラー（仮想デバイス）がそれらをハイパーバイザーにリダイレクトすることです。仮想マシンは、仮想SCSIコントローラーを介してこれらのストレージコマンドを送信し、ハイパーバイザーに到達します。
ハイパーバイザーは、ここからこれらのストレージコマンドに何が起こるかを決定します。仮想マシンがローカルディスク上に独自のVMDKまたは仮想ディスクファイルを持っている場合、それらのストレージコマンドをローカルハードドライブ上のそのファイルに送信するだけです。
この最も基本的な機能とは別に、
- ファイバチャネルストレージアレイ
- イーサネットベースのiSCSIストレージアレイ
- イーサネット経由のファイバチャネル
しかし、それらはすべて同じように機能します。
異なるのは実際にはネットワークです。
ハイパーバイザーがそのストレージコマンドをファイバーチャネルに送信すると、そのストレージコマンドは、最終的に仮想ディスクに到達するまで、そのファイバーチャネルネットワークを通過します。
ハイパーバイザーに関係なく、仮想マシンには仮想ディスクがあります。
これが、仮想ディスクの場所に関係なく、SCSIコマンドが仮想マシンから仮想ディスクに到達する方法です。
Ubuntuベースの仮想マシンがSCSIコマンドを生成すると、それを仮想SCSIコントローラーに送信します。
ハイパーバイザーはその仮想ディスクの適切な場所を決定し、それをストレージアダプターに送信し、ストレージコマンドがデータストアに到着します。
これらのデータトラバーサルの変更は、実際には仮想マシンの仮想ディスクを含むファイルに書き込まれます。 .VMX、.VMDK、またはその他の仮想ファイルタイプである可能性があります。
これで、ネットワークとストレージの仮想化の基本を理解できたと思います。仮想化の効率とモビリティのメリットと、物理ホストを仮想マシンに変換する方法について説明します。
これまで、さまざまなリソース管理モードで仮想化が基本的にどのように機能するかについて説明してきました。それでは、多くの主なメリットについて説明しましょう。
まず、効率について話しましょう。
仮想インフラストラクチャを体育館と比較すると、これを以前に経験したことがある人もいるかもしれません。
1月1日頃にジムに通う人なら、ジムはとても忙しくなり始めます。
年間の通常の期間には、約20台のトレッドミルと50台のエクササイズマシンを備えたジムで十分です。
しかし、ジムの所有者であれば、1月になると、2〜3倍の人数になり、環境のサイズを3倍にすると生産性が向上することをご存知でしょう。
それらすべての人々が、ええ、たぶん彼らはあまり運動するのが好きではないことに気づいたとき、彼らはジムの使用をやめます。
今後は、必要に応じてジムのサイズを小さくすることができます。
これは、仮想データセンターのハードウェアでも同じことができるとしたら、本当に素晴らしいことです。
仮想化を扱うとき、それはクラウドコンピューティングのアイデアをもたらします。たとえば、Linodeのようなベンダーやサービスプロバイダーがあります。これを使用すると、他の誰かのハードウェア上に多数の一時的な仮想マシンを起動して、顧客の忙しい時期に対応できます。
しかし、最初に仮想化しないと、クラウドコンピューティングに実際に到達することはできません。これは、インフラストラクチャが急速に拡大または縮小する可能性がある、いわゆる弾力性のある状態に到達するためのパスに沿った最初のステップです。
仮想化は、そのような柔軟性に向けた構成要素です。ワークロードを統合する機能を提供します。
以下に、物理サーバーのデータセンターを示します。
ベストプラクティスとして、これらのサーバーのすべてが単一のオペレーティングシステムを実行しているべきではありません。
サーバーごとに1つだけではなく、これらのサーバーのすべてで20〜30のLinuxインスタンスを実行した場合に、さらに多くのワークロードを実行できるかどうかを考えてください。
これが仮想化の最大のメリットです。これが、このイノベーションを仮想化に駆り立てた最初のメリットです。統合です。
次の図では、環境内で個別の物理システムとして使用できる、役割の異なる3つの異なるサーバーがあります。
すべてのリソースの20％を使用しているプリントサーバーがあり、同じことがWebサーバーとデータベースサーバーにも当てはまります。
これらは、実際にはすべてのリソースを使用していない物理サーバーです。考えてみれば、そのすべてのハードウェアにお金を払っています。使用しているのが20％しかない場合は、80％を無駄にしています。
1つのオペレーティングシステムしか実行できない物理ホスト上でリソースを座礁させることにより、この問題に対処するための2つの選択肢があります。
サーバーに他のアプリケーションのインストールを開始し、同じサーバーで複数のアプリケーションを実行することができます。ただし、プリントサーバーを再起動する必要がある場合は、そのプリントサーバーで他に何が実行されているかを気にする必要がありますか？
プリントサーバーのメンテナンスを行うことで、他に何に影響を与えることができますか？同じハードウェア上で相互に依存するアプリケーションのユースケースとシナリオが多すぎるため、効率が大幅に低下します。
したがって、ほとんどの場合、最終的にはリソースの浪費になります。代わりに、これらの物理サーバーを取り除き、ハイパーバイザーでこれらのワークロードを統合することができます：
この統合により、そのハイパーバイザーで複数のオペレーティングシステムインスタンスを実行できるようになりました。これで、リソース使用率が60％または70％になる可能性のあるスイートスポットを非常に簡単かつ効率的に最大化、サイズ変更、およびヒットできます。
これで、購入したリソースを効率的に使用できますが、リソースに負担をかけることはありません。
これが仮想化の究極の目標です。使用されることのないリソースに余分な資本を浪費することなく、製造されたハードウェアへの投資を最大化することです。
仮想化のもう1つの大きな利点は、モビリティです。
ネットワークとストレージの仮想化がどのように機能するかを思い出せる場合は、ここでファイバーチャネルストレージアレイがあるシナリオを考えてみてください。また、新しいiSCSIストレージアレイに投資したばかりだと考えてみましょう。
ここで、ファイバーチャネルストレージアレイがあり、この仮想マシンとそのすべてのファイルを、別のネットワーク上にある新しいiSCSIストレージデバイスに再配置するとします。
イーサネットネットワーク上にあるとしましょう。これで、ハイパーバイザーまたは仮想化ソフトウェアを使用して簡単に再配置できます。 SCSIコマンドがVMから出力されると、ハイパーバイザーによって受信されます。別のストレージアダプタを使用してこのVMSファイルを別のストレージアレイに再配置すると、ハイパーバイザーはその変更が行われたことを認識します。
これらのストレージコマンドを新しい場所にリダイレクトするだけで、仮想マシンのダウンタイムなしでこれを実行できるという利点もあります。
別のシナリオを見てみましょう。
複数のホストがあり、Linux VMを使用して、VMのライブ状態を別のホストに再配置することを選択したとします。他のホストが共有ストレージに接続できる限り、これも機能します。 VMは、引き続き仮想ディスクと、必要な他のすべての重要なVMファイルにアクセスできます。
これが、ストレージ、仮想化、共有ストレージがモビリティの実現にどのように役立つかです。仮想マシンを取得して別のホストに移動し、ダウンタイムなしでファイルをあるストレージシステムから別のストレージシステムに移動できます。
これはすべて、仮想マシンとハードウェアの間にハイパーバイザーが介在しているためです。
これは、一般にデカップリングとして知られているものです。これは、仮想マシンがどのハードウェアとも直接の関係を持たないことを意味します。ある物理サーバーから別の物理サーバーに移動できます。あるストレージシステムから別のストレージシステムに移動することもできます。仮想マシンと特定のハードウェアの間に固定された関係はありません。それらは、用語の本当の意味で分離されています。
したがって、ご覧のとおり、モビリティは仮想化の大きなメリットです。
別の見方：
複数のホストがあり、これらすべてのホストで多数の仮想マシンが実行されていて、ワークロードが希望どおりにバランスが取れていないとします。
ホスト1で3つの仮想マシンを実行している場合は、それらのVMSの一部をホスト2に移行して、これら2つのホストのワークロードを均等化することをお勧めします。
ホストのリソース使用率が常にかなり均等に使用されていることを確認する必要があります。
ホスト1のメモリが非常に少なくなっている場合は、一部のVMを他のホストに移動できます。理想的には、ダウンタイムなしでそれを実行する必要があります。
ライブマイグレーションを実行し、実行中のVMを取得して、ダウンタイムなしで1つの物理サーバーから別の物理サーバーに移動できます。これが、VMを移行する重要な理由の1つです。
もう1つの理由は、あらゆる種類のメンテナンスアクティビティを実行する必要がある場合でもあります。たとえば、物理メモリをインストールして、別のホストまたは他の形式の物理メンテナンスを追加できます。
これは、ホストでダウンタイムが発生することを意味します。これを防ぐには、すべてのVMを別のホストに移行したり、メンテナンスを実行したり、メモリをインストールしたり、パッチをインストールしたり、必要な再起動を実行したりすることができます。そのホストからすべてのVMを移行し、必要なことをすべて実行して、ホストがバックアップされたらそれらを元に戻すことができます。これはすべて、ユーザーを混乱させることなく実行できます。
これがどのように行われるか：
移行の例を見てみましょう。ここで、パッチを適用する仮想マシンがホスト上で実行されているとします。このホストも再起動する必要があります。
したがって、このVMのホスト1からホスト2への移行を開始する必要があります。
ただし、いくつかの前提条件があります：
- 共有ストレージ
- 仮想ディスクファイル
- 構成ファイル
- 仮想NIC
- スナップショット
これは、ネットワークアクセスがあり、仮想ネックが仮想スイッチに接続されており、VLANで使用できるVMです。
仮想スイッチは物理スイッチに接続されており、それに応じて仮想マシンがアドレス指定されます。
このVMは、仮想スイッチにポートグループがあるVLANに存在します。このVMを別のホストに移動し、そこに一致する構成がない仮想スイッチがある場合、そのネットワークは使用できなくなります。
あなたはそれを望まない。
したがって、これらのホストの両方に互換性のあるネットワークがあることを確認する必要があります。
簡単に言うと、移行されたVMがホスト2を移動するときに何も変わらないようにし、ホスト1にあるのと同じように互換性のあるプロセッサが必要です。
ホスト1でIntelの場合は、ホスト2でAMDと互換性を持たせる必要があります。
これらの2つのホストは、可能な限り同一にする必要があります。
ネットワークとストレージの構成に関しては、明らかに一致している必要があります。
最後に、ホスト1からホスト2への転送を実行する方法が必要です。したがって、メモリのすべてのコンテンツを取得し、現在のVMで現在発生していることを取得して、他のホストにそのコピーを作成する特別なネットワークを作成します。
私の前提条件を満たしたら、残りの部分は非常に簡単です。
この場合、宛先ホストで作成されるVMのコピーを作成します。
VMwareの用語に基づいて、VMカーネルポートと呼ばれるものを使用してネットワークを作成し、そのネットワークを使用して、宛先ホストに現在のVMのコピーを作成します。
そのコピーが完了すると、そのコピープロセス中にそのVMで変更されたすべてのものをキャプチャします。これをメモリビットマップと呼びます。
このメモリビットマップのすべてのコンテンツがVMの新しいコピーに転送され、それが実際に実行されている仮想マシンになります。
ダウンタイムはごくわずかであるため、アプリケーションのユーザーには認識されません。これは、仮想マシンが実行され、あるホストから別のホストに移動されている間の、仮想マシンのライブマイグレーションと呼ばれます。
This facilitates amazing flexibility, because you can move VMs wherever you need to.
Another notable advantage is automated load balancing.
You can group together hosts in what's called a cluster. Once you group those together, what you would now want is to allow your virtual machines to efficiently make use of the resources of the cluster as a whole.
You'll want to consider all of these hosts are interchangeable. It doesn't matter which host your VMs run on. If VMs need to move around to equalize workload, you can definitely make that to happen automatically.
That's the purpose of automatic load bouncing in VMware terminology.
This is also called distributed resource scheduler, in order to allow virtual machines to automatically be live migrated from host to host for the purposes of load balancing across themselves.
Converting physical servers to VMs
In this section, you'll learn about some concepts required to convert a physical machine to a virtual machine.
There are different software options out there to accomplish that.
Let's say you have a physical server with Ubuntu installed on it. It has all kinds of physical hardware like CPUs, RAM and network adapters and storage disks.
Our Ubuntu operating system has drivers for devices such as network adapters. It knows what kind of CPUs are being used:be it AMD or Intel CPUs. It has got a SCSI controller to connect to physical disks and the operating system is also aware of the actual physical hardware.
When we take this physical server and use one of our software tools to convert it to a virtual machine, the first step that happens is that virtual machine is created as virtual replica of the physical machine.
You're going to have a virtual machine present your hypervisor with the appropriate CPU, memory, network and storage specifications. It might not exactly match up with what we had in the physical server.
When you create a virtual machine, your goal should always be to rightsize that virtual machine. It's never to just take what the physical server had and duplicate it. The goal is always to right size it to give the virtual machine the correct resources that it needs to do its job (efficiently run applications) and nothing extra.
You'd want your resource consumption to be about 60, 70 percent utilization for CPU and the same for memory. You don't want them unutilized at 10 percent with four CPUs. That's not efficient.
You're also going to need a physical NIC, for the virtual machine and this is going to be a hardware change for the guest operating system.
So what would be most ideal to have is a network interface card that was specifically designed to run on a virtual machine, a good example of this is the VMware VMAX.
The beautiful thing about this, is that now the virtual machine has no relationship with actual physical hardware, so we get mobility by breaking out of specific hardware dependency everytime.
Other benefit that is often overlooked is the fact that as you virtualize, all of your OS instances(Linux/Mac/Windows) are going to have a similar set of virtual hardware. It allows you to standardize your operating system configuration.
You replace our physical hardware with virtual hardware and your physical hard disk with a virtual disk.
This is a file that could be on a local storage of the host, it could be on:
- a fibre channel
- a SCSI storage array
- an NFS server
What's most important is that you create this virtual disk and migrate all of the data from the source virtual machine to the virtual disk. When the power's on, it's got its new hardware with its new disk. From this point on, it should just work.
That's how you convert a physical server to a virtual machine.
Depending on which hypervisor you're using:
- VMware has vCenter converter
- Microsoft has VM converter
- Veeam has disk to VHD
You can start using these solutions on your existing physical servers, convert them to virtual machines and run them on your hypervisor. Helder has shared some tips on building homelab which is a good way to experiment.
Hope you found this detailed introduction to virtualization helpful. Please leave any feedback if you have in the comment section below. Thank you.