CISCO DNA Center High Availability and Disaster Recovery User Guide

CISCO DNA Center High Availability and Disaster Recovery

Product Information

Specifications

• Product Name: Cisco DNA Center High Availability
• Release Version: 2.2.3
• Publication Date: First Published: 2021-08-04 | Last Modified:
  2021-02-03

Product Overview

The Cisco DNA Center High Availability (HA) framework is designed to minimize downtime and increase network resilience in the event of failures. It achieves this by providing near real-time synchronization of changes across cluster nodes and ensuring the network has redundancy to handle any issues that may arise. The supported synchronization types include settings, licensing files, and the key store. This guide provides information on the requirements for using HA, best practices for deployment and administration, and details on failure scenarios and how Cisco DNA Center handles them. It also covers any required user actions. Cisco DNA Center HA supports both Automation and Assurance functionality.

Cisco DNA Center High Availability Guide, Release 2.2.3
Refer to the following guide for a description of Cisco DNA Center’s high availability (HA) implementation.

Note:   For a description of disaster recovery functionality in the Cisco DNA Center, see the “Implement Disaster Recovery” chapter in the Cisco DNA Center Administrator Guide.

Note: The documentation set for this product strives to use bias-free language. For purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, the language used based on standards documentation, or language that is used by a referenced third-party product.

High Availability Overview

Cisco DNA Center’s HA framework is designed to reduce the amount of downtime that results from failures and make your network more resilient when they take place. It does so by providing the near real-time synchronization of changes across your cluster nodes, giving your network a level of redundancy to deal with any issues that arise. The supported synchronization types include:

• Database changes, such as updates related to configuration, performance and monitoring data.
• File changes, such as report configurations, configuration templates, TFTP-root directory, administration settings, licensing files, and the key store.

This guide covers the requirements that need to be met to use HA, deployment and administration best practices, and the failure scenarios you may encounter (as well as how Cisco DNA Center deals with them and any required user action).

Important: Cisco DNA Center provides HA support for both Automation and Assurance functionality.

High Availability Requirements

To use Cisco DNA Center High Availability, the following requirements must be met:

• Your cluster consists of three Cisco DNA Center appliances with the same number of cores (three 56-core appliances, for example). Regarding 44-core appliances, your cluster can consist of both the first-generation
  44-core appliance (Cisco part number DN1-HW-APL) and the second-generation 44-core appliance (Cisco part numbers DN2-HW-APL and DN2-HW-APL-U).

• Refer to the Maglev Wizard Interface Configuration Order topic in the Cisco DNA Center Second-Generation Appliance Installation Guide for a listing of first and second-generation appliances and their corresponding Cisco part numbers.

• A cluster with more than three nodes is not supported. Fault tolerance for a three-node cluster is designed to handle single-node failure. If two nodes fail, the quorum necessary to perform HA operations is lost and the cluster breaks.
  Note: To view a listing of first and second-generation appliances and their corresponding Cisco part number, see the “Maglev Wizard Interface Configuration Order” topic in the Cisco DNA Center Second-Generation Appliance Installation Guide.

• Your secondary appliances are running the same version of Cisco DNA Center (1.2.8 or later) as the primary appliance.

• Multinode cluster deployments require all of the member nodes to be in the same network and at the same site. The Cisco DNA Center appliance does not support the distribution of nodes across multiple networks or sites.

• Your cluster’s Round-Trip Time (RTT) is 10 milliseconds or less.

High Availability Functionality

Cisco DNA Center supports a three-node cluster configuration, which provides both software and hardware availability. A software failure occurs when a service on a node fails. Software high availability involves the ability of the services on the node or nodes to be restarted. For example, if a service fails on one node in a three-node cluster, that service is either restarted on the same node or on one of the other two remaining nodes. A hardware failure occurs when the appliance itself malfunctions or fails. Hardware high availability is enabled by the presence of multiple appliances in a cluster, multiple disk drives within each appliance’s RAID configuration, and multiple power supplies. As a result, a failure by one of these components can be tolerated until the faulty component is restored or replaced.

Note: Cisco DNA Center does not support a cluster with more than three nodes. For example, a multimode cluster with five or seven nodes is not currently supported. Fault tolerance for a three-node cluster is designed to handle single-node failure. In other words, the Cisco DNA Center tries to provide high availability across specific services even if a single node fails. If two nodes fail, the quorum necessary to perform HA operations is lost, and the cluster breaks.

