Catalyst Center リリース 2.3.7.x ハイアベイラビリティガイド
このガイドでは、Catalyst Center の高可用性 (HA) 実装の詳細について説明します。
 （注） |
Catalyst Center のディザスタリカバリ機能の説明については、Cisco Catalyst Center 管理者ガイド [英語] の「Implement Disaster Recovery」の章を参照してください。 |
Catalyst Center 高可用性の概要
Catalyst Center のハイアベイラビリティ（HA）フレームワークは、障害によるダウンタイムを減らし、ネットワークの回復力を高めるように設計されています。HA フレームワークは、クラスタノード全体でほぼリアルタイムの変更の同期を提供することでこれを実現し、発生した問題に対処するためのレベルの冗長性をネットワークに与えます。サポートされる同期のタイプは、次のとおりです。
-
データベースの変更（設定、パフォーマンス、およびモニターリングデータに関連する更新など）。
-
ファイルの変更（レポート設定、設定テンプレート、TFTP ルートディレクトリ、管理設定、ライセンスファイル、キーストアなど）。
このガイドでは、HA を使用するために満たす必要がある要件、展開と管理のベストプラクティス、および障害（ある場合）について説明します。
（注） |
Catalyst Center は、自動化機能と保証機能の両方に HA サポートを提供します。 |
ハイ アベイラビリティ要件
実稼働環境で HA を有効にするには、次の要件を満たす必要があります。
-
クラスタは、コア数が同じ 3 つの Catalyst Center アプライアンス（3 つの第 2 世代 56 コアアプライアンスなど）で構成します。
重要
Catalyst Center 2.3.7.6 では、第 3 世代アプライアンスを含む混合クラスタはサポートされていませ ん。第 3 世代アプライアンスのサポートは、今後のリリースで追加されます。
-
セカンダリアプライアンスでプライマリアプライアンスと同じバージョンの Catalyst Center を実行している必要があります。
-
マルチノードクラスタの導入では、すべてのメンバノードを同じサイトの同じネットワーク内にする必要があります。Catalyst Center アプライアンスは、複数のネットワークまたはサイト間でのノードの配布をサポートしていません。
-
クラスタのラウンドトリップ時間（RTT）は 10 ミリ秒以下です。
ハイアベイラビリティの機能
Catalyst Center は、ソフトウェアとハードウェアの両方の HA を提供する 3 ノードクラスタ設定をサポートしています。ノード上のサービスが機能しなくなると、ソフトウェア障害が発生します。ソフトウェア HA には、ノード上のサービスを再起動する機能が含まれます。たとえば 3 ノードクラスタの 1 つのノードでサービスに障害が発生した場合、そのサービスは、同じノードまたは残りの 2 つのノードのいずれかで再起動されます。アプライアンスが誤動作または故障すると、ハードウェア障害が発生します。ハードウェアの HA は、クラスタ内の複数のアプライアンス、各アプライアンスの RAID 設定内の複数のディスクドライブ、および複数の電源装置が存在することによって有効になります。その結果、障害が発生したコンポーネントが復元または交換されるまで、これらのコンポーネントのいずれかによる障害を許容することができます。
（注） |
Catalyst Center は、3 つを超えるノードを持つクラスタをサポートしていません。たとえば 5 つまたは 7 つのノードを持つマルチノードクラスタは現在サポートされていません。 3 ノードクラスタの故障耐性は、単一ノードの障害に対応するよう設計されています。つまり、単一ノードが機能しなくなった場合でも、Catalyst Center は特定のサービス全体に HA を提供しようとします。2 つのノードで障害が発生した場合、HA 動作を実行するために必要なクォーラムが失われ、クラスタが分割されます。 |
クラスタリングおよびデータベース レプリケーション
Catalyst Center 複数のノード間での分散処理とデータベース レプリケーション用メカニズムとなります。クラスタリングにより、リソースと機能を共有するとともに、HA を実現することができます。
セキュリティの複製
マルチノード環境では、X.509 証明書やトラストプールを含む単一ノードのセキュリティ機能が他の 2 つのノードで複製されます。ノードを既存のクラスタに結合して 3 ノードクラスタを形成すると、Catalyst Center GUI ユーザークレデンシャルがノード間で共有されます。ただし、CLI ユーザークレデンシャルは、各ノードで別々であるため、共有されません。
ソフトウェアアップグレード
マルチノードクラスタでは、Catalyst Center GUI からクラスタ全体のアップグレードをトリガーできます（GUI は単一ノードだけでなくクラスタ全体を表します）。GUI からトリガーされたアップグレードでは、クラスタ内のすべてのノードが自動的にアップグレードされます。
（注） |
（Catalyst Center のコアインフラストラクチャを更新する）システムアップグレードを開始すると、Catalyst Center はメンテナンスモードになります。メンテナンスモードでは、アップグレードプロセスが完了するまで Catalyst Center を利用できなくなります。システムアップグレードのスケジュールを設定する際は、このことを考慮する必要があります。システムアップグレードが完了したら、 の順に選択してインストールされているバージョンを確認し、GUI でアップグレードの成功を確認できます。
|
ハイアベイラビリティ展開
このセクションのトピックでは、実稼働環境で HA 対応クラスタを展開および管理する際に従う必要があるベストプラクティスについて説明します。
展開の推奨事項
Catalyst Center は 3 ノードクラスタをサポートします。奇数のノードは、分散システムで操作を実行するために必要なクォーラムを提供します。Catalyst Center はこれらを 3 つの独立したノードではなく、仮想 IP アドレスを介してアクセスされる 1 つの論理エンティティと見なします。
HA を展開する場合は、次のことを推奨します。
-
3 ノードクラスタを設定する場合は、クラスタがネットワーク障害の影響を受ける可能性があるため、低速リンク間で LAN をスパンするようにノードを設定しないでください。また、障害が発生したサービスの回復に必要な時間が長くなる可能性があります. 3 ノードクラスタでクラスタインターフェイスを設定する場合は、すべてのクラスタノードが同じサブネット内にあることを確認してください。
-
HA の動作に悪影響を与える可能性があるため、管理、データ、および HA の責任で単一のインターフェイスを過負荷にしないでください。少なくとも、クラスタインターフェイスと企業インターフェイスを使用して、クラスタトラフィックと企業トラフィックを分離します。
-
アプライアンス設定ウィザードで、Catalyst Center は、[Services Subnet] および [Cluster Services Subnet] フィールドにリンクローカル（169.x.x.x）サブネットを事前入力します。デフォルトのサブネットを使用することをお勧めしますが、別のサブネットを指定することもできます。異なるサブネットを指定する場合は、プライベートネットワークの IETF RFC 1918 および 6598 仕様に準拠する必要があります。
詳細については、RFC 1918 では『プライベートインターネット用のアドレス割り当て』を、RFC 6598 では『IANA-Reserved IPv4 Prefix For Shared Address Space』を参照してください。
-
オフ時間中は HA を有効にしてください。Catalyst Center がメンテナンスモードを開始し、サービスの再配布が完了するまで使用できないためです。
クラスタの展開
HA が有効になっている 3 ノードクラスタに Catalyst Center を展開するには、次の手順を実行します。
手順
|
ステップ 1 |
クラスタ内の最初のノードに Catalyst Center を設定します。 設置ガイド [英語] で、使用する構成ウィザードとアプライアンスのタイプに固有のトピックを参照してください。
|
||
|
ステップ 2 |
クラスタ内の 2 番目のノードで Catalyst Center を設定します。 設置ガイド [英語] で、使用する構成ウィザードとアプライアンスのタイプに固有のトピックを参照してください。
|
||
|
ステップ 3 |
クラスタ内の 3 番目のノードで Catalyst Center を設定します。 前述の手順の完了時に表示されたのと同じセカンダリアプライアンスの設定項目を参照してください。 |
||
|
ステップ 4 |
クラスタで HA をアクティブにします。
|
クラスタの管理
このセクションのトピックでは、実稼働環境で HA が有効になっている場合に完了する必要がある管理タスクについて説明します。
maglev コマンドの実行
Catalyst Center アプライアンスに現在設定されている IP アドレス、スタティックルート、DNS サーバー、または maglev ユーザーパスワードを変更するには、 sudo maglev-config update CLI コマンドを実行する必要があります。
一般的なクラスタノードの動作
クラスタ内のノードに実行する必要がある操作は次のとおりです。
-
計画メンテナンスを実行する前のクラスタノードのシャットダウン
-
ダウンしたノードを復元するため、または設定の変更を保存するためのリブート
-
ノードでの返品許可（RMA）の準備
-
アプライアンスにインストールされている Cisco IMC ファームウェアの更新
（注） |
稼働中の 3 ノードクラスタ内の 2 つのノードを同時に再起動またはシャットダウンすることはできません。このような操作を行うと、クラスタのクォーラム要件が成立しなくなるからです。 |
| タスク | 操作 | ||
|---|---|---|---|
|
CLI から、3 ノードクラスタ内のすべてのノードをシャットダウンします。 |
すべてのノードで sudo shutdown -h now コマンドを同時に実行します。 ノードの電源をオンに戻すときは、Cisco IMC を介してすべてのノードの電源を同時にオンにしてください。 |
||
|
メンテナンスのために 1 つのノードをシャットダウンまたは切断します（ノードを再起動するだけではない場合）。 |
次のコマンドを実行します。
ノードでメンテナンスを実行したら、次の手順を実行します。
|
||
|
再起動が必要な変更を行った後は、1 つ以上のノードを再起動します。 |
該当ノードで sudo shutdown -r now コマンドを実行します。 |
||
|
RMA 用のノードを準備します。 |
|
||
|
アプライアンスの Cisco IMC ファームウェアを更新します。 |
次の手順を実行します。
|
障害が発生したノードの交換
ノードに障害が発生した場合は、次のタスクを実行して交換します。
-
障害が発生したノードをクラスタから削除します。
障害が発生したノードの削除を参照してください。
-
障害が発生したノードを別のノードと交換します。
交換ノードの追加を参照してください。
障害が発生したノードの削除
ハードウェア障害が原因でノードに障害が発生した場合は、そのノードをクラスタから削除する必要があります。このタスクについてサポートが必要な場合は、Cisco TAC にお問い合わせください。
 警告 |
