VMware Integrated OpenStack 7.0 リリース ノート

VMware Integrated OpenStack 7.0 | 2020 年 6 月 4 日 | ビルド 16227912 リリース ノートに追加または更新された内容をご確認ください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

• VMware Integrated OpenStack について
• 新機能
• インストールとアップグレード
• 互換性
• 非推奨に関する通知
• 利用可能な言語
• VMware Integrated OpenStack 用オープン ソース コンポーネント
• 既知の問題

VMware Integrated OpenStack について

VMware Integrated OpenStack は、統合プロセスを効率化することで、OpenStack クラウド インフラストラクチャのデプロイを大幅に簡略化します。VMware Integrated OpenStack には事前設定なしですぐに使用できる OpenStack 機能と、vCenter Server で仮想アプライアンスとして稼動するデプロイ マネージャの vApp を介した簡単な構成ワークフローが備わっています。

新機能

• OpenStack Train：VMware Integrated OpenStack 7.0 は、OpenStack の Train リリースに基づいています。
• 最新バージョンの VMware 製品のサポート：VMware Integrated OpenStack 7.0 は、VMware vSphere 7.0 および NSX-T Data Center 3.0 をサポートし、これらと完全な互換性があります。
• OpenStack 機能：
  • Nova サーバ インスタンスで vCPU の選択的な固定がサポートされています。vCPU のサブセットを物理 CPU コアに固定することができます。この機能には vSphere 7.0 以降が必要です。
  • ネットワーク接続の HA で SR-IOV NIC の冗長性をサポートしたことで、別の物理 NIC から vNIC プロビジョニングをスケジュール設定できるようになりました。 
  • Neutron Trunk サービスのサポートにより、単一の仮想 NIC (vNIC) を使用して複数のネットワークを 1 つのインスタンスに接続できるようになりました。インスタンスを 1 つのポートに接続することで、複数のネットワークをインスタンスに提供できます。トランク サービスの使用方法については、OpenStack コミュニティのドキュメントを参照してください。この機能を利用するには、Neutron Policy Plugin が必要です。 
  • Octavia LBaaS のサポート。OpenStack Octavia プロジェクトはこのリリースに統合されています。
  • IPv6 メンバーを含む Octavia LBaaS での IPv6 のサポート。この機能を使用するには NSX-T 3.0 以降と Neutron Policy Plugin が必要です。
  • 外部ネットワークとしての NSX-T vRF Lite のサポート。この機能を使用するには NSX-T 3.0 以降と Neutron Policy Plugin が必要です。
  • Distributed Switch 7.0 での NSX-T のサポート。これには、vSphere 7.0 以降と NSX-T 3.0 以降が必要です。展開の推奨事項と既知の制限について理解するには、NSX-T 3.0 リリースノートの「新機能」セクションを参照してください。
• 制御プレーンの強化：
  • パッチ管理：Blue/Green のアップグレード手順を必要としない組み込みのパッチ適用機能
  • パブリック API：VMware Integrated OpenStack 7.0 の展開を管理する API
  • Python 3：VMware Integrated OpenStack 7.0 はすべて Python 3 で記述されるようになりました。
  • コマンドライン：viocli コマンドライン ユーティリティの強化
  • 安定性とパフォーマンスの向上
• ライセンス モデル： 
  • VIO 7.0 では、Data Center Edition が Carrier Edition に統合されています。Carrier Edition は購入可能で、すべての機能が含まれています。Data Center Edition を購入することはできなくなりました。VIO 7.0 へのアップグレードに影響はありません。詳細については、ナレッジベースの記事 KB79285 を参照してください。

インストールとアップグレード

• インストール：
  • VIO 7.0 の新しい展開では、Neutron プラグイン、Distributed Switch、および NSX-T Policy API のみがサポートされます。
• アップグレード：
  • VIO でサポートされるアップグレード パス：
    • VIO 5.1 から VIO 7.0 へアップグレード
    • VIO 6.0 から VIO 7.0 へアップグレード
  • アップグレード パスでは、NSX-V および NSX-T 管理プラグインに加え、Neutron プラグインがサポートされます
  • アップグレード前に「既知の問題」セクションを確認し、製品ドキュメントで詳細なアップグレード手順を確認してください。

互換性

• VMware Integrated OpenStack と他のすべての VMware 製品との互換性については、VMware 製品の相互運用性マトリックスを参照してください。

非推奨に関する通知 

