3.4. 既知の問題

現在、ネットワークの設定を変更するとインターフェースが再起動して、オーバークラウドノード上のネットワーク接続が中断されるという既知の問題があります。そのため、ネットワークの中断によって、Pacemaker コントローラークラスター内でサービスが停止し、ノードがフェンシングされてしまいます (フェンシングが設定されている場合)。その結果、tripleo-heat-templates はオーバークラウドの更新時にネットワーク設定の変更を適用しないように設計されています。ネットワークの変更を適用しないことによって、意図せずにクラスターのサービスが停止してしまうことを避けます。

現在、特定の設定ステップでは、オーバークラウドコントローラーに SSH 接続する必要があり、オーバークラウドノードに到達するには、仮想 IP を通過する必要があります。
お使いの環境で外部のロードバランサーを使用している場合には、このステップで接続は成功しない可能性が高くなります。この問題を回避するには、外部のロードバランサーがポート 22 を転送するように設定すると、仮想 IP へ正常に SSH 接続できるようになります。

controller_v6.yaml テンプレートには、管理ネットワークの VLAN 用のパラメーターが 1 つ含まれています。このパラメーターは、現在のバージョンの director ではサポートされていないので、管理ネットワークに関する他のコメントとともに無視しても安全です。管理ネットワークの参照は、カスタムテンプレートにコピーする必要はありません。

このパラメーターは将来のバージョンでサポートされる予定です。

director はデプロイメントの前または実行中にネットワークの検証を提供しません。そのため、ネットワーク設定が適切でないデプロイメントが数時間実行されて、何も出力が表示されずに結果的に失敗する可能性があります。ネットワーク検証のスクリプトは現在開発中で、将来のリリースで実装される予定です。

今回のリリースでは、Red Hat OpenStack Platform director は、コントローラーノード 3 台で構成される高可用性 (HA) のオーバークラウドデプロイメントのみをサポートしています。

現在、director がパブリック API に接続して最終の設定のデプロイ後のステップを完了するのに必要となる既知の要件があります。この要件は、アンダークラウドノードにはパブリック API へのルートが 1 つあることと、そのルートが標準の OpenStack API ポートおよびポート 22 (SSH) で到達可能である必要があることです。
この要件に対応するには、デプロイ後のタスクで使用するコントローラー上の外部ネットワークにアンダークラウドが到達可能かをチェックしておいてください。このような準備をしておくことにより、アンダークラウドはデプロイ後にパブリック API に正常に接続して、最終の設定タスクを実行することができます。これらのタスクは、admin アカウントを使用して新規作成したデプロイメントを管理するのに必要です。

NovaEnableRbdBackend パラメーターを使用する場合には、一時ストレージが true としてハードコードされています。これは、NovaEnableRbdBackend インスタンスが Ceph Storage 上に cinder バックエンドを使用できないことを意味します。回避策として、以下の行を puppet/hieradata/compute.yaml に追加します。

nova::compute::rbd::ephemeral_storage: false

これで一時ストレージが無効になります。

openstack-cinder-volume が LVM バックエンドの使用時にオーバークラウドノードが再起動すると、ファイルベースのループバックデバイスは再度作成されません。回避策として、ループバックデバイスを手動で再作成します。

$ sudo losetup /dev/loop2 /var/lib/cinder/cinder-volumes

次に、openstack-cinder-volume を再起動します。openstack-cinder-volume はオーバークラウドコントローラーノードの高可用性クラスター内では、1 回に 1 つのノードでしか実行できません。ただし、ループバックデバイスは、全ノード上に存在します。

Red Hat OpenStack Platform director のデプロイ時には、bare-metal ノードの電源はオフにして、ironic で「node-state」と「provisioning-state」が正しい必要があります。
たとえば、ironic がノードを「Available, powered-on」で表示されていても、サーバーが実際には電源がオフの状態である場合には、そのノードはデプロイメントには使用できません。
そのため、ironic でのノードの状態と実際のノードの状態を一致させる必要があります。「ironic node-set-power-state <node> [on|off]」と「ironic node-set-provisioning-state <node> available」のいずれか一方または両方を使用して、ironic 内での電源状態がサーバーの実際の状態と一致するようにして、ノードが「Available」とマークされるようにします。
その結果、ironic でのノードの状態が正しくなった後には、ironic は電源状態を正しく管理して、ノードをデプロイできるようになります。

