VMware Integrated OpenStack 7.0 | 2020 年 6 月 4 日 | ビルド 16227912

リリース ノートに追加または更新された内容をご確認ください。

リリース ノートの概要

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

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 プラグインがサポートされます
    • アップグレード前に「既知の問題」セクションを確認し、製品ドキュメントで詳細なアップグレード手順を確認してください。

互換性

非推奨に関する通知 

  • このリリースでは、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 アドレス ブロックは使用しないでください。

    check-circle-line exclamation-circle-line close-line
    Scroll to top icon