Cisco DNA Center リリース 2.2.3 ハイアベイラビリティガイド
Cisco DNA Center のハイアベイラビリティ（HA）実装の説明については、次のガイドを参照してください。
 （注） |
Cisco DNA Center のディザスタリカバリ機能の説明については、 『Cisco DNA Center Administrator Guide』の「Implement Disaster Recovery」の章を参照してください。 |
（注） |
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、基準ドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。 |
高可用性の概要
Cisco DNA Center のハイアベイラビリティ（HA）フレームワークは、障害によるダウンタイムの量を削減し、障害が発生したときのネットワークの耐障害性を向上させるように設計されています。これは、クラスタノード間でほぼリアルタイムで変更を同期することによって実現され、発生する問題に対処できるレベルの冗長性をネットワークに提供します。サポートされる同期のタイプは、次のとおりです。
-
データベースの変更（設定、パフォーマンス、およびモニターリング データに関連する更新など）。
-
ファイルの変更（レポート設定、設定テンプレート、TFTP ルートディレクトリ、管理設定、ライセンスファイル、キーストアなど）。
このガイドでは、HA、導入、管理のベストプラクティス、および発生する可能性がある障害シナリオを使用するために満たす必要がある要件（および Cisco DNA Center による処理方法と必要なユーザーアクション）について説明します。
重要 |
Cisco DNA Center では、自動化とアシュアランスの両方の機能について HA がサポートされます。 |
ハイ アベイラビリティ要件
実稼働環境で HA を有効にするには、次の要件を満たす必要があります。
-
クラスタは、コア数が同じ 3 つの Cisco DNA Center アプライアンス（3 つの 56 コアアプライアンスなど）で構成します。44 コアアプライアンスに関して言えば、第 1 世代の 44 コアアプライアンス（シスコ製品番号 DN1）と第 2 世代の 44 コアアプライアンス（シスコ製品番号 DN2-HW-APL および DN2-HW-APL-U）の両方でクラスタを構成できることを意味します。
（注）
第 1 世代および第 2 世代のアプライアンスとそれに対応するシスコ製品番号リストを参照するには、『Cisco DNA Center Second-Generation Appliance Installation Guide』のトピック「Maglev Wizard Interface Configuration Order」を参照してください。
-
セカンダリアプライアンスでプライマリアプライアンスと同じバージョン（1.2.8 以降）の Cisco DNA Center を実行します。
-
マルチノードクラスタの導入では、すべてのメンバノードを同じサイトの同じネットワーク内にする必要があります。Cisco DNA Center アプライアンスは、複数のネットワークまたはサイト間でのノードの配布をサポートしていません。
-
クラスタの往復時間（RTT）は 10 ミリ秒以下です。
ハイアベイラビリティの機能
Cisco DNA Center は、ソフトウェアとハードウェアの両方のハイアベイラビリティを提供する 3 ノードクラスタ設定をサポートしています。ノード上のサービスが機能しなくなると、ソフトウェア障害が発生します。ソフトウェアのハイアベイラビリティには、ノード上のサービスを再起動する機能が含まれています。たとえば 3 ノードクラスタの 1 つのノードでサービスに障害が発生した場合、そのサービスは、同じノードまたは残りの 2 つのノードのいずれかで再起動されます。アプライアンス自体に動作不良や障害があると、ハードウェア障害が発生します。ハードウェアのハイアベイラビリティは、クラスタ内の複数のアプライアンス、各アプライアンスの RAID 設定内の複数のディスクドライブ、および複数の電源装置が存在することによって有効になります。その結果、障害が発生したコンポーネントが復元または交換されるまで、これらのコンポーネントのいずれかによる障害を許容することができます。
（注） |
Cisco DNA Center は、3 つを超えるノードを持つクラスタをサポートしていません。たとえば 5 つまたは 7 つのノードを持つマルチノードクラスタは現在サポートされていません。 3 ノードクラスタの故障耐性は、単一ノードの障害に対応するよう設計されています。つまり、単一ノードが機能しなくなった場合でも、Cisco DNA Center は特定のサービス全体にハイアベイラビリティを提供しようとします。2 つのノードで障害が発生した場合、HA 動作を実行するために必要なクォーラムが失われ、クラスタが分割されます。 |
クラスタリングおよびデータベース レプリケーション
Cisco DNA Center 複数のノード間での分散処理とデータベース レプリケーション用メカニズムとなります。クラスタリングにより、リソースと機能を共有するとともに、ハイアベイラビリティを実現することができます。
セキュリティの複製
マルチノード環境では、X.509 証明書やトラストプールを含む単一ノードのセキュリティ機能が他の 2 つのノードで複製されます。ノードを既存のクラスタに結合して 3 ノードクラスタを形成すると、Cisco DNA Center GUI ユーザークレデンシャルがノード間で共有されます。ただし、CLI ユーザークレデンシャルは、各ノードで別々であるため、共有されません。
ソフトウェアアップグレード
マルチノードクラスタでは、Cisco DNA Center GUI からクラスタ全体のアップグレードをトリガーできます（GUI は単一ノードだけでなくクラスタ全体を表します）。GUI からトリガーされたアップグレードでは、クラスタ内のすべてのノードが自動的にアップグレードされます。
（注） |
（Cisco DNA Center のコアインフラストラクチャを更新する）システムアップグレードを開始すると、Cisco DNA Center はメンテナンスモードになります。メンテナンスモードでは、アップグレードプロセスが完了するまで Cisco DNA Center を利用できなくなります。システムアップグレードのスケジュールを設定する際は、このことを考慮する必要があります。システムアップグレードが完了したら、 の順にアクセスしてインストールされているバージョンを確認し、GUI でアップグレードの成功を確認できます。
|
）をクリックして選択しますハイアベイラビリティ展開
このセクションのトピックでは、実稼働環境で HA 対応クラスタを展開および管理する際に従う必要があるベストプラクティスについて説明します。
展開の推奨事項
Cisco DNA Center は 3 ノードクラスタをサポートします。ノード数が奇数の場合、このような分散システムで操作を実行するために必要なクォーラムが提供されます。Cisco DNA Center はこれらを 3 つの独立したノードではなく、仮想 IP アドレスを介してアクセスされる 1 つの論理エンティティと見なします。
HA を展開する場合は、次のことを推奨します。
-
3 ノードクラスタを設定する場合は、クラスタがネットワーク障害の影響を受ける可能性があるため、低速リンク間で LAN をスパンするようにノードを設定しないでください。また、1 つのノードで障害が発生したサービスを回復させるために必要な時間を増やすこともできます。3 ノードクラスタのクラスタインターフェイスを設定する場合、すべてのクラスタノードが同じサブネット内に存在するようにしてください。
-
HA の動作に悪影響を及ぼす可能性があるため、管理、データ、および HA の責任で単一のインターフェイスをオーバーロードすることは避けてください。
-
アプライアンス設定ウィザードで、Cisco DNA Center は、[Services Subnet] および [Cluster Services Subnet] フィールドにリンクローカル（169.x.x.x）サブネットを事前入力します。デフォルトのサブネットを使用することをお勧めしますが、別のサブネットを指定することもできます。その場合、サブネットは、次のアドレス範囲をサポートするプライベートネットワークの IETF RFC 1918 および 6598 仕様に準拠している必要があります。
-
10.0.0.0/8
-
172.16.0.0/12
-
192.168.0.0/16
-
100.64.0.0/10
詳細については、RFC 1918 では『プライベートインターネット用のアドレス割り当て』を、RFC 6598 では『IANA-Reserved IPv4 Prefix For Shared Address Space』を参照してください。
-
-
オフ時間中は HA を有効にしてください。Cisco DNA Center がメンテナンスモードを開始し、サービスの再配布が完了するまで使用できないためです。
クラスタの展開
HA が有効になっている 3 ノードクラスタに Cisco DNA Center を展開するには、次の手順を実行します。
手順
|
ステップ 1 |
クラスタ内の最初のノードに Cisco DNA Center を設定します。
|
||
|
ステップ 2 |
クラスタ内の 2 番目のノードで Cisco DNA Center を設定します。
|
||
|
ステップ 3 |
クラスタ内の 3 番目のノードで Cisco DNA Center を設定します。 前述の手順の完了時に表示されたのと同じセカンダリアプライアンスの設定項目を参照してください。 |
||
|
ステップ 4 |
クラスタで高可用性を有効にします。
|
クラスタの管理
このセクションのトピックでは、実稼働環境で HA が有効になっている場合に完了する必要がある管理タスクについて説明します。
Maglev コマンドの実行
クラスタ内のノードで Maglev コマンドを正常に実行するには、次の手順を実行します。
始める前に
-
セッションで最初の Maglev コマンドを実行する前に、この手順のみを完了する必要があります。現在のセッションを閉じて新しいセッションを開始しない限り、再度完了する必要はありません。
-
SSH クライアントでコマンドを実行すると、RSA ホストキーが変更されたことを示すエラーメッセージが表示され、~/.ssh/known_hosts ファイルに正しいキーを追加するように求められます。これは通常、アプライアンスが以前に指定したものとは異なる IP アドレスを使用して再イメージ化された場合に発生します。このような状況が発生した場合は、次の手順を実行します。
-
アプライアンスに割り当てられる IP アドレスを次のアドレスに設定します。cat ~/.ssh/known_hosts
ここで、~ は、マシン上の known_host ファイルが存在するディレクトリを表します。
出力結果は次の例のようになります。
[192.168.254.21]:2222 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBA19/31YV+cQvI1rmIVl/ CaE/BqCdeg5Xr/pSOtwNnKB6eDrXvLSAUMz+EED339GvbkxT/DdsdGZn2BeWHIifuY= -
known_hosts ファイルからこの IP アドレスに関連付けられている次のすべてのキーを削除します。ssh-keygen -R appliance's-IP-address
この例では、次のコマンドを実行します。ssh-keygen -R 192.168.254.21:2222
（注）
別のオプションとして、~/.ssh/known_hosts ファイルを削除してから次の手順に進むこともできます。
-
以前に実行しようとしたコマンドを実行します。
-
手順
|
ステップ 1 |
SSH クライアントで、次のコマンドを入力します。 ssh node's IP address -l maglev-p 2222 |
|
ステップ 2 |
ノードの信頼性が確立できないことを示すメッセージが表示された場合は、続行するように求められたら、 yesを入力します。 |
|
ステップ 3 |
ノードの maglev ユーザーに対して設定されている Linux パスワードを入力します。 |
|
ステップ 4 |
実行する Maglev コマンドを入力します。 |
|
ステップ 5 |
Cisco DNA Center のデフォルトの管理スーパーユーザー用に設定されたパスワードを入力します。 |
一般的なクラスタノードの動作
クラスタ内のノードに対して完了する必要がある操作は、通常、次の操作です。クラスタノードのシャットダウン（計画されたメンテナンスを実行する前に実行）、返品許可（RMA）のためのノードの準備、ノードの再起動（ダウンしているノードを復元する場合、または設定変更を保存する場合に実行）などです。
（注） |
稼働中の 3 ノードクラスタ内の 2 つのノードを同時に再起動またはシャットダウンすることはできません。このような操作を行うと、クラスタのクォーラム要件が成立しなくなります。 |
| 動作 | 必要なアクション | ||
|---|---|---|---|
|
CLI から 3 ノードクラスタ内のすべてのノードをシャットダウンします。 |
すべてのノードで sudo shutdown -h now コマンドを同時に実行します。 |
||
|
再起動が必要な変更を行った後は、1 つ以上のノードを再起動します。 |
該当ノードで sudo shutdown -r now コマンドを実行します。 |
||
|
メンテナンスのために 1 つのノードをシャットダウンまたは切断します（ノードを再起動するだけではない場合）。 |
次のコマンドを実行します。
ノードでメンテナンスを実行したら、次の手順を実行します。
|
||
|
RMA 用のノードを準備します。 |
次の手順を実行します。
|
障害が発生したノードの交換
ノードに障害が発生した場合は、次のタスクを実行して交換します。
-
障害が発生したノードをクラスタから削除します。
障害が発生したノードの削除を参照してください。
-
障害が発生したノードを別のノードと交換します。
交換ノードの追加を参照してください。
障害が発生したノードの削除
ハードウェア障害が原因でノードに障害が発生した場合は、そのノードをクラスタから削除する必要があります。このタスクについてサポートが必要な場合は、Cisco TAC にお問い合わせください。
 警告 |