IBM x3550 M5 サーバーには、Red Hat OpenStack Platform で機能する最小限のバージョンのファームウェアが必要です。 
そのため、ファームウェアのレベルが古い場合には、デプロイメントの前にアップグレードする必要があります。影響を受けるシステムは、次のバージョン (またはそれ以降のバージョン) にアップグレードする必要があります。
DSA 10.1, IMM2 1.72, UEFI 1.10, Bootcode NA, Broadcom GigE 17.0.4.4a 

ファームウェアのアップグレード後には、デプロイメントは想定通りに進めることができるはずです。

puppet のマニフェストのバグが原因で、アンダークラウドのインストールプロセス中に LVM パーティションの自動マウントが誤って無効化されていました。その結果、root および swap 以外のパーティションを使用する (カーネルコマンドラインでアクティブ化された) アンダークラウドホストは、緊急シェルでしかブートできない可能性がありました。

この問題を回避するには、複数の方法があります。以下のいずれかを選択してください。

1. /etc/fstab からマウントポイントを手動で削除します。この方法は、今後いかなる場合においても問題が生じることを防ぐことができます。他のパーティションを削除して、別のパーティション (root または swap) にスペースを追加することも可能です。

2. アクティブ化するパーティションを /etc/lvm.conf で設定します。この方法は、次回の更新/アップグレードでアンダークラウドのインストールが再実行されるまで機能します。

3. 初回のデプロイメントを root と swap パーティションに限定します。この方法は、問題を完全に回避することができます。

Red Hat Ceph を永続ストレージ用バックエンドとして使用する場合には、Compute サービスは利用可能なストレージ容量を正しく計算しません。厳密に言うと、Compute がレプリケーションを考慮に入れず、単に利用可能なストレージを加算してしまいます。その結果、利用可能なストレージ容量は実際の容量を大幅に上回る値が提示され、予期しないストレージオーバーサブスクリプションが発生してしまう可能性があります。

一時ストレージの正しい容量を確認するには、代わりに Ceph サービスに対して直接クエリーを実行してください。

「tuned」プロファイルがアクティブ化された後には、「openvswitch」サービスよりも前に「tuned」サービスを起動して、PMD に割り当てられるコアが正しく設定されるようにする必要があります。

回避策として、以下のスクリプトを実行して 「tuned」サービスを変更することができます。

#!/bin/bash

tuned_service=/usr/lib/systemd/system/tuned.service

grep -q "network.target" $tuned_service
if [ "$?" -eq 0 ]; then
  sed -i '/After=.*/s/network.target//g' $tuned_service
fi

grep -q "Before=.*network.target" $tuned_service
if [ ! "$?" -eq 0 ]; then
  grep -q "Before=.*" $tuned_service
  if [ "$?" -eq 0 ]; then
    sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service
  else
    sed -i '/After/i Before=network.target openvswitch.service' $tuned_service
  fi
fi

systemctl daemon-reload
systemctl restart openvswitch
exit 0

現在、「Instance.pci_devices」フィールドでは NULL 値を指定可能ですが、「get_instance_pci_devs()」関数はその可能性を許可していません。旧デプロイメント (例: Red Hat OpenStack Platform 9) からインスタンスに渡される場合には「pci_devices」の値が指定されていないと、「None」をリストとして反復を試みてクラッシュします。
この問題の対象範囲には、アップグレードのワークフローの一環としてトリガーされるライブマイグレーションが含まれ、Red Hat OpenStack Platform 9 ホストから Red Hat OpenStack Platform 10 ホストにゲストのライブマイグレーションを試みます。
この問題を解決するためのパッチは特定済みで、Red Hat のお客様にはエラータとして リリースされる予定です。既存インスタンスをライブマイグレーションする方法でローリングアップグレードを予定しているお客様は、このエラータが提供されるまでアップグレードを見合わせることを推奨します。

Red Hat Enterprise Linux 6 には GRUB Legacy のみが含まれていますが、OpenStack Bare Metal Provisioning サービス (ironic) は GRUB2 のインストールのみをサポートしているため、ローカルブートでパーティションイメージをデプロイすると、ブートローダーのインストール中にエラーが発生します。
回避策としては、ベアメタルインスタンスに RHEL 6 を使用する場合には、フレーバーの設定で、boot_option を local に設定しないようにします。GRUB Legacy がインストール済みの RHEL 6 ディスクイメージ全体をデプロイすることも検討することができます。

