以下は 2025 年 2 月 19 日に開催した わかる！ACI の APIC と switch におけるアップグレード入門 の Q＆A セッションでいただいた質問とその回答となります。多数のご質問誠にありがとうございました。なお、当日の資料や録画は以下より確認可能です。
プレゼンテーション資料 ウェビナー録画 イベント概要
質問 1. APIC のアップグレードが完了するまでには実際どれくらいの時間がかかりますか。
APIC のアップグレードを開始してから完了するまでのおおよその目安は約 3 時間です。データサイズにも依存しますのであくまで目安となります。
質問 2. FTAG とはなんですか。
Forwarding TAG (転送タグ) の略です。ACI では、FTAG ディストリビューションツリーを使用して ACI ファブリック内でマルチデスティネーショントラフィックを転送します。詳細は以下のドキュメントをご確認ください。
Deploying IP Multicast in ACI and Multi-Site Fabrics (p.10 FTAG Distribution Trees)
質問 3. アップグレードフロースライドのステップ 3 で、大きい ISIS メトリックより、なにを実現しようとするんでしょうか。
大きい ISIS メトリックを一時的に利用することで、トラフィックを片寄して影響が受ける機器に到来しないようにしています。（オーバーロードモード）
質問 4. シャードって、データ（設定も含め）をカップセルカする基本単位でしょうか。
ご認識のとおりです。ACI 内の設定等の情報は Shard (32 個)に分割され、各 Shard は 3 つのコピー（レプリカ）を作成し、3 台の APICに分散保存されます。仮に 2 台構成でこの分散情報を格納している場合、1 台の APIC に障害が発生し情報の不整合が発生した場合に、どちらの情報が正しいかの判断がつきません。3 台構成であれば 1 台の APIC に障害が発生し情報が破損しても、残り 2 台の情報は正常であるため正しい情報がどれかの判断がつくようになります。
質問 5. SMU イメージは、どこで、どう検索して、ダウンロードできますか。
SMU は通常のダウンロードページからはダウンロードできませんので TAC にご相談ください。また、すべての不具合に SMU が提供されているものではありませんのでその点はご理解ください。
質問 6. APIC が古いバージョンの状態で、新しいバージョンの Switch をファブリックに参加させたい場合は、APIC のバージョンアップ後に Switchを参加させればよいでしょうか。
ご認識のとおりです。
質問 7. ACI Pre-Upgrade Validation Scriptは、CLI でどうやって走れますか。
GitHub にて ACI Pre-Upgrade Validation Script の実行方法が記載されておりますため、詳細は以下をご参照ください。
ACI Pre-Upgrade Validation Script (Getting Started)
質問 8. ACI Upgrade は極力短い期間で完了することが望ましいと考えてはおりますが、作業の都合上 数ヶ月にまたがって実施しなければいけないことがあります。その際にどれくらいの期間複数バージョンを混在させておくことが許容されるのか、目安があれば教えてください。また混在させておくことのリスクがあれば合わせて教えてください。
バージョンの混在環境は継続的に ACI Fabric を運用することを意図したものではありませんので、可能な限り早くバージョンを揃えるようにしてください。混在させておく場合、許容される作業が限定的となります。また、vPC ペアとなるスイッチでは通常のスイッチで許容されている操作が適用外となりますので早めにバージョンを揃えるようにしてください。
詳細は以下をご参照ください。
ACI: Mixed Versions on Cisco ACI Switches について
質問 9. CIMC をアップグレードする際に APIC 側で何か操作は必要でしょうか。
APIC 側での特別な操作は不要で、APIC の decommission や commission も必要ありません。
質問 10. スイッチのアップグレード時のスイッチグループ分けのベストプラクティスはありますか。
下記のドキュメントをご確認ください。
Cisco APIC インストールおよび ACI アップグレード、ダウングレード ガイド
(ACI スイッチ アップグレードとダウングレードのガイドライン)
質問 11. AES 暗号化によるバックアップ情報は、どっちに格納されて、保存しますか？ローカル保存であれば、（アップグレードが失敗した場合）依然として復旧できますでしょうか。
バックアップは必ずリモートサーバーなどに保存してください。
質問 12. Graceful Upgrade の選択基準についてですが、Upgrade 中の通信影響は極力短い方が望ましいので、常に有効にした方が良いように感じますが、どうしても必要な場合にのみ使用するのは何か理由がありますでしょうか。
Graceful Upgrade の場合、アップグレードに時間がかかるようになります。Graceful Upgrade で何か問題があった際に行うトラブルシューティングが複雑となりますので、必要な場合にのみ有効化するようにしてください。本番環境で Graceful Upgrade を実施する前に事前に検証されることを強くおすすめします。
質問 13. 高度オプションの Compatibility Check で default 値から変えた際、ラボ環境での使用ということですが、何が困りますか。
デフォルト値から変更しますとサポートされていないアップグレードパスが利用できるようになり、アップグレードの際に想定外の問題が発生する可能性があります。
質問 14. Upgrade に失敗した場合、どんなログを取得すれば良いでしょうか。
任意の APIC 1 台にて tac-outputs、APIC 全台の On-demand Techsupport（取得不可であれば local techsupport）を必ずご取得ください。スイッチの upgrade に失敗した場合は該当機器の On-demand Tehcsupport（取得不可であれば local techsupport）も採取ください。
質問 15. アップグレードが停止して、仮に以前のバージョンに切り戻して APIC クラスターが完全に壊れてしまった場合、どうなりますか。
正常時の設定情報のバックアップがあればシステムを中断することなく復旧できる場合があります。正常時の設定情報のバックアップがない場合は ACI fabric の初期化が必要となり、その場合は通信影響が発生します。
質問 16. メンテナンスタイムを確保できないファブリックをアップグレードする場合、夜間帯等ではなく問い合わせが可能な日中（最繁期）にアップグレードする方が良いでしょうか。
日中にアップグレードして問題が発生した場合でも、障害の内容によってシビラティが異なりますため、恐れ入りますが即自回答となるかはお約束できかねます。基本的には利用者が少ない時間帯でのアップグレードを推奨します。
質問 17. アップグレードに失敗した際に行うログ取得操作について、通信影響は考慮しなくてよいでしょうか。
APIC で取得するログは基本的にデータプレーンの通信に影響を及ぼしません。
公開の難しい情報などは掲載を見送らせていただくこともございます。ご容赦いただけますと幸いです。
当オンラインセミナーのご参加、誠にありがとうございました。 またのご参加をお待ちしております。