Clustering and Database Replication
Cisco DNA Center provides a mechanism for distributed processing and database replication among multiple nodes. Clustering allows for resource and feature sharing, as well as enabling high availability.

Security Replication
In a multi-node environment, the security features of a single node are replicated to the other two nodes, including X.509 certificates or trust pools. When nodes are joined to an existing cluster to form a three-node cluster, the Cisco DNA Center GUI user credentials are shared across the nodes. However, the CLI user credentials are not shared and remain separate for each node.

Software Upgrade
In a multi-node cluster, you can trigger a cluster-wide upgrade from the Cisco DNA Center GUI. The upgrade initiated from the GUI will automatically upgrade all nodes in the cluster.

Note
After you initiate a system upgrade (which updates Cisco DNA Center’s core infrastructure), Cisco DNA Center goes into maintenance mode. In maintenance mode, the Cisco DNA Center will be unavailable until the upgrade process is completed. You should take this into account when scheduling a system upgrade. Once the system upgrade is complete, you can verify its success in the GUI by accessing System > Software Updates > Updates and checking the installed version.

1. In the Cisco DNA Center GUI, click the Menu icon ( ) and choose System > Software Updates > Updates.
2. In the System Update area, confirm that the latest system package has been installed.

Product Usage Instructions

High Availability Deployment
The topics in this section cover the best practices you should follow when deploying and administering an HA-enabled cluster in your production environment.

To deploy Cisco DNA Center High Availability, follow these steps:

1. Ensure that you have met all the requirements mentioned in the “High Availability Requirements” section.
2. Refer to the Maglev Wizard Interface Configuration Order topic in the Cisco DNA Center Second-Generation Appliance Installation Guide for detailed instructions on appliance configuration.
3. Set up a three-node cluster by joining nodes to an existing cluster. This can be done through the Cisco DNA Center GUI.
4. Verify the successful replication of security features and credentials across all nodes.

Deployment Recommendations
Cisco DNA Center supports three-node clusters. The odd number of nodes provides the quorum necessary to perform any operation in a distributed system such as this. Instead of three separate nodes, Cisco DNA Center views them as one logical entity accessed via a virtual IP address.

When deploying HA, we recommend the following:

• When setting up a three-node cluster, do not configure the nodes to span a LAN across slow links, as this can make the cluster susceptible to network failures. It can also increase the amount of time needed for a service that fails on one of the nodes to recover. When configuring a three-node cluster’s cluster interface, also ensure that all of the cluster nodes reside in the same subnet.

• Avoid overloading a single interface with management, data, and HA responsibilities, as this might negatively impact HA operation.

• In the appliance configuration wizards, Cisco DNA Center prepopulates the Services Subnet and Cluster Services Subnet fields with link-local (169.x.x.x) subnets. We recommend that you use the default subnets, but you can choose to specify different subnets. If you do so, they must conform with the IETF RFC 1918 and 6598 specifications for private networks, which support the following address ranges:

  • 10.0.0.0/8

  • 172.16.0.0/12

  • 192.168.0.0/16

  • 100.64.0.0/10
    For details, see RFC 1918, Address Allocation for Private Internets, and RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space.

  • Enable HA during off-hours, because Cisco DNA Center enters maintenance mode and is unavailable until it finishes redistributing services.

Administration Best Practices
To ensure optimal performance and effective administration of Cisco DNA Center High Availability, consider the following best practices:

• Regularly monitor the health and status of all cluster nodes using the Cisco DNA Center GUI.
• Maintain up-to-date backups of critical data and configurations.
• Follow Cisco’s recommended security practices for securing the cluster and its communication.
• Perform regular software updates and upgrades to benefit from bug fixes and new features.

Deploy a Cluster
To deploy Cisco DNA Center on a three-node cluster with HA enabled, complete the following procedure:

Procedure
Step 1: Configure Cisco DNA Center on the first node in your cluster:

