Cisco APIC インストールおよび ACI アップグレード、ダウングレード ガイド

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

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

マニュアルのコンテンツ
このマニュアル内で検索

検索結果

Updated:
2024年9月12日木曜日

章のタイトル： ACI ファームウェア アップグレードの概要

ACI ファームウェア アップグレードの概要

ファームウェア管理について

Cisco ACI にはいくつかの種類のファームウェアがあります。次に、このドキュメントで説明するファームウェアの概要を示します。この章では、主に上位 2 種類の Cisco ACI ファームウェア（Cisco APIC ファームウェアとスイッチ ファームウェア）に焦点を当てます。

ファームウェアのタイプ

説明

例

Cisco APIC ファームウェア

APIC アプライアンスで実行されている APIC のオペレーション システム。

APIC リリース 5.2(1g)：

aci-apic-dk9.5.2.1g

スイッチのファームウェア

Nexus 9000 シリーズで稼働する ACI スイッチのオペレーティング システム。

ACI スイッチ リリース 15.2(1g)：

aci-n9000-dk9.15.2.1g.bin

ソフトウェア メンテナンス アップグレード（SMU）パッチ

APIC または ACI スイッチの特定の障害のパッチ イメージ。

詳細については、ソフトウェア メンテナンス アップグレード パッチを参照してください。

5.2(1g) リリースを使用している APIC の CSCaa12345 パッチ：

aci-apic-patch-CSCaa12345-5.2.1g-S.1.0.x86_64.tgz

15.2(1g) リリースを使用している ACI スイッチの CSCaa12345 パッチ：

aci-n9000-patch-CSCaa12345-15.2.1g-S.1.1.1.rpm

サイレント ロール（SR）パッケージ

ACI スイッチの特定のハードウェア コンポーネント用のファームウェアのパッケージ。

詳細については、サイレント ロール パッケージのアップグレードを参照してください。

aci-srpkg-dk9.1.0.0.bin

アップグレードまたはダウン グレードするワークフローを Cisco ACI ファブリック

Cisco APIC は、ファブリック全体のアップグレードとダウングレードを一元的に管理します。Cisco APIC は、イメージのリポジトリとして（例：ファームウェア リポジトリ）、およびブート サーバとして機能します。リーフ スイッチとスパイン スイッチにはACI インフラ ネットワークを使用した Cisco APIC への接続性があり、アップグレードまたは、ダウングレードするときスイッチは Cisco APIC からファームウェアをダウンロードします。このセクションでは、アップグレードまたは、ダウングレードを正常に完了するための推奨手順を説明します。

  1. ターゲットAPICおよびACIスイッチのバージョンを選択します。

    1. APICとACIスイッチの両方を同じバージョンにアップグレードまたは、ダウングレードする必要があります。

    2. 相互に互換性のあるAPICおよびACIスイッチのバージョンは、xy（z）および1x.y（z）の形式で記述されます。たとえば、APICバージョン5.2（1g）はACIスイッチバージョン15.2（1g）に対応します。

    3. リリースノート（APICおよびACIスイッチ）で、未解決の問題や欠陥がないか、ターゲットバージョンを確認します。 https://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html#Release_Notes https://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-release-notes-list.html

  2. 現在のバージョンからサポートされているアップグレードとダウングレードパスについては、[APIC アップグレード/ダウングレード サポート マトリックス（APIC Upgrade/Downgrade Support Matrix）]を参照してください。

    1. 現在のバージョンとターゲットバージョンが離れすぎている場合は、[APIC アップグレード/ダウングレード サポート マトリックス（APIC Upgrade/Downgrade Support Matrix）] で推奨されている中間バージョンにAPICとスイッチの両方をアップグレードまたは、ダウングレードする必要があります。詳細については、「マルチ アップグレードとダウングレード」を参照してください。

    2. APIC アップグレード/ダウングレード サポートマトリックスには、ターゲット APIC バージョンに使用する必要がある UCS HUU バージョンも示されます。

  3. ACI アップグレード アーキテクチャを確認します。

    実行すべきでないことと期待すべきことを理解するには、ACI アップグレード/ダウングレード アーキテクチャ を参照してください。

  4. バックアップ用に設定をエクスポートします。

    詳細については、 『Cisco ACI Configuration Files：Import and Export』を参照してください。https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_KB_Using_Import_Export_to_Recover_Config_States.htmlAES暗号化が有効になっていることを確認します。

  5. 事前に APIC イメージにパッケージされているものを除き、APIC 上のすべての App Center アプリを無効化します。

    詳細については、App Center アプリの注意事項を参照してください。

  6. APIC と ACI スイッチ ファームウェアの両方を APIC にダウンロードします。

    詳細については、各リリースの『APIC での APIC およびスイッチ イメージのダウンロード』の項を参照してください。

  7. APICから各スイッチにACIスイッチファームウェアをダウンロードします。

    スイッチリリース14.1（1）以降、スイッチはアップグレードまたは、ダウングレード前にAPICからイメージをダウンロードできます。詳細については、ルール 5：スイッチ イメージを事前にダウンロードして時間を節約しますを参照してください。

  8. ップグレード前の検証の実行

    詳細については、アップグレード / ダウングレード前のチェックリストを参照してください。

  9. サポートマトリックスで推奨されている場合は、APIC の HUU（CIMC、BIOS、ネットワークアダプタ、RAID コントローラ、ディスク）を介してすべてのサーバー コンポーネントをアップグレードまたは、ダウングレードします。

    詳細については、CIMC ソフトウェアのアップグレード を参照してください。

  10. APIC をアップグレードまたはダウングレードします。

    詳細については、各リリースの『Cisco APIC のアップグレード』の項を参照してください。

  11. ACI モード スイッチをアップグレードまたはダウングレードします。

    1. すべてのAPICが完全に適合するまで待ちます。

    2. 詳細については、各リリースの 『リーフおよびスパイン スイッチのアップグレード』の項を参照してください。

  12. これが [マルチステップ アップグレード（Multistep Upgrade）] の場合は、上記の手順を繰り返して、APICとスイッチの両方の即時バージョンへのアップグレードまたは、ダウングレードが完了し、APIC クラスタ ステータスが [完全に適合した（Fully Fit）] 後に、中間バージョンからターゲットバージョンにアップグレードまたは、ダウングレードします。


