第3章 リリースの情報

Red Hat OpenStack Platform の今回のリリースでは、以下の機能拡張が提供されています。

Swift のオブジェクトは、ディスク上にクリアテキストとして保管されます。このようなディスクは、ライフサイクル終了に達した時に適切に破棄しなければ、セキュリティーリスクをもたらす可能性があります。このリスクは、オブジェクトを暗号化することによって軽減されます。

Swift はこれらの暗号化タスクを透過的に実行し、オブジェクトは swift にアップロードされる際には自動的に暗号化され、ユーザーに提供される際には自動的に復号化されます。この暗号化と復号化は、Barbican に保管されている同じ (対称) キーを使用して処理されます。

collectd コンポーザブルサービス向けに以下の新しいパラメーターが追加されました。CollectdGnocchiAuthMode が simple に設定されると、CollectdGnocchiProtocol、CollectdGnocchiServer、CollectdGnocchiPort、CollectdGnocchiUser が設定に取り入れられます。

CollectdGnocchiAuthMode が keystone に設定されている場合には、CollectdGnocchiKeystone* パラメーターが設定に取り入れられます。

追加されたパラメーターに関する詳しい説明は以下のとおりです。

本セクションに記載する項目は、テクノロジープレビューとして提供しています。テクノロジープレビューステータスのスコープに関する詳細情報およびそれに伴うサポートへの影響については、テクノロジープレビュー機能のサポート範囲 を参照してください。

required(必須)、legacy(デフォルト。利用可能な場合には必須)、preferred(あると良い)

いずれの場合も、可能であれば、厳格な NUMA アフィニティーが提供されます。これらのポリシーにより、リソースの使用率を最大化するために、PCI エイリアスごとの NUMA アフィニティーをどの程度厳格にするかを設定できるようになります。これらのポリシー間の主要な相違点は、どれだけの NUMA アフィニティーを破棄するとスケジューリングが失敗するかという点です。

PCI デバイスに preferred ポリシーを設定した場合、PCI デバイスの NUMA ノードとは異なる NUMA ノードが利用できれば、nova はそのノード上の CPU を使用します。これにより、リソースの使用率が高くなりますが、それらのインスタンスのパフォーマンスは低減します。

本項では、Red Hat OpenStack Platform の注目すべき変更点や推奨プラクティスなど、今回のリリースに関する重要な情報を記載しています。お使いのデプロイメントに最大限の効果をもたらすために、以下の情報を考慮する必要があります。

その結果、Shared File System サービスは、NetApp IPv6 ネットワーク上で ONTAP バックエンドによってバッキングされる共有のエクスポートをサポートします。エクスポートされた共有へのアクセスは、IPv6 クライアントのアドレスによって制御されます。

# ip netns exec qrouter...
RTNETLINK answers: Invalid argument

ネットワーク名前空間内でコマンドを実行するには、その名前空間を作成した neutron コンテナーから操作を行う必要があります。たとえば、l3-agent からルーター用のネットワーク名前空間を作成した場合には、コマンドを以下のように変更します。

# docker exec neutron_l3_agent ip netns exec qrouter...

同様に、qdhcp で始まるネットワーク名前空間の場合には、neutron_dhcp コンテナーからコマンドを実行してください。

GA リリース版の tripleo では、デフォルトではこの拡張機能が設定されない点に注意してください。BZ#1577592 で回避策を参照してください。

parameter_defaults: NovaReservedHostMemory: 2048

デフォルトのネットワーク名を変更するには、カスタムのコンポーザブルネットワークファイル (network_data.yaml) を使用して、openstack overcloud deploy コマンドに-n オプションを指定してそのファイルを追加してください。このファイルで、name_lower フィールドに変更するネットワークのカスタム net 名を指定します。詳しい情報は、オーバークラウドの高度なカスタマイズのカスタムコンポーザブルネットワークを参照してください。

また、ServiceNetMap テーブルのローカルパラメーターを network_environment.yaml に追加して、古いネットワーク名のデフォルト値を新しいカスタム名でオーバーライドする必要があります。デフォルト値は /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml にあります。この ServiceNetMap の変更は、今後の OSP-13 リリースでは必要なくなります。

その結果、metadata-agent が新しいメタデータ名前空間をプロビジョニングせず、クラスターが想定通りに動作しないため、仮想マシンの起動が機能しない場合があります。

回避策としては、新しいコントローラーが OVN データベース向けにマスターとして昇格した後に、全コンピュートノードで ovn_metadata_agent コンテナーを再起動する方法を使用することができます。また、plugin.ini で ovsdb_probe_interval の値を 600000 ミリ秒に増やしてください。

