1.8 リリースノート

Red Hat Hyperconverged Infrastructure for Virtualization 1.8

リリースノートおよび既知の問題

概要

本書では、リリース時に Red Hat Hyperconverged Infrastructure for Virtualization 1.8 の既知の問題を説明し、以前のリリースからの主な変更点について説明します。

第1章 本リリースでは何が変更されましたか?

1.1. バージョン 1.8 の主な変更点

Red Hat Hyperconverged Infrastructure for Virtualization 1.8 と以前のバージョンとの間には、以下のような違いがありますのでご注意ください。

変更された動作

  • Red Hat Hyperconverged Infrastructure for Virtualization 1.8 および Red Hat Virtualization 4.4 は Red Hat Enterprise Linux 8 をベースにしています。Red Hat Enterprise Linux 8 の主な相違点は、『RHEL 8 の導入における検討事項』を参照してください。
  • クラスタのアップグレードでは、アップグレードの途中で容量不足に陥るリスクを軽減するため、glusterディスクに10%以上の空き容量が必要になりました。これは、Red Hat Hyperconverged Infrastructure for Virtualization 1.8 へのアップグレード後に利用できます。(BZ#1783750)
  • Webコンソールの「ホスト」タブと「追加のホスト」タブが統合され、従来は両方に表示されていた情報が新たに「ホスト」タブに表示されるようになりました。(BZ#1762804)
  • Readcache および readcachesize オプションは、Red Hat Enterprise Linux 8 ベースのオペレーティングシステムではサポートされていないため、VDO ボリュームから削除されました。(BZ#1808081)
  • Red Hat Virtualization のサポートに合わせて Quartz スケジューラが標準の Java スケジューラに変更されました。(BZ#1797487)

機能拡張

  • 管理者ポータルで、クラスタ内のすべてのホストをワンクリックでアップグレードできるようになりました。これは、Red Hat Hyperconverged Infrastructure for Virtualization 1.8 へのアップグレード後に利用できます。(BZ#1721366)
  • 新しい Red Hat Hyperconverged Infrastructure for Virtualization のデプロイメントでは、Network-Bound Disk Encryption (NBDE) を使用した、保存データの暗号化がサポートされるようになりました。(BZ#1821248, BZ#1781184)
  • IPv6ネットワークに対応しました。IPv4 アドレスと IPv6 アドレスの両方を備えた環境はサポートされません。(BZ#1721383)
  • 新しいロール、Playbook、インベントリの例が用意されており、以下のタスクを簡素化、自動化できます。

  • Webコンソールで、IPv4またはIPv6ベースのデプロイメントを選択するオプションを追加しました。(BZ#1688798)
  • レプリケーションモジュールのfsyncイーガーロック機能を使用するようになり、Red Hat Hyperconverged Infrastructure for Virtualization 1.8 で、サイズが 4k にほぼ等しいスモールブロックの書き込みの多いワークロードのパフォーマンスが 50% 以上向上しました。(BZ#1836164)
  • Webコンソールでマルチパスデバイスのブラックリスト化に対応しました。(BZ#1814120)
  • 新しいフェンシングポリシーskip_fencing_if_gluster_bricks_upおよびskip_fencing_if_gluster_quorum_not_metが追加され、デフォルトで有効になりました。(BZ#1775552)
  • Red Hat Hyperconverged Infrastructure for Virtualization は、ストレージドメインを作成する前に、Red Hat Gluster Storage の「performance.strict-o-direct」オプションが有効になっていることを確認するようになりました。(BZ#1807400)
  • Red Hat Gluster Storage のボリュームオプションは、管理者ポータ ルでボリューム名に「all」を使用してすべてのボリュームに設定できるようになりました。(BZ#1775586)
  • 読み取り専用のフィールドが Web コンソールのユーザーインターフェースに含まれなくなり、インターフェースがシンプルで読みやすくなりました。(BZ#1814553)

第2章 バグ修正

本セクションでは、バージョン 1.8 で修正された Red Hat Hyperconverged Infrastructure for Virtualization の以前のバージョンに影響する重要なバグについて説明します。

BZ#1688239: IPv6 ネットワークを使用した Geo-replication
以前のバージョンでは、geo レプリケーションを IPv6 アドレスで使用できませんでした。今回のリリースにより、gluster geo-replication に使用されるヘルパースクリプトはすべて IPV6 ホスト名(FQDN)と互換性があります。
BZ#1719140 - 仮想マシンの可用性
仮想化グループオプションが更新され、いずれかのホストの電源が切れたときに仮想マシンが利用できるようになります。
BZ#1792821: heal 後のスプリットブレイン
以前のバージョンでは、回復ソース(回復ターゲットではない)のみが利用できる場合に、ディレクトリー内のエントリーの回復がトリガーされる可能性がありました。これにより、レプリケーションの拡張属性がリセットされ、回復ターゲットが再び利用可能になったときに GFID スプリットブレイン状態が生じました。この問題を回避するには、レプリケートセット内のすべてのブリックが利用可能な場合にのみ、エントリーの回復がトリガーされます。
BZ#1721097 - VDO statistics
以前は、VDO ボリュームでは、Virtual Disk Optimization(VDO)の統計は利用できませんでした。今回のリリースでは、Virtual Disk Optimization(VDO)が VDO 統計ツールとは異なる出力を正しく処理し、Virtual Desktop および Servers Manager によるトレースバックを回避します。
BZ#1836164 - 書き込み負荷の多いワークロードのレプリケーション
レプリケーションモジュールの fsyncEager-lock 機能を使用することで、サイズが 4k 書き込みで約 4k 負荷の小さいブロックのパフォーマンスが改善され、Red Hat hyperconverged Infrastructure for Virtualization 1.8 で 50 パーセント以上改善します。
BZ#1821763 - VDO volumes および maxDiscardSize パラメーター
仮想ディスクの最適化(VDO)Ansible モジュールが maxDiscardSize パラメーターに対応し、デフォルトでこのパラメーターを設定します。その結果、このパラメーターで作成された VDO ボリュームが失敗しなくなりました。
BZ#1808081 - VDO ボリュームの読み取りおよび読み取りサイズ
仮想ディスク最適化(VDO)の readcache オプションおよび readcachesize オプションは、Red Hat Enterprise Linux 8 をベースとした VDO ボリュームではサポートされません。これには、Red Hat HashiCorp Infrastructure for Virtualization 1.8 が含まれています。このオプションが削除され、バージョン 1.8 で VDO ボリュームの作成が成功するようになりました。
BZ#1793398: Ansible を使用したデプロイメント
以前のバージョンでは、変数(he_ansible_host_name および he_mem_size_MB)の誤った値が原因で、コマンドラインインターフェースからデプロイメント Playbook の実行に失敗していました。変数の値が更新され、デプロイメント Playbook が正しく実行されるようになりました。
BZ#1809413: Activating glusterd service caused quorum loss
以前は、管理者ポータルからホストをアクティベートすると、glusterd サービスが再起動され、glusterd プロセス ID が変更されるとクォーラム(定足数)が失われていました。今回のリリースでは、ホストのアクティベーション時に glusterd サービスが起動および実行しても再起動されないため、glusterd プロセス ID は変更されず、クォーラムが失われることはありません。
BZ#1796035 - 管理者ポータルの追加ホスト
以前のバージョンでは、追加のホストは Administrator Portal のポストデプロイメントに自動的に追加されませんでした。今回のリリースで、gluster ansible ロールが更新され、追加のホストが自動的に管理者ポータルに追加されるようになりました。
BZ#1774900: 切断されたホストの検出
以前のバージョンでは、非接続ホストの検出には、sanlock タイムアウトの所要時間が長くなっていました。今回のリリースでは、gluster のソケットおよび rpc タイムアウトが改善され、sanlock タイムアウトが発生する前に検出されたホストが検出され、1 台のホストの再起動が他のホストで実行している仮想マシンに影響しなくなりました。
BZ#179592 8: Erroneous deployment failure message
コマンドラインインターフェースでデプロイメント Playbook を実行すると、Web フックが gluster-eventsapi に正常に追加されましたが、成功ではなく失敗を報告し、初回の試行時にデプロイメントが失敗する原因となっていました。これは修正され、デプロイメントが正しく機能するようになりました。
BZ#1715428 - ストレージドメインの作成
以前のバージョンでは、ストレージドメインは、追加のホストが指定された場合にのみ自動的に作成されていました。2 つの操作は論理的に関連していないため分離され、ストレージドメインは追加のホストが指定されているかどうかに関係なく作成されるようになりました。
BZ#1733413 - Incorrect volume type displayed
以前のバージョンでは、Web コンソールにはボリューム種別の選択に不要なドロップダウンメニューが含まれ、単一ノードデプロイメントの誤ったボリューム種別(複製)が表示されていました。メニューが削除され、正しいボリュームタイプ(分散)が表示されます。
BZ#1754743 - VDO ボリュームでのボリュームの失敗キャッシュ
以前は、仮想ディスクの最適化(VDO)とキャッシュボリュームの両方を使用するボリュームを設定すると、Web コンソールでデプロイメントが失敗しました。これは、基礎となるボリュームパスが「/dev/mapper/vdo_sdx」ではなく「/dev/sdx」形式で指定されていたためです。正しい形式で VDO ボリュームが指定され、デプロイメントに失敗しなくなりました。
BZ#1432326: ネットワークをホストに関連付けた後にネットワークと同期しなくなる
Gluster ネットワークが新しいノードのネットワークインターフェースに関連付けられていると、Gluster ネットワークは同期されていない状態になりました。これは、Red Hat hyperconverged Infrastructure for Virtualization 1.8 では発生しなくなりました。
BZ#1567908 - 再起動後に表示されるデバイスのマルチパスエントリー
vdsm サービスは、Red Hat Virtualization の初回インストール後にさまざまな設定変更を行います。このような変更の 1 つにより、ローカルデバイスなど、Red Hat hyperconverged Infrastructure for Virtualization でデバイスのマルチパスエントリーが表示されました。これにより、Red Hat hyperconverged Infrastructure for Virtualization のデプロイメントプロセスが完了する前に、更新されたか、または再起動されたホストで問題が発生していました。Red Hat Hyperconverged Infrastructure for Virtualization は、マルチパスデバイスをブラックリストに登録するオプションを提供するようになりました。これにより、RHHI for Virtualization でエントリーが使用されなくなりました。
BZ#1590264 - ホストエンジンのデプロイメント後にストレージネットワークダウン
Red Hat hyperconverged Infrastructure for Virtualization の設定時には、Red Hat Gluster Storage をセットアップするには、2 つの別々のネットワークインターフェースが必要です。ストレージの設定が完了すると、ホストエンジンがデプロイされ、ホストが管理対象ホストとしてエンジンに追加されます。以前のリリースでは、デプロイメント時に、ストレージネットワークが変更されて BOOTPROTO=dhcp を削除していました。つまり、ストレージネットワークには IP アドレスが自動的に割り当てられておらず、ホストエンジンのデプロイ後には利用できませんでした。この行はデプロイメント時に削除されず、ストレージネットワークは予想通りに利用可能です。
BZ#1609451: リブート後にボリュームのステータスが誤って報告される
アップグレードまたは更新の一部として再起動した際に、関連する glusterfsd プロセスが想定どおりに実行されている場合でも、gluster ボリュームステータス の後続の実行により、ブリックが実行されていないことが誤って報告されることがあります。このような状況では、状態が正しく報告されるようになりました。
BZ#1856629: Warning use device with format /dev/mapper/<WWID > seen with gluster devices enabled(gluster devices が有効な状態で警告によるデバイスの使用)
Web コンソールからボリュームを拡張する際に、デバイス名 /dev/sdx使用して day2 操作の一部として、ブラックリスト gluster device チェックボックスが有効になっている場合でも、/dev/mapper/<WWID> 形式のデバイス名 が表示されます。バージョン 1.8 では、この警告の注記を無視して、警告が有効ではないため、デプロイメントの次のステップに進むことを推奨します。バージョン 1.8 Batch Update 1 では、この問題が修正され、誤った警告が表示されなくなりました。

第3章 既知の問題

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

BZ#1851114 - エラーメッセージの デバイスパスがこのデバイスの有効な名前ではない

論理ボリューム(LV)名が python-blivet の制限である 55 文字を超えると、ValueError: gluster_thinpool_gluster_vg_<WWID> などのエラーメッセージが、vdsm.log ファイルおよび super vdsm.log ファイルに表示されます。

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

  1. ボリュームグループの名前(VG)の名前を変更します。

    # vgrename gluster_vg_<WWID> gluster_vg_<last-4-digit-WWID>
  2. シンプールの名前を変更します。

    # lvrename gluster_vg_<last-4-digit-WWID> gluster_thinpool_gluster_vg_<WWID> gluster_thinpool_gluster_vg_<last-4-digit-WWID>
BZ#1853995: ストレージドメインを更新すると、エラーダイアログボックスが表示される
ホストの置き換え時にプライマリー volfile を置き換えて管理ポータルからストレージドメインを更新するのに対し、ポータルには 操作をキャンセルしたダイアログボックス が表示されます。ただし、バックエンドでは値が更新されます。
BZ#1855945 - RHHI for Virtualization depolyment fails using multipath configuration and lvm cache

マルチパスデバイス名を持つ仮想化に対する RHHI のデプロイメント時に、ボリュームグループ(VG)と論理ボリューム(LV)が作成され、WWW が 128 文字よりも長くなった LV 名になります。これにより、LV キャッシュの作成に失敗します。

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

マルチパスデバイス名 ''/dev/mapper/<WWID>' で RHHI for Virtualization のデプロイメントを開始する場合は、VG と thinpool のサフィックスを、4 桁の WWID に置き換えます。

  1. Web コンソールからのデプロイメント時に、ブリックの /dev/mapper/<WWID> としてマルチパスデバイス名を 指定します。
  2. Next をクリックしてインベントリーファイルを生成します。
  3. SSH 経由でデプロイメントノードにログインします。
  4. LVM コンポーネントで & lt;WWID& gt; を検索します。

    # grep vg /etc/ansible/hc_wizard_inventory.yml
  5. すべての WWID の場合は、WWID を最後の 4 桁の WWID に置き換えます。

    # sed -i 's/<WWID>/<last-4-digit-WWID>/g' /etc/ansible/hc_wizard_inventory.yml
  6. Web コンソールからのデプロイメントを続行します。
BZ#1856577 - IPv6 環境で共有ストレージボリュームがマウントできない

IPv6 アドレスを使用して RHHI for Virtualization のデプロイメント時に gluster_shared_storage オプションを使用して gluster ボリュームを作成すると、fstab ファイルにマウントオプションが追加されません。その結果、共有ストレージはマウントに失敗します。

この問題を回避するには、fstab ファイルに xlator-option=transport.address-family=inet6 としてマウントオプションを追加 ます。

BZ#1856594: Web コンソールからの day2 操作で VDO が有効な gluster ボリュームの作成に失敗する

仮想ディスク最適化(VDO)が、Web コンソールで day2 操作のある gluster ボリュームが失敗する。

この問題を回避するには、/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/ vdo_create.yml の Playbook vdo_create.yml を変更し、以下のように ansible タスクを変更します。

- name: Restart all VDO volumes
  shell: "vdo stop -n {{item.name}} && vdo start -n {{item.name}}"
  with_items: "{{ gluster_infra_vdo }}"
BZ#1858197: ボリュームの自己回復待ち、ブリックの投稿がオンラインになる

デュアルネットワーク設定(gluster および ovirt 管理用)では、自動ファイルレプリケーション(AFR)ヒューラースレッドは、自己修復デーモンの再起動時に生成されず、ボリューム内の自己回復エントリーが保留されます。

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

  1. コマンドを使用してホスト名を他のネットワーク FQDN に変更します。

    # hostnamectl set-hostname <other-network-FQDN>
  2. コマンドを使用して回復を開始します。

    # gluster volume heal <volname>
BZ#1554241: キャッシュボリュームは、非対称ブリック設定に手動で接続する必要があります。

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

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

# lvconvert --uncache volume_group/logical_cache_volume

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

BZ#1690820 - host フィールドに IP アドレスが FQDN ではない状態でボリュームを設定する手順

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