（注）  

Cisco ACI ファブリックの導入環境に Cisco AVS/AVS が含まれている場合は、Cisco AVS/AVS を Cisco APIC との互換性があるバージョンにアップグレードまたは、ダウングレードしてください。Cisco AVS / AVEをアップグレードまたは、ダウングレードするには、 [Cisco ACI 仮想エッジ インストール ガイド（Cisco ACI Virtual Edge Installation Guide）]の[Cisco APIC、ファブリック スイッチと Cisco ACI 仮想エッジの推奨されているアップグレード順序 （Recommended Upgrade Sequence for Cisco APIC, the Fabric Switches, and Cisco ACI Virtual Edge）]を参照してください。

ACI スイッチ アップグレードとダウングレードのガイドライン

ACI スイッチのアップグレードとダウングレードのガイドラインは次のとおりです：

ルール 1：リーフ スイッチとスパイン スイッチを少なくとも 2 つのグループに分割する

次に例を示します。

  • グループ ODD：リーフ 101、リーフ 103、スパイン 1001

  • Group EVEN：リーフ 102、リーフ 104、スパイン 1002

ルール 2：スパイン スイッチのグループ化方法を決定する

  • 各ポッドでは、少なくとも 1 つの MP-BGP ルート リフレクタ（RR）スパイン スイッチを常に稼働させてください。

  • IPN 接続のスパイン スイッチを少なくとも 1 つ、各ポッドで常に稼働させてください。

  • 特定のポッドにスパイン スイッチが 1 つしかない場合（マルチポッドの場合）、スパイン スイッチのグレースフル アップグレードを実行しないでください。

    詳細については、ACI スイッチのグレースフル アップグレードまたは、ダウングレードを参照してください。

次に例を示します。

グループの更新

ポッド 1

ポッド 2

ODD

リーフ 101、リーフ 103、リーフ 105

スパイン 1001（RR、IPN）

スパイン 1003

リーフ 201、リーフ 203、リーフ 205

スパイン 2001（RR、IPN）

スパイン 2003

EVEN

リーフ 102、リーフ 104、リーフ 106

スパイン 1002（RR、IPN）

スパイン 1004

リーフ 202、リーフ 204、リーフ 206

スパイン 2002（RR、IPN）

スパイン 2004

ここで、

  • RR は、ルート リフレクタ スパイン スイッチを意味します。

  • IPN は、IPN に接続されたスパイン スイッチを意味します。

ルール 3：リーフ スイッチをグループ化する方法を決定します

  • 常に同じ vPC ペアのリーフ スイッチの 1 つを稼働状態に維持します

  • 各 Cisco Application Policy Infrastructure Controller (APIC) に接続されているリーフスイッチの 1 つを常に稼働させます。

次に例を示します。

グループの更新

ポッド 1

ポッド 2

ODD

リーフ 101（vPC 11、APIC1）

リーフ 103（vPC 12、APIC2）

リーフ 105（vPC 13）

スパイン 1001

リーフ 201（vPC 21、APIC3）

リーフ 203（vPC 22）

リーフ 205（vPC 23）

スパイン 2001

EVEN

リーフ 102（vPC 11、APIC1）

リーフ 104（vPC 12、APIC2）

リーフ 106（vPC 13）

スパイン 1002

リーフ 202（vPC 21、APIC3）

リーフ 204（vPC 22）

リーフ 206（vPC 23）

スパイン 2002

ここで、

  • vPC xx は、1 つの vPC ペアを意味します。

  • APICx とは、Cisco APIC に接続されたリーフスイッチのことです。

ルール 4：スイッチ更新グループの同時キャパシティを理解する

全般

  • 各アップグレード/メンテナンス グループに含められるのは、最大 80 スイッチ ノードです。

  • 同時キャパシティ（同時にアップグレードまたは、ダウングレードされるスイッチ）は、同じ更新/メンテナンス グループ内で同時にアップグレードまたは、ダウングレードする必要があるスイッチの数を決定します。ただし、同時キャパシティ設定では、同じグループのどのスイッチを同時にアップグレードまたは、ダウングレードするかを管理できないため、同時キャパシティ設定に依存するのではなく、異なるスケジュールでスイッチをアップグレードまたは、ダウングレードするために個別の更新グループを作成することを推奨します。

  • 同じ vPC ペアの両方のリーフ ノードが同じスイッチ アップグレードまたは、ダウングレード グループにある場合、同時キャパシティに関係なく、一度に 1 つのリーフ ノードのみがアップグレードまたは、ダウングレードされます。

  • Cisco APIC リリース 4.1（1）以降、グレースフルアップグレードまたは、ダウングレードが適用され、同じポッドに他の動作可能なスパインスイッチがない場合、同時キャパシティ設定に関係なく、アップグレードまたは、ダウングレードは拒否されます。

Cisco APIC リリース 4.2(5) よりも前のリリース：

  • 同じ更新グループ内でも、スイッチは一度に 1 つのポッドのみアップグレードまたは、ダウングレードされます。

  • グループあたりのデフォルトの同時キャパシティは 20 です。

同じグループに 20 を超えるスイッチがある場合は、アップグレード スケジューラを使用して容量を無制限に変更できます。

詳細については、『リーフおよびスパイン スイッチ ソフトウェア バージョンのアップグレード』を参照してください。

Cisco APIC リリース 4.2(5) 以降：

  • 同じ更新グループ内のスイッチは、ポッドに関係なく同時にアップグレードまたは、ダウングレードされます。

  • グループあたりのデフォルトの同時キャパシティは無制限です。

