Red Hat Hyperconverged Infrastructure for Virtualizationのデプロイ

Red Hat Hyperconverged Infrastructure for Virtualization 1.7

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

概要

本書では、Red Hat Gluster Storage 3.5 および Red Hat Virtualization 4.3 を使用して、3 つの物理マシンに Red Hat IaaS Infrastructure for Virtualization(RHHI for Virtualization)をデプロイする方法を説明します。これにより、リモートオフィス/ブランチオフィス(ROBO)環境で使用する個別のクラスターが作成されます。ここでは、リモートオフィスは、データを定期的に中央のデータセンターに同期しますが、中央のデータセンターへの接続が失われた場合に、完全に機能する状態を維持することができます。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

パート I. プラン

第1章 アーキテクチャー

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

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

このデプロイメントの主要なユースケースは、リモートオフィス/ブランチオフィス(ROBO)環境です。ここでは、リモートオフィスは定期的に中央データセンターにデータを同期しますが、機能するのに中央のデータセンターへの接続を必要としません。

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

3 台の物理マシンにデプロイされた Red Hat Hyperconverged Infrastructure for Virtualization のアーキテクチャーの図

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 を有効にして必要なパフォーマンスを実現することを確実に推奨しています。

VDO の下の層で RAID ハードウェアを使用する予定の場合には、SSD/NVMe ディスクを使用してパフォーマンスの問題を回避することを推奨します。VDO の下で RAID ハードウェア層を使用していない場合は、スピンディスクを使用できます。

第2章 サポート要件

このセクションでは、予定されるデプロイメントが Red Hat のサポート要件を満たしていることを確認します。

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

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

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

2.2. 物理マシン

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

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

  • データおよび管理トラフィックを分離するために、物理マシンごとに少なくとも 2 つの NIC(ネットワークインターフェースコントローラー)が設定されます(詳細は 「ネットワーキング」 を参照してください)。
  • 小規模なデプロイメントの場合:

    • 12 コア以上
    • 64GB 以上の RAM
    • 最大 48TB ストレージ
  • 中規模デプロイメントの場合

    • 12 コア以上
    • 最小 128GB RAM
    • 最大 64TB ストレージ
  • 大規模なデプロイメントの場合

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

2.3. 仮想マシン

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

仮想マシンおよび仮想 CPU の最大数 に関する情報は、Virtualization limits for Red Hat Virtualization を参照してください。また、デプロイメントのプランニングは RHHI for Virtualization Sizing Tool を使用します。

注記

Red Hat Hyperconverged Infrastructure for Virtualization(Red Hat OpenShift Container Platformがインストールされた仮想マシンをホストするハイパーコンバージドノード)の上にOpenShift Container Storageを置くことは、サポートされていない構成です。

2.4. ホスト型エンジン仮想マシン

ホスト型エンジン仮想マシンには、少なくとも以下が必要です。

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

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

2.5. ネットワーキング

DNS で正引きおよび逆引き解決が可能な完全修飾ドメイン名 は、すべてのハイパーコンバージドホストおよびホスト型エンジン仮想マシンに必要です。

外部 DNS が利用できない場合(例: 分離された環境など)、各ノードの /etc/hosts ファイルにすべてのホストおよびホスト型エンジンノードのフロントエンドアドレスが含まれることを確認します。

IPv6 は、IPv6 のみの環境(DNS およびゲートウェイアドレスを含む)ではテクノロジープレビューとしてサポートされます。IPv4 アドレスと IPv6 アドレスの両方を備えた環境はサポートされません。

重要

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

Red Hat は、仮想マシンのトラフィックに フロントエンド管理ネットワーク と、gluster トラフィックおよび仮想マシンの移行向けの バックエンドストレージネットワーク という別のネットワークを使用することを推奨します。

Red Hat では、それぞれのノードに各ネットワーク用にイーサネットポートを 1 つずつ設定することを推奨します。これにより、最適なパフォーマンスが確保されます。高可用性を確保するには、各ネットワークを別個のネットワークスイッチに配置します。フォールトトレランスを強化するために、スイッチごとに個別の電源供給を指定します。

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

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

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

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

  • 信頼できるタイムソースを設定します。
  • IPv6 アドレスは使用しないでください。

    警告

    Bug 1688239: 現在、IPv6 ベースの geo レプリケーションが正しく機能しなくなります。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 では、/var/log のサイズを 15 GB 以上に増やして、Red Hat Gluster Storage の追加ロギング要件に十分な領域を提供することを推奨します。

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

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