Ceph と LVM 専用のブロックストレージノードを使用する Red Hat OpenStack 10 環境をデプロイ/アップグレードすると、ボリュームがアタッチされたインスタンスの作成は機能しなくなります。この問題は、director がアップグレード中に Block Storage サービスを設定する方法にバグがあることが原因です。 

具体的には、Heat テンプレートはデフォルトでは、Ceph と専用のブロックストレージノードを併せて設定するユースケースは考慮されていないため、director は一部の必要な設定の定義に失敗してしまいます。

LVM は、特にエンタープライズ環境の実稼働用の Block Storage バックエンドには適していない点に注意してください。

この問題は回避するには、以下の内容を記載した環境ファイルをアップグレードまたはデプロイメントに追加してください。

parameter_defaults:
  BlockStorageExtraConfig:
    tripleo::profile::base::cinder::volume::cinder_enable_iscsi_backend: true
    tripleo::profile::base::cinder::volume::cinder_enable_rbd_backend: false

オーバークラウドのイメージに、バージョン 2.7.1-4 未満の 「tuned」 が同梱されている場合には、「tuned」 パッケージの更新をそのオーバークラウドに手動で適用する必要があります。「tuned」バージョンが 2.7.1-4 以降の場合には、「tuned」にコアの一覧を提供してプロファイルをアクティブ化する必要があります。以下に例を示します。

# echo "isolated_cores=2,4,6,8,10,12,14,18,20,22,24,26,28,30" >> /etc/tuned/cpu-partitioning-variables.conf
# tuned-adm profile cpu-partitioning

以前のバージョン (Red Hat Ceph Storage 1.3) を使用する外部の Ceph Storage クラスターと統合された Red Hat OpenStack Platform 環境をアップグレードまたはデプロイする場合には、後方互換性を有効にする必要があります。そのためには、以下のスニペットを記載した環境ファイルをアップグレードまたはデプロイメントに追加します。

parameter_defaults:
  ExtraConfig:
    ceph::conf::args:
      client/rbd_default_features:
        value: "1"

ユーザー空間データパス (DPDK) を使用する場合には、一部の非 PMD スレッドは PMD を実行するのと同じ CPU 上で実行されます (「pmd-cpu-mask」で設定されます)。これは、PMD が割り込みされ、レイテンシースパイクやドロップなどが発生する原因となります。

今回の更新では post-install.yaml ファイルの修正が実装されました。このファイルは https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/single/network-functions-virtualization-configuration-guide/#ap-ovsdpdk-post-install に記載されています。

Ceph Storage ノードは、「ext4」でフォーマットされたローカルのファイルシステムを「ceph-osd」サービスのバックエンドとして使用していました。

注記: Red Hat OpenStack Platform 9 (Mitaka) の「overcloud-full」イメージの一部は「xfs」の代わりに「ext4」を使用して作成されていました。

Jewel リリースでは「ceph-osd」が、バックエンドで許可されているファイル名の最大長を確認して、Ceph 自体で設定されている上限よりも低い場合には拒否します。回避策として、Ceph Storage ノードにログインして以下のコマンドを実行すると、「ceph-osd」に使用中のファイルシステムを確認することができます。

  # df -l --output=fstype /var/lib/ceph/osd/ceph-$ID

ここで $ID は OSD ID です。以下に例を示します。

  # df -l --output=fstype /var/lib/ceph/osd/ceph-0

注記: 単一の Ceph Storage ノードは、複数の「ceph-osd」インスタンスをホストしている可能性があり、その場合には、複数のサブディレクトリーが各インスタンスの「/var/lib/ceph/osd/」に存在することになります。

OSD インスタンスの*いずれか*が「ext4」ファイルシステムでバッキングされている場合には、Ceph が短いファイル名を使用するように設定する必要があります。これは、以下の内容を記載した追加の環境ファイルをデプロイ/アップグレードすることによって設定することができます。

  parameter_defaults:
    ExtraConfig:
      ceph::profile::params::osd_max_object_name_len: 256
      ceph::profile::params::osd_max_object_namespace_len: 64

その結果、Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 へのアップグレード後に、各「ceph-osd」インスタンスが稼働しているかどうかを確認できるようになります。

