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 の応答。
（注） |
Catalyst Center では、自動化とアシュアランスの両方の機能について HA がサポートされます。 |
HA の要件
HA を有効にするには、実稼働環境が次の要件を満たす必要があります。
-
クラスターが、同じマシンプロファイルを持つ 3 つの Catalyst Center アプライアンス（3 つの第 3 世代大規模アプライアンスなど）で構成されている。
サポートされるアプライアンスを参照してください。
-
セカンダリアプライアンスがプライマリアプライアンスと同じバージョンの Catalyst Center を実行している。
-
クラスターのアプライアンスが同じネットワークに属し、同じサイトに存在する。
（注）
この要件は、すべてのマルチノードクラスターの展開に適用されます。Catalyst Center アプライアンスは、複数のネットワークまたはサイト間でのノードの配布をサポートしていません。
-
クラスタのラウンドトリップ時間（RTT）は 10 ミリ秒以下です。
サポートされるアプライアンス
表 1 では、HA をサポートする Catalyst Center アプライアンスのリストを示します。
|
マシンプロファイル |
マシン プロファイル エイリアス |
シスコ製品番号 | コア数 |
|---|---|---|---|
|
medium |
medium |
第 2 世代
|
44 |
|
第 3 世代
|
32 |
||
|
t2_large |
large |
第 2 世代
|
72 |
|
第 3 世代
|
|||
|
t2_2xlarge |
特大 |
第 2 世代
|
112 |
|
第 3 世代
|
80 |
重要 |
Catalyst Center 2.3.7.9 では、HA が有効になっている混合 3 ノードクラスターのサポートが追加されています。有効な混合クラスターは、次の要件を満たしています。
|
高可用性の機能
Catalyst Center は、ソフトウェアとハードウェアの両方の HA を提供する 3 ノードクラスター設定をサポートしています。
-
ソフトウェア HA：ノード上の障害が発生したすべてのサービスを再起動します。サービスで障害が発生した場合、Catalyst Center は同じノードまたは別のクラスターノードでそのサービスを再起動します。
-
ハードウェア HA：複数のアプライアンス、ディスクドライブ（各アプライアンスの RAID 設定内）、および電源を使用して、障害のあるコンポーネントが復元または交換されるまで、これらのコンポーネントによる障害を許容します。
重要 |
|
クラスタリングおよびデータベース レプリケーション
Catalyst Center により、複数のノード間での分散処理とデータベース レプリケーションが可能になります。クラスタリングにより、リソースと機能を共有することで HA が実現できます。
セキュリティの複製
マルチノード環境では、X.509 証明書やトラストプールを含む単一ノードのセキュリティ機能が Catalyst Center によって他の 2 つのノードに複製されます。これらのノードを結合して 3 ノードクラスターを形成した後、Catalyst Center はノード間で GUI ユーザーログイン情報を共有します。CLI ユーザーログイン情報については、各ノードで異なるため Catalyst Center は共有しません。
システムのアップグレード
マルチノードクラスターでは、Catalyst Center GUI でクラスター全体のアップグレードをトリガーできます。GUI は、単一のノードのみではなくクラスター全体を表します。GUI でトリガーされたアップグレードでは、すべてのクラスターノードが自動的に更新されます。
（注） |
Catalyst Center のコアインフラストラクチャを更新するためにシステムアップグレードを開始すると、Catalyst Center はメンテナンスモードになります。メンテナンスモードでは、アップグレードプロセスが完了するまで Catalyst Center を利用できなくなります。システムアップグレードのスケジュールを設定する際は、このことを考慮してください。 |
正常なシステムアップグレードの確認
GUI で次の手順を完了することで、システムアップグレードが正常に行われたことを確認できます。
手順
|
ステップ 1 |
メインメニューから次を選択します。。 |
|
ステップ 2 |
[System Update] 領域で、最新のシステムパッケージがインストールされていることを検証します。 |
ハイアベイラビリティ展開
このセクションでは、実稼働環境で 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 では『Address Allocation for Private Internets』を、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 コマンドを実行します。
一般的なクラスターノードの操作
表 1 では、クラスター内のノードを管理する際に実行する最も一般的な操作について説明します。
| タスク | 操作 | ||||
|---|---|---|---|---|---|
|
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 つのスイッチがダウンした場合の影響が軽減されます。
ハイアベイラビリティ障害のシナリオ
以下に関連する問題が原因でノードに障害が発生する可能性があります。
-
ソフトウェア
-
ネットワークアクセス、および
-
ハードウェアにライセンスは必要ありません。
障害が発生すると、Catalyst Center は通常 2 分以内に検出し、自動的に障害の解決を試みます。2 分よりも長く続く障害には、ユーザーの介入が必要になる場合があります。
表 1 では、クラスターで発生する可能性のある障害シナリオと、各シナリオでの Catalyst Center の対応方法について説明します。表の最初の列に注意してください。これは、クラスターの動作を復元するためにユーザーからのアクションを必要とするシナリオを示しています。
（注） |
クラスタを動作させるには、Catalyst Center の HA の実装で常に少なくとも 2 つのクラスタノードが稼働している必要があります。 |
|
ユーザーアクションの必要性 |
障害シナリオ |
HA の動作 |
||
|---|---|---|---|---|
|
あり |
クラスタ内のすべてのノードがダウンする。 |
すぐに自動化バックアップを実行します。『Cisco Digital Network Architecture Center 管理者ガイド』の「Backup and Restore」の章を参照してください。 |
||
|
なし |
ノードに障害が発生している、到達不能になった、または 2 分未満のサービス障害が発生している。 |
ノードが復元された後、次のようになります。
|
||
|
なし |
ノードに障害が発生している、到達不能になった、または 2 分未満のサービス障害が発生している。 |
ノードが復元されると、次のアクションが実行されます。
|
||
|
あり |
2 つのノードで障害が発生するか、到達不能です。 |
クラスターが破損していて、接続が復元されるまで GUI にアクセスできません。
|
||
|
あり |
ノードに障害が発生し、クラスタから削除する必要がある。 |
Cisco TAC に問い合わせてサポートを受けてください。 |
||
|
なし |
すべてのノードが相互の接続を失います。 |
接続が復元されるまで、GUI にはアクセスできません。接続が復元されると、動作が再開され、クラスターメンバーによって共有されるデータが同期されます。 |
||
|
対応 |
バックアップがスケジュールされ、ハードウェア障害のためにノードがダウンします。 |
交換用ノードについて、および新しいノードをクラスタに参加させて残りの 2 つのノードでサービスを復元するためのサポートについては、Cisco TAC にお問い合わせください。 |
||
|
あり |
GUI の赤色のバナーで、ノードがダウンしていることが示されます。「 |
ノードがダウンしたことがバナーで示されます。その結果、Assurance のデータ収集と処理が停止し、データが使用できなくなります。ノードが復帰すると、Assurance機能が復元されます。障害がハードウェア障害に関連している場合は、次の手順を実行します。
|
||
|
あり |
UI の赤色のバナーでノードがダウンしていることが示されるが、最終的に「 |
システムは引き続き使用できます。ノードがダウンしている理由を調査し、バックアップします。 |
||
|
あり |
クラスタのアップグレード中に障害が発生する。 |
Cisco TAC に問い合わせてサポートを受けてください。 |
||
|
なし |
アプライアンスポートに障害が発生する。 |
|
||
|
あり |
アプライアンスハードウェアに障害が発生する。 |
障害が発生したハードウェアコンポーネント（ファン、電源装置、ディスクドライブなど）を交換します。これらのコンポーネントに属する複数のインスタンスがアプライアンスで検出されるため、1 つのコンポーネントの障害は一時的に許容される可能性があります。 RAID コントローラは新しく追加されたディスクドライブをアプライアンス上の他のドライブと同期するため、これが起きている間は I/O システムのパフォーマンスが低下する可能性があります。 |
サービス再配布時間
表 1 は、HA 環境で 2 つのノードにサービスを再配布するために必要な時間を表示します。
| イベント | ノードが使用できなくなる期間 |
|---|---|
|
ノードがダウンしていることを Catalyst Center が検出 |
2 分 |
|
サービス再配布の開始 |
1 分 |
|
サービス再配布の完了 |
25 minutes |
サービスの再配布に必要な時間はさまざまです。これは、ダウンしたノード内のポッドの数と、それらのポッドを他のノードに再配置するのに必要な時間によって変わります。再配布後にサービスが準備完了状態になるまでに必要な時間は、それぞれの稼働状況プローブと準備状況プローブによって異なります。
ポッドはマップされておらず、Kubernetes はクラスターの VIP を認識していないため、サービス配布はクラスターの VIP の影響を受けません。ただし、ダウンしたノードがコントローラマネージャまたは kube-scheduler サービスのリーダーである場合、再配布が若干遅れる可能性があります。新しいリーダーが引き継いでスイッチオーバーを実行する前に、次のいずれが成立している必要があります。
-
リーダーが保持しているリースが期限切れになっている、または
-
更新期限日を過ぎている。
ノード障害時のポッドの動作
このトピックでは、ノードに障害が発生して到達不能になった場合、または 5 分以上サービス障害状態が続いている場合でのポッドの動作について説明します。
-
StatefulSet：ポッドはデータストレージを提供します。このタイプのポッドはノードにバインドされており、ローカル永続ボリューム（LPV）を使用します。ノードがダウンすると、そのノード上のすべてのステートフルセットが保留状態に移行します。
StatefulSet ポッドには、たとえば以下があります。
-
MongoDB
-
Elasticsearch、および
-
PostgreSQL。
-
-
DaemonSet：設計上、ポッドは厳密にノードにバインドされます。
DaemonSet ポッドには、たとえば以下があります。
-
agent
-
broker-agent、および
-
keepalived。
-
-
ステートレス展開：
-
独自のデータストアを持たないポッドは、データの保存と取得に StatefulSet を使用します。
-
展開の規模はさまざまです。展開には、1 ポッドインスタンス（spf-service-manager-service など）、 2 ポッドインスタンス（apic-em-inventory-manager-service など）、3 ポッドインスタンス（kong、platform-ui、collector-snmp など）といったものがあります。
-
単一インスタンスのステートレスポッドは、クラスターの現在の状態に基づいてノード間を自由に移動できます。
-
2 インスタンスのステートレスポッドはノード間を柔軟に移動できますが、同じノードで 2 つのステートレスポッドを実行することはできません。
-
3 インスタンスのステートレスポッドにはノードの非アフィニティがあります。つまり、同じノードで 2 つのインスタンスを実行することはできません。
-
フィードバック