第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に正常に追加されますが、成功するのではなく、障害を報告します。これにより、デプロイメントに失敗します。この問題を回避するには、以下の手順に従います。
デプロイメントの試行をクリーンアップします。
# ovirt-hosted-engine-cleanup -q
フロントエンド FQDN(完全修飾ドメイン
名)に対応するホスト名を設定します。# hostnamectl set-hostname <Front-end-FQDN>
ホストエンジンを再デプロイします。
# 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 を実行するように最初のホストのみが設定されます。これにより、デプロイメントの可用性が低下します。
この問題を回避するには、それぞれの追加ホストで以下の手順を実行します。
- 追加のホストをメンテナンスに移動します。
-
ホストを再インストールするため、
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 のデプロイメントプロセスが完了する前に、更新または再起動されるホストで問題が発生します。
この問題を回避するには、すべてのデバイスをマルチパスブラックリストに追加します。
以下を
/etc/multipath.confに追加します。blacklist { devnode "*" }- すべてのハイパーコンバージドホストを再起動します。
- 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