この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Application Policy Infrastructure Controller (APIC) アプライアンスは、クラスタに配置されます。Cisco ACI ファブリックを制御するためには、クラスタ内で少なくとも 3台のコントローラを設定します。コントローラ クラスタの最終的なサイズは、ACI 導入のサイズに直接正比例し、トランザクション レートの要件によって決まります。クラスタ内のコントローラは、あらゆるユーザのあらゆる操作に対応できます。また、クラスタのコントローラは、透過的に追加または削除できます。
このセクションでは、APIC クラスタの拡張、契約、および回復に関連する例を示します。
Cisco APIC のクラスタの拡大とは、正当な境界内で、クラスタ サイズを N から N+1 へサイズの不一致を増加させる動作です。オペレータが管理クラスタ サイズを設定し、適切なクラスタ ID の APIC を接続すると、クラスタが拡張を実行します。
クラスタの拡大時は、APIC コントローラを物理的に接続した順序に関係なく、APIC の ID 番号順に検出および拡大が実行されます。たとえば、APIC2 が APIC1 の後で検出され、APIC3 が APIC2 の後に検出され、以降、クラスタに追加する必要のあるすべての APIC が検出されるまで続行されます。各 APIC が順番に検出されるとともに、単一または複数のデータ パスが確立され、パスに沿ってすべてのスイッチがファブリックに参加します。拡張プロセスは稼動中のクラスタ サイズが管理クラスタ サイズと同等に達するまで続行されます。
Cisco APIC クラスタの縮小とは、正当な境界内で、クラスタ サイズ N から N -1 へサイズの不一致を軽減する動作です。縮小によってクラスタ内の残りの APIC の計算およびメモリの負荷が増大し、解放された APIC クラスタのスロットはオペレータ入力だけで使用できなくなります。
クラスタの縮小の際は、クラスタ内の最後の APIC を最初に解放し、以降逆順で連続的に行います。たとえば、APIC4 は APIC3 の前に解放し、APIC3 は APIC2 の前に解放する必要があります。
Cisco Application Policy Infrastructure Controller (APIC) クラスタは複数の Cisco APIC コントローラで構成され、Cisco Application Centric Infrastructure（ACI）ファブリックに対する統合されたリアルタイム モニタリング、診断および構成管理機能がオペレータに提供されます。最適なシステム パフォーマンスが得られるように、Cisco APIC クラスタを変更する場合は次のガイドラインに使用してください：
クラスタへの変更を開始する前に、必ずその状態を確認してください。クラスタに対して計画した変更を実行するときは、クラスタ内のすべてのコントローラが正常である必要があります。クラスタ内の 1 つ以上の Cisco APIC のヘルス ステータスが「十分に正常」でない場合は、先に進む前にその状況を修復してください。また、Cisco APIC に追加されたクラスタ コントローラが Cisco APIC クラスタ内の他のコントローラと同じファームウェア バージョンを実行しているか確認してください。
クラスタ内には少なくとも 3 つのアクティブな Cisco APIC があり、追加のスタンバイ Cisco APIC があることを推奨します。 Cisco APIC クラスタには、3 ～ 7 個のアクティブな Cisco APICを含めることができます。展開に必要なアクティブな Cisco APIC の数を確認するには、『検証済みスケーラビリティ ガイド』を参照してください。
現在クラスタにない Cisco APIC からのクラスタ情報は無視します。正確なクラスタ情報ではありません。
クラスタ スロットには Cisco APIC ChassisID を含みます。スロットを設定すると、割り当てられたシャーシ ID の Cisco APIC を解放するまでそのスロットは使用できません。
Cisco APIC ファームウェア アップグレードが進行中の場合は、それが完了し、クラスタが完全に適合するまでクラスタへの他の変更はしないでください。
Cisco APIC を移動する際は、最初に正常なクラスタがあることを確認します。Cisco APIC クラスタの状態を確認するには、後にシャット ダウンする Cisco APIC を選択します。Cisco APIC をシャットダウンした後、Cisco APIC に移動し、再接続して、電源を入れます。GUI から、クラスタ内のすべてのコントローラが完全に適合状態に戻すことを確認します。
 （注） |
