APIC クラスタのアップグレードまたは、ダウングレードを実行する場合は、アップグレードまたは、ダウングレードされた APIC のデータがターゲット イメージと互換性があることを保証するとともに、各 APIC を個別にアップグレードまたは、ダウングレードするために発生する特定のシーケンスのイベントがあります。これらのイベントのほとんどはバックグラウンドで発生するため、APIC クラスタのアップグレードまたは、ダウングレードをトリガーするときに表示される内容を理解することが重要です。

1. ファームウェア リポジトリにイメージを追加します。イメージはすべての APIC クラスタ メンバーに同期されます。

2. 特定のターゲット バージョンへのアップグレードまたは、ダウングレードがトリガーされます。

3. クラスタ内の各 APIC は、最初の grub パーティションに新しいイメージをインストールするプロセスを実行します。これは、アップグレードまたは、ダウングレード プロセスを高速化するために並行して行われます。

4. イメージのインストールが完了すると、各 APIC は順番にデータベース ファイルのデータ変換プロセスを順番に実行します。これが発生すると、次のイベントが発生します。

   1. データ管理エンジン（DME）プロセスがシャットダウンします。これには、すべての API 要求を処理する nginx Web サーバが含まれます。このため、UI / API、およびその APIC で実行される他のバックエンド アプリケーションにアクセスできなくなります。

   2. データベース ファイルが初期バージョンからターゲット バージョンに変換されます。これにかかる時間は、 ACI ファブリックに展開された構成、運用データ、監査ログなどのレコード オブジェクトを含むデータベースのサイズによって異なります。このため、変換を完了するまでの合計時間は導入環境によって異なります。

      ソース バージョンが APIC リリース 6.0(3) 以降の場合、データベース変換プロセスが強化され、以前のリリースと比較してこのプロセスの待機時間が短くなることがあります。

      ソース バージョンが APIC リリース 6.2(1) 以降の場合、 APIC 1 はアップグレードの一元的なオーケストレーション ポイントとして機能し、 APIC クラスタ全体に分散されるすべてのデータベースのデータベース変換を一度に実行します。他の APIC は、それ自体にローカルな特別な APIC に対してのみ変換を実行します。これにより、クラスタ同期の問題のリスクを軽減することで、より堅牢な変換プロセスが提供されます。

      （注）	この段階で APIC に対して実行される破壊的なアクションがないことが重要です。詳細については、「アップグレードまたは、ダウングレードに関するガイドラインおよび制限事項」を参照してください。

   3. APIC は、データベース変換プロセスが正常に完了した後にリロードし、ターゲット バージョンで定義されたソフトウェアのバージョンで起動します。

5. リロードを実行した APIC がオンラインに戻ると、4 で説明した一連のイベントがクラスタ内の次の APIC で発生します。その間、オンラインに戻ったAPICは、データベースの最終チェックとしてアップグレード後のアクティビティを開始します。このプロセスは、クラスタのすべてのメンバーがアップグレードまたは、ダウングレードされるまで繰り返されます。

6. Cisco APIC 6.0(6) より前は、すべての APIC がオンラインに戻り、アップグレード後のアクティビティに関係なく完全に適合したときに、 APIC クラスタのアップグレードが完了したと見なされました。Cisco APIC 6.0(6) 以降、各 APIC ノードでアップグレード後のアクティビティが完了するまで、 APIC クラスタのアップグレードのステータスは「Post Upgrade Pending」に移行します。その後、アップグレードステータスが最終的に「Completed」になります。

   （注）

   スイッチのアップグレードを続行する前に、 APIC でのアップグレード後のアクティビティを正常に完了する必要があります。一般に、 APIC クラスタとスイッチのアップグレードは同じメンテナンス期間中に発生しない可能性があるため、 APIC クラスタのアップグレード前とスイッチのアップグレード前に、それぞれ pre-upgrade validation script を実行することをお勧めしウィンドウ。ただし、Cisco APIC 6.0(6) より前では、同じメンテナンス ウィンドウ内で行われる場合でも、スイッチのアップグレード前にスクリプトを実行することを強くお勧めします。このスクリプトは、アップグレード前の検証だけでは、アップグレード後のアクティビティのステータスも確認して、APIC クラスタのアップグレード後にファブリックによりスイッチのアップグレードを続行する準備ができていることを確認するためです。

7. Cisco APIC 6.1(2) 以降、すべてのアクティブな APIC ノードがアップグレードされた後、スタンバイ APIC ノードで同じアップグレード手順が実行されます。詳細については、『Cisco APIC 6.1 向けスタートアップ ガイド』を参照してください。

次の項では、APIC アップグレードの詳細な概要を示します。

5.2(4) 以降のリリースにアップグレードすると、Cisco Application Policy Infrastructure Controller (APIC) によって次のデフォルトのインターフェイスポリシーが自動的に作成されます。

• CDP (cdpIfPol)

  • system-cdp-disabled

  • system-cdp-enabled

• LLDP (lldpIfPol)

  • system-lldp-disabled

  • system-lldp-enabled

• LACP (lacpLagPol)

  • system-static-on

  • system-lacp-passive

  • system-lacp-active

• リンクレベル (fabricHIfPol)

  • system-link-level-100M-auto

  • system-link-level-1G-auto

  • system-link-level-10G-auto

  • system-link-level-25G-auto

  • system-link-level-40G-auto

  • system-link-level-100G-auto

  • system-link-level-400G-auto

• ブレイクアウトポート グループマップ (infraBrkoutPortGrp)

  • system-breakout-10g-4x

  • system-breakout-25g-4x

  • system-breakout-100g-4x

アップグレード中に、これらのポリシーのいずれかとまったく同じ名前とパラメータを持つポリシーがすでに存在する場合、システムはそれらのポリシーの所有権を取得し、ポリシーは読み取り専用になります。そうではなく、system-cdp-disabled の設定が「有効」になっているなど、パラメータが異なる場合、ポリシーは引き続きユーザーポリシーになります。つまり、ユーザーはポリシーを変更できます。

ACI スイッチ ノードのアップグレードとダウングレードを実行すると、アップグレードとダウングレード中のデバイスで発生するイベントの特定のシーケンスがあります。これらのイベントのほとんどはバックグラウンドで発生するため、ACI スイッチ ノードのアップグレードをトリガーするときに表示される内容を理解することが重要です。

1. イメージが APIC からスイッチにプッシュされます。

2. スイッチのファイル システムとブートフラッシュをチェックして、イメージを抽出するのに十分な領域があることを確認します。

3. イメージが抽出され、プライマリ GRUB パーティションがターゲット バージョンに更新されます。古いバージョンはリカバリ パーティションに移動されます。

4. BIOS および EPLD イメージは、必要に応じてアップグレードされます。

5. スイッチはクリーン リロードを実行し、新しいバージョンのソフトウェアを実行している ACI ファブリックに再参加します。

リリース 2.1(4) 以降では、サードパーティ製ミクロン ソリッド ステート ドライブ (SSD) ファームウェア自動更新のサポートが追加されました。標準的な Cisco APIC ソフトウェア アップグレードプロセスの一環として、アップグレード時にスイッチが再起動します。そのブート時のプロセスでは、システムは現在の SSD ファームウェアもチェックし、必要に応じて SSD ファームウェアへのアップグレードを自動的に実行します。システムが SSD ファームウェアのアップグレードを実行すると、スイッチは後でもう一度クリーン リブートします。

次の項では、スイッチ アップグレードの詳細な概要を示します。