Deploying Red Hat Hyperconverged Infrastructure for Virtualization

Red Hat Hyperconverged Infrastructure for Virtualization 1.6

Red Hat Hyperconverged Infrastructure for Virtualization のデプロイ手順

概要

本書は、Red Hat Gluster Storage 3.4 と Red Hat Virtualization 4.3 を使用して、3 つの物理マシンに Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization)をデプロイする方法について説明します。これにより、リモートオフィスのオフィス(ROBO)環境で使用する個別のクラスターが作成されます。リモートオフィスは、通常のベースにある中央データセンターにデータを同期しますが、中央のデータセンターへの接続が失われた場合には、完全に機能し続けます。

パート I. プラン

第1章 アーキテクチャー

Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization)は、1 つのデプロイメントでコンピュート、ストレージ、ネットワーク、管理機能を組み合わせたものです。

RHHI for Virtualization は 3 つの物理マシン全体にデプロイされ、Red Hat Gluster Storage 3.4 および Red Hat Virtualization 4.3 を使用して個別のクラスターまたは Pod を作成します。

このデプロイメントのドロントのユースケースは、リモートオフィスのオフィス(ROBO)環境にあり、リモートオフィスが、通常のベースにある中央データセンターにデータを同期しますが、中央のデータセンターへの接続は不要です。

以下の図は、単一クラスターの基本アーキテクチャーを示しています。

A diagram of the architecture of Red Hat Hyperconverged Infrastructure for Virtualization deployed across three physical machines

1.1. VDO の理解

Red Hat Hyperconverged Infrastructure for Virtualization 1.6 では、Virtual Data Optimizer(VDO)レイヤーを設定して、ストレージのデータの削減および重複排除を提供できます。

VDO は、デプロイメント時に新規インストールで有効化された場合に限りサポートされており、以前のバージョンの RHHI for Virtualization からアップグレードしたデプロイメントで有効にできません。

VDO は、データに必要な領域を減らすために、以下のタイプのデータ削減を行います。

重複排除
ゼロおよび重複データブロックを削除します。VDO は、UDS(Universal Deduplication Service)カーネルモジュールを使用して重複したデータを検出します。重複したデータを書き込む代わりに、VDO は元のブロックへの参照として記録します。論理ブロックアドレスは、VDO により物理ブロックアドレスにマッピングされます。
圧縮
ディスクに書き込む前に、重複しないブロックを固定長(4 KB)ブロックにパックすることで、データのサイズを縮小します。これにより、ストレージからデータの読み取りのパフォーマンスを迅速化するのに役立ちます。

ベストレートでは、元のサイズの 15% にデータを減らすことができます。

データを削減することで追加の処理コストが発生するため、圧縮と重複排除を有効にすると書き込みパフォーマンスが低下することになります。したがって、VDO は、パフォーマンスの影響を受けるワークロードには推奨されません。Red Hat では、実稼働環境に VDO をデプロイする前に、VDO を有効にして必要なパフォーマンスがテスト、検証することを強く推奨します。

第2章 サポート要件

本セクションを参照して、お使いのデプロイメントが Red Hat によるサポートの要件を満たしていることを確認してください。

2.1. オペレーティングシステム

Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization)は、他のすべての設定のベースとして Red Hat Virtualization Host 4.3 を使用します。Red Hat Enterprise Linux ホストはサポートされていません。

以下の表は、サポートされている RHHI for Virtualization デプロイメントに使用する各製品でサポートされているバージョンを示しています。

表2.1 バージョンの互換性

RHHI versionRHGS バージョンRHV バージョン

1.0

3.2

4.1.0 から 4.1.7

1.1

3.3.1

4.1.8 から 4.2.0

1.5

3.4 Batch 1 更新

4.2.7

1.5.1

3.4 Batch 2 更新

4.2.8

1.6

3.4 Batch 4 更新

4.3 から current

Red Hat Virtualization の要件についての詳細は、『Red Hat Virtualization の プランニングおよび前提条件ガイド』 の「要件」を参照してください。

2.2. 物理マシン

Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization)には 少なくとも 3 つの物理マシン が必要です。6、9、または 12 の物理マシンへのスケーリングもサポートされています。詳細は、「 スケーリング 」を参照してください。

それぞれの物理マシンには、以下の機能が必要です。

  • データおよび管理トラフィックを分離するため、物理マシンごとに少なくとも 2 つの NIC（ネットワークインターフェースコントローラー）を分離します（詳細は、「ネットワーク」 を参照してください）。

  • 小規模なデプロイメントの場合：

    • 12 以上のコア
    • 64GB 以上の RAM
    • 最大 48TB ストレージ

  • 中規模デプロイメントの場合：

    • 12 以上のコア
    • 128GB 以上の RAM
    • 最大 64TB ストレージ

  • 大規模なデプロイメントの場合：

    • 16 以上のコア
    • 256GB 以上の RAM
    • 最大 80TB ストレージ

2.3. 仮想マシン

ハイパーコンバージドデプロイメントで実行できる仮想マシンの数は、それらの仮想マシンの動作と、その中の負荷を大幅に変動させます。ワークロードの CPU、メモリー、スループットの要件をテストし、ハイパーコンバージド環境をプロビジョニングします。

2.4. セルフホストエンジン用仮想マシン

セルフホストエンジン用仮想マシンには、少なくとも以下の項目が必要です。

  • 1 デュアルコア CPU（1 クアッドコアまたは複数のデュアルコア CPU が推奨されます）
  • 他のプロセスと共有されていない 4GB RAM（16GB 推奨）
  • 25GB のローカル、書き込み可能なディスク領域（50GB 推奨）
  • 帯域幅が 1 つ以上ある NIC 1 つ

詳細は、『Red Hat Virtualization 4.3 の プランニングおよび前提条件ガイド』 の「 要件 」を参照してください。

2.5. ネットワーク

DNS が転送および逆に解決される完全修飾ドメイン名は、すべてのハイパーコンバージドホストおよび Red Hat Virtualization Manager を提供する Hosted Engine 仮想マシンに必要です。

IPv6 は、IPv6 専用環境（DNS およびゲートウェイアドレスを含む）ではテクノロジープレビューとして提供されます。IPv4 アドレスと IPv6 アドレスの両方の環境はサポートされません。

重要

テクノロジープレビュー機能は、カスタマーポータルの「 テクノロジプレビュー機能のサポート範囲」で詳細に説明されているように制限されたサポート範囲 で提供されます。

クラスター内のクライアントストレージトラフィックおよび管理トラフィックは、別個のネットワークを使用する必要があります。これは、フロントエンド管理ネットワーク およびバックエンドストレージネットワークです 。

各ノードに、各ネットワーク用に 2 つのイーサネットポートが必要です。これにより、最適なパフォーマンスが確保されます。高可用性を確保するには、各ネットワークを別のネットワークスイッチに配置します。フォールトトレランスを改善するには、各スイッチに個別の電源名を指定します。

フロントエンド管理ネットワーク
  • Red Hat Virtualization および仮想マシンによって使用されます。
  • イーサネット接続は、1 つ以上の 1Gbps が必要です。
  • このネットワークに割り当てられる IP アドレスは、相互に同じサブネットおよびバックエンドストレージネットワークとは異なるサブネット上にある必要があります。
  • このネットワークの IP アドレスは、管理者が選択できます。
バックエンドストレージネットワーク
  • ハイパーコンバージドノード間のストレージおよび移行トラフィックで使用されます。
  • イーサネット接続として少なくとも 1 つの 10Gbps が必要です。
  • ピア間の最大 5 ミリ秒が必要です。

