サイトマップ
購入のご案内

アカウントをお持ちの場合

  •   パーソナライズされたコンテンツ
  •   製品とサポート

アカウントをお持ちでない場合

アカウントを作成

Cisco ACI OpenStack 統合プラグインの移行

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

翻訳について

このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。 あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。

マニュアルのコンテンツ
このマニュアル内で検索
ご利用いただける言語
Download Options

Book Title

Cisco ACI OpenStack 統合プラグインの移行

Chapter Title

移行

検索結果

Updated:
2019年2月12日

章のタイトル： 移行

移行

この章の内容は、次のとおりです。

概要

ACI OpenStack Newton（OpenStack Platform 10）には、Neutron および ML2 プラグイン用の 3 台のメカニズム ドライバが付属しています。

  • レガシー ML2 ドライバ

  • レガシー GBP ドライバ

  • ML2 と GBP の統合ドライバ

Ocata（OpenStack Platform 11）以降の ACI OpenStack ソリューションに付属しているのは、統合ドライバのみです。新しいバージョンの ACI OpenStack にアップグレードする前に、Neutron メカニズム ドライバを統合ドライバに更新する必要があります。従来のドライバと統合ドライバでは一部の機能および相互運用性が異なるため、同等交換はできません。一般的な ML2 と Neutron の使用状況では、この手順で簡単に移行できます。

注意事項と制約事項

移行には、次の注意事項と制約事項が適用されます。

  • 移行の対象はレガシー ML2 ドライバのみで、レガシー GBP ドライバは対象外です。レガシー プラグインと統合プラグインの両方でサポートされる機能に制限されます。

  • 移行は Red Hat OpenStack Platform 10 でのみサポートされます。移行時に、OpenStack アップグレードなどの他の手順と組み合わせることはできません。

  • ライブ マイグレーション、作成または削除などの手順が VM に影響することはありませんが、トラフィックには最大で数 10 分の影響が及びます。したがって、必要に応じてバックアップ、移行、ロールバックを実行できる十分な長さのメンテナンス期間にスケジュールを設定する必要があります。

  • この移行手順は途中で中止できません。移行は OpenStack クラスタ全体に対して実行する必要があります。テナント、ネットワーク、ホストごとというように徐々に行うことはできません。

  • VLAN モードで実行する場合は、移行の前後に VLAN を十分に使用できることが前提となります。OpenStack クラスタには、分離された VLAN ディストリビューションを含めます。厳格な要件ではありませんが、これによってバックアップから復元せずに簡単な手順で元に戻すことができる場合があります。

  • ソフトウェア アップグレードは、このプロセスに含まれていません。これはレガシー プラグインから統合プラグインへの移行専用です。必要なソフトウェア アップグレードはすべて、移行の前に実行する必要があります。

  • 移行は ACI の共通テナントに設定されている L3 アウト ポリシーでのみサポートされます。

  • 移行プロセスを容易にするツールを含む、導入ツール パッケージがリリースで提供されます。パッケージ内のツールは、移行の特定の手順をスクリプト化する方法の参照用として提供されます。

移行

次のプロセスは、テンプレートとしてのみ利用してください。インストール固有の考慮事項によって追加の手順または別の手順を実行する場合もあります。このプロセスは VLAN カプセル化と RPM パッケージ化を使用するサイト向けの例ですが、特定のインストールではこれらのいずれかまたは両方が異なる場合があります。

始める前に

開始する前に、次の前提条件を満たしていることを確認します。

  • Cisco ACI ファブリックをリリース 3.2(4) に更新します。リリース 4.0(1) 以降はサポートされていません。

  • Cisco ACI プラグインを最新の 4.0(x) リリースに更新し、既存の ML2 ドライバと設定を引き続き使用します。

  • 導入ツール パッケージをコントローラにインストールします。

手順

ステップ 1

