第3章 既知の問題

本セクションでは、Red Hat IaaS Infrastructure for Virtualization(RHHI for Virtualization)に影響を与えることがわかっている予期しない動作を説明します。

BZ#1793398 - デプロイメント時の Ansible ロールの正しい変数

コマンドラインから自動デプロイメントを実行すると、変数が間違っているため、RHHI for Virtualization のデプロイメントに失敗します。

この問題を回避するには、以下を実行します。

  • /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/he_gluster_vars.json ファイルで、he_ansible_host_name: host1 を削除します。
  • /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/he_gluster_vars.json ファイルで、he_mem_size_MB 変数の値を 16384 に更新します。
BZ#1795928: Ansible ロールを使用した最初のデプロイメントに失敗する

自動デプロイメント中に、Web フックは gluster-eventsapi に正常に追加されますが、成功するのではなく、障害を報告します。これにより、デプロイメントに失敗します。

この問題を回避するには、以下の手順に従います。

  1. デプロイメントの試行をクリーンアップします。

    # ovirt-hosted-engine-cleanup -q
  2. フロントエンド FQDN(完全修飾ドメイン )に対応するホスト名を設定します。

    # hostnamectl set-hostname <Front-end-FQDN>
  3. ホストエンジンを再デプロイします。

    # ansible-playbook -i /root/gluster_inventory.yml /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/tasks/he_deployment.yml --extra-vars='@/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/he_gluster_vars.json'
BZ#1796035: Ansible ロールは Hosted Engine を実行するように追加のホストを設定しない

自動デプロイメント時に、Hosted Engine を実行するように最初のホストのみが設定されます。これにより、デプロイメントの可用性が低下します。

この問題を回避するには、それぞれの追加ホストで以下の手順を実行します。

  1. 追加のホストをメンテナンスに移動します。
  2. ホストを再インストールするため、HostedEngine=deploy を設定してください。
BZ#1754743: デプロイメント中に VDO ボリュームとの LV キャッシュの有効化に失敗する

VDO(Virtual Data Optimizer)が有効なシンプールデバイスに LV キャッシュが割り当てられている場合は、キャッシュデバイスのパスは、/dev/<device name> ではなく /dev/mapper/vdo_<device name > である必要があります

この問題を回避するには、生成された Ansible インベントリーファイルを編集します。

VDO が sdb から作成され、キャッシュディスクが sdc の場合は、設定は以下のようになります。

gluster_infra_cache_vars:
        - vgname: gluster_vg_sdb
          cachedisk: `/dev/mapper/vdo_sdb,/dev/sdc`
          cachelvname: cachelv_gluster_thinpool_gluster_vg_sdb
          cachethinpoolname: gluster_thinpool_gluster_vg_sdb
          cachelvsize: 1G
          cachemode: writethrough
BZ#1432326: ネットワークをホストに関連付けると、ネットワークの同期がなくなります。
Gluster ネットワークが Red Hat Gluster Storage ノードのネットワークインターフェースに関連付けられていると、Gluster ネットワークは同期されていない状態になります。この問題を回避するには、ノードに対応する Management タブをクリックし、Refresh Capabilities をクリックします。
BZ#1547674: デフォルトのスラブサイズが VDO ボリュームサイズに制限

VDO(Virtual Data Optimizer)ボリュームは、最大 8096 のスラブで構成されます。デフォルトのスラブサイズは 2GB で、VDO ボリュームを最大物理サイズ 16TB に制限し、サポートされる最大論理サイズは 160TB です。つまり、16TB を超える物理デバイスで VDO ボリュームを作成すると失敗します。

この問題を回避するには、VDO ボリュームの作成時に大きなスラブサイズを指定します。

BZ#1554241: キャッシュボリュームを手動で非対称設定にアタッチする必要がある

ブリックが非対称で設定され、論理キャッシュボリュームが設定されている場合、キャッシュボリュームは 1 つのブリックにのみ割り当てられます。これは、非対称ブリック設定の現在の実装はデバイスごとに個別のボリュームグループとシンプールを作成するためです。そのため、非対称ブリック設定にはデバイスごとにキャッシュボリュームが必要です。ただし、これにより多数のキャッシュデバイスが使用され、現在 Web コンソールを使用して設定することはできません。

この問題を回避するには、最初に非対称ブリックセットに適用されているキャッシュボリュームを削除します。

# lvconvert --uncache volume_group/logical_cache_volume

次に、「 論理ボリュームの設定」の手順に従い、論理ボリューム を手動で作成します。