Open vSwitch、仮想マシンの CPU または仮想マシン内の VNF スレッドの実行中に、割り当てられた CPU への割り込みをできるだけ少なくするためには、CPU を分離すべきです。ただし、CPUAffinity は、全カーネルスレッドがこれらの CPU 上で実行されないようにすることはできません。大半のカーネルスレッドを防ぐには、ブートオプション 'isolcpus=<cpulist>' を使用する必要があります。これには 'nohz_full' および 'rcu_nocbs' と同じ CPU リストが使用されます。'isolcpus' はカーネルブート時に使用され、多数のカーネルスレッドが CPU 上でスケジュールされるのを防ぐことができます。これは、ハイパーバイザーとゲストサーバーの両方で実行することが可能です。

#!/bin/bash
isol_cpus=`awk '{ for (i = 1; i <= NF; i++) if ($i ~ /nohz/) print $i };'
/proc/cmdline | cut -d"=" -f2`
 
if [ ! -z "$isol_cpus" ]; then
  grubby --update-kernel=grubby --default-kernel --args=isolcpus=$isol_cpus
fi


2) 以下のスニペットは、エミュレータースレッドのアクションを再度固定するので、パフォーマンス上の特定の問題が発生した場合以外は使用することをお勧めしません。 

#!/bin/bash
cpu_list=`grep -e "^CPUAffinity=.*" /etc/systemd/system.conf | sed -e 's/CPUAffinity=//' -e 's/ /,/'`
 if [ ! -z "$cpu_list" ]; then
   virsh_list=`virsh list| sed -e '1,2d' -e 's/\s\+/ /g' | awk -F" " '{print $2}'`
     if [ ! -z "$virsh_list" ]; then
       for vm in $virsh_list; do virsh emulatorpin $vm --cpulist $cpu_list; done
     fi
 fi

「openstack baremetal import --json instackenv.json」を使用してインポートしたノードは、インポートを試みる前に電源をオフにする必要があります。ノードの電源がオンの場合には、Ironic はノードの追加やイントロスペクションを試みません。
この回避策として、「openstack baremetal import --json instackenv.json」を実行する前に全オーバークラウドノードの電源をオフにすることができます。
その結果、ノードの電源がオフになっている場合にはインポートが正常に機能するはずです。

DHCP HA を使用する場合には、コンポーザブルロールを使用して、「NeutronDhcpAgentsPerNetwork」の値を  dhcp-agent 数に等しい値または 3 のいずれか低い方に設定すべきです。このように設定しなかった場合には、この値はデフォルトで「ControllerCount」に設定され、各ネットワークで多数の DHCP サーバーの起動に対応するために dhcp-agent 数が十分でない場合があるために最適ではありません。

「AllocationPools」IPv6 ネットワークおよび IP の割り当てプールに入力するアドレス範囲は、RFC 5952 に従って有効な形式で入力する必要があります。エントリーが不完全だと機能せず、無効なエントリーによりエラーが発生します。
そのため、IPv6 アドレスは有効な形式で入力する必要があります。ゼロが繰り返される場合には「::」に置き換えることができます。
たとえば、「fd00:0001:0000:0000:00a1:00b2:00c3:0010」という IP アドレスは、「fd00:1::a1:b2:c3:10」と示すことができますが、「fd00:01::0b2:0c3:10」には無効な先頭ゼロ (01, 0b2, 0c3) が含まれているので使用できません。このフィールドでは、先頭のゼロを切り捨てるか、完全に埋め込む必要があります。

Glance で、glance.store.http.Store は、/etc/glance/glance.conf に known_store として設定されていないため、Glance クライアントで --copy-from 引数を使用してイメージを作成することはできません。このコマンドを実行すると、「400 Bad Request」エラーが表示されて操作が失敗します。回避策として、/etc/glance/glance-api.conf を編集して、「store」設定オプションのリストに glance.store.http.Store を追加してから、openstack-glance-api サーバーを再起動します。これにより、--copy-from 引数を使用した Glance イメージの作成を正常に実行できるようになります。

「openstack overcloud update stack」コマンドは、背後で操作が継続するにもかかわらず、即時に出力を返していました。このコマンドは対話的でないため、永遠に実行されるように見えました。そのような場合には、「-i」のフラグを付けてコマンドを実行すると、手動での対話が必要な場合にユーザーにプロンプトが表示されるようになります。

タイミングの問題により、オーバークラウドの neutron サービスは正しく自動起動しません。これは、インスタンスがアクセスできないことを意味します。回避策として、コントローラーノードクラスターで以下のコマンドを実行することができます。

$ sudo pcs resource debug-start neutron-l3-agent

これでインスタンスが適切に起動するようになります。