Cisco APIC リリース 4.2(5) からの上記の拡張機能は、Cisco APIC が 4.2(5) 以降にアップグレードされるとすぐに有効になります。たとえば、Cisco APIC が 4.2(5) にアップグレードされ、スイッチがまだリリース 13.2(10) である場合、スイッチが 13.2(10) から 14.2(5) にアップグレードされると、上記の拡張機能が有効になります。

この機能拡張により、スイッチのアップグレードにかかる時間を短縮できます。

ルール 5：スイッチ イメージを事前にダウンロードして時間を節約します

Cisco APIC とスイッチイメージを Cisco APIC のファームウェアリポジトリにダウンロードした後でも、スイッチは Cisco APIC からイメージをダウンロードする必要があります。以降のリリースでは、この操作は実際のアップグレード手順とは別に実行できます。これは事前ダウンロードと呼ばれ、アップグレードまたはダウン グレードするワークフローを Cisco ACI ファブリック のステップ 7 に相当します。

スイッチ リリース 14.1(1) より前：

未サポートアップグレードまたは、ダウングレードがトリガーされると、スイッチは Cisco APIC からイメージをダウンロードします。

スイッチ リリース 14.(1) 〜 15.0(x)：

  • 事前ダウンロードは、アップグレード スケジューラを使用して実行できます。

  • 推奨されるアップグレード手順の順守：

    1. 遠い将来（10 年先など）に設定されたスケジューラで更新グループを作成します。これにより、スイッチは Cisco APIC からイメージをすぐにダウンロードします。

    2. メンテナンス ウィンドウでアップグレードを開始する時間になったら、同じグループを編集し、[アップグレード開始時間（Upgrade Start Time）] を [今すぐ（Now）] に変更します。

  • スイッチの現在のバージョンが 14.2(5) 以降の場合、Cisco APIC GUI に事前ダウンロードの進行状況が表示されます。

スイッチ リリース 15.1(1) 以降：

  • 事前ダウンロードは、スケジューラを使用せずに GUI ワークフローでネイティブに構築されます。

    1. 更新グループを作成し、[ダウンロードの開始（Begin Download）] をクリックすると、スイッチは Cisco APIC からイメージをダウンロードします。

    2. 事前ダウンロードが完了すると、各スイッチに [インストール準備完了（Ready to Install）] と表示されます。

    3. 同じグループに対して [インストールの開始（Begin Install）] を実行して、アップグレードをトリガーします。

スイッチ リリース 14.1(1) からの上記の拡張（事前ダウンロード）は、Cisco APIC とスイッチの両方が対応するバージョンにアップグレードまたは、ダウングレードされた後にのみ有効になります。たとえば、Cisco APIC が 4.2(7) にアップグレードされ、スイッチが 13.2(10) にある場合、スイッチを 13.2(10) から 14.2(7) にアップグレードするための事前ダウンロードは使用できません。一方、Cisco APIC が 5.2(1) にアップグレードされ、スイッチが 14.2(7) のままの場合、 [ダウンロードの開始（Begin Download）] を使用して、 14.2(7) から 15.2(1) へのスイッチのアップグレードのため、新しい Cisco APIC GUI を介して事前ダウンロードが実行します。

ACI スイッチのグレースフル アップグレードまたは、ダウングレード

アップグレードまたは、ダウングレード手順を実行するときにユーザートラフィックからスイッチを分離する場合は、次の状況でサポートされているものとサポートされていないものをよりよく理解するために、使用可能なさまざまな用語と方法を理解しておくと役立ちます：

  • グレースフル挿入と削除（GIR）：ユーザー トラフィックからスイッチを分離するために使用される操作。

  • メンテナンス モード：デバッグ目的でユーザー トラフィックからスイッチを分離するために使用されます。[ファブリック（Fabric）] > [インベントリ（Inventory）] > [ファブリックメンバーシップ（Fabric Membership）] にある Cisco APIC GUI の[ファブリックメンバーシップ（Fabric Membership）] ページの [メンテナンス（GIR）（Maintenance（GIR））] フィールドを有効にすることで、スイッチをメンテナンスモードにできます（スイッチを右クリックして [メンテナンス（GIR）Maintenance（GIR）] を選択します）。

    スイッチをメンテナンスモードにすると、そのスイッチは動作可能な ACI ファブリック インフラストラクチャの一部とは見なされず、通常の Cisco APIC 通信は受け入れられません。したがって、この状態にあるスイッチのファームウェア アップグレードまたは、ダウングレードを実行しようとすると、プロセスで機能不全が発生したり、不完全なステータスで無限に止まる可能性があるため、スイッチ上でのこの状態のスイッチに対するファームウェア アップグレードまたは、ダウングレードの実行はサポートされていません。

  • グレースフル アップグレード：アップグレード手順中にユーザトラフィックから隔離されたスイッチをリロードするために使用されます。スイッチは、ファームウェア アップグレード プロセス中の特定の時点で自動的にリブートするようにプログラムされています。この操作は、リブートの前に自動的に GIR を実行します。Cisco APIC GUI の [管理（Admin）] > [ファームウェア（Firmware）] で、更新グループ内のスイッチの [グレースフルメンテナンス（Graceful Maintenance）] オプション（リリース 5.1 より前のリリース）または [グレースフルアップグレード（Graceful Upgrade）] オプション（リリース 5.1 以降）を確認できます。

    スイッチがユーザ トラフィックから分離された後、ユーザ トラフィックが冗長パスを通過するようにリロードされる前に手順を停止する場合、このような操作は現在 ACI ではサポートされていません。

ACI スイッチのグレースフル アップグレードのガイドライン