Intelligent Platform Management Interface(IPMI)を使用するネットワークフェンシングデバイスには、別のネットワークが必要です。

Hosted Engine 仮想マシンに DHCP ネットワーク設定を使用する場合は、Red Hat Hyperconverged Infrastructure for Virtualization を設定する前に DHCP サーバーを設定する必要があります。

geo レプリケーションを使用してデータのコピーを保存して障害復旧を設定する場合 は、以下を行います。

  • 信頼できるタイムソースを設定します。

  • IPv6 アドレスは使用しないでください。

    警告

    Bug 1688239 は 現在、IPv6 ベースのジオレプリケーションの動作を阻止しています。geo レプリケーションを使用して障害復旧機能が必要な場合は、IPv6 アドレスを使用しないでください。

デプロイメントプロセスを開始する前に、 以下の詳細を確認します。

  • ハイパーコンバージドホストへのゲートウェイの IP アドレスこのアドレスは ping 要求に応答する必要があります。
  • フロントエンド管理ネットワークの IP アドレス
  • セルフホストエンジン用仮想マシンの完全修飾ドメイン名(FQDN)。
  • セルフホストエンジンの静的 FQDN および IP アドレスに解決する MAC アドレス。

2.6. ストレージ

ハイパーコンバージドホストは、設定、ログ、およびカーネルダンプを保存し、そのストレージをスワップ領域として使用します。本セクションでは、ハイパーコンバージドホストの最小ディレクトリーサイズを説明します。Red Hat は、これらの最小値よりも多くのストレージ容量を使用するデフォルトの割り当てを使用することを推奨します。

  • / (root)- 6GB
  • /home - 1GB
  • /tmp - 1GB
  • /boot - 1GB
  • /var - 15GB
  • /var/crash - 10GB

  • /var/log - 8GB

    重要

    Red Hat は、Red Hat Gluster Storage の追加のログ要件に十分な領域を提供するために、/var/log のサイズを 15GB 以上に増やすことを推奨します。

    Web コンソールを使用して論理ボリューム の拡大手順に従って、オペレーティングシステムのインストール後にこのパーティションのサイズを大きくします。

  • /var/log/audit - 2GB
  • swap - 1GB（詳細は 推奨されるスワップサイズ を参照）
  • Anaconda は、将来のメタデータ拡張用に、ボリュームグループ内のシンプールサイズの 20% を確保します。これは、通常の使用条件においてデフォルト設定で領域が不足するのを防ぐためです。インストール中のシンプールのオーバープロビジョニングもサポートされていません。
  • 最少の合計： 55GB

2.6.1. ディスク

Red Hat は、最高のパフォーマンスを得るために Solid State Disks(SSD)を推奨します。ハードドライブディスク(HDD)を使用する場合は、LVM キャッシュボリュームとして、より高速 SSD も設定する必要があります。

Red Hat Virtualization では 512 バイトエミュレーション(512e)をサポートする必要があるため、4k ネイティブデバイスは Red Hat Hyperconverged Infrastructure for Virtualization ではサポートされません。

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 つ以上のホットスペアドライブを提供することを推奨しています。

2.6.3. JBOD

Red Hat Hyperconverged Infrastructure for Virtualization 1.6 の時点で、JBOD 設定は完全にサポートされているため、アーキテクチャーのレビューは必要ありません。

2.6.4. 論理ボリューム

エンジン Gluster ボリュームを構成する論理ボリュームは、シックのプロビジョニングが必要です。これにより、ホスト型エンジンは、領域の状態外、破壊的なボリューム設定の変更、I/O のオーバーヘッドおよび移行アクティビティーから保護されます。

vmstore およびオプションの データ Gluster ボリュームを 構成 する論理ボリュームは、シンプロビジョニングする必要があります。これにより、基礎となるボリューム設定における柔軟性が向上します。シンプロビジョニングしたボリュームが Hard Drive Disks(HDD)の場合は、パフォーマンスを向上させるために、lvmcache(Solid State Disk)として小さい方が高速で Solid State Disk(SSD)を設定します。

2.6.5. Red Hat Gluster Storage ボリューム

Red Hat Hyperconverged Infrastructure for Virtualization は、3-4 Red Hat Gluster Storage ボリュームを持つことが予想されます。

  • セルフホストエンジン用の 1 エンジン ボリューム
  • 仮想マシンオペレーティングシステムのディスクイメージ用の 1 vmstore ボリューム
  • 1 オプションの他の仮想マシンディスクイメージ用のオプションの データ ボリューム
  • 1 shared_storage volume for geo-replication metadata

バックアップストレージ要件を最小限に抑えるには 、 別の vmstore と data volumes が推奨されます。仮想マシンデータをオペレーティングシステムイメージから保存することは、VMstore ボリューム 上のオペレーティングシステムイメージがより簡単に再ビルドされるため、ストレージ ボリューム のみが事前の場合にバックアップされる必要があります。

Red Hat Hyperconverged Infrastructure for Virtualization のデプロイメントには、最大 1 つのジオレプリケーションのボリュームを含めることができます。

2.6.6. ボリュームタイプ

Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization)は、デプロイ時に以下のボリューム種別のみをサポートします。

  • 複製されたボリューム （3 つのノード間で 3 つのブリックにある同じデータのコピー）

    これらのボリュームは、デプロイメント後に分散複製されたボリュームに拡張できます。

  • 複製された複製ボリューム （2 つのブリックで同じデータの完全なコピー 2 つ、および 3 つのノードにメタデータが含まれる 1 Arbiter ブリック）の完全なコピー。

    これらのボリュームは、デプロイメント後に、調整された分散複製されたボリュームに拡張できます。

  • 分散ボリューム （1 データのコピー、他のブリックへのレプリケーションなし）

Arbiter ブリックにはファイル名、構造、およびメタデータのみが格納されることに注意してください。つまり、3 方向の複製されたボリュームには、同じレベルの一貫性を実現するために、3 方向の複製ボリュームが最低 75% のストレージ領域を必要とします。ただし、arbiter ブリックはメタデータしか格納されないため、3 方向の複製ボリュームは双方向で複製されたボリュームの可用性のみを提供します。

複製された複製ボリュームの再生に関する詳細は、『Red Hat Gluster Storage Administration Guide』 の「 Creating multiple arbited replicated volumes across less nodes 」を参照してください。

2.7. VDO(Virtual Data Optimizer)

VDO(Virtual Data Optimizer)レイヤーは、Red Hat Hyperconverged Infrastructure for Virtualization 1.6 としてサポートされます。

VDO サポートは新しいデプロイメントにのみ制限され、既存のデプロイメントに VDO レイヤーの追加を試行しないでください。

2.8. スケーリング

Red Hat Hyperconverged Infrastructure for Virtualization の初期デプロイメントは、1 ノードまたは 3 ノードです。

1 ノードのデプロイメントはスケーリングできません。

3 つのノードのデプロイメントは、以下のいずれかの方法で 6、9、または 12 ノードにスケーリングできます。

  1. 新しいハイパーコンバージドノードをクラスターに追加し、3 つのセットで、最大 12 ハイパーコンバージドノードの 1 つまでです。
  2. 新規または既存のノードで新しいディスクを使用して、新しい Gluster ボリュームを作成します。
  3. 既存の Gluster ボリュームを展開し、新規または既存ノードで新しいディスクを使用して 6、9、または 12 ノードの間です。