すべての neutron コントローラ ノードに AIM サービスをインストールして初期化します。この手順により、neutron ノードでインストール済みの統合プラグインを使用できるようになります。

  1. a. AIM をインストールします。

    例:

    # yum -y install aci-integration-module.noarch

  2. neutron 設定を使用して、AIM DB 移行スクリプトを実行します。この手順を実行するのは 1 回のみで、すべてのコントローラで繰り返す必要はありません。

    例:

    # aimctl -c /etc/neutron/neutron.conf db-migration upgrade

  3. 既存の neutron 設定から AIM 設定を作成するスクリプトを実行します。

    例:

    # deployment_tool aim-config

    /etc/aim/aim.conf ファイルと /etc/aim/aimctl.conf ファイルを調べて、VMM ドメイン、物理ドメイン、物理リンク、およびその他の状態の設定が neutron 設定ファイルから AIM 設定ファイルに正常に移行されたことを確認します。各状態がレガシー設定ファイルに含まれていない場合は、それぞれを手動で追加する必要があります。保持する必要があるスタティック パス バインディングを設定ファイルに追加します。

  4. 次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで AIM 設定をインストールします。

    例:

    # aimctl config replace
ステップ 2

AIM サービスを開始します。AIM サービスを再開すると、新しい VMM ドメイン用に APIC リソースがプロビジョニングされます。L3out の使用状況によっては、外部トラフィックに影響する可能性があります。それ以外の場合は、分離されます。すべてのリソースが APIC と同期されるまで待ちます。

  1. AIM/AID を起動します。

    例:

    # systemctl start aim-event-service-rpc
# systemctl start aim-event-service-polling
# systemctl start aim-aid

  2. 次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで AIM 設定ファイルからインフラストラクチャを作成します。この手順によって、APIC に新しい VMM ドメインも作成されます。

    例:

    # aimctl infra create
ステップ 3

次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで、新しい VMM ドメインや新しいシステム ID を使って AIM を更新します。VMM ドメインをロードします。

例:

# aimctl manager load-domains
ステップ 4

AIM サービスが正常にインストールされたら、すべての neutron ノードでサービスを再度シャットダウンします。AIM を使用するのは統合プラグインのみであり、現在 OpenStack は従来のプラグインを使用しているため、この手順が既存の OpenStack ワークロードに影響することはありません。AIM/AID を停止します。

例:

# systemctl stop aim-event-service-rpc
# systemctl stop aim-event-service-polling
# systemctl stop aim-aid
ステップ 5

エージェントを実行しているすべてのホストで、neutron-opflex-agents をシャットダウンします。

例:

# systemctl stop neutron-opflex-agent
ステップ 6

neutron-server をシャットダウンします。

例:

# systemctl stop neutron-server

neutron-server がシャットダウンされると、新しい OpenStack ワークロードをプロビジョニングすることも、既存のワークロードを更新することもできません。既存のワークロードのトラフィックは、それまでどおり引き続き機能します。

ステップ 7

現在の状態をバックアップします。

  1. 現在の neutron データベースをバックアップします。

  2. 現在の APIC 設定をバックアップします。

この手順でバックアップした neutron データベースと APIC 設定を復元すれば、ロールバックを実行できます。

ステップ 8

neutron で統合プラグインを使用する準備を行います。

  1. この OpenStack インスタンスで使用する共通ユーザの既存の ACI テナントと契約を追跡します。

  2. 新しいプラグインを使用するように neutron 設定ファイルを再設定します。

    例:

    # deployment_tool toggle-config --toggle new

  3. 前の OpenStack クラスタと異なるシステム ID、新しい VLAN プール、同じ AEP を使用するように設定ファイルを更新します。

  4. neutron 設定ファイルに l3out DN を追加します。

    例:

    [ml2_apic_aim]
migrate_ext_net_dns=<UUID of net>: <DN of External Network in APIC>
ステップ 9

修復モードで検証ツールを実行します。これにより、AIM データベースに新しい設定が作成されます。さらに、neutron-server の再起動時に更新を必要とするようにポートが設定されます。

  1. 検証ツールを実行します。

    例:

    # gbp-validate --config-file \ 