• このリリースでは、Neutron LBaaS は非推奨になり、OpenStack Octavia プロジェクトに置き換えられました。
• このリリースでは、Neutron FWaaS v1 は非推奨になり、FWaaS v2 に置き換えられました。
• 次のネットワーク機能は廃止されています。以降のバージョンでは削除される予定です。
  • Neutron 用の NSX Data Center for vSphere ドライバ。
  • Neutron 用の NSX-T 管理プラグイン。今後は、NSX-T Policy Plugin が使用されます。
  • TVD プラグイン。単一の VMware Integrated OpenStack デプロイで、NSX Data Center for vSphere バックエンドと NSX-T Data Center バックエンドを使用できます。

利用可能な言語

VMware Integrated OpenStack 7.0 は英語、および簡体字中国語、繁体字中国語、日本語、韓国語、フランス語、ドイツ語、スペイン語の 7 つの追加言語でご利用になれます。

次の項目には ASCII 文字のみを含める必要があります。

• OpenStack リソース（プロジェクト、ユーザー、イメージなど）の名前
• インフラストラクチャ コンポーネント（ESXi ホスト、ポート グループ、データセンター、データストアなど）の名前
• LDAP および Active Directory の属性 

VMware Integrated OpenStack 用オープン ソース コンポーネント

VMware Integrated OpenStack 7.0 ベータ版で配布されるオープン ソース ソフトウェア コンポーネントに適用される著作権情報とライセンスは、製品ダウンロード ページの [オープン ソース] タブで確認できます。VMware Integrated OpenStack のコンポーネントの公開パッケージをダウンロードすることもできます。これらのコンポーネントは GPL、LGPL、または他の同様なライセンスで管理されており、ライセンスに沿ってソース コードまたはソース コードの変更内容を公開する必要があります。

既知の問題

既知の問題には、次のトピックが含まれます。

アップグレード

アップグレードの実行前に、次の問題を考慮する必要があります。

• 複数の操作を同時に実行すると Neutron サービスが ToozConnectionError を報告する

  NSX-V プラグインを使用して VMware Integrated OpenStack 5.x から 7.0 にアップグレードした後、ネットワーク関連の操作を実行すると、特に複数の操作が同時に実行されている期間に、Neutron サービスが ToozConnectionError を報告します。

  回避策：この問題を回避するには、VMware Integrated OpenStack のユーザー インターフェイスで、Neutron サービスのレプリカを 1 に設定します。アップグレード前にこの問題を回避するには、「新しい VMware Integrated OpenStack デプロイへの移行」の説明に従って VIO Manager とコントローラ ノードのサイズを中規模から大規模に変更してください。

• バージョン 5.x で作成したファイアウォールが VMware Integrated OpenStack 7.0 への直接アップグレード後に表示されない

  VMware Integrated OpenStack 5.x は FWaaS v1 を使用します。VMware Integrated OpenStack 7.0 は FWaaS v2 を使用します。

  回避策：バージョン 5.x を使用して作成したファイアウォールをバージョン 7.0 に移行するには、VMware Integrated OpenStack バージョン 6.0 にアップグレードし、FWaaS v1 から FWaaS v2 への移行を手動で実行してから、バージョン 7.0 にアップグレードします。

• VIO 5.x から 7.0 へのアップグレード後、Horizon の操作でログイン画面に繰り返しリダイレクトされる

  アップグレード後、Horizon ポッドまたは Ingress ポッドで次のような問題が発生することがあります。ポッドを再作成すると、機能は通常の状態に復元されます。

  回避策：次の手順を実行して、Horizon ポッドまたは Ingress ポッドを再作成します。

  1. 管理仮想マシンに SSH 接続します。
  2. Horizon ポッドを再作成するには、次のコマンドを使用します。
     kubectl get pods -n openstack|grep horizon-server| awk '{print $1}'|xargs kubectl -n openstack delete pod 
  3. Ingress ポッドを再作成するには、次のコマンドを使用します。
     kubectl get pods -n openstack|grep '^ingress' | awk '{print $1}'|xargs kubectl -n openstack delete pod
• コンピューティング クラスタを含まない vCenter Server インスタンスは、アップグレード中に保持されない

  VMware Integrated OpenStack 5.1 デプロイに vCenter Server インスタンスが含まれていて、そのインスタンスからデプロイに追加されたコンピューティング ノードがない場合、VMware Integrated OpenStack 7.0 にアップグレード後、vCenter Server インスタンスに関するこれらの設定は保持されません。

  回避策：アップグレードの終了後に、目的の vCenter Server インスタンスを VMware Integrated OpenStack 7.0 デプロイに追加します。