一度に 3 つ以上のノードにまたがるボリュームを作成することはできません。まず 3 ノードボリュームを作成してから、必要に応じて複数のノードに拡張する必要があります。

2.9. 既存の 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.10. 障害復旧

Red Hat は、障害復旧ソリューションを設定することを強く推奨します。障害復旧ソリューションとしてジオレプリケーションを設定する方法は、「 Maintaining Red Hat Hyperconverged Infrastructure for Virtualization : https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.6/html/maintaining_red_hat_hyperconverged_infrastructure_for_virtualization/config-backup-recovery」を参照してください。

警告

Bug 1688239 は 現在、IPv6 ベースのジオレプリケーションの動作を阻止しています。geo レプリケーションを使用して障害復旧機能が必要な場合は、IPv6 アドレスを使用しないでください。

2.10.1. ジオレプリケーションの前提条件

ジオレプリケーションを設定する場合は、以下の要件および制限に注意してください。

ジオレプリケーションの 1 つのボリュームのみ
Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization)は、ジオレプリケーションの 1 つのボリュームのみをサポートします。Red Hat は、仮想マシンのデータを格納するボリュームのバックアップを推奨します。これには通常最も有用なデータが含まれているためです。
2 つの異なるマネージャーが必要です
ジオレプリケーションの移行ボリュームおよび宛先ボリュームは、Red Hat Virtualization Manager の異なるインスタンスで管理する必要があります。

2.10.2. フェイルオーバーとフェルバック設定の前提条件

バージョンが環境間で一致している必要があります。
プライマリー環境とセカンダリー環境は、同一データセンターの互換バージョン、クラスターの互換バージョン、および PostgreSQL のバージョンが同じである Red Hat Virtualization Manager のバージョンが同じであるようにしてください。
セルフホストエンジン用ストレージドメインに仮想マシンディスクがない
セルフホストエンジン用仮想マシンが使用するストレージドメインはフェイルオーバーしないため、このストレージドメインの仮想マシンディスクは失われます。
別のマスターノードから Ansible Playbook を手動で実行
Ansible Playbook は、Ansible マスターノードとして機能する別のマシンから手動で生成し、実行します。

2.11. 単一ノードデプロイメントの追加の要件

Red Hat Hyperconverged Infrastructure for Virtualization は、以下の追加および例外を除き、すべての サポート対象要件 が満たされている単一のノード上でのデプロイメントでサポートされます。

単一ノードのデプロイメントには、以下を実行して物理マシンが必要です。

  • 1 ネットワークインターフェースコントローラー
  • 12 以上のコア
  • 64GB 以上の RAM
  • 最大 48TB ストレージ

単一ノードのデプロイメントはスケーリングできず、高可用性はありません。

第3章 推奨事項

このセクションで説明する設定は必須ではありませんが、デプロイメントの安定性やパフォーマンスが向上する可能性があります。

3.1. 推奨情報

  • デプロイメントが完了するまですぐに完全バックアップを作成し、バックアップを別の場所に保存します。その後、通常のバックアップを作成します。詳細は、「 バックアップおよびリカバリーオプションの設定」を 参照してください。
  • デプロイメントが、同じ 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 のどちらに登録します。
  • アクティビティー追跡を行うために、多くのユーザーがデフォルトの管理者アカウントを使用できる代わりに、個別の管理者アカウントを作成します。
  • ホストへのアクセスを制限し、個別のログインを作成します。使用するすべてのユーザーが単一の root ログインを作成しません。『 Red Hat Enterprise Linux 7 システム 管理者のガイド』の「ユーザーとグループ の管理」を参照してください。
  • ホストに信頼できないユーザーを作成しないでください。
  • 不要なセキュリティーリスクを追加するその他のコンポーネントや、アナライザー、コンパイラー、またはその他のコンポーネントをインストールしないでください。

3.3. ホストの推奨事項

  • 同じクラスターでホストを標準化します。これには、一貫性のあるハードウェアモデルとファームウェアバージョンが含まれます。同じクラスター内で異なるサーバーハードウェアを混在させると、ホストからホストにパフォーマンスの一貫性が失われることがあります。
  • デプロイ時にフェンスデバイスを設定します。高可用性には、フェンスデバイスが必要です。
  • フェンシングトラフィックには、別のハードウェアスイッチを使用します。監視とフェンシングが同じスイッチ経由になると、そのスイッチは高可用性のために単一障害点になります。

3.4. ネットワークに関する推奨事項

  • 特に実稼働ホスト上でのネットワークインターフェースをボンディングします。ボンディングにより、サービス全体やネットワーク帯域幅が向上します。『 Administration Guide』の 「Network Bonding 」を参照してください。
  • パフォーマンスを最適化し、トラブルシューティングを簡素化するには、VLAN を使用して異なるトラフィック種別を分離し、GbE または 40 GbE ネットワークを最適に使用できるようにします。
  • 基礎となるスイッチがジャンボフレームをサポートする場合は、下層のスイッチがサポートする最大サイズ（例： 9000）に MTU を設定します。この設定により、ほとんどのアプリケーションでは帯域幅が向上し、CPU 使用率が低下する最適なスループットが有効になります。デフォルトの MTU は、基礎となるスイッチでサポートされる最小サイズによって決定されます。LLDP を有効にした場合には、ホスト ネットワーク設定ウィンドウで NIC のツールヒントで各ホストのピアで MTU をサポートしていることが 分かります。
  • 1 GbE ネットワークは管理トラフィックにのみ使用する必要があります。仮想マシンおよびイーサネットベースのストレージには 10 GbE または 40 GbE を使用します。
  • ストレージが使用するために追加の物理インターフェースがホストに追加される場合には、VLAN が物理インターフェースに直接割り当てられるように、仮想マシンネットワーク のチェックを解除します。

3.4.1. ホストネットワーク設定の推奨プラクティス

ネットワーク環境が複雑な場合には、ホストを Red Hat Virtualization Manager に追加する前に、ホストネットワークを手動で設定しなければならない場合があります。

Red Hat では、ホストネットワーク設定の以下のプラクティスを推奨します。

  • Web コンソールを使用してネットワークを設定します。別の方法では、nmtui または nmcli を使用できます。
  • セルフホストエンジンのデプロイメントまたは Manager へのホスト追加にネットワークが必要ない場合は、ホストを Manager に追加した後に、管理ポータルでネットワークを設定します。「データセンターまたはクラスターでの新規論理ネットワークの作成」を参照してください。

  • 以下の命名規則を使用します。

    • 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）
  • ネットワークボンディング を使用する。ネットワークチーミングはサポートされていません。

  • 推奨されるボンディングモードを使用する。

    • 仮想マシンが ovirtmgmt ネットワークを使用しない場合には、ネットワークではサポートされるいずれかのボンディングモードが使用されます。
    • 仮想マシンが ovirtmgmt ネットワークを使用する場合には、「 Which bonding mode 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 を使用してください。詳細は、『オーバークラウドの高度な カスタマイズ』の「ボンディングモード 」を参照してください。

  • 以下の例に示すように、物理 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 」を参照してください。
重要

静的 IPv6 アドレスを使用する管理ブリッジを作成する場合は、ホストを追加する前に、インターフェース設定でネットワークマネージャー制御を無効にします。詳細は、https://access.redhat.com/solutions/3981311 を参照してください。