/etc/neutron/neutron.conf --config-file \ 
/etc/neutron/plugins/ml2/ml2_conf.ini

    すべての設定が「修復可能」であることを示すメッセージが表示されてツールが完了します。

  2. 修復モードで検証ツールを実行します。

    例:

    # gbp-validate --repair --config-file \ 
/etc/neutron/neutron.conf --config-file \ 
/etc/neutron/plugins/ml2/ml2_conf.ini

いずれかの手順が失敗した場合は、ステップ 7 および 8 の変更を元に戻して移行手順を中止してください。失敗した場合はシスコ サポートで根本原因を分析し、今後の移行を成功させるために必要な変更を行う必要があります。
ステップ 10

すべてのノードで OpFlex エージェントをシャットダウンします。この手順を実行すると、ACI コントロール プレーンからの OpenStack ワークロードのトラフィックが切断されますが、既存のワークロードに影響することはありません。

  1. OpFlex エージェントを停止します。

    例:

    # systemctl stop opflex-agent

  2. OpFlex エージェントの VMM ドメインの設定を取得します。

    例:

    # deployment-tool get-domains

  3. マッピング ファイル（デフォルトのファイル名：opflex_hosts.txt）の編集後に、新しい VMM ドメインを使用するように OpFlex エージェントの設定を更新します。

    例:

    # deployment-tool update-domains
ステップ 11

一度に 1 台のコンピューティング ノードで、次の手順を順番に実行します。

  1. Opflex エージェントを再起動して、約 60 秒待ちます。

    例:

    # systemctl start opflex-agent

    60 秒は一般に推定される待機時間です。実際の時間はインストールの規模によって異なります。

  2. neutron-opflex-agent を再起動します。

    例:

    # systemctl start neutron-opflex-agent

この手順では、このホストのすべての neutron ポートとそれぞれのフローティング IP を新しい VMM に移行します。

ステップ 12

AIM と neutron-server を起動します。

  1. AIM を起動します。

    例:

    # systemctl start aim-event-service-rpc
# systemctl start aim-event-service-polling
# systemctl start aim-aid

  2. ステップ 8b では、統合プラグインへのアップグレード時にポート バインディングが成功するように、導入ツールの「toggle-config」コマンドで agent_down_time パラメータを大きな値に設定しました。意図する agent_down_time 値を使用するには、次のコマンドを実行する前に、このパラメータを目的の値に設定する必要があります（デフォルトは 60 秒）。

  3. neutron-server を起動します。

    例:

    # systemctl start neutron-server
ステップ 13

L3out ポリシーに使用された古いブリッジ ドメインのサブネットを削除します。これにより、ネットワーク アドレッシングと関連するポリシーに使用する必要があるブリッジ ドメインおよび外部エンドポイント グループが明確になります。移行中に外部接続が必要な場合は、この接続が必要なホストのブリッジ ドメインにホスト ルート（つまり /32 アドレッシング）を追加できます。

ステップ 14

新しい VMM ドメインを AEP と関連付けます。
ステップ 15

次の点を確認します。

  1. 接続：各コンピューティング ノード上にあるサンプル VM の L2 および L3 接続。

  2. 移行後のセキュリティ グループが iptables ではなく OVS によって適用されている。

  3. 新しい VM を作成する際の DHCP とメタデータの使用状況。

  4. フローティング IP および SNAT の接続（該当する場合）。

  5. ステップ 1c で設定したスタティック パス。

  6. 新しい EPG による既存の契約の使用状況（該当する場合）。

  7. 移行後の LBaaS の使用状況（該当する場合）。

この手順が失敗した場合は、ロールバックを実行して移行手順で行われた変更を元に戻します。
ステップ 16

古い VMM ドメインと AEP の関連付けを削除します。
ステップ 17

APIC で残りのリソースをクリーンアップします。

  1. 古いシステム ID を持つ VMM を削除します。

  2. 古い APIC 設定またはステップ 7a で保存した関連付けを削除します。

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