2.6.1. ディスク

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

異なるブロックサイズを持つディスク間で Gluster ボリュームのブリックをホストしないでください。VDOデバイスのデフォルトのブロックサイズがバージョン1.6の512バイトからバージョン1.7では4KBに変更されたため、ボリュームを作成する前にレンガのホストとして使用されている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 ハードウェアを使用する予定の場合には、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とオプションのdataGlusterボリュームを構成する論理ボリュームはシンプロビジョニングされている必要があります。これにより、基礎となるボリューム設定で柔軟性が向上します。シンプロビジョニングされたボリュームがハードディスク(HDD)にある場合は、パフォーマンスを向上させるために、小規模かつ高速な Solid State Disk(SSD)を lvmcache として設定します。

2.6.5. Red Hat Gluster Storage ボリューム

Red Hat Hyperconverged Infrastructure for Virtualizationには、Red Hat Gluster Storageのボリュームが3から4個搭載される予定です。

  • ホステッドエンジン用のエンジンボリューム 1 個
  • 仮想マシンのオペレーティングシステムディスクイメージ用のvmstoreボリューム 1 個
  • 他の仮想マシンのディスクイメージ用の data ボリューム 1 個
  • ジオレプリケーションメタデータ用のshared_storageボリューム 1 個

バックアップに必要なストレージ容量を最小限に抑えるために、vmstoredataボリュームを分けることをお勧めします。オペレーティングシステムイメージから分離されている仮想マシンデータを保存すると、vmstore ボリュームのオペレーティングシステムイメージをより簡単に再構築できるため、ストレージ領域がプレミアムにあるときに data ボリュームのみのバックアップを作成する必要があります。

仮想化のデプロイメント用の Red Hat ハイパーコンバージドインフラストラクチャーには、最大 1 つの geo-replicated ボリュームを含めることができます。

2.6.6. ボリュームタイプ

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

  • Replicated volumes(3つのブリック上の同じデータの3つのコピー、3つのノードにまたがる)。

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

  • Arbitrated replicated volumes(3 つのノードにまたがって、2 つのブリックに同じデータのフルコピーを 2 つ、メタデータを含む 1 つのアービターブリックにコピーしたもの)。

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

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

判定ブリックは、ファイル名、構造、およびメタデータのみを保存することに注意してください。つまり、3 方向の判別複製ボリュームは、同じレベルの一貫性を実現するために、3 方向の複製ボリュームが 75 % である必要があることを意味します。ただし、arbiter ブリックはメタデータのみを格納するため、3 方向の判別複製ボリュームは双方向複製ボリュームのみを提供します。

裁定済みレプリケートボリュームのレイアウトの詳細については、Red Hat Gluster Storage Administration GuideCreating multiple arbitrated replicated volumes across fewer total nodes を参照してください。

2.7. VDO (Virtual Data Optimizer)

VDO(Virtual Data Optimizer)層は、Red Hat Hyperconverged Infrastructure for Virtualization 1.6 でサポートされます。

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

VDO デバイスのデフォルトのブロックサイズが、バージョン 1.6 の 512 バイトからバージョン 1.7 で 4 KB に変更されることに注意してください。異なるブロックサイズを持つディスク間で Gluster ボリュームのブリックをホストしないでください。

2.8. スケーリング

仮想化用の Red Hat IaaS Infrastructure の初期デプロイメントは 1 ノードまたは 3 ノードです。

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

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

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

Web コンソールを使用して、作成時に 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 は、障害復旧ソリューションを設定することを強く推奨します。Geo レプリケーションを障害復旧ソリューションとして設定する方法の詳細は、「 Red Hat IaaS Infrastructure for Virtualization:https://access.redhat.com/documentation/ja-jp/red_hat_hyperconverged_infrastructure_for_virtualization/1.7/html/maintaining_red_hat_hyperconverged_infrastructure_for_virtualization/config-backup-recovery 」を参照してください。

警告

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

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

geo レプリケーションを設定する際には、以下の要件と制限に注意してください。

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

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

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

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