3.5. セルフホストエンジンに関する推奨事項

  • 環境がこれを実行するのに十分な大きさであれば、Red Hat Virtualization Manager およびその他のインフラストラクチャーレベルのサービス用に、別のデータセンターおよびクラスターを作成します。Manager 用仮想マシンは通常のクラスターのホストで実行できますが、実稼働仮想マシンから分離は、バックアップのスケジュール、パフォーマンス、可用性、およびセキュリティーが容易になります。
  • Manager 用仮想マシン専用のストレージドメインは、セルフホストエンジンのデプロイメント中に作成されます。他の仮想マシンには、このストレージドメインを使用しないでください。
  • Manager 用仮想マシンがそれら間で安全に移行できるように、すべてのセルフホストエンジンノードには等しい CPU ファミリーが必要です。さまざまなファミリーを利用したい場合は、最も小さいインストールを開始します。
  • Manager 用仮想マシンをシャットダウンするか、移行する必要がある場合、Manager 用仮想マシンの再起動または移行のためにセルフホストエンジンノードに十分なメモリーが必要です。

パート II. デプロイ

第4章 デプロイメントワークフロー

Red Hat Hyperconverged Infrastructure for Virtualization(RHHI for Virtualization)をデプロイするワークフローは以下のとおりです。

  1. 計画されているデプロイメントがサポート要件を満たしていることを確認します： 2章サポート要件
  2. ハイパーコンバージドホストとして機能する物理マシンをインストールします。「ホストの物理マシンのインストール」
  3. パスワードなしで鍵ベースの SSH 認証を設定し、ホストの自動設定を有効にします( 5章パスワードなしの公開鍵ベースの SSH 認証の設定 )。
  4. Web コンソールを使って物理ホストに Red Hat Gluster Storage を設定します。6章Web コンソールを使用したホスト型エンジンのための Red Hat Gluster Storage の設定
  5. Web コンソール 7章Web コンソールを使用したホスト型エンジンのデプロイ を使用して、Hosted Engine をデプロイします。
  6. 管理ポータルを使用して Red Hat Gluster Storage ノードを設定します。管理ポータル にログインして設定を完了 します。

4.1. ホストの物理マシンのインストール

物理マシンには、ハイパーコンバージドホストとして使用するために、オペレーティングシステムと適切なソフトウェアリポジトリーへのアクセスが必要です。

  1. 各物理マシンに Red Hat Virtualization Host をインストールします。
  2. 各物理マシンで Red Hat Virtualization Host ソフトウェアリポジトリーを有効にします。

4.1.1. Red Hat Virtualization Host のインストール

Red Hat Virtualization Host は、Red Hat Virtualization または Red Hat Hyperconverged Infrastructure のハイパーバイザーとして機能する物理マシンの設定用に設計された最小限のオペレーティングシステムです。

前提条件

  • 物理マシンが物理マシンで概説されている要件を満たしていることを 確認します。

手順

  1. カスタマーポータルから Red Hat Virtualization Host ISO イメージをダウンロードします。

    1. カスタマーポータル https://access.redhat.com にログインします。
    2. メニューバーの Downloads をクリックします。
    3. Red Hat Virtualization をクリックします。スクロールし、Download Latest をクリックして製品のダウンロードページにアクセスします。
    4. RHV 4.3 の Hypervisor イメージ に移動し、今すぐダウンロード をクリックします。
    5. 起動可能なメディアデバイスを作成します。詳細は、『 Red Hat Enterprise Linux インストールガイド』 の「メディア 」を参照してください。
  2. Red Hat Virtualization Host をインストールするマシンを起動し、準備したインストールメディアから起動します。

  3. 起動メニューから Install RHVH 4.3 を選択して、Enter を押します。

    注記

    Tab キーを押してカーネルパラメーターを編集することもできます。カーネルパラメーターはスペースで区切る必要があります。また、Enter キーを押して、指定したカーネルパラメーターを使用してシステムを起動することができます。Esc キーを押してカーネルパラメーターへの変更を消去し、起動メニューに戻ります。

  4. 言語を選択し、続行 をクリックします。

  5. 日付と時刻 の画面からタイムゾーンを選択し、完了 をクリックします。

    重要

    Red Hat は、すべてのホストで協定世界時(UTC)を使用することを推奨します。これは、データ収集と接続が、日の節約時間など、ローカルタイムのバリエーションによる影響を受けないようにするのに役立ちます。

  6. キーボード 画面からキーボードレイアウトを選択し、完了 をクリックします。

  7. インストール 先画面でインストール先 を指定します。

    重要
    • Red Hat では、自動構成のパーティションオプションを使用すること を強く推奨します。
    • すべてのディスクはデフォルトで選択されるため、インストール先として使用しないディスクの選択を解除します。
    • 保存データの暗号化はサポートされません。暗号化を有効にしないでください。

    • Red Hat は、Red Hat Gluster Storage の追加のログ要件に十分な領域を提供するために、/var/log のサイズを 15GB 以上に増やすことを推奨します。

      Web コンソールを使用して論理ボリューム の拡大手順に従って、オペレーティングシステムのインストール後にこのパーティションのサイズを大きくします。

    完了 をクリックします。

  8. ネットワークとホスト名画面で、イーサネットネットワークを選択し ます。

    1. Configure…​ → General をクリックし、Automatically connect to this network when it is available チェックボックスを選択します。
  9. オプションで 言語サポート、セキュリティーポリシー、および Kdump を設定します。インストールの 概要画面の各セクションの詳細は、『 Red Hat Enterprise Linux 7 インストールガイド』 の「 Anaconda を使用 したインストール 」を参照してください。
  10. インストールの開始 をクリックします。

  11. Red Hat Virtualization Host のインストール中に root パスワードを設定して、必要に応じて追加のユーザーを作成します。

    警告

    ローカルのセキュリティー脆弱性が攻撃される可能性があるので、Red Hat Virtualization Host で信頼できないユーザーを作成することを強く推奨します。

  12. 再起動 をクリックしてインストールを完了します。

    注記

    Red Hat Virtualization Host の再起動時に、nodectl check はホストのヘルスチェックを実行し、コマンドラインへのログイン時に結果を表示します。メッセージ node status: OK または node status: DEGRADED はヘルスステータスを示します。nodectl check を実行して詳細情報を取得します。サービスはデフォルトで有効になっています。

4.1.2. ソフトウェアリポジトリーの有効化

  1. Web コンソールにログインします。

    https://server1.example.com:9090/ など、管理 FQDN およびポート 9090 を使用します。

  2. サブスクリプション に移動し、システムの 登録を クリックしてカスタマーポータルのユーザー名とパスワードを入力します。

    Red Hat Virtualization Host のサブスクリプションが自動的にシステムにアタッチされます。

  3. 端末 をクリックします。

  4. Red Hat Virtualization Host 7 リポジトリーを有効にして、Red Hat Virtualization Host に対する後続の更新を可能にします。 

    # subscription-manager repos --enable=rhel-7-server-rhvh-4-rpms

第5章 パスワードなしの公開鍵ベースの SSH 認証の設定

最初のハイパーコンバージドホストの root ユーザーのパスワードなしで公開鍵ベースの SSH 認証を設定する（それ 自体を含む）。これは、すべてのストレージおよび管理インターフェースで、IP アドレスと FQDN の両方に対して行います。

5.1. 最初のホストに既知のホストを追加

ホストで認識していないシステムからホストにログインする場合には、そのシステムを既知のホストとして追加するよう要求されます。

  1. 最初のハイパーコンバージドホストに root ユーザーとしてログインします。

  2. 最初のホストを含む、クラスター内のホストごとに以下の手順を実行します。

    1. SSH を使用して、root ユーザーとしてホストにログインします。 

      [root@server1]# ssh root@server1.example.com

    2. yes を入力して、接続を続行します。 

      [root@server1]# ssh root@server2.example.com
