Red Hat Openstack を使用した環境でのゼロインパクト アップグレード プロセスを使用した Contrail Networking の更新 13

Docker レジストリの設定は、環境に依存しません。 Docker のレジストリ 設定の詳細については、Docker の Docker レジストリを参照してください。

アンダークラウドに入力するコマンドの例を以下に示します。

変数の ContrailImageTag 位置は環境によって異なります。よく使用される環境では、この変数はファイルに設定されます contrail-services.yaml 。

Contrail Registry 20XX への README アクセスからこのパラメーターを取得ContrailImageTagできます。

および パラメーターのいずれかを使用して、ファイルでのカーネルモード vRouter 巨大ページ サポートを contrail-services.yaml ContrailVrouterHugepages1GB: ContrailVrouterHugepages2MB: 有効または検証できます。

Red Hat Openstack 環境でのカーネルモード vRouter 巨大ページ サポートに関する注意:

• Contrail Networking リリース 2005 でカーネルモード vRouter の巨大ページ サポートが導入され、デフォルトでは Contrail Networking リリース 2005 以降で 2 つの 1 GB 巨大ページをサポートするように構成されています。

  巨大なページ構成を確定するには、コンピューティング ノードを 1 回再起動する必要があります。この最初の再起動後、コンピューティング ノードは、再起動することなく、今後の Contrail Networking ソフトウェア アップグレードを実行できます。

  特に、Contrail Networking 2005 以降を実行している環境のコンピューティング ノードでは、カーネルモード vRouter が再起動されるまで、巨大なページ サポートが有効になっていないことです。2x1GBの巨大ページサポート構成はデフォルトで存在しますが、コンピューティングノードが再起動されるまで有効ではありません。

• ほとんどの環境では、1 GB または 2MB のカーネルモード vRouter 巨大ページのみを使用することをお勧めします。しかし、Red Hat Openstack 環境で 1GB または 2MB のカーネルモード vRouter の巨大ページを同時に有効にすることもできます。この場合は、両方の巨大ページ オプションを有効にする必要がある場合に有効にできます。

• Red Hat Openstack 環境で vRouter の巨大ページ構成設定を変更するには、通常、コンピューティング ノードを再起動する必要があります。

  • 1 GB ページ: 再起動が必要です。

  • 2 MB:通常、再起動が必要です。メモリが断片化されていない環境や、必要なページ数を簡単に割り当てることができる環境では、再起動が避けられる場合があります。

• ほとんどの環境では、1024x2MBの巨大ページサイズのデフォルト設定または2x1GBサイズの設定のいずれかを使用して、2GBのメモリをアロケーションすることをお勧めします。一部の大規模な環境では、拡張のために追加の巨大なページ メモリ設定が必要になる場合があります。その他の巨大なページサイズ設定は、専門のユーザーのみが特殊な状況で設定する必要があります。

• と ContrailVrouterHugepages2MB: のContrailVrouterHugepages1GB:パラメータがファイル内の空のcontrail-services.yaml値に設定されている場合、vRouterの巨大ページは無効になります。

例：

• リポジトリのイメージをオーバークラウド ノードにプルします。

  このステップを実行する方法は複数あります。この操作の一般的な実行方法には、Docker コンテナ用の docker pull コマンドと openstack overcloud container image upload Openstack コンテナの コマンドの使用、および スクリプトの実行がtools/contrail/update_contrail_preparation.shtripleo-heat-templates/upload.containers.sh含まれます。

• (すべてのセットアップでは必須ではありません)事前定義された値が使用環境に適していない場合は、スクリプトのエクスポート変数を指定します。スクリプトの場所:

  このアップグレードでは、スクリプト内の以下の変数が特に重要です。

  • CONTRAIL_NEW_IMAGE_TAG—Contrail のターゲット アップグレード バージョンのイメージ タグ。デフォルト値は.latest

    必要に応じて、 Contrail Registry 20XX への README Access から特定のイメージに対してこのパラメーターを取得できます。

    メモ：

    古いデプロイの中には、変数の CONTRAIL_IMAGE_TAG 代わりに 変数を使用する CONTRAIL_NEW_IMAGE_TAG ものもあります。両方の変数がスクリプトによって update_contrail_preparation.sh 認識され、同じ関数を実行します。

  • SSH_USER—クラウドノードにログインするためのSSHユーザー名。デフォルト値は.heat-admin

  • SSH_OPTIONS-カスタムSSHオプション値。

    ご使用の環境のデフォルト SSH オプションは、通常、事前に定義されています。通常、更新プログラムをカスタマイズする場合にのみこの値を変更します。

  • STOP_CONTAINERS—アップグレードを続行する前に停止する必要があるコンテナのリスト。デフォルト値は.contrail_config_api contrail_analytics_api

• スクリプトを実行します。

  注意：

  スクリプトの実行が開始すると、Contrail サービスは機能しなくなる。

• 最初の openstack overcloud update run Contrail コントローラで、必要に応じて Contrail Analytics ノードで コマンドを実行します。このステップの目的は、1 つの Contrail Controller と 1 つの Contrail Analytics ノードを更新して環境をサポートし、追加のダウンタイムを発生させることなく他の Contrail コントローラと分析ノードを更新できるようにすることです。

  例：

  先に進む前に、Contrail ステータスが ok overcloud-contrailcontroller-0 であることを確認します。

  分析ノードと analyticsdb ノードが別々のノードにある場合、ノードを個別に更新しなければならない場合があります。

• アップグレード後、Contrail Controller ノードと Contrail Analytics および AnalyticsDB ノードの Docker コンテナのステータスとバージョンを確認します。

• 残りの Contrail Controller ノードを更新します。

  例：

例：

メモ：

このステップでは、コンピューティング ノード エージェントがダウンします。想定されるダウンタイムは環境によって異なりますが、通常は 1~5 分です。

このステップを実行する前に、このダウンタイムを許容できないワークロードの移行を検討する

コンピューティング ノードを再起動して更新を完了します。

メモ：

カーネル更新も必要な場合にのみ、この手順を完了するには再起動が必要です。コンピューティング ノードの再起動を避けたい場合は、ファイル内のログ ファイルをチェックして、計算ノードの /var/log/yum.log 更新中にカーネル パッケージが更新されたかどうかを確認してください。再起動は、カーネルの更新がコンピューティング ノードの更新手順の一部として行われた場合にのみ必要です。

コマンドを contrail-status 使用してアップグレード ステータスを監視します。すべてのポッドが状態に達し、 running すべてのサービスが状態に達していることを確認します active 。

この contrail-status コマンドは、アップグレードが成功した後に出力されます。

メモ：

読みやすくするために、この contrail-status コマンドのサンプルからいくつかの出力フィールドとデータが削除されています。

メモ：

このステップで使用する openstack overcloud update converge オプションは、7 で入力された コマンドで使用されるオプションと openstack overcloud update prepare 一致 します。

このステップで行われた更新が成功したことを確認するための画面メッセージ SUCCESS を監視します。