ACI スイッチ アップグレードとダウングレードのガイドライン のすべての注意事項は、グレースフル アップグレードにも適用されます。ただし、このセクションでは、グレースフル アップグレードに特に重要ないくつかの注意事項について詳しく説明します。

  • ルール 2：スパイン スイッチのグループ化方法を決定する で提案されているように、特にマルチポッド設定でグレースフル アップグレードを実行している場合は、ポッドのすべてのスパイン スイッチを一度にアップグレードしないでください。

    そうしないと、アップグレードが失敗し、スパイン スイッチがファブリックから無期限に隔離されたままになります。これはグレースフル アップグレード プロセスの一部のため、IPN 接続性は正常にアップグレードされる各スパイン スイッチで明示的にダウンされるため、ファブリックから分離できます。この方法でアップグレードすると、スパインスイッチ自体を含むポッド全体が、他のポッド内の Cisco APIC およびスイッチとの通信を失い、自己回復の手段がなくなります。

    このため、グレースフル アップグレードを実行している場合、スイッチが個別にアップグレードされるように、同じポッドのスパイン スイッチから異なるメンテナンス/更新グループに配置する必要があります。ポッドにスパイン スイッチが 1 つしかない場合は、アップグレードの前に [グレースフル アップグレード（Graceful Upgrade）]（または [グレースフル メンテナンス（Graceful Maintenance）]） オプションを無効にする必要があります。この手順に従わない場合は、CSCvn28063 に示されている回避策を参照してください。

    この問題を回避するために、Cisco APIC 4.1(1) リリースでは、グレースアップグレードが適用された際に、ポッドの最後のスパインスイッチのアップグレードを拒否する安全なメカニズムが導入されました。このブロックメカニズムについても、ルール 4：スイッチ更新グループの同時キャパシティを理解する で説明します。

  • ルール 3：リーフ スイッチをグループ化する方法を決定します で提案されているように、同じ Cisco APIC に接続された 2 つのリーフスイッチが同時にアップグレードされないように、Cisco APIC 接続リーフスイッチを異なるメンテナンス/更新グループに配置する必要があります。

マルチ アップグレードとダウングレード

Cisco ACI ファブリックでは基本的に、すべてのノード (APIC、リーフ スイッチ、およびスパイン スイッチ) が同じソフトウェア リリースまたは互換性のあるソフトウェア リリースである必要があります。この場合、APIC ノードの標準リリース形式は x.y(z)、リーフおよびスパイン スイッチは、スイッチ固有の標準リリース形式の 1x.y(z) になります。たとえば、 APIC ノードがソフトウェアリリース 4.2(1) である場合、リーフ スイッチとスパイン スイッチは、スイッチ固有の互換性のあるソフトウェアリリースである 14.2(1) である必要があります。

APIC アップグレード/ダウングレード サポート マトリックスには、現在のバージョンとターゲット バージョンでサポートされているアップグレードおよびダウングレード パスが表示されます。これら 2 つのバージョンが離れすぎている場合、ターゲット バージョンへの直接アップグレードまたは、ダウングレードはサポートされない可能性があります。

現在のリリースからの直接のアップグレード パスが存在しないリリースにアップグレードする場合は、すべての APIC とスイッチを、直接アップグレード パスが存在する、サポート対象の中間リリースにアップグレードしたうえで、そのリリースから目的のリリースにアップグレードする必要があります。状況によっては、目的のリリースにアップグレードする前に、複数の中間リリースにアップグレードしなければならない場合があります。この場合、複数の対象 APIC とスイッチの両方をそのつど同じリリースにアップグレードします。

たとえば、 APICアップグレード/ダウングレードサポートマトリックスに、リリース 2.3(1) からリリース 4.2(3) へのアップグレードのための複数の中間リリースが示されている場合、次のような状況が考えられます。

この状況では、次の方法でアップグレードを実行します。

  1. APIC を 3.1(2) リリースにアップグレードし、スイッチを 13.1(2) リリースにアップグレードします。

  2. 3.1 (2)/13.1 (2) へのアップグレード後に、すべての APIC およびスイッチが完全に適合した状態で、動作していることを確認します。

  3. 4.1(2) および 14.1(2) についても同じ手順を繰り返します。

  4. 4.2(3) および 14.2(3) についても同じ手順を繰り返します。

大規模ファブリックのアップグレードまたは、ダウングレード

多数のスイッチのある巨大なファブリックをアップグレードまたはダウングレードする場合や、数日かけてアップグレードまたはダウングレードを行う場合など、ファブリック内で異なるリリースを同時に使用することになる状況があります。このような状況では、ファブリック内には常に、多くとも 2 つの異なる APIC とスイッチ ソフトウェア リリースが存在し得ます。ただし、これらの状況でサポートされる操作は限られています。詳細については、Cisco ACI スイッチの混合バージョンで許可される操作を参照してください。

Cisco ミニ ACI ファブリックをアップグレードまたは、ダウンレード

Cisco Application Centric Infrastructure (ACI) リリース 4.0（1）は、小規模展開のための Cisco ミニ ACI ファブリックを紹介します。ミニ ACI ファブリックは、 仮想マシン内で実行する一つの物理 Cisco APIC と二つの仮想化 Cisco APIC（vAPICs）を含むCisco Application Policy Infrastructure Controller (APIC) クラスタと一緒に機能します。 これにより、Cisco APICクラスタの物理的な設置面積とコストが削減され、ラック スペースや初期予算が限られているシナリオでCisco ACIファブリックを展開できます。このようなシナリオの例には、コロケーション施設やシングルルームのデータ センターが含まれます。このような場合、設置面積や初期費用の関係で本格的なCisco ACI導入は現実的ではありません。

インストール、アップグレード、ダウングレードの手順を含む Cisco ミニ ACIファブリックの詳細については、Cisco ミニ ACI ファブリックと仮想 APIC のドキュメントを参照してください：

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/Cisco-Mini-ACI-Fabric-and-Virtual-APICs.html

App Center アプリの注意事項

