テクニカルリファレンス
Red Hat Virtualization 環境の技術アーキテクチャー
概要
第1章 はじめに
1.1. Red Hat Virtualization Manager
Red Hat Virtualization Manager は、仮想化環境に一元管理を提供します。Red Hat Virtualization Manager にアクセスする際に、さまざまなインターフェイスを使用できます。各インターフェイスは、異なる方法で仮想化環境へのアクセスを容易にします。
図1.1 Red Hat Virtualization Manager のアーキテクチャー
Red Hat Virtualization Manager は、グラフィカルインターフェイスとアプリケーションプログラミングインターフェイス (API) を提供します。各インターフェイスは、Red Hat JBoss Enterprise Application Platform の組み込みインスタンスによって提供されるアプリケーションである Manager に接続します。Red Hat JBoss Enterprise Application Platform に加えて、Red Hat Virtualization をサポートする他の多くのコンポーネントがあります。
1.2. Red Hat Virtualization Host
Red Hat Virtualization 環境には、1 つ以上のホストが接続されています。ホストは、仮想マシンが利用する物理ハードウェアを提供するサーバーです。
Red Hat Virtualization ホスト (RHVH) は、仮想化ホストを作成するために特別にカスタマイズされたインストールメディアを使用してインストールされた最適化されているオペレーティングシステムを実行します。
Red Hat Enterprise Linux ホストは、インストール後にホストとして使用できるように設定された標準の Red Hat Enterprise Linux オペレーティングシステムを実行しているサーバーです。
ホストインストールの方法にはいずれも、同じ方法で残りの仮想化環境と対話するホストが作成されます。つまり、どちらも ホスト と呼ばれます。
図1.2 ホストアーキテクチャー
- Kernel-based Virtual Machine (KVM)
- カーネルベースの仮想マシン (KVM) は、Intel VT または AMD-V ハードウェア拡張機能を使用して完全仮想化を提供するロード可能なカーネルモジュールです。KVM 自体はカーネルスペースで実行されますが、KVM で実行されるゲストは、ユーザースペースで個別の QEMU プロセスとして実行されます。KVM を使用すると、ホストはその物理ハードウェアを仮想マシンで使用できるようになります。
- QEMU
- QEMU は、完全なシステムエミュレーションを提供するために使用されるマルチプラットフォームエミュレーターです。QEMU は、1 つ以上のプロセッサーと周辺機器を含む PC などの完全なシステムをエミュレートします。QEMU を使用して、さまざまなオペレーティングシステムを起動したり、システムコードをデバッグしたりできます。QEMU は、KVM および適切な仮想化拡張機能を備えたプロセッサーと連携して動作し、完全なハードウェア支援による仮想化を提供します。
- Red Hat Virtualization Manager ホストエージェント (VDSM)
-
Red Hat Virtualization では、VDSM は仮想マシンおよびストレージでアクションを開始します。また、ホスト間の通信も容易になります。VDSM は、メモリー、ストレージ、ネットワークなどのホストリソースを監視します。さらに、VDSM は、仮想マシンの作成、統計の蓄積、ログの収集などのタスクを管理します。VDSM インスタンスは各ホストで実行し、設定可能なポート
54321
を使用して Red Hat Virtualization Manager から管理コマンドを受け取ります。
- VDSM-REG
-
VDSM は VDSM-REG を使用して各ホストを Red Hat Virtualization Manager に登録します。VDSM-REG は、ポート
80
またはポート443
を使用して、ホストとそのホストに関する情報を提供します。 - libvirt
- Libvirt は、仮想マシンとそれに関連する仮想デバイスの管理を容易にします。Red Hat Virtualization Manager が仮想マシンのライフサイクルコマンド (開始、停止、再起動) を開始すると、VDSM は関連するホストマシンで libvirt を呼び出してそれらを実行します。
- Storage Pool Manager (SPM)
Storage Pool Manager (SPM) は、データセンター内の 1 つのホストに割り当てられたロールです。SPM ホストは、データセンターのすべてのストレージドメイン構造メタデータを変更する唯一の権限を持っています。これには、仮想ディスク、スナップショット、およびテンプレートの作成、削除、および操作が含まれます。また、ストレージエリアネットワーク (SAN) 上のスパースブロックデバイスへのストレージの割り当ても含まれます。SPM のロールは、データセンター内の任意のホストに移行できます。その結果、データセンター内のすべてのホストは、データセンターで定義されているすべてのストレージドメインにアクセスできる必要があります。
Red Hat Virtualization Manager は、SPM が常に利用できることを確認します。ストレージ接続エラーが発生すると、Manager は SPM のロールを別のホストに再割り当てします。
- ゲストのオペレーティングシステム
ゲストオペレーティングシステムを変更して、Red Hat Virtualization 環境の仮想マシンにインストールする必要はありません。ゲストオペレーティングシステム、およびゲスト上のアプリケーションは、仮想化環境を認識せず、正常に実行されます。
Red Hat は、仮想化デバイスへのより高速で効率的なアクセスを可能にする拡張デバイスドライバーを提供します。Red Hat Virtualization Guest Agent をゲストにインストールすることもできます。これにより、管理コンソールに拡張ゲスト情報が提供されます。
1.3. Manager をサポートするコンポーネント
- Red Hat JBoss Enterprise Application Platform
- Red Hat JBoss Enterprise Application Platform は Java アプリケーションサーバーです。クロスプラットフォームの Java アプリケーションの効率的な開発と配信をサポートするフレームワークを提供します。Red Hat Virtualization Manager は、Red Hat JBoss Enterprise Application Platform を使用して提供されます。
Red Hat Virtualization Manager にバンドルされた Red Hat JBoss Enterprise Application Platform のバージョンは、他のアプリケーションを提供するのには使用 されません。これは、Red Hat Virtualization Manager にサービスを提供するという特定の目的のためにカスタマイズされています。Manager に含まれている Red Hat JBoss Enterprise Application Platform を追加の目的で使用すると、Red Hat Virtualization 環境にサービスを提供する機能に悪影響を及ぼします。
- レポートおよび履歴データの収集
Red Hat Virtualization Manager には、ホスト、仮想マシン、およびストレージに関するモニタリングデータを収集する Data Warehouse が含まれています。多数の事前定義されたレポートが利用可能です。お客様は、SQL をサポートするクエリーツールを使用して、環境を分析し、レポートを作成できます。
Red Hat Virtualization Manager のインストールプロセスにより、2 つのデータベースが作成されます。これらのデータベースは、インストール時に選択された Postgres インスタンスで作成されます。
- engine データベースは、Red Hat Virtualization Manager が使用するメインのデータストアです。仮想化環境に関する情報 (状態、設定、およびパフォーマンスなど) が、このデータベースに保管されます。
ovirt_engine_history データベースには、エンジン の運用データベースから時間の経過とともに照合される設定情報および統計メトリックが含まれます。エンジン データベースの設定データは 1 分ごとに検証され、変更は ovirt_engine_history データベースに複製されます。データベースへの変更を追跡することで、データベース内のオブジェクトに関する情報が提供されます。これにより、Red Hat Virtualization 環境のパフォーマンスを分析して向上させ、問題を解決することができます。
ovirt_engine_history データベースに基づくレポートの生成に関する詳細は、Red Hat Virtualization Data Warehouse ガイド の 履歴データベース を参照してください。
重要ovirt_engine_history データベースへのデータのレプリケーションは、
RHEVM History サービス
である ovirt-engine-dwhd によって実行されます。- ディレクトリーサービス
- ディレクトリーサービスは、ユーザーおよび組織の情報をネットワークベースのストレージで一元的に保存します。保存される情報の種類には、アプリケーション設定、ユーザープロファイル、グループデータ、ポリシー、およびアクセス制御が含まれます。Red Hat Virtualization Manager は、Active Directory、Identity Management (IdM)、OpenLDAP、および Red Hat Directory Server 9 をサポートします。管理目的のみのローカル内部ドメインもあります。この内部ドメインには、admin ユーザーという 1 人のユーザーしかいません。
1.4. ストレージ
Red Hat Virtualization は、仮想ディスク、テンプレート、スナップショット、および ISO ファイルに集中型ストレージシステムを使用します。ストレージは、ストレージドメインで構成されるストレージプールに論理的にグループ化されます。ストレージドメインは、ストレージ容量と、ストレージの内部構造を説明するメタデータの組み合わせです。ストレージドメインタイプ を参照してください。
各データセンターに必要なのはデータドメインだけです。データストレージドメインは、単一のデータセンター専用です。エクスポートドメインと ISO ドメインは任意です。ストレージドメインは共有リソースであり、データセンター内のすべてのホストがアクセスできる必要があります。
1.5. ネットワーク
Red Hat Virtualization ネットワークアーキテクチャーは、Red Hat Virtualization 環境のさまざまな要素間の接続を容易にします。ネットワークアーキテクチャーは、ネットワーク接続をサポートするだけでなく、ネットワークの分離も可能にします。
図1.3 ネットワークアーキテクチャー
ネットワーキングは、Red Hat Virtualization でいくつかのレイヤーで定義されています。基盤となる物理ネットワークインフラストラクチャーは、ハードウェアと Red Hat Virtualization 環境の論理コンポーネント間の接続を可能にするように配置および設定されている必要があります。
- ネットワークインフラストラクチャー層
Red Hat Virtualization ネットワークアーキテクチャーは、いくつかの一般的なハードウェアおよびソフトウェアデバイスに依存しています。
- ネットワークインターフェイスコントローラー (NIC) は、ホストをネットワークに接続する物理ネットワークインターフェイスデバイスです。
- 仮想 NIC (vNIC) は、ホストの物理 NIC を使用して動作する論理 NIC です。これらは、仮想マシンへのネットワーク接続を提供します。
- ボンドは、複数の NIC を単一のインターフェイスにバインドします。
- ブリッジは、パケット交換ネットワークのパケット転送技術です。これらは、仮想マシンの論理ネットワークの基盤を形成します。
- 論理ネットワーク
論理ネットワークでは、環境要件に基づいてネットワークトラフィックを分離できます。論理ネットワークの種類は次のとおりです。
- 仮想マシンネットワークトラフィックを伝送する論理ネットワーク、
- 仮想マシンネットワークトラフィックを伝送しない論理ネットワーク、
- オプションの論理ネットワーク
- 必要なネットワーク。
すべての論理ネットワークは、必須または任意のいずれかです。
仮想マシンネットワークトラフィックを伝送する論理ネットワークは、ソフトウェアブリッジデバイスとしてホストレベルで実装されます。デフォルトでは、Red Hat Virtualization Manager (ovirtmgmt 管理ネットワーク 9 のインストール時に 1 つの論理ネットワークが定義されます。
管理者が追加できるその他の論理ネットワークは、専用のストレージ論理ネットワークと専用のディスプレイ論理ネットワークです。仮想マシントラフィックを伝送しない論理ネットワークには、ホスト上に関連付けられたブリッジデバイスがありません。これらは、ホストネットワークインターフェイスに直接関連付けられています。
Red Hat Virtualization は、管理関連のネットワークトラフィックを移行関連のネットワークトラフィックから分離します。これにより、ライブマイグレーションに専用ネットワーク (ルーティングなし) を使用できるようになり、移行中に管理ネットワーク (ovirtmgmt) がハイパーバイザーへの接続を失うことがなくなります。
- 異なる層の論理ネットワークの説明
- 論理ネットワークは、仮想化環境の各レイヤーに異なる影響を及ぼします。
データセンター層
論理ネットワークはデータセンターレベルで定義されます。各データセンターには、デフォルトで ovirtmgmt 管理ネットワークがあります。それ以上の論理ネットワークはオプションですが、推奨されます。仮想マシンネットワーク およびカスタム MTU の指定はデータセンターレベルで設定できます。データセンター用に定義された論理ネットワークも、論理ネットワークを使用するクラスターに追加する必要があります。
クラスター層
論理ネットワークはデータセンターから利用可能になり、それらを使用するクラスターに追加する必要があります。デフォルトでは、各クラスターは管理ネットワークに接続されています。オプションで、クラスターの親データセンター用に定義された論理ネットワークをクラスターに追加できます。必要な論理ネットワークがクラスターに追加されたら、クラスター内のホストごとに実装する必要があります。任意の論理ネットワークは、必要に応じてホストに追加できます。
ホスト層
仮想マシンの論理ネットワークは、特定のネットワークインターフェイスに関連付けられたソフトウェアブリッジデバイスとして、クラスター内のホストごとに実装されます。非仮想マシンの論理ネットワークにはブリッジが関連付けられておらず、ホストネットワークインターフェイスに直接関連付けられています。各ホストには、Red Hat Virtualization 環境に含まれている結果として、そのネットワークデバイスの 1 つを使用するブリッジとして実装された管理ネットワークがあります。クラスターに追加されたさらに必要な論理ネットワークは、クラスターで動作可能になるために、各ホストのネットワークインターフェイスに関連付けられている必要があります。
仮想マシン層
論理ネットワークは、ネットワークを物理マシンで利用できるようにするのと同じ方法で、仮想マシンで利用できるようにすることができます。仮想マシンは、その仮想 NIC を、それを実行するホストに実装されている任意の仮想マシン論理ネットワークに接続できます。次に、仮想マシンは、接続されている論理ネットワーク上で使用可能な他のデバイスまたは宛先への接続を取得します。
例1.1 Management Network
ovirtmgmt
という名前の管理論理ネットワークは、Red Hat Virtualization Manager のインストール時に自動的に作成されます。ovirtmgmt
ネットワークは、Red Hat Virtualization Manager とホスト間のトラフィックの管理専用です。特に目的のブリッジが設定されていない場合、ovirtmgmt
はすべてのトラフィックのデフォルトブリッジになります。
1.6. データセンター
データセンターは、Red Hat Virtualization における最高レベルの抽象化です。データセンターには、次の 3 種類の情報が含まれています。
- ストレージ
- これには、ストレージタイプ、ストレージドメイン、およびストレージドメインの接続情報が含まれます。ストレージはデータセンター用に定義されており、データセンター内のすべてのクラスターで使用できます。データセンター内のすべてのホストクラスターは、同じストレージドメインにアクセスできます。
- 論理ネットワーク
- これには、ネットワークアドレス、VLAN タグ、STP サポートなどの詳細が含まれます。データセンターの論理ネットワークを定義し、それらをクラスターに適用できます。
- クラスター
- クラスターは、AMD または Intel プロセッサーのいずれかの互換性のあるプロセッサーコアを備えたホストのグループです。クラスターは移行ドメインです。仮想マシンは、他のクラスターではなく、クラスター内の任意のホストにライブマイグレーションできます。1 つのデータセンターに複数のクラスターを保持でき、各クラスターに複数のホストを含めることができます。
1.7. データセンターおよびクラスターの互換性レベル
Red Hat Virtualization データセンターおよびクラスターには、互換バージョンがあります。
データセンター互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
クラスターの互換バージョンは、そのクラスター内のすべてのホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
以下の表は、RHV バージョンの互換性マトリックスと、必要なデータセンターおよびクラスターの互換性レベルを提供します。
互換性レベル | RHV バージョン | 説明 |
---|---|---|
4.7 | 4.4 | 互換性レベル 4.7 は、RHEL8.6 ハイパーバイザーによって導入された新機能をサポートするために RHV 4.4 で導入されました。 |
4.6 | 4.4.6 | 互換性レベル 4.6 は、Advanced Virtualization 8.4 パッケージを使用する RHEL 8.4 ハイパーバイザーによって導入された新機能をサポートするために、RHV 4.4.6 で導入されました。 |
4.5 | 4.4.3 | 互換性レベル 4.5 は、Advanced Virtualization 8.3 パッケージを使用する RHEL 8.3 ハイパーバイザーによって導入された新機能をサポートするために、RHV 4.4.3 で導入されました。 |
制限事項
クラスター互換性レベルを 4.6 にアップグレードすると、VirtIO NIC は別のデバイスとして列挙されます。そのため、NIC の再設定が必要になる場合があります。Red Hat は、仮想マシンをテストするために、クラスターをアップグレードする前に仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することを推奨します。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
第2章 ストレージ
2.1. ストレージドメインの概要
ストレージドメインは、共通のストレージインターフェイスを持つイメージのコレクションです。ストレージドメインには、テンプレートと仮想マシンの完全なイメージ (スナップショットを含む)、ISO ファイル、およびそれら自体に関するメタデータが含まれています。ストレージドメインは、ブロックデバイス (SAN - iSCSI または FCP) またはファイルシステム (NAS - NFS、GlusterFS、またはその他の POSIX 準拠のファイルシステム) のいずれかで構成できます。
GlusterFS Storage は非推奨になり、将来のリリースではサポートされなくなります。
NAS では、すべての仮想ディスク、テンプレート、およびスナップショットはファイルです。
SAN (iSCSI/FCP) では、各仮想ディスク、テンプレート、またはスナップショットは論理ボリュームです。ブロックデバイスは、ボリュームグループと呼ばれる論理エンティティーに集約され、LVM (Logical Volume Manager) によって論理ボリュームに分割されて仮想ハードディスクとして使用されます。LVM の詳細は、Red Hat Enterprise Linux 論理ボリュームの設定と管理 を参照してください。
仮想ディスクの形式は、QCOW2 または raw のいずれかになります。ストレージのタイプは、スパースまたは事前割り当てのいずれかです。スナップショットは常にスパースですが、どちらの形式のディスクでも取得できます。
同じストレージドメインを共有する仮想マシンは、同じクラスターに属するホスト間で移行できます。
2.2. ストレージバッキングストレージドメインの種類
ストレージドメインは、ブロックベースおよびファイルベースのストレージを使用して実装できます。
- ファイルベースのストレージ
Red Hat Virtualization でサポートされているファイルベースのストレージタイプは、NFS、GlusterFS、その他の POSIX 準拠のファイルシステム、およびホストにローカルなストレージです。
注記GlusterFS Storage は非推奨になり、将来のリリースではサポートされなくなります。
ファイルベースのストレージは、Red Hat Virtualization 環境の外部で管理されます。
NFS ストレージは、Red Hat Enterprise Linux NFS サーバーまたはその他のサードパーティーのネットワーク接続ストレージサーバーによって管理されます。
ホストは、独自のローカルストレージファイルシステムを管理できます。
- ブロックベースのストレージ
ブロックストレージは、フォーマットされていないブロックデバイスを使用します。ブロックデバイスは、Logical Volume Manager (LVM) によってボリュームグループに集約されます。LVM のインスタンスは、他のホストで実行されているインスタンスを認識せずに、すべてのホストで実行されます。VDSM は、ボリュームグループの変更をスキャンすることにより、LVM の上にクラスタリングロジックを追加します。変更が検出されると、VDSM は、ボリュームグループ情報を更新するように指示することにより、個々のホストを更新します。ホストはボリュームグループを論理ボリュームに分割し、論理ボリュームのメタデータをディスクに書き込みます。既存のストレージドメインにさらにストレージ容量が追加されると、Red Hat Virtualization Manager により、各ホストの VDSM がボリュームグループ情報を更新します。
論理ユニット番号 (LUN) は、個々のブロックデバイスです。サポートされているブロックストレージプロトコルの 1 つである iSCSI またはファイバーチャネルは、LUN への接続に使用されます。Red Hat Virtualization Manager は、LUN へのソフトウェア iSCSI 接続を管理します。他のすべてのブロックストレージ接続は、Red Hat Virtualization 環境の外部で管理されます。論理ボリュームの作成、論理ボリュームの拡張または削除、新しい LUN の追加など、ブロックベースのストレージ環境での変更は、Storage Pool Manager と呼ばれる特別に選択されたホスト上の LVM によって処理されます。次に、変更は VDSM によって同期され、ストレージメタデータはクラスター内のすべてのホスト間で更新されます。
2.3. ストレージドメインタイプ
Red Hat Virtualization は、以下のタイプのストレージドメインと、各ストレージドメインがサポートするストレージタイプをサポートします。
データドメイン は、Red Hat Virtualization 環境内のすべての仮想マシンのハードディスクイメージを保存します。ディスクイメージには、インストールされているオペレーティングシステム、または仮想マシンによって保存または生成されたデータが含まれている場合があります。データストレージドメインは、NFS、iSCSI、FCP、GlusterFS、および POSIX 準拠のストレージをサポートします。データドメインを複数のデータセンター間で共有することはできません。
注記GlusterFS Storage は非推奨になり、将来のリリースではサポートされなくなります。
エクスポートドメイン は、ハードディスクイメージや、データセンター間で転送される仮想マシンテンプレートの一時的なストレージを提供します。さらに、エクスポートストレージドメインは、バックアップされた仮想マシンのコピーを保存します。エクスポートストレージドメインは NFS ストレージをサポートします。複数のデータセンターが単一のエクスポートストレージドメインにアクセスできますが、一度に使用できるのは 1 つのデータセンターのみです。
注記エクスポートドメインは非推奨になりました。ストレージデータドメインはデータセンターからデタッチし、同じ環境または別の環境にある別のデータセンターにインポートすることができます。仮想マシン、フローティング仮想ディスク、およびテンプレートは、インポートされたストレージドメインからアタッチされたデータセンターにアップロードできます。
ISO ドメイン は、イメージとも呼ばれる ISO ファイルを保存します。ISO ファイルは、物理 CD または DVD を表したものです。Red Hat Virtualization 環境では、一般的なタイプの ISO ファイルは、オペレーティングシステムのインストールディスク、アプリケーションのインストールディスク、およびゲストエージェントのインストールディスクです。これらのイメージは、物理ディスクをディスクドライブに挿入して起動するのと同じ方法で、仮想マシンに接続して起動できます。ISO ストレージドメインにより、データセンター内のすべてのホストが ISO を共有できるようになり、物理的な光メディアが不要になります。
注記ISO ドメインは、非推奨のストレージドメインタイプです。ISO アップローダーツールが非推奨になりました。Red Hat は、管理ポータルまたは REST API を使用して、データドメインに ISO イメージをアップロードすることを推奨します。
2.4. 仮想ディスクのストレージフォーマット
- QCOW2 形式の仮想マシンストレージ
QCOW2 は、仮想ディスクのストレージ形式です。QCOW は QEMU コピーオンライトの略です。QCOW2 形式は、論理ブロックと物理ブロックの間にマッピングを追加することにより、物理ストレージ層を仮想層から切り離します。各論理ブロックはその物理オフセットにマップされます。これにより、ストレージのオーバーコミットメントと仮想マシンのスナップショットが可能になります。各 QCOW ボリュームは、基盤となる仮想ディスクに加えられた変更のみを表します。
初期マッピングは、すべての論理ブロックをバッキングファイルまたはボリュームのオフセットにポイントします。スナップショットの後に仮想マシンが QCOW2 ボリュームにデータを書き込むと、関連するブロックがバッキングボリュームから読み取られ、新しい情報で変更されて、新しいスナップショット QCOW2 ボリュームに書き込まれます。次に、新しい場所を指すように地図が更新されます。
- Raw
RAW ストレージ形式には、RAW 形式で保存された仮想ディスクにフォーマットが適用されないという点で QCOW2 よりもパフォーマンス上の利点があります。RAW 形式で保存された仮想ディスクでの仮想マシンのデータ操作には、ホストによる追加の作業は必要ありません。仮想マシンが仮想ディスクの特定のオフセットにデータを書き込む場合、I/O はバッキングファイルまたは論理ボリュームの同じオフセットに書き込まれます。
Raw 形式では、ストレージアレイから外部で管理されているシンプロビジョニングされた LUN を使用しない限り、定義されたイメージのスペース全体を事前に割り当てる必要があります。
2.5. 仮想ディスクストレージ割り当てポリシー
- 事前に割り当てられたストレージ
- 仮想ディスクに必要なすべてのストレージは、仮想マシンの作成前に割り当てられます。仮想マシン用に 20GB のディスクイメージが作成される場合、ディスクイメージは 20GB のストレージドメイン容量を使用します。事前に割り当てられたディスクイメージは拡大できません。ストレージの事前割り当ては、実行時にストレージの割り当てが行われないため、書き込み時間が短縮されることを意味しますが、柔軟性が犠牲になります。この方法でストレージを割り振ると、ストレージをオーバーコミットする Red Hat Virtualization Manager の容量が減少します。ストレージの遅延に対する許容度が低い、高強度の I/O タスクに使用される仮想マシンには、事前に割り当てられたストレージを推奨します。一般に、サーバー仮想マシンはこの説明に適合します。
ストレージバックエンドによって提供されるシンプロビジョニング機能を使用している場合でも、仮想マシンのストレージをプロビジョニングするときに、管理ポータルから事前に割り当てられたストレージを選択する必要があります。
- 部分的に割り当てられたストレージ
- 仮想ディスクのサイズの上限は、仮想マシンの作成時に設定されます。最初は、ディスクイメージはストレージドメインの容量を使用していません。上限に達するまで、仮想マシンがデータをディスクに書き込むにつれて、使用量は増加します。ディスクイメージ内のデータが削除されても、容量はストレージドメインに戻されません。わずかに割り当てられたストレージは、ストレージの遅延にある程度の許容度がある低または中強度の I/O タスクを持つ仮想マシンに適しています。一般に、デスクトップ仮想マシンはこの説明に適合します。
シンプロビジョニング機能がストレージバックエンドによって提供される場合は、シンプロビジョニングの推奨される実装として使用する必要があります。ストレージは、事前に割り当てられたグラフィカルユーザーインターフェイスからプロビジョニングし、シンプロビジョニングをバックエンドソリューションに任せる必要があります。
2.6. Red Hat Virtualization のストレージメタデータバージョン
Red Hat Virtualization は、ストレージドメインに関する情報をストレージドメイン自体のメタデータとして保存します。Red Hat Virtualization の各メジャーリリースでは、ストレージメタデータの実装が改善されています。
V1 メタデータ (Red Hat Virtualization 2.x シリーズ)
- 各ストレージドメインには、独自の構造を説明するメタデータと、仮想ディスクのバックアップに使用されるすべての物理ボリュームの名前が含まれています。
- マスタードメインには、ストレージプール内のすべてのドメインと物理ボリューム名のメタデータが追加で含まれています。このメタデータの合計サイズは 2 KB に制限されており、プールに含めることができるストレージドメインの数が制限されます。
- テンプレートと仮想マシンのベースイメージは読み取り専用です。
- V1 メタデータは、NFS、iSCSI、および FC ストレージドメインに適用できます。
V2 メタデータ (Red Hat Enterprise Virtualization 3.0)
- すべてのストレージドメインとプールのメタデータは、論理ボリュームに書き込まれるのではなく、論理ボリュームタグとして保存されます。仮想ディスクボリュームに関するメタデータは、引き続きドメインの論理ボリュームに保存されます。
- 物理ボリューム名はメタデータに含まれなくなりました。
- テンプレートと仮想マシンのベースイメージは読み取り専用です。
- V2 メタデータは、iSCSI および FC ストレージドメインに適用できます。
V3 メタデータ (Red Hat Enterprise Virtualization 3.1 以降)
- すべてのストレージドメインとプールのメタデータは、論理ボリュームに書き込まれるのではなく、論理ボリュームタグとして保存されます。仮想ディスクボリュームに関するメタデータは、引き続きドメインの論理ボリュームに保存されます。
- 仮想マシンとテンプレートのベースイメージは読み取り専用ではなくなりました。この変更により、ライブスナップショット、ライブストレージの移行、およびスナップショットからのクローン作成が可能になります。
- 英語以外のボリューム名に対して、Unicode メタデータのサポートが追加されました。
V3 メタデータは、NFS、GlusterFS、POSIX、iSCSI、および FC ストレージドメインに適用できます。
注記GlusterFS Storage は非推奨になり、将来のリリースではサポートされなくなります。
V4 メタデータ (Red Hat Virtualization 4.1 以降)
- QCOW2 互換レベルのサポート -QCOW イメージ形式にはバージョン番号が含まれているため、イメージ形式を変更して以前のバージョンと互換性がないようにする新機能を導入できます。新しい QEMU バージョン (1.7 以降) は QCOW2 バージョン 3 をサポートします。これは下位互換性がありませんが、ゼロクラスターやパフォーマンスの向上などの改善が導入されています。
VM リースをサポートする新しい xleases ボリューム - この機能により、リースを仮想マシンディスクに接続せずに、共有ストレージ上の仮想マシンごとにリースを取得する機能が追加されます。
VM リースには、次の 2 つの重要な機能があります。
- スプリットブレインの回避。
- 元のホストが応答しなくなった場合に別のホストで VM を起動すると、HA VM の可用性が向上します。
V5 メタデータ (Red Hat Virtualization 4.3 以降)
- 4K (4096 バイト) ブロックストレージのサポート。
- 可変 SANLOCK アラインメントのサポート。
新しいプロパティーのサポート:
-
BLOCK_SIZE
- ストレージドメインのブロックサイズをバイト単位で保存します。 ALIGNMENT
- xlease ボリュームのフォーマットとサイズを指定します。(1MB から 8MB)。サポートされるホストの最大数 (ユーザーが提供する値) とディスクブロックサイズによって決まります。例: 512b のブロックサイズと 2000 ホストのサポートにより、1MB の xlease ボリュームが得られます。
2000 ホストの 4K ブロックサイズは、8MB の xlease ボリュームになります。
最大ホストのデフォルト値は 250 であり、4K ディスクの xlease ボリュームは 1MB になります。
-
非推奨のプロパティー:
-
LOGBLKSIZE
フィールド、PHYBLKSIZE
フィールド、MTIME
フィールド、およびPOOL_UUID
フィールドはストレージドメインのメタデータから削除されました。 -
SIZE
(ブロックでのサイズ) フィールドはCAP
(バイト単位) に置き換えられました。
-
- ブートディスクは常に 512 バイトのエミュレーションを使用するため、4K フォーマットのディスクからブートすることはできません。
- nfs 形式は常に 512 バイトを使用します。
2.7. Red Hat Virtualization でのストレージドメインの自動リカバリー
Red Hat Virtualization 環境のホストは、各ドメインからメタデータを読み取ることにより、データセンターのストレージドメインを監視します。データセンター内のすべてのホストがストレージドメインにアクセスできないと報告すると、ストレージドメインは非アクティブになります。
Manager は、非アクティブなストレージドメインを切断するのではなく、たとえば一時的なネットワークの停止などにより、ストレージドメインが一時的に非アクティブになっていると見なします。5 分ごとに、Manager は非アクティブなストレージドメインの再アクティブ化を試みます。
ストレージ接続の中断の原因を修正するために管理者の介入が必要になる場合がありますが、接続が復元されると、マネージャーはストレージドメインの再アクティブ化を処理します。
2.8. Storage Pool Manager
Red Hat Virtualization は、メタデータを使用してストレージドメインの内部構造を記述します。構造メタデータは、各ストレージドメインのセグメントに書き込まれます。ホストは、単一のライターと複数のリーダーの設定に基づいて、ストレージドメインのメタデータを操作します。ストレージドメインの構造メタデータは、イメージとスナップショットの作成と削除、およびボリュームとドメインの拡張を追跡します。
データドメインの構造を変更できるホストは、Storage Pool Manager (SPM) と呼ばれます。SPM は、ディスクイメージの作成と削除、スナップショットの作成とマージ、ストレージドメイン間でのイメージのコピー、テンプレートの作成、ブロックデバイスのストレージ割り当てなど、データセンター内のすべてのメタデータの変更を調整します。データセンターごとに 1 つの SPM があります。他のすべてのホストは、ストレージドメインの構造メタデータのみを読み取ることができます。
ホストは SPM として手動で選択することも、Red Hat Virtualization によって割り当てることもできます。Manager は、潜在的な SPM ホストにストレージ中心のリースを引き受けさせることにより、SPM のロールを割り当てます。リースにより、SPM ホストはストレージメタデータを書き込むことができます。Manager またはホストによって追跡されるのではなく、ストレージドメインに書き込まれるため、ストレージ中心です。ストレージ中心リースは、leases と呼ばれる master
ストレージドメインの特殊な論理ボリュームに書き込まれます。データドメインの構造に関するメタデータは、metadata と呼ばれる特別な論理ボリュームに書き込まれます。leases 論理ボリュームは、metadata 論理ボリュームの変更から保護します。
Manager は VDSM を使用してホストに spmStart コマンドを実行し、そのホストの VDSM がストレージ中心リースを想定しようとします。ホストが成功すると、ホストは SPM になり、Red Hat Virtualization Manager が新しいホストに SPM のロールを引き受けるように要求するまで、ストレージ中心のリースを保持します。
次の場合、マネージャーは SPM のロールを別のホストに移動します。
-
SPM ホストはすべてのストレージドメインにアクセスできるわけではありませんが、
master
ストレージドメインにはアクセスできます - ストレージ接続が失われたか、リースボリュームがいっぱいで、書き込み操作を実行できないため、SPM ホストはリースを更新できません。
- SPM ホストがクラッシュする
図2.1 Storage Pool Manager は、構造メタデータを排他的に書き込みます。
2.9. Storage Pool Manager の選択プロセス
ホストに Storage Pool Manager (SPM) のロールが手動で割り当てられていない場合、SPM 選択プロセスは Red Hat Virtualization によって開始および管理されます。
まず、Red Hat Virtualization Manager は、VDSM がどのホストにストレージ中心のリースがあるかを確認するように要求します。
Red Hat Virtualization Manager は、ストレージドメインの最初の作成以降の SPM 割り当ての履歴を追跡します。SPM ロールの可用性は、次の 3 つの方法で確認されます。
- "getSPMstatus" コマンド: マネージャーは VDSM を使用して、最後に SPM ステータスがあったホストを確認し、"SPM"、"Contending"、または "Free" のいずれかを受け取ります。
- ストレージドメインのメタデータボリュームには、SPM ステータスの最後のホストが含まれています。
- ストレージドメインのメタデータボリュームには、SPM ステータスの最後のホストのバージョンが含まれています。
運用可能で応答性の高いホストがストレージ中心のリースを保持している場合、Red Hat Virtualization Manager は管理者ポータルでそのホスト SPM をマークします。それ以上のアクションは実行されません。
SPM ホストが応答しない場合は、到達不能と見なされます。ホストに電源管理が設定されている場合、ホストは自動的にフェンスされます。そうでない場合は、手動フェンシングが必要です。以前の Storage Pool Manager がフェンスで囲まれるまで、Storage Pool Manager のロールを新しいホストに割り当てることはできません。
SPM のロールとストレージ中心のリースが空いている場合、Red Hat Virtualization Manager はそれらをデータセンター内のランダムに選択された運用ホストに割り当てます。
新しいホストで SPM ロールの割り当てが失敗した場合、Red Hat Virtualization Manager は、操作が失敗したホストを含むリストにホストを追加し、これらのホストを SPM ロールの対象外としてマークします。このリストは、次の SPM 選択プロセスの開始時にクリアされるため、すべてのホストが再び適格になります。
Red Hat Virtualization Manager は、SPM の選択が成功するまで、失敗したホストのリストにないランダムに選択されたホストが、Storage Pool Manager ロールとストレージ中心のリースを引き継ぐように要求し続けます。
現在の SPM が応答しないか、その責任を果たせなくなるたびに、Red Hat Virtualization は Storage Pool Manager の選択プロセスを開始します。
2.10. Red Hat Virtualization における排他的リソースと Sanlock
Red Hat Virtualization 環境の特定のリソースには、排他的にアクセスする必要があります。
SPM のロールはそのようなリソースの 1 つです。複数のホストが SPM になると、同じデータが 2 つの場所から同時に変更される可能性があるため、データが破損するリスクがあります。
Red Hat Enterprise Virtualization 3.1 以前では、SPM の除外は、セーフリース と呼ばれる VDSM 機能を使用して維持および追跡されました。リースは、データセンター内のすべてのストレージドメインの特別な領域に書き込まれました。環境内のすべてのホストは、ネットワークに依存しない方法で SPM ステータスを追跡できます。VDSM のセーフリースは、SPM のロールという 1 つのリソースの独占権のみを維持していました。
Sanlock は同じ機能を提供しますが、SPM ロールをロック可能なリソースの 1 つとして扱います。Sanlock は、追加のリソースをロックできるため、より柔軟性があります。
リソースのロックが必要なアプリケーションは、Sanlock に登録できます。登録されたアプリケーションは、Sanlock が自分に代わってリソースをロックするように要求できるため、他のアプリケーションはそのリソースにアクセスできません。たとえば、VDSM が SPM ステータスをロックする代わりに、VDSM は Sanlock にロックするように要求するようになりました。
ロックは、ロックスペース のディスクで追跡されます。ストレージドメインごとに 1 つのロックスペースがあります。SPM リソースのロックの場合、各ホストの liveness は、ストレージに接続したときに Manager から受け取ったホスト ID を更新し、定期的にタイムスタンプをロックスペースに書き込むホストの機能によってロックスペースで追跡されます。ids 論理ボリュームは各ホストの一意の識別子を追跡し、ホストが hostid を更新するたびに更新されます。SPM リソースは、ライブホストのみが保持できます。
リソースは、leases 論理ボリュームのディスクで追跡されます。ディスクの表現が、それを取得したプロセスの一意識別子で更新した場合に、リソースが 取得 されることを意味します。SPM ロールの場合、SPM リソースは、それを取得した hostid で更新されます。
各ホストの Sanlock プロセスは、リソースが取得されていることを確認するために 1 回だけリソースをチェックする必要があります。最初のチェックの後、Sanlock は、ロックされたリソースを持つホストのタイムスタンプが古くなるまで、ロックスペースを監視できます。
Sanlock は、リソースを使用するアプリケーションを監視します。たとえば、VDSM は SPM ステータスとホスト ID について監視されます。ホストが Manager からホスト ID を更新できない場合は、ロックスペース内のすべてのリソースの排他性が失われます。Sanlock はリソースを更新して、リソースが使用されなくなったことを示します。
SPM ホストがストレージドメインのロックスペースにタイムスタンプを一定時間書き込むことができない場合、ホストの Sanlock のインスタンスは、VDSM プロセスがそのリソースを解放するように要求します。VDSM プロセスが応答すると、そのリソースが解放され、ロックスペース内の SPM リソースを別のホストが取得できます。
SPM ホスト上の VDSM がリソースを解放する要求に応答しない場合、ホスト上の Sanlock は VDSM プロセスを強制終了します。kill コマンドが失敗した場合、Sanlock は sigkill を使用して VDSM を強制終了しようとしてエスカレーションします。sigkill が失敗した場合は、Sanlock は ウォッチドッグデーモン に依存してホストを再起動します。
ホストの VDSM が hostid を更新し、ロックスペースにタイムスタンプを書き込むたびに、ウォッチドッグデーモンは ペット を受け取ります。VDSM がこれを実行できない場合、ウォッチドッグデーモンは pet されなくなります。ウォッチドッグデーモンが一定時間ペットを受信しないと、ホストを再起動します。この最終レベルのエスカレーションに達すると、SPM リソースが解放され、別のホストが取得できることが保証されます。
2.11. シンプロビジョニングとストレージのオーバーコミットメント
Red Hat Virtualization Manager は、仮想化環境内のストレージ使用を最適化するためのプロビジョニングポリシーを提供します。シンプロビジョニングポリシーを使用すると、ストレージリソースをオーバーコミットし、仮想化環境の実際のストレージ使用量に基づいてストレージをプロビジョニングできます。
ストレージのオーバーコミットメントとは、ストレージプールで物理的に利用できるよりも多くのストレージを仮想マシンに割り当てることです。一般に、仮想マシンは、割り当てられているストレージよりも少ないストレージを使用します。シンプロビジョニングにより、仮想マシンは、実際にはストレージのごく一部しか割り当てられていない場合でも、仮想マシンに定義されたストレージが完全に割り当てられているかのように動作できます。
Red Hat Virtualization Manager は独自のシンプロビジョニング機能を提供しますが、ストレージバックエンドのシンプロビジョニング機能が提供されている場合はそれを使用する必要があります。
ストレージのオーバーコミットメントをサポートするために、VDSM は、論理ストレージ割り当てを実際のストレージ使用量と比較するしきい値を定義します。このしきい値は、ディスクイメージに書き込まれるデータが、ディスクイメージをバックアップする論理ボリュームよりも小さいことを確認するために使用されます。QEMU は、論理ボリュームに書き込まれる最大のオフセットを識別します。これは、ストレージの最大使用ポイントを示します。VDSM は、QEMU によってマークされた最大オフセットを監視して、使用量が定義されたしきい値を超えないようにします。VDSM が最大オフセットがしきい値を下回っていることを示し続ける限り、Red Hat Virtualization Manager は、問題の論理ボリュームに操作を続行するのに十分なストレージがあることを認識します。
QEMU が使用量がしきい値制限を超えて上昇したことを示すと、VDSM は、ディスクイメージがまもなく論理ボリュームのサイズに達することを Manager に通知します。Red Hat Virtualization Manager は、SPM ホストが論理ボリュームを拡張することを要求します。このプロセスは、データセンターのデータストレージドメインに使用可能なスペースがある限り繰り返すことができます。データストレージドメインの空き容量が不足した場合は、手動でストレージ容量を追加して拡張する必要があります。
2.12. 論理ボリューム拡張
Red Hat Virtualization Manager は、シンプロビジョニングを使用して、ストレージプールで使用可能なストレージをオーバーコミットし、物理的に使用可能なストレージよりも多くのストレージを割り当てます。仮想マシンは、動作中にデータを書き込みます。シンプロビジョニングされたディスクイメージを備えた仮想マシンは、最終的に、ディスクイメージをサポートする論理ボリュームが保持できるよりも多くのデータを書き込みます。これが発生すると、論理ボリューム拡張が追加のストレージを提供し、仮想マシンの継続的な操作を容易にするために使用されます。
Red Hat Virtualization は、LVM 上にシンプロビジョニングメカニズムを提供します。QCOW2 形式のストレージを使用する場合、Red Hat Virtualization はホストシステムプロセス qemu-kvm に依存して、ディスク上のストレージブロックを論理ブロックに順次マップします。これにより、たとえば、1 GB の論理ボリュームでバックアップされた論理 100 GB ディスクの定義が可能になります。qemu-kvm が VDSM によって設定された使用量のしきい値を超えると、ローカル VDSM インスタンスは、論理ボリュームをさらに 1 ギガバイト拡張するように SPM に要求します。ボリューム拡張が必要な仮想マシンを実行しているホスト上の VDSM は、より多くのスペースが必要であることを SPM VDSM に通知します。SPM は論理ボリュームを拡張し、SPM VDSM インスタンスにより、ホスト VDSM はボリュームグループ情報をリフレッシュし、拡張操作が完了したことを認識します。ホストは操作を続行できます。
論理ボリューム拡張では、ホストが他のどのホストが SPM であるかを知っている必要はありません。それは SPM 自体でさえあり得ます。ストレージ拡張通信は、ストレージメールボックスを介して行われます。ストレージメールボックスは、データストレージドメイン上の専用の論理ボリュームです。論理ボリュームを拡張するために SPM を必要とするホストは、ストレージメールボックス内のその特定のホストに指定された領域にメッセージを書き込みます。SPM は、受信メールを定期的に読み取り、要求された論理ボリューム拡張を実行し、送信メールに応答を書き込みます。リクエストを送信した後、ホストは 2 秒ごとに受信メールの応答を監視します。ホストは、論理ボリューム拡張要求への正常な応答を受信すると、デバイスマッパーの論理ボリュームマップを更新して、新しく割り当てられたストレージを認識します。
ストレージプールで使用可能な物理ストレージがほぼ使い果たされると、リソースを補充する手段がなくても、複数のイメージで使用可能なストレージが不足する可能性があります。そのストレージを消費するストレージプールにより、QEMU は enospc エラー を返します。これは、デバイスに利用可能なストレージがなくなったことを示します。この時点で、実行中の仮想マシンは自動的に一時停止され、ボリュームグループに新しい LUN を追加するには手動による介入が必要になります。
新しい LUN がボリュームグループに追加されると、Storage Pool Manager は追加のストレージをそれを必要とする論理ボリュームに自動的に分散します。追加のリソースの自動割り当てにより、関連する仮想マシンは、中断されることなく自動的に操作を続行したり、停止した場合に操作を再開したりできます。
2.13. ストレージ容量に対するストレージドメインアクションの影響
- ステートレス仮想マシンの電源をオン、オフ、および再起動します
- これらの 3 つのプロセスは、ステートレス仮想マシンのコピーオンライト (COW) レイヤーに影響を与えます。詳細は、仮想マシン管理ガイド の 仮想マシンの一般的な設定表 の Stateless 行を参照してください。
- ストレージドメインを作成する
ブロックストレージドメインを作成すると、以下に示す 7 つの LV と同じ名前のファイルが作成され、最初は容量が少なくて済みます。
ids 64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-ao---- 128.00m inbox 64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 128.00m leases 64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 2.00g master 64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-ao---- 1.00g metadata 64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 512.00m outbox 64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 128.00m xleases 64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 1.00g
- ストレージドメインを削除する
- ストレージドメインを削除すると、プロセスが削除した容量と同じ量だけディスクの容量が解放されます。
- ストレージドメインを移行する
- ストレージドメインの移行では、追加のストレージ容量は使用されません。ストレージドメインの移行に関する詳細は、管理ガイド の 同じ環境内のデータセンター間でのストレージドメインの移行 を参照してください。
- 仮想ディスクを他のストレージドメインに移動する
仮想ディスクを移行するには、ターゲットストレージドメインで使用できる十分な空き容量が必要です。管理ポータルで、ターゲットドメインのおおよその空き容量を確認できます。
移動プロセスのストレージタイプは、表示容量に影響します。たとえば、事前に割り当てられたディスクをブロックストレージからファイルストレージに移動すると、結果として生じる空き領域は、最初の空き領域よりもかなり小さくなる可能性があります。
仮想ディスクを別のストレージドメインにライブ移行すると、スナップショットも作成されます。スナップショットは、移行の完了後に自動的にマージされます。仮想ディスクの移動に関する詳細は、管理ガイド の 仮想ディスクの移動 を参照してください。
- ストレージドメインを一時停止する
- ストレージドメインを一時停止しても、追加のストレージ容量は使用されません。
- 仮想マシンのスナップショットを作成する
仮想マシンのスナップショットを作成すると、ストレージドメインの容量に影響を与える可能性があります。
- ライブスナップショットの作成では、デフォルトでメモリースナップショットが使用され、仮想マシンごとに 2 つの追加ボリュームが生成されます。最初のボリュームは、メモリー、ビデオメモリー、および 200MB のバッファーの合計です。2 番目のボリュームには、サイズが数 MB の仮想マシン設定が含まれています。ブロックストレージを使用する場合、Red Hat Virtualization が提供できる最も近いユニットに切り上げが行われます。
- オフラインスナップショットの作成は、最初に 1 GB のブロックストレージを消費し、ディスクのサイズまで動的です。
- スナップショットのクローンを作成すると、元のディスクと同じサイズの新しいディスクが作成されます。
- スナップショットをコミットすると、チェーン内のどこでコミットが発生するかに応じて、すべての子ボリュームが削除されます。
- スナップショットを削除すると、最終的に各ディスクの子ボリュームが削除され、実行中の仮想マシンでのみサポートされます。
- スナップショットをプレビューすると、ディスクごとに一時ボリュームが作成されるため、プレビューを作成するために十分な容量が利用可能である必要があります。
- スナップショットプレビューを元に戻すと、プレビューによって作成された一時ボリュームが削除されます。
- 直接 LUN の接続および削除
- 直接 LUN はストレージドメインコンポーネントではないため、直接 LUN を接続および削除しても、ストレージドメインには影響しません。詳細は、管理ガイド の ライブストレージの移行の概要 を参照してください。
第3章 ネットワーク
3.1. ホストネットワーキング
データリンク層 (レイヤー 2) で RHV を使用すると、Linux ボンドを VLAN に接続し、ネットワークインターフェイスの MTU を定義できます。これらのネットワークは、Linux ブリッジを介して仮想マシンに共有できます。
SR-IOV の場合、仮想関数の数とそれらの論理ネットワークへのマッピングを設定できます。
FCoE は独自の VLAN を管理します。これらの FCoE マネージド VLAN は、ストレージアクセス専用に使用されます。これらは、マネージャーおよび仮想マシンからは見えません。
iSCSI は iSCSI ボンドを管理します。これらは、RHV の可視ホストネットワーク設定の一部ではありません。iSCSI ボンドなしで iSCSI を使用できます。これは、iSCSI ストレージの信頼性を向上させるためにのみ役立ちます。
クラスター内のすべてのホストは、管理ネットワークの IP スタックとして IPv4 または IPv6 のいずれかを使用する必要があります。デュアルスタックには対応していません。
ホストが使用する DNS リゾルバーを設定できます。
ネットワークのロールと QoS を管理することも可能です。
3.2. 仮想マシンのネットワークタイプ
RHV では、仮想マシンの仮想 NIC は次のタイプのネットワークに接続できます。
- Linux ブリッジ
- SR-IOV NIC
- RHV の内部 OVN
次の図は、これら 3 つのアプローチの構造を示しています。
- Host 1 は Linux ブリッジを表します。
- Host 2 は SR-IOV NIC を表します。
- Host 3 は OVN を表します。
Linux ブリッジ | SR-IOV | RHV 内部 OVN | |
---|---|---|---|
物理ホストネットワークからの分離 | レイヤー 3、個別の IP ネットワークが可能 | レイヤー 2、個別の VLAN が可能 | 分離 |
Live Migration | x | x | x |
QoS | x | ||
Port Mirroring | x | ||
プラグされた vNIC の設定 | x | x | |
MAC アドレス管理 | x | x | x |
MTU 伝播 | x | x | |
VLAN フィルタリング、物理スイッチでの設定が必要になる場合があります | x | x | テクノロジープレビュー |
MAC スプーフィング保護 | x | x | |
IP スプーフィング保護 | x | x | |
事前定義されたネットワークフィルター | x | ||
カスタムレイヤー 3/4 フィルタリング | x | ||
NAT | |||
DHCP/ ルーター広告 | x | ||
レイヤー 3 ルーター | x | ||
パフォーマンス |
|
|
|
仮想マシンネットワークデータのカプセル化 | フラット、VLAN | フラット、VLAN | 安定: GENEVE; テクノロジープレビュー: フラット、VLAN |
さまざまなシナリオでのネットワークの選択
Linux ブリッジがデフォルトであり、最も実績のあるオプションです。ほとんどのユースケースに適合します。
非常に低いネットワーク遅延または多数のイーサネットフレームを必要とするシナリオでは、SR-IOV への投資を検討してください。ただし、SR-IOV にはハードウェアサポートと追加の設定手順が必要であることに注意してください。
RHV の内部 OVN ネットワークにより、仮想マシンは手動のネットワーク設定なしで相互に通信できます。
Manager は、ソフトウェア定義ネットワーク (SDN) 機能とユーザーインターフェイスのサブセットのみを提供します。RHV の内部 OVN やサードパーティーの SDN と同様に、すべての SDN 機能を使用するには、CloudForms などの追加のクライアントを使用する必要があります。
1 つのホストですべてのネットワークタイプを組み合わせて、同じ仮想マシンに接続できます。
3.2.1. ゲストオペレーティングシステムとの相互作用
RHV は、cloud-init を介して設定データを提供することにより、仮想マシンの初期設定をサポートします。qemu-guest-agent が仮想マシン内で実行されている場合、RHV は仮想マシンの IP アドレスを報告できます。
仮想マシンが VirtIO NIC を使用する場合は、RHV 論理ネットワークの MTU がゲストオペレーティングシステムに提供されます。論理ネットワークがこれらのアドバタイズメントをサポートしている場合、ゲストオペレーティングシステムは DHCPv4 または IPv6 ルーターアドバタイズメントから MTU を取得できます。
3.2.2. ホストと仮想マシンのネットワーク
Linux ブリッジネットワークは、OSI レイヤー 3 で仮想マシンとホストネットワークを分離します。したがって、VLAN、ボンディング、MTU などのネットワーク設定は、ホストとその仮想マシン間で共有されます。
表面を減らすために、ホストは仮想マシンに接続されている VLAN に IP アドレスを割り当てないでください。IP アドレスを割り当てないことにより、ホストは仮想マシンのトラフィックによって引き起こされる潜在的な混乱を回避できます。
Linux ブリッジに関連付けられた IP アドレスは、接続にブリッジを使用する仮想マシンと同じサブネット内にある必要はありません。ブリッジに、ブリッジを使用する仮想マシンと同じサブネット上の IP アドレスが割り当てられている場合、ホストは仮想マシンによって論理ネットワーク内でアドレス指定できます。原則として、仮想化ホストでネットワーク公開サービスを実行することは推奨されません。
3.3. ネットワークアーキテクチャー
Red Hat Virtualization のネットワークには、基本的なネットワーク、クラスター内のネットワーク、およびホストネットワーク設定が含まれます。
- 基本的なネットワーキング
- ネットワーキングを容易にする基本的なハードウェアおよびソフトウェア要素。
- クラスター内のネットワーキング
- ホスト、論理ネットワーク、仮想マシンなどのクラスターオブジェクト間のネットワーク相互作用。
- ホストネットワーク設定
- ホスト内のネットワークでサポートされる設定。
適切に設計および構築されたネットワークにより、高帯域幅タスクが適切な帯域幅を受け取り、遅延がユーザーの操作に影響を与えず、仮想マシンを移行ドメイン内で正常に移行できるようになります。ネットワークの構築が不十分だと、許容できない遅延が発生し、ネットワークのフラッディングが原因で移行とクローン作成の失敗が発生する可能性があります。
ネットワークを管理する代替方法は、Cisco のドキュメント に従って、Cisco の Application Policy Infrastructure Controller (APIC) バージョン 3.1 (1) 以降に Red Hat Virtualization を設定して、Cisco Application Centric Infrastructure (ACI) と統合することです。Red Hat Virtualization 側では、必要なのはホストの NIC をネットワークに接続し、仮想マシンの vNIC を必要なネットワークに接続することだけです。残りの設定タスクは、Cisco ACI によって管理されます。
3.4. 基本的なネットワーク用語
Red Hat Virtualization は、以下を使用して、仮想マシン、仮想化ホスト、およびより広範なネットワーク間のネットワーク機能を提供します。
- 論理ネットワーク
- ネットワークインターフェイスコントローラー (NIC)
- Linux ブリッジ
- ボンド
- 仮想ネットワークインターフェイスコントローラー (vNIC)
- 仮想 LAN (VLAN)
NIC、Linux ブリッジ、および vNIC は、ホスト、仮想マシン、ローカルエリアネットワーク、およびインターネット間のネットワーク通信を可能にします。ボンドと VLAN は、セキュリティー、フォールトトレランス、およびネットワーク容量を強化するために任意で実装されます。
3.5. ネットワークインターフェイスコントローラー
ネットワークインターフェイスコントローラー (NIC) は、コンピューターをコンピューターネットワークに接続するネットワークアダプターまたは LAN アダプターです。NIC は、マシンの物理層とデータリンク層の両方で動作し、ネットワーク接続を可能にします。Red Hat Virtualization 環境のすべての仮想化ホストには少なくとも 1 つの NIC がありますが、ホストには 2 つ以上の NIC があるのが一般的です。
1 つの物理 NIC には、複数の仮想 NIC (vNIC) を論理的に接続できます。仮想 NIC は、仮想マシンのネットワークインターフェイスとして機能します。vNIC とそれをサポートする NIC を区別するために、Red Hat Virtualization マネージャーは各 vNIC に一意の MAC アドレスを割り当てます。
3.6. Linux ブリッジ
Linux ブリッジは、パケット交換ネットワークでパケット転送を使用するソフトウェアデバイスです。ブリッジングにより、複数のネットワークインターフェイスデバイスが 1 つの NIC の接続を共有し、ネットワーク上で個別の物理デバイスとして表示されます。ブリッジは、パケットの送信元アドレスを調べて、関連するターゲットアドレスを決定します。ターゲットアドレスが決定されると、ブリッジは将来の参照のために場所をテーブルに追加します。これにより、ホストはネットワークトラフィックをブリッジのメンバーである仮想マシンに関連付けられた vNIC にリダイレクトできます。
カスタムプロパティーは、ブリッジとイーサネット接続の両方に定義できます。VDSM は、ネットワーク定義とカスタムプロパティーをセットアップネットワークフックスクリプトに渡します。
3.7. ボンド
ボンドは、複数のネットワークインターフェイスカードを 1 つのソフトウェア定義デバイスにまとめたものです。ボンディングされたネットワークインターフェイスは、ボンディングに含まれるネットワークインターフェイスカードの伝送機能を組み合わせて単一のネットワークインターフェイスとして機能するため、単一のネットワークインターフェイスカードよりも高速な伝送速度を提供できます。また、ボンド自体が失敗するには、ボンド内のすべてのネットワークインターフェイスカードが失敗する必要があるため、ボンディングによってフォールトトレランスが向上します。ただし、1 つの制限は、ボンディングされたネットワークインターフェイスを形成するネットワークインターフェイスカードは、ボンド内のすべてのネットワークインターフェイスカードが同じオプションとモードをサポートするように、同じメーカーとモデルである必要があることです。
結合のパケット分散アルゴリズムは、使用される結合モードによって決定されます。
モード 1、2、3、および 4 は、仮想マシン (ブリッジ) と非仮想マシン (ブリッジレス) の両方のネットワークタイプをサポートします。モード 0、5、および 6 は、非仮想マシン (ブリッジレス) ネットワークのみをサポートします。
3.8. ボンディングモード
Red Hat Virtualization はデフォルトでモード 4 を使用しますが、以下の一般的なボンディングモードをサポートします。
Mode 0 (round-robin policy)
- ネットワークインターフェイスカードを介してパケットを順番に送信します。パケットは、ボンドで最初に使用可能なネットワークインターフェイスカードで始まり、ボンドで最後に使用可能なネットワークインターフェイスカードで終わるループで送信されます。その後のすべてのループは、最初に使用可能なネットワークインターフェイスカードから始まります。モード 0 はフォールトトレランスを提供し、ボンド内のすべてのネットワークインターフェイスカード間で負荷を分散します。ただし、モード 0 はブリッジと組み合わせて使用できないため、仮想マシンの論理ネットワークとの互換性はありません。
Mode 1 (active-backup policy)
- 1 枚のネットワークインターフェイスカードがアクティブなまま、すべてのネットワークインターフェイスカードをバックアップ状態に設定します。アクティブなネットワークインターフェイスカードに障害が発生した場合、バックアップネットワークインターフェイスカードの 1 つが、ボンド内の唯一のアクティブなネットワークインターフェイスカードとしてそのネットワークインターフェイスカードに置き換わります。モード 1 のボンドの MAC アドレスは、アクティブなネットワークインターフェイスカードの MAC アドレスを反映するようにボンドの MAC アドレスが変更された場合に発生する可能性のある混乱を防ぐために、1 つのポートにのみ表示されます。モード 1 はフォールトトレランスを提供し、Red Hat Virtualization でサポートされています。
Mode 2 (XOR policy)
-
ネットワークインターフェイスカードの
スレーブ
数をモジュロとして、送信元および宛先 MAC アドレスでの XOR 操作の結果に基づいて、パケットを送信するためのネットワークインターフェイスカードを選択します。この計算により、使用される宛先 MAC アドレスごとに同じネットワークインターフェイスカードが選択されるようになります。モード 2 は、フォールトトレランスと負荷分散を提供し、Red Hat Virtualization でサポートされています。 Mode 3 (broadcast policy)
- すべてのパケットをすべてのネットワークインターフェイスカードに送信します。モード 3 はフォールトトレランスを提供し、Red Hat Virtualization でサポートされています。
Mode 4 (IEEE 802.3ad policy)
- インターフェイスが同じ速度とデュプレックス設定を共有するアグリゲーショングループを作成します。モード 4 は、IEEE 802.3ad 仕様に従って、アクティブなアグリゲーショングループ内のすべてのネットワークインターフェイスカードを使用し、Red Hat Virtualization でサポートされます。
Mode 5 (adaptive transmit load balancing policy)
- 送信トラフィックの分散がボンド内の各ネットワークインターフェイスカードの負荷を考慮し、現在のネットワークインターフェイスカードがすべての受信トラフィックを受信するようにします。トラフィックの受信に割り当てられたネットワークインターフェイスカードに障害が発生した場合、別のネットワークインターフェイスカードが着信トラフィックの受信のロールに割り当てられます。モード 5 はブリッジと組み合わせて使用できないため、仮想マシンの論理ネットワークとは互換性がありません。
Mode 6 (adaptive load balancing policy)
- 特別なスイッチ要件なしで、モード 5 (適応型送信負荷分散ポリシー) と IPv4 トラフィックの受信負荷分散を組み合わせます。ARP ネゴシエーションは、受信負荷のバランスを取るために使用されます。モード 6 はブリッジと組み合わせて使用できないため、仮想マシンの論理ネットワークとは互換性がありません。
3.9. ボンディング用のスイッチ設定
スイッチの設定は、ハードウェアの要件によって異なります。オペレーティングシステムのデプロイメントおよびネットワーク設定ガイドを参照してください。
すべてのタイプのスイッチに関しては、Cisco Port Aggregation Protocol (PAgP) プロトコル ではなく、Link Aggregation Control Protocol (LACP) プロトコルを使用してスイッチボンディングを設定することが重要です。
3.10. 仮想ネットワークインターフェイスカード
仮想ネットワークインターフェイスカード (vNIC) は、ホストの物理 NIC に基づく仮想ネットワークインターフェイスです。各ホストは複数の NIC を持つことができ、各 NIC は複数の vNIC のベースになることができます。
vNIC を仮想マシンに接続すると、Red Hat Virtualization Manager は、vNIC が接続されている仮想マシン、vNIC 自体、および vNIC のベースとなる物理ホスト NIC の間にいくつかの関連付けを作成します。具体的には、vNIC が仮想マシンに接続されると、vNIC のベースとなる物理ホスト NIC に新しい vNIC と MAC アドレスが作成されます。次に、vNIC がアタッチされた後に仮想マシンの初回起動時に、libvirt
は PCI アドレスを vNIC に割り当てます。次に、MAC アドレスおよび PCI アドレスは、仮想マシンの vNIC の名前 (例: eth0
) の取得に使用されます。
テンプレートまたはスナップショットに基づいて仮想マシンを作成する場合、MAC アドレスを割り当ててそれらの MAC アドレスを PCI アドレスに関連付けるプロセスは少し異なります。
- テンプレートまたはスナップショットに対して PCI アドレスがすでに作成されている場合、そのテンプレートまたはスナップショットに基づいて作成された仮想マシン上の vNIC は、それらの PCI アドレスに従って順序付けられます。次に、MAC アドレスがこの順序で vNIC に割り当てられます。
- テンプレートの PCI アドレスがまだ作成されていない場合、そのテンプレートに基づいて作成された仮想マシン上の vNIC はアルファベット順に並べられます。次に、MAC アドレスがこの順序で vNIC に割り当てられます。
- スナップショットの PCI アドレスがまだ作成されていない場合、Red Hat Virtualization Manager は、そのスナップショットに基づいて仮想マシン上の vNIC に新しい MAC アドレスを割り当てます。
作成されると、vNIC はネットワークブリッジデバイスに追加されます。ネットワークブリッジデバイスは、仮想マシンを仮想論理ネットワークに接続します。
仮想化ホストで ip addr show
コマンドを実行すると、そのホスト上の仮想マシンに関連付けられているすべての vNIC が表示されます。また、論理ネットワークをバックアップするために作成されたネットワークブリッジ、およびホストによって使用される NIC も表示されます。
[root@rhev-host-01 ~]# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:21:86:a2:85:cd brd ff:ff:ff:ff:ff:ff inet6 fe80::221:86ff:fea2:85cd/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 00:21:6b:cc:14:6c brd ff:ff:ff:ff:ff:ff 5: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 4a:d5:52:c2:7f:4b brd ff:ff:ff:ff:ff:ff 6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 7: bond4: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 8: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 10: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 11: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:21:86:a2:85:cd brd ff:ff:ff:ff:ff:ff inet 10.64.32.134/23 brd 10.64.33.255 scope global ovirtmgmt inet6 fe80::221:86ff:fea2:85cd/64 scope link valid_lft forever preferred_lft forever
コマンドからのコンソール出力は、1 つのループバックデバイス (lo)、1 つのイーサネットデバイス (eth0)、1 つのワイヤレスデバイス (wlan0)、1 つの VDSM ダミーデバイス (;vdsmdummy;)、5 つのボンディングデバイス (bond0、bond4、bond1、bond2、bond3)、および 1 つのネットワークブリッジ (ovirtmgmt)) が表示されます。
vNIC は、すべてネットワークブリッジデバイスと論理ネットワークのメンバーです。ブリッジメンバーシップは、brctl show
コマンドを使用して表示できます。
[root@rhev-host-01 ~]# brctl show bridge name bridge id STP enabled interfaces ovirtmgmt 8000.e41f13b7fdd4 no vnet002 vnet001 vnet000 eth0
brctl show
コマンドの出力は、virtio vNIC が ovirtmgmt ブリッジのメンバーであることを示しています。vNIC が割り当てられているすべての仮想マシンが ovirtmgmt 論理ネットワークに接続されています。eth0 NIC は ovirtmgmt ブリッジのメンバーでもあります。eth0 デバイスはスイッチに接続され、ホスト外の接続を提供します。
3.11. 仮想 LAN (VLAN)
VLAN (仮想 LAN) は、ネットワークパケットに適用できる属性です。ネットワークパケットは、番号付き VLAN に "タグ付け" できます。VLAN は、スイッチレベルでネットワークトラフィックを分離するために使用されるセキュリティー機能です。VLAN は分離されており、相互に排他的です。Red Hat Virtualization Manager は VLAN に対応しており、VLAN トラフィックにタグを付けてリダイレクトできますが、VLAN の実装には、VLAN をサポートするスイッチが必要です。
スイッチレベルでは、ポートに VLAN 指定が割り当てられます。スイッチは、特定のポートから発信されたトラフィックに VLAN タグを適用し、トラフィックを VLAN の一部としてマークし、応答が同じ VLAN タグを確実に伝送するようにします。VLAN は、複数のスイッチにまたがって拡張できます。スイッチ上の VLAN タグ付きネットワークトラフィックは、正しい VLAN で指定されたポートに接続されているマシンを除いて検出できません。特定のポートを複数の VLAN にタグ付けすると、複数の VLAN からのトラフィックを単一のポートに送信し、トラフィックを受け取るマシンのソフトウェアを使用して解読することができます。
3.12. ネットワークラベル
ネットワークラベルを使用して、論理ネットワークの作成と管理、およびそれらの論理ネットワークを物理ホストネットワークインターフェイスとボンドに関連付けることに関連するいくつかの管理タスクを簡素化できます。
ネットワークラベルは、論理ネットワークまたは物理ホストネットワークインターフェイスに添付できる、プレーンテキストの人間が読める形式のラベルです。ラベルを作成するときは、次のルールに従ってください。
- ラベルの長さに制限はありません。
- 小文字と大文字、アンダースコア、ハイフンを組み合わせて使用する必要があります。
- 使用スペースや特殊文字は使用できません。
論理ネットワークまたは物理ホストネットワークインターフェイスにラベルを付けると、同じラベルが付けられている他の論理ネットワークまたは物理ホストネットワークインターフェイスとの関連付けが作成されます。
ネットワークラベルの関連付け
- 論理ネットワークにラベルを付けると、その論理ネットワークは、指定されたラベルを持つ物理ホストネットワークインターフェイスに自動的に関連付けられます。
- 物理ホストネットワークインターフェイスにラベルを付けると、指定されたラベルの論理ネットワークはすべて、その物理ホストネットワークインターフェイスに自動的に関連付けられます。
- 論理ネットワークまたは物理ホストネットワークインターフェイスに接続されているラベルを変更することは、ラベルを削除して新しいラベルを追加することと同じです。関連する論理ネットワークまたは物理ホストネットワークインターフェイス間の関連付けが更新されます。
ネットワークラベルとクラスター
- ラベル付きの論理ネットワークがクラスターに追加され、そのクラスター内に同じラベルの物理ホストネットワークインターフェイスがある場合、論理ネットワークはその物理ホストネットワークインターフェイスに自動的に追加されます。
- ラベル付き論理ネットワークがクラスターから切り離され、そのクラスター内に同じラベルの物理ホストネットワークインターフェイスがある場合、論理ネットワークはその物理ホストネットワークインターフェイスから自動的に切り離されます。
ネットワークラベルとロールを持つ論理ネットワーク
ラベル付き論理ネットワークがディスプレイネットワークまたは移行ネットワークとして機能するように割り当てられると、その論理ネットワークは DHCP を使用して物理ホストネットワークインターフェイス上に設定され、論理ネットワークに IP アドレスを割り当てることができます。
ロールネットワーク (たとえば、"移行ネットワーク" や "ディスプレイネットワーク") にラベルを設定すると、そのネットワークがすべてのホストに大量にデプロイメントされます。このようなネットワークの大量追加は、DHCP を使用して実現しています。多くの静的 IP アドレスを入力するタスクのスケーラブルでない性質のため、この大量デプロイメントの方法は、静的アドレスを入力する方法よりも選択されました。
3.13. クラスターネットワーク
クラスターレベルのネットワークオブジェクトには、次のものがあります。
- クラスター
- 論理ネットワーク
データセンターは複数のクラスターの論理グループであり、各クラスターは複数のホストの論理グループです。次の図は、1 つのクラスターの内容を示しています。
図3.1 クラスター内のネットワーキング
クラスター内のホストはすべて、同じストレージドメインにアクセスできます。クラスター内のホストには、クラスターに適用された論理ネットワークもあります。仮想マシンの論理ネットワークを仮想マシンで使用できるようにするには、Red Hat Virtualization Manager を使用して、クラスター内のホストごとにネットワークを定義および実装する必要があります。他の論理ネットワークタイプは、それらを使用するホストにのみ実装できます。
マルチホストネットワーク設定では、更新されたネットワーク設定を、ネットワークが割り当てられたデータセンター内のすべてのホストに自動適用します。
3.14. 論理ネットワーク
論理ネットワークにより、Red Hat Virtualization 環境はネットワークトラフィックをタイプ別に分離できます。たとえば、ovirtmgmt ネットワークは、Manager とホスト間の管理通信に使用される Red Hat Virtualization のインストール時にデフォルトで作成されます。論理ネットワークの一般的な使用法は、同様の要件と使用法を持つネットワークトラフィックをグループ化することです。多くの場合、ストレージネットワークとディスプレイネットワークは、最適化とトラブルシューティングのためにそれぞれのタイプのトラフィックを分離するために管理者によって作成されます。
Red Hat Virtualization は、以下の論理ネットワークタイプをサポートします。
- ストレージや移行トラフィックなどのホストネットワークトラフィックのみを伝送する論理ネットワーク
- ホストおよび仮想マシンのネットワークトラフィックを伝送する論理ネットワーク
- OVN ネットワークなど、仮想マシンネットワークトラフィックのみを伝送する論理ネットワーク
論理ネットワークはデータセンターレベルで定義されます。
必要に応じて、Red Hat Virtualization Manager は、仮想マシンネットワークのタイプに応じて、ホスト上の論理ネットワークを自動的にインスタンス化します。詳細は、仮想マシンのネットワーク種別 を参照してください。
例3.1 論理ネットワークの使用例。
システム管理者は、論理ネットワークを使用して Web サーバーをテストしたいと考えています。
Purple Data Center と呼ばれるデータセンターの Pink Cluster と呼ばれるクラスターには、Red Host と White Host と呼ばれる 2 つのホストがあります。Red Hat Host と White Host の両方が、すべてのネットワーク機能にデフォルトの論理ネットワーク ovirtmgmt を使用していました。Pink Cluster を担当するシステム管理者は、Web サーバーと一部のクライアント仮想マシンを別々の論理ネットワークに配置することにより、Web サーバーのネットワークテストを分離することを決定します。また、新しい論理ネットワーク test_logical_network を呼び出すようも決定します。
- VLAN タグ付けを有効にして Purple Data Center 用に、test_logical_network という名前の新規の論理ネットワークを作成します。同じ物理 NIC に 2 つの論理ネットワークが接続されている場合は、VLAN タギングが必要です。test_logical_network を Pink Cluster に適用します。
- Red Host では、test_logical_network を RHV が作成するブリッジに含まれる物理 NIC に割り当てます。Pink クラスターの各ホストに物理ネットワークインターフェイスを test_logical_network に追加することにより、ネットワークがクラスター内のすべてのホストに対応するブリッジを設定するまで、ネットワークは稼働しません。White Host に対してこのステップを繰り返します。White Host と Red Host の両方に、test_logical_network の論理ネットワークが物理ネットワークインターフェイスにブリッジされている場合、test_logical_network は動作し、仮想マシンで使用することができます。
- 彼女は、Red Host と White Host の仮想マシンを新しいネットワークに関連付けます。
3.15. 必須ネットワーク、任意のネットワーク、および仮想マシンネットワーク
必要なネットワークは、クラスター内のすべてのホストが使用できる必要がある論理ネットワークです。ホストに必要なネットワークが動作しなくなると、そのホストで実行されている仮想マシンが別のホストに移行されます。この移行の範囲は、選択したスケジューリングポリシーによって異なります。これは、ミッションクリティカルなワークロードを実行している仮想マシンがある場合に役立ちます。
任意のネットワークは、明示的に Required として宣言されていない論理ネットワークです。オプションのネットワークは、それらを使用するホストにのみ実装できます。任意のネットワークの有無に関わらず、ホストの 操作 ステータスには影響を及ぼしません。不要なネットワークが動作しなくなった場合、ネットワーク上で実行されている仮想マシンは別のホストに移行されません。これにより、大量の移行によって引き起こされる不要な I/O の過負荷を防ぎます。論理ネットワークが作成され、クラスターに追加されると、Required ボックスがデフォルトで選択されることに注意してください。
ネットワークの Required の指定を変更するには、管理ポータルからネットワークを選択し、Cluster タブをクリックして、Manage Networks ボタンをクリックします。
ユーザーインターフェイスの仮想マシンネットワークと呼ばれる 仮想マシンネットワーク は、仮想マシンのネットワークトラフィックのみを伝送するように指定された論理ネットワークです。仮想マシンネットワークは、必須または任意にすることができます。任意の仮想マシンネットワークを使用する仮想マシンは、そのネットワークを備えたホストでのみ起動します。
3.16. ポートミラーリング
ポートミラーリングは、特定の論理ネットワーク上のレイヤー 3 ネットワークトラフィックとホストを仮想マシン上の仮想インターフェイスにコピーします。この仮想マシンは、ネットワークのデバッグとチューニング、侵入検知、および同じホストと論理ネットワーク上の他の仮想マシンの動作の監視に使用できます。
コピーされる唯一のトラフィックは、1 つのホスト上の 1 つの論理ネットワークの内部です。ホストの外部のネットワーク上のトラフィックは増加しません。ただし、ポートミラーリングが有効になっている仮想マシンは、他の仮想マシンよりも多くのホスト CPU と RAM を使用します。
ポートミラーリングは、論理ネットワークの vNIC プロファイルで有効または無効にされており、次の制限があります。
- ポートミラーリングが有効になっているプロファイルを使用した vNIC のホットリンクはサポートされていません。
- vNIC プロファイルが仮想マシンに接続されている場合は、ポートミラーリングを変更することができません。
上記の制限があるため、追加の専用 vNIC プロファイルでポートミラーリングを有効にすることが推奨されます。
ポートミラーリングを有効にすると、他のネットワークユーザーのプライバシーが低下します。
3.17. ホストネットワーク設定
クラスターネットワーク は、これらのネットワーク設定を理解するのに役立ちます。
仮想化ホストのネットワーク設定の一般的なタイプは次のとおりです。
ブリッジと NIC の設定
この設定では、Linux ブリッジを使用して、1 つ以上の仮想マシンをホストの NIC に接続します。
この設定例は、Red Hat Virtualization Manager のインストール時に
ovirtmgmt
ネットワークの自動作成です。次に、ホストのインストール時に、Red Hat Virtualization Manager はホストに VDSM をインストールします。VDSM インストールプロセスでは、ホストの IP アドレスを取得するovirtmgmt
ブリッジを作成し、Manager との通信を有効にします。重要クラスター内のすべてのホストは、管理ネットワークの IP スタックとして IPv4 または IPv6 のいずれかを使用する必要があります。デュアルスタックには対応していません。
ブリッジ、VLAN、および NIC の設定
VLAN をブリッジと NIC の設定に含めることで、ネットワークを介したデータ転送のための安全なチャネルを提供し、複数の VLAN を使用して複数のブリッジを単一の NIC に接続することをサポートできます。
ブリッジ、ボンド、および VLAN の設定
ボンドは、2 つ (またはそれ以上) の物理イーサネットリンクを組み合わせた論理リンクを作成します。結果として得られる利点には、ボンディングモードに応じて、NIC のフォールトトレランスと潜在的な帯域幅の拡張が含まれます。
複数のブリッジ、複数の VLAN、および NIC の設定
この設定は、NIC を複数の VLAN に接続します。
たとえば、1 つの NIC を 2 つの VLAN に接続するために、2 つの VLAN の 1 つにタグ付けされたネットワークトラフィックを、ホスト上の 1 つの NIC に渡すようにネットワークスイッチを設定できます。ホストは 2 つの vNIC を使用して、VLAN ごとに 1 つずつ VLAN トラフィックを分離します。次に、いずれかの VLAN にタグ付けされたトラフィックは、適切な vNIC をブリッジメンバーとして使用することにより、別のブリッジに接続します。次に、各ブリッジは複数の仮想マシンに接続します。
注記複数の NIC を結合して、複数の VLAN との接続を容易にすることもできます。この設定の各 VLAN は、複数の NIC を構成するボンドを介して定義されます。各 VLAN は個々のブリッジに接続し、各ブリッジは 1 つ以上のゲストに接続します。
第4章 電源管理
4.1. 電力管理とフェンシングの概要
Red Hat Virtualization 環境は、電力管理とフェンシングが設定されている場合に最も柔軟で回復力があります。電源管理により、Red Hat Virtualization Manager はホストのパワーサイクル操作を制御できます。最も重要なのは、問題が検出されたホストを再起動することです。フェンシングは、パフォーマンスの低下を防ぐために、問題のあるホストを再起動することにより、機能している Red Hat Virtualization 環境から分離するために使用されます。フェンスで囲まれたホストは、管理者の操作によって応答状態に戻り、その環境に再統合できます。
電源管理とフェンシングは、ホストのオペレーティングシステムとは独立してホストを再起動するために、特別な専用ハードウェアを利用します。Red Hat Virtualization Manager は、ネットワーク IP アドレスまたはホスト名を使用して電力管理デバイスに接続します。Red Hat Virtualization のコンテキストでは、電源管理デバイスとフェンシングデバイスは同じものです。
4.2. Red Hat Virtualization の Proxy による電源管理
Red Hat Virtualization Manager は、フェンスエージェントと直接通信しません。その代わりに、Manager はプロキシーを使用してホストの電源管理デバイスに電源管理コマンドを送信します。Manager は VDSM を使用して電源管理デバイスのアクションを実行するため、環境内の別のホストをフェンシングプロキシーとして使用しています。
以下のいずれかを選択できます。
- フェンシングが必要なホストと同じクラスター内の任意のホスト。
- フェンシングが必要なホストと同じデータセンターにあるすべてのホスト。
実行可能なフェンシングプロキシーホストのステータスは UP または Maintenance のいずれかです。
4.3. 電源管理
Red Hat Virtualization Manager は、稼働していないか、応答しない状態になったホストを再起動することができ、また使用率の低いホストの電源をオフにして電力を節約することができます。この機能は、適切に設定された電源管理デバイスによって異なります。Red Hat Virtualization 環境は、以下の電力管理デバイスをサポートします。
-
American Power Conversion (
apc
) -
IBM Bladecenter (
Bladecenter
) -
Cisco Unified Computing System (
cisco_ucs
) -
Dell Remote Access Card 5 (
drac5
) -
Dell Remote Access Card 7 (
drac7
) -
Electronic Power Switch (
eps
) -
HP BladeSystem (
hpblade
) -
Integrated Lights Out (
ilo
,ilo2
,ilo3
,ilo4
) -
Intelligent Platform Management Interface (
ipmilan
) -
Remote Supervisor Adapter (
rsa
) -
Fujitsu-Siemens RSB (
rsb
) -
Western Telematic, Inc (
wti
)
HP サーバーは ilo3
または ilo4
を使用し、Dell サーバーは drac5
または Integrated Dell Remote Access Controller (idrac
) を使用し、IBM サーバーは ipmilan
を使用します。IMM (Integrated Management Module) は IPMI プロトコルを使用するため、IMM ユーザーは ipmilan
を使用できます。
APC 5.x の電源管理デバイスは、apc フェンスエージェントでは対応していません。代わりに apc_snmp フェンスエージェントを使用してください。
リストされている電力管理デバイスと通信するために、Red Hat Virtualization はフェンスエージェントを利用します。Red Hat Virtualization Manager を使用すると、管理者は、デバイスが受け入れて応答するパラメーターを使用して、環境内の電力管理デバイスのフェンスエージェントを設定できます。基本的な設定オプションは、グラフィカルユーザーインターフェイスを使用して設定できます。特別な設定オプションも入力でき、解析されずにフェンスデバイスに渡されます。特別な設定オプションは特定のフェンスデバイスに固有ですが、基本的な設定オプションは、サポートされているすべての電源管理デバイスによって提供される機能用です。すべての電力管理デバイスによって提供される基本的な機能は次のとおりです。
- ステータス: ホストのステータスを確認します。
- 起動: ホストの電源をオンにします。
- 停止: ホストの電源を切ります。
- 再起動: ホストを再起動します。実際には、停止、待機、ステータス、開始、待機、ステータスとして実装されます。
ベストプラクティスは、電源管理設定を最初に設定するときに 1 回テストし、その後、機能が継続することを確認するために時々テストすることです。
復元力は、環境内のすべてのホストで適切に設定された電源管理デバイスによって提供されます。フェンシングエージェントを使用すると、Red Hat Virtualization Manager はホストの電源管理デバイスと通信して、問題のあるホストのオペレーティングシステムをバイパスし、ホストを再起動して他の環境からホストを分離できます。その後、Manager は、問題のあるホストによって保持されていた場合、SPM のロールを再割り当てし、他のホストで可用性の高い仮想マシンを安全に再起動できます。
4.4. フェンシング
Red Hat Virtualization 環境のコンテキストでは、フェンシングは、Manager がフェンスエージェントを使用して開始し、電源管理デバイスによって実行されるホストの再起動です。フェンシングにより、クラスターは予期しないホスト障害に対応できるだけでなく、省電力、負荷分散、および仮想マシンの可用性ポリシーを適用できます。
フェンシングにより、Storage Pool Manager (SPM) のロールが常に機能しているホストに割り当てられます。フェンスで囲まれたホストが SPM であった場合、SPM のロールは放棄され、応答可能なホストに再割り当てされます。SPM のロールを持つホストは、データドメイン構造のメタデータを書き込むことができる唯一のホストであるため、応答がなく、フェンスで囲まれていない SPM ホストにより、環境は仮想ディスクの作成と破棄、スナップショットの作成、論理ボリュームの拡張、およびデータドメイン構造メタデータへの変更を必要とする他のすべてのアクションを行うことができなくなります。
ホストが応答しなくなると、そのホストで現在実行されているすべての仮想マシンも応答しなくなる可能性があります。ただし、応答しないホストは、実行中の仮想マシンの仮想マシンハードディスクイメージのロックを保持します。2 番目のホストで仮想マシンを起動し、仮想マシンのハードディスクイメージに 2 番目のホストの書き込み権限を割り当てようとすると、データが破損する可能性があります。
フェンシングにより、Red Hat Virtualization Manager は、仮想マシンのハードディスクイメージのロックが解除されたと見なすことができます。Manager は、フェンスエージェントを使用して、問題のあるホストが再起動されたことを確認できます。この確認を受け取ると、Red Hat Virtualization Manager は、データ破壊のリスクを冒すことなく、問題のあるホストから別のホスト上の仮想マシンを起動できます。フェンシングは、高可用性仮想マシンの基盤です。高可用性とマークされた仮想マシンは、データの破損を引き起こさないという確実性がなければ、代替ホストで安全に起動することはできません。
ホストが応答しなくなった場合、Red Hat Virtualization Manager は、アクションが実行される前に 30 秒の猶予期間が経過することを許可し、ホストが一時的なエラーから回復できるようにします。猶予期間が経過するまでにホストが応答しなくなった場合、Manager は応答しないホストからの悪影響を自動的に軽減し始めます。Manager は、ホストの電源管理カードのフェンシングエージェントを使用して、ホストを停止し、停止したことを確認し、ホストを開始し、ホストが開始されたことを確認します。ホストは起動を完了すると、フェンスで囲まれる前にその一部であったクラスターに再参加しようとします。ホストが応答しなくなる原因となっていた問題が再起動によって解決されている場合、ホストは自動的に Up ステータスに設定され、仮想マシンの起動とホスティングができるようになります。
4.5. ソフトフェンシングホスト
ホストは予期せぬ問題で応答しなくなることがありますが、VDSM は要求に応答できないものの、VDSM に依存している仮想マシンは稼働しており、アクセス可能です。このような場合は、VDSM を再起動することで VDSM が応答可能な状態に戻り、この問題が解決します。
"SSH Soft Fencing" とは、応答しないホストに対して Manager が SSH 経由で VDSM の再起動を試みるプロセスのことです。Manager が SSH 経由で VDSM の再起動に失敗した場合、外部フェンシングエージェントが設定されていれば、フェンシングの責任は外部フェンシングエージェントに移ります。
SSH でのソフトフェンシングは以下のように動作します。ホストでフェンシングを設定して有効にする必要があり、有効なプロキシーホスト (データセンター内の UP 状態の 2 番目のホスト) が存在する必要があります。Manager とホストの接続がタイムアウトすると、以下のようになります。
- 最初のネットワーク障害では、ホストの状態が "接続中" に変わります。
- その後、マネージャーは VDSM にステータスの問い合わせを 3 回試みるか、ホストの負荷に応じた間隔で待機します。間隔の長さを決定する式は、設定値 TimeoutToResetVdsInSeconds (デフォルトは 60 秒) + [DelayResetPerVmInSeconds (デフォルトは 0.5 秒)]*(ホスト上で実行している仮想マシンの数) + [DelayResetForSpmInSeconds (デフォルトは 20 秒)] * 1 (ホストが SPM として実行している場合) または 0 (ホストが SPM として実行されていない場合)。VDSM に最大応答時間を与えるために、Manager は上記の 2 つのオプションのうち長い方を選択します (VDSM のステータスまたは上記の式で決定された間隔を取得するための 3 回の試行)。
-
その間隔が経過してもホストが応答しない場合は、
vdsm restart
を SSH 経由で実行します。 -
vdsm restart
が行われても、ホストと Manager 間の接続が再度確立しない場合は、ホストのステータスがNon Responsive
に変わり、電源管理が設定されている場合はフェンシングが外部フェンシングエージェントに渡されます。
SSH を介したソフトフェンシングは、電源管理が設定されていないホストで実行できます。これはフェンシングとは異なります。フェンシングは、電源管理が設定されているホストでのみ実行できます。
4.6. 複数の電力管理フェンシングエージェントの使用
シングルエージェントはプライマリーエージェントとして扱われます。セカンダリーエージェントは、フェンシングエージェントが 2 つある場合に有効です。たとえば、各電源スイッチに 2 つのエージェントが同じ電源スイッチに接続されているデュアル電源ホストの場合です。エージェントは、同じタイプでも異なるタイプでもかまいません。
ホストに複数のフェンシングエージェントを配置すると、フェンシング手順の信頼性が向上します。たとえば、ホスト上の唯一のフェンシングエージェントに障害が発生した場合、ホストは手動で再起動されるまで非動作状態のままになります。以前にホストで実行していた仮想マシンは一時停止となり、元のホストが手動でフェンスされた後にのみ、クラスター内の別のホストにフェイルオーバーします。複数のエージェントがあり、最初のエージェントに障害が発生した場合は、次のエージェントを呼び出すことができます。
2 つのフェンシングエージェントがホストで定義されている場合、それらは同時フローまたは順次フローを使用するように設定できます。
- 同時: プライマリーエージェントとセカンダリーエージェントの両方が、ホストを停止するために Stop コマンドに応答する必要があります。1 つのエージェントが開始コマンドに応答すると、ホストが起動します。
- 順次: ホストを停止または起動するには、プライマリーエージェントが最初に使用され、失敗した場合はセカンダリーエージェントが使用されます。
第5章 負荷分散、スケジューリング、および移行
5.1. 負荷分散、スケジューリング、および移行
個々のホストには有限のハードウェアリソースがあり、障害が発生しやすくなっています。障害とリソースの枯渇を軽減するために、ホストはクラスターにグループ化されます。クラスターは、基本的に共有リソースのグループです。Red Hat Virtualization 環境は、負荷分散ポリシー、スケジューリング、および移行を使用して、ホストリソースの需要の変化に対応します。Manager は、クラスター内の単一のホストがそのクラスター内のすべての仮想マシンを担当しないようにすることができます。逆に、Manager は十分に活用されていないホストを認識し、そこからすべての仮想マシンを移行できるため、管理者はそのホストをシャットダウンして電力を節約できます。
次の 3 つのイベントの結果として、使用可能なリソースがチェックされます。
- 仮想マシンの起動 - リソースがチェックされ、仮想マシンが起動するホストが決定されます。
- 仮想マシンの移行 - 適切なターゲットホストを決定するために、リソースがチェックされます。
- 時間の経過 - リソースは定期的にチェックされ、個々のホストの負荷がクラスターの負荷分散ポリシーに準拠しているかどうかが判断されます。
Manager は、クラスターの負荷分散ポリシーを使用して、クラスター内の 1 つのホストから別のホストへの仮想マシンの移行をスケジュールすることにより、使用可能なリソースの変更に応答します。次のセクションでは、負荷分散ポリシー、スケジューリング、および仮想マシンの移行の関係を説明します。
5.2. 負荷分散ポリシー
負荷分散ポリシーはクラスターに設定されます。クラスターには、それぞれ異なるハードウェアパラメーターと使用可能なメモリーを持つ 1 つ以上のホストが含まれます。Red Hat Virtualization Manager は、負荷分散ポリシーを使用して、クラスター内のどのホストで仮想マシンを起動するかを決定します。負荷分散ポリシーにより、Manager は、仮想マシンを使用率の高いホストから使用率の低いホストにいつ移動するかを決定することもできます。
負荷分散プロセスは、データセンター内のクラスターごとに 1 分ごとに実行されます。これは、どのホストが過剰に使用されているか、どのホストが十分に使用されていないか、および仮想マシンの移行の有効なターゲットであるかを判別します。決定は、特定のクラスターの管理者によって設定された負荷分散ポリシーに基づいて行われます。負荷分散ポリシーのオプションは、VM_Evenly_Distributed、Evenly_Distributed、Power_Saving、Cluster_Maintenance、および None です。
5.3. 負荷分散ポリシー: VM_Evenly_Distributed
仮想マシンの均等分散ロードバランシングポリシーは、仮想マシンの数に基づいて、仮想マシンをホスト間で均等に分散します。高い仮想マシン数は、各ホストで実行できる仮想マシンの最大数であり、それを超えると、ホストの過負荷と見なされます。VM_Evenly_Distributed ポリシーを使用すると、管理者はホストに高い仮想マシン数を設定できます。最も使用率の高いホストと最も使用率の低いホスト間の仮想マシン数の最大包括的差異も、管理者によって設定されます。クラスターのすべてのホストが移行しきい値内に留まる仮想マシン数がある場合、クラスターが分散されます。管理者は、SPM ホストで予約する仮想マシンのスロット数も設定します。SPM ホストの負荷は他のホストよりも低いため、この変数は、実行できる仮想マシンの数を他のホストよりも少なく定義します。いずれかのホストが高い仮想マシン数よりも多くの仮想マシンを実行していて、少なくとも 1 つのホストの仮想マシン数が移行しきい値の範囲外である場合、仮想マシンは CPU が最も少ないクラスター内のホストに 1 つずつ移行されます。クラスター内のすべてのホストの仮想マシン数が移行しきい値内に収まるまで、一度に 1 台の仮想マシンが移行されます。
5.4. 負荷分散ポリシー: Evenly_Distributed
図5.1 Evenly Distributed スケジューリングポリシー
均等に分散された負荷分散ポリシーは、最小の CPU 負荷または最大の使用可能なメモリーに従って新しい仮想マシンのホストを選択します。クラスター内のホストに設定された時間許可される最大 CPU 負荷と最小使用可能メモリーは、均等に分散されたスケジューリングポリシーのパラメーターによって定義されます。これらの制限を超えると、環境のパフォーマンスが低下します。均等に分散されたポリシーにより、管理者は仮想マシンを実行するためにこれらのレベルを設定できます。ホストが定義された最大 CPU 負荷または最小使用可能メモリーに達し、ホストが設定された時間より長くそこにとどまる場合、そのホスト上の仮想マシンは、どのパラメーターが利用されているかによって、クラスター内の最小 CPU または最大利用メモリーを持つホストに 1 つずつ移行されます。ホストリソースは 1 分に 1 回チェックされ、ホストの CPU 負荷が定義された制限を下回るか、ホストの使用可能なメモリーが定義された制限を超えるまで、一度に 1 つの仮想マシンが移行されます。
5.5. 負荷分散ポリシー: Power_Saving
図5.2 Power Saving スケジューリングポリシー
省電力の負荷分散ポリシーは、最小の CPU または最大の使用可能なメモリーに従って、新しい仮想マシンのホストを選択します。クラスター内のホストに設定された時間許可される最大 CPU 負荷と最小使用可能メモリーは、省電力スケジューリングポリシーのパラメーターによって定義されます。これらの制限を超えると、環境のパフォーマンスが低下します。省電力パラメーターは、ホストの継続的な動作が非効率的な電力使用と見なされる前に、クラスター内のホストに設定された時間だけ許可される最小 CPU 負荷と最大使用可能メモリーも定義します。ホストが最大 CPU 負荷または最小使用可能メモリーに達し、設定された時間より長くそこにとどまる場合、そのホスト上の仮想マシンは、どのパラメーターが利用されているかによって、最小 CPU または最大利用メモリーを持つホストに 1 つずつ移行されます。ホストリソースは 1 分に 1 回チェックされ、ホストの CPU 負荷が定義された制限を下回るか、ホストの使用可能なメモリーが定義された制限を超えるまで、一度に 1 つの仮想マシンが移行されます。ホストの CPU 負荷が定義された最小レベルを下回るか、ホストの使用可能なメモリーが定義された最大レベルを超える場合、クラスター内の他のホストが最大 CPU 負荷を下回っていて、最小使用可能メモリーを超えている限り、そのホスト上の仮想マシンはクラスター内の他のホストに移行されます。十分に活用されていないホストから残りの仮想マシンが削除されると、Manager は自動的にホストマシンの電源を切り、負荷分散が必要な場合、またはクラスター内に十分な空きホストがない場合にホストを再起動します。
5.6. 負荷分散ポリシー: なし
負荷分散ポリシーが選択されていない場合、仮想マシンは、CPU 使用率と使用可能なメモリーが最も少ないクラスター内のホストで起動します。CPU 使用率を決定するために、仮想 CPU カウントと CPU 使用率を考慮した複合メトリックが使用されます。ホストの選択ポイントは新しい仮想マシンの起動時のみであるため、このアプローチは最も動的ではありません。ホストに対する需要の増加を反映するために、仮想マシンは自動的に移行されません。
管理者は、どのホストが特定の仮想マシンの適切な移行ターゲットであるかを決定する必要があります。仮想マシンは、ピン留めを使用して特定のホストに関連付けることもできます。固定すると、仮想マシンが他のホストに自動的に移行されなくなります。リソースが大量に消費される環境では、手動移行が最善のアプローチです。
5.7. 負荷分散ポリシー: Cluster_Maintenance
クラスターメインテンススケジューリングポリシーは、メンテナンスタスク時にクラスター内のアクティビティーを制限します。クラスターメンテナンスポリシーが設定されている場合:
- 高可用性の仮想マシンを除き、新規の仮想マシンを起動することはできません。(ユーザーは、可用性の高い仮想マシンを作成して手動で起動できます。)
- ホストの障害が発生した場合、高可用性仮想マシンが正しく再起動し、どの仮想マシンも移行できます。
5.8. 高可用性仮想マシンの予約
高可用性 (HA) 仮想マシン予約ポリシーにより、Red Hat Virtualization Manager は高可用性仮想マシンのクラスター容量を監視できます。Manager には、個々の仮想マシンに高可用性のフラグを立てる機能があります。つまり、ホストに障害が発生した場合、これらの仮想マシンは代替ホストで再起動されます。このポリシーは、クラスター内のホスト間で高可用性の仮想マシンのバランスを取ります。クラスター内のいずれかのホストに障害が発生した場合、残りのホストは、クラスターのパフォーマンスに影響を与えることなく、可用性の高い仮想マシンの移行負荷をサポートできます。高可用性仮想マシンの予約が有効になっている場合、Manager は、既存のホストに予期しない障害が発生した場合に HA 仮想マシンが移行するための適切な容量がクラスター内に存在することを確認します。
5.9. スケジューリング
Red Hat Virtualization では、スケジューリングとは、Red Hat Virtualization Manager がクラスター内のホストを新規または移行された仮想マシンのターゲットとして選択する方法を指します。
ホストが仮想マシンを起動したり、別のホストから移行された仮想マシンを受け入れたりする資格を得るには、ホストで起動または移行される仮想マシンの要件をサポートするのに十分な空きメモリーと CPU が必要です。仮想マシンは、CPU が過負荷状態のホストでは起動しません。デフォルトでは、ホストの CPU に 5 分間 80% 以上の負荷がかかった場合に過負荷と判断されますが、この値はスケジューリングポリシーを使用して変更できます。複数のホストが適格なターゲットである場合は、クラスターの負荷分散ポリシーに基づいて 1 つが選択されます。たとえば、Evenly_Distributed ポリシーが有効な場合、Manager は CPU 使用率が最も低いホストを選択します。Power_Saving ポリシーが有効な場合は、最大サービスレベルと最小サービスレベルの間で CPU 使用率が最も低いホストが選択されます。特定のホストの Storage Pool Manager (SPM) ステータスも、仮想マシンまたは仮想マシンの移行を開始するためのターゲットとしての適格性に影響します。非 SPM ホストが優先ターゲットホストです。たとえば、クラスターで開始された最初の仮想マシンは、SPM のロールがそのクラスター内のホストによって保持されている場合、SPM ホスト上で実行されません。
詳細は、管理ガイド の スケジュールポリシー を参照してください。
5.10. Migration
Red Hat Virtualization Manager は、移行を使用してクラスターの負荷分散ポリシーを適用します。仮想マシンの移行は、クラスターの負荷分散ポリシーとクラスター内のホストに対する現在の要求に従って行われます。移行は、ホストがフェンスされているとき、またはメンテナンスモードに移行したときに自動的に発生するように設定することもできます。Red Hat Virtualization Manager は、最初に CPU 使用率が最も低い仮想マシンを移行します。これはパーセンテージとして計算され、I/O 操作が CPU 使用率に影響を与える場合を除いて、RAM 使用量または I/O 操作は考慮されません。同じ CPU 使用率の仮想マシンが複数ある場合、最初に移行されるのは、仮想マシンの CPU 使用率を決定するために Red Hat Virtualization Manager によって実行されるデータベースクエリーによって返される最初の仮想マシンです。
仮想マシンの移行には、デフォルトで次の制限があります。
- 各仮想マシンの移行には、52 MiBps の帯域幅制限が課せられます。
- 移行は、仮想マシンメモリーの GB あたり 64 秒後にタイムアウトになります。
- 進行が 240 秒間停止すると、移行は中止されます。
- 同時送信移行は、ホストごとの CPU コアごとに 1 つ、または 2 つのうち小さい方に制限されます。
移行設定の調整の詳細は vdsm.conf のライブマイグレーションの "migration_max_bandwidth" および "max_outgoing_migrations" パラメーターについて を参照してください。
第6章 ディレクトリーサービス
6.1. ディレクトリーサービス
Red Hat Virtualization プラットフォームは、ユーザーの認証と承認をディレクトリーサービスに依存しています。VM ポータル、管理ポータル、REST API を含むすべての Manager インターフェイスとの対話は、認証され、許可されたユーザーに制限されます。Red Hat Virtualization 環境内の仮想マシンは、同じディレクトリーサービスを使用して認証と承認を提供できますが、そうするように設定する必要があります。Red Hat Virtualization Manager で使用するために現在サポートされているディレクトリーサービスのプロバイダーは、Identity Management (IdM)、Red Hat Directory Server 9 (RHDS)、Active Directory (AD)、および OpenLDAP です。Red Hat Virtualization Manager は、以下のディレクトリーサーバーとインターフェイスします。
- ポータルログイン (ユーザー、パワーユーザー、管理者、REST API)。
- ユーザー情報を表示するためのクエリー。
- Manager をドメインに追加します。
認証とは、一部のデータを生成した当事者の検証と識別、および生成されたデータの整合性の検証です。プリンシパルは、身元が確認された当事者です。検証者は、本人の身元の保証を要求する当事者です。Red Hat Virtualization の場合は、Manager がベリファイアであり、ユーザーがプリンシパルです。データの整合性とは、受信したデータがプリンシパルによって生成されたデータと同じであることを保証することです。
機密性と承認は認証と密接に関連しています。機密保持は、データを受け取ることを意図していない人への開示からデータを保護します。強力な認証方法は、任意で機密性を提供できます。承認は、プリンシパルが操作を実行できるかどうかを決定します。Red Hat Virtualization は、ディレクトリーサービスを使用してユーザーをロールに関連付け、それに応じて認証を提供します。承認は通常、プリンシパルが認証された後に実行され、ベリファイアのローカルまたはリモートの情報に基づく場合があります。
インストール中に、ローカルの内部ドメインが Red Hat Virtualization 環境の管理用に自動的に設定されます。インストールが完了したら、さらにドメインを追加できます。
6.2. ローカル認証: 内部ドメイン
Red Hat Virtualization Manager は、インストール中に限定された内部管理ドメインを作成します。このドメインは、ディレクトリーサーバー上のディレクトリーサービスユーザーとしてではなく、Red Hat Virtualization PostgreSQL データベースのキーに基づいて存在するため、AD または IdM ドメインと同じではありません。内部ドメインにはユーザーが 1 人 (admin@internal ユーザー) しかないため、内部ドメインは外部ドメインとは異なります。このアプローチを初期認証に採用することで、完全で機能的なディレクトリーサーバーを必要とせずに Red Hat Virtualization を評価でき、外部ディレクトリーサービスの問題をトラブルシューティングするための管理者アカウントを利用できるようになります。
admin@internal ユーザーは、環境の初期設定用です。これには、ホストのインストールと受け入れ、外部 AD または IdM 認証ドメインの追加、外部ドメインからのユーザーへのアクセス許可の委任が含まれます。
6.3. GSSAPI を使用したリモート認証
Red Hat Virtualization のコンテキストでは、リモート認証とは、Red Hat Virtualization Manager ではなく、リモートサービスによって処理される認証を指します。リモート認証は、AD、IdM、または RHDS ドメイン内から Manager に到達するユーザーまたは API 接続に使用されます。Red Hat Virtualization Manager は、管理者が engine-manage-domains ツールを使用して RHDS、AD、または IdM ドメインの一部であるように設定する必要があります。これには、システムをドメインに参加させるのに十分な特権を持つ、ドメインの RHDS、AD、または IdM ディレクトリーサーバーからのアカウントの認証情報をマネージャーに提供する必要があります。ドメインが追加された後、ドメインユーザーは、パスワードを使用してディレクトリーサーバーに対して Red Hat Virtualization Manager によって認証されます。Manager は、Simple Authentication and Security Layer (SASL) と呼ばれるフレームワークを使用します。SASL は、Generic Security Services Application Program Interface (GSSAPI) を使用して、ユーザーの ID を安全に検証し、ユーザーが使用できる承認レベルを確認します。
図6.1 GSSAPI 認証
第7章 テンプレートおよびプール
7.1. テンプレートおよびプール
Red Hat Virtualization 環境は、ユーザーへの仮想マシンのプロビジョニングを簡素化するツールを管理者に提供します。これらはテンプレートとプールです。テンプレートは、管理者がオペレーティングシステムのインストールと設定をバイパスして、既存の事前設定された仮想マシンに基づいて新しい仮想マシンをすばやく作成できるようにするショートカットです。これは、アプライアンスのように使用される仮想マシン、たとえば Web サーバー仮想マシンに特に役立ちます。組織が特定の Web サーバーの多くのインスタンスを使用する場合、管理者は、テンプレートとして使用される仮想マシンを作成し、オペレーティングシステム、Web サーバー、サポートパッケージをインストールし、固有の設定変更を適用できます。管理者は、必要に応じて新しい同一の仮想マシンを作成するために使用される、動作中の仮想マシンに基づいてテンプレートを作成できます。
仮想マシンプールは、ユーザーに迅速にプロビジョニングできる特定のテンプレートに基づく仮想マシンのグループです。プール内で仮想マシンを使用するためのアクセス許可は、プールレベルで付与されます。プールを使用する権限が付与されたユーザーには、プールから任意の仮想マシンが割り当てられます。仮想マシンプールに内在するのは、その中の仮想マシンの一時的な性質です。ユーザーには、過去にプール内のどの仮想マシンを使用したかに関わらず仮想マシンが割り当てられるため、プールはデータの永続性を必要とする目的には適していません。仮想マシンプールは、ユーザーデータが中央の場所に保存され、仮想マシンがそのデータにアクセスして使用する手段である場合、またはデータの永続性が重要でない場合に最適です。プールを作成すると、プールに配置される仮想マシンが停止状態で作成されます。これらは、ユーザーの要求に応じて開始されます。
7.2. テンプレート
テンプレートを作成するには、管理者が仮想マシンを作成してカスタマイズします。必要なパッケージがインストールされ、カスタマイズされた設定が適用され、デプロイ後に仮想マシンに加える必要のある変更を最小限に抑えるために、仮想マシンがその意図された目的のために準備されます。仮想マシンからテンプレートを作成する前の (任意ですが推奨される) 手順は一般化です。一般化は、デプロイ時に変更されるシステムユーザー名、パスワード、タイムゾーン情報などの詳細を削除するために使用されます。一般化は、カスタマイズされた設定には影響しません。Red Hat Virtualization 環境の Windows および Linux ゲストの概要については、仮想マシン管理ガイド の テンプレート を参照してください。Red Hat Enterprise Linux ゲストは、sys-unconfig
を使用して一般化されています。Windows ゲストは、sys-prep
を使用して一般化されます。
テンプレートの基礎を提供する仮想マシンが十分に設定され、必要に応じて一般化され、停止されると、管理者は仮想マシンからテンプレートを作成できます。仮想マシンからテンプレートを作成すると、特別に設定された仮想ディスクの読み取り専用コピーが作成されます。読み取り専用イメージは、そのテンプレートに基づいて後で作成されるすべての仮想マシンのバッキングイメージを形成します。つまり、テンプレートは基本的に、仮想ハードウェア設定が関連付けられた、カスタマイズされた読み取り専用仮想ディスクです。テンプレートから作成された仮想マシンでハードウェアを変更できます。たとえば、1 ギガバイトの RAM を持つテンプレートから作成された仮想マシンに 2 ギガバイトの RAM をプロビジョニングします。ただし、テンプレート仮想ディスクは変更できません。変更すると、テンプレートに基づいてすべての仮想マシンが変更されるためです。
テンプレートが作成されると、複数の仮想マシンのベースとして使用できます。仮想マシンは、シン プロビジョニング方式、または クローン プロビジョニング方法を使用して、指定のテンプレートから作成されます。テンプレートから複製された仮想マシンは、テンプレートベースイメージの完全な書き込み可能コピーを取得し、テンプレートの存在に依存しなくなる代わりに、シン作成方法のスペース節約を犠牲にします。シンメソッドを使用してテンプレートから作成された仮想マシンは、テンプレートからの読み取り専用イメージをベースイメージとして使用するため、テンプレートとそれから作成されたすべての仮想マシンを同じストレージドメインに格納する必要があります。データへの変更および新しく生成されたデータは、コピーオンライトイメージに保存されます。テンプレートに基づく各仮想マシンは、同じベースの読み取り専用イメージと、仮想マシンに固有のコピーオンライトイメージを使用します。これにより、同一のデータがストレージに保持される回数が制限されるため、ストレージを節約できます。さらに、読み取り専用のバッキングイメージを頻繁に使用すると、アクセスされているデータがキャッシュされ、正味のパフォーマンスが向上する可能性があります。
7.3. Pools
仮想マシンプールを使用すると、デスクトップとしてユーザーに多数の同一の仮想マシンを迅速にプロビジョニングできます。プールから仮想マシンにアクセスして使用する権限を付与されたユーザーは、要求のキュー内の位置に基づいて、使用可能な仮想マシンを受け取ります。プール内の仮想マシンは、データの永続性を許可しません。仮想マシンがプールから割り当てられるたびに、仮想マシンは基本状態で割り当てられます。これは、ユーザーデータが一元的に保存されている状況での使用に最適です。
仮想マシンプールはテンプレートから作成されます。プール内の各仮想マシンは、同じバッキング読み取り専用イメージを使用し、一時的なコピーオンライトイメージを使用して、変更されたデータと新しく生成されたデータを保持します。プール内の仮想マシンは、ユーザーが生成および変更したデータを保持するコピーオンライトレイヤーがシャットダウン時に失われるという点で、他の仮想マシンとは異なります。これは、仮想マシンプールが、それをサポートするテンプレートよりも多くのストレージと、使用中に生成または変更されたデータ用の領域を必要としないことを意味します。仮想マシンプールは、各ユーザーに専用の仮想デスクトップを提供するためのストレージコストをかけずに、一部のタスクでユーザーにコンピューティングパワーを提供する効率的な方法です。
例7.1 プールの使用例
テクニカルサポート会社は 10 人のヘルプデスクスタッフを雇用しています。ただし、常に 5 つだけが機能しています。ヘルプデスクの従業員ごとに 1 つずつ、合計 10 台の仮想マシンを作成する代わりに、5 台の仮想マシンのプールを作成できます。ヘルプデスクの従業員は、シフトの開始時に仮想マシンを割り当て、終了時にそれをプールに戻します。
第8章 仮想マシンのスナップショット
8.1. Snapshots
スナップショットは、管理者が特定の時点で仮想マシンのオペレーティングシステム、アプリケーション、およびデータの復元ポイントを作成できるようにするストレージ機能です。スナップショットは、仮想マシンのハードディスクイメージに現在存在するデータを COW ボリュームとして保存し、スナップショットの作成時に存在していたデータへの復元を可能にします。スナップショットにより、現在のレイヤー上に新しい COW レイヤーが作成されます。スナップショットが作成された後に実行されるすべての書き込みアクションは、新しい COW レイヤーに書き込まれます。
仮想マシンのハードディスクイメージは 1 つ以上のボリュームのチェーンであることを理解することが重要です。仮想マシンの観点からは、これらのボリュームは単一のディスクイメージとして表示されます。仮想マシンは、そのディスクが複数のボリュームで構成されているという事実に気づいていません。
COW ボリュームと COW レイヤーという用語は同じ意味で使用されますが、レイヤーはスナップショットの時間的性質をより明確に認識します。各スナップショットが作成され、管理者はスナップショットの作成 後 にデータに加えられた不適切な変更を破棄します。スナップショットは、多くのワードプロセッサーに存在する Undo 関数と同様の機能を提供します。
共有可能とマークされた仮想マシンのハードディスクのスナップショット、および直接 LUN接続に基づくスナップショットは、ライブまたはその他の方法でサポートされていません。
3 つの主要なスナップショット操作は次のとおりです。
- 作成。仮想マシン用に作成された最初のスナップショットが含まれます。
- プレビュー。スナップショットをプレビューして、スナップショットが作成された時点にシステムデータを復元するかどうかを決定します。
- 削除。これには、不要になった復元ポイントの削除が含まれます。
スナップショット操作に関するタスクベースの情報は、Red Hat Virtualization 仮想マシン管理ガイド の スナップ を参照してください。
8.2. Red Hat Virtualization のライブスナップショット
共有可能とマークされた仮想マシンのハードディスクのスナップショット、および直接 LUN接続に基づくスナップショットは、ライブまたはその他の方法でサポートされていません。
複製または移行されていない他の仮想マシンは、実行中、一時停止中、または停止時にスナップショットを取得できます。
仮想マシンのライブスナップショットが開始すると、マネージャーは、SPM ホストが仮想マシンが使用する新しいボリュームを作成するように要求します。新しいボリュームの準備ができると、Manager は VDSM を使用して、仮想マシンを実行しているホスト上の libvirt および qemu と通信し、仮想マシンの書き込み操作に新しいボリュームの使用を開始する必要があります。仮想マシンが新しいボリュームに書き込める場合、スナップショット操作は成功したと見なされ、仮想マシンは前のボリュームへの書き込みを停止します。仮想マシンが新しいボリュームに書き込めない場合、スナップショット操作は失敗と見なされ、新しいボリュームが削除されます。
仮想マシンは、ライブスナップショットが開始してから新しいボリュームの準備が整うまで、現在のボリュームと新しいボリュームの両方にアクセスする必要があるため、両方のボリュームが読み取り/書き込みアクセスで開かれます。
静止をサポートするゲストエージェントがインストールされている仮想マシンは、スナップショット全体でファイルシステムの一貫性を確保できます。登録済みの Red Hat Enterprise Linux ゲストは qemu-guest-agent をインストールして、スナップショットの前に休止を有効にできます。
スナップショットの作成時に静止互換のゲストエージェントが仮想マシンに存在する場合、VDSM は libvirt を使用してエージェントと通信し、スナップショットの準備をします。未処理の書き込みアクションが完了すると、スナップショットが作成される前にファイルシステムがフリーズになります。スナップショットが完了し、libvirt が仮想マシンをディスク書き込みアクション用の新しいボリュームに切り替えると、ファイルシステムが解凍され、ディスクへの書き込みが再開されます。
静止を有効にして試行されたすべてのライブスナップショット。互換性のあるゲストエージェントが存在しないために snapshot コマンドが失敗すると、ライブスナップショットは use-quiescing フラグなしで再度開始します。仮想マシンが静止ファイルシステムでスナップショット前の状態に戻ると、ファイルシステムチェックを必要とせずに正常に起動します。静止していないファイルシステムを使用して以前のスナップショットを元に戻すには、起動時にファイルシステムをチェックする必要があります。
8.3. スナップショットの作成
Red Hat Virtualization では、仮想マシンの初期スナップショットは、初期スナップショットが QCOW2 または raw のいずれかの形式を保持するという点で後続のスナップショットとは異なります。仮想マシンの最初のスナップショットは、既存のボリュームをベースイメージとして使用します。追加のスナップショットは、前のスナップショット以降にイメージに保存されたデータに加えられた変更を追跡する追加の COW レイヤーです。
初期スナップショットの作成 にあるように、スナップショットの作成により、仮想ディスクを構成するボリュームが、その後のすべてのスナップショットのベースイメージとして機能するようになります。
図8.1 最初のスナップショットの作成
最初のスナップショットの後に作成されたスナップショットは、スナップショットの作成後に作成または変更されたデータが保存される新しい COW ボリュームの作成につながります。新しく作成された各 COW レイヤーには、COW メタデータのみが含まれます。スナップショットの作成後に仮想マシンを使用して操作することによって作成されたデータは、この新しい COW レイヤーに書き込まれます。仮想マシンを使用して前の COW レイヤーに存在するデータを変更すると、データは前のレイヤーから読み取られ、最新のレイヤーに書き込まれます。仮想マシンは、仮想マシンに対して透過的に、最新から最古までの各 COW レイヤーをチェックすることによってデータを検索します。
図8.2 追加のスナップショットの作成
8.4. イメージ不一致ツールを使用したスナップショットの状態の監視
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに引き継がないようにします。
- ストレージ操作に失敗した後、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後に使用します。
- 定期的に、問題が悪化する前に潜在的な問題を検出しあす。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン。このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7ev
の RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止する。つまり、スナップショットの作成や削除、ディスクの編集、移動、作成、削除は行わないでください。行った場合、不一致の誤検出が発生する可能性があります。プロセス中、仮想マシンは正常に動作し続けることができます。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
# rhv-image-discrepancies
- ツールが不一致を検出したら、再実行して結果を確認します。ツールの実行中に一部の操作が実行された可能性がある場合、特に注意が必要です。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致が報告される可能性があります。報告された場合、これらのストレージドメインは RHV データベースにはこれらのストレージドメインのイメージエントリーがないため、無視できます。
結果について
このツールは以下を報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースに表示されているがストレージにはないボリュームがある場合
- 一部のボリューム属性がストレージとデータベースで異なる場合
出力サンプル
Checking storage domain c277ad93-0973-43d9-a0ca-22199bc8e801 Looking for missing images... No missing images found Checking discrepancies between SD/DB attributes... image ef325650-4b39-43cf-9e00-62b9f7659020 has a different attribute capacity on storage(2696984576) and on DB(2696986624) image 852613ce-79ee-4adc-a56a-ea650dcb4cfa has a different attribute capacity on storage(5424252928) and on DB(5424254976) Checking storage domain c64637b4-f0e8-408c-b8af-6a52946113e2 Looking for missing images... No missing images found Checking discrepancies between SD/DB attributes... No discrepancies found
8.5. スナップショットプレビュー
仮想ディスクを元に戻すスナップショットを選択するために、管理者は以前に作成されたすべてのスナップショットをプレビューできます。
管理者は、ゲストごとに使用可能なスナップショットから、スナップショットボリュームを選択してその内容をプレビューできます。プレビュースナップショット にあるように、各スナップショットは COW ボリュームとして保存され、プレビューされると、プレビュー対象のスナップショットから新しいプレビューレイヤーがコピーされます。ゲストは、実際のスナップショットボリュームではなく、プレビューを操作します。
管理者が選択したスナップショットをプレビューした後、プレビューをコミットして、ゲストデータをスナップショットでキャプチャされた状態に復元できます。管理者がプレビューをコミットすると、ゲストはプレビューレイヤーに接続されます。
スナップショットがプレビューされたら、管理者は Undo を選択して、表示したスナップショットのプレビュー層を破棄することができます。スナップショット自体を含むレイヤーは、プレビューレイヤーが破棄されても保持されます。
図8.3 スナップショットのプレビュー
8.6. スナップショットの削除
不要になった個々のスナップショットを削除できます。スナップショットを削除すると、仮想ディスクをその特定の復元ポイントに復元する機能が削除されます。スナップショットによって消費されたディスクスペースを再利用する必要はなく、データを削除するわけでもありません。後続のスナップショットが削除されたスナップショットのデータを上書きした場合にのみ、ディスク領域が再利用されます。たとえば、5 つのスナップショットのうち 3 番目のスナップショットを削除した場合、4 番目と 5 番目のスナップショットを使用するには、3 番目のスナップショットの変更されていないデータをディスクに保存する必要があります。ただし、4 番目または 5 番目のスナップショットが 3 番目のデータを上書きした場合は、3 番目のスナップショットが冗長化され、ディスク領域を再利用できます。ディスクスペースの再利用の可能性は別として、スナップショットを削除すると、仮想マシンのパフォーマンスも向上する可能性があります。
図8.4 スナップショットの削除
スナップショットの削除は非同期ブロックジョブとして処理され、VDSM が仮想マシンの復元ファイルに操作の記録を保持するため、操作中に VDSM が再起動したり、仮想マシンがシャットダウンしたりしても、ジョブを追跡できます。操作が開始すると、操作が失敗したり中断されたりした場合でも、削除されるスナップショットをプレビューしたり、復元ポイントとして使用したりすることはできません。アクティブレイヤーとその親レイヤーを統合する操作では、アクティブレイヤーから親レイヤーへのデータコピーと、アクティブレイヤーと親レイヤーへのディスクライトのミラーリングの 2 段階の処理に分割されます。最後に、削除されるスナップショット内のデータがその親スナップショットとマージされ、VDSM がイメージチェーン全体で変更を同期すると、ジョブは完了したと見なされます。
削除に失敗した場合は、根本的な問題 (たとえば、ホストの障害、ストレージデバイスへのアクセス不能、または一時的なネットワークの問題) を修正して、再試行してください。
第9章 ハードウェアドライバーとデバイス
9.1. 仮想化されたハードウェア
Red Hat Virtualization は、仮想化されたゲストに 3 つの異なるタイプのシステムデバイスを提供します。これらのハードウェアデバイスはすべて、仮想化されたゲストに物理的に接続されたハードウェアデバイスとして表示されますが、デバイスドライバーはさまざまな方法で機能します。
- エミュレートされたデバイス
- エミュレートされたデバイスは、仮想デバイスと呼ばれることもあり、完全にソフトウェアに存在します。エミュレートされたデバイスドライバーは、ホストで実行しているオペレーティングシステム (ソースデバイスを管理する) とゲストで実行してオペレーティングシステムの間の変換レイヤーです。エミュレートされたデバイスとの間でやり取りされるデバイスレベルの命令は、ハイパーバイザーによってインターセプトおよび変換されます。Linux カーネルによってエミュレートおよび認識されるのと同じタイプのデバイスは、エミュレートされたドライバーのバッキングソースデバイスとして使用できます。
- 準仮想化デバイス
- 準仮想化デバイスでは、ゲストオペレーティングシステムにデバイスドライバーをインストールして、ホストマシンのハイパーバイザーと通信するためのインターフェイスを提供する必要があります。このインターフェイスは、仮想化環境の外部でディスク I/O などの従来の集中的なタスクを実行できるようにするために使用されます。この方法で仮想化に固有のオーバーヘッドを削減することは、ゲストオペレーティングシステムのパフォーマンスを、物理ハードウェアで直接実行する場合に期待されるパフォーマンスに近づけることを目的としています。
- 物理的に共有されているデバイス
- 特定のハードウェアプラットフォームでは、仮想化されたゲストがさまざまなハードウェアデバイスやコンポーネントに直接アクセスできます。仮想化におけるこのプロセスは、パススルーまたはデバイス割り当てと呼ばれます。パススルーを使用すると、デバイスがゲストオペレーティングシステムに物理的に接続されているかのように表示および動作できます。
9.2. Red Hat Virtualization における安定したデバイスアドレス
仮想ハードウェアの PCI アドレスの割り当ては、ovirt-engine データベースに永続化されます。
PCI アドレスは仮想マシンの作成時に QEMU
によって割り当てられ、libvirt
が VDSM
に報告されます。VDSM
はそれらを Manager に戻します。ここでは、ovirt-engine データベースに保管されています。
仮想マシンが起動すると、Manager はデータベースからデバイスアドレスを VDSM
に送信します。VDSM
は、仮想マシンの初回実行時に割り当てられた PCI デバイスアドレスを使用して仮想マシンを起動する libvirt
に渡します。
デバイスが仮想マシンから削除されると、安定した PCI アドレスを含む、そのデバイスへのすべての参照も削除されます。削除したデバイスを交換するためにデバイスが追加されると、QEMU
によって PCI アドレスが割り当てられます。これは、置き換えるデバイスと同じであるとは限りません。
9.3. 中央処理装置 (CPU)
クラスター内の各ホストには、いくつかの仮想 CPU(vCPU) があります。次に、仮想 CPU は、ホスト上で実行されているゲストに公開されます。クラスター内のホストによって公開されるすべての仮想 CPU は、クラスターが Red Hat Virtualization Manager を介して最初に作成されたときに選択されたタイプです。クラスター内で仮想 CPU タイプを混在させることはできません。
使用可能な各仮想 CPU タイプには、同じ名前の物理 CPU に基づく特性があります。仮想 CPU は、物理 CPU とゲストオペレーティングシステムを区別できません。
x2APIC のサポート:
Red Hat Enterprise Linux 7 ホストが提供するすべての仮想 CPU モデルには、x2APIC のサポートが含まれています。これにより、ハードウェア割り込みをより適切に処理するための Advanced Programmable Interrupt Controller (APIC) が提供されます。
9.4. システムデバイス
システムデバイスはゲストが実行するために重要であり、削除することはできません。ゲストに接続されている各システムデバイスも、使用可能な PCI スロットを使用します。デフォルトのシステムデバイスは次のとおりです。
- ホストブリッジ
- ISA ブリッジと USB ブリッジ (USB ブリッジと ISA ブリッジは同じデバイスです)
- VGA または qxl ドライバーを使用したグラフィックカード
- メモリーバルーンデバイス
Intel Q35 ベースの仮想マシンで PCI Express と従来の PCI デバイスを使用する方法に関する情報は、Using PCI Express and Conventional PCI Devices with the Q35 Virtual Machine を参照してください。
9.5. ネットワークデバイス
Red Hat Virtualization は、3 つの異なるタイプのネットワークインターフェイスコントローラーをゲストに公開できます。ゲストに公開するネットワークインターフェイスコントローラーのタイプは、ゲストの作成時に選択されますが、Red Hat Virtualization Manager から変更できます。
- e1000 ネットワークインターフェイスコントローラーは、仮想化 Intel PRO/1000(e1000) をゲストに公開します。
- virtio ネットワークインターフェイスコントローラーは、準仮想化ネットワークデバイスをゲストに公開します。
- rtl8139 ネットワークインターフェイスコントローラーは、ゲストに仮想化された Realtek Semiconductor Corp RTL8139 を公開します。
ゲストごとに複数のネットワークインターフェイスコントローラーを使用できます。追加された各コントローラーは、ゲストで使用可能な PCI スロットを占有します。
9.6. グラフィックデバイス
SPICE または VNC グラフィックプロトコルを使用して、エミュレートされたグラフィックデバイスに接続できます。
管理ポータルで Video Type を選択できます。
- QXL: QXL ゲストドライバーで最適に機能する準仮想化ビデオカードを改良します。
-
VGA:
Bochs
VESA 拡張機能でダミー VGA カードをまとめます。 - BOCHS: UEFI で実行されるゲストマシンのレガシーエミュレーションを使用せずにダミー VGA カードを調整します。これは、UEFI サーバーのデフォルトのディスプレイビデオカードエミュレーターです。
UEFI で設定され、互換性レベル 4.6 以上のタイプ server
の仮想マシンの場合、BOCHS は Video Type のデフォルト値になります。
Red Hat Virtualization 4.4.5 では、この機能を有効にするには、以下を実行する必要があります。
以下のコマンドを実行します。
engine-config --set EnableBochsDisplay=true --cver=<version>
ここで、
<version>
は互換バージョンです。- エンジンを再始動します。
- Video Type を BOCHS に手動で設定します。
9.7. ストレージデバイス
ストレージデバイスとストレージプールは、ブロックデバイスドライバーを使用して、ストレージデバイスを仮想化ゲストに接続できます。ストレージドライバーはストレージデバイスではないことに注意してください。ドライバーは、バッキングストレージデバイス、ファイル、またはストレージプールボリュームを仮想化されたゲストに接続するのに使用されます。バッキングストレージデバイスは、サポートされている任意のタイプのストレージデバイス、ファイル、またはストレージプールボリュームにすることができます。
- IDE ドライバーは、エミュレートされたブロックデバイスをゲストに公開します。エミュレートされた IDE ドライバーは、最大 4 つの仮想化 IDE ハードディスクまたは仮想化 IDE CD-ROM ドライブの組み合わせを各仮想化ゲストに割り当てるために使用できます。エミュレートされた IDE ドライバーは、仮想化 DVD-ROM ドライブを提供するためにも使用されます。
- VirtIO ドライバーは、準仮想化ブロックデバイスをゲストに公開します。準仮想化ブロックドライバーは、仮想化ゲストに接続されたハイパーバイザーによってサポートされるすべてのストレージデバイス用のドライバーです (エミュレートする必要があるフロッピーディスクドライブを除く)。
9.8. サウンドデバイス
2 つのエミュレートされたサウンドデバイスが利用可能です。
- ac97 は、Intel 82801AA AC97 Audio と互換性のあるサウンドカードをエミュレートします。
- es1370 は、ENSONIQ AudioPCI ES1370 サウンドカードをエミュレートします。
9.9. シリアルドライバー
準仮想化シリアルドライバー (virtio-serial) は、バイト指向の文字ストリームドライバーです。準仮想化シリアルドライバーは、ネットワークが利用できない、または使用できない場合に、ホストのユーザースペースとゲストのユーザースペースの間の単純な通信インターフェイスを提供します。
9.10. バルーンドライバー
バルーンドライバーを使用すると、ゲストは必要なメモリー量をハイパーバイザーに表現できます。バルーンドライバーを使用すると、ホストはゲストに効率的にメモリーを割り当て、他のゲストやプロセスに空きメモリーを割り当てることができます。
バルーンドライバーを使用しているゲストは、ゲストの RAM のセクションを未使用としてマークできます (バルーンの膨張)。ハイパーバイザーはメモリーを解放し、そのメモリーを他のホストプロセスまたはそのホスト上の他のゲストに使用できます。ゲストが解放されたメモリーを再度必要とする場合、ハイパーバイザーは RAM をゲストに再割り当てできます (バルーンの収縮)。
付録A 列挙値の翻訳
API は、Red Hat Virtualization クエリー言語を使用して検索クエリーを実行します。詳細は、管理ポータルの概要 の 検索 を参照してください。
クエリー言語を使用する場合、API の特定の列挙値には異なる検索クエリーが必要であることに注意してください。以下の表は、リソースタイプに応じたこれらのキー列挙値の翻訳を示しています。
API 列挙型 | API 列挙可能な値 | クエリー言語値 |
---|---|---|
|
|
|
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
付録B イベントコード
この表には、すべてのイベントコードが記載されています。
コード | 名前 | 重大度 | メッセージ |
---|---|---|---|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|