この問題には、次のような症状があります。いずれかの OpenStack サービスのログで DuplicateMessageError: Found duplicate message(629ff0024219488499b0fac0cacaa3a5). Skipping it.の形式のエントリーが表示される。openstack network agent list で一部のエージェントが DOWN と返される。

通常の操作ができる状態に戻すには、いずれかのコントローラーノードでコマンド pcs resource restart rabbitmq-bundle を実行します (1 台のコントローラーでのみ実行する必要があります)。

現時点における Red Hat OpenStack Platform の既知の問題は以下のとおりです。

この問題を回避するには、OS::TripleO::Services::NeutronDhcpAgent を以下のように変更してください。

OS::TripleO::Services::NeutronDhcpAgent: docker/services/neutron-dhcp.yaml

従って、director のアンダークラウドのバックアップと復元は Red Hat OpenStack Platform 13 の一般提供リリースでは提供されません。この手順の更新は、一般提供リリースの後に優先され、確認が済み次第公開される予定です。

失われた FIB テーブルのエントリーが原因で、仮想マシンはパブリックネットワークへの接続を失います。

Floating IP を仮想マシンに割り当てると、パブリックネットワークへの接続が復元されます。その Floating IP が仮想マシンに割り当てられている限りは、インターネットへの接続が可能です。ただし、外部ネットワークからのパブリック IP/Floating IP を失います。

デプロイメントが合格した場合、そのデプロイメントが正常に実行されるには、3 つの OpenDaylight インスタンス中 2 つが機能している必要があります。3 つ目の OpenDaylight インスタンスが正しく起動されていない可能性があります。docker ps コマンドで、各コンテナーの正常性ステータスを確認していださい。正常でない場合には、docker restart opendaylight_api でそのコンテナーを再起動します。

デプロイメントが失敗した場合の唯一のオプションは、そのデプロイメントを再起動することです。TLS ベースのデプロイメントの場合には、OpenDaylight の全インスタンスが正しく起動しないと、デプロイメントは失敗します。

この問題を回避するには、オーバークラウドがまだ OSP 10 の間に、オーバークラウドの最後のマイナーバージョン更新を実行する準備が整った時点で次の手順を実行します。1. テンプレートファイル /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration.yaml を編集します。2. そのテンプレートから RHELUnregistration および RHELUnregistrationDeployment のリソースを削除します。3. マイナー更新と Fast Forward Upgrade の手順を続行します。

このような場合には、次のアクションを実行すべきです。問題の発生したノードを再起動する。REST エンドポイントをモニターリングして、クラスターメンバーの正常性を確認する (http://$ODL_IP:8081/jolokia/read/org.opendaylight.controller:Category=ShardManager,name=shard-manager-config,type=DistributedConfigDatastore)。応答には、SyncStatus のフィールドが含まれるはずで、値が true の場合には、クラスターメンバーが正常であることを示します。

それらの仮想マシン間の ARP パケット送信は失敗するため、2 つの仮想マシン間には実質的にネットワークがないことになります。

manila-share サービスを初期化できるようにするには、以下の手順を実行してください。

1) オーバークラウドのデプロイに使用する /usr/share/openstack/tripleo-heat-templates のコピーを作成します。

2) …​/tripleo-heat-templates/docker/services/ceph-ansible/ceph-base.yaml ファイルを編集して、295 行目の 3 つ並んだバックスラッシュをすべて 1 つのバックスラッシュに変更します。

編集前:

mon_cap: 'allow r, allow command \\\"auth del\\\", allow command \\\"auth caps\\\", allow command \\\"auth get\\\", allow command \\\"auth get-or-create\\\"'

編集後:

mon_cap: 'allow r, allow command \"auth del\", allow command \"auth caps\", allow command \"auth get\", allow command \"auth get-or-create\"'

3) tripleo-heat-templates のコピーのパスを元の overcloud-deploy コマンドで実行した /usr/share/openstack-tripleo-heat テンプレートの場所に置き換えて、オーバークラウドをデプロイします。

ceph キーの /etc/ceph/ceph.client.manila.keyring ファイルには適切な内容が記載されるようになり、manila-share サービスは正常に初期化されるようになります。

モニターの警告の閾値は、1 OSD あたり 300 から 200 PG に削減されています。200 は、一般的な推奨目標値である 1 OSD あたり 100 PG の 2 倍です。この上限は、モニター上の mon_max_pg_per_osd オプションで調整することができます。以前の mon_pg_warn_max_per_osd オプションは削除されています。