Cisco APIC ノードの https://dcappcenter.cisco.com/ からアプリケーションを実行している場合は、次のようにします。

  • それらの APIC ノードで APIC ソフトウェアをアップグレードまたはダウングレードする前に、これらのアプリケーションを無効にします。

  • これらの APIC ノードで APIC ソフトウェアをアップグレードまたはダウングレードする際に、アプリをインストールしたり、削除したりしないでください。

  • これらの APIC ノードで APIC ソフトウェアをアップグレードまたはダウングレードする際に、アプリ イメージのアップグレードを実行しないでください。

  • 3.2(1) リリース以前のリリースからアップグレードし、アップグレード前にアプリケーションがインストールされていた場合、アプリケーションは機能しなくなります。アプリケーションを再度使用するには、それらをアンインストールしてから再インストールする必要があります。

  • APIC リリース 5.2(1) 以降にアップグレードする場合、外部スイッチ アプリケーション バージョン 1.1 をインストールしている場合は、APIC リリース 5.2(1) 以降にアップグレードする前に、アプリケーションを削除し、バージョン 1.2 を再インストールする必要があります。

ファブリック全体 (APIC ノードとスイッチ) の APIC ソフトウェアのアップグレードまたはダウングレードプロセスが完了したら、それらを無効にした場合は、アプリを再度有効にします。APIC ソフトウェアのアップグレードまたはダウングレードプロセスが完了した後、アプリケーションをインストールまたは削除したり、アプリ イメージのアップグレードを実行したりできます。

現在のソフトウェア バージョンの決定

このセクションの手順を使用して、ファブリック内のスイッチおよび APIC で現在実行されているソフトウェア ビルドを確認します。

現在のソフトウェア バージョンの決定

ファブリックの APIC で現在実行されているソフトウェア バージョンを確認できます。

  • Cisco APIC GUI ウィンドウの右上隅にあるアイコン () をクリックし、[バージョン情報 (About)] を選択します。

  • [Controllers] ページに移動します。

    • リリース 5.1(1) 以前のリリースの場合、[管理（Admin）] > [ファームウェア（Firmware）] > [インフラストラクチャ（Infrastructure）] > [コントローラ（Controllers）] に移動します。ソフトウェア バージョンは、このページの表の [現在のファームウェア (Current Firmware)] カラムに表示されます。

    • リリース5.1(1) 以降の場合は、[管理（Admin）] > [ファームウェア（Firmware）] に移動し、左側のナビゲーション ウィンドウで [ダッシュボード（Dashboard）] をクリックします。ソフトウェア バージョンは、ページの [コントローラ（Controllers）] 領域の [ファームウェア（Firmware）] フィールドに表示されます。

      この同じページの [コントローラ（Controllers）] 領域を検索することで、個々の APIC で実行されているソフトウェア バージョンを確認することもできます。各 APIC で実行されているソフトウェア バージョンは、[現在のバージョン（Current Version）] 列に表示されます。

スイッチの現在のソフトウェア バージョンの確認

ファブリック内のリーフ スイッチおよびスパイン スイッチで現在実行されているソフトウェア バージョンを確認するには：

  • リリース5.1(1) より前のリリースの場合は、[管理（Admin）] > [ファームウェア（Firmware）] > [インフラストラクチャ（Infrastructure）] > [ノード（Nodes）] に移動します。ソフトウェア バージョンは、このページの表の [現在のファームウェア (Current Firmware)] カラムに表示されます。

  • リリース5.1(1) 以降の場合は、[管理（Admin）] > [ファームウェア（Firmware）] に移動し、左側のナビゲーション ウィンドウで [ダッシュボード（Dashboard）] をクリックします。ソフトウェア バージョンは、ページの [ノード（Nodes）] 領域の [ファームウェア（Firmware）] フィールドに表示されます。

  • リリース 5.2(1) 以降では、[管理（Admin）] [ファームウェア（Firmware）] > [ノード（Nodes）] > タブの[ノード サマリ（Node Summary）]も使用できます。

スケジューラを使用してアップグレードまたは、ダウングレードすることについて

スケジューラを使用すると、Cisco APIC クラスタやスイッチのアップグレードまた、ダウングレードなど、操作の時間枠を指定します。これらの時間枠は、1 -回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。このセクションでは、アップグレードまたは、ダウングレードのスケジューラの仕組みについて説明します。スケジューラに関する詳細情報については、『Cisco アプリケーション セントリック インフラストラクチャの基礎』を参照してください。


（注）  

クラスタのアップグレードを実行する場合、 Cisco APIC はクラスタに参加するためすべて同じバージョンである必要があります。ファブリックに参加する際の自動アップグレードはありません。

  • Cisco APIC クラスタ アップグレード：Cisco APIC のデフォルトのスケジューラ オブジェクトがあります。一般的なスケジューラ オブジェクトには複数のプロパティがありますが、開始時間のプロパティのみ Cisco APIC クラスタ アップグレードに設定可能です。開始時間を指定する場合、 Cisco APIC アップグレード スケジューラは 1 日の期間に指定された開始時刻からアクティブになります。コントローラに対して runningVersion != desiredVersion の場合、このアクティブな 1 日のウィンドウの間いつでもクラスタ アップグレードを開始します。スケジューラのその他のパラメータは Cisco APIC アップグレードに設定できません。スケジューラを使用しない 1 回のトリガを使用して、Cisco APIC アップグレードを実行できることにも注意してください。この 1 回のトリガは、[今すぐアップグレード] とも呼ばれます。

  • スイッチのアップグレード：スケジューラはメンテナンス グループに関連付けることができます。スイッチのメンテナンス グループに接続されているスケジューラには、「startTime」、「concurCap」および「duration」などいくつかの設定可能なパラメータがあります。これらのパラメータは下記に説明されています。

    • startTime：アクティブなウィンドウの開始。

    • concurCap：同時にアップグレードするノードの数。

    • Duration：アクティブなウィンドウの長さ。

    グループ内のスイッチに対して runningVersion != desiredVersion の場合、このアクティブな 1 日のウィンドウの間いつでもスイッチはアップグレードの対象となります。アップグレードの対象ノード間で、次の制約がアップグレードの候補の選択に適用されます。

    • 「concurCap」ノード以上には現在アップグレードできません。

    • 1 回でアップグレードされるのは仮想ポート チャネル（vPC）ペアの 1 つのノードのみです。

    • Cisco APIC クラスタはノードのアップグレードを開始する前に正常な状態である必要があります。


    （注）  

    GUI、CLI、または REST API を使用して、即時アップグレードとスケジューラベースのアップグレードのオプションがあります。たとえば、CLI では、EXEC モードで firmware upgrade switch-group コマンドを使用して、スイッチグループをすぐにアップグレードできます。このコマンドは、設定されたスケジュール済みアップグレードよりも優先されます。