The authenticity of host 'server2.example.com (192.51.100.28)' can't be established.
ECDSA key fingerprint is SHA256:Td8KqgVIPXdTIasdfa2xRwn3/asdBasdpnaGM.
Are you sure you want to continue connecting (yes/no)?

      これにより、最初のホストのホストキーがターゲットホストの known_hosts ファイルに自動的に追加されます。 

      Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.51.100.28' (ECDSA) to the list of known hosts.

    3. ターゲットホストの root ユーザーのパスワードを入力して、ログインプロセスを完了します。 

      root@server2.example.com's password: ***************
Last login: Mon May 27 10:04:49 2019
[root@server2]#

    4. ホストからログアウトします。 

      [root@server2]# exit
[root@server1]#
      注記

      最初のホストからそれ自体に SSH セッションからログアウトした場合、コマンドラインプロンプトのユーザーとサーバーは同じままとなり、変更するセッションのみになります。 

      [root@server1]# exit
[root@server1]#

5.2. パスワードなしの SSH 鍵ペアの生成

公開鍵と秘密鍵のペアを生成すると、鍵ベースの SSH 認証を使用できます。パスワードを使用しないキーペアを生成することで、Ansible を使用してデプロイメントや設定プロセスの自動化が簡単になります。

手順

  1. 最初のハイパーコンバージドホストに root ユーザーとしてログインします。

  2. パスワードを使用しない SSH キーを生成します。

    1. キー生成プロセスを開始します。 

      # ssh-keygen -t rsa
Generating public/private rsa key pair.

    2. キーの場所を入力します。

      括弧で示したデフォルトの場所は、他の入力が指定されていない場合に使用されます。 

      Enter file in which to save the key (/home/username/.ssh/id_rsa): <location>/<keyname>

    3. 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 この出力はプライベートキーです。秘密鍵は共有しないでください。秘密鍵を所有することで、他者は公開鍵を持つシステムで権限を借用できます。

5.3. SSH 鍵のコピー

秘密鍵を使用してホストにアクセスするには、そのホストには公開鍵のコピーが必要です。

前提条件

  • 公開鍵と秘密鍵を生成する。
  • ホストの root ユーザーから、IP アドレスと FQDN の両方を使用した、同じホスト上のすべてのストレージおよび管理インターフェースへの SSH アクセス。

手順

  1. 最初のホストに root ユーザーとしてログインします。

  2. アクセスするホストに公開鍵をコピーします。 

    # ssh-copy-id -i <location>/<keyname>.pub <user>@<hostname>

    プロンプトが表示されたら、<user>@<hostname> のパスワードを入力します。

    警告

    .pub で終わるファイルを使用するようにしてください。秘密鍵は共有しないでください。秘密鍵を所有することで、他者は公開鍵を持つシステムで権限を借用できます。

第6章 Web コンソールを使用したホスト型エンジンのための Red Hat Gluster Storage の設定

重要

このデプロイメントプロセスの一部として指定するディスクに、パーティションまたはラベルがないことを確認してください。

  1. Web コンソールにログインします。

    https://node1.example.com:9090/ などの最初のハイパーコンバージドホストの Web コンソール管理インターフェースを参照し、「ホストの物理マシンのインストール」 で作成 し た認証情報を使用してログインします。

  2. デプロイメントウィザードの開始

    1. Virtualization → Hosted Engine をクリックし、Hyperconverged の下にある Start をクリックします。

      Hosted Engine Setup screen with Start buttons underneath the Hosted Engine and Hyperconverged options

      Gluster 設定 画面が開きます。

    2. Gluster ウィザードの実行 ボタンをクリックします。

      Selecting the type of hyperconverged deployment in the Web Console

      Gluster デプロイメントウィンドウが 3 ノードモードで開きます。

  3. ハイパーコンバージドホストを指定します。

    3 つのハイパーコンバージドホストのストレージネットワーク上のバックエンドの追加ホストを指定します。デプロイメントタスクと Hosted Engine を実行するホストであるため、キーペアを使用して SSH を実行できるハイパーコンバージドホストを最初に一覧表示する必要があります。

    注記

    調整された複製ボリュームを作成する予定の場合には、この画面で arbiter ブリックを Host3 として指定するようにしてください。

    The Hosts tab of the Gluster Deployment window with example IP addresses in the Host Address fields

    Next をクリックします。

  4. 追加のホストを指定します

    複数ノードのデプロイメントの場合は、他の 2 つのハイパーコンバージドホストのフロントエンドの追加ホストまたは IP アドレスを追加し、デプロイメントが完了したら Red Hat Virtualization Manager に自動的に追加できるようにします。

    The Additional Hosts tab of the Gluster Deployment window with example fully qualified domain names entered
    重要

  5. ボリュームの指定

    作成するボリュームを指定します。

    The Volumes tab of the Gluster Deployment window with the default values shown
    名前
    作成するボリュームの名前を指定します。
    ボリュームタイプ
    Replicate のボリューム種別を指定します。本リリースでは、レプリケートされたボリュームのみがサポートされます。
    Arbiter
    Arbiter ブリックでボリュームを作成するかどうかを指定します。このボックスにチェックマークを入れた場合、3 番目のディスクはメタデータのみを保存します。
    ブリック Dirs
    このボリュームのブリックが含まれるディレクトリー。

    デフォルトの値は、ほとんどのインストールでは適切です。

  6. ブリックの指定

    作成するブリックの詳細を入力します。ホストの選択 ドロップダウンメニューを使用して、設定するホストを変更します。

    The Bricks tab of the Gluster Deployment window with the default values shown
    RAID
    使用する RAID 設定を指定します。これは、ホストの RAID 設定と一致する必要があります。サポートされている値は、raid5、raid6、および jbod です。このオプションを設定すると、ストレージが RAID 設定に対して正しく調整されます。
    ストライプのサイズ
    RAID ストライプのサイズを KB 単位で指定します。単位を入力せず、数字のみを入力しません。これは、jbod 設定では無視されます。
    ディスク数
    RAID ボリューム内のデータディスクの数を指定します。これは、jbod 設定では無視されます。
    LV Name
    作成する論理ボリュームの名前。これは、ウィザードの前のページで指定した名前で事前入力されます。
    デバイス
    使用する raw デバイスを指定します。Red Hat は、パーティションが分割されていないデバイスを推奨します。
    Size
    作成する論理ボリュームのサイズを GB 単位で指定します。単位を入力せず、数字のみを入力しません。この数は、レプリケートされたセット内のすべてのブリックで同じでなければなりません。Arbiter ブリックは、レプリカセットの他のブリックよりも小さくすることができます。
    マウントポイント
    論理ボリュームのマウントポイントこれは、ウィザードの前のページで指定したブリックディレクトリーで事前に入力されます。
    Thinp
    このオプションは有効になっており、ボリュームはデフォルトでプロビジョニングされます。ただし、engine ボリュームの場合以外はシンプロビジョニングする必要があります。
    「 Dedupe & 圧縮の有効化」
    デプロイメント時に圧縮および重複排除用に VDO を使用してボリュームをプロビジョニングするかどうかを指定します。
    論理サイズ(GB)
    VDO ボリュームの論理サイズを指定します。これは、絶対最大論理サイズ 4PB の物理ボリュームの最大 10 倍になります。
    LV キャッシュの設定
    必要に応じて、小規模で高速 SSD デバイスを、大規模で低速な論理ボリュームの論理ボリュームキャッシュとして設定します。デバイスパスを SSD フィールドに追加し、サイズを LV Size(GB) フィールドに追加し、デバイスが使用する Cache Mode を設定します。
    警告

    ライトバックモードの使用時にデータの損失を回避するために、Red Hat は、2 つの異なる SSD/NVMe デバイスを使用することを推奨します。RAID-1 設定（ソフトウェアまたはハードウェア）で 2 つのデバイスを設定すると、失われた書き込みによるデータ損失の可能性を大幅に削減します。

    lvmcache 設定の詳細は、「 Red Hat Enterprise Linux 7 LVM の管理 」を参照してください。

    1. （必要に応じて）システムにマルチパスデバイスがある場合は、追加の設定が必要です。

      1. マルチパスデバイスの使用

        RHHI for Virtualization デプロイメントでマルチパスデバイスを使用する場合は、マルチパス WWID を使用してデバイスを指定します。たとえば、/dev/sdb の代わりに /dev/mapper/3600508b1001caab032303683327a6a2e を使用します。

      2. マルチパスデバイスの使用を無効にする

        マルチパスデバイスが環境に存在していても、RHHI for Virtualization デプロイメントに使用しない場合は、デバイスをブラックリストに指定します。

        1. カスタムのマルチパス設定ファイルを作成します。 

          # touch /etc/multipath/conf.d/99-custom-multipath.conf

        2. 以下の内容をファイルに追加します。ここで、<device> はブラックリストに指定するデバイスの名前に置き換えます。 

          blacklist {
  devnodes "<device>"
}

          たとえば、/dev/sdb デバイスをブラックリストに指定するには、以下を追加します。 

          blacklist {
  devnodes "sdb"
}

        3. multipathd を再起動します。 

          # systemctl restart multipathd

        4. lsblk コマンドを使用して、ディスクにマルチパス名が含まれなくなったことを確認します。

          マルチパス名がまだ存在する場合は、ホストを再起動します。

  7. 設定の確認と編集

    The Review tab of the Gluster Deployment window with part of the generated deployment configuration file visible

    1. Edit をクリックして、生成されたデプロイメント設定ファイルの編集を開始します。

      必要な変更を加え、Save をクリックします。

    2. 設定ファイルの確認

      すべての設定情報が正しい場合は Deploy をクリックします。

  8. デプロイメントが完了するまで待機

    テキストフィールドで、デプロイメントの進捗を確認することができます。

    完了したら、ウィンドウに Successfully deployed gluster が 表示されます。

    The final screen of the Gluster Deployment window showing a message that says Successfully deployed Gluster and a button to Continue to Hosted Engine Deployment

    Hosted Engine Deployment をクリックし、7章Web コンソールを使用したホスト型エンジンのデプロイ の手順に従い、デプロイメントプロセスを続行します。