• If you are configuring a first-generation appliance, see the “Configure the Primary Node” topic in the Cisco DNA Center First-Generation Appliance Installation Guide.
• If you are configuring a second-generation appliance, see the topic that is specific to the configuration wizard you want to use and your appliance type in the Cisco DNA Center Second-Generation Appliance Installation Guide:
• If you are configuring a second-generation appliance using the Maglev Configuration wizard, see the “Configure the Primary Node Using the Maglev Wizard” topic.
• If you are configuring a 44- or 56-core appliance using the browser-based configuration wizard, see the “Configure the Primary Node Using the Advanced Install Configuration Wizard” topic in the “Configure the 44/56-Core Node Using the Browser-Based Wizard” chapter.
• If you are configuring a 112-core appliance using the browser-based configuration wizard, see the “Configure the Primary Node Using the Advanced Install Configuration Wizard” topic in the “Configure the 112-Core Node Using the Browser-Based Wizard” chapter.

Step 2: Configure Cisco DNA Center on the second node in your cluster:

• If you are configuring a first-generation appliance, see the “Configure a Secondary Node” topic in the Cisco DNA Center First-Generation Appliance Installation Guide.
• If you are configuring a second-generation appliance, see the topic that is specific to the configuration wizard you want to use and your appliance type in the Cisco DNA Center Second-Generation Appliance Installation Guide:
• If you are configuring a second-generation appliance using the Maglev Configuration wizard, see the “Configure a Secondary Node Using the Maglev Wizard” topic.
• If you are configuring a 44- or 56-core appliance using the browser-based configuration wizard, see the “Configure a Secondary Node Using the Advanced Install Configuration Wizard” topic in the “Configure the 44/56-Core Node Using the Browser-Based Wizard” chapter.
• If you are configuring a 112-core appliance using the browser-based configuration wizard, see the “Configure a Secondary Node Using the Advanced Install Configuration Wizard” topic in the “Configure the 112-Core Node Using the Browser-Based Wizard” chapter.

Step 3: Configure Cisco DNA Center on the third node in your cluster.

• Refer to the same secondary appliance configuration topic you viewed while completing the preceding step

Step 4: Activate high availability on your cluster:

• In the Cisco DNA Center GUI, click the Menu icon ( ) and choose System > Settings > System Configuration > High Availability.
• Click Activate High Availability.

Note

• After you click Activate High Availability in the GUI, the Cisco DNA Center enters into maintenance mode. In this mode, the Cisco DNA Center is unavailable until the process is completed, which can take several hours. You should take this into account when scheduling an HA deployment.
• Cisco DNA Center also goes into maintenance mode when you restore the database and perform a system upgrade (not a package upgrade).
• To enable external authentication with an AAA server in a three-node cluster environment, you must configure all individual Cisco DNA Center node IP addresses and the virtual IP address for the three-node cluster on the AAA server.

Dealing with Failure Scenarios
Cisco DNA Center is designed to handle failure scenarios and provide high availability. In the event of a failure, follow these steps:

1. Identify the cause of the failure by checking the logs and monitoring the system status.
2. If a single node fails, the remaining nodes in the cluster should continue to provide service. No user action is required in this case.
3. If two nodes fail, the cluster will break, and user intervention is needed to restore the cluster. Contact Cisco support for assistance in this situation.

Administer a Cluster

The topics in this section cover the administrative tasks you will need to complete when HA is enabled in your production environment.

Run Maglev Commands
To run maglev commands successfully on the nodes in your cluster, do the following:

Before you begin

• You only need to complete this procedure before you run the first maglev command in a session. You do not need to complete it again unless you close the current session and start a new one.

• When you run a command in an SSH client, you may get an error message that indicates the RSA host key has been changed and prompts you to add the correct key to the ~/.ssh/known_hosts file. This typically happens when an appliance has been reimaged using a different IP address from the one that was specified for the appliance previously. If this happens, do the following:

  1. Determine the IP address that is assigned to your appliance: cat ~/.ssh/known_hosts where ~ represents the directory in which the known_host file resides on your machine.
     The resulting output will look similar to the following example: [192.168.254.21]:2222 ecdsa-sha2-nistp256

  2. Remove all of the keys associated with this IP address from the known_hosts file: ssh-keygen -R appliance’s-IP-address Continuing our example, you would run the following command: ssh-keygen -R 192.168.254.21:2222
     Note
     Another option is to delete the ~/.ssh/known_hosts file before proceeding to the next step.

  3. Run the command you tried to run previously.

Procedure

