Cisco DNA Center リリース 1.3.1.0 HA ガイド
Cisco DNA Center のハイアベイラビリティ(HA)実装の説明については、次のガイドを参照してください。
ハイ アベイラビリティの概要
Cisco DNA Center のハイアベイラビリティ(HA)フレームワークは、障害によるダウンタイムの量を削減し、障害が発生したときのネットワークの耐障害性を向上させるように設計されています。障害が発生した場合、このフレームワークは、ネットワークを以前の動作状態に復元するのに役立ちます。これが不可能な場合、Cisco DNA Center は注意が必要な問題があることを示します。
Cisco DNA Center の HA フレームワークでは、クラスタノードの変更が行われたと判断すると、この変更を他のノードと同期します。サポートされる同期のタイプは、次のとおりです。
-
データベースの変更(設定、パフォーマンス、およびモニタリング データに関連する更新など)。
-
ファイルの変更(レポート設定、設定テンプレート、TFTP ルートディレクトリ、管理設定、ライセンスファイル、キーストアなど)。
このガイドでは、HA、導入、管理のベストプラクティス、および発生する可能性がある障害シナリオを使用するために満たす必要がある要件(および Cisco DNA Center による処理方法と必要なユーザアクション)について説明します。このガイドを参照する際は、次の点に注意してください。
-
シードとマスタの用語は同義で使用しています。シードノード(マスタノード)は、NDP 名前空間で Elasticsearch が実行されているノードです。
-
このリリースでは、Cisco DNA Center は自動化機能の HA サポートのみを提供します。現時点で、アシュアランスの HA はサポートされていません。
ハイ アベイラビリティ要件
実稼働環境で HA を有効にするには、次の要件を満たす必要があります。
-
クラスタは、コア数が同じ 3 つの Cisco DNA Center アプライアンスで構成します。つまり、第 1 世代の 44 コアアプライアンス(Cisco 部品番号 DN1)と第 2 世代の 44 コアアプライアンス(Cisco 部品番号 DN2-HW-APL および DN2-HW-APL-U)の両方でクラスタを構成できることを意味します。
(注)
第 1 世代および第 2 世代のアプライアンスとそれに対応するシスコ製品番号リストを参照するには、『Cisco Digital Network Architecture Center 第 2 世代アプライアンス インストール ガイド』のトピック「インターフェイス名とウィザードの設定順序」を参照してください。
-
アプライアンスが Cisco DNA Center 1.2.8 以降の同じバージョンを実行している。たとえばバージョン 1.2.8 のパッチが 1 つのクラスタノードにインストールされている場合は、HA を動作させるために、他のクラスタノードにも同じパッチをインストールする必要があります。
ハイアベイラビリティの機能
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 を利用できなくなります。Cisco DNA Center システムアップグレードのスケジュールを設定する際は、このことを考慮する必要があります。システムアップグレードが完了したら、 の順にアクセスしてインストールされているバージョンを確認し、GUI でアップグレードの成功を確認できます。 |
[ハイアベイラビリティ展開(High Availability Deployment)]
このセクションのトピックでは、実稼働環境で HA 対応クラスタを展開および管理する際に従う必要があるベストプラクティスについて説明します。
展開の推奨事項
3 つのノード(1 つのシードノードと 2 つの非シードノード)で構成されるクラスタを設定することを推奨します。ノード数が奇数の場合、このような分散システムで操作を実行するために必要なクォーラムが提供されます。Cisco DNA Center はこれらを 3 つの独立したノードではなく、仮想 IP アドレスを介してアクセスされる 1 つの論理エンティティと見なします。
HA を展開する場合は、次のことを推奨します。
-
3 ノードクラスタを設定する場合は、クラスタがネットワーク障害の影響を受ける可能性があるため、低速リンク間で LAN をスパンするようにノードを設定しないでください。また、1 つのノードで障害が発生したサービスを回復させるために必要な時間を増やすこともできます。3 ノードクラスタのクラスタインターフェイスを設定する場合、すべてのクラスタノードが同じサブネット内に存在するようにしてください。
-
HA の動作に悪影響を及ぼす可能性があるため、管理、データ、および HA の責任で単一のインターフェイスをオーバーロードすることは避けてください。
-
クラスタノードを設定する場合は、リンクローカルサブネット(169.x.x.x)をクラスタまたはサービスサブネットとして指定しないでください(そのアドレスは Cisco DNA Center 内部ネットワークによって使用されるため)。
(注)
サブネットは、次のアドレス範囲をサポートするプライベートネットワークの 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 では『Address Allocation For Private Internets』を、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 を設定します。 ステップ 2 の完了時に表示されたのと同じアドオンノードの設定項目を参照してください。 |
||
ステップ 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 用のノードを準備します。 |
次の手順を実行します。
|
失敗したクラスタノードの回復
3 ノードクラスタに属するノードに障害が発生した場合、通常、クラスタが回復するまでに 30 分かかります。ノードがダウンしていることを検出するために 5 分、別のノードにサービスを移動するのに 25 分かかります。5 分後に、次のバナーメッセージが表示されます。「自動化およびアシュアランスサービスは現在ダウンしています。ノード node_details との接続が失われました。 (Automation and Assurance services are currently down. Connectivity with node node_details has been lost.)」障害が発生したノードを回復するには、次の手順を実行します。
手順
ステップ 1 |
正常なクラスタノードにログインし、コマンド maglev node remove failed-node's-IP-address を入力します。 これにより、クラスタから障害ノードが除外されます。 |
ステップ 2 |
アクティブノードで maglev package status コマンドを入力します。 Cisco DNA Center からこの情報にアクセスすることもできます。 をクリックし、[概要(About)] の順に選択してください。
|
ステップ 3 |
Cisco TAC に連絡してそのコマンドの出力を提供し、ご使用のバージョンと一致する ISO を確認してください。 |
ステップ 4 |
削除したノードを再度追加するには、再設置する必要があります。
|
ステップ 5 |
HA 動作を最適化するために、クラスタノード間でサービスを再配布します。
|
失敗したシードノードの置換
シードノードに障害が発生した場合は、次のタスクを実行して交換します。
-
障害が発生したノードをクラスタから削除します。
「障害が発生したシードノードの削除」を参照してください。
-
障害が発生したノードを別のノードと交換します。
「新しい シードノードの追加」を参照してください。
失敗したシードノードの削除
シードノードで障害が発生した場合、それを削除し、動作中のノードと交換する必要があります。シードノードの削除には、約 30 分かかります。
このセクションは、ハードウェア障害が原因で障害が発生した場合にのみ適用されます。
(注) |
シードノードを削除すると、既存のアシュアランスデータは失われますが、残されたノードが新しい アシュアランスデータの収集を開始します。 |
始める前に
次のことを実行してください。
-
データのバックアップを作成します。ノード障害のためにこの手順を実行している場合は、今すぐバックアップを作成することはできません。代わりに、定期的に作成したバックアップに依存する必要があります。
-
この手順を実行するには 30 分以上必要です。
手順
ステップ 1 |
(オプション)アシュアランス シードノードを削除する必要がある場合は、次のアクションを実行して削除するノードを特定します。
|
ステップ 2 |
削除するノードをシャットダウンします。 シャットダウンプロセスには約 10 分かかります。 |
ステップ 3 |
次のノードがダウンしていることを確認します。 magctl node display ノードのステータスは「NOT_READY」でなければなりません。 |
ステップ 4 |
appstack が次のステータスになっていることを確認します。 magctl appstack status シャットダウンされたノードのポッドに、ステータスとして「NODE LOST」 または「Pending」 が表示されます。 |
ステップ 5 |
削除していない次のノード(非シードノード)のいずれかにログインします。 maglev login -u admin -p admin-password -c node's-IP-address:443 |
ステップ 6 |
障害が発生した次のシードノードをクラスタから削除します。 maglev node remove node's IP address ノードの削除プロセスは、完了するまでに約 30 分かかります。 |
ステップ 7 |
次の残りの 2 つのノードですべてのサービスが実行されていることを確認します。 magctl node display magctl appstack status |
新しいシードノードの追加
障害が発生したシードノードを削除したら、クラスタに新しいノードを追加できます。
手順
ステップ 1 |
クラスタ内の他のノードが実行しているものと同じソフトウェアバージョンを新しいノードにインストールします。
|
||
ステップ 2 |
インストールが完了したら、次のコマンドを入力します。 magctl node display 新しいノードに [準備完了(Ready)] ステータスが表示されます。 |
||
ステップ 3 |
新しいノードで次を実行します。 |
||
ステップ 4 |
以前に アシュアランス データをバックアップしていた場合は、そのデータを復元します。 詳細については、『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 のバグと回避策については、『Release Notes for Cisco Digital Network Architecture Center』の「Open Bugs—High Availability」を参照してください。
ユーザアクションの必要性 |
障害シナリオ |
HA の動作 |
---|---|---|
Yes |
クラスタ内のすべてのノードがダウンする。 |
すぐに自動化バックアップを実行します。『Cisco Digital Network Architecture Center 管理者ガイド』の「Backup and Restore」の章を参照してください。 |
なし |
ノードに障害が発生している、到達不能である、または 5 分未満のサービス障害が発生している。 |
ノードが復元された後、次のようになります。
|
なし |
非シードノードに障害が発生している、到達不能である、または 5 分未満のサービス障害が発生している。 |
ノードが復元されてから、ノードがクラスタに再参加するまでは、次のようになります。
ノードがクラスタに再参加した後、次のようになります。
|
なし |
シードノードに障害が発生している、到達不能である、または 5 分未満のサービス障害が発生している。 |
ノードが復元されてから、ノードがクラスタに再参加するまでは、次のようになります。
ノードがクラスタに再参加した後、次のようになります。
|
Yes |
2 つのノードで障害が発生するか、到達不能です。 |
クラスタが破損していて、接続が復元されるまで UI にアクセスできません。
|
Yes |
ノードに障害が発生し、クラスタから削除する必要がある。 |
失敗したクラスタノードの回復 で説明されているタスクを実行して、障害が発生したクラスタノードを削除してから復元します。 |
なし |
すべてのノードが相互の接続を失う。 |
接続が復元されるまで UI にアクセスできません。接続が復元されると、動作が再開され、クラスタメンバーによって共有されるデータが同期されます。 |
Yes |
バックアップがスケジュールされ、ハードウェア障害が原因でシードノードがダウンする。 |
次の手順を実行します。
|
Yes |
UI の赤色のバナーで、ノードがダウンしていることが示されます。「アシュアランスサービスは現在ダウンしています。ホスト <IP-address> との接続が失われています。(services are currently down. Connectivity with host <IP_address> has been lost.)」 |
シードノードがダウンし、アシュアランス データが失われたことがバナーで示されます。シードノードが復帰すると、アシュアランス機能が復元されます。ただし、障害がハードウェア障害に関連している場合は、次の手順を実行します。
|
Yes |
UI の赤色のバナーでノードがダウンしていることが示されるが、最終的に「この IP アドレスはダウンしています。(This IP address is down.)」というメッセージで黄色に変更される。 |
システムは引き続き使用できます。ノードがダウンしている理由を調査し、バックアップします。 |
Yes |
クラスタのアップグレード中に障害が発生する。 |
次の手順を実行します。
|
なし |
アプライアンスポートに障害が発生する。 |
|
Yes |
アプライアンスハードウェアに障害が発生する。 |
障害が発生したハードウェアコンポーネント(ファン、電源装置、ディスクドライブなど)を交換します。これらのコンポーネントに属する複数のインスタンスがアプライアンスで検出されるため、1 つのコンポーネントの障害は一時的に許容される可能性があります。 RAID コントローラは新しく追加されたディスクドライブをアプライアンス上の他のドライブと同期するため、これが起きている間は I/O システムのパフォーマンスが低下する可能性があります。 |