Red Hat Hyperconverged Infrastructure for Virtualizationのデプロイ
Red Hat Hyperconverged Infrastructure for Virtualization のデプロイ手順
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。
パート I. プラン
第1章 アーキテクチャー
Red Hat Hyperconverged Infrastructure for Virtualization (RHHI for Virtualization)は、1 つのデプロイメントにコンピュート、ストレージ、ネットワーク、および管理機能を組み合わせたものです。
RHHI for Virtualization は、Red Hat Gluster Storage 3.5 および Red Hat Virtualization 4.4 を使用して、個別のクラスターまたは Pod を作成するために多数の物理マシンにまたがってデプロイされます。
このデプロイメントの主要なユースケースは、リモートオフィス/ブランチオフィス(ROBO)環境です。ここでは、リモートオフィスは定期的に中央データセンターにデータを同期しますが、機能するのに中央のデータセンターへの接続を必要としません。
以下の図は、3 つの物理マシンにデプロイされる、単一クラスターの基本アーキテクチャーを示しています。
1.1. VDO の概要
Red Hat Hyperconverged Infrastructure for Virtualization 1.6 の時点で、VDO (Virtual Data Optimizer)レイヤーを設定して、ストレージのデータ削減と重複排除を提供できます。
VDO は、新規インストールのデプロイ時に有効化された場合にのみサポートされ、RHHI for Virtualization の以前のバージョンからアップグレードされたデプロイメントで有効にすることはできません。
VDO は、以下のタイプのデータ削減を行い、データが必要とする領域を縮小します。
- 重複排除
- ゼロおよび重複するデータブロックを排除します。VDO は、UDS（Universal Deduplication Service）カーネルモジュールを使用して重複データを検出します。重複データを書き込む代わりに、VDO は元のブロックへの参照として記録します。論理ブロックアドレスは、VDO により物理ブロックアドレスにマッピングされます。
- 圧縮
- ディスクに書き込む前に、重複しないブロックを固定の長さ(4 KB)のブロックに一緒にパッキングすることで、データのサイズを縮小します。これにより、ストレージからデータを読み取るパフォーマンスが向上します。
最大で、データは元のサイズの 15% に縮小できます。
データの削減には追加の処理コストが発生するため、圧縮および重複排除を有効にすると書き込みパフォーマンスが低下します。そのため、パフォーマンス重視ワークロードには VDO は推奨されません。特にディスク暗号化などのパフォーマンスを低下させる他の技術と併用する場合には、Red Hat では、VDO を実環境にデプロイする前に、VDO を有効にしてワークロードが要求されるレベルのパフォーマンスを達成することをテストし、検証することを強く推奨します。
VDO の下の層で RAID ハードウェアを使用する予定の場合には、Red Hat では、SSD/NVMe ディスクを使用してパフォーマンスの問題を回避することを強く推奨します。VDO の下で RAID ハードウェア層を使用していない場合は、スピンディスクを使用できます。
第2章 サポート要件
このセクションを確認して、予定されるデプロイメントが Red Hat のサポート要件を満たすようにしてください。
2.1. オペレーティングシステム
Red Hat Hyperconverged Infrastructure for Virtualization (RHHI for Virtualization)は、その他すべての設定のベースとして Red Hat Virtualization Host 4.4 を使用します。Red Hat Enterprise Linux ホストはサポートされません。
Red Hat Virtualization の要件の詳細は、Red Hat Virtualization Planning and Prerequisites GuideのRequirementsを参照してください。
2.1.1. ブラウザーの要件
Web コンソールおよび Red Hat Virtualization 管理ポータルのサポートは、アクセスに使用する Web ブラウザーによって異なります。
通常、Mozilla Firefox、Google Chrome、または Microsoft Edge の最新バージョンを使用します。
Web コンソールのブラウザーサポートの詳細は、「Logging in to the web console」を参照してください。
管理ポータルのブラウザーサポートの詳細は、Red Hat Virtualization の Browser requirements を参照してください。
2.2. 物理マシン
Red Hat Hyperconverged Infrastructure for Virtualization (RHHI for Virtualization)には、少なくとも 3 台の物理マシン が必要です。6、9、または 12 台の物理マシンへのスケーリングもサポートされます。より詳細な要件については、「スケーリング」を参照してください。
各物理マシンには、以下の機能が必要です。
- データと管理のトラフィックを分離するために、物理マシンごとに少なくとも 2 つの NIC（ネットワークインターフェースコントローラー）（詳細は、「ネットワーキング」を参照してください）。
小規模なデプロイメントの場合：
- 12 コア以上
- 64 GB 以上の RAM
- 最大で 48 TB のストレージ
中規模デプロイメントの場合：
- 12 コア以上
- 128 GB 以上の RAM
- 最大で 64 TB のストレージ
大規模なデプロイメントの場合：
- 16 コア以上
- 256 GB 以上の RAM
- 最大で 80 TB のストレージ
2.3. 仮想マシン
ハイパーコンバージドのデプロイメントで実行できる仮想マシンの数は、それらの仮想マシンが何をするかと、仮想マシンが対応する負荷に大きく依存します。ワークロードの CPU、メモリー、およびスループットの要件をテストし、それに応じてハイパーコンバージド環境をプロビジョニングします。
仮想マシンおよび仮想 CPU の最大数に関する情報は、Virtualization limits for Red Hat Virtualizationを参照してください。また、RHHI for Virtualization Sizing Tool を使用して、デプロイメントのプランニングの参考にしてください。
Red Hat Hyperconverged Infrastructure for Virtualization上にOpenShift Container Storageを構築する構成（Red Hat OpenShift Container Platformでインストールされた仮想マシンをホストするハイパーコンバージドノード）は、サポートされる構成ではありません。
2.4. Hosted Engine 仮想マシン
Hosted Engine 仮想マシンには、少なくとも以下が必要です。
- 1 つのデュアルコア CPU（1 クアッドコアまたは複数のデュアルコア CPU を推奨）
- 他のプロセスと共有されない 4 GB のRAM（16 GB を推奨）
- 25 GB のローカルの書き込み可能なディスク領域（5 0GB を推奨）
- 1 NIC（最低 1 Gbps 帯域幅）
詳細は、『Red Hat Virtualization 4.4 Planning and Prerequisites Guide』の「Requirements」を参照してください。
2.5. ネットワーキング
DNS で正引きおよび逆引き解決が可能な完全修飾ドメイン名 は、すべてのハイパーコンバージドホストおよびHosted Engine仮想マシンに必要です。
外部 DNS が利用できない場合（例：分離された環境など）、各ノードの /etc/hosts ファイルにすべてのホストおよびHosted Engineノードのフロントおよびバックエンドアドレスが含まれるようにします。
IPv6 は IPv6 専用環境でサポートされています（DNS およびゲートウェイアドレスを含む）。IPv4 アドレスと IPv6 アドレスの両方を備えた環境はサポートされません。
Red Hat は、仮想マシンのトラフィックに フロントエンド管理ネットワーク と、gluster トラフィックおよび仮想マシンの移行向けの バックエンドストレージネットワーク という別のネットワークを使用することを推奨します。
図2.1 ネットワークダイアグラム
Red Hat では、それぞれのノードに各ネットワーク用にイーサネットポートを 1 つずつ設定することを推奨します。これにより、最適なパフォーマンスが確保されます。高可用性を確保するには、各ネットワークを別個のネットワークスイッチに配置します。耐障害性を強化するために、スイッチごとに個別の電源を用意します。
- フロントエンド管理ネットワーク
- Red Hat Virtualization および仮想マシンによって使用されます。
- 少なくとも1つの 1 Gbps イーサネット接続が必要です。
- このネットワークに割り当てられる IP アドレスは、相互に同じサブネット上になければならず、またバックエンドストレージネットワークとは別のサブネット上になければなりません。
- このネットワークの IP アドレスは、管理者が選択できます。
- バックエンドストレージネットワーク
- ハイパーコンバージドノード間のストレージおよび移行トラフィックに使用されます。
- 少なくとも1つの 10 Gbps イーサネット接続が必要です。
- ピア間のレイテンシーは、最大でも 5 ミリ秒でなければなりません。
Intelligent Platform Management Interface (IPMI)を使用するネットワークフェンシングデバイスには、個別のネットワークが必要です。
Hosted Engine 仮想マシンに DHCP ネットワーク設定を使用する場合は、Red Hat Hyperconverged Infrastructure for Virtualization を設定する前に DHCP サーバーを設定する必要があります。
データのコピーを保存するために Geo レプリケーションを使用して 障害復旧を設定する場合は、信頼できるタイムソースを設定してください。
デプロイメントプロセスを開始する前に、 以下の詳細を決定してください。
- ハイパーコンバージドホストへのゲートウェイの IP アドレス。このアドレスは ping 要求に応答する必要があります。
- フロントエンド管理ネットワークの IP アドレス。
- Hosted Engine仮想マシンの完全修飾ドメイン名(FQDN)。
- Hosted Engineの静的 FQDN および IP アドレスに解決する MAC アドレス。
2.6. ストレージ
ハイパーコンバージドホストは、設定、ログ、およびカーネルダンプを保存し、そのストレージをスワップ領域として使用します。このセクションでは、ハイパーコンバージドホストのディレクトリーの最小サイズを一覧表示します。Red Hat は、この最小値よりも多くのストレージ容量を使用するデフォルトの割り当てを使用することを推奨します。
-
/(ルート) - 6 GB -
/home- 1 GB -
/tmp- 1 GB -
/boot- 1 GB -
/var- 15 GB -
/var/crash- 10 GB /var/log- 8 GB重要Red Hat では、
/var/logのサイズを 15 GB 以上に増やして、Red Hat Gluster Storage の追加ロギング要件に十分な領域を提供することを推奨します。Growing a logical volume using the Web Consoleの手順に従って、オペレーティングシステムのインストール後にこのパーティションのサイズを増やします。
-
/var/log/audit- 2 GB -
swap- 1 GB（詳細は Recommended swap size を参照） - Anaconda では、将来のメタデータ拡張用に、ボリュームグループ内のシンプールサイズの 20% が確保されます。これは、通常の使用条件においてデフォルト設定でストレージを使い果たすのを防ぐためです。インストール中のシンプールのオーバープロビジョニングもサポートされていません。
- 最小合計 - 64 GB
2.6.1. ディスク
Red Hat では、最適なパフォーマンスを得るために、SSD (Solid State Disks)を推奨します。ハードドライブディスク(HDD)を使用する場合は、LVM キャッシュボリュームとして小型で高速なSSD も設定する必要があります。キャッシュデバイスは、他のボリュームと同じブロックサイズを使用する必要があります。
異なるブロックサイズを持つディスクにまたがって Gluster ボリュームのブリックをホストしないでください。VDO デバイスのデフォルトのブロックサイズがバージョン 1.6 の 512 バイトからバージョン1.7の 4 KB に変更されたため、ボリュームを作成する前に、ブリックをホストするのに使用される VDO デバイスのブロックサイズを確認するようにしてください。以下のコマンドを実行して、ディスクのブロックサイズ（バイト単位）を確認します。
# blockdev --getss <disk_path>
2.6.2. RAID
RAID5 および RAID6 の設定がサポートされます。ただし、RAID 設定制限は、使用中のテクノロジーによって異なります。
- SAS/SATA 7k ディスクは、RAID6 でサポートされています（最大で 10+2）
SAS 10k および 15k のディスクは以下のようにサポートされます。
- RAID5（最大で 7+1）
- RAID6（最大で 10+2）
RAID カードは、フラッシュでサポートされる書き込みキャッシュを使用する必要があります。
Red Hat は、さらに各サーバーに少なくとも 1 つのホットスペアドライブを提供することを推奨します。
VDO の下の層で RAID ハードウェアを使用する予定の場合には、Red Hat では、SSD/NVMe ディスクを使用してパフォーマンスの問題を回避することを強く推奨します。VDO の下で RAID ハードウェア層を使用していない場合は、スピンディスクを使用できます。
2.6.3. JBOD
Red Hat Hyperconverged Infrastructure for Virtualization 1.6 の時点で、JBOD 設定は完全にサポートされ、アーキテクチャーレビューが不要になりました。
2.6.4. 論理ボリューム
エンジン gluster ボリュームを構成する論理ボリュームは、シックプロビジョニングする必要があります。これにより、Hosted Engine が領域不足、破壊的なボリューム設定の変更、I/O オーバーヘッド、および移行アクティビティーから保護されます。
vmstore およびオプションの データ gluster ボリュームを構成する論理ボリュームは、シンプロビジョニングする必要があります。これにより、基礎となるボリューム設定で柔軟性が向上します。
シンプロビジョニングされたボリュームがハードドライブディスク(HDD)にある場合は、パフォーマンスを向上させるために、lvmcacheとして小型で高速なSolid State Disk (SSD) を設定する必要があります。キャッシュデバイスは、他のボリュームと同じブロックサイズを使用する必要があります。
2.6.5. Red Hat Gluster Storage ボリューム
Red Hat Hyperconverged Infrastructure for Virtualization には、3 - 4 の Red Hat Gluster Storage ボリュームが想定されています。
- Hosted Engine用に 1 つの engine ボリューム
- 仮想マシンのオペレーティングシステムディスクイメージ用に 1 つの vmstore ボリューム
- 他の仮想マシンディスクイメージ用に 1 つの dataボリューム
- Geo レプリケーションメタデータ用に 1 つの shared_storage ボリューム
バックアップストレージ要件を最小限に抑えるために、別の vmstore と dat ボリュームが推奨されます。オペレーティングシステムイメージから分離して仮想マシンデータを保存すると、vmstore ボリュームのオペレーティングシステムイメージはより簡単に再ビルドできるため、ストレージ領域が限られている場合でも data ボリュームだけしかバックアップする必要がありません。
2.6.6. ボリュームタイプ
Red Hat Hyperconverged Infrastructure for Virtualization (RHHI for Virtualization)は、デプロイ時に以下のボリューム種別のみをサポートします。
- 複製ボリューム（3 つのノードで、3 つのブリック上の同じデータの3つのコピー）
- 判定複製ボリューム（3 つのノードで、2 つのブリックとメタデータが含まれる 1 つの判定ブリック上の同じデータの2つのフルコピー）
単一ブリックの分散ボリューム（データの1つのコピー、他のブリックへのレプリケーションなし）
注記単一ブリックの分散ボリュームは、Red Hat Hyperconverged Infrastructure for Virtualization の単一ノードデプロイメントでのみサポートされます。
『Automating RHHI for Virtualization deployment』で説明されている Ansible Playbook を使用して、Red Hat Hyperconverged Infrastructure for Virtualization のデプロイメント時に分散複製または分散判定複製 ボリュームを作成できます。
判定ブリックは、ファイル名、構造、およびメタデータのみを保存することに注意してください。つまり、3 方向の判定複製ボリュームは、同じレベルの一貫性を実現するために、3 方向の複製ボリュームが必要とするストレージ容量の約 75% を必要とすることを意味します。ただし、判定ブリックはメタデータのみを格納するため、3 方向の判定複製ボリュームは双方向複製ボリュームの可用性のみを提供します。
判定複製ボリュームのレイアウトの詳細は、『Administration Guide』の「Creating multiple arbitrated replicated volumes across fewer total nodes」を参照してください。
2.7. ディスクの暗号化
ディスクの暗号化は、Red Hat Hyperconverged Infrastructure for Virtualization 1.8 以降でサポートされています。
サポートされる方法は Network-Bound Disk Encryption (NBDE)です。これは、鍵サーバーを使用して起動時に暗号化されたクライアントに復号化鍵を提供します。これにより、復号化パスワードを手動で入力する必要がなくなります。
NBDEをサポートするには、NBDEキーサーバーとして動作する追加のサーバー（物理または仮想）が1台以上必要です。耐障害性を確保するには、Red Hat では2台の NBDE 鍵サーバーを推奨します。
NBDE 鍵サーバーは、Red Hat Hyperconverged Infrastructure for Virtualization クラスターに含めることはできません。
NBDE キーサーバーは、以下のいずれかのオペレーティングシステムを使用できます。
- Red Hat Enterprise Linux 7.8 以降
- Red Hat Enterprise Linux 8.2 以降
ディスクの暗号化は、一般的にパフォーマンスが若干低下します。特に、ディスク暗号化を、Virtual Disk Optimizationを使用した重複排除や圧縮など、速度が若干低下する他の技術と組み合わせて使用している場合は、本番環境に投入する前にこの構成を十分にテストし、ユースケースのパフォーマンス要件を満たしていることを確認してください。
2.8. VDO (Virtual Data Optimizer)
Virtual Data Optimizer (VDO)層は、Red Hat Hyperconverged Infrastructure for Virtualization 1.6 以降でサポートされています。
VDO のサポートは、新しいデプロイメントのみに限定されます。既存のデプロイメントに VDO レイヤーを追加しないでください。
VDO デバイスのデフォルトのブロックサイズがバージョン 1.6 の 512 バイトからバージョン1.7の 4 KB に変更されたことに注意してください。異なるブロックサイズを持つディスクにまたがって Gluster ボリュームのブリックをホストしないでください。
データの削減には追加の処理コストが発生するため、圧縮および重複排除を有効にすると書き込みパフォーマンスが低下します。そのため、パフォーマンス重視ワークロードには VDO は推奨されません。特にディスク暗号化などのパフォーマンスを低下させる他の技術と併用する場合には、Red Hat では、VDO を実環境にデプロイする前に、VDO を有効にしてワークロードが要求されるレベルのパフォーマンスを達成することをテストし、検証することを強く推奨します。
2.9. スケーリング
初期のデプロイメントで使用できるノードの数は、デプロイメント方法によって異なります。
Web コンソールを使用する場合は、1 台または 3 台のハイパーコンバージドノードをデプロイすることができます。
この場合、作成時に 3 つ以上のノードにまたがるボリュームを作成することはできません。まず 3 ノードのボリュームを作成してから、デプロイメント後にそれ以上のノードに拡張する必要があります。
- Ansible 自動化を使用する場合は、最大 12 台のハイパーコンバージドノードまでデプロイし、デプロイ時に必要な数のノードにボリュームを分散させることができます。
1 ノードのデプロイメントをスケーリングすることはできません。
他のデプロイメントは、最小の 3 ノードから、6、9、または 12 ノードにスケーリングできます。
ディスクを追加し、Gluster ボリュームを拡張してデプロイメントをスケーリングできます。新規または既存のノードにディスクを追加し、それらを使用して新規 Gluster ボリュームを作成するか、または既存の Gluster ボリュームを拡張します。
2.10. 既存の Red Hat Gluster Storage 設定
Red Hat Hyperconverged Infrastructure for Virtualization は、本書で指定されているとおりにデプロイした場合にのみサポートされます。既存の Red Hat Gluster Storage 設定は、ハイパーコンバージド設定では使用できません。既存の Red Hat Gluster Storage 設定を使用する場合は、Configuring Red Hat Virtualization with Red Hat Gluster Storageに記載されている従来の設定ドキュメントを参照してください。
2.11. 障害復旧
Red Hat は、障害復旧ソリューションを設定することを強く推奨します。Geo レプリケーションを障害復旧ソリューションとして設定する方法は、Maintaining Red Hat Hyperconverged Infrastructure for Virtualization（https://access.redhat.com/documentation/ja-jp/red_hat_hyperconverged_infrastructure_for_virtualization/1.8/html/maintaining_red_hat_hyperconverged_infrastructure_for_virtualization/config-backup-recovery）を参照してください。
2.11.1. Geo レプリケーションの前提条件
Geo レプリケーションを設定する際には、以下の要件と制限に注意してください。
- 2 つの異なるマネージャーが必要です
- Geo レプリケーションのソースおよび宛先ボリュームは、Red Hat Virtualization Manager の異なるインスタンスで管理される必要があります。
2.11.2. フェイルオーバーおよびフェイルバック設定の前提条件
- バージョンが環境間で一致している必要があります
- プライマリー環境とセカンダリー環境で、データセンターの互換バージョン、クラスターの互換バージョン、および PostgreSQL のバージョンが等価な、同じバージョンの Red Hat Virtualization Manager が含まれている必要があります。
- Hosted Engineストレージドメインに仮想マシンディスクがない
- Hosted Engine仮想マシンで使用されるストレージドメインはフェイルオーバーされないため、このストレージドメインの仮想マシンディスクはすべて失われます。
- Ansible Playbook を別のマシンから手動で実行する
Ansible Playbook を Ansible コントローラノードとして機能する別のマシンから手動で生成し、実行します。このノードには、必要な障害復旧 Ansible ロールをすべて提供する
ovirt-ansible-collectionパッケージが必要です。注記ovirt-ansible-collectionパッケージは、デフォルトで Hosted Engine 仮想マシンと共にインストールされます。ただし、プライマリーサイトに影響を与える障害時に、この仮想マシンが停止している可能性があります。プライマリーサイト外のマシンを使用してこの Playbook を実行することは安全ですが、テスト目的では、Hosted Engine 仮想マシンからこれらの Playbook をトリガーすることができます。
2.12. 単一ノードデプロイメントの追加要件
Red Hat Hyperconverged Infrastructure for Virtualization は、以下の追加および例外を除き、すべてのサポート要件が満たされていれば、単一ノードでの展開がサポートされます。
単一ノードのデプロイメントには、以下が含まれる物理マシンが必要です。
- 1 ネットワークインターフェースコントローラー
- 12 コア以上
- 64 GB 以上の RAM
シングルノードのデプロイメントは、拡張性がなく、高可用性もありません。このデプロイメントタイプはコストが低くなっていますが、可用性のオプションを削除します。
第3章 推奨事項
このセクションで説明している設定は必須ではありませんが、デプロイメントの安定性またはパフォーマンスを向上させる可能性があります。
3.1. 推奨情報
- デプロイメントが完了したらすぐに完全バックアップを作成し、バックアップを別の場所に保存します。その後は、定期的にバックアップを作成します。詳細は、「Configuring backup and recovery options」を参照してください。
- デプロイメントが依存するサービスを同じRHHI for Virtualization環境内の仮想マシンとして実行することは避けてください。必要なサービスを同じデプロイメントで実行する必要がある場合は、デプロイメントを慎重に計画して、必要なサービスを実行している仮想マシンのダウンタイムを最小限に抑えるために慎重にデプロイメントを計画してください。
-
ハイパーコンバージドノードに十分なエントロピーを確保してください。
/proc/sys/kernel/random/entropy_availの値が200未満の場合に障害が発生する可能性があります。エントロピーを増やすには、rng-toolsパッケージをインストールして、https://access.redhat.com/solutions/1395493 の手順に従います。 - 環境の操作を行うユーザーが誰でも現在の状態と必要な手順を理解するように、環境を文書化します。
3.2. セキュリティーに関する推奨事項
- ホストまたは仮想マシンで、セキュリティー機能 (HTTPS、SELinux、ファイアウォールなど) を無効にしないでください。
- 最新のセキュリティーアップデートとエラータを受け取るために、すべてのホストと Red Hat Enterprise Linux 仮想マシンを Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のいずれかに登録します。
- アクティビティーを適切に追跡するために、多くのユーザーにデフォルトの admin アカウントの使用を許可する代わりに、個別の管理者アカウントを作成します。
- ホストへのアクセスを制限し、別のログインを作成します。すべてのユーザーが使用する 1 つの root ログインを作成しないでください。Red Hat Enterprise Linux 8 ドキュメントの「Managing user accounts in the web console」を参照してください。
- ホストに信頼できないユーザーを作成しないでください。
- 解析ツール、コンパイラー等の追加のパッケージ、または不要なセキュリティーリスクを追加するその他のコンポーネントをインストールしないでください。
3.3. ホストの推奨事項
- 同じクラスター内のホストを標準化します。これには、一貫性のあるハードウェアモデルとファームウェアのバージョンが含まれます。同じクラスター内で異なるサーバーハードウェアを混在させると、ホスト間でパフォーマンスが一定しない可能性があります。
- デプロイ時にフェンシングデバイスを設定します。高可用性には、フェンシングデバイスが必要です。
- フェンシングトラフィックには、別のハードウェアスイッチを使用します。同じスイッチで監視とフェンシングが行われると、そのスイッチは、高可用性の対して単一障害点になります。
3.4. ネットワークの推奨事項
- 特に実稼働ホストでは、ネットワークインターフェースをボンディングします。ボンディングにより、サービスの全体的な可用性と、ネットワークの帯域幅が向上します。『Administration Guide』の「Network Bonding」を参照してください。
- 最適なパフォーマンスと簡素化されたトラブルシューティングを行うには、VLAN を使用して異なるトラフィック種別を分離し、10 GbE ネットワークまたは 40 GbE ネットワークを最大限活用します。
-
基礎となるスイッチがジャンボフレームをサポートする場合は、基礎となるスイッチが対応する最大サイズ (例:
9000) に MTU を設定します。この設定により、ほとんどのアプリケーションに対して、帯域幅が高くなり、CPU 使用率が削減され、最適なスループットが得られます。デフォルトの MTU は、基礎となるスイッチでサポートされる最小サイズで決定されます。LLDP が有効化されている場合には、Setup Host Networks ウィンドウの NIC のツールチップで各ホストのピアが対応する MTU が表示されます。 - 1 GbE ネットワークは、管理トラフィックにのみ使用してください。仮想マシンおよびイーサネットベースのストレージには、10 GbE または 40 GbE を使用します。
- ストレージ用に追加の物理インターフェースをホストに追加する場合は、仮想マシンネットワーク のチェックをクリアし、VLAN が物理インターフェースに直接割り当てられるようにします。
3.4.1. ホストネットワーク設定の推奨プラクティス
お使いのネットワーク環境が複雑な場合には、ホストを Red Hat Virtualization Manager に追加する前に、ホストネットワークを手動で設定しなければならない場合があります。
Red Hatでは、以下に示すホストネットワーク設定のプラクティスを推奨しています。
- Web コンソールを使用してネットワークを設定する。nmtui または nmcli を使用することもできます。
- セルフホストエンジンのデプロイメントまたは Manager へのホスト追加にネットワークが必要ない場合には、ホストを Manager に追加した後に、管理ポータルでネットワークを設定する。「Creating a New Logical Network in a Data Center or Cluster」を参照してください。
以下の命名規則を使用する。
-
VLAN デバイス:
VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD -
VLAN インターフェース:
physical_device.VLAN_ID(例:eth0.23、eth1.128、enp3s0.50) -
ボンディングインターフェース:
bondnumber(例:bond0、bond1) -
ボンディングインターフェースの VLAN:
bondnumber.VLAN_ID(例:bond0.50、bond1.128)
-
VLAN デバイス:
- ネットワークボンディング を使用する。ネットワークチーミングはサポートされません。
推奨されるボンディングモードを使用する。
-
仮想マシンの論理ネットワーク(
ovirtmgmt)として使用されるブリッジネットワークの場合は、「Which bonding modes work when used with a bridge that virtual machine guests or containers connect to?」を参照してください。 - その他の論理ネットワークでは、サポートされる任意のボンディングモードを使用できます。
-
Red Hat Virtualization のデフォルトのボンディングモードは
(Mode 4)Dynamic Link Aggregationです。お使いのスイッチがリンクアグリゲーション制御プロトコル (LACP) に対応していない場合には、(Mode 1) Active-Backupを使用してください。詳細は、『Administration Guide』の 「Bonding Modes」 を参照してください。
-
仮想マシンの論理ネットワーク(
以下の例に示すように、物理 NIC 上に VLAN を設定する (以下の例では
nmcliを使用していますが、任意のツールを使用することができます)。# nmcli connection add type vlan con-name vlan50 ifname eth0.50 dev eth0 id 50 # nmcli con mod vlan50 +ipv4.dns 8.8.8.8 +ipv4.addresses 123.123.0.1/24 +ivp4.gateway 123.123.0.254
以下の例に示すように、ボンディング上に VLAN を設定する (以下の例では
nmcliを使用していますが、任意のツールを使用することができます)。# nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100" ipv4.method disabled ipv6.method ignore # nmcli connection add type ethernet con-name eth0 ifname eth0 master bond0 slave-type bond # nmcli connection add type ethernet con-name eth1 ifname eth1 master bond0 slave-type bond # nmcli connection add type vlan con-name vlan50 ifname bond0.50 dev bond0 id 50 # nmcli con mod vlan50 +ipv4.dns 8.8.8.8 +ipv4.addresses 123.123.0.1/24 +ivp4.gateway 123.123.0.254
-
firewalldを無効にしないでください。 - ホストを Manager に追加した後に、管理ポータルでファイアウォールルールをカスタマイズする。『Administration Guide』の 「Configuring Host Firewall Rules」 を参照してください。
3.5. セルフホストエンジンの推奨事項
- Red Hat Virtualization Manager およびその他のインフラストラクチャーレベルのサービス用に、別のデータセンターおよびクラスターを作成します (環境が十分大きく、それが可能な場合)。Manager 用仮想マシンは通常のクラスター内のホストで実行できますが、実稼働仮想マシンから分離することで、バックアップスケジュールが容易になり、パフォーマンス、可用性、およびセキュリティーが向上します。
- Manager 用仮想マシン専用のストレージドメインは、セルフホストエンジンのデプロイメント時に作成されます。他の仮想マシンにはこのストレージドメインを使用しないでください。
- Manager 用仮想マシンがホスト間で安全に移行できるように、セルフホストエンジンノードはすべて同じ CPU ファミリーを持つようにします。さまざまなファミリーがある場合は、最も性能の低いものでインストールを開始します。
- Manager 用仮想マシンがシャットダウンするか、または移行する必要がある場合は、Manager 用仮想マシンが再起動または移行できるように、セルフホストエンジンノードに十分なメモリーが必要です。
パート II. デプロイ
第4章 デプロイメントワークフロー
Red Hat Hyperconverged Infrastructure for Virtualization デプロイのワークフローは、以下のとおりです。
要件を確認します。
予定されているデプロイメントがサポート要件を満たしていることを確認: Requirements を満たし、デプロイメントプロセス中に参照できるように installation checklist を入力します。
オペレーティングシステムをインストールします。
- ハイパーコンバージドホストとして機能する各物理マシンにオペレーティングシステムをインストールします: Installing hyperconverged hosts を参照してください。
- （必要に応じて） NBDE(Network-Bound Disk Encryption)キーサーバーとして機能する各物理または仮想マシンにオペレーティングシステムをインストールします。
ハイパーコンバージドホスト間の認証を設定します。
ホストの自動設定を有効にするためにパスワードなしでキーベースの SSH 認証を設定する（Configure key-based SSH authentication）。
（オプション）ディスクの暗号化を設定します。
ハイパーコンバージドクラスターを設定します。
第5章 オペレーティングシステムのインストール
5.1. ハイパーコンバージドホストのインストール
ハイパーコンバージドホストでサポートされるオペレーティングシステムは、最新バージョンの Red Hat Virtualization 4 です。
5.1.1. Red Hat Virtualization 4 を使用したハイパーコンバージドホストのインストール
5.1.1.1. Red Hat Virtualization 4 オペレーティングシステムのダウンロード
- Red Hat カスタマーポータル に移動します。
- Downloads をクリックし、製品ダウンロード一覧を取得します。
- Red Hat Virtualization をクリックします。
- Download latest をクリックします。
-
Product Software（製品ソフトウェア）タブで、最新のハイパーバイザーイメージ
Hypervisor Image for RHV 4.4の横にある Download ボタンをクリックします。 ファイルがダウンロードされたら、その SHA-256 チェックサムがページにあるものと一致することを確認します。
$ sha256sum image.isoダウンロードしたイメージを使用してインストールメディアデバイスを作成します。
Red Hat Enterprise Linux 8 ドキュメントの Creating installation media を参照してください。
5.1.1.2. ハイパーコンバージドホストへの Red Hat Virtualization 4 オペレーティングシステムのインストール
前提条件
- このオペレーティングシステムは、ハイパーコンバージドホストでのみサポートされます。このオペレーティングシステムでは、NBDE(Network-Bound Disk Encryption)キーサーバーをインストールしないでください。
- ハイパーコンバージドホストでディスク暗号化を有効にする場合は、追加のサーバー要件に注意してください。詳細は、Disk encryption requirements を参照してください。
手順
- 準備済みインストールメディアからマシンを起動し、起動します。
- 起動メニューで Install Red Hat Virtualization 4 を選択し、Enter を押します。
- 言語を選択し、Continue をクリックします。
- デフォルトの Localization オプションを受け入れます。
Installation destination をクリックします。
ストレージドメインに使用されるディスクなど、インストールの場所として使用しないディスクの選択を解除します。
警告チェックマークが付いているディスクはフォーマットされ、それらのデータはすべて失われます。このホストを再インストールする場合には、保持するデータと共にディスクがチェックマークが表示されないようにします。
-
Automatic partitioningオプションを選択します。 （オプション）ディスクの暗号化を使用する場合は、Encrypt my data パスワードを指定します。
警告マシンが起動しなくなるので、このパスワードを忘れないようにしてください。
このパスワードは、Network-Bound Disk Encryption の設定時にこのホストの
rootpassphraseとして使用されます。- 完了をクリックします。
Network and Host Name をクリックします。
-
Ethernet スイッチを
ONに切り替えます。 ネットワークインターフェースを選択し、Configure をクリックします。
- Generalタブで、優先的に自動的に接続するチェックボックスをチェックします。
（オプション）IPv4 の代わりに IPv6 ネットワークを使用するには、IPv6 設定 タブでネットワークの詳細を指定します。
静的ネットワーク設定では、IPv6 アドレス、プレフィックス、ゲートウェイ、ならびに IPv6 DNS サーバーおよび追加の検索ドメインを指定するようにしてください。
重要IPv4 または IPv6 のいずれかを使用する必要があります。混合ネットワークはサポートされません。
- 保存 をクリックします。
- 完了をクリックします。
-
Ethernet スイッチを
- （オプション）セキュリティーポリシーを設定します。
インストールの開始をクリックします。
root パスワードを設定します。
警告Red Hat は、ローカルのセキュリティー脆弱性が悪用される可能性があるため、ハイパーコンバージドホストに追加のユーザーを作成しないことを推奨します。
- 再起動 をクリックしてインストールを完了します。
/var/logパーティションのサイズを増やします。Red Hat Gluster Storage のロギング要件には、15 GB 以上の空き領域が必要です。Growing a logical volume using the Web Console の手順に従って、このパーティションのサイズを増やします。
5.2. NBDE(Network-Bound Disk Encryption key)サーバーのインストール
Network-Bound Disk Encryption を使用して Red Hat Hyperconverged Infrastructure for Virtualization のディスクのコンテンツを暗号化する場合には、少なくとも 1 つのキーサーバーをインストールする必要があります。
NBDE(Network-Bound Disk Encryption)キーサーバーでサポートされるオペレーティングシステムは、Red Hat Enterprise Linux 7 および 8 の最新バージョンです。
5.2.1. Red Hat Enterprise Linux 8 を使用した NBDE 鍵サーバーのインストール
5.2.1.1. Red Hat Enterprise Linux 8 オペレーティングシステムのダウンロード
- Red Hat カスタマーポータル に移動します。
- Downloads をクリックし、製品ダウンロード一覧を取得します。
- Red Hat Enterprise Linux 8 をクリックします。
-
Product Software（製品ソフトウェア）タブで、最新のバイナリー DVD イメージ（
Red Hat Enterprise Linux 8.2 Binary DVDなど）の横にある Download をクリックします。 ファイルがダウンロードされたら、その SHA-256 チェックサムがページにあるものと一致することを確認します。
$ sha256sum image.isoイメージを使用してインストールメディアデバイスを作成します。
詳細は、Red Hat Enterprise Linux 8 ドキュメントの Creating installation media を参照してください。
5.2.1.2. Red Hat Enterprise Linux 8 オペレーティングシステムの Network-Bound Disk Encryption Key サーバーへのインストール
手順
- 準備済みインストールメディアからマシンを起動し、起動します。
- 起動メニューで Install Red Hat Enterprise Linux 8 を選択し、Enter を押します。
- 言語を選択し、Continue をクリックします。
- デフォルトのLocalizationおよびSoftwareオプションを受け入れます。
Installation destination をクリックします。
オペレーティングシステムをインストールするディスクを選択します。
警告チェックマークが付いているディスクはフォーマットされ、それらのデータはすべて失われます。このホストを再インストールする場合には、保持するデータと共にディスクがチェックマークが表示されないようにします。
（オプション）ディスクの暗号化を使用する場合は、Encrypt my data パスワードを指定します。
警告マシンが起動しなくなるので、このパスワードを忘れないようにしてください。
- 完了をクリックします。
Network and Host Name をクリックします。
-
Ethernet スイッチを
ONに切り替えます。 ネットワークインターフェースを選択し、Configure をクリックします。
- Generalタブで、優先的に自動的に接続するチェックボックスをチェックします。
（オプション）IPv4 の代わりに IPv6 ネットワークを使用するには、IPv6 設定 タブでネットワークの詳細を指定します。
静的ネットワーク設定では、IPv6 アドレス、プレフィックス、ゲートウェイ、ならびに IPv6 DNS サーバーおよび追加の検索ドメインを指定するようにしてください。
重要IPv4 または IPv6 のいずれかを使用する必要があります。混合ネットワークはサポートされません。
- 保存 をクリックします。
- 完了をクリックします。
-
Ethernet スイッチを
- （オプション）セキュリティーポリシーを設定します。
インストールの開始をクリックします。
- root パスワードを設定します。
- 再起動 をクリックしてインストールを完了します。
- 初期セットアップ 画面で、ライセンスアグリーメントに同意して、システムを登録します。
5.2.2. Red Hat Enterprise Linux 7 を使用した NBDE 鍵サーバーのインストール
5.2.2.1. Red Hat Enterprise Linux 7 オペレーティングシステムのダウンロード
- Red Hat カスタマーポータル に移動します。
- Downloads をクリックし、製品ダウンロード一覧を取得します。
- バージョン 7 以下 をクリックします。
-
Product Software（製品ソフトウェア）タブで、最新のバイナリー DVD イメージの横にある Download をクリックします（例:
Red Hat Enterprise Linux 7.8 Binary DVD）。 ファイルがダウンロードされたら、その SHA-256 チェックサムがページにあるものと一致することを確認します。
$ sha256sum image.isoイメージを使用してインストールメディアデバイスを作成します。
詳細は、Red Hat Enterprise Linux 8 ドキュメントの Creating installation media を参照してください。
5.2.2.2. Red Hat Enterprise Linux 7 オペレーティングシステムの Network-Bound Disk Encryption Key サーバーへのインストール
前提条件
- このオペレーティングシステムは、NBDE(Network-Bound Disk Encryption)キーサーバーでのみサポートされることに注意してください。このオペレーティングシステムを使用するハイパーコンバージドホストをインストールしないでください。
手順
- 準備済みインストールメディアからマシンを起動し、起動します。
- 起動メニューで Install Red Hat Enterprise Linux 7 を選択して Enter を押します。
- 言語を選択し、Continue をクリックします。
日付と時刻 をクリックします。
- タイムゾーンを選択します。
- 完了をクリックします。
キーボード をクリックします。
- キーボードレイアウトを選択します。
- 完了をクリックします。
Installation destination をクリックします。
- インストール場所として使用しないディスクの選択を解除します。
ディスクの暗号化を使用する場合は、Encrypt my data パスワードを指定します。
警告マシンが起動しなくなるので、このパスワードを忘れないようにしてください。
- 完了をクリックします。
Network and Host Name をクリックします。
- Configure → General をクリックします。
- このネットワークが利用可能な場合は、自動的に接続する のチェックボックスにチェックを入れます。
- 完了をクリックします。
- 必要に応じて、言語サポート、セキュリティーポリシー、および kdump を設定します。
インストールの開始をクリックします。
- root パスワードを設定します。
- 再起動 をクリックしてインストールを完了します。
- 初期セットアップ 画面で、ライセンスアグリーメントに同意して、システムを登録します。
第6章 追加ソフトウェアのインストール
ソフトウェアおよび更新にアクセスするために追加の設定を実行する必要があります。
- ソフトウェア更新にアクセスできることの確認: Configure software repository access using the web console を参照してください。
- ハイパーコンバージドホストがディスクの暗号化を使用する場合は、Install disk encryption software を参照してください。
6.1. ソフトウェアアクセスの設定
6.1.1. Web コンソールを使用したソフトウェアリポジトリーへのアクセスの設定
前提条件
- このプロセスは、Red Hat Virtualization 4 をベースとするハイパーコンバージドホストを対象にしています。
手順
各ハイパーコンバージドホストで以下を行います。
Web コンソールにログインします。
管理 FQDN およびポート 9090 を使用します（例:
https://server1.example.com:9090/）- Subscriptions をクリックします。
Register System をクリックします。
- カスタマーポータルのユーザー名とパスワードを入力します。
完了をクリックします。
Red Hat Virtualization Host のサブスクリプションが自動的にシステムにアタッチされます。
Red Hat Virtualization 4 のリポジトリーを有効にして、Red Hat Virtualization Host に対する後続の更新を可能にします。
# subscription-manager repos \ --enable=rhvh-4-for-rhel-8-x86_64-rpms
（オプション）ディスクの暗号化を使用する場合は、NBDE(Network-Bound Disk Encryption)キーサーバーごとに以下を実行します。
- NBDE 鍵サーバーにログインします。
NBDE 鍵サーバーを Red Hat に登録します。
# subscription-manager register --username=username --password=password
サブスクリプションプールを割り当てます。
# subscription-manager attach --pool=pool_idディスク暗号化ソフトウェアに必要なリポジトリーを有効にします。
Red Hat Enterprise Linux 8 をベースとした NBDE 鍵サーバーの場合:
# subscription-manager repos \ --enable="rhel-8-for-x86_64-baseos-rpms" \ --enable="rhel-8-for-x86_64-appstream-rpms"
Red Hat Enterprise Linux 7 をベースとした NBDE 鍵サーバーの場合:
# subscription-manager repos --enable="rhel-7-server-rpms"
6.2. ソフトウェアのインストール
6.2.1. ディスク暗号化ソフトウェアのインストール
Network-Bound Disk Encryption key サーバーには、ディスクの暗号化をサポートする追加のパッケージが必要です。
前提条件
手順
NBDE(Network-Bound Disk Encryption)キーサーバーで、サーバー側のパッケージをインストールします。
# yum install tang -y
第7章 ファイアウォールルールの変更
7.1. ディスク暗号化のファイアウォールルールの変更
NBDE(Network-Bound Disk Encryption)鍵サーバーで、暗号鍵を提供できるようにポートを開く必要があります。
手順
各 NBDE 鍵サーバーで以下を行います。
暗号化キーを提供するために必要なポートを開きます。
注記デフォルトのポートは
80/tcpです。カスタムポートを使用するには、Red Hat Enterprise Linux 8 ドキュメントの Configuring a tang server with SELinux in enforcing mode を参照してください。# firewall-cmd --add-port=80/tcp # firewall-cmd --add-port=80/tcp --permanent
以下のコマンドの出力にポートが表示されることを確認します。
# firewall-cmd --list-ports | grep '80/tcp'
第8章 パスワードを使用しない公開鍵ベースの SSH 認証の設定
最初のハイパーコンバージドホスト上のルートユーザーに、そのホスト自体を含むすべてのホストに対するパスワードを使用しない公開鍵ベースのSSH認証を設定します。この作業は、すべてのストレージと管理インターフェースについて、IPアドレスとFQDNの両方に対して行います。
8.1. パスワードなしの SSH 鍵ペアの生成
公開鍵と秘密鍵のペアを生成すると、キーベースの SSH 認証を使用できます。パスワードを使用しないキーペアを生成すると、Ansible を使用してデプロイメントおよび設定プロセスを自動化できます。
手順
- 最初のハイパーコンバージドホストに root ユーザーとしてログインします。
パスワードを使用しない SSH キーを生成します。
キー生成プロセスを開始します。
# ssh-keygen -t rsa Generating public/private rsa key pair.
キーの場所を入力します。
括弧で示されているデフォルトの場所は、他の入力が指定されていない場合に使用されます。
Enter file in which to save the key (/home/username/.ssh/id_rsa): <location>/<keyname>
Enterを 2 回 押して、空白パスフレーズを指定および確認します。Enter passphrase (empty for no passphrase): Enter same passphrase again:
秘密鍵は
<location>/<keyname>に保存されます。公開鍵は<location>/<keyname>.pubに保存されます。Your identification has been saved in <location>/<keyname>. Your public key has been saved in <location>/<keyname>.pub. The key fingerprint is SHA256:8BhZageKrLXM99z5f/AM9aPo/KAUd8ZZFPcPFWqK6+M root@server1.example.com The key's randomart image is: +---[ECDSA 256]---+ | . . +=| | . . . = o.o| | + . * . o...| | = . . * . + +..| |. + . . So o * ..| | . o . .+ = ..| | o oo ..=. .| | ooo...+ | | .E++oo | +----[SHA256]-----+
警告この出力での
Your identificationは、あなたの秘密鍵です。秘密鍵を共有しないでください。自分の秘密鍵を持っていると、自分の公開鍵を持っているシステムで、他人が自分になりすますことができます。
8.2. SSH キーのコピー
秘密鍵を使用してホストにアクセスするには、そのホストには公開鍵のコピーが必要です。
前提条件
- パスワードのない公開鍵と秘密鍵のペアを生成します。
手順
- root ユーザーとして最初のホストにログインします。
フロントエンドとバックエンドの両方のFQDNを使って、コマンドを実行するホストを含む、アクセスする各ホストに、公開鍵をコピーしてください。
# ssh-copy-id -i <location>/<keyname>.pub <user>@<hostname>
プロンプトが表示されたら、
<user>@<hostname>のパスワードを入力します。警告必ず
.pubで終わるファイルを使用していることを確認してください。秘密鍵を共有しないでください。自分の秘密鍵を持っていると、自分の公開鍵を持っているシステムで、他人が自分になりすますことができます。たとえば、3 ノードのデプロイメントにおいて、root ユーザーとして
server1.example.comにログインしている場合は、以下のコマンドを実行します。# ssh-copy-id -i <location>/<keyname>.pub root@server1front.example.com # ssh-copy-id -i <location>/<keyname>.pub root@server2front.example.com # ssh-copy-id -i <location>/<keyname>.pub root@server3front.example.com # ssh-copy-id -i <location>/<keyname>.pub root@server1back.example.com # ssh-copy-id -i <location>/<keyname>.pub root@server2back.example.com # ssh-copy-id -i <location>/<keyname>.pub root@server3back.example.com
第9章 ディスク暗号化の設定
9.1. NBDE(Network-Bound Disk Encryption key)サーバーの設定
前提条件
- Network-Bound Disk Encryption key serverをインストールしている必要があります（Network-Bound Disk Encryption key serverのインストール）。
手順
tangd サービスを開始して有効にします。
NBDE(Network-Bound Disk Encryption)キーサーバーごとに以下のコマンドを実行します。
# systemctl enable tangd.socket --now
ハイパーコンバージドホストが鍵サーバーにアクセスできることを確認します。
- ハイパーコンバージドホストにログインします。
キーサーバーから復号化鍵を要求します。
# curl key-server.example.com/adv以下のような出力が表示された場合、鍵サーバーはアクセス可能で、キーを正しくアドバタイズします。
{"payload":"eyJrZXlzIjpbeyJhbGciOiJFQ01SIiwiY3J2IjoiUC01MjEiLCJrZXlfb3BzIjpbImRlcml2ZUtleSJdLCJrdHkiOiJFQyIsIngiOiJBQ2ZjNVFwVmlhal9wNWcwUlE4VW52dmdNN1AyRTRqa21XUEpSM3VRUkFsVWp0eWlfZ0Y5WEV3WmU5TmhIdHhDaG53OXhMSkphajRieVk1ZVFGNGxhcXQ2IiwieSI6IkFOMmhpcmNpU2tnWG5HV2VHeGN1Nzk3N3B3empCTzZjZWt5TFJZdlh4SkNvb3BfNmdZdnR2bEpJUk4wS211Y1g3WHUwMlNVWlpqTVVxU3EtdGwyeEQ1SGcifSx7ImFsZyI6IkVTNTEyIiwiY3J2IjoiUC01MjEiLCJrZXlfb3BzIjpbInZlcmlmeSJdLCJrdHkiOiJFQyIsIngiOiJBQXlXeU8zTTFEWEdIaS1PZ04tRFhHU29yNl9BcUlJdzQ5OHhRTzdMam1kMnJ5bDN2WUFXTUVyR1l2MVhKdzdvbEhxdEdDQnhqV0I4RzZZV09vLWRpTUxwIiwieSI6IkFVWkNXUTAxd3lVMXlYR2R0SUMtOHJhVUVadWM5V3JyekFVbUIyQVF5VTRsWDcxd1RUWTJEeDlMMzliQU9tVk5oRGstS2lQNFZfYUlsZDFqVl9zdHRuVGoifV19","protected":"eyJhbGciOiJFUzUxMiIsImN0eSI6Imp3ay1zZXQranNvbiJ9","signature":"ARiMIYnCj7-1C-ZAQ_CKee676s_vYpi9J94WBibroou5MRsO6ZhRohqh_SCbW1jWWJr8btymTfQgBF_RwzVNCnllAXt_D5KSu8UDc4LnKU-egiV-02b61aiWB0udiEfYkF66krIajzA9y5j7qTdZpWsBObYVvuoJvlRo_jpzXJv0qEMi"}
9.2. ハイパーコンバージドホストをNetwork-Bound Disk Encryptionクライアントとして設定する。
9.2.1. ディスク暗号化設定の詳細の定義
- 最初のハイパーコンバージドホストにログインします。
hc-ansible-deploymentディレクトリーに移動します。# cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
今後の参照用に
luks_tang_inventory.ymlファイルのコピーを作成します。cp luks_tang_inventory.yml luks_tang_inventory.yml.backup
luks_tang_inventory.yml ファイルで設定を定義します。
サンプルの
luks_tang_inventory.ymlファイルを使用して、各ホストでディスク暗号化の詳細を定義します。このファイルの概要については、Understanding the luks_tang_inventory.yml fileに記載されています。luks_tang_inventory.ymlファイルを編集し、ansible-vaultを使用してパスワードを指定します。luks_tang_inventory.ymlに必要な変数にはパスワードの値が含まれます。そのため、パスワード値を保護するためにファイルを暗号化することが重要です。# ansible-vault encrypt luks_tang_inventory.yml
プロンプトが表示されたら、新しい vault パスワードを入力し、確認します。
9.2.2. ディスク暗号化設定 Playbook の実行
前提条件
-
luks_tang_inventory.ymlplaybookで設定を定義する: 「ディスク暗号化設定の詳細の定義」. - ハイパーコンバージドホストには、暗号化されたブートディスクが必要です。
手順
- 最初のハイパーコンバージドホストにログインします。
hc-ansible-deployment ディレクトリーに移動します。
# cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
rootユーザーで以下のコマンドを実行すると、設定プロセスが開始されます。
# ansible-playbook -i luks_tang_inventory.yml tasks/luks_tang_setup.yml --tags=blacklistdevices,luksencrypt,bindtang --ask-vault-pass
ディスク暗号化の設定を開始するプロンプトが表示されたら、このファイルの vault パスワードを入力します。
検証
- 各ホストを再起動して、復号したパスフレーズを手動で入力しなくても、ログインプロンプトに起動できることを確認します。
-
ディスク暗号化を使用するデバイスには、Red Hat Hyperconverged Infrastructure for Virtualization の設定を継続すると、
/dev/mapper/luks_sdXのパスがあることに注意してください。
トラブルシューティング
指定したブートデバイス
/dev/sda2は暗号化されません。TASK [Check if root device is encrypted] fatal: [server1.example.com]: FAILED! => {"changed": false, "msg": "The given boot device /dev/sda2 is not encrypted."}
ソリューション 「ハイパーコンバージドホストのインストール」 に記載されている手順でハイパーコンバージドホストを再インストールします。インストールプロセス中にEncrypt my data を選択し、ディスク暗号化に関するすべての指示に従うことを確認してください。
この結果では、no_log: true が指定されているという事実により、出力は表示されません。
TASK [gluster.infra/roles/backend_setup : Encrypt devices using key file] failed: [host1.example.com] (item=None) => {"censored": "the output has been hidden due to the fact that no_log: true was specified for this result", "changed": true}
パスフレーズを公開しないように、この出力が切り替わりました。
Encrypt devices using key fileタスクでこの出力が表示された場合、デバイスの暗号化に失敗しています。インベントリーファイルに誤ったディスクを指定している可能性があります。解決策: デプロイに失敗した後、Cleaning up Network-Bound Disk Encryption after a failed deploymentを参照してデプロイメントのクリーンアップします。次に、インベントリーファイルでディスク名を修正します。
Tang サーバーからゼロ以外のリターンコード
TASK [gluster.infra/roles/backend_setup : Download the advertisement from tang server for IPv4] * failed: [host1.example.com] (item={url: http://tang-server.example.com}) => {"ansible_index_var": "index", "ansible_loop_var": "item", "changed": true, "cmd": "curl -sfg \"http://tang-server.example.com/adv\" -o /etc/adv0.jws", "delta": "0:02:08.703711", "end": "2020-06-10 18:18:09.853701", "index": 0, "item": {"url": "http://tang-server.example.com"}, "msg": "non-zero return code*", "rc": 7, "start": "2020-06-10 18:16:01.149990", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}
このエラーは、提供されたFQDNが正しくないか、ホストから見つからないために、サーバーが提供された
urlにアクセスできないことを示しています。解決策: NBDE キーサーバーに提供される
urlの値を修正するか、またはurl値がホストからアクセス可能であることを確認します。次に、bindtangタグを使用して Playbook を再度実行します。# ansible-playbook -i luks_tang_inventory.yml tasks/luks_tang_setup.yml --ask-vault-pass --tags=bindtang- その他のプレイブックの失敗については、Cleaning up Network-Bound Disk Encryption after a failed deploymentの手順で、デプロイメントをクリーンアップしてください。設定 Playbook を再度実行する前に、Playbook とインベントリーファイルで誤った値を確認し、すべてのサーバーへのアクセスをテストします。
第10章 Web コンソールを使用したHosted Engine用Red Hat Gluster Storage の設定
このデプロイメントプロセスの一部として指定するディスクに、パーティションやラベルがないことを確認してください。
Web コンソールにログインします。
最初のハイパーコンバージドホストの Web コンソール管理インターフェース（例: https://node1.example.com:9090/）を参照し、「ハイパーコンバージドホストのインストール」で作成した認証情報でログインします。
デプロイメントウィザードの開始
Virtualization → Hosted Engine をクリックし、Hyperconverged の下の Start をクリックします。
Gluster Configuration ウィンドウが開きます。
Run Gluster Wizard ボタンをクリックします。
Gluster Deployment ウインドウが3ノードモードで開きます。
ホストの指定
-
ホストが複数のネットワークを使用しない場合は、
Use same hostname for storage and public networkのチェックボックスをチェックします。 -
ホストが IPv6 ネットワークを使用している場合は、
Select if hosts are using IPv6を確認します。このオプションを選択すると、ホストが FQDN を使用する必要があります。IPv6 アドレスはサポートされません。 ハイパーコンバージドホストのバックエンド（ストレージネットワーク）とフロントエンド（パブリックネットワーク）のFQDNを指定します。
Host1フィールドには、キーベース認証を使ってパスワードなしで他のホストにSSH接続できるハイパーコンバージドホストのFQDNを指定します。
- Next をクリックします。
-
ホストが複数のネットワークを使用しない場合は、
ボリュームの指定
作成するボリュームを指定します。
- 名前
- 作成するボリュームの名前を指定します。
- ボリュームタイプ
- 3ノードのデプロイメントでは、複製ボリュームのみがサポートされます。
- Arbiter
- 判定ブリックを使用してボリュームを作成するかどうかを指定します。このボックスをチェックすると、3番目のディスクにはメタデータのみが保存されます。
- ブリックDir
-
このボリュームのブリックが含まれるディレクトリー。
gluster_bricks/<volname>/<volname>形式のブリックパスを使用します。
ほとんどのインストールでは、デフォルト値が正しくありません。
追加のボリュームが必要な場合は、Add Volumes をクリックして別の行を追加し、追加のボリュームの詳細を入力します。
ブリックの指定
作成するブリックの詳細を入力します。
- RAID タイプ
- ホストの RAID 設定を指定します。サポートされる値は、raid5、raid6、jbod です。このオプションを設定すると、RAID 設定用にストレージが正しく調整されるようになります。
- ストライプサイズ
- RAID のストライプサイズを KB 単位で指定します。これは、jbod 設定で無視できます。
- データディスク数
- ホストの RAID ボリューム内のデータディスクの数を指定します。これは、jbod 設定で無視できます。
- Gluster デバイスをブラックリスト登録
-
Gluster ブリックとして指定されているディスクが、マルチパスデバイス名を使用しないようにします。マルチパスデバイス名を使用する場合は、このチェックボックスのチェックを外して、
/dev/mapper/<WWID>形式を使用してDeviceフィールドを指定します。 - ホストの選択
- ホストが異なるデバイス名やサイズを使用する必要がある場合は、このドロップダウンメニューを使用して、設定したいホストに変更します。
- LV Name
- 作成する論理ボリュームの名前。これは、ウィザードの前のページで指定した名前で事前に入力されます。
- デバイス名
-
/dev/sdcの形式で、使用する raw デバイスを指定します。マルチパスデバイスには、/dev/mapper/<WWID>形式を使用します。Network-Bound Disk Encryption を使用するデバイスに/dev/mapper/luks_<name>形式を使用します。 - LV Size
- 作成する論理ボリュームのサイズ（GiB 単位）を指定します。単位は入力しないでください。この数字のみ入力してください。この数は、複製されたセット内のすべてのブリックで同じである必要があります。Arbiter ブリックは、レプリケーションセット内の他のブリックよりも小さくすることができます。
- LVサイズの推奨値
- エンジンブリックの論理ボリュームは、サイズ100 GBのシックLVとし、他のブリックはシンプールのメタデータ用に16 GB、スペアメタデータ用に16 GBを確保したシンLVとして作成します。
例:
If the host has a disk of size 1TB, then engine brick size = 100GB ( thick LV ) Pool metadata size = 16GB Spare metadata size = 16GB Available space for thinpool = 1TB - ( 100GB + 16GB + 16GB ) = 868 GB
ボリューム用の他のブリックは、利用可能な868 GBのシンプールのストレージスペースで作成することができます。例えば、vmstoreブリックは200 GB、dataブリックは668 GBです。
- デプレートおよび圧縮の有効化
デプロイメント時に圧縮および重複排除に VDO を使用してボリュームをプロビジョニングするかどうかを指定します。ブリックの論理サイズは、VDO 領域の節約の一環として、物理ボリュームのサイズを 10 倍に拡張します。
注記ボリュームの一部であるすべてのブリックに対して、
Dedupe & Compressionを有効にしてください。- LV キャッシュの設定
必要に応じて、このチェックボックスにチェックを付けて、高速 SSD デバイスを、大規模で低速な論理ボリュームの論理ボリュームキャッシュとして設定します。
- デバイスパスを SSD フィールドに追加します。
- キャッシュデバイスをアタッチ する Thinpool device を指定します。
- LV Size(GB) フィールドにサイズを追加します。
- デバイス が使用する Cache Mode を設定します。
警告ライトバックモードを使用する際にデータの損失を回避するために、Red Hat は 2 つの異なる SSD/NVMe デバイスを使用することを推奨します。（ソフトウェアまたはハードウェア経由）RAID-1 設定で 2 つのデバイスを設定すると、書き込みが失われる可能性が大幅に削減されます。
lvmcache 設定の詳細は、Red Hat Enterprise Linux 8 ドキュメントの LVM cache logical volumes を参照してください。
設定の確認および編集
Edit をクリックして、生成されたデプロイメント設定ファイルの編集を開始します。
必要な変更を加え、Save をクリックします。
設定ファイルを確認します。
すべての設定の詳細が正しい場合は、Deploy をクリックします。
デプロイメントが完了するまで待ちます。
テキストフィールドでデプロイメントの進捗を確認できます。
ウィンドウには、Successfully deployed gluster が表示されます。
Continue to Hosted Engine Deployment をクリックし、11章Web コンソールを使用したHosted Engineのデプロイ の手順に従ってデプロイメントプロセスを続行します。
デプロイメントに失敗した場合は、Clean up をクリックして、システムへの正しくない変更をすべて削除します。配置に Network-Bound Disk Encryption を使用している場合は、Cleaning up Network-Bound Disk Encryption after a failed deployment の手順に従う必要があります。
クリーンアップが完了したら、Redeploy をクリックします。これにより Review and edit configuration タブに戻り、デプロイメントを再試行する前に生成された設定ファイルの問題を修正できます。
第11章 Web コンソールを使用したHosted Engineのデプロイ
本セクションでは、Web コンソールを使用して、Hosted Engineをデプロイする方法を説明します。このプロセスを実行すると、Red Hat Virtualization Manager がデプロイメントの最初の物理マシン上で仮想マシンとして実行されます。また、3 台の物理マシンで構成される Default クラスタを構成し、クラスタ内の各マシンに対して Red Hat Gluster Storage 機能とvirtual-host tunedパフォーマンスプロファイルを有効にします。
前提条件
- デプロイメントプロセス中に RHV-M Appliance がインストールされている。ただし、必要な場合は、インストールを開始する前にデプロイメントホストにインストールすることができます。
# yum install rhvm-appliance
Manager 用仮想マシンの手動インストールはサポートされていません。
- Web コンソールを使用したHosted Engine用Red Hat Gluster Storage の設定
ホスト型エンジンデプロイメントに必要な情報を収集
デプロイメントプロセスを開始する前に、以下の情報を準備してください。
- hyperconverged ホストへの ping 送信可能なゲートウェイの IP アドレス
- フロントエンド管理ネットワークの IP アドレス
- ホスト型エンジン仮想マシンの完全修飾ドメイン名(FQDN)
- ホスト型エンジンの静的 FQDN および IP アドレスに解決する MAC アドレス
手順
ホスト型エンジン Deployment ウィザードを開く
Web コンソールを使用したHosted Engine用Red Hat Gluster Storage の設定 の最後から継続する場合には、ウィザードはすでに開いていることになります。
それ以外の場合:
- Virtualization → Hosted Engine をクリックします。
- Hyperconverged の下にある Start をクリックします。
Use existing configuration をクリックします。
重要以前のデプロイメントに失敗した場合は、Use existing configuration ではなく Clean up をクリックして、以前の試行を最初から破棄して開始します。配置に Network-Bound Disk Encryption を使用している場合は、Cleaning up Network-Bound Disk Encryption after a failed deployment の手順に従う必要があります。
仮想マシンの詳細の指定
以下の詳細を入力します。
- エンジン仮想マシン FQDN
-
ホスト型エンジン仮想マシンに使用される完全修飾ドメイン名（例:
engine.example.com）。 - MAC Address
Engine VM FQDN に関連付けられた MAC アドレス。
重要事前に設定された MAC アドレスを置き換える必要があります。
- Network Configuration
Network Configuration ドロップダウンリストから DHCP または Static のいずれかを選択します。
- DHCP を選択する場合は、ホストされる Engine 仮想マシンの DHCP 予約があり、そのホスト名が DHCP から受信したアドレスに解決されるようにします。その MAC アドレスを MAC Address フィールドで指定します。
Static を選択した場合には、以下の情報を入力します。
- VM IP Address: IP アドレスは、ホストと同じサブネットに属している必要があります。たとえば、ホストが 10.1.1.0/24 内にある場合、Hosted Engine 仮想マシンの IP は同じサブネット範囲(10.1.1.1-254/24)になければなりません。
- Gateway Address: ゲートウェイの IP アドレス
- DNS サーバー
- ブリッジインターフェース
- Bridge Interface のドロップダウンリストから、ブリッジインターフェースを選択します。
- root パスワード
- Hosted Engine 仮想マシンに使用される root パスワード。
- Root SSH Access
- Root SSH Access を許可するかどうかを指定します。Root SSH Access のデフォルト値が Yes に設定されます。
- 仮想 CPU 数
- 仮想マシンの Number of Virtual CPU を入力します。
- メモリーサイズ(MiB)
Memory Size(MiB)に、メモリーのサイズを入力します。使用可能なメモリー容量が入力フィールドの横に表示されます。
注記Red Hat は、Root SSH Access、仮想 CPU の数、および Memory Size の値をデフォルト値に維持することを推奨します。
オプションで、Advanced フィールドを展開します。
- Root SSH Public Key
- ホスト型エンジン仮想マシンへの root アクセスに使用する Root SSH Public Key を入力します。
- ホストファイルの編集
- Edit Hosts File のチェックボックスを選択/選択解除して、Hosted Engine 仮想マシンとベースホストのエントリーを仮想マシンの /etc/hosts ファイルに追加するかどうかを指定します。ホスト名は解決可能でなければなりません。
- ブリッジ名
- Bridge Name で管理ブリッジの名前を変更します。あるいは、デフォルトの ovirtmgmt を適用します。
- Gateway Address: ゲートウェイの IP アドレス
- Gateway Address に、管理ブリッジのゲートウェイアドレスを入力します。
- ホスト FQDN
- Manager に追加する最初のホストのホスト FQDN を入力します。これは、デプロイメントを実行しているベースホストのフロントエンド FQDN です。
- ネットワークテスト
-
静的ネットワーク設定がある場合、または
/etc/hostsで定義されたアドレスを持つ分離された環境を使用している場合は、Network Test を Ping に設定します。
- Next をクリックします。FQDN は、次の画面が表示される前に検証されます。
仮想管理の詳細を指定する
管理ポータルで
adminアカウントが使用するパスワードを入力します。通知用にメールアドレスを指定することもできます。通知の後デプロイメントも設定できます。15章デプロイメント後設定の提案 を参照してください。
- Next をクリックします。
仮想マシン設定の確認
このタブにリストされている詳細が正しいことを確認します。Back をクリックして、誤った情報を修正します。
- Prepare VM をクリックします。
仮想マシンの準備が完了するまで待ちます。
準備が正常に行われない場合は、Viewing Hosted Engine deployment errors を参照してください。
- Next をクリックします。
Hosted Engine仮想マシンのストレージの検証
Mount Optionsの欄に、
backup-volfile-servers=<host2-ip-address>:<host3-ip-address>、およびIPv6を使用する場合はxlator-option=transport.address-family=inet6が正しく入力されていることを確認します。以下に例を示します。backup-volfile-servers=<host2-ip-address>:<host3-ip-address>,xlator-option=transport.address-family=inet6
- Next をクリックします。
ホスト型エンジンのデプロイメントの最終処理
デプロイメントの詳細を確認し、それらが正しいことを確認します。
注記設定中に指定した応答は応答ファイルに保存され、必要に応じてホストされたエンジンを再インストールする上で役立ちます。応答ファイルは、デフォルトで
/etc/ovirt-hosted-engine/answers.confに作成されます。このファイルは、Red Hat サポートの支援なしに手動で変更することができません。
- Finish Deployment をクリックします。
デプロイメントが完了するまで待ちます。
設定の詳細によっては、時間がかかる場合があります。
ウィンドウには、完了すると以下が表示されます。
重要RHHI-V のデプロイメントが正常に完了した後、他の 2 つの Red Hat Virtualization ホストが再起動されます。これらのホストが起動するのを待つと、Red Hat Virtualization 管理ポータルにアクセスできるようになります。デプロイメントが正常に完了しない場合は、Viewing Hosted Engine deployment errors を参照してください。
Close をクリックします。
ホストエンジンのデプロイメントの確認
管理ポータル（例: http://engine.example.com/ovirt-engine）を参照し、前のステップで設定した管理認証情報を使用してログインできることを確認します。Dashboard をクリックし、ホスト、ストレージドメイン、および仮想マシンを検索します。
第12章 gluster トラフィック用論理ネットワークの設定
個別の gluster 論理ネットワークを作成するために、Red Hat Hyperconverged Infrastructure for Virtualization (RHHI for Virtualization) 1.7 では、Red Hat Virtualization 管理ポータルから手動で手順を実行する必要がありました。RHHI for Virtualization 1.8からは、このプロセスを次のようにAnsible Playbookを使って自動化できます。
12.1. glusterトラフィックの論理ネットワーク詳細の定義
前提条件
- Red Hat Hyperconverged Infrastructure for Virtualization のデプロイメントが完了し、ホストが動作状態にある。
手順
- 最初のハイパーコンバージドホストにログインします。
hc-ansible-deploymentディレクトリーに移動します。# cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
今後の参照用に
gluster_network_inventory.ymlファイルのコピーを作成します。# cp gluster_network_inventory.yml gluster_network_inventory.yml.backup
gluster_network_inventory.ymlファイルで設定を定義します。サンプルの
gluster_network_inventory.ymlファイルを使用して、各ホストの詳細を定義します。このファイルの概要については、gluster_network_inventory.yml ファイルの概要に記載されています。gluster_network_inventory.ymlファイルを暗号化し、ansible-vaultを使用してパスワードを指定します。gluster_network_inventory.ymlに必要な変数にはパスワードの値が含まれます。そのため、パスワード値を保護するためにファイルを暗号化することが重要です。# ansible-vault encrypt gluster_network_inventory.yml
プロンプトが表示されたら、新しい vault パスワードを入力し、確認します。
12.2. gluster ネットワーク用 Playbookの実行
前提条件
-
gluster_network_inventory.ymlPlaybookで設定を定義します：「glusterトラフィックの論理ネットワーク詳細の定義」
手順
- 最初のハイパーコンバージドホストにログインします。
hc-ansible-deployment ディレクトリーに移動します。
# cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
rootユーザーで以下のコマンドを実行すると、設定プロセスが開始されます。
# ansible-playbook -i gluster_network_inventory.yml tasks/gluster_network_setup.yml --ask-vault-pass
ネットワークの設定を開始するプロンプトが表示されたら、このファイルの vault パスワードを入力します。
12.3. gluster トラフィック用論理ネットワークの確認
以下を確認し、gluster トラフィック用の論理ネットワークが正常に作成され、ホストに接続されていることを検証します。
gluster 論理ネットワークの可用性を検証します。
- 管理ポータルにログインします。
-
Network→Networks をクリックします。これにより、新しく作成された
gluster_netネットワークが一覧表示されます。 -
gluster_net → Clustersタブの順にクリックし、Network Roleカラムにマウスを合わせると
Migration Glusterと表示されます。
gluster_netが全てのホストのストレージネットワークインターフェースに接続されていることを確認します。- Compute→Hosts→ 任意のホストをクリックします。
-
Network Interfacesタブを選択し、ストレージやバックエンドのネットワークに対応するLogical Networksというラベルの近くにあるドロップダウンボタンをクリックすると、ネットワーク名として
gluster_netが表示されます。
12.4. (オプション) ジャンボフレーム用の論理ネットワークの編集
ジャンボフレーム（MTU 9000）を有効にしている場合は、デフォルトのネットワーク設定を編集して、ストレージのトラフィックにジャンボフレームが使用されるようにする必要があります。ネットワークコンポーネント（スイッチ）がジャンボフレームに対応している必要があります。
ここでは、ストレージネットワークgluster_netのジャンボフレーム用に論理ネットワークを編集する手順を説明します。
前提条件
- gluster トラフィック用の論理ネットワークが正常に作成され、ホストに接続されている。
手順
- 管理ポータルにログインします。
- Networks→Network をクリックします。
- gluster_net→Edit をクリックします。
- カスタムMTUを選択し、9000とします。
- OK をクリックします。
すべてのネットワークコンポーネントが同じMTUで有効になっていることを確認してください。
パート III. 検証
第13章 デプロイメントの確認
デプロイメントが完了したら、デプロイメントが正常に完了したことを確認します。
管理ポータルを参照します（例: http://engine.example.com/ovirt-engine）。
管理コンソールのログイン
ホスト型エンジンのデプロイメント時に追加された管理認証情報を使用してログインします。
ログインに成功すると、Dashboard が表示されます。
管理コンソールダッシュボード
クラスターが利用可能であることを確認します。
管理コンソールダッシュボード - クラスター
少なくとも1 つのホストが利用可能であることを確認します。
Hosted Engineのデプロイメント時に追加のホスト情報を提供した場合は、図のように3つのホストがここに表示されます。
管理コンソールダッシュボード - Hosts
- Compute → Hosts をクリックします。
すべてのホストの Status が
Upと表示されていることを確認します。管理コンソール - Hosts
すべてのストレージドメインが利用可能であることを確認します。
- Storage → Domains をクリックします。
Activeアイコンが最初の列に表示されることを確認します。管理コンソール: ストレージドメイン
パート IV. 次のステップ
第14章 Red Hat Virtualization Manager リポジトリーの有効化
システムを Red Hat Subscription Manager に登録し、Red Hat Virtualization Manager のサブスクリプションをアタッチして Manager のリポジトリーを有効にします。
手順
コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
# subscription-manager register
注記IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。
Red Hat Virtualization Manager のサブスクリプションプールを見つけ、プール ID を記録します。
# subscription-manager list --available
上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。
# subscription-manager attach --pool=pool_id
注記現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。
# subscription-manager list --consumed
有効なリポジトリーをすべて一覧表示するには、以下のコマンドを実行します。
# yum repolist
リポジトリーを設定します。
# subscription-manager repos \ --disable='*' \ --enable=rhel-8-for-x86_64-baseos-rpms \ --enable=rhel-8-for-x86_64-appstream-rpms \ --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \ --enable=fast-datapath-for-rhel-8-x86_64-rpms \ --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \ --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \ --enable=rhceph-4-tools-for-rhel-8-x86_64-rpmspki-deps モジュールを有効にします。
# yum module -y enable pki-deps
postgresql モジュールのバージョン 12 を有効にします。
# yum module -y enable postgresql:12
インストール済みパッケージを同期して、利用可能な最新バージョンに更新します。
# yum distro-sync
関連情報
モジュールとモジュールストリームについては、インストール、管理、およびユーザ空間コンポーネントの削除のセクションを参照してください。
第15章 デプロイメント後設定の提案
要件によっては、新たにデプロイした Red Hat Hyperconverged Infrastructure for Virtualization で追加の設定を実行することができます。本セクションでは、追加の設定に推奨される手順を説明します。
これらのプロセスの詳細は、Maintaining Red Hat Hyperconverged Infrastructure for Virtualization を参照してください。
15.1. 通知の設定
メール通知を設定するには、Configuring Event Notifications in the Administration Portal を参照してください。
15.2. （オプション）ホストの電源管理の設定
Red Hat Virtualization Manager 4.4 は、稼働していないか、応答しない状態になったホストを再起動することができ、また使用率の低いホストの電源をオフにして電力を節約することができます。この機能は、適切に設定された電源管理デバイスによって異なります。
詳細は、Configuring Host Power Management Settings を参照してください。
15.3. バックアップおよびリカバリーオプションの設定
Red Hat は、すべての実稼働デプロイメントで少なくとも基本的な障害復旧機能を設定することを推奨します。
詳細については、Maintaining Red Hat Hyperconverged Infrastructure for Virtualization の Configuring backup and recovery options を参照してください。
パート V. Troubleshoot
第16章 ログファイルの場所
デプロイメントプロセス中に、進捗情報が Web ブラウザーに表示されます。この情報はローカルファイルシステムにも保存され、ログに記録された情報をアーカイブまたは後で確認したりできます。たとえば、Web ブラウザーが応答を停止するか、情報の確認前に閉じられた場合などがこれに該当します。
Web コンソールベースのデプロイメントプロセスのログファイル（10章Web コンソールを使用したHosted Engine用Red Hat Gluster Storage の設定に文書化）は、デフォルトで /var/log/cockpit/ovirt-dashboard/gluster-deployment.log ファイルに保存されます。
デプロイメントプロセスのホストエンジンのセットアップ部分のログファイル（11章Web コンソールを使用したHosted Engineのデプロイ で説明）は、/var/log/ovirt-hosted-engine-setupディレクトリに格納され、ファイル名はovirt-hosted-engine-setup-<date>.log という形式になっています。
第17章 デプロイメントエラー
17.1. クリーンアップ操作の順序
デプロイメントが失敗する場所によっては、多くのクリーンアップ操作を実施する必要がある場合があります。
タスク自体の順序に対して、タスクのクリーンアップを逆に実行します。たとえば、デプロイメント時に以下のタスクを実行します。
- Ansible を使用した Network-Bound Disk Encryption(Network-Bound Disk Encryption)を設定します。
- Web コンソールを使用して Red Hat Gluster Storage を設定します。
- Web コンソールを使用してホスト型エンジンを設定します。
ステップ 2 でデプロイメントが失敗する場合は、ステップ 2 のクリーンアップを実行します。必要に応じて、手順 1 のクリーンアップを実行します。
17.2. ストレージのデプロイに失敗しました
ストレージのデプロイメント中にエラーが発生した場合、展開プロセスが停止し、Deployment failed と表示されます。
ストレージのデプロイに失敗しました
- エラー情報については、Web コンソールの出力を確認します。
- Clean up をクリックして、システムに不正な変更をすべて削除します。配置に Network-Bound Disk Encryption を使用している場合は、Cleaning up Network-Bound Disk Encryption after a failed deployment の手順に従う必要があります。
- Redeploy をクリックし、エラーが出される可能性のある入力値を修正します。エラーの解決に関するヘルプが必要な場合は、詳細について Red Hat サポートにお問い合わせください。
- ストレージのデプロイメントに戻って、もう一度試してみてください。
17.2.1. デプロイメントの失敗後のネットワーク境界ディスク暗号化のクリーンアップ
Network-Bound Disk Encryption を使用し、デプロイメントが失敗する場合は、Cleanupボタンをクリックして再度試行することはできません。また、再起動する前に、luks_device_cleanup.yml Playbook を実行してクリーニングプロセスを完了させる必要もあります。
以下に示すようにこの Playbook を実行し、セットアップ中に指定した luks_tang_inventory.yml ファイルを提供します。
# ansible-playbook -i luks_tang_inventory.yml /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/tasks/luks_device_cleanup.yml --ask-vault-pass
17.2.2. Error: VDO signature detected on device
ストレージのデプロイメント中、Create VDO with specified size の作成は、VDO signature detected on device で失敗する可能性があります。
TASK [gluster.infra/roles/backend_setup : Create VDO with specified size] task path: /etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml:9 failed: [host1.example.com] (item={u'writepolicy': u'auto', u'name': u'vdo_sdb', u'readcachesize': u'20M', u'readcache': u'enabled', u'emulate512': u'off', u'logicalsize': u'11000G', u'device': u'/dev/sdb', u'slabsize': u'32G', u'blockmapcachesize': u'128M'}) => {"ansible_loop_var": "item", "changed": false, "err": "vdo: ERROR - vdo signature detected on /dev/sdb at offset 0; use --force to override\n", "item": {"blockmapcachesize": "128M", "device": "/dev/sdb", "emulate512": "off", "logicalsize": "11000G", "name": "vdo_sdb", "readcache": "enabled", "readcachesize": "20M", "slabsize": "32G", "writepolicy": "auto"}, "msg": "Creating VDO vdo_sdb failed.", "rc": 5}
このエラーは、指定したデバイスがすでに VDO デバイスである場合や、デバイスが VDO デバイスとして設定されていて、正しくクリーンアップされなかった場合に発生します。
- VDO デバイスを誤って指定した場合は、ストレージ設定に戻り、VDO 以外のデバイスとは異なるものを指定します。
以前 VDO デバイスとして使用されていたデバイスを指定した場合は、以下を行います。
デバイスの種類を確認します。
# blkid -p /dev/sdb /dev/sdb: UUID="fee52367-c2ca-4fab-a6e9-58267895fe3f" TYPE="vdo" USAGE="other"
出力に
TYPE="vdo"が表示されても、このデバイスは適切にクリーンアップされませんでした。- このデバイスを使用するには、Manually cleaning up a VDO device 手順に従ってください。その後、ストレージのデプロイメント に戻り、再度検証します。
クリーンなデバイスを指定し、ストレージデプロイメントウィンドウの Clean up ボタンを使用して、失敗したデプロイメントをクリーンアップしてこのエラーを回避します。
17.2.3. VDO デバイスの手動クリーンアップ
以下の手順に従って、デプロイメントの失敗の原因となった VDO デバイスを手動でクリーンアップします。
これは破壊的プロセスです。クリーンアップするデバイスのデータはすべて失われます。
手順
wipefs を使用してデバイスをクリーンアップします。
# wipefs -a /dev/sdX
検証
デバイスに
TYPE="vdo"が設定されていない ことを確認します。# blkid -p /dev/sdb /dev/sdb: UUID="fee52367-c2ca-4fab-a6e9-58267895fe3f" TYPE="vdo" USAGE="other"
次のステップ
- ストレージのデプロイメントに戻って、もう一度試してみてください。
17.3. 仮想マシンの準備に失敗しました
Hosted Engine のデプロイメント における仮想マシンの準備中にエラーが発生した場合には、デプロイメントは一時停止し、以下のような画面が表示されます。
仮想マシンの準備に失敗しました
- エラー情報については、Web コンソールの出力を確認します。
- Back をクリックして、エラーの原因となった可能性がある入力値を修正します。ネットワーク設定に適切な値が VM タブに提供されるようにしてください。エラーの解決に関するヘルプが必要な場合は、詳細について Red Hat サポートにお問い合わせください。
rhvm-applianceパッケージが最初のハイパーコンバージドホストで利用可能であることを確認します。# yum install rhvm-appliance
Hosted Engine のデプロイメント に戻って再試行してください。
エラーを解決している間にデプロイメントウィザードを終了する場合は、デプロイメントプロセスを再試行するときに、Use existing configuration を選択します。
17.4. ホスト型エンジンのデプロイに失敗しました
ホストされているエンジンのデプロイメント中にエラーが発生した場合には、デプロイメントの一時停止と Deployment failed が表示されます。
ホスト型エンジンのデプロイメントに失敗しました
- エラー情報については、Web コンソールの出力を確認します。
engineボリュームの内容を削除します。engineボリュームをマウントします。# mount -t glusterfs <server1>:/engine /mnt/test
ボリュームの内容を削除します。
# rm -rf /mnt/test/*
engineボリュームをアンマウントします。# umount /mnt/test
- Redeploy をクリックし、エラーが出される可能性のある入力値を修正します。
上記のステップ a、b、および c の実行後にデプロイメントが失敗する場合以下の手順を再度実行し、続いてホスト型エンジンをクリーンアップします。
# ovirt-hosted-engine-cleanup
Hosted Engine のデプロイメント に戻って再試行してください。
エラーを解決している間にデプロイメントウィザードを終了する場合は、デプロイメントプロセスを再試行するときに、Use existing configuration を選択します。
エラーの解決に関するヘルプが必要な場合は、詳細について Red Hat サポートにお問い合わせください。
パート VI. 参考資料
付録A Ansible Vault で暗号化されたファイルの使用
Red Hat は、パスワードやその他の機密情報を含むデプロイメントおよび管理ファイルの内容を暗号化することを推奨します。Ansible Vault は、これらのファイルを暗号化する 1 つの方法です。Ansible Vault の詳細は、Ansible documentation を参照してください。
A.1. ファイルの暗号化
ansible-vault createコマンドで暗号化ファイルを作成したり、ansible-vault encryptコマンドで既存のファイルを暗号化することができます。
暗号化ファイルを作成したり、既存のファイルを暗号化したりすると、パスワードを指定するように求められます。このパスワードは、暗号化後にファイルを復号化するために使用されます。このファイル内の情報を直接使用する場合や、ファイルの内容に依存する Playbook を実行する場合は、このパスワードを指定する必要があります。
暗号化されたファイルの作成
$ ansible-vault create variables.yml
New Vault password:
Confirm New Vault password:
ansible-vault create コマンドは新しいファイルのパスワードを要求し、保存する前にファイルを生成できるようにデフォルトのテキストエディター（シェル環境で $EDITOR として定義）で新規ファイルを開きます。
すでにファイルを作成していて、それを暗号化したい場合は、ansible-vault encryptコマンドを使用します。
既存のファイルの暗号化
$ ansible-vault encrypt existing-variables.yml
New Vault password:
Confirm New Vault password:
Encryption successful
A.2. 暗号化されたファイルの編集
暗号化されたファイルを編集するには、ansible-vault editコマンドを使用し、そのファイルのVaultパスワードを指定します。
暗号化されたファイルの編集
$ ansible-vault edit variables.yml
New Vault password:
Confirm New Vault password:
ansible-vault editコマンドは、ファイルのパスワードの入力を求め、デフォルトのテキストエディタ（シェル環境で$EDITORと定義されている）でファイルを開き、ファイルの内容を編集・保存できるようにします。
A.3. 暗号化されたファイルの新規パスワードへのキーの指定
ansible-vault rekey コマンドを使用して、ファイルの復号化に使用するパスワードを変更できます。
$ ansible-vault rekey variables.yml
Vault password:
New Vault password:
Confirm New Vault password:
Rekey successful
ansible-vault rekey コマンドは、現在の Vault パスワードの入力を要求し、新しい Vault パスワードを設定して確認するプロンプトを表示します。
付録B luks_tang_inventory.yml ファイルについて
B.1. ディスク暗号化の設定パラメーター
- hc_nodes（必須）
ホストのバックエンド FQDN を使用するハイパーコンバージドホストの一覧およびそのホストの設定詳細。ホスト固有の設定は、ホストのバックエンド FQDN の下に定義されます。すべてのホストに共通する設定は vars: セクションで定義されます。
hc_nodes: hosts: host1backend.example.com: [configuration specific to this host] host2backend.example.com: host3backend.example.com: host4backend.example.com: host5backend.example.com: host6backend.example.com: vars: [configuration common to all hosts]- blacklist_mpath_devices（オプション）
デフォルトでは、Red Hat Virtualization Host はマルチパス設定を有効にし、ディスクに基礎となるマルチパス設定がなくても、すべてのディスクに一意のマルチパス名とワールドワイド識別子を提供します。マルチパスデバイス名が一覧表示されるデバイスに使用されていないようにマルチパス設定がない場合は、このセクションを追加してください。ここに記載されていないディスクは、マルチパス構成が利用可能であると想定され、インベントリーファイルの後続のセクションで定義する際には、
/dev/sdxの代わりにパスフォーマット/dev/mapper/<WWID>が必要となります。4 つのデバイス（sda、sdb、sdc、および sdd）を持つサーバーでは、以下の設定は 2 つのデバイスのみをブラックリストに指定します。パスの形式 /dev/mapper/<WWID> は、この一覧に記載されていないデバイスで想定されています。
hc_nodes: hosts: host1backend.example.com: blacklist_mpath_devices: - sdb - sdc- gluster_infra_luks_devices (required)
暗号化するデバイスの一覧と、各デバイスに使用する暗号化パスフレーズの一覧。
hc_nodes: hosts: host1backend.example.com: gluster_infra_luks_devices: - devicename: /dev/sdb passphrase: Str0ngPa55#- devicename
-
デバイスの名前（
/dev/sdx形式）。 - passphrase
- 暗号化を設定する際にこのデバイスに使用するパスワード。NBDE(Network-Bound Disk Encryption)を使用したディスク暗号化が設定されると、新しいランダムキーが生成され、セキュリティーが強化されます。
- rootpassphrase（必須）
このホストでオペレーティングシステムの インストール時にデータを暗号化 する際に使用したパスワード。
hc_nodes: hosts: host1backend.example.com: rootpassphrase: h1-Str0ngPa55#- rootdevice（必須）
このホストへのオペレーティングシステムのインストール時に Encrypt my data を選択したときに暗号化されたルートデバイス。
hc_nodes: hosts: host1backend.example.com: rootdevice: /dev/sda2- Networkinterface（必須）
このホストが NBDE 鍵サーバーに到達するために使用するネットワークインターフェース。
hc_nodes: hosts: host1backend.example.com: networkinterface: ens3s0f0- ip_version（必須）
IPv4 ネットワークまたは IPv6 ネットワークを使用するかどうか。有効な値は
IPv4およびIPv6です。デフォルト値はありません。混合ネットワークはサポートされません。hc_nodes: vars: ip_version: IPv4- ip_config_method (必須)
DHCP または静的ネットワークを使用するかどうか。有効な値は
dhcpおよびstaticです。デフォルト値はありません。hc_nodes: vars: ip_config_method: dhcpこのオプションの他の有効な値は
staticです。これには、以下の追加パラメーターが必要で、ホストごとに個別に定義されます。hc_nodes: hosts: host1backend.example.com: ip_config_method: static host_ip_addr: 192.168.1.101 host_ip_prefix: 24 host_net_gateway: 192.168.1.100 host2backend.example.com: ip_config_method: static host_ip_addr: 192.168.1.102 host_ip_prefix: 24 host_net_gateway: 192.168.1.100 host3backend.example.com: ip_config_method: static host_ip_addr: 192.168.1.102 host_ip_prefix: 24 host_net_gateway: 192.168.1.100- gluster_infra_tangservers
http://を含む NBDE キーサーバーまたはサーバーのアドレス。サーバーがデフォルト(80)以外のポートを使用する場合は、URL の最後に:_port_を追加してポートを指定します。hc_nodes: vars: gluster_infra_tangservers: - url: http://key-server1.example.com - url: http://key-server2.example.com:80
B.2. 例: luks_tang_inventory.yml
動的に割り当てられる IP アドレス
hc_nodes:
hosts:
host1-backend.example.com:
blacklist_mpath_devices:
- sda
- sdb
- sdc
gluster_infra_luks_devices:
- devicename: /dev/sdb
passphrase: dev-sdb-encrypt-passphrase
- devicename: /dev/sdc
passphrase: dev-sdc-encrypt-passphrase
rootpassphrase: host1-root-passphrase
rootdevice: /dev/sda2
networkinterface: eth0
host2-backend.example.com:
blacklist_mpath_devices:
- sda
- sdb
- sdc
gluster_infra_luks_devices:
- devicename: /dev/sdb
passphrase: dev-sdb-encrypt-passphrase
- devicename: /dev/sdc
passphrase: dev-sdc-encrypt-passphrase
rootpassphrase: host2-root-passphrase
rootdevice: /dev/sda2
networkinterface: eth0
host3-backend.example.com:
blacklist_mpath_devices:
- sda
- sdb
- sdc
gluster_infra_luks_devices:
- devicename: /dev/sdb
passphrase: dev-sdb-encrypt-passphrase
- devicename: /dev/sdc
passphrase: dev-sdc-encrypt-passphrase
rootpassphrase: host3-root-passphrase
rootdevice: /dev/sda2
networkinterface: eth0
vars:
ip_version: IPv4
ip_config_method: dhcp
gluster_infra_tangservers:
- url: http://key-server1.example.com:80
- url: http://key-server2.example.com:80
静的 IP アドレス
hc_nodes:
hosts:
host1-backend.example.com:
blacklist_mpath_devices:
- sda
- sdb
- sdc
gluster_infra_luks_devices:
- devicename: /dev/sdb
passphrase: dev-sdb-encrypt-passphrase
- devicename: /dev/sdc
passphrase: dev-sdc-encrypt-passphrase
rootpassphrase: host1-root-passphrase
rootdevice: /dev/sda2
networkinterface: eth0
host_ip_addr: host1-static-ip
host_ip_prefix: network-prefix
host_net_gateway: default-network-gateway
host2-backend.example.com:
blacklist_mpath_devices:
- sda
- sdb
- sdc
gluster_infra_luks_devices:
- devicename: /dev/sdb
passphrase: dev-sdb-encrypt-passphrase
- devicename: /dev/sdc
passphrase: dev-sdc-encrypt-passphrase
rootpassphrase: host2-root-passphrase
rootdevice: /dev/sda2
networkinterface: eth0
host_ip_addr: host1-static-ip
host_ip_prefix: network-prefix
host_net_gateway: default-network-gateway
host3-backend.example.com:
blacklist_mpath_devices:
- sda
- sdb
- sdc
gluster_infra_luks_devices:
- devicename: /dev/sdb
passphrase: dev-sdb-encrypt-passphrase
- devicename: /dev/sdc
passphrase: dev-sdc-encrypt-passphrase
rootpassphrase: host3-root-passphrase
rootdevice: /dev/sda2
networkinterface: eth0
host_ip_addr: host1-static-ip
host_ip_prefix: network-prefix
host_net_gateway: default-network-gateway
vars:
ip_version: IPv4
ip_config_method: static
gluster_infra_tangservers:
- url: http://key-server1.example.com:80
- url: http://key-server2.example.com:80
付録C gluster_network_inventory.ymlファイルの概要
C.1. glusterネットワーク作成のための設定パラメータ
vars
- he_fqdn
- Hosted Engine仮想マシンのFQDN
- he_admin_password
- RHV Manager 管理ポータルのパスワード
- datacenter_name
-
RHVのデータセンター名。通常、Red Hat Hyperconverged Infrastructure for Virtualization のデプロイメントでは、3 台のホストがすべて
DefaultデータセンターのDefaultクラスタに追加されます。 - cluster_name
- RHVクラスター名
- boot_protocol
- DHCP または静的ネットワークを使用するかどうか。
- version（オプション）
- IPv4とIPv6のどちらのネットワークを使用するか。v4がデフォルトで、このパラメーターが省略された場合には、v4と仮定されます。もう一つの有効な値はv6です。混合ネットワークはサポートされません。
- mtu_value (オプション)
-
ネットワークの最大送信単位（1回のトランザクションで送信可能な最大のパケットまたはフレームサイズ）を指定します。デフォルト値は
1500です。ジャンボフレームをサポートしているネットワークでは、この値を9000にすると、スループットが大幅に向上します。
cluster_nodes
- host
- Red Hat Virtualization 管理ポータルに記載されている、ホストのパブリックネットワーク FQDN。
- interface
- ストレージやバックエンドネットワークに対応するネットワークインターフェースまたはボンド
C.2. gluster_network_inventory.ymlの例
all:
hosts:
localhost:
vars:
he_fqdn: rhv-manager.example.com
he_admin_password: xxxxxxxxxx
datacenter_name: Default
cluster_name: Default
boot_protocol: dhcp
version: v4
mtu_value: 9000
# For dhcp boot_protocol
cluster_nodes:
- {host: host1-frontend.example.com, interface: eth1}
- {host: host2-frontend.example.com, interface: eth1}
- {host: host3-frontend.example.com, interface: eth1}付録D 用語集
D.1. 仮想化用語
- Administration Portal
- oVirt engine Web ユーザーインターフェースをベースとする Red Hat Virtualization Manager が提供する Web ユーザーインターフェース。これにより、管理者はネットワーク、ストレージドメイン、仮想マシンテンプレートなどのクラスターリソースを管理および監視できます。
- ホスト型エンジン
- RHHI for Virtualization を管理する Red Hat Virtualization Manager のインスタンス。
- Hosted Engine 仮想マシン
- Red Hat Virtualization Manager として機能する仮想マシン。ホスト型 Engine 仮想マシンは、ホスト型 Engine 仮想マシンで実行されている Red Hat Virtualization Manager のインスタンスが管理する仮想化ホストで実行されます。
- Manager ノード
- ホスト型エンジンの仮想マシンで実行するのではなく、Red Hat Virtualization Manager を直接実行する仮想化ホスト。
- Red Hat Enterprise Linux ホスト
- Red Hat Enterprise Linux でインストールした物理マシンと、Red Hat Virtualization ホストと同じ機能を提供する追加パッケージ。このタイプのホストは、RHHI for Virtualization での使用はサポートされません。
- Red Hat Virtualization
- Linux および Microsoft Windows ワークロードのリソース、プロセス、およびアプリケーションを仮想化するためのオペレーティングシステムと管理インターフェース。
- Red Hat Virtualization ホスト
- Red Hat Virtualization でインストールされた物理マシン。Linux および Microsoft Windows ワークロードのリソース、プロセス、およびアプリケーションの仮想化をサポートする物理リソースを提供します。これは、RHHI for Virtualization でサポートされる唯一のタイプのホストです。
- Red Hat Virtualization Manager
- Red Hat Virtualization の管理および監視機能を実行するサーバー
- セルフホストエンジンのノード
- ホスト型エンジン仮想マシンを含む仮想化ホスト。RHHI for Virtualization デプロイメントのすべてのホストはセルフホストエンジンノードを持つことができますが、一度にセルフホストエンジンノードが 1 つしかありません。
- ストレージドメイン
- イメージ、テンプレート、スナップショット、およびメタデータの名前付きコレクション。ストレージドメインは、ブロックデバイスまたはファイルシステムから構成できます。ストレージドメインは、データセンターにアタッチされ、データセンター内のホストにはイメージ、テンプレートなどのコレクションにアクセスできます。
- virtualization host
- クライアントアクセスのために物理リソース、プロセス、およびアプリケーションを仮想化する機能がある物理マシン。
- VM ポータル
- Red Hat Virtualization Manager が提供する Web ユーザーインターフェースこれにより、ユーザーは仮想マシンの管理および監視を行うことができます。
D.2. ストレージ用語
- ブリック
- 信頼できるストレージプール内のサーバーにエクスポートされるディレクトリー。
- キャッシュ論理ボリューム
- 大規模で低速な論理ボリュームのパフォーマンスを改善するのに使用される小規模で高速な論理ボリューム。
- geo-replication
- ソースの Gluster ボリュームからターゲットボリュームへのデータの非同期レプリケーション。Geo レプリケーションは、ローカル領域ネットワークおよびインターネット全体で機能します。ターゲットボリュームは、異なる信頼できるストレージプールの Gluster ボリューム、または別のタイプのストレージになります。
- Gluster ボリューム
- ワークロードの要件に応じてデータを分散、複製、または分散するように設定できるブリックの論理グループ。
- 論理ボリューム管理(LVM)
- 物理ディスクを大きな仮想パーティションに統合する方法。物理ボリュームはボリュームグループに配置され、必要に応じて論理ボリュームに分割できるストレージのプールを形成します。
- Red Hat Gluster Storage
- Red Hat Enterprise Linux をベースとするオペレーティングシステムは、分散型のソフトウェア定義のストレージをサポートする追加パッケージが含まれています。
- ソースボリューム
- データが geo レプリケーション時にコピーされる Gluster ボリューム。
- ストレージホスト
- クライアントアクセス用にストレージを提供する物理マシン。
- ターゲットボリューム
- geo レプリケーション時にデータがコピーされる Gluster ボリュームまたは他のストレージボリューム。
- シンプロビジョニング
- 必要な領域のみが作成時に割り当てられるように、プロビジョニングストレージは、時間の経過に応じてさらに領域を動的に割り当てられるようにします。
- シックプロビジョニング
- すぐに領域が必要かどうかに関係なく、すべての領域が作成時に割り当てられるようにプロビジョニングストレージをプロビジョニングします。
- 信頼できるストレージプール
- 信頼されるピアとして相互に認識する Red Hat Gluster Storage サーバーのグループ。
D.3. ハイパーコンバージドインフラストラクチャーの用語
- Red Hat Hyperconverged Infrastructure(RHHI)for Virtualization
- RHHI for Virtualization は、仮想コンピュートおよび仮想ストレージリソースの両方を提供する単一の製品です。Red Hat Virtualization および Red Hat Gluster Storage は、接続設定にインストールされます。ここでは、両方の製品のサービスがクラスター内の各物理マシンで利用できます。
- ハイパーコンバージドホスト
- 仮想化プロセスとアプリケーションが同じホスト上で実行する物理ストレージを提供する物理マシン。RHHI for Virtualization と共にインストールされるすべてのホストは、ハイパーコンバージドホストです。
- Web コンソール
- RHHI for Virtualization のデプロイ、管理、監視用の Web ユーザーインターフェース。Web コンソールは、Red Hat Virtualization Manager の Web Console サービスおよびプラグインによって提供されます。