スケジューラに関する注意事

1回限りのアップグレード スケジュールまたは定期的アップグレード スケジュールのいずれを設定しているかに応じて、アップグレード スケジュールを過去の日付に設定した場合、システムの反応は異なります。

  • 過去の日付を使用して1 回限りのアップグレードスケジュールを設定すると、システムによって設定が拒否されます。

  • 定期的アップグレードまたは 1 度だけのアップグレードのスケジュールに過去の日付が設定されている場合、スケジューラはただちにアップグレードをトリガします。たとえば、水曜日に正午にいて、正午の火曜日ごとに定期アップグレードスケジュールを設定した場合、スケジューラは最初にアップグレードをすぐにトリガーし、その時点から火曜日ごとにアップグレードを実行します。

GUI を使用したスケジューラ―の構成

トリガー スケジューラを使用すると、管理者による介入なしで 1 つ以上のノードをアップグレードして再起動できる、1 回限りまたは繰り返しの期間を定義できます。

手順

ステップ 1

[トリガー スケジューラの作成 (Create Trigger Scheduler)] ウィンドウにアクセスします。

ステップ 2

[トリガー スケジューラの作成 (Create Trigger Scheduler)] ウィンドウで、[名前 (name)] フィールドにスケジューラ ポリシーの名前を入力し、[スケジュール ウィンドウ (schedule Windows)] 領域で [+] をクリックして [スケジュールの作成 (Create Schedule)create schedule]ウィンドウを表示します。

ステップ 3

[ウィンドウ タイプ (Window Type)] フィールドで、1 回限りまたは定期スケジュール ウィンドウのどちらを設定するかに応じて、[1 回限り (One Time)] または [定期 (Recurring)] をクリックします。

ステップ 4

[ウィンドウ名 (Window Name)] フィールドで、このスケジュール ウィンドウの名前を入力します。

このフィールドの最大文字数は 16 です。

ステップ 5

[スケジュール (schedule)] ウィンドウを実行する日付と時刻を決定します。

日付と時刻を設定するためのオプションは、ワンタイムまたは定期スケジュール ウィンドウのどちらを設定するかによって異なります。

  • 1 回限りのスケジュール ウィンドウを設定している場合は、[日付 (Date) )] フィールドに、1回限りのスケジュール ウィンドウが発生する日付を入力します。このフィールドでは、YYYY-MM-DD HH: MM: SS AM/PM の形式を使用するか、下矢印をクリックしてカレンダーから日付と時刻を選択します。

    （注）  

     

    [1 回限りのスケジュール (one-time schedule)] ウィンドウの過去の日付と時刻 (現在の日付と時刻の前) を入力すると、システムはそのエントリを拒否します。

  • [定期スケジュール (Recurring Schedule)] ウィンドウを設定している場合は、次のフィールドに必要な情報を入力します。

    • [日 (Day)]: 定期スケジュールウィンドウを実行する日付を選択します。定期スケジュールウィンドウを毎週実行する特定の日を選択するか、または定期的なスケジュールウィンドウを毎日、すべての偶数日または週のすべての奇数の曜日に実行するかを選択します。

    • [時間 (hour)]: 軍事 24 時間のクロック値 (0-23) を使用して、スケジュールウィンドウを繰り返す時間を入力します。

    • [分 (minute)]: 定期スケジュールウィンドウを発生させる分を入力します。

    たとえば、毎日午後 11:30 の火曜日に定期スケジュールウィンドウを設定する場合は、次のように選択します。

    • Day: 火曜日

    • 時間:22

    • 分:30

（注）  

 

定期スケジュールウィンドウの過去の日付と時刻 (現在の日時よりも前) を入力すると、スケジューラはすぐにアップグレードをトリガーします。たとえば、水曜日に正午にあり、火曜日ごとの午後 11:30 に定期アップグレードスケジュールを設定した場合、スケジューラは最初にアップグレードをトリガーし、その時点から火曜日ごとの午後 11:30 にアップグレードを実行します。

ステップ 6

[最大同時ノード (Maximum Concurrent nodes)] フィールドに、同時アップグレードを行うことが許可されるノードの最大数を入力します。

このフィールドに 0 を入力すると、ノードが APIC ノードであるか、リーフまたはスパインスイッチであるかに応じて、ソフトウェアによってデフォルト値が自動的に選択されます。

  • リリース 4.2(5) より前のリリースでは、このフィールドのデフォルト値「0」は APIC ノードの場合は 1、リーフまたはスパイン スイッチの場合は 20 と解釈されます。このフィールドに入力できる POD ごとの最大ノード数は 200 です。

  • リリース 4.2(5) 以降では、このフィールドのデフォルト値「0」は、APIC ノードでは 1 と解釈されます。リーフまたはスパイン スイッチの場合、このフィールドのデフォルト値の「0」の解釈は 20 から無制限に変更されています。つまり、このフィールドに「0」を入力すると、一度にアップグレードできるリーフ スイッチまたはスパイン スイッチの数は無制限になります。