BZ#1590264: Hosted Engine のデプロイメント後にストレージネットワークがダウンしている

RHHI for Virtualization の設定中に、Red Hat Gluster Storage を設定するには 2 つの異なるネットワークインターフェースが必要です。ストレージの設定が完了すると、ホストエンジンがデプロイされ、ホストは管理対象ホストとして Red Hat Virtualization に追加されます。ホストのデプロイメント時に、ストレージネットワークが変更され、BOOTPROTO=dhcp が削除されます。つまり、ストレージネットワークには IP アドレスは自動的に割り当てられず、ホストエンジンのデプロイ後には利用できません。

この問題を回避するには、ホストエンジンのデプロイが完了した後に、ストレージネットワークのネットワークインターフェース設定ファイルに BOOTPROTO=dhcp 行を追加します。

BZ#1567908: 再起動後にデバイスのマルチパスエントリーが表示される

vdsm サービスは、Red Hat Virtualization を最初にインストールした後に、さまざまな設定変更を行います。このような変更の 1 つにより、ローカルデバイスを含む、RHHI for Virtualization でデバイスのマルチパスエントリーが表示されます。これにより、RHHI for Virtualization のデプロイメントプロセスが完了する前に、更新または再起動されるホストで問題が発生します。

この問題を回避するには、すべてのデバイスをマルチパスブラックリストに追加します。

  1. 以下を /etc/multipath.conf に追加します。

    blacklist {
      devnode "*"
    }
  2. すべてのハイパーコンバージドホストを再起動します。
BZ#1609451: 再起動後にボリュームのステータスが誤って報告される

アップグレードや更新の一部としてノードが再起動すると、後続の gluster ボリュームステータス の実行では、関連する glusterfsd プロセスが想定どおりに実行されている場合でも、ブリックが実行されていないことを報告することがあります。

この問題を回避するには、ノードのアップグレード、更新、または再起動後に、ハイパーコンバージドノードで glusterd を再起動します。

BZ#1688269: IPv6 ホストが Red Hat Virtualization Manager に追加されない

IPv6 アドレスを使用して仮想化用に Red Hat ハイパーコンバージドインフラストラクチャーをデプロイする場合、2 つ目および 3 番目のハイパーコンバージドホストは、デプロイメントプロセス中にホストエンジンの仮想マシンによって自動的に管理されるように設定されません。

この問題を回避するには、デプロイメントが完了したら、2 番目のホストと 3 番目のホストを Red Hat Virtualization Manager に手動で追加します。ホストの 追加

BZ#1688239: IPv6 で Geo-replication セッションの作成に失敗する
gverify.sh スクリプトは geo-replication 時に使用され、データの同期前にセカンダリーボリュームをマウントできることを確認します。IPv6 を使用すると、チェックの一部として --xlator-option=transport.address-family=inet6 マウントオプションを使用しないため、スクリプトが失敗します。そのため、現時点では IPv6 アドレスで Geo レプリケーションを使用できません。
BZ#1688243: IPv6 デプロイメントに追加のマウントオプションが必要
IPv6 を使用するデプロイメントでは、追加のマウントオプションが正しく機能する必要があります。この問題を回避するには、Hosted Engine のデプロイメント中に xlator-option="transport.address-family=inet6"マウント オプション フィールドに追加します。
BZ#1690820: ボリュームを作成して、ホストフィールドに、FQDN ではなく IP アドレスを設定します。

ボリュームの作成 ボタンを使用して Web コンソールを使用して新規ボリュームを作成する場合、ホストの値は gluster peer リストから入力され、最初のホストは FQDN ではなく IP アドレスになります。ボリューム作成の一環として、この値は FQDN 検証プロセスに渡されます。これは、IP アドレスで失敗します。

この問題を回避するには、生成された変数ファイルを編集して、IP アドレスの代わりに FQDN を手動で挿入します。

BZ#1506680: 再インストール時にディスクプロパティーが正しく消去されない

インストーラーは、既存の論理ボリュームから何らかのメタデータをクリーンアップできません。つまり、ディスクを手動でクリアしない限り、ハイパーコンバージドホストの再インストールに失敗します。

この問題を回避するには、以下のコマンドを実行し、物理マシンに割り当てられたディスクからすべてのデータおよびメタデータを削除します。

警告

これらのコマンドにより、すべてのディスク上のデータおよびメタデータがすべて完全に削除されるため、これらのコマンドを実行する前に保持するデータをすべてバックアップしてください。

# pvremove /dev/* --force -y
# for disk in $(ls /dev/{sd*,nv*}); do wipefs -a -f $disk; done