重要

デプロイメントが失敗した場合は、Clean up をクリックして、システムへの変更が正しくないものを削除します。

クリーンアップが完了したら、Redeploy をクリックします。これにより、Review and edit configuration タブに戻り、生成された設定ファイルのすべての問題を修正してからデプロイメントを再試行できます。

第7章 Web コンソールを使用したホスト型エンジンのデプロイ

本セクションでは、Web コンソールを使用して、Hosted Engine をデプロイする方法を説明します。このプロセスに従うと、Red Hat Virtualization Manager がデプロイメントの最初の物理マシンで仮想マシンとして稼働します。また、3 つの物理マシンで構成されるデフォルトクラスターを設定し、クラスター内の各マシンに対して Red Hat Gluster Storage 機能および virtual-host tuned パフォーマンスプロファイルも有効にします。

前提条件

  • Web コンソールを使用したホスト型エンジンのための Red Hat Gluster Storage の設定

  • セルフホストエンジンのデプロイメントに必要な情報の収集

    デプロイメントプロセスを開始する前に、以下の情報の準備が整います。

    • ハイパーコンバージドホストへの ping 可能なゲートウェイの IP アドレス
    • フロントエンド管理ネットワークの IP アドレス
    • セルフホストエンジン用仮想マシンの完全修飾ドメイン名(FQDN)
    • セルフホストエンジンの静的 FQDN および IP アドレスに解決する MAC アドレス

手順

  1. セルフホストエンジンのデプロイメントウィザードを開く

    Web コンソールを使用してセルフホストエンジン用に Red Hat Gluster Storage を直接設定する場合は、ウィザードがすでに開いて いるはずです。

    そうでない場合は、以下を実行します。

    1. Virtualization → Hosted Engine をクリックします。
    2. Hyperconverged の下の Start をクリックします。

    3. 既存の設定の使用 をクリックします。

      重要

      以前のデプロイメントに失敗した場合は、既存の設定ではなく クリーンアップ をクリックし、以前の試行を破棄して ゼロから開始します。

  2. 仮想マシンの詳細を指定する

    The VM tab of the Hosted Engine Deployment window with example values entered in all fields.

    1. 以下の詳細を入力し、Validate for FQDN フィールドをクリックします。

      Engine VM FQDN
      セルフホストエンジン用仮想マシンに使用する完全修飾ドメイン名（例： engine.example.com ）。
      MAC ADDRESS

      Engine 仮想マシンの FQDN に関連付けられた MAC アドレス。

      重要

      事前に設定した MAC アドレスを置き換える必要があります。

      root パスワード
      セルフホストエンジン用仮想マシンに使用する root パスワード
    2. Next をクリックします。FQDN は、次の画面が表示される前に検証されます。

  3. 仮想化管理の詳細指定

    1. 管理ポータルで、admin アカウントで使用するパスワードを入力します。通知の動作を指定することもできます。

      The Engine tab of the Hosted Engine Deployment window with example values entered in all fields.
    2. Next をクリックします。

  4. 仮想マシン設定の確認

    1. このタブに一覧表示された詳細が正しいことを確認します。戻る をクリックして、誤った情報を修正します。

      The Prepare VM tab of the Hosted Engine Deployment window with configuration details displayed for review.
    2. 仮想マシンの準備 をクリックします。

    3. 仮想マシンの準備が完了するまで待ちます。

      The Prepare VM tab of the Hosted Engine Deployment window showing, 'Execution completed successfully. Please proceed to the next step.'

      準備に成功しない場合は、「 Hosted Engine デプロイメントエラーの表示」を参照してください。

    4. Next をクリックします。

  5. セルフホストエンジン用仮想マシンのストレージを指定します

    1. プライマリーホストと engine ボリュームの場所を指定します。

    2. マウントオプションフィールドに正しく設定され て いることを確認してください。

      • <host2-ip-address> および <host3-ip-address> の代わりに挿入される適切な IP アドレスで backup-volfile-servers=<host2-ip-address>:<host3-ip-address> があることを確認します。

      • お使いの環境で IPv6 アドレスが使用されている場合は、以下のように backup-volfile-servers の値の後に xlator-option=transport.address-family=inet6 オプションを追加します。 

        backup-volfile-servers=<host2-ip-address>:<host3-ip-address>,xlator-option=transport.address-family=inet6
        The Storage tab of the Hosted Engine Deployment window with the engine volume specified as hosted engine virtual machine storage.
    3. Next をクリックします。

  6. セルフホストエンジンのデプロイメントの最終処理

    1. デプロイメントの詳細を確認し、それらが正しいことを確認します。

      注記

      設定時に提供された応答は応答ファイルに保存され、必要に応じてセルフホストエンジンを再インストールするのに役立ちます。応答ファイルは、デフォルトで /etc/ovirt-hosted-engine/answers.conf に作成されます。このファイルは、Red Hat サポートのサポートなしで手動で変更しないでください。

      The Finish tab of the Hosted Engine Deployment window with details of the Hosted Engine’s storage displayed.
    2. デプロイメント完了をクリックし ます。

  7. デプロイメントが完了するまで待機

    これには最長 30 分の時間がかかります。

    完了したら、ウィンドウが表示されます。

    The Finish tab of the Hosted Engine Deployment window showing Hosted Engine deployment complete.
    重要

    デプロイメントが正常に完了しない場合は、「 Hosted Engine デプロイメントエラーの表示」を参照して ください。

    閉じる をクリックします。

  8. セルフホストエンジンのデプロイメントの確認

    管理ポータル（例： http://engine.example.com/ovirt-engine ）を参照し、前のステップで設定した管理認証情報を使用してログインできることを確認します。Dashboard をクリックし、ホスト、ストレージドメイン、および仮想マシンを見つけます。

    The Administration Portal dashboard after deployment.