• Step 1: In an SSH client, enter the following command: ssh node’s-IP-address -l maglev -p 2222
• Step 2: If you see a message indicating that the node’s authenticity cannot be established, enter yes when prompted to continue.
• Step 3: Enter the Linux password configured for the node’s maglev user.
• Step 4: Enter the maglev command that you want to run.
• Step 5: Enter the password configured for Cisco DNA Center’s default admin superuser.

Typical Cluster Node Operations
The following operations are the ones you will typically need to complete for the nodes in your cluster, such as shutting down a cluster node (which you would do before performing planned maintenance), preparing a node for Return Merchandise Authorization (RMA), or rebooting (which you would do to restore a node that has been down or save configuration changes).

Note: You cannot simultaneously reboot or shut down two nodes in an operational three-node cluster, as this breaks the cluster’s quorum requirement.

sudo shutdown -h now command on all of the nodes at the same time.
Reboot one or more nodes after making any change that may require a reboot.| Run the sudo shutdown -r now command on the relevant nodes.
Operation| Required Actions
---|---
Shut down or disconnect one node

for maintenance (in situations where you are not just rebooting the node).

| Run the following commands:

1. maglev node drain node’s-IP-address

2. maglev node drain_history (to confirm that the node drained successfully)

3. sudo shutdown -h now (run on the node you are shutting down)

After performing maintenance on the node, complete the following steps:

1. Log in to the Cisco IMC GUI as the Cisco IMC user.

2. From the hyperlinked menu, choose Host Power > Power On to power on the node. It should take 30–45 minutes for the node to come back up.

3. Run the magctl node display command and wait for the node’s status to display as Ready.

4. Run the maglev node allow node’s-IP-address command.

5. Run the magctl workflow status command and wait until its output indicates that the task you initiated in the previous step completed successfully before you proceed.

6. Run the maglev service nodescale refresh command, which puts the node in maintenance mode.

Note **** Instead of running the command, you can also do the following:

a. In the Cisco DNA Center GUI, click the Menu icon (    ) and choose System > Settings > System Configuration > High Availability.

b. Click Activate High Availability.

Prepare a node for RMA.| Do the following:

1. Complete the steps descibed in the previous row for shutting down or disconnecting a cluster node for maintenance.

2. Run the magctl node display command to confirm that the node which was drained is in the NotReady state.

3. Contact the Cisco TAC for assistance with removing the node from your cluster.

4. Run the magctl node display command again.

Only two nodes should be displayed for the cluster now.

Replace a Failed Node
If a node fails, complete the following tasks in order to replace it:

1. Remove the failed node from your cluster. See Remove the Failed Node, on page 8.
2. Replace the failed node with another node. See Add a Replacement Node, on page 8.

Remove the Failed Node
If a node fails because of a hardware failure, you’ll need to remove it from the cluster. For assistance with this task, contact the Cisco TAC.

Warning
A two-node cluster (a transient configuration that’s not supported for normal use) results when one of the following situations occur:

• During the initial formation of a three-node cluster, only two of the cluster nodes are available.
• In an existing three-node cluster, one of the nodes has failed, or is currently down.

While a two-node cluster is active, you will not be able to remove either of its nodes.

Add a Replacement Node
After removing the failed node, you can add a replacement node to the cluster.

Before you begin
Make sure that you complete the following tasks:

• Remove the failed node. For information, see Remove the Failed Node, on page 8.
• Allocate at least 30 minutes to perform this procedure.

Procedure

• Step 1: On the replacement node, install the same software version that the other nodes in the cluster are running.
  • If you are configuring a first-generation appliance, use the Maglev Configuration wizard’s Join a Cisco DNA Center Cluster option. See the “Configure a Secondary Node” topic in the Cisco DNA Center First-Generation Appliance Installation Guide.
  • If you are configuring a second-generation appliance using the Maglev Configuration wizard, use the wizard’s Join a Cisco DNA Center Cluster option. See the “Configure a Secondary Node Using the Maglev Wizard” topic in the Cisco DNA Center Second-Generation Appliance Installation Guide.
  • If you are configuring a second-generation appliance using the browser-based configuration wizard, use the wizard’s Join an existing cluster option. See one of the following topics in the Cisco DNA Center Second-Generation Appliance Installation Guide:
  • 44 or 56-core appliance: See the “Configure a Secondary Node Using the Advanced Install Configuration Wizard” topic in the “Configure the 44/56-Core Appliance Using the Browser-Based Wizard” chapter.
  • 112-core appliance: See the “Configure a Secondary Node Using the Advanced Install Configuration Wizard” topic in the “Configure the 112-Core Appliance Using the Browser-Based Wizard” chapter.