一度に 1 つの Cisco APIC のみ移動します。 |
一連のリーフ スイッチに接続されている Cisco APIC を別のリーフ スイッチのセットに移動する場合、または Cisco APIC を同じリーフ スイッチ内の別のポートに移動する場合は、まずクラスタが正常であることを確認します。Cisco APIC クラスタの状態を確認したら、移動してクラスタからデコミッションする Cisco APIC を選択します。Cisco APIC がデコミッションされたら、 Cisco APIC を移動してコミッションします。
Cisco APIC クラスタを設定する前に、すべての Cisco APIC のパフォーマンスが同じファームウェア バージョンを実行していることを確認します。異なるバージョンを実行して Cisco APIC のパフォーマンスの最初のクラスタ リングはサポートされていない動作し、クラスタ内の問題が発生する可能性があります。
他のオブジェクトとは異なり、ログ レコード オブジェクトは、いずれかの Cisco APIC のデータベースの 1 つのシャードにのみ保存されます。これらのオブジェクトは、使用停止またはCisco APIC交換すると永久に失われます。
Cisco APICをデコミッションすると、Cisco APIC に保存されていたすべての障害、イベント、および監査ログ履歴が失われます。すべての Cisco APIC を交換すると、すべてのログ履歴が失われます。Cisco APICを移行する前に、ログ履歴を手動でバックアップすることをお勧めします。
APIC クラスタ サイズを拡大するには、次のガイドラインに従ってください。
クラスタの拡大がファブリックのワークロードの要求に影響しないときに、クラスタの拡大を予定します。
クラスタ内の 1 つ以上の APIC コントローラのヘルス ステータスが「十分に正常」でない場合は、先に進む前にその状況を修復してください。
ハードウェア インストレーション ガイドの手順に従って、新しい APIC コントローラを準備します。PING テストでインバンド接続を確認します。
クラスタの目標サイズを既存のクラスタ サイズ コントローラ数に新規コントローラ数を加えた数になるように増やします。たとえば、既存のクラスタ サイズ コントローラの数が 3 で、3 台のコントローラを追加する場合は、新しいクラスタの目標サイズを 6 に設定します。クラスタは、クラスタにすべての新規コントローラが含まれるまで一度にコントローラ 1 台ずつ順にサイズを増やします。
（注） |
既存の APIC コントローラが利用できなくなった場合、クラスタの拡大は停止します。クラスタの拡大を進める前に、この問題を解決します。 |
各アプライアンスの追加時に APIC が同期化しなければならないデータ量によって、拡大処理を完了するために必要な時間はアプライアンスごとに 10 分を超える可能性があります。クラスタが正常に拡大すると、APIC の運用サイズと目標サイズが同じになります。
（注） |
APIC がクラスタの拡大を完了するまでは、クラスタに追加の変更をしないようにします。 |
Cisco Application Policy Infrastructure Controller（APIC）クラスタのサイズを縮小し、クラスタから削除されたCisco APICを解放するには、次のガイドラインに従います。
（注） |
縮小したクラスタから Cisco APICを解放し、電源オフする正しい手順を実行しないと、予期しない結果を招く可能性があります。認識されていない Cisco APICをファブリックに接続されたままにしないでください。 |
クラスタ サイズを縮小した場合、残りCisco APICの負荷が増加します。クラスタの同期がファブリックのワークロードの要求に影響しないときに、 Cisco APICサイズの縮小を予定します。
クラスタ内の 1 つ以上の Cisco APIC のヘルス ステータスが「十分に正常」でない場合は、先に進む前にその状況を修復してください。
クラスタの目標サイズを新たな低い値に減らします。たとえば、既存のクラスタ サイズが 6 で、3 台のコントローラを削除する場合は、クラスタの目標サイズを 3 に減らします。
既存のクラスタ内でコントローラ識別子の番号が最大のものから、APICを 1 台ずつ、解放、電源オフ、接続解除し、クラスタが新規の小さい目標サイズになるまで行います。
各コントローラを解放および削除するごとに、Cisco APIC はクラスタを同期します。
（注） |
クラスタから Cisco APICをデコミッションした後に、直ちに電源をオフにし、再発見を予防するためにファブリックから切断します。サービスを回復する前に、全消去を実行して工場出荷時の状態にリセットします。 切断が遅延し、デコミッションされたコントローラが再検出された場合は、次の手順に従って削除します：
|
既存の Cisco APICが使用できなくなると、クラスタの同期が停止します。クラスタの同期を進める前に、この問題を解決します。
コントローラの削除の際に Cisco APIC が同期すべきデータの量により、各コントローラの解放とクラスタの同期を完了するために要する時間は、コントローラごとに 10 分以上になる可能性があります。
（注） |
クラスタに追加の変更を行う前に、必要な解放手順全体を完了し、Cisco APIC がクラスタの同期を完了できるようにしてください。 |
Cisco APIC コントローラを交換するには、次の注意事項に従ってください。
クラスタの Cisco APIC コントローラのヘルス ステータスが [十分に適合] ではない場合、続行する前に問題を解決します。
クラスタの同期がファブリックのワークロードの要求に影響しないときに、Cisco APIC コントローラの交換を予定します。
（注） |
既存の Cisco APIC コントローラが使用できなくなると、クラスタの同期が停止します。クラスタの同期を進める前に、この問題を解決します。 |
次の順序で交換手順を実行します。
APIC の設定パラメータとイメージが交換されることに注意してください。
交換する APIC をデコミッションします（GUI を使用したクラスタでの Cisco APIC のデコミッション を参照）
交換される APIC と同じ設定およびイメージを使用して、交換 APIC をコミッションします（GUI を使用したクラスタの Cisco APIC のコミッショニング を参照）
ハードウェア インストレーション ガイドの手順に従って、Cisco APIC コントローラの交換を準備します。PING テストでインバンド接続を確認します。
（注） |
交換する前に Cisco APIC コントローラを解放しないと、クラスタによる交換コントローラの吸収が妨げられます。さらに、解放された Cisco APIC コントローラを稼働状態に戻す前に、全消去を実行して工場出荷時の状態にリセットします。 |
データ量によって Cisco APIC はコントローラの交換時に同期する必要があり、交換が完了するまでに交換コントローラごとに 10 分以上かかることがあります。交換コントローラとクラスタが正常に同期されると、Cisco APIC 動作サイズと目標サイズは未変更のままです。
（注） |
Cisco APIC がクラスタの同期を完了するまで、クラスタに追加の変更を加えないでください。 |
UUID とファブリックのドメイン名は、リブートしても Cisco APIC コントローラに保持されます。ただし、初期状態にリブートするとこの情報は削除されます。Cisco APIC コントローラを 1 つのファブリックから別のファブリックへ移動する場合、そのコントローラを異なる Cisco ACI ファブリックに追加する前に初期状態にリブートする必要があります。
この手順では、既存のクラスタに 1 つ以上の APIC を追加します。この手順は、Cisco APIC リリース 6.0(2) より前のリリースに適用されます。リリース 6.0(2) でクラスタを拡張するには、後続の手順で詳しく説明するように、[ノードの追加（Add Node）] オプションを使用できます。
最初に、クラスタに追加する Cisco APIC を設定する必要があります。Cisco APIC の設定の詳細については、Cisco APIC のセットアップ を参照してください。
|
ステップ 1 |
メニュー バーで、 を選択します。 |
||
|
ステップ 2 |
[ナビゲーション（Navigation）] ウィンドウで、 を展開します。 apic_name の場合、拡大したいクラスタ内にある Cisco APIC を選択する必要があります。 |
||
|
ステップ 3 |
クラスタの縮小に進む前に、クラスタのヘルス ステータスが [Fully Fit] であることを確認します。 |
||
|
ステップ 4 |
[Work] ペインで、 をクリックします。 |
||
|
ステップ 5 |
[Change Cluster Size] ダイアログボックスの、[Target Cluster Administrative Size] フィールドで、目的のクラスタ サイズの数字を選択します。Submit をクリックします。
|
||
|
ステップ 6 |
[Confirmation] ダイアログボックスで、[Yes] をクリックします。 |
||
|
ステップ 7 |
クラスタに追加するすべての Cisco APIC コントローラを物理的に接続します。 |
||
|
ステップ 8 |
Cisco APIC が動作状態にあり、各コントローラのヘルス ステータスが Fully Fit であることを確認します。 |
Cisco APIC リリース 6.0(2) で導入された [ノードの追加（Add Node）] オプションを使用してクラスタを拡張するには、既存の Cisco Application Policy Infrastructure Controller （APIC）クラスタでこの手順に従います。6.0(2) より前の Cisco APIC リリースでクラスタを拡張するには、前の手順を参照してください。
[ノードの追加（Add Node）] オプションは、Cisco APIC をクラスタに追加するためのより簡単で直接的な方法です。
追加するノードがクリーンなノードであるか、 工場出荷時の状態にリセットされていることを確認します。
[全般（General）] ペインで現在のクラスタ サイズを確認します。N の場合、ノードが正常に追加されると、サイズは N+1 になります。
|
ステップ 1 |
メニュー バーで、 を選択します。[ナビゲーション（Navigation）] ウィンドウで、を展開します。 |
|
ステップ 2 |
[アクティブ コントローラ（Active Controllers）] ペインで、[アクション（Actions）] ボタンをクリックし、[ノードの追加（Add Node）] オプションを選択します。 [ノードの追加（Add Node）] 画面が表示されます。 |
|
ステップ 3 |
[ノードの追加（Add Node）] 画面で、以下の詳細を入力します： [コントローラの種類（Controller Type）] を選択します。選択に基づいて、関連するサブステップに進みます。 IPv6 アドレスをサポートする必要がある場合は、 [有効（Enabled）] チェックボックスをオンにします。 |
|
ステップ 4 |
[適用（Apply）] をクリックします。 |
新しく追加されたコントローラが [未承認のコントローラ（Unauthorized Controllers）] ペインに表示されます。最新のコントローラがクラスタの他のコントローラとともに [アクティブなコントローラ（Active Controllers）] ペインに表示されるまで数分待ちます。
また、[一般（General）] ペインの [現在のサイズ（Current Size）] と [ターゲットサイズ（Target Size）] を確認します。表示される数は、最新のノードの追加で更新されます。
この手順により、クラスタ サイズが縮小されます。この手順は、Cisco APIC リリース 6.0(2) より前のリリースに適用されます。リリース 6.0(2) でクラスタを縮小するには、後続の手順で説明する [ノードの削除（Delete Node）] オプションを使用できます。
|
ステップ 1 |
メニューバーで、 を選択します。Navigation ウィンドウで、 を展開します。 クラスタ内にある apic_name で、これから解放するコントローラ以外のものを選択します。 |
||
|
ステップ 2 |
クラスタの縮小に進む前に、クラスタのヘルス ステータスが [Fully Fit] であることを確認します。 |
||
|
ステップ 3 |
[Work] ペインで、 をクリックします。 |
||
|
ステップ 4 |
[Change Cluster Size] ダイアログボックスの [Target Cluster Administrative Size] フィールドで、縮小したいクラスタの目標数を選択します。Submit をクリックします。
|
||
|
ステップ 5 |
[作業（Work）] ペインの [アクティブ コントローラ（Active Controller）] 領域で、クラスタ内の最後の APIC を選択します。 例: |
||
|
ステップ 6 |
デコミッションするコントローラを右クリックして、[デコミッション（Decommission）] を右クリックします。[確認 (Confirmation)] ダイアログ ボックスが表示されたら、[はい (Yes)] をクリックします。 |
||
|
ステップ 7 |
コントローラ ID の番号で最大から最小に向かう正しい順序でクラスタ内のすべての APICについて、上記のコントローラを 1 つずつ解放する手順を繰り返します。
|
Cisco APIC リリース 6.0(2) で導入された [ノードの 削除（Delete Node）] オプションを使用してクラスタを縮小するには、次の手順に従います。6.0(2) より前の APIC リリースでクラスタを縮小するには、前の手順を参照してください。
この手順を使用すれば、APIC クラスタから 1 つ以上のノードを削除できます。
[ノードの削除（Delete Node）] オプションには、クラスタ サイズの縮小とノードのデコミッションの 2 つの操作が含まれます。
（注） |
2 ノード クラスタはサポートされていません。3 ノード クラスタから 1 つのノードを削除することはできません。推奨される最小クラスタ サイズは 3 です。 |
（注） |
Cisco APIC 6.1(2) 以降では、クラスタからスタンバイ ノードを削除できます。スタンバイ ノードを削除したら、クラスタに追加する前にクリーン リブートを実行する必要があります。 |
|
ステップ 1 |
メニュー バーで、 を選択します。[ナビゲーション（Navigation）] ウィンドウで、を展開します。 |
||||
|
ステップ 2 |
[アクティブ コントローラ（Active Controllers）] ペインで、必要なチェックボックスをオンにして、削除するコントローラを選択します。 |
||||
|
ステップ 3 |
[アクション（Actions）] ボタンをクリックし、[ノードの削除（Delete Node）] オプションを選択します。 |
||||
|
ステップ 4 |
ポップアップ画面で [OK] をクリックして、削除を確認します。 強制オプションを選択しても影響はありません。Cisco APIC リリース 6.0(2) ではサポートされていないため、無操作のオプションです。
[全般（General）] ペインの [現在のサイズ（Current Size）] と [ターゲット サイズ（Target Size）] を確認します。表示されるサイズは、以前より 1 つ小さくなります。以前のクラスタサイズが N であった場合には、N-1 になります。
|
クラスタから APIC をデコミッションした後に、コントローラの電源をオフにし、ファブリックから切断します。
数分待ってから、クラスタの残りのノードの [正常性状態（Health State）] が [完全に適合（Fully fit）] と表示されていることを確認してから、さらにアクションを実行します。
Cisco APIC コントローラのコミッションとデコミッション
APIC をコミッショニングするには、次の手順を使用します。この手順は、Cisco APIC リリース 6.0(2) より前のリリースに適用されます。リリース 6.0(2) では、試運転ワークフローが変更されました。詳細については、後続のセクションを参照してください。
|
ステップ 1 |
メニュー バーで、 を選択します。 |
|
ステップ 2 |
Navigation ウィンドウで、 を展開します。 |
|
ステップ 3 |
継続する前に、[作業 (Work)] ウィンドウの [APIC クラスタ (APIC Cluster)] から、[アクティブ コントローラ (Active Controllers)] サマリ テーブルのクラスタの [健全性状態 (Health State)] が [完全に適合 (Fully Fit)] になっていることを確認します。 |
|
ステップ 4 |
[作業 (Work)] ウィンドウで、[未登録 (Unregistered)] と [動作状態 (Operational State)] カラムに表示されている、デコミッションされたコントローラを右クリックし、[コミッション (Commission)] を選択します。 |
|
ステップ 5 |
Confirmation ダイアログボックスで Yes をクリックします。 |
|
ステップ 6 |
コミッションされた Cisco APIC が動作状態であり、ヘルス ステータスが、Fully Fit であることを確認します。 |
既存の Cisco Application Policy Infrastructure Controller （APIC）クラスタでこの手順に従い、そのクラスタで Cisco APIC をコミッションします。この手順は、Cisco APIC リリース 6.0(2) に当てはまります。リリース 6.0(2) から、コミッション ワークフローが強化されました。これは、既存のコントローラのプロビジョニングと、RMA（返品承認）にも使用できます。
|
ステップ 1 |
メニュー バーで、 を選択します。 |
|
ステップ 2 |
[ナビゲーション（Navigation）] ウィンドウで、を展開します。 |
|
ステップ 3 |
[アクティブ コントローラ（Active Controllers）] テーブルからデコミッションされた Cisco APIC を選択します。 |
|
ステップ 4 |
[アクティブ コントローラ（Active Controllers） ] テーブルで、各 Cisco APICの行の末尾に表示される [アクション（Actions） ] アイコン（3 つのドット）をクリックします。表示されたオプションから、 [コミッション（Commission）]をクリックします。 [コミッション（Commission）] ダイアログボックスが表示されます。 |
|
ステップ 5 |
[コミッション（Commission）] 画面に以下の詳細を入力します。 [コントローラ タイプ（Controller Type）]を選択します。選択に基づいて、関連するサブステップに進みます。 IPv6 アドレスをサポートする必要がある場合は、 [有効（Enabled）] チェックボックスをオンにします。 |
|
ステップ 6 |
[適用（Apply）] をクリックします。 |
|
ステップ 7 |
コミッションされた Cisco APIC が動作状態であり、ヘルス ステータスが、Fully Fit であることを確認します。 |
この手順では、クラスタ内の Cisco Application Policy Infrastructure Controller（APIC）をデコミッションします。この手順は、Cisco APIC リリース 6.0(2) より前の APIC リリースに適用されます。リリース 6.0(2) で APIC をデコミッションするには、次の手順を参照してください。
（注） |
他のオブジェクトとは異なり、ログ レコード オブジェクトは、いずれかの Cisco APIC のデータベースの 1 つのシャードにのみ保存されます。これらのオブジェクトは、使用停止またはCisco APIC交換すると永久に失われます。 |
|
ステップ 1 |
メニューバーで、 を選択します。 |
||
|
ステップ 2 |
[ナビゲーション（Navigation）] ウィンドウで、 を展開します。 クラスタ内にある [apic_name] で、これから解放するコントローラ以外のものを選択します。 [ノードで確認されるクラスタ (Cluster as Seen by Node)] ウィンドウは、[作業 (Work)] ペインにコントローラの詳細と 3 つのタブ ([APIC クラスタ (APIC Cluster)]、および [スタンバイ APIC (Standby APIC)]) が表示されます。 |
||
|
ステップ 3 |
継続する前に、[作業 (Work)] ウィンドウで、[APIC クラスタ (APIC Cluster)] ([アクティブ コントローラ (Active Controllers)] サマリ テーブルの [健全性状態 (Health State)]) が [完全に適合 (Fully Fit)] になっていることを確認します。 |
||
|
ステップ 4 |
[作業 (Work)] ペインの [APIC クラスタ (APIC Cluster)] タブにある [アクティブ コントローラ (Active Controllers)] テーブルで、デコミッションするコントローラを右クリックし、[デコミッション (Decommission)] を選択します。 |
||
|
ステップ 5 |
Yes をクリックします。 解放されたコントローラは [Operational State] 列に [Unregistered] と表示されます。コントローラは稼動対象外になり、Work ウィンドウには表示されなくなります。
|
この手順では、クラスタ内の Cisco APIC をデコミッションします。この手順は、Cisco APIC リリース 6.0(2) に当てはまります。リリース 6.0(2) より前のリリースの Cisco APIC をデコミッションするには、前述の手順を使用します。
（注） |
他のオブジェクトとは異なり、ログ レコード オブジェクトは、いずれかの Cisco APIC のデータベースの 1 つのシャードにのみ保存されます。これらのオブジェクトは、使用停止またはCisco APIC交換すると永久に失われます。 |
|
ステップ 1 |
メニュー バーで、 を選択します。 |
||
|
ステップ 2 |
[ナビゲーション（Navigation）] ウィンドウで、 を展開します。 クラスタ内にある [apic_name] で、これから解放するコントローラ以外のものを選択します。 [ノードから見たクラスタ（Cluster as Seen by Node）] ウィンドウでは、[作業 （Work）] ペインにコントローラの詳細と 3 つのタブ（[APIC クラスタ（APIC Cluster）]、および [スタンバイ APIC （Standby APIC）]）が表示されます。 |
||
|
ステップ 3 |
継続する前に、[作業（Work）] ウィンドウで、クラスタの [正常性状態（Health State）]（[アクティブ コントローラ（Active Controllers）] サマリ テーブルに示されているもの）が [完全に適合（Fully Fit）] になっていることを確認します。 |
||
|
ステップ 4 |
[アクティブ コントローラ（Active Controllers）] テーブルで、各 APIC の行の最後に表示される [アクション（Actions）] アイコン（3 つのドット）をクリックします。[デコミッション（Decommission）] オプションを選択します。 [デコミッション（Decommission）] ダイアログ ボックスが表示されます。 |
||
|
ステップ 5 |
[OK] をクリックします。 Cisco APIC リリース 6.0(2) ではサポートされていないため、[強制（Force）] の [有効（Enabled）] チェックボックスは 操作不可 オプションです。 解放されたコントローラは [Operational State] 列に [Unregistered] と表示されます。コントローラは稼動対象外になり、Work ウィンドウには表示されなくなります。
|
クラスタ内の APIC のシャットダウン
クラスタですべての APIC パフォーマンスをシャットダウンする前に、APIC クラスタが健全な状態であり、すべての APIC が完全に適合していることを確認します。このプロセスを開始したら、このプロセス中に設定の変更を行わないことをお勧めします。クラスタのすべての APIC をグレースフルにシャット ダウンするには、次の手順を使用します。
|
ステップ 1 |
アプライアンス ID1 で Cisco APIC にログインします。 |
|
ステップ 2 |
メニュー バーで、 を選択します。 |
|
ステップ 3 |
[ナビゲーション] ペインで、 を展開します。 クラスタ内の三番目のノードを選択する必要があります。 |
|
ステップ 4 |
コントローラを右クリックし、[シャット ダウン] をクリックします。 |
|
ステップ 5 |
クラスタの二番目の APIC をシャットダウンするには手順を繰り返します。 |
|
ステップ 6 |
クラスタの最初の APIC の Cisco IMC にログインし、APIC をシャットダウンします。 |
|
ステップ 7 |
を選択します。 クラスタの 3 つすべての APIC をシャットダウンしました。 |
クラスタに戻り、apic のパフォーマンスを起動するのにには、次の手順を使用します。
|
ステップ 1 |
クラスタ内の最初の APIC の Cisco IMC にログインします。 |
|
ステップ 2 |
選択 最初 APIC の電源をオンにします。 |
|
ステップ 3 |
APIC し、クラスタ内の 3 番目の APIC の電源を 2 番目の手順を繰り返します。 Apic のパフォーマンスの電源がオンにすべての後にことを確認しますが、apic のパフォーマンスが完全に適合状態ではすべて。Apic のパフォーマンスが完全に適合状態であることを確認した後でのみ、apic 内で、設定変更を行う必要があります。 |
Cold Standby
Cold Standby 機能 Cisco Application Policy Infrastructure Controller(APIC クラスタ用) を使用すれば、クラスタ内の Cisco APIC をアクティブ/スタンバイモードで運用できます。Cisco APIC クラスタでは、指定されたアクティブ状態の Cisco APIC は負荷を共有し、指定されたスタンバイ状態の Cisco APIC はアクティブなクラスタ内の任意の Cisco APIC の置き換えとして動作することができます。
管理者ユーザーとして、Cisco APIC が初めて起動したときに Cold Standby 機能をセット アップできます。クラスタ内には少なくとも 3 基のアクティブ状態の Cisco APIC があり、1 基以上のスタンバイ状態の Cisco APIC があるようにすることを推奨します。管理者ユーザーとして、アクティブな Cisco APIC をスタンバイ状態の Cisco APIC で置き換えるには、切り替えを開始できます。
スタンバイ Cisco Application Policy Infrastructure Controller（APIC）に対する注意事項と制限事項：
スタンバイ Cisco APIC を追加するには 3 つのアクティブ Cisco APIC が必要です。
スタンバイ Cisco APIC は、初期セットアップ中にスタンバイ Cisco APIC がクラスタに参加するときに、クラスタの同じファームウェア バージョンで実行する必要があります。
アップグレード プロセス中に、Cisco APIC のすべてのアクティブなパフォーマンスをアップグレードすると、スタンバイ Cisco APIC もありますが自動的にアップグレードします。
初期設定時に、スタンバイ Cisco APIC に ID が割り当てられます。スタンバイ Cisco APIC がアクティブ Cisco APIC に切り替えられた後、スタンバイ Cisco APIC（新しくアクティブになった）は、置き換えられた（前にアクティブだった）Cisco APIC の ID の使用を開始します。
管理者ログインはスタンバイ Cisco APIC で有効ではありません。Cold Standby Cisco APIC をトラブルシューティングをするには、rescue-user として SSH を使用して、スタンバイにログインする必要があります。
切り替え中、置き換えられたアクティブ Cisco APIC は、置き換えられた Cisco APIC への接続を防ぐため、電源オフにする必要があります。
次の条件が失敗する経由でスイッチします。
スタンバイ Cisco APIC に接続がない場合。
スタンバイ Cisco APIC のファームウェアのバージョンがアクティブ クラスタと同じではない場合。
スタンバイ Cisco APIC をアクティブに切り替えた後、必要に応じて別のスタンバイ Cisco APIC をセットアップできます。
スタンバイの OOB IP アドレスを保留する（新しいアクティブ）がオンの場合、スタンバイ（新しいアクティブ）Cisco APICは元のスタンバイのアウトオブバンド管理 IP アドレスを保留します。
[スタンバイ（新しいアクティブ）の OOB IP アドレスを保持する（Retain OOB IP address for Standby（new active）] がオンでない場合：
1 つのアクティブな Cisco APIC がダウンした場合：スタンバイ（新しいアクティブ）Cisco APICは古いアクティブな Cisco APIC のアウトオブバンド管理 IP を使用します。
複数のアクティブ Cisco APIC がダウンしている場合：スタンバイ（新しいアクティブ）Cisco APIC は、アクティブな Cisco APIC のアウトオブバンド管理 IP アドレスを使用しようとしますが、アクティブな Cisco APIC のアウトオブバンド管理 IP アドレス構成のシャードがマイノリティ状態にある場合は失敗する可能性があります。
Cisco ACI マルチポッド については、古いアクティブ Cisco APIC とスタンバイ Cisco APIC が異なるアウトオブバンド管理 IP サブネットを使用している場合、スタンバイ（新しいアクティブ）では、Cisco APIC が元のスタンバイ アウトオブバンド管理 IP アドレスを保持するオプションをオンにする必要があります。そうしないと、スタンバイ（新しいアクティブ）Cisco APIC へのアウトオブバンド管理 IP 接続が失われます。この状況は、古いアクティブ Cisco APIC とスタンバイ Cisco APIC が異なるポッドにある場合に発生する可能性があります。
この理由でアウトオブバンド管理 IP 接続が失われた場合、または複数のアクティブ Cisco APIC がダウンしている場合は、新しい静的ノード管理 OOB IP アドレスを作成して、新しいアクティブ（以前はスタンバイ）Cisco APIC アウトオブバンド管理 IP アドレスを変更する必要があります。構成を変更するには、クラスタのマイノリティ状態を解除する必要があります。
スタンバイ Cisco APIC はポリシー設定または管理で関係しません。
管理者クレデンシャルを持っている場合でも、スタンバイ Cisco APIC に情報が複製されることはありません。
Cisco APIC をアクティブに昇格させても、スタンバイ Cisco APIC はインバンド管理 IP アドレスを保持しません。正しいインバンド管理 IP アドレスを持つように Cisco APIC を手動で再設定する必要があります。
メニューバーで、 を選択します。
Navigation ウィンドウで、 を展開します。
[作業] ペインで、スタンバイ コントローラが [スタンバイ コントローラ] で表示されます。
スタンバイ APIC 内で現用系 APIC 経由でスイッチするには、次の手順を使用します。
|
ステップ 1 |
メニューバーで、 を選択します。 |
||
|
ステップ 2 |
[ナビゲーション（Navigation）] ウィンドウで、を展開します。 Apic_controller_name 交換されているコントローラの名前以外にする必要があります。 |
||
|
ステップ 3 |
作業 ペインで、ことを確認します、 ヘルス状態 で、現用系コントローラの要約表は、続行する前に、 十分に適合現用系コントローラのことを示します。 |
||
|
ステップ 4 |
をクリックする apic_controller_name スイッチ オーバーします。 |
||
|
ステップ 5 |
[ワーク（Work）] ペインで、置き換えるコントローラの行にある [ ... ] をクリックし、[ 置換（Replace）] を選択します。 |
||
|
ステップ 6 |
ドロップダウンリストから Backup Controller を選択して、Submit をクリックします。 現用系 APIC をスタンバイ APIC に切り替えて、システムを現用系として登録するには、数分かかる場合があります。 |
||
|
ステップ 7 |
上で、スイッチの進行状況を確認します フェールオーバーのステータス フィールドで、 アクティブ コントローラ の要約表。
|
ウォーム スタンバイ
Cisco APIC 6.1(2) 以降、スタンバイ APIC は、コールド スタンバイ APIC とは異なるウォーム スタンバイ APIC として設定できます。アクティブに昇格するまでデータが含まれないコールド スタンバイ APIC とは異なり、ウォーム スタンバイ APIC は、スタンバイ ロールである間、アクティブ APIC ノードからのすべてのデータを常に同期します。これにより、データベースの一部またはすべてが APIC クラスタ全体に分散されているため、ウォーム スタンバイ APIC を使用して APIC クラスタを再構築できます。このようなシナリオのいくつかを以下で説明します。
APIC クラスタは、シャーディングおよびレプリカと呼ばれるデータベース テクノロジを使用します。ACI ファブリックのデータは、シャードと呼ばれる小さな部分に分割され、アクティブな APIC ノードに分散されます。各シャードは、クラスタのサイズに関係なく、最大 3 つのレプリカに複製されます。たとえば、5 つの APIC ノードのクラスタがある場合、1 つのシャードは APIC 1、2、および 3 で複製され、別のシャードは APIC 3、4、および 5 で複製される、などのようになります。そのため、クラスタ内の 3 つ以上の APIC ノードが失われると、アクティブな APIC ノードが残っていても、一部のシャードのデータが完全に失われます。このような場合を考えると、コールド スタンバイ APIC は失われた APIC ノードの代わりになることはできません。それ自体にデータを含まず、残りのアクティブな APIC ノードから失われたシャードを復元できないからです。同様に、クラスタ内のすべての APIC ノードが失われた場合も、失われた APIC ノードの数に関係なく、コールド スタンバイ APIC はそれらを置き換えることができません。
これらのシナリオでは、ウォーム スタンバイ APIC を使用できます。このようなデータ損失シナリオの現実的な例を次に示します。
データ損失のシナリオ 1：
ポッド 1 に APIC 1、2、3 があり、ポッド 2 に APIC 4 と 5 があるマルチポッド展開では、ポッド 1 が災害（洪水、火災、地震など）のためにダウンした場合、 3 つの APIC ノードが失われます。これは、一部のデータベース シャードが完全に失われることを意味します。
データ損失のシナリオ 2：
ポッド 1 と 2 が同じ場所にあり、ポッド 3 と 4 が別の場所にあるマルチポッド展開で、ポッド 1 に APIC 1 と 2、ポッド 2 に APIC 3 と 4、ポッド 3 に APIC 5 と 6、ポッド 4 の APIC 7 があるとします。ポッド 1 と 2 がある場所で障害が発生すると、4 つの APIC（APIC 1、2、3、4）が失われます。これは、一部のデータベースシャードが完全に失われることを意味します。
データ損失のシナリオ 3：
ポッド 1 に APIC 1 と 2 があり、ポッド 2 に APIC 3 があり、ポッド 3 にアクティブな APIC がないマルチポッド展開では、ポッド 1 と 2 が災害のためにダウンすると、ファブリックのすべてのデータが失われます。すべてのアクティブな APIC ノードが失われると、クラスタが削除されるからです。
これらのシナリオで、正常なポッド/サイトにウォーム スタンバイ APIC がある場合には、ウォーム スタンバイ APIC は、すべてのアクティブ APIC ノードからすべてのシャードを同期していたため、失われたデータ シャードを復元し、ファブリックを復元できます。これは、コールド スタンバイ APIC では不可能です。
これらの例は、すべてマルチポッド展開です。これは、単一のポッド展開で、スタンバイ APIC ノードが失われても、クラスタ内の 3 つ以上の APIC ノードまたはすべての APIC ノードが失われる可能性は低いためです。それとは反対に、ウォーム スタンバイ APIC は、マルチポッドとシングル ポット展開の両方で、同様にサポートされ、機能します。
これらの例に示すように、ウォーム スタンバイ APIC で導入された新機能は、特別な障害リカバリです。データベース シャードの一部またはすべてが失われ、APIC クラスタを再構築する必要がありますが、アクティブな APIC ノードの交換が短時間で容易に行えます。これはウォーム APIC とコールド スタンバイ APIC の両方でサポートされています。
1 つのアクティブ APIC ノードをウォームまたはコールド スタンバイ APIC ノードに置き換える必要がある場合、残りの正常なアクティブ APIC ノードの 1 つから置換操作がトリガされます。ただし、データ損失の場合にクラスタを再構築するためのウォーム スタンバイ APIC の昇格は、アクティブな APIC ノードが残っていない可能性があるため、残りの正常なアクティブ APIC ノードを介して実行されません。実際には、ウォーム スタンバイ APIC ノードの 1 つで GUI または REST API を介して実行できます。これにより、ウォーム スタンバイ APIC が常に APIC 1 に昇格され、障害リカバリの開始点になることができます。詳細はGUI を使用したウォーム スタンバイ APIC による障害リカバリを参照してください。
ウォーム スタンバイ APIC が壊滅的なイベントからファブリックを復元できるようにするため、ポッドまたは地理的サイトなどの各障害ドメインに少なくとも 1 つのウォーム スタンバイ APIC ノードを配置することをお勧めします。
ウォーム スタンバイ APIC に対する注意事項と制限事項を以下に示します。
ウォーム スタンバイ APIC は、すべての物理 APIC ノードを持つ APIC クラスタでのみサポートされます。仮想 APIC ノードを持つ APIC クラスタは、スタンバイ APIC をサポートしません。
ウォーム スタンバイ APIC は、直接接続と L3 ネットワーク経由でリモート接続の両方のタイプの APIC 接続でサポートされます。
APIC クラスタは、1 つのタイプのスタンバイ APIC（コールドまたはウォーム）のみをサポートできます。コールド スタンバイ APIC とウォーム スタンバイ APIC は、同じ APIC クラスタに共存できません。デフォルトはコールド スタンバイ APIC に設定されています。スタンバイ APIC ノードがクラスタに追加される前後に、スタンバイ APIC のタイプを変更できます。
APIC クラスタごとに最大 3 つのウォーム スタンバイ APIC ノードがサポートされます。
4 つ以上のコールドスタンバイ APIC ノードがある場合、クラスタのスタンバイ APIC タイプをウォームに変更することはできません。
クラスタ全体を再構築するためのウォーム スタンバイ APIC を使用した障害リカバリは、クラスタにデータ損失がある場合、つまり 3 つ以上のアクティブな APIC ノードが失われ、その結果、一部のシャードの 3 つのレプリカがすべて永久に失われた場合にのみ許可されます。
ポッド間ネットワーク（IPN）のネットワークの問題が原因で 3 つ以上のアクティブな APIC が一時的に失われた場合は、ウォーム スタンバイ APIC ノードを APIC 1 に昇格しないでください。これを行うと、APIC ノードが各ポッドで正常であっても、他のすべての APIC を初期化してクラスタを再構築せざるを得なくなるからです。
ウォーム スタンバイ APIC をサポートしていない 6.1(2) よりも古いバージョンにダウングレードする前に、クラスタのスタンバイ APIC タイプをコールドに変更する必要があります。
コールド スタンバイ APIC のみを備えた Cisco APIC 6.1(2) より前では、スタンバイ APIC ノードのアップグレード（またはダウングレード）は表示されませんでした。スイッチのアップグレードを続行する前に待機する必要はありませんでした。アクティブノードの APIC アップグレードが完了した後、スタンバイ APIC ノードが初期化され、新しいバージョンで起動されました。
Cisco APIC 6.1(2) 以降、スタンバイ APIC ノードがある場合、APIC のアップグレード プロセスは以前よりも少し長くかかることがあります。アップグレード プロセスには、ウォーム スタンバイ APIC とコールド スタンバイ APIC の両方のスタンバイ APIC ノードが明示的に含まれます。これは、データベースがウォーム スタンバイ APIC でバックアップされ、新しいバージョン モデルに一致するように更新されるようにするためです。コールド スタンバイ APIC には更新されるデータは含まれていませんが、同じプロセスがコールド スタンバイ APIC に適用されます。このプロセスはウォーム スタンバイ APIC よりもはるかに高速に完了します。
スタンバイ ノードはクラスタから削除できます。詳細については、クラスタからスタンバイを削除するを参照してください。
Cisco APIC のスタンバイ タイプを変更するには、次の手順を実行します。
|
ステップ 1 |
[システム（System）] > [システムの設定（System Settings）] サブメニューに移動します。 |
|
ステップ 2 |
[ファブリック全体の設定ポリシー（Fabric Wide Settings Policy）] ページで、スタンバイタイプとして [ウォーム（Warm）] または [コールド（Cold）] を選択します。  |
|
ステップ 3 |
[送信（Submit）] をクリックします。 |
|
ステップ 4 |
ウォーム スタンバイのステータスを確認するには、次の手順を実行します。
|
スタンバイ APIC を追加するには、次の手順に従います。
|
ステップ 1 |
メニュー バーで、[System] > [Controllers] の順に選択します。 |
|
ステップ 2 |
[ナビゲーション（Navigation）] ペインで、 [コントローラ（Controllers）] > [apic_name] > [ノードから見たクラスタ（Cluster as Seen by Node）] を展開します。 |
|
ステップ 3 |
[作業（Work）] ペインで、 [アクション（Actions）] > [スタンバイ ノードの追加（Add Standby Node）]をクリックします。 |
|
ステップ 4 |
[コントローラ タイプ（Controller Type）] フィールドで、 [物理（Physical）]を選択します。 |
|
ステップ 5 |
[接続タイプ（Connectivity Type）] フィールドで、 [CMIC]を選択します。 |
|
ステップ 6 |
[CMICの詳細（CMIC Details） ] ペインで、次の詳細を入力します。
|
|
ステップ 7 |
[全般（General）] ペインで、次の詳細を入力します。 |
|
ステップ 8 |
[アウトオブバンドネットワーク（Out of Band Network）] ペインで、次の詳細を入力します。
OOB 管理用に IPv6 アドレスを有効にしている場合は、IPv6 アドレスとゲートウェイを入力します。
|
|
ステップ 9 |
[適用（Apply）] をクリックします。 |
Cisco APIC からウォーム スタンバイを選択して削除するには、次の手順を実行します。
|
ステップ 1 |
メニュー バーで、[System] > [Controllers] の順に選択します。 |
||
|
ステップ 2 |
[ナビゲーション（Navigation）] ウィンドウで、[コントローラ（Controllers）] > apic_controller_name < [ノードから見たクラスタ（Cluster as Seen by Node）] を展開します。 |
||
|
ステップ 3 |
[コントローラ（Controllers）] ペインで、ノードを選択し、 [アクション（Actions）] > [ノードの削除（Delete Nodes）] をクリックします。
|
「ウォーム スタンバイ」セクションで説明したように、ウォーム スタンバイ APIC の使用例の 1 つは、アクティブな APIC ノードとともに一部またはすべてのデータベース情報（シャード）が失われた場合に、APIC クラスタを再構築することです。ウォーム スタンバイ APIC を使用したリカバリが必要なデータ損失シナリオの詳細については、Cisco APIC クラスタのウォーム スタンバイ セクションを参照してください。
APIC クラスタを再構築して、APIC クラスタのデータ損失を引き起こした壊滅的なイベントからファブリックを復元するには、ウォーム スタンバイ APIC ノードの 1 つの GUI または REST API にアクセスし、以下の手順に従います。
このセクションの手順では、スタンバイ ノード自体のデータベース情報を使用して、ウォーム スタンバイ APIC ノードを APIC 1 に昇格させます。ウォーム スタンバイ APIC ノードが APIC 1 に正常に昇格されたら、残りのアクティブおよびスタンバイ（あるいはその両方の）APIC ノードを初期化し、新しいアクティブ APIC 2、APIC 3 などとして検出します。新しい APIC ノードが検出されると、以前はウォーム スタンバイ APIC ノードであった APIC 1 に保存されたデータが、各シャードの新しいレプリカとしてそれらの新しいノードに配布されます。
（注） |
ウォーム スタンバイ APIC ノードが APIC 1 に昇格されると、スタンバイ APIC ノードは、ACI スイッチがスタンバイ ノード（間もなく新しい APIC 1 になる）のみを確認できるように、まだ到達可能な残りのアクティブまたはスタンバイ APIC のインフラ インターフェイスをシャットダウンします。残りのアクティブな APIC ノードとの競合を回避するためです。 |
Cisco APIC の Cisco APIC 障害リカバリを構成するには、次の手順を実行します。
|
ステップ 1 |
https://<standby APIC OoB IP> にアクセスして、ウォーム スタンバイ APIC のいずれかにログインします。管理者ユーザーのパスワードは必須です。 |
||
|
ステップ 2 |
[昇格（Promote）] をクリックして、ウォーム スタンバイ APIC を APIC 1 に昇格させ、APIC クラスタの再構築を開始します。
|
||
|
ステップ 3 |
[イニシエーションの進行状況（Initiation Progress）] ステータスが表示されます。成功すると、アクティブな Cisco APIC が表示されます。GUI は、以前のスタンバイ ノードを新しい APIC 1 として使用する通常の APIC GUI に移行します。この GUI を使用して、次のステップで新しい APIC 2、APIC 3 などを追加します。  |
||
|
ステップ 4 |
各ノードの CLI で、acidiag touch setup を使用して残りの APIC ノードを初期化し、acidiag reboot を実行します 。 |
||
|
ステップ 5 |
新しい APIC 1 の APIC GUI を使用して、初期化された APIC ノードを新しい APIC 2、APIC 3 などとして追加します。詳細については、ノード追加オプションを使用した APIC クラスタの拡大を参照してください。 |
Cisco APIC リリース 6.1(1) 以降では、物理 APIC クラスタから ESXi ホストに展開された仮想 APIC クラスタへの移行がサポートされています（VMware vCenter を使用）。（ESXi ホスト上の）仮想 APIC クラスタから物理 APIC クラスタへの移行もサポートされています。
次に、物理 APIC を仮想 APIC に移行する（およびその逆）ための注意事項と制限事項を示します。
ガイドライン
レイヤ 2 の物理 APIC（ファブリックに直接接続）はレイヤ 2 仮想 APIC に移行でき、レイヤ 2 仮想 APIC はレイヤ 2 物理 APIC に移行できます。レイヤ 3（ファブリックにリモート接続されている）の物理 APIC は、レイヤ 3 仮想 APIC に移行できます。レイヤ 3 の仮想 APIC は、レイヤ 3 の物理 APIC に移行できます。レイヤ 2 APIC からレイヤ 3 APIC への移行（またはその逆）はサポートされていません。
アップグレードが進行中の場合は、移行プロセスを開始しないでください。
移行が進行中の場合は、アップグレードを開始しないでください。
APIC OOB を使用する構成は、移行プロセスの完了後に更新する必要があります。
NDO が構成されている場合は、移行によって OOB IP アドレスとサブネットアドレスが変更されるため、NDO の接続の詳細を更新する必要があります。
SMU が物理 APIC にインストールされている場合、Cisco APIC リリース 6.1(1) の移行（物理 APIC から仮想 APIC へ）は推奨されません。移行を続行する前に、SMU の修正が適用されたイメージにクラスタをアップグレードする必要があります。
app-infra の場合、移行前に ELAM/FTRIAGE の実行中のジョブを停止し、移行が完了した後に再起動します。
制限事項
スタンバイノードの移行はサポートされていません。移行の前に、クラスタからスタンバイ ノードを削除してから移行します。
ミニ ACI ファブリックの移行はサポートされていません。
このセクションでは、移行プロセスの概要を示します。詳細なステップについては、後続のセクションの「物理 APIC から仮想 APIC への移行」の手順を参照してください。
3 ノードクラスタを考えてみます。 つまり、3 つのソースノードがあり、移行の後には 3 つのターゲットノードになります。コントローラ ID 1 の APIC は APIC 1 と見なされます。APIC 1（IP アドレス 172.16.1.1）にログインし、移行プロセスを開始します。
|
APIC |
ソース ノード |
ターゲット ノード |
|---|---|---|
|
APIC 1 |
172.16.1.1 |
172.16.1.11 |
|
APIC 2 |
172.16.1.2 |
172.16.1.12 |
|
APIC 3 |
17.16.1.3 |
172.16.1.13 |
移行プロセスの段階
ソース APIC 1（172.16.1.1）にログインし、移行プロセスを開始します。
ソース ノード APIC 3（172.16.1.3）の移行が開始されます。
APIC 3 の移行が完了しました（ターゲット ノード 172.16.1.13 へ）。
ソース ノード APIC 2（172.16.1.2）の移行が開始されます。
APIC 2 の移行が完了しました（ターゲット ノード 172.16.1.12 へ）。
ターゲット APIC 2 が制御を行い、APIC 1 の移行を有効にします。これはハンドオーバー プロセスと呼ばれ、制御がソース APIC 1（172.16.1.1）からターゲット APIC 2（172.16.1.12）に渡されます。この段階で、新しいウィンドウが表示されます（URL がターゲット APIC 2 にリダイレクトされます）。これは、移行が成功すると、ソース APIC 1 が（移行されたターゲット APIC を持つ）クラスタの一部ではなくなるためです。
移行は逆順で完了されます。つまり、APIC N（例では APIC 3）が最初に移行され、次に APIC N-1（例では APIC 2）、最後に APIC 1 が移行されます。
この手順に従って、物理 APIC クラスタのノードを仮想 APIC クラスタに移行します（またはその逆）。
移行プロセスを開始する前に必要な前提条件は次のとおりです。
クラスタの正常性
現在の APIC クラスタが [完全に適合（Fully fit）] であることを確認します。
全般
送信元と宛先の APIC の日付と時刻が同期されていることを確認します。
すべてのコントローラが Cisco APIC リリース 6.1(1) 上にあり、すべてのスイッチがコントローラと同じバージョンを実行していることを確認します。
送信元ノードとターゲット ノード
直接接続された APIC の移行では、送信元ノードとターゲット ノードの両方が同じレイヤ 2 ネットワーク上にあることを確認します。
リモート接続された APIC の移行では、送信元ノードとターゲット ノードの両方にインフラ ネットワーク接続があることを確認します。つまり、新しいターゲット APIC には、ファブリックのインフラ ネットワークと対話できるように、正しい IPN 構成が必要です。
ターゲット ノードの管理者パスワードは、送信元クラスタと同じです。
ターゲット ノードの OOB IP アドレスは異なる必要がありますが、他のすべてのフィールドは送信元ノードと同じでも異なっていてもかまいません。インフラ アドレスは、レイヤ 2（直接接続）でも同じままです。レイヤ 3（リモート接続）クラスタの場合、展開に基づいて同じにすることも、異なるものにすることもできます。
送信元クラスタとターゲット クラスタの OOB ネットワーキング スタックが一致している必要があります。たとえば、送信元クラスタが OOB にデュアル スタック（IPv4 および IPv6）を使用している場合、ターゲット ノードにもデュアル スタック（IPv4 および IPv6）アドレスの詳細を指定する必要があります。
送信元 APIC と宛先 APIC 間の OOB 接続を確認します。
新しい APIC の OOB コントラクトと到達可能性が正しく設定されていることを確認します。移行プロセスでは、OOB IP アドレスを使用して APIC 間の通信を行います。
仮想 APIC から物理 APIC への移行の場合
物理 APIC ノードが初期設定にリセットされていることを確認します。 acidiag touch setup および acidiag reboot コマンドを使用します。
CIMC の有無にかかわらず移行する場合（物理 APIC に適用）：
|
次の場合... |
手順 ... |
|---|---|
|
CIMC の使用 |
物理 APIC CIMC アドレスが仮想 APIC の OOB ネットワークから到達可能であることを確認します。 |
|
CIMC を使用しない |
工場出荷時のリセット後に物理 APIC で OOB IP アドレスが手動で構成されていることを確認し、接続に OOB オプションを使用します。 |
物理から仮想への移行の場合
VMware vCenter を使用したCisco 仮想 APIC の展開ガイドの手順に従って仮想 APIC ノードを展開したことを確認します。
VMM ドメインの一部である vCenter に仮想 APIC が展開されている場合は、仮想 APIC が展開されている ESXi ホストに接続されているインターフェイスで設定されている AEP でインフラストラクチャ VLAN が有効になっていることを確認します。
|
ステップ 1 |
[ノードから見たクラスタ（Cluster as Seen by Node）] 画面で、 [移行（Migrate）] をクリックします（ [クラスタの概要（Cluster Overview）] 領域に表示されます）。 クラスタ内の使用可能なすべてのコントローラが表示されます。
|
||
|
ステップ 2 |
[検証（Validate）] 列の横にある鉛筆アイコンをクリックして、選択したコントローラの移行プロセスを開始します。 [ノードの追加（Add Node）] 画面が表示されます。 |
||
|
ステップ 3 |
[ノードの追加（Add Node）] 画面で、以下の詳細を入力します： OOB ゲートウェイと IP アドレスは、（検証に基づいて）テーブルに自動的に入力されます。 [適用（Apply）]をクリックします。検証ステータスは、[ノードの移行（Migrate Nodes）] 画面に [完了（Complete）] と表示されます。 鉛筆アイコン（[検証（Validation）] 列の横）をクリックして、クラスタ内の他の APIC に対して同じプロセスを繰り返します。すべてのコントローラの詳細を入力したら、[移行（Migrate）] 画面の下部にある [移行（Migrate）] ボタンをクリックします。 |
移行プロセスには一連のアクティビティが含まれ、段階的に表示されます。各段階は、色分けされたバーで示されます。
[クラスタ ステータスの移行（Migrate Cluster Status）] 画面には、全体的な移行ステータスが表示され、その後に apisever のステータスが表示されます。apiserver は、移行プロセス全体を調整するプロセスです。apiserver ステータスの下に、コントローラ単位の移行ステータスが表示されます。ノードのソース IP アドレスとターゲット IP アドレスも表示されます。
APIC 2 へのハンドオーバーが完了した後、apiserver ステータスは 100% 完了（緑色のバー）として示されます。この段階で、新しいウィンドウが表示されます（URL がターゲット APIC 2 にリダイレクトされます）。ターゲット APIC 2 にログインします。移行が完了するまで、 移行が進行中であることを示すバナーが GUI の上部に表示されます。ハンドオーバー プロセスの後、送信元 APIC 1 に表示されたバナーがターゲット APIC 2 に表示されます。バナーの [ステータスの表示（View Status）] リンクをクリックして、移行ステータスを確認します。
[クラスタステータスの移行（Migrate Cluster Status）] 画面にある [中止（Abort）] ボタンをクリックして、送信元 APIC 1 からの移行プロセスを中止することもできます。[中止（Abort）] ボタンは、移行を開始してから一定期間が経過した後にのみ表示されます。
移行が正常に終了すると、次のようになります：
移行ステータスが表示されなくなります。移行が失敗した場合は、失敗メッセージが明示的に表示されます。
ターゲット クラスタが正常であり、完全に適合しているかどうかを確認するには、 [システム（System） ] > [コントローラ（Controllers）] > [コントローラの展開（Expand Controllers）]に移動します。 [コントローラ 1（Controller 1）] > [ノードで表示されるクラスタ（Cluster as seen by Node）] を展開します。
すべてのファブリックノードがアクティブ状態であるかどうかを確認します。 [ファブリック（Fabric）] 、 [ファブリック メンバーシップ（Fabric Membership）] の順に選択します。
ターゲット APIC のポッド ID が変更された場合は、[テナント管理（Tenant Management）] 画面でノードのインバンド アドレスを再構成する必要があります。[テナント（Tenants）] > [管理（Mgmt）]> [ノード管理アドレス（Node Management Addresses）] ページに移動します。
移行プロセスは、障害が原因で中断されることもありますし、ユーザーが移行の中止を選択することもあります。移行が成功しなかった場合は、ソースまたはターゲットのいずれかのコントローラ タイプに移行を元に戻すか、移行を再開することをお勧めします。物理コントローラと仮想コントローラが混在する状態で APIC クラスタを移行が失敗した状態にすることは推奨されません。復元または再開を試みる前に、次のセクション「基本的なトラブルシューティング」のステップに従って、クラスタを正常な状態にします。
[再開（resume）] を選択した場合、移行プロセスは続行されます。[ノードの移行（Migrate Node）] 画面（ソース APIC 1）で、次の手順を実行します。
移行するコントローラ タイプに基づいて、すべてのターゲット ノードの詳細を入力します。
[移行（Migrate）] をクリックします。
元に戻すことを選択した場合：移行プロセスは再起動されます。クラスタのコントローラを初期（ソース）IPアドレスに取得した後、移行プロセスを再起動する必要があります。
acidiag touch setup および acidiag reboot コマンドを使用して、移行の途中だった各ソース APIC ノードを初期設定にリセットします。
移行プロセスによって以前に移行された APIC がソース コントローラ タイプに戻るため、 [ノードの移行（Migrate Node）] 画面で、すべてのノードのソース APIC の詳細を入力します。
[移行（Migrate）] をクリックします。
（注） |
ハンドオーバー プロセス（ソース APIC 1 からターゲット APIC 2 に制御が渡される）後に移行プロセスが失敗した場合、移行を再開または元に戻すことはできません。 |
前述のように、移行のさまざまなサブステージとその完了の進行状況は、コントローラごとにバーで示されます。いずれかの段階で障害が発生した場合は、関連するテクニカルサポートの詳細を収集し、Cisco TAC にお問い合わせください。テクニカル サポートのログを収集するには、 [管理（Admin）] > [インポート/エクスポート（Import/Export ）] > [ エクスポート ポリシー（Export Policies）] > [オンデマンド テクニカル サポート（On-demand Tech Support）] > [migration_techsuppport] に移動します。
2 つのノードが正常に移行され、3 番目のノードの移行中に障害が検出された 3 ノードクラスタについて考えます。障害が発生したノードのステータスを確認します。コントローラが完全に適合した 状態でない場合、移行は失敗する可能性があります。
クラスタを正常な状態にする手順：
|
ステップ 1 |
（APIC 1 での移行の失敗した場合） [システム（System）] > [コントローラ（Controllers）]に移動して、ターゲット APIC 2 からクラスタの正常性を確認します。[コントローラ 2（Controller 2）] > [ノードから見たクラスタ（Cluster as seen by Node）] を選択します。 または （APIC 2 から Nへの移行が失敗した場合） [システム（System）] > [コントローラ（Controllers）]に移動して、ソース APIC 1 からクラスタの正常性を確認します。[コントローラ 1（Controller 1）] > [ノードから見たクラスタ（Cluster as seen by Node）] を選択します。 |
|
ステップ 2 |
APIC 1（またはクラスタの他のノード）が [完全に適合（Fully Fit）]でない場合は、コントローラのシリアル番号の横にある 3 つのドットをクリックします。[メンテナンス（Maintenance）] > [デコミッション（Decommission）]を選択します。ノードが [完全に適合（Fully Fit）] 状態ではないため、 [強制デコミッション（Force Decommission）] をクリックします。SSH を使用してソース APIC ノード N に接続し、次のコマンド acidiag touch setup 、 acidiag reboot を使用してノードを工場出荷時の状態にリセットします。 |
|
ステップ 3 |
ソース APIC 1 から、[システム（System）] > [コントローラ（Controllers）]に移動します。[コントローラ（Controllers）] > [コントローラ 1（Controller 1 ）] > [ノードから見たクラスタ（Cluster as seen by Node）] をクリックします。 または ターゲット APIC 2 から、[システム（System）] > [コントローラ（Controllers）]に移動します。[コントローラ（Controllers） ] > [コントローラ 2（Controller 2） ] > [ノード別クラスタ（Cluster）] をクリックします。 |
|
ステップ 4 |
コントローラのコミッションを行うには、コントローラのシリアル番号の横にある 3 つのドットをクリックします。[メンテナンス（Maintenance）] > [コミッション（Commission）] を選択します。必要に応じて、詳細を入力します。「ノードのコミッショニング」の手順（この章で前述）を参照してください。ここでの唯一の違いは、コントローラ ID には、クラスタ内のコントローラの ID に対応する番号が事前に入力されていることです。 コントローラのコミッションが行われると、クラスタは [完全に適合（Fully Fit）]と表示されます。 |
|
ステップ 5 |
障害が発生したノードのコミッションを行った後、クラスタのステータスを確認します。クラスタが正常な状態の場合は、 [ノードから見たクラスタ（Cluster as seen by Node）] 画面で [移行（Migrate）] をクリックして移行を再開します。移行が再び失敗した場合には、Cisco の TAC に連絡してください。 |
フィードバック