次のステップ

第8章 Red Hat Gluster Storage を Red Hat Virtualization ストレージドメインとして設定

8.1. Gluster トラフィック用論理ネットワークの作成

  1. 管理ポータルにログインします。

    管理ポータル（例： http://engine.example.com/ovirt-engine）を参照し、 7章Web コンソールを使用したホスト型エンジンのデプロイ で設定した管理認証情報を使用してログインします。

  2. Gluster トラフィック用論理ネットワークの作成

    1. Network → Networks の順にクリックし、New をクリックします。New Logical Network ウィザードが表示されます。
    2. ウィザードの General タブで、新しい論理ネットワークの 名前 を指定し、仮想マシンのネットワークチェックボックス の選択を解除します。
    3. ウィザードの Cluster タブで、Required チェックボックスの選択を解除します。
    4. OK をクリックして、新しい論理ネットワークを作成します。

  3. Gluster の新しい論理ネットワークを有効にする

    1. Network → ネットワークをクリックして、新しい論理ネットワークを選択します。
    2. Clusters サブタブをクリックし、Manage Network をクリックします。Manage Network ダイアログが表示されます。
    3. ネットワークの管理 ダイアログで、移行ネットワークおよび Gluster Network のチェックボックスを選択します。
    4. OK をクリックして保存します。

  4. Gluster ネットワークのホストへの接続

    1. コンピュート → ホスト をクリックし、ホストを選択します。
    2. ネットワークインターフェースサブタブをクリック して、ホストネットワークの設定をクリックします。ホストネットワーク の設定画面 が開きます。
    3. 新たに作成されたネットワークを正しいインターフェースにドラッグアンドドロップします。
    4. ホストと Engine 間の接続の確認 ボックスにチェックマークを入れます。
    5. Save network configuration チェックボックスが選択されていることを確認します。
    6. OK をクリックして保存します。

  5. ネットワークの正常性を確認します。

    ネットワークインターフェースタブを クリックし て、ホストのネットワークの状態を確認します。ネットワークインターフェースが「Out of sync」の状態に入るか、または IP アドレスがない場合は、Management → Refresh Capabilities をクリックします。

8.2. 追加のハイパーコンバージドホストの設定

お使いの環境で IPv6 アドレスを使用する場合や、Web コンソールを使用して Red Hat Gluster Storage 用に Red Hat Gluster Storage の設定 の一部として追加のハイパーコンバージドホストを指定していない場合には、その他のハイパーコンバージドホストごとに以下の手順にしたがってください。

  1. コンピュート → ホスト をクリックして、新規 をクリックして、新規ホスト 画面を 開きます。
  2. 管理するホストの 名前 、ホスト名、および パスワード を指定します。
  3. Advanced Parameters で、デプロイメントプロセスで ファイアウォールルールがすでに設定されているので、ホストのファイアウォールを自動設定 するチェックボックスの選択を解除します。
  4. New Host ダイアログの Hosted Engine タブで、Choose hosted Engine deployment アクション の値を Deploy に設定します。これにより、セルフホストエンジンが新規ホストで実行できます。

  5. OK をクリックします。

    1. 残りの全ホストへの Gluster ネットワークの接続
  6. 新たに追加されたホストの名前をクリックし、ホストページに移動します。
  7. ネットワークインターフェースサブタブをクリック して、ホストネットワークの設定をクリックします。
  8. 新たに作成されたネットワークを正しいインターフェースにドラッグアンドドロップします。
  9. Verify connectivity チェックボックスが選択されていることを確認します。
  10. Save network configuration チェックボックスが選択されていることを確認します。

  11. OK をクリックして保存します。

    1. このホストの 一般 サブタブで、Hosted Engine HA の値がスコアとして正の整数でアクティブ で あることを確認します。

      重要

      Score が N/A として一覧表示されている場合には、select hosted Engine deployment アクション のデプロイアクションの選択が記憶されている可能性があります。「 Red Hat Hyperconverged Infrastructure for Virtualization を含むハイパーコンバージドホストの 再 インストール」の手順に従い、デプロイアクションでホストを再インストールし て ください。

    2. ネットワークの正常性を確認します。

      ネットワークインターフェースタブを クリックし て、ホストのネットワークの状態を確認します。ネットワークインターフェースが「Out of sync」の状態に入るか、または IP アドレスがない場合は、Management → Refresh Capabilities をクリックします。

詳細は、『Red Hat Virtualization 4.3 セルフホストエンジンガイド』 を参照してください。https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/self-hosted_engine_guide/chap-installing_additional_hosts_to_a_self-hosted_environment

パート III. 検証

第9章 デプロイメントの確認

デプロイメントが完了したら、デプロイメントが正常に完了したことを確認します。

  1. 管理ポータル（例： http://engine.example.com/ovirt-engine）。

    管理コンソールログイン

    Login page for the Administration Console

  2. セルフホストエンジンのデプロイメント実行時に追加される管理者認証情報を使用してログインします。

    ログインに成功すると、ダッシュボードが表示されます。

    管理コンソールダッシュボード

    Administration Console Dashboard

  3. クラスターが利用可能であることを確認します。

    管理コンソールダッシュボード - クラスター

    The cluster widget with one cluster showing

  4. 1 つ以上のホストが利用可能であることを確認します。

    セルフホストエンジンのデプロイメント中に追加のホストの詳細を提供している場合には、以下に示すように 3 台のホストが表示されます。

    管理コンソールダッシュボード： ホスト

    The hosts widget with 3 hosts showing

    1. コンピュート → ホスト をクリックします。

    2. 全ホストが Up の ステータスで一覧表示されていること を確認します。

      管理コンソール - ホスト

      Administration Console host dashboard

  5. すべてのストレージドメインが利用可能であることを確認します。

    1. Storage → ドメイン をクリックします。

    2. Active アイコンが最初の列に表示されることを確認します。

      管理コンソール - ストレージドメイン

      Administration Console storage domain dashboard

パート IV. 次のステップ

第10章 デプロイメント後の設定に関する提案

要件に応じて、新たにデプロイされた Red Hat Hyperconverged Infrastructure for Virtualization で追加の設定を実行することができます。このセクションは、追加設定の次のステップについて説明します。

このプロセスの詳細は、『Red Hat Hyperconverged Infrastructure for Virtualization』の「 Maintaining Red Hat Hyperconverged Infrastructure for Virtualization 」を参照してください。