Important: In the Maglev Cluster Details screen (Maglev Configuration wizard) or Primary Cluster Details screen (Advanced Install configuration wizard), enter the IP address that’s configured for the Cluster port on either of the nodes that are still active.

• Step 2: After the installation is complete, enter the following command: magical node display

  • The replacement node should show the Ready status.

• Step 3: Redistribute services to the replacement node by activating high availability on your cluster:

  • a. In the Cisco DNA Center GUI, click the Menu icon ( ) and choose System > Settings > System Configuration > High Availability.
    b. Click Activate High Availability.

• Step 4: Verify that services have been redistributed: magical app stack status

  • The replacement node should show a running.

• Step 5: If you previously backed up Assurance data, restore it.
  For information, see the “Restore Data from Backups” topic in the Cisco Digital Network Architecture Center Administrator Guide.

Important: After you add the failed node back to your cluster, it serves as an add-on node. The node does not resume its previous role as the primary node.

Minimize Failure and Outage Impact
In a typical three-node Cisco DNA Center cluster, each node is connected to a single cluster switch via the node’s cluster port interface. Connectivity with the cluster switch requires two transceivers and a fiber optic cable, any of which can fail. The cluster switch itself can also fail (due to things like a loss of power or manual restart), which can result in an outage of your Cisco DNA Center cluster and loss of all controller functionality. To minimize the impact of a failure or outage on your cluster, do one or more of the following:

• Perform management operations such as software upgrades, configuration reloads, and power cycling during non-critical time periods, as these operations can result in a cluster outage.
• Connect your cluster nodes to a switch that supports the in-service software upgrade (ISSU) feature. This feature allows you to upgrade system software while the system continues to forward traffic, using nonstop forwarding (NSF) with stateful switchover (SSO) to perform software upgrades with no system downtime.
• Connect your cluster nodes to a switch stack, which allows you to connect each cluster node to a different member of the switch stack joined via Cisco StackWise. As the cluster is connected to multiple switches, the impact of one switch going down is mitigated.

High Availability Failure Scenarios

Nodes can fail due to issues in one or more of the following areas:

• Software
• Network access
• Hardware

When a failure occurs, Cisco DNA Center normally detects it within 5 minutes and resolves the failure on its own. Failures that persist for longer than 5 minutes might require user intervention.
The following table describes failure scenarios your cluster might encounter and how Cisco DNA Center responds to them. Pay attention to the table’s first column, which indicates the scenarios that require action from you in order to restore the operation of your cluster.

Important: For a cluster to operate, Cisco DNA Center’s HA implementation requires at least two cluster nodes to be up at any given time.

immediately. See the “Backup and Restore” chapter in the Cisco Digital Network Architecture Center Administrator Guide.
No| A node fails, is unreachable, or experiences a service failure for less than 5 minutes.| •  The UI is not accessible for 5 minutes after a node fails.

•  Services that were running on the failed node are not migrated to other nodes.

•  The northbound interface (NBI) remains usable on the remaining two nodes when using the VIP.

•  VIP connectivity will be restored after failover, and API calls recover after services are up and running.

After the node is restored:

•  Data on the restored node is synched with other cluster members.

Note **** Historical Assurance data is restored, but data that was modified or updated during the failover process is not.

•  Pending UI and NBI calls that have not timed out complete.

connectivity with a node has been lost.

•  The UI remains usable on the remaining two nodes when using the VIP.

•  Services that were running on the failed node are migrated to other nodes.

•  The status of services running on the failed node may be set to either NodeLost or

Unknown.

•  The NBI on the failed node is not accessible, while the NBI on the remaining two nodes remain operational.

After the node is restored, and before the node rejoins the cluster:

•  Cisco DNA Center provides a status message indicating that cluster operation has resumed.

•  Pending UI calls that have not timed out complete.

•  Service requests that were pending on the failed node are completed on the node that the service was migrated to.

After the node rejoins the cluster:

•  Data on the restored node is synched with other cluster members.

•  Services that were running on the failed node are stopped.

•  All service requests that were pending on the failed node are stopped.

•  Assurance UI selections operate as expected.