ステップ 7

[最大実行時間 (Maximum Running time)] フィールドで、スケジュール ウィンドウの最大継続時間を入力します。これは、アップグレード プロセスを開始するために許可する時間の長さです。

このフィールドでは、DD: HH: MM: SS の形式を使用し、最大 24 時間 (01:00:00:00) を使用します。[スケジューラ (scheduler)] ウィンドウで時間制限を適用しない場合は、[無制限 (unlimited)] を入力します。

たとえば、これらのフィールドに次の値を入力したとします。

  • 最大同時ノード (Maximum Concurrent Nodes)数:20

  • 最大実行時間 (Maximum Running Time): 00:00:30:00

この場合、このスケジュール ウィンドウでは、20 個のノードを同時にアップグレードできます。これらの 20 ノードは、上記のフィールドに入力した開始時刻から 30 分以内にアップグレードプロセスが正常に開始した場合にのみアップグレードされます。アップグレード プロセスが 30 分以内に正常に開始されない場合、この時点では 20 ノードはアップグレードされません。また、定期スケジュール ウィンドウを設定した場合、次回スケジューラ ウィンドウが繰り返しに設定されたときに、システムはこれらの 20 ノードのアップグレードを試行します。

[最大実行時間 (Maximum Running Time)] フィールドに入力した値は、グループ内のスイッチがアップグレードするために必要な時間には影響しません。たとえば、[最大実行時間 (Maximum Running Time)] フィールドに値 5 を入力した場合は、アップグレードが 5 分後に開始されない場合、システムはスイッチのアップグレードプロセスを放棄することのみを意味します。これは、システムが 5 分後にアップグレードプロセスを停止することを意味するものではありません。通常、各スイッチのアップグレードには約 10 分かかります。

ステップ 8

[トリガー スケジューラ―の作成 (Create Trigger Scheduler)] ウィンドウで必要な情報の入力が完了したら、[OK] をクリックします。

[トリガー スケジューラ―の作成 (Create Trigger Scheduler)] ウィンドウが再度表示され、新しく設定されたスケジュール ウィンドウがスケジュール ウィンドウ テーブルに表示されます。

ステップ 9

このトリガー スケジューラに対して追加のスケジュール ウィンドウを作成するかどうかを決定します。

このトリガー スケジューラに対してより多くのスケジュール ウィンドウを作成する場合は、[スケジュール ウィンドウ (Schedule Windows)] 領域で [+] をクリックして、[スケジュール ウィンドウの作成 (Create Schedule Window)] ウィンドウを再度表示します。

たとえば、毎日 2 回開始するようにアップグレードを設定する場合や、毎日 12:00 AM と PM の場合、または特定の曜日にアップグレードを設定する場合は、より多くのスケジュールウィンドウを作成することができます。

ステップ 10

必要なスケジュールウィンドウの設定が完了したら、[トリガー スケジューラの作成 (Create Trigger Scheduler )] ウィンドウで [送信 (Submit)] をクリックします。

[ノード アップグレードの選択 (Select Node Upgrade) ] ウィンドウが再度表示されます。

ステップ 11

[ノード アップグレードの選択 (Select Node Upgrade)] ウィンドウで、[スケジューラ (Scheduler)] フィールドを見つけて、先ほど設定したトリガースケジュールを選択します。

ステップ 12

[ノード アップグレードの選択 (Select Node Upgrade)] ウィンドウで必要な追加設定を完了し、[送信 (Submit)] をクリックします。

NX-OS スタイルの CLI を使用したスケジューラ―の構成

スケジュールにより、設定のインポート/エクスポートまたはテクニカル サポートの収集などの操作を 1 つ以上の指定した時間帯に発生させることができます。

スケジュールには、一連のタイム ウィンドウ（オカレンス）が含まれます。これらのウィンドウは、1 回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。期間や実行するタスクの最大数などのウィンドウで定義されているオプションにより、スケジュール設定されたタスクの実行時期が決定されます。たとえば、最大時間長またはタスク数に達したため特定のメンテナンス時間帯に変更を展開できない場合、この展開は次のメンテナンス時間に持ち越されます。

各スケジュールは、APIC が 1 つまたは複数のメンテナンス時間帯に入っているかどうか、定期的に確認します。入っている場合、スケジュールはメンテナンス ポリシーで指定された制限に対し適切な展開を実行します。

スケジュールには、スケジュールに関連付けられたメンテナンス時間を決定する 1 つ以上のオカレンスが含まれています。オカレンスは次のいずれかになります。

  • 絶対（1 回）時間帯：絶対時間帯は、1 回しか発生しないスケジュールを定義します。これらの時間帯は、その時間帯の最大時間長まで、または時間帯の中で実行可能なタスクの最大数に達するまで継続されます。

  • 繰り返し時間帯：繰り返し時間帯は、繰り返しのスケジュールを定義します。この時間帯は、タスクの最大数に達するまで、または時間帯に指定された日の終わりに達するまで継続します。

手順

  コマンドまたはアクション 目的

ステップ 1

configure

例:

apic1# configure

グローバル コンフィギュレーション モードを開始します。

ステップ 2

[no] scheduler schedule-name

例:

apic1(config)# scheduler controller schedule myScheduler

新しいスケジューラを作成するか、既存のスケジューラを設定します。

ステップ 3

[no] description text

例:

apic1(config-scheduler)# description 'This is my scheduler'

このスケジューラの説明を追加します。テキストにスペースが含まれている場合は、単一引用符で囲む必要があります。

ステップ 4

[no] absolute window ウィンドウ名

例:

apic1(config-scheduler)# absolute window myAbsoluteWindow

絶対（1 回）の時間帯スケジュールを作成します。

ステップ 5

[no] max concurrent nodes count

例:

apic1(config-scheduler-absolute)# max concurrent nodes 300