• ロード バランサを Neutron-LBaaS から Octavia に移行すると、メンバーのないロード バランサが表示されない

  メンバーのないロード バランサは使用されないため、移行されません。バックエンドの実装がないため、Neutron データベースの同期中に表示されなくなります。

  回避策：移行前に、使用されていないロード バランサを削除します。

• VIO 5.1.0.4 からのアップグレード後も、古い Nova サービスが存在している

  VIO 5.1.0.4 から 7.0 へのアップグレード後に、レガシー Nova サービスが「down」になっています。

  [root@vioadmin1-vioshim-5dbf477dc4-2lh7s ~]# nova service-list

  +--------------------------------------------------------------------------- | Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | Forced down |+-------------------------------------------------------------------------- | cbe3345a-4daa-41fa-8133-60302e369533 | nova-conductor | controller02 | internal | enabled | down | 2020-04-29T14:58:20.000000 | - | False | | cb2ebf3c-53e1-493b-979e-471a1bd2e3b9 | nova-conductor | controller01 | internal | enabled | down | 2020-04-29T14:58:20.000000 | - | False | | 669d979a-26a2-4b85-a139-a6705a3b04f8 | nova-scheduler | controller02 | internal | enabled | down | 2020-04-29T14:58:23.000000 | - | False | | f97b8c40-ab45-4e9c-ac3d-675f1600d5ad | nova-scheduler | controller01 | internal | enabled | down | 2020-04-29T14:58:23.000000 | - | False | | 39312d81-841e-4399-b178-f9b7d47eba1b | nova-consoleauth | controller02 | internal | enabled | down | 2020-04-29T14:58:17.000000 | - | False | | 793480c6-6503-4fc2-a89e-fe20a3700efb | nova-consoleauth | controller01 | internal | enabled | down | 2020-04-29T14:58:16.000000 | - | False | |04T05:15:54.000000 | - | False |

  回避策：「down」状態のサービスを削除します。

  1. Nova CR を更新します。
     viocli update nova nova-xxx
  2. manifests パラメータに cron_job_service_cleaner: true を設定します。以下に例を示します。
     conf:
  nova:
    neutron:
      metadata_proxy_shared_secret: .Secret:managedencryptedpasswords:data.metadata_proxy_shared_secret
    vmware:
      passthrough: "false"
      tenant_vdc: "false"
manifests: 
  cron_job_service_cleaner: true
  3. CR を保存し、すべての Nova ポッドが再作成されるまで待機します。

  約 1 時間後、cronjob により「down」状態のすべてのサービスが削除されます。

• VIO 5.1 からのアップグレード後、LDAP ユーザーがログインできない

  VIO 5.1 からのアップグレード後、LDAP ユーザーが VIO 7.0 にログインできません。

  回避策：VIO 5.1 のリリース後、Keystone Community のコードで変更が実行されています。この問題を回避するには、ユーザー データベースを更新する必要があります。ナレッジベースの記事 KB79373 を参照してください。

一般的な問題

 

• パブリック API のレート制限を使用できない

  VMware Integrated OpenStack 7.0 では、パブリック API にレート制限を適用できません。

  回避策：なし。この機能は、この後のバージョンで提供されます。

• VMware Integrated OpenStack 7.0 にアップグレードした後、デフォルトのプールを既存の LBaaS リスナーに追加することができない

  VMware Integrated OpenStack 5.1 では、LBaaS リスナーのデフォルトのプールの変更はサポートされていません。この機能は、VMware Integrated OpenStack 7.0 でサポートされています。ただし、デフォルトのプールを持たない VMware Integrated OpenStack 5.1 で LBaaS リスナーを作成すると、VMware Integrated OpenStack 7.0 にアップグレードした後でも、リスナーにデフォルトのプールを追加することはできません。

  回避策：影響を受けるリスナーを削除し、再度作成します。

• ルーターに接続されていないプライベート サブネットを使用してロード バランサを作成すると、エラー状態になる

  MP プラグインや Policy Plugin などの Neutron NSX-T プラグインでは、ルーターに接続されていないプライベート サブネットを使用してロード バランサを作成すると、ロード バランサにエラーが発生しますが、エラーがユーザーに報告されません。

  回避策：ルーターに接続されているサブネットを使用してロード バランサを作成します。