Yes| Two nodes fail or are unreachable.| The cluster is broken and the UI is not accessible until connectivity has been restored.

•  If the nodes recover, operations resume and the data shared by cluster members is synced.

•  If the nodes do not recover, contact the Cisco TAC for assistance.

Yes| A node fails and needs to be removed from a cluster.| Contact the Cisco TAC for assistance.
No| All nodes lose connectivity with one another.| The UI is not accessible until connectivity has been restored. Once connectivity has been restored, operations resume and the data shared by cluster members is synced.
Yes| A backup is scheduled and a node goes down due to a hardware failure.| Contact the Cisco TAC for a replacement node, as well as assistance with joining the new node to the cluster and restoring services on the two remaining nodes.
Requires User Action| Failure Scenario| HA Behavior
---|---|---
Yes| A red banner in the UI indicates that a node is down: “Assurance services are

currently down. Connectivity with host _< IP-address> _has been lost.”

| The banner indicates that the node is down. As a result, Assurance data collection and processing stops and data will not be available. If the node comes back up, your Assurance functionality is restored. If the failure is related to a hardware failure, do the following:

1. Remove the node that failed.

See Remove the Failed Node, on page 8.

2. Add a new node to replace the one that failed. See Add a Replacement Node, on page 8.

Yes| A red banner in the UI indicates that a node is down, but eventually changes to yellow with this message: “This IP address is down.”| The system is still usable. Investigate why the node is down, and bring it back up.
Yes| A failure occurs while upgrading a cluster.| Contact the Cisco TAC for assistance.
No| An appliance port fails.| •  Cluster port: Cisco DNA Center detects the failure within 5 minutes and times the user out. After 5 minutes, you should be able to log back in. A banner then appears, indicating the services that are currently unavailable. Service failover completes within 10 minutes. The areas of the UI you can access will depend on which services have been restored. After the services that were unavailable are fully restored, the banner closes.

•  Enterprise port: Cisco DNA Center might not be able to reach and manage your network.

•  Management port: Any upgrades and image downloads that are currently in progress will fail and northbound interface operations will also be affected.

Yes| Appliance hardware fails.| Replace the hardware component (such as a fan, power supply, or disk drive) that failed. Because multiple instances of these components are found in an appliance, the failure of one component can be tolerated temporarily.

As the RAID controller syncs a newly added disk drive with the other drives on the appliance, there might be a degradation in performance on the I/O system while this occurs.

Explanation of Pending State During a Failover

A pod that is in Pending state behaves as follows:

• Stateful set: The pod has some type of data storage. These pods are node-bound using local persistent volume (LPV)—when the node is down, all stateful sets on that node move to the Pending state. Stateful examples are MongoDB, Elasticsearch, and Postgres.
• DaemonSet: By design, the pod is strictly node-bound. DaemonSet examples are agent, broker-agent, and keepalive.
• Stateless/deployment:
  • While the pod doesn’t have data to store on its own, it uses a stateful set to store and/or retrieve data.
  • Deployment scale varies. Some deployments have 1x pod instance (such as spf-service-manager-service); some have 2x pod instances (such as apic-em-inventory-manager-service); some have 3x pod instances (such as kong, platform-ui, collector-snmp).
  • The 1x stateless pods are free to move across nodes based on the current state of the cluster.
  • The 2x stateless pods have the flexibility to move across nodes, but no two instances of stateless pods can run on the same node.
  • The 3x stateless pods have node anti-affinity, meaning no two instances can run on the same node.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE- NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version. Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)
© 2021 Cisco Systems, Inc. All rights reserved.

FAQ

Q: Can I have more than three nodes in a Cisco DNA Center High Availability cluster?
A: No, Cisco DNA Center does not support a cluster with more than three nodes. The fault tolerance mechanism is designed to handle single-node failure.

Q: Are CLI user credentials shared across nodes in a multinode cluster?
A: No, CLI user credentials are not shared and remain separate for each node even in a multinode cluster.

References

• Kubernetes 1.14: Local Persistent Volumes GA | Kubernetes
• DaemonSet | Kubernetes
• Deployments | Kubernetes
• RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space
• Cisco Trademarks - Cisco
• Cisco Catalyst Center - Install and Upgrade Guides - Cisco
• Cisco Catalyst Center - Maintain and Operate Guides - Cisco

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>