1.7 リリースノート

Red Hat Hyperconverged Infrastructure for Virtualization 1.7

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

概要

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

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

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

第1章 本リリースではどのような変更がありますか?

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

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.8
4 KB ブロックサイズのサポート
Gluster ボリュームでホストされるストレージドメインは、ブロックサイズが 4 KB のディスクをサポートするようになりました。
VDO デバイスの 4 KB ブロックサイズ

以前は、VDO デバイスはデフォルトで 512 バイトのブロックサイズをエミュレートしていました。Red Hat Hyperconverged Inrastructure for Virtualization 1.7 の時点で、新規に作成された VDO デバイスはブロックサイズ 4 KB を使用します。

重要

同じ Gluster ボリュームのブリックのブロックサイズは同じでなければなりません。ブロックサイズ 512 バイトの VDO ボリュームと、4 KB の新しい VDO ボリュームの両方に、Gluster ボリュームのブリックを配置しないでください。

自動デプロイ時のボリューム作成用のノードを指定する
以前のバージョンの自動デプロイメントでは、ボリュームはすべてのノードに作成されていました。3 つのノードを超えるデプロイメントでは、自動デプロイメント時にボリュームをデプロイするノードを指定できるようになりました。

1.2. テクノロジープレビュー

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

このセクションに一覧表示される機能は、テクノロジープレビューのサポート制限下で提供されます。

IPv6 ネットワーキングサポート

IPv6 のみの環境の IPv6 アドレスでは、テクノロジープレビューのサポートが利用できるようになりました(DNS およびゲートウェイアドレスを含む)。このテクノロジープレビューの IPv6 サポートには、いくつかの重要な制限があります。

  • geo レプリケーションを使用した障害復旧はサポートされません(BZ#1688239)。
  • IPv6 ホストが提供するストレージをマウントする際に追加のマウントオプションが必要です( xlator-option=transport.address-family=inet6 (BZ#1688243)。
  • RHV 管理ポータルにホストを自動的に追加することはできません(BZ#1688269)

第2章 バグ修正

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

BZ#1670722 - 再起動後に gluster マウントを壊すとデバイス名を変更
Gluster ブリックは、以前はデバイス名を使用してマウントされていました。このデバイス名はシステムの再起動後に変更される可能性があります。これにより、ブリックが利用できなくなります。ブリックはデバイス名ではなく UUID を使用してマウントされ、問題を回避できるようになりました。
BZ#1723730: VDO に必要な 512 バイトエミュレーション
以前は、4KB ブロックデバイスが完全にサポートされる前に、Virtual Disk Optimizer デバイスが 512 バイトエミュレーションを使用する必要がありました。このエミュレーションは必要なくなり、4KB ブロックデバイスのサポートを利用できるようになりました。
BZ#1780290: シャーディングが有効にされた非稼働ホスト
シャーディングが有効になり、ファイルのパスがリンクされていないものの、記述子が依然として利用可能であった場合でも、ファイルに対する読み取りまたは書き込み操作の実行を試みると、ホストが機能しなくなります。これでファイルパスはリンクされず、この問題を回避しています。

第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