すべてのサポート 要件を満たしている場合、Red Hat ハイパーコンバージドインフラストラクチャー 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 のいずれかに登録します。
  • アクティビティーを適切に追跡するために、多くのユーザーにデフォルトの admin アカウントの使用を許可する代わりに、個別の管理者アカウントを作成します。
  • ホストへのアクセスを制限し、別のログインを作成します。すべてのユーザーが使用する 1 つの root ログインを作成しないでください。『Red Hat Enterprise Linux 7 システム 管理者のガイド』の「ユーザーとグループ の管理」を参照してください。
  • ホストに信頼できないユーザーを作成しないでください。
  • 解析ツール、コンパイラー等の追加のパッケージ、または不要なセキュリティーリスクを追加するその他のコンポーネントをインストールしないでください。

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.5. セルフホストエンジンの推奨事項

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

パート II. デプロイ

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

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

  1. 予定されているデプロイメントがサポート要件を満たしていることを確認します( 2章サポート要件 )。
  2. ハイパーコンバージドホストとして機能する物理マシンをインストールします( 「ホストの物理マシンのインストール」 )。
  3. パスワードなしで鍵ベースの SSH 認証を設定し、ホストの自動設定を有効にします( 5章パスワードなしの公開鍵ベースの SSH 認証の設定 )。
  4. Web コンソールを使用して、物理ホストに Red Hat Gluster Storage を設定します( 6章Web コンソールを使用したHosted Engine用Red Hat Gluster Storage の設定 )。
  5. Web コンソールを使用して Hosted Engine をデプロイします( 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 IaaS 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 Image に移動し今すぐダウンロード をクリックします。
    5. 起動可能なメディアデバイスを作成します。詳細については、Red Hat Enterprise Linux Installation GuideMaking Media を参照してください。
  2. Red Hat Virtualization Host をインストールするマシンを起動し、準備したインストールメディアから起動します。
  3. 起動メニューから Install RHVH 4.3 を 選択し、Enter を押します。

    注記

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

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

    重要

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

  6. キーボード画面からキーボードレイアウトを選択し 完了 をクリックし ます
  7. インストール 画面でインストールの場所を指定します。

    重要
    • Red Hat は、Automatically configure partitioning オプションを使用することを強くお勧めします。
    • すべてのディスクがデフォルトで選択されるため、インストール場所として使用しないディスクの選択を解除します。
    • at-rest 暗号化はサポートされていません。暗号化を有効にしないでください。
    • Red Hat では、/var/log のサイズを 15 GB 以上に増やして、Red Hat Gluster Storage の追加ロギング要件に十分な領域を提供することを推奨します。

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

    完了をクリックします。

  8. ネットワーク &amp ; ホスト名 の画面からイーサネットネットワークを選択します。

    1. Configure…General の順にクリックし、利用可能な場合にこのネットワークに自動接続 チェックボックスを選択します。
  9. オプションで 言語サポートセキュリティーポリシー、および Kdump を設定します。インストール 概要 画面の各セクションの詳細は、『 Red Hat Enterprise Linux 7 インストールガイド』 の「Anaconda を使用 した Anaconda のインストール 」を参照してください。
  10. インストールの開始 をクリックします。
  11. root パスワードを設定し、オプションで Red Hat Virtualization Host のインストール時に追加のユーザーを作成します。

    警告

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

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

    注記

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

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

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

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

  2. Subscriptions に移動し、Register System をクリックしてカスタマーポータルのユーザー名とパスワードを入力します。

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

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

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

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

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

5.1. パスワードなしの 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.2. SSH キーのコピー

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

前提条件

  • 公開鍵と秘密鍵を生成する

手順

  1. 最初のホストに root ユーザーとしてログインします。
  2. フロントエンドとバックエンドの両方のFQDNを使って、コマンドを実行するホストを含む、アクセスする各ホストに、公開鍵をコピーしてください。

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

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

    警告

    必ず .pub で終わるファイルを使用していることを確認してください。秘密鍵を共有しないでください。自分の秘密鍵を持っていると、自分の公開鍵を持っているシステムで、他人が自分になりすますことができます。

    たとえば、server1.example.com で root ユーザーとしてログインしている場合は、以下のコマンドを実行します。

    # 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

第6章 Web コンソールを使用したHosted Engine用Red Hat Gluster Storage の設定

重要

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

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

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

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

    1. VirtualizationHosted Engine をクリックし、Hyperconverged の下の Start をクリックします。

      Hosted Engine および Hyperconverged オプションの下の起動ボタンのあるホスト型エンジンセットアップ画面

      Gluster Configuration ウィンドウが開きます。

    2. Run Gluster Wizard ボタンをクリックします。

      Webコンソールでハイパーコンバージド展開のタイプを選択する

      Gluster Deployment ウインドウが3ノードモードで開きます。

  3. ハイパーコンバージドホストの指定

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

    注記

    調整されたレプリケートされたボリュームを作成する予定がある場合は、この画面で arbiter ブリックのホストを Host3 として指定してください。

    Gluster DeploymentウィンドウのHostsタブ:Host AddressフィールドのIPアドレスの例

    次へをクリックします。

  4. 追加のホストの指定

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

    完全修飾ドメイン名の例を含む Gluster Deployment ウィンドウの Additional Hosts タブ
    重要

    Bug 1688269 は、デプロイメントの完了時に IPv6 アドレスを持つホストが Red Hat Virtualization Manager に自動的に追加されないことを意味します。ホスト エンジンにさらにハイパーコンバージドホストを追加する に従って、デプロイメント後にそれらを追加 できます。

  5. ボリュームの指定

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

    デフォルト値が表示されたGluster Deployment ウィンドウのVolumesタブ
    名前
    作成するボリュームの名前を指定します。
    Volume Type
    Replicate ボリュームタイプを指定します。本リリースでは、複製されたボリュームのみがサポートされます。
    Arbiter
    判定ブリックを使用してボリュームを作成するかどうかを指定します。このボックスをチェックすると、3番目のディスクにはメタデータのみが保存されます。
    ブリックDir
    このボリュームのブリックが含まれるディレクトリー。
    ボリュームの追加
    ボリュームを追加するには、Add Volume オプションをクリックすると、空のエントリーが作成されます。追加するボリュームの名前を指定し、arbiter ボリュームが必要な場合は arbiter チェックボックスにチェックを入れます。ブリックパスを /gluster_bricks/<volname>/<volname> として使用することが推奨されます

    ほとんどのインストールでは、デフォルト値が正しくありません。

  6. ブリックの指定

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

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

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

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

    1. (オプション)システムにマルチパスデバイスがある場合は、追加の設定が必要です。

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

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

      2. マルチパスデバイスの使用を無効にする場合は、次のコマンドを実行します。

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

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

          # mkdir /etc/multipath/conf.d
          # touch /etc/multipath/conf.d/99-custom-multipath.conf
        2. 以下の内容をファイルに追加します。< device> はブラックリストに登録するデバイスの名前に置き換えます。

          blacklist {
            devnode "<device>"
          }

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

          blacklist {
            devnode "sdb"
          }
        3. multipathd を再起動します。

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

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

  7. 設定の確認および編集

    生成されたデプロイメント設定ファイルの一部を持つ Gluster Deployment ウィンドウの Review タブを表示
    1. Edit をクリックして、生成されたデプロイメント設定ファイルの編集を開始します。

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

    2. 設定ファイルの確認

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

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

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

    ウィンドウには、Successfully deployed gluster が表示されます。

    Gluster Deployment ウィンドウの最後の画面には、S successfully deployed Gluster とボタンが Hosted Engine Deployment に送信されることを示すメッセージが表示されます。

    Continue to Hosted Engine Deployment をクリックし、7章Web コンソールを使用したHosted Engineのデプロイ の説明に従ってデプロイメントプロセスを続行します。

重要

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

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

第7章 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 アドレス

手順

  1. ホスト型エンジン Deployment ウィザードを開く

    Web コンソールを使用して「Configure Red Hat Gluster Storage for Hosted Engine 」の最後から直接いる場合は、ウィザードがすでに開いています。

    それ以外の場合:

    1. VirtualizationHosted Engine をクリックします。
    2. Hyperconverged の下にある Start をクリックします。
    3. Use existing configuration をクリックします。

      重要

      以前のデプロイメントに失敗した場合は、Use existing configuration ではなく Clean up をクリックして、以前の試行を最初から破棄して開始します。

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

    Hosted Engine Deployment ウィンドウの VM タブに、全フィールドに入力された値の例を入力します。
    1. 以下の詳細を入力し、Validate for FQDN フィールドをクリックします。

      エンジン仮想マシン 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 の値をデフォルト値に維持することを推奨します。

    2. オプションで、Advanced フィールドを展開します。

      ホスト型エンジン Deployment ウィンドウの詳細オプション。
      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 に設定します。
    3. Next をクリックします。FQDN は、次の画面が表示される前に検証されます。
  3. 仮想管理の詳細を指定する

    1. 管理ポータルで admin アカウントが使用するパスワードを入力します。また、通知用のメールアドレスを指定することもできます。これには、デプロイメント後の追加の設定が必要です。10章デプロイメント後設定の提案 を参照してください。

      Hosted Engine Deployment ウィンドウの Engine タブに、全フィールドに入力されたサンプルの値が含まれます。
    2. Next をクリックします。
  4. 仮想マシン設定の確認

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

      Hosted Engine Deployment ウィンドウの Prepare VM タブが表示され、レビュー用に設定の詳細が表示されます。
    2. Prepare VM をクリックします。
    3. 仮想マシンの準備が完了するまで待ちます。

      Hosted Engine DeploymentウィンドウのPrepare VMタブに Execution completed successfully と表示されています。次のステップに進むようにしてください。

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

    4. Next をクリックします。
  5. ホスト型エンジン仮想マシンのストレージの指定

    1. プライマリーホストと エンジン ボリュームの場所を指定します。
    2. マウントオプション フィールドに正しく入力されていることを確認します。

      • <host 2-ip-address> および <host3-ip-address> の代わりに適切な IP アドレスが挿入されている backup-volfile-servers= <host 2-ip-address>:<host 3 -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
        Hosted Engine Deployment ウィンドウのストレージタブ。エンジンボリュームは、ホストされたエンジン仮想マシンのストレージとして指定されています。
    3. Next をクリックします。
  6. ホスト型エンジンのデプロイメントの最終処理

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

      注記

      設定中に指定した応答は応答ファイルに保存され、必要に応じてホストされたエンジンを再インストールする上で役立ちます。応答ファイルは、デフォルトで /etc/ovirt-hosted-engine/answers.conf に作成されます。このファイルは、Red Hat サポートの支援なしに手動で変更することができません。

      Hosted Engine Deployment ウィンドウの Finish タブが表示され、ホスト型エンジンのストレージが表示されます。
    2. Finish Deployment をクリックします。
  7. デプロイメントが完了するまで待ちます。

    設定の詳細によっては、時間がかかる場合があります。

    ウィンドウには、完了すると以下が表示されます。

    Hosted Engine Deployment ウィンドウの Finish タブに、Hosted Engine のデプロイメントが完了しました。
    重要

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

    Close をクリックします。

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

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

    デプロイ後の管理ポータルのダッシュボード

第8章 「Configure Red Hat Gluster Storage as a Red Hat Virtualization storage domain」

8.1. gluster トラフィック用の論理ネットワークを作成します。

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

    管理ポータル(例: http://engine.example.com/ovirt-engine)に移動し、7章Web コンソールを使用したHosted Engineのデプロイ で設定した管理クレデンシャルを使用してログインします。

  2. gluster トラフィック用の論理ネットワークを作成します。

    1. ネットワークネットワーク をクリックしてから、新規 をクリック ます。New Logical Network ウィザードが表示されます。
    2. ウィザードの General タブで、新しい論理ネットワークの 名前 を指定して、VM Network チェックボックスの選択を解除します。
    3. ウィザードの Cluster タブで、Required チェックボックスの選択を解除します。
    4. OK をクリックして、新しい論理ネットワークを作成します。
  3. gluster の新しい論理ネットワークを有効にします。

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

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

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

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

お使いの環境で IPv6 アドレスを使用する場合や、Web コンソールを使用して Red Hat Gluster Storage for Hosted Engine の設定 の一部として追加のハイパーコンバージドホストを指定しない場合は、他のハイパーコンバージドホストごとに、管理ポータルで以下の手順に従います。

  1. コンピュートホスト をクリックしてから 新規 をクリックして 新規ホスト ウィンドウを 開きます。
  2. 管理するホストの 名前、ホスト名、および パスワード を入力します。
  3. Advanced ParametersAutomatically configure host firewall チェックボックスの選択を解除します。
  4. 新規 ホスト ダイアログの Hosted Engine タブで、Choose hosted engine デプロイメントアクション の値を Deploy に設定します。これにより、ホストされたエンジンが新規ホストで実行できます。
  5. OK をクリックします。

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

    1. このホストの General サブタブで、Hosted Engine HA の値が Active で、正の整数をスコアとして使用していることを確認します。

      重要

      ScoreN/A としてリストされている場合は、Choose hosted engine deployment アクションの deploy アクションを選択する必要がある場合があります。『 Red Hat Warehouse Infrastructure for Virtualization の維持』の「ハイパーコンバージドホストの再インストール の手順に従い、デプロイ アクションでホストを再インストールします。

    2. ネットワークの正常性の確認

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

詳細は、『Red Hat Virtualization 4.3 セルフホストエンジンガイド』 を参照してください。https://access.redhat.com/documentation/ja-jp/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. ホスト型エンジンのデプロイメント時に追加された管理認証情報を使用してログインします。

    ログインに成功すると、Dashboard が表示されます。

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

    Administration Console Dashboard

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

    アドミニストレーションコンソールのダッシュボード : クラスタ

    The cluster widget with one cluster showing

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

    ホスト型エンジンのデプロイメント中に追加のホストの詳細を指定した場合は、以下に示すように 3 つのホストが表示されます。

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

    The hosts widget with 3 hosts showing

    1. ComputeHosts をクリックします。
    2. すべてのホストの StatusUp と表示されていることを確認します。

      管理コンソール - Hosts

      Administration Console host dashboard

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

    1. Storage から Domains をクリックします。
    2. Active アイコンが最初の列に表示されることを確認します。

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

      Administration Console storage domain dashboard

パート IV. 次のステップ

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

要件によっては、新たにデプロイした Red Hat Hyperconverged Infrastructure for Virtualization で追加の設定を実行することができます。本セクションでは、追加の設定に推奨される手順を説明します。

これらのプロセスの詳細は、『 Red Hat Warehouse Infrastructure for Virtualization』 を参照してください。

10.1. 通知の設定

メール通知を設定するには、「 管理ポータルでのイベント 通知の設定」を参照してください。

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

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

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

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

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

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

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

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

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

Web コンソールベースのデプロイメントプロセスのログファイル( 6章Web コンソールを使用したHosted Engine用Red Hat Gluster Storage の設定で文書化)は、デフォルトで /var/log/cockpit/ovirt-dashboard/gluster-deployment.log ファイルに保存されます。

デプロイメントプロセスの Hosted Engine 設定部分( 7章Web コンソールを使用したHosted Engineのデプロイで文書化されている)のログファイルは /var/log/ovirt-hosted-engine-setup ディレクトリーに保存されます。ファイル名は ovirt-hosted-engine-setup-<date>.log です。

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

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

ストレージのデプロイメント中にエラーが発生した場合、展開プロセスが停止し、Deployment failed と表示されます。

Deploying storage failed

Example of failed storage deployment

  • エラー情報については、Web コンソールの出力を確認します。
  • Clean up をクリックして、システムに不正な変更をすべて削除します。
  • Redeploy をクリックし、エラーが出される可能性のある入力値を修正します。エラーの解決に関するヘルプが必要な場合は、詳細について Red Hat サポートにお問い合わせください。
  • ストレージのデプロイメントに戻って、もう一度試してみてください。

12.1.1. 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}

このエラーは、以下の 2 つの状況で発生します。

  • VDO デバイスとして設定されているデバイスを指定し、データ損失を回避するためにデプロイメントスクリプトが停止しました。

    解決策:

    • ストレージ設定に戻り、別の VDO 以外のデバイスを指定します。
    • VDO デバイスを手動でクリーンアップ」の 手順に従い、既存の VDO ファイルシステムを削除します。次に、ストレージ設定に戻り、再試行します。
  • 適切にクリーンアップされず、VDO 署名が含まれるデバイスを指定していると、VDO デバイスが適切に設定されていないにもかかわらず、VDO 署名が含まれます。

    解決策:

    1. デバイスの TYPE が "vdo" であることを確認します。

      # blkid -p /dev/sdb
      /dev/sdb: UUID="fee52367-c2ca-4fab-a6e9-58267895fe3f" TYPE="vdo" USAGE="other"
    2. このデバイスを使用するには、Manually cleaning up a VDO device の手順に従ってください。その後、ストレージのデプロイメント に戻り、再度検証します。

クリーンなデバイスを指定し、ストレージデプロイメントウィンドウの Clean up ボタンを使用して、失敗したデプロイメントをクリーンアップしてこのエラーを回避します。

12.1.2. VDO デバイスの手動クリーンアップ

以下の手順に従って、デプロイメントの失敗の原因となった VDO デバイスを手動でクリーンアップします。

警告

これは破壊的プロセスです。クリーンアップするデバイスのデータはすべて失われます。

手順

  1. wipefs を使用してデバイスをクリーンアップします。

    # wipefs -a /dev/sdX

検証

  1. デバイスに TYPE="vdo" がさらに設定されていないことを確認します。

    # blkid -p /dev/sdb
    /dev/sdb: UUID="fee52367-c2ca-4fab-a6e9-58267895fe3f" TYPE="vdo" USAGE="other"

次のステップ

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

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

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

Example of failed virtual machine preparation

  • エラー情報については、Web コンソールの出力を確認します。
  • Clean up をクリックして、システムに不正な変更をすべて削除します。
  • Redeploy をクリックし、エラーが出される可能性のある入力値を修正します。エラーの解決に関するヘルプが必要な場合は、詳細について Red Hat サポートにお問い合わせください。
  • すべてのホストで rhvm-appliance パッケージが利用可能であることを確認します。

    # yum install rhvm-appliance
  • Hosted Engine デプロイメント に戻り、再試行します。

    エラーを解決している間にデプロイメントウィザードを終了する場合は、デプロイメントプロセスを再試行するときに、Use existing configuration を選択します。

12.3. ホスト型エンジンのデプロイに失敗しました

ホストされているエンジンのデプロイメント中にエラーが発生した場合には、デプロイメントの一時停止と 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 サポートにお問い合わせください。
  • Hosted Engine デプロイメント に戻り、再試行します。

    エラーを解決している間にデプロイメントウィザードを終了する場合は、デプロイメントプロセスを再試行するときに、Use existing configuration を選択します。

パート VI. 参考資料

付録A 用語集

A.1. 仮想化用語

Administration Portal
oVirt engine Web ユーザーインターフェースをベースとする Red Hat Virtualization Manager が提供する Web ユーザーインターフェース。これにより、管理者はネットワーク、ストレージドメイン、仮想マシンテンプレートなどのクラスターリソースを管理および監視できます。
ホスト型エンジン
RHHI for Virtualization を管理する Red Hat Virtualization Manager のインスタンス。
ホスト型エンジン仮想マシン
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 ユーザーインターフェースこれにより、ユーザーは仮想マシンの管理および監視を行うことができます。

A.2. ストレージ用語

ブリック
信頼できるストレージプール内のサーバーにエクスポートされるディレクトリー。
キャッシュ論理ボリューム
大規模で低速な論理ボリュームのパフォーマンスを改善するのに使用される小規模で高速な論理ボリューム。
geo-replication
ソースの Gluster ボリュームからターゲットボリュームへのデータの非同期レプリケーション。Geo レプリケーションは、ローカル領域ネットワークおよびインターネット全体で機能します。ターゲットボリュームは、異なる信頼できるストレージプールの Gluster ボリューム、または別のタイプのストレージになります。
Gluster ボリューム
ワークロードの要件に応じてデータを分散、複製、または分散するように設定できるブリックの論理グループ。
論理ボリューム管理(LVM)
物理ディスクを大きな仮想パーティションに統合する方法。物理ボリュームはボリュームグループに配置され、必要に応じて論理ボリュームに分割できるストレージのプールを形成します。
Red Hat Gluster Storage
Red Hat Enterprise Linux をベースとするオペレーティングシステムは、分散型のソフトウェア定義のストレージをサポートする追加パッケージが含まれています。
ソースボリューム
データが geo レプリケーション時にコピーされる Gluster ボリューム。
ストレージホスト
クライアントアクセス用にストレージを提供する物理マシン。
ターゲットボリューム
geo レプリケーション時にデータがコピーされる 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 コンソールサービスおよびプラグインによって提供されます。