• 一部のファイアウォール グループ、ポリシー、ルールが、Horizon ファイアウォール ダッシュボードに表示されない

  Horizon ファイアウォール ダッシュボードは、共有フラグが true または false に設定されたファイアウォール グループ、ポリシー、ルールを表示するように設計されています。共有フラグが未設定の場合、ファイアウォール グループ、ポリシー、ルールは表示されません。

  回避策：OpenStack CLI では共有フラグの設定が必須ではないため、OpenStack CLI を使用してファイアウォール グループ、ポリシー、ルールをリストできます。または、Horizon ファイアウォール ダッシュボード内の共有フラグが未設定のすべてのレコードについて、値をゼロまたは false に更新することができます。論理的には、false は未設定と等価です。例：

  update firewall_groups_v2 set shared=0 where shared is NULL;
update firewall_policies_v2 set shared=0 where shared is NULL;
update firewall_rules_v2 set shared=0 where shared is NULL;

• イメージを Glance にアップロードすると、完了する前にタイムアウトになる

  Horizon または CLI のいずれかを使用している場合、サイズの大きいイメージを Glance にアップロードすると、完了する前にタイムアウトになることがあります。

  • Horizon ユーザー インターフェイスを使用している場合は、イメージは Horizon の一時フォルダにアップロードされてから Glance にアップロードされます。Horizon のセッションの時間制限は 1 時間です。アップロード操作が 1 時間以内に完了しなかった場合、セッションは終了し、イメージのアップロード プロセスは中止されます。
  • CLI を使用している場合は、イメージは glance-api の作業フォルダにアップロードされます。このフォルダでは、イメージの形式が変換されることがあります。その後、イメージは Glance データストアに転送されます。イメージが大きすぎる場合、プロセスはタイムアウトになり、中止されることがあります。

  回避策：余分なステップである Horizon の一時フォルダへのアップロードを削除してアップロード時間を短縮するには、CLI を使用してイメージをアップロードします。サイズの大きいイメージの場合、CLI を実行しているクライアントからアクセス可能な Web サーバに配置してから、glance async import コマンドを使用してイメージをアップロードします。https://docs.openstack.org/python-glanceclient/latest/cli/details.html#glance-task-create を参照してください。

  たとえば、以下のコマンドを使用して、Https://raw.githubusercontent.com/arnaudleg/openstack-cli-tests/master/files/cirros-0.3.0-i386-disk.vmdk という URL からイメージをインポートできます。

  glance task-create --type import --input '{"import_from_format": "vmdk", "import_from": "https://raw.githubusercontent.com/arnaudleg/openstack-cli-tests/master/files/cirros-0.3.0-i386-disk.vmdk", "image_properties": {"name": "cirros-imported", "disk_format": "vmdk", "container_format": "bare", "vmware_adaptertype": "ide", "vmware_disktype": "streamOptimized", "vmware_ostype": "otherGuest"}}'

• ポッドが保留の状態に移行する。VIO 管理サーバまたはコントローラのステータスが「準備ができていません」に変わる

  この状況は、VIO 管理サーバとコントローラ仮想マシンでのリソースの競合が原因で発生します。kubelet が適切な時間内にタスクを完了できない場合、Kubernetes ノードに「準備ができていません」とマークされます。Kubernetes は、使用可能な他のノードにポッドを再度スケジュール設定します。他のノードが使用できない場合、ポッドは保留の状態になります。コンパクトなセットアップでは、単一ノードでのポッドの集約度の高さに比例して、この問題に対してより脆弱になります。

  回避策：Kubernetes ノードのステータスを「準備ができていません」から「準備完了」に変更するには、systemctl restart kubelet を使用して kubelet サービスを再起動します。この問題に永続的に対処するには、スケールアウトしてコントローラ ノードを追加し、各ノードの負荷を軽減します。

• OpenStack のデプロイ時に誤った認証情報を入力すると、ウィザードは正しい認証情報を認識できないことがある

  OpenStack のデプロイ プロセスで、vCenter Server または NSX Manager の認証情報を正しく入力しなかった場合、ウィザードは正しい認証情報を認識できないことがあります。誤った情報を削除して、正しい認証情報を入力しても、ウィザードは検証に失敗することがあります。

  回避策：デプロイ ウィザードを閉じて、もう一度開きます。

• セキュリティ グループの IPv4 アドレス ブロックとして CIDR 0.0.0.0/x を使用すると、NSX-V バックエンドで「any」に変換される

  セキュリティ グループ ルールに CIDR 0.0.0.0/x（x > 0、x < = 32）が設定されている場合、VMware Integrated OpenStack プラグインによって NSX-V バックエンドで「any」に変換されます。これは、IPv6 で ::/x（x>0、x<=128）を使用してセキュリティ グループ ルールを設定した場合にも適用されます。

  回避策：0.0.0.0/x または ::/x アドレス ブロックは使用しないでください。