同時に処理できるノード（タスク）の最大数を設定します。指定できる範囲は 0 ～ 65535 です。ノード数を制限しない場合は 0 に設定します。

ステップ 6

[no] max running time time

例:

apic1(config-scheduler-absolute)# max running time 00:01:30:00

dd:hh:mm:ss の形式でタスクの最大実行時間を設定します。指定できる範囲は 0 ～ 65535 です。時間の制限がない場合は 0 に設定します。

ステップ 7

[no] time start time

例:

apic1(config-scheduler-absolute)# time start 2016:jan:01:12:01

[[[yyyy:]mmm:]dd:]HH:MM 形式で開始時刻を設定します。

ステップ 8

exit

例:

apic1(config-scheduler-absolute)# exit

スケジューラ コンフィギュレーション モードに戻ります。

ステップ 9

[no] recurring window ウィンドウ名

例:

apic1(config-scheduler)# recurring window myRecurringWindow

繰り返し時間帯のスケジュールを作成します。

ステップ 10

[no] max concurrent nodes count

例:

apic1(config-scheduler-recurring)# max concurrent nodes 300

同時に処理できるノード（タスク）の最大数を設定します。指定できる範囲は 0 ～ 65535 です。ノード数を制限しない場合は 0 に設定します。

ステップ 11

[no] max running time time

例:

apic1(config-scheduler-recurring)# max running time 00:01:30:00

dd:hh:mm:ss の形式でタスクの最大実行時間を設定します。指定できる範囲は 0 ～ 65535 です。時間の制限がない場合は 0 に設定します。

ステップ 12

[no] time start { daily HH:MM | weekly （使用状況を参照） HH:MM}

例:

apic1(config-scheduler-recurring)# time start weekly wednesday 12:30

期間（毎日または毎週）と開始時刻を設定します。weekly を選択した場合、次のオプションから選択します。

  • monday

  • tuesday

  • wednesday

  • thursday

  • friday

  • saturday

  • sunday

  • even-day

  • odd-day

  • every-day

例

次に、毎週水曜日に実行するよう繰り返しスケジューラを設定する例を示します。 


apic1# configure
apic1(config)# scheduler controller schedule myScheduler
apic1(config-scheduler)# description 'This is my scheduler'
apic1(config-scheduler)# recurring window myRecurringWindow
apic1(config-scheduler-recurring)# max concurrent nodes 300
apic1(config-scheduler-recurring)# max running time 00:01:30:00
apic1(config-scheduler-recurring)# time start weekly wednesday 12:30

REST API を使用したスケジューラ―の構成

スケジュールにより、設定のインポート/エクスポートまたはテクニカル サポートの収集などの操作を 1 つ以上の指定した時間帯に発生させることができます。

スケジュールには、一連のタイム ウィンドウ（オカレンス）が含まれます。これらのウィンドウは、1 回だけ発生させるか、または毎週指定した日時に繰り返し発生させることができます。期間や実行するタスクの最大数などのウィンドウで定義されているオプションにより、スケジュール設定されたタスクの実行時期が決定されます。たとえば、最大時間長またはタスク数に達したため特定のメンテナンス時間帯に変更を展開できない場合、この展開は次のメンテナンス時間に持ち越されます。

各スケジュールは、APIC が 1 つまたは複数のメンテナンス時間帯に入っているかどうか、定期的に確認します。入っている場合、スケジュールはメンテナンス ポリシーで指定された制限に対し適切な展開を実行します。

スケジュールには、スケジュールに関連付けられたメンテナンス時間を決定する 1 つ以上のオカレンスが含まれています。オカレンスは次のいずれかになります。

  • 絶対（1 回）時間帯：絶対時間帯は、1 回しか発生しないスケジュールを定義します。これらの時間帯は、その時間帯の最大時間長まで、または時間帯の中で実行可能なタスクの最大数に達するまで継続されます。

  • 繰り返し時間帯：繰り返し時間帯は、繰り返しのスケジュールを定義します。この時間帯は、タスクの最大数に達するまで、または時間帯に指定された日の終わりに達するまで継続します。

手順

ステップ 1

リポジトリにスイッチ イメージをダウンロードします。

例:

POST URL: https://<ip address>/api/node/mo/uni/fabric.xml
<firmwareRepoP>
	<firmwareOSource name="Switch_Image_download" proto="http" url="http://<ip address>/<ver-no>"/>
</firmwareRepoP>

ステップ 2

次のポリシーを、POST 送信することにより、ノード ID が 101、102、103、104 の スイッチから構成されるファームウェア グループを作成し、ノード ID 101、102、103、104 によるメンテナンス グループを作成します。

例:

POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<fabricInst>
<firmwareFwP
    name="AllswitchesFwP"
    version="<ver-no>"
    ignoreCompat="true">
</firmwareFwP>

<firmwareFwGrp
    name="AllswitchesFwGrp" >
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<firmwareRsFwgrpp
    tnFirmwareFwPName="AllswitchesFwP">
</firmwareRsFwgrpp>
</firmwareFwGrp>

<maintMaintP
    name="AllswitchesMaintP"
    runMode="pauseOnlyOnFailures" >
</maintMaintP>

<maintMaintGrp
    name="AllswitchesMaintGrp">
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<maintRsMgrpp
    tnMaintMaintPName="AllswitchesMaintP">
</maintRsMgrpp>
</maintMaintGrp>
</fabricInst>

ステップ 3

スケジューラに基づいてすべてのスイッチをアップグレードするには、次のようなポリシーをポストします。

例:

POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<trigSchedP annotation="" descr="" dn="uni/fabric/schedp-EveryEightHours" name="EveryEightHours" nameAlias="" ownerKey="" ownerTag="" userdom="">
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="17" minute="0" name="third" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="9" minute="0" name="second" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="1" minute="0" name="first" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
</trigSchedP>

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

Feedbackフィードバック

シスコに問い合わせ