プールの消費する PG の量を少なくすることはできません。アップグレードにより既存のデプロイメントが上限に達した場合には、ceph-upgrade のステップを実行中に上限をアップグレード前の値に増やすことができます。環境ファイルで、以下のようなパラメーター設定を追加します。

parameter_defaults:
  CephConfigOverrides:
    mon_max_pg_per_osd: 300

この設定は ceph.conf に適用されて、クラスターは HEALTH_OK の状態を維持します。

オーバークラウドの外部ネットワーク用の NIC テンプレートでは、常に OVS ブリッジを使用してください。このブリッジは、director ではデフォルトで br-ex という名前です (任意の名前を使用可)。外部ネットワークに使用する物理ホストのインターフェイスをこの OVS ブリッジに接続する必要があります。

OVS ブリッジに接続したインターフェイスを使用すると、デプロイメントは正しく機能し、外部ネットワークからテナントにトラフィックが通過できるようになります。

問題が発生すると、neutron サーバーは OVN North および South DB サーバーに接続できなくなり、neutron サーバーに対する Create/Update/Delete API はすべて失敗します。

この問題は、ovn-dbs-bundle リソースを再起動すると解決します。以下のコマンドを、いずれかのコントローラーノードで実行してください。

pcs resource restart ovn-dbs-bundle

SNAT トラフィックが流れるようにするには、VXLAN トンネルを適切に設定する必要があります。VLAN テナントネットワークを使用する場合は、次のいずれかの方法で MTU を設定して、SNAT トラフィックが VXLAN トンネルを流れるようにしてください。VLAN テナントベースのネットワークを、ネットワーク設定 1 つにつき 1450 の MTU を使用するように設定する。NeutronGlobalPhysnetMtu heat パラメーターを 1450 に設定する。注記: これは、すべての flat/VLAN プロバイダーネットワークが 1450 MTU となることを意味し、望ましい設定ではありません (外部プロバイダーネットワークは特に)。テナントネットワークの下層は、MTU を 1550 (またはそれ以上) に設定します。これには、テナントネットワーク用の NIC の NIC テンプレートで MTU を設定する操作が含まれます。

Red Hat OpenStack Platform 13 に含まれる HAProxy は 1.6 より古いバージョンで、PING タイプのヘルスモニターを設定すると TCP 接続が使用されます。

そのようなテストは省略するか、nova の設定にそれらのフィルターを追加する必要があります。

回避策としては、以下のようにアンダークラウドデプロイメント用に更にテンプレートを追加することによって、コントロールプレーンネットワークで snmpd サブネットを手動で設定する必要があります。

parameter_defaults: SnmpdIpSubnet: 192.168.24.0/24

回避策としては、以下のようにアンダークラウドデプロイメント用に更にテンプレートを追加することによって、コントロールプレーンネットワークで snmpd サブネットを手動で設定する必要があります。

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

このため、Error response from daemon: No such container: ceph-create-keys.というメッセージが表示されてデプロイメントが失敗する場合があります。 この失敗が、ceph-ansible の実行に影響を及ぼす場合があります。これには、複数のコンピュートノードを使用している、または Ceph クライアントとして動作し Ceph を使用するサービスをホスティングするカスタムロールを使用している新規デプロイメントが含まれます。

この問題を回避するには、デフォルトの PG 数を 32 に設定しておき、デプロイメントの終了時には、Storage Strategies Guide の Set the Number of PGs に記載の手順で PG 数を増やします。

ゲストを削除した後には、nova-compute サービスを再起動する必要があります。ゲストを削除した後にこのサービスを再起動すると、利用可能な SR-IOV デバイスの一覧が正しくなります。

以下の回避策のいずれかを使用することができます。

オプション A: Pacemaker によって管理されているコンテナーがあるノード上の /etc/sysconfig/docker ファイルを手動で更新して、新たに導入された非セキュアなレジストリーを追加します。

オプション B: アップグレードの直前に openstack overcloud deploy コマンドを実行して、環境ファイルの DockerInsecureRegistryAddress パラメーターで必要な新しい非セキュアなレジストリーを指定します。

これで、アップグレード中にすべてのコンテナーイメージが正常にダウンロードされるようになるはずです。

回避策としては、全コントローラーノードでファイアウォールルールを追加して、それらが DROP ルールの前に挿入されるようにする方法があります。

IPv4:
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT

IPv6:
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

HAProxy を再起動します。

  # docker restart haproxy-bundle-docker-0

Unexpected API Error. Table 'nova_cell0.instances' doesn't exist

このエラーは、以下のコマンドを実行すると解決することができます。

$ sudo nova-manage api_db sync

この問題はクリティカルではないので、Fast forward Upgrade プロセスを大きく妨げることにはならないはずです。