2 ノードクラスタ（通常の使用ではサポートされない一時的な設定）は、次のいずれかの状況が発生した場合に発生します。
2 ノードクラスタがアクティブな間は、いずれのノードも削除できません。 |
交換ノードの追加
障害が発生したシードノードを削除したら、クラスタに交換ノードを追加できます。
手順
|
ステップ 1 |
交換ノードでは、クラスタ内の他のノードが実行しているものと同じソフトウェアバージョンをインストールします。
|
||
|
ステップ 2 |
インストールが完了したら、次のコマンドを入力します。 magctl node display 交換ノードに [Ready] ステータスが表示されます。 |
||
|
ステップ 3 |
クラスタで高可用性をアクティブ化することにより、交換ノードにサービスを再配布します。
|
||
|
ステップ 4 |
次のサービスが再配布されたことを確認します。 magctl appstack status 交換ノードのステータスが [Running] と表示されます。 |
||
|
ステップ 5 |
以前に アシュアランス データをバックアップしていた場合は、そのデータを復元します。 詳細については、『Cisco Digital Network Architecture Center 管理者ガイド』の「Restore Data from Backups」のトピックを参照してください。
|
障害と停止の影響を最小限に抑える
一般的な 3 ノード Cisco DNA Center クラスタでは、各ノードはノードのクラスタ ポート インターフェイスを介して 1 つのクラスタスイッチに接続されます。クラスタスイッチとの接続には、2 つのトランシーバと 1 つの光ファイバケーブルが必要です。これらはいずれも障害が発生する可能性があります。クラスタスイッチ自体も（電源切断や手動再起動などにより）障害が発生する可能性があります。これにより、Cisco DNA Center クラスタが停止し、すべてのコントローラ機能が失われる可能性があります。クラスタの障害または停止の影響を最小限に抑えるには、次の 1 つ以上を実行します。
-
ソフトウェアアップグレード、設定のリロード、電源の再投入などの管理操作は重要ではない期間中に実行します。これらの操作によってクラスタの停止が発生する可能性があるためです。
-
インサービス ソフトウェア アップグレード（ISSU）機能をサポートするスイッチにクラスタノードを接続します。この機能を使用すると、システムはステートフル スイッチオーバー（SSO）によるノンストップ フォワーディング（NSF）を使用してトラフィックの転送を続行しながらシステムソフトウェアをアップグレードすることができ、システムのダウンタイムなしでソフトウェアアップグレードを実行します。
-
クラスタノードをスイッチスタックに接続します。これにより、各クラスタノードを、Cisco StackWise を介して参加しているスイッチスタックの別のメンバーに接続できます。クラスタが複数のスイッチに接続されているため、1 つのスイッチがダウンした場合の影響が軽減されます。
ハイアベイラビリティ障害のシナリオ
ノードの障害は、以下の 1 つ以上の領域で起きた問題が原因で発生する可能性があります。
-
ソフトウェア
-
ネットワーク アクセス層
-
ハードウェア
障害が発生すると、Cisco DNA Center は通常 5 分以内に検出し、障害を自力で解決します。5 分よりも長く続く障害には、ユーザーの介入が必要になる場合があります。
次の表に、クラスタで発生する可能性のある障害シナリオと、Cisco DNA Center による対応方法について説明します。表の最初の列に注意してください。これは、クラスタの動作を復元するためにユーザーからのアクションを必要とするシナリオを示しています。
重要 |
クラスタを動作させるには、Cisco DNA Center の HA の実装で常に少なくとも 2 つのクラスタノードが稼働している必要があります。 |
|
ユーザーアクションの必要性 |
障害シナリオ |
HA の動作 |
||
|---|---|---|---|---|
|
あり |
クラスタ内のすべてのノードがダウンする。 |
すぐに自動化バックアップを実行します。『Cisco Digital Network Architecture Center 管理者ガイド』の「Backup and Restore」の章を参照してください。 |
||
|
なし |
ノードに障害が発生している、到達不能である、または 5 分未満のサービス障害が発生している。 |
ノードが復元された後、次のようになります。
|
||
|
なし |
ノードに障害が発生している、到達不能である、または 5 分未満のサービス障害が発生している。 |
ノードが復元されてから、ノードがクラスタに再参加するまでは、次のようになります。
ノードがクラスタに再参加した後、次のようになります。
|
||
|
あり |
2 つのノードで障害が発生するか、到達不能です。 |
クラスタが破損していて、接続が復元されるまで UI にアクセスできません。
|
||
|
あり |
ノードに障害が発生し、クラスタから削除する必要がある。 |
Cisco TAC に問い合わせてサポートを受けてください。 |
||
|
なし |
すべてのノードが相互の接続を失う。 |
接続が復元されるまで UI にアクセスできません。接続が復元されると、動作が再開され、クラスタメンバーによって共有されるデータが同期されます。 |
||
|
あり |
バックアップがスケジュールされ、ハードウェア障害が原因でノードがダウンする。 |
交換用ノードについて、および新しいノードをクラスタに参加させて残りの 2 つのノードでサービスを復元するためのサポートについては、Cisco TAC にお問い合わせください。 |
||
|
あり |
UI の赤色のバナーで、ノードがダウンしていることが示されます。「アシュアランスサービスは現在ダウンしています。ホスト <IP-address> との接続が失われています。（services are currently down. Connectivity with host <IP_address> has been lost.）」 |
ノードがダウンしたことがバナーで示されます。その結果、アシュアランス のデータ収集と処理が停止し、データが使用できなくなります。ノードが復帰すると、アシュアランス機能が復元されます。障害がハードウェア障害に関連している場合は、次の手順を実行します。
|
||
|
あり |
UI の赤色のバナーでノードがダウンしていることが示されるが、最終的に「この IP アドレスはダウンしています。（This IP address is down.）」というメッセージで黄色に変更される。 |
システムは引き続き使用できます。ノードがダウンしている理由を調査し、バックアップします。 |
||
|
あり |
クラスタのアップグレード中に障害が発生する。 |
Cisco TAC に問い合わせてサポートを受けてください。 |
||
|
なし |
アプライアンスポートに障害が発生する。 |
|
||
|
あり |
アプライアンスハードウェアに障害が発生する。 |
障害が発生したハードウェアコンポーネント（ファン、電源装置、ディスクドライブなど）を交換します。これらのコンポーネントに属する複数のインスタンスがアプライアンスで検出されるため、1 つのコンポーネントの障害は一時的に許容される可能性があります。 RAID コントローラは新しく追加されたディスクドライブをアプライアンス上の他のドライブと同期するため、これが起きている間は I/O システムのパフォーマンスが低下する可能性があります。 |
フェールオーバー中の保留ステータスについて
保留ステータスのポッドは、次のように動作します。
-
ステートフルセット：ポッドには何らかのタイプのデータストレージがあります。これらの 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 つのインスタンスを実行することはできません。
-
フィードバック