次のいずれかの状況が発生した場合、2 ノードクラスタ（通常の使用ではサポートされない一時的な設定）になります。
2 ノードクラスタがアクティブな間は、いずれのノードも削除できません。 |
交換ノードの追加
障害が発生したシードノードを削除したら、クラスタに交換ノードを追加できます。
次のタスクを実行します。
-
障害が発生したノードを削除します。詳細については、障害が発生したノードの削除を参照してください。
-
この手順を実行するには 30 分以上必要です。
手順
|
ステップ 1 |
交換ノードでは、クラスタ内の他のノードが実行しているものと同じソフトウェアバージョンをインストールします。
|
||
|
ステップ 2 |
インストールが完了したら、次のコマンドを入力します。 magctl node display 交換ノードに [Ready] ステータスが表示されます。 |
||
|
ステップ 3 |
クラスタで HA をアクティブ化して、交換用ノードにサービスを再配布します。
|
||
|
ステップ 4 |
次のサービスが再配布されたことを確認します。 magctl appstack status 交換ノードのステータスが [Running] と表示されます。 |
障害と停止の影響を最小限に抑える
一般的な 3 ノード Catalyst Center クラスタでは、各ノードはノードのクラスタ ポート インターフェイスを介して 1 つのクラスタスイッチに接続されます。クラスタスイッチとの接続には、2 つのトランシーバと 1 つの光ファイバケーブルが必要です。これらはいずれも障害が発生する可能性があります。クラスタスイッチ自体も（電源切断や手動再起動により）障害が発生する可能性があります。これにより、Catalyst Center クラスタが停止し、すべてのコントローラ機能が失われる可能性があります。クラスタの障害または停止の影響を最小限に抑えるには、次の 1 つ以上を実行します。
-
ソフトウェアアップグレード、設定のリロード、電源の再投入などの管理操作は重要ではない期間中に実行します。これらの操作によってクラスタの停止が発生する可能性があるためです。
-
インサービス ソフトウェア アップグレード（ISSU）機能をサポートするスイッチにクラスタノードを接続します。この機能を使用すると、システムはステートフル スイッチオーバー（SSO）によるノンストップ フォワーディング（NSF）を使用してトラフィックの転送を続行しながらシステムソフトウェアをアップグレードすることができ、システムのダウンタイムなしでソフトウェアアップグレードを実行します。
-
クラスタノードをスイッチスタックに接続します。これにより、各クラスタノードを、Cisco StackWise を使用して参加しているスイッチスタックの別のメンバーに接続できます。クラスタが複数のスイッチに接続されているため、1 つのスイッチがダウンした場合の影響が軽減されます。
ハイアベイラビリティ障害のシナリオ
ノードの障害は、以下の 1 つ以上の領域で起きた問題が原因で発生する可能性があります。
-
ソフトウェア
-
ネットワーク アクセス層
-
ハードウェア
障害が発生すると、Catalyst Center は通常 5 分以内に検出し、障害を自力で解決します。5 分よりも長く続く障害には、ユーザーの介入が必要になる場合があります。
次の表に、クラスタで発生する可能性のある障害シナリオと、Catalyst Center による対応方法について説明します。表の最初の列に注意してください。これは、クラスタの動作を復元するためにユーザーからのアクションを必要とするシナリオを示しています。
（注） |
クラスタを動作させるには、Catalyst Center の HA の実装で常に少なくとも 2 つのクラスタノードが稼働している必要があります。 |
|
ユーザーアクションの必要性 |
障害シナリオ |
HA の動作 |
||
|---|---|---|---|---|
|
あり |
クラスタ内のすべてのノードがダウンする。 |
すぐに自動化バックアップを実行します。『Cisco Digital Network Architecture Center 管理者ガイド』の「Backup and Restore」の章を参照してください。 |
||
|
なし |
ノードに障害が発生している、到達不能である、または 5 分未満のサービス障害が発生している。 |
ノードが復元された後、次のようになります。
|
||
|
なし |
ノードに障害が発生している、到達不能である、または 5 分未満のサービス障害が発生している。 |
ノードが復元されると、次のアクションが実行されます。
|
||
|
あり |
2 つのノードで障害が発生するか、到達不能です。 |
クラスタが破損していて、接続が復元されるまで GUI にアクセスできません。
|
||
|
あり |
ノードに障害が発生し、クラスタから削除する必要がある。 |
Cisco TAC に問い合わせてサポートを受けてください。 |
||
|
なし |
すべてのノードが相互の接続を失います。 |
接続が復元されるまで、GUI にはアクセスできません。接続が復元されると、操作が再開され、クラスタメンバーによって共有されるデータが同期されます。 |
||
|
対応 |
バックアップがスケジュールされ、ハードウェア障害のためにノードがダウンします。 |
交換用ノードについて、および新しいノードをクラスタに参加させて残りの 2 つのノードでサービスを復元するためのサポートについては、Cisco TAC にお問い合わせください。 |
||
|
あり |
GUI の赤色のバナーで、ノードがダウンしていることが示されます。「 |
ノードがダウンしたことがバナーで示されます。その結果、アシュアランス のデータ収集と処理が停止し、データが使用できなくなります。ノードが復帰すると、アシュアランス機能が復元されます。障害がハードウェア障害に関連している場合は、次の手順を実行します。
|
||
|
あり |
UI の赤色のバナーでノードがダウンしていることが示されるが、最終的に「 |
システムは引き続き使用できます。ノードがダウンしている理由を調査し、バックアップします。 |
||
|
あり |
クラスタのアップグレード中に障害が発生する。 |
Cisco TAC に問い合わせてサポートを受けてください。 |
||
|
なし |
アプライアンスポートに障害が発生する。 |
|
||
|
あり |
アプライアンスハードウェアに障害が発生する。 |
障害が発生したハードウェアコンポーネント（ファン、電源装置、ディスクドライブなど）を交換します。これらのコンポーネントに属する複数のインスタンスがアプライアンスで検出されるため、1 つのコンポーネントの障害は一時的に許容される可能性があります。 RAID コントローラは新しく追加されたディスクドライブをアプライアンス上の他のドライブと同期するため、これが起きている間は I/O システムのパフォーマンスが低下する可能性があります。 |
ノード障害時のポッドの動作
ノードに障害が発生して到達不能になった場合、または 5 分以上サービス障害状態が続いている場合、ポッドの移動動作は次のようになります。
-
ステートフルセット：ポッドには何らかのタイプのデータストレージがあります。これらの Pod は、ローカル永続ボリューム（LPV）を使用してノードにバインドされます。ノードがダウンすると、そのノード上のすべてのステートフルセットが保留状態に移行します。ステートフルな例は、Mongodb、Elasticsearch、Postgres です。
-
DaemonSet：設計上、ポッドは厳密にノードにバインドされます。DaemonSet の例は、agent、broker-agent、および keepalived です。
-
ステートレス/展開：
-
ポッドには、保存するデータがありませんが、ステートフルセットを使用してデータを保存または取得します。
-
展開の規模はさまざまです。一部の展開には 1x ポッドインスタンス（spf-service-manager-service など）、 2x ポッドインスタンス（apic-em-inventory-manager-service など）、および 3x ポッドインスタンス（kong、platform-ui、collector-snmp など）があります。
-
1x ステートレスポッドは、クラスタの現在の状態に基づいてノード間を自由に移動できます。
-
2x ステートレスポッドはノード間を柔軟に移動できますが、同じノードで 2 つのステートレスポッドを実行することはできません。
-
3x ステートレスポッドにはノードの非アフィニティがあります。つまり、同じノードで 2 つのインスタンスを実行することはできません。
-
フィードバック