10.1. 高可用性のためのフェンシングの設定

フェンシングにより、クラスターはパフォーマンスおよび可用性ポリシーを適用し、ハイパーコンバージドホストを自動的に再起動することで、予期しないホスト障害に対応することができます。

詳細は、「 フェンスポリシーを使用した高可用性の設定 」を参照してください。

10.2. バックアップおよびリカバリーオプションの設定

Red Hat は、すべての実稼働デプロイメントで少なくとも基本的な障害復旧機能を設定することを推奨します。

詳細は、『 Maintaining Red Hat Hyperconverged Infrastructure for Virtualization 』の「 Configuring backup and recovery options 」を参照してください。

パート V. トラブルシューティング

第11章 ログファイルの場所

デプロイメントプロセス中に、進捗情報が Web ブラウザーに表示されます。また、この情報はローカルファイルシステムに保存され、ログに記録された情報が後でアーカイブまたはレビューされます。たとえば、Web ブラウザーが応答が停止したり、情報がレビューされる前に閉じられた場合などです。

Web コンソールベースのデプロイメントプロセスのログファイル（ 6章Web コンソールを使用したホスト型エンジンのための Red Hat Gluster Storage の設定で文書化）は、デフォルトで /var/log/ansible.log ファイルに保存されます。

デプロイメントプロセスの Hosted Engine 設定部分（ 7章Web コンソールを使用したホスト型エンジンのデプロイに文書化）のログファイルは /var/log/ovirt-hosted-engine-setup ディレクトリーに保存され、ファイル名の形式が ovirt-hosted-engine-setup-<date>.log です。

第12章 デプロイメントエラーの表示

12.1. ストレージのデプロイに失敗しました。

ストレージのデプロイメント中にエラーが発生すると、デプロイメントプロセス は停止し、&#x24e7; Deployment failed が表示されます。

ストレージのデプロイに失敗しました。

Example of failed storage deployment

  • エラー情報の Web コンソール出力を確認します。
  • Clean up を クリックして、システムへの誤った変更を削除します。
  • Redeploy をクリックし、エラーが発生する可能性のある入力された値を修正します。エラーを解決する必要がある場合は、Red Hat サポートまでお問い合わせください。
  • ストレージのデプロイメント に戻り、再試行します。

12.2. 仮想マシンの準備に失敗しました

Hosted Engine デプロイメント で仮想マシンの準備中にエラーが発生した場合は、デプロイメントを一時停止し、以下のような画面が表示されます。

仮想マシンの準備に失敗しました。

Example of failed virtual machine preparation

  • エラー情報の Web コンソール出力を確認します。
  • Clean up を クリックして、システムへの誤った変更を削除します。
  • Redeploy をクリックし、エラーが発生する可能性のある入力された値を修正します。エラーを解決する必要がある場合は、Red Hat サポートまでお問い合わせください。

  • すべてのホストで rhvm-appliance パッケージが利用可能であることを確認します。 

    # yum install rhvm-appliance

  • セルフホストエンジンのデプロイメント に戻り、再試行します。

    解決中にデプロイメントウィザードを閉じる場合は、デプロイメントプロセスを再試行するときに 既存の設定を使用 できます。

12.3. セルフホストエンジンのデプロイに失敗しました。

セルフホストエンジンのデプロイメント中にエラーが発生すると、デプロイメントは一時停止し、&#x24e7; Deployment failed が表示されます。

セルフホストエンジンのデプロイメントに失敗しました。

Example of a failed hosted engine deployment

  • エラー情報の Web コンソール出力を確認します。

  • engine ボリュームの内容を削除します。

    1. engine ボリュームをマウントします。 

      # mount -t glusterfs <server1>:/engine /mnt/test

    2. ボリュームの内容を削除します。 

      # rm -rf /mnt/test/*

    3. engine ボリュームをアンマウントします。 

      # umount /mnt/test
  • Clean up を クリックして、システムへの誤った変更を削除します。
  • Redeploy をクリックし、エラーが発生する可能性のある入力された値を修正します。エラーを解決する必要がある場合は、Red Hat サポートまでお問い合わせください。

  • セルフホストエンジンのデプロイメント に戻り、再試行します。

    解決中にデプロイメントウィザードを閉じる場合は、デプロイメントプロセスを再試行するときに 既存の設定を使用 できます。

パート VI. リファレンス資料

付録A 用語集

A.1. 仮想化の用語

管理ポータル
oVirt engine Web ユーザーインターフェースに基づく、Red Hat Virtualization Manager が提供する Web ユーザーインターフェース。これにより、管理者はネットワーク、ストレージドメイン、仮想マシンテンプレートなどのクラスターリソースを管理し、監視することができます。
セルフホストエンジン
RHHI for Virtualization を管理する Red Hat Virtualization Manager のインスタンス。
セルフホストエンジン用仮想マシン
Red Hat Virtualization Manager として動作する仮想マシン。Hosted Engine 仮想マシンは、Hosted 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 つだけ存在します。
ストレージドメイン
イメージ、テンプレート、スナップショット、およびメタデータの名前付きコレクション。ストレージドメインは、ブロックデバイスまたはファイルシステムで構成されます。ストレージドメインは、データセンター内でホストコレクションにアクセスできるように、イメージ、テンプレートなどにアクセスするためにデータセンターにアタッチされます。
仮想化ホスト
クライアントアクセス用に、物理リソース、プロセス、およびアプリケーションを仮想化する機能を持つ物理マシン。
VM ポータル
Red Hat Virtualization Manager が提供する Web ユーザーインターフェース。これにより、ユーザーは仮想マシンを管理および監視できます。

A.2. ストレージに関する用語

ブリック
信頼されたストレージプール内のサーバーにエクスポートされたディレクトリー。
キャッシュ論理ボリューム
大規模で低速な論理ボリュームのパフォーマンスを改善するのに使用される小規模の論理ボリューム。
geo-replication
ソースの Gluster ボリュームからターゲットボリュームへのデータの非同期レプリケーションの 1 つの方法。ジオレプリケーションは、ローカルおよびリモートエリアネットワークとインターネット全体で動作します。ターゲットボリュームは、別の信頼できるストレージプール内の Gluster ボリューム、または別のタイプのストレージです。
Gluster ボリューム
ワークロード要件に応じて、データを分散、複製、または分散するように設定できるブリックの論理グループ。
論理ボリューム管理(LVM)
物理ディスクを大きな仮想パーティションに統合する方法。ボリュームグループはボリュームグループに配置され、必要に応じて論理ボリュームに分割できるストレージのプールを形成します。
Red Hat Gluster Storage
Red Hat Enterprise Linux をベースとするオペレーティングシステムには、分散型のソフトウェア定義ストレージのサポートを提供する追加のパッケージが含まれています。
ソースボリューム
ジオレプリケーション中にデータをコピーする Gluster ボリューム。
ストレージホスト
クライアントアクセス用にストレージを提供する物理マシン。
ターゲットボリューム
Gluster ボリュームまたはジオレプリケーション中にデータをコピーするその他のストレージボリューム。
シンプロビジョニング
同時に割り当てる領域だけを持つストレージをプロビジョニングし、必要な容量が過剰に動的に割り当てられます。
シックプロビジョニング
領域がすぐに必要かどうかにかかわらず、すべての領域が作成時に割り当てられるストレージをプロビジョニングします。
信頼できるストレージプール
相互に信頼できるピアとして認識する Red Hat Gluster Storage サーバーのグループ。

A.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 コンソールサービスおよびプラグインにより提供されます。