Configure Redundancy

Datacenter Redundancy is configured between two HPE Aruba Networking Central On-Premises clusters to provide data redundancy on the secondary cluster, so that it can continue to operate if there is a failure.

The Single-node deployment of HPE Aruba Networking Central On-Premises supports the Datacenter Redundancy functionality. For more information, see Scale Devices for Cluster.

On HPE Aruba Networking Central On-Premises WebUI, two similar clusters are paired for redundancy. The primary cluster acts as a normal HPE Aruba Networking Central On-Premises cluster and the secondary cluster has the redundant data. If there is a failure, the secondary will act as the primary to continue the network functioning.

Devices Supporting Datacenter Redundancy

• Campus APs

• AOS-CX Switches

  Only AOS-CX switches running 10.12.1000 or later firmware version is supported.

• Instant Access Points

  Only Instant Access Point models running ArubaOS 8.12.0.0 or later software version is supported.

• Controllers

  • ArubaOS 8.x requirements for Datacenter Redundancy, onboard the controller only on the primary cluster. Add the virtual IPs of both the clusters in the management server of the controller.

For the complete list of device details, see Supported Devices

Prerequisites:

• Ensure both the HPE Aruba Networking Central On-Premises clusters are running on the same version and have same number of nodes on their clusters.

• Ensure both the HPE Aruba Networking Central On-Premises clusters are active and healthy.

• Ensure both the HPE Aruba Networking Central On-Premises clusters have same deployment type (online, offline, FIPS Federal Information Processing Standards. FIPS validation is mandatory for federal government departments that collect, store, transfer, share, and disseminate sensitive data. , appliance, or non-appliance)

• Ensure both the HPE Aruba Networking Central On-Premises clusters have distinct IPs, FQDNs, and hostnames.

• Ensure an external backup server with adequate storage space is configured. The storage requirement is dependent on the size of backups generated by the cluster. The backup server must have access to both the clusters and the clusters must have good latency and bandwidth (above 1 Gbps Gigabits per second. ) for faster backup operation. A bandwidth of 10 Gbps throughput is recommended for optimal performance between the backup server and HPE Aruba Networking Central On-Premises clusters. Ensure the data backup is taken on the primary cluster and that data is restored on the secondary cluster.

• Ensure to schedule backup on both clusters before pairing them for DR. The Backup Mode must be same on both clusters, either Full Backup or Incremental Backup. For more information, seeBackup and Restore Data in DR Cluster.

• Both clusters must be configured with DHCP Dynamic Host Configuration Protocol. A network protocol that enables a server to automatically assign an IP address to an IP-enabled device from a defined range of numbers configured for a given network. option 43 for the Instant APs to support datacenter redundancy. Therefore, it is not required to establish WebSocket connection for Instant APs. The Option 60 is required for the initial onboarding The process of preparing a device for use on an enterprise network, by creating the appropriate access credentials and setting up the network connection parameters. of devices via Pre-Shared Key (PSK Pre-shared key. A unique  shared secret that was previously shared between two parties by using a secure channel. This is used with WPA security, which requires the owner of a network to provide a passphrase to users for network access.  ). For more information, see Adding Instant APs and Switches Using PSK.

  Option 43 in the format <device_name>,<server1_IP>,<pre-shared key>,<server2_IP>. Example,

  option 43 text "305_IAP,100.100.100.10,pre-shared_key,100.100.100.20"

• During a failover, switches back off from the primary cluster because the IP is no more reachable. Then, the switches try to establish connection to the secondary cluster either through management or default VRF. For more information about switch CLI Command-Line Interface. A console interface with a command line shell that allows users to execute text input as commands and convert these commands to appropriate functions. cluster configurations, see location-override or location-override-alternative for AOS-CX switches on The CLI Bank. A command name can be same between the products, so ensure to choose your command based on the native product or feature.

• Ensure that ZTP Zero Touch Provisioning. ZTP is a device provisioning mechanism that allows automatic and quick provisioning of devices with a minimal or at times no manual intervention. is supported for the switches in the DR cluster for the DHCP provisioning of primary and secondary cluster IP.

• Ensure to enable 443 port bidirectional traffic for HTTPS Hypertext Transfer Protocol Secure. HTTPS is a variant of the HTTP that adds a layer of security on the data in transit through a secure socket layer  or transport layer security protocol connection. communication between the DR clusters. For more information, see Configure Communication Ports .

For information about how to pair and configure two HPE Aruba Networking Central On-Premises clusters for redundancy, see Pairing and Configuring the Clusters

Limitations:

• During any system operation, the DR operations such as failover or data synchronization are not allowed until the system operation is completed on the HPE Aruba Networking Central On-Premises cluster.

• After the failover, the administrator must set up the controller WebSocket configuration to the new HPE Aruba Networking Central On-Premises cluster. For more information, see WebSocket Connection for Controllers.

• If factory reset is done on one cluster, then DR must be re-configured on both the clusters.

• After the failover, the correct status of AOS-CX switches may appear after a short delay. This is because the restart and stabilization process takes time, and until such time, the switch may continue to be displayed in the previous state. Once the switches are reconnected and their status has changed, the data is refreshed and displayed appropriately. Depending on the size and load, this process can take up to about two hours.

• If Incremental Backup type is configured on DR-enabled clusters and a failover occurs, the backup and restore of data on the new primary or secondary does not continue for remaining days of the current cycle. Instead, it starts new from the next cycle.

  For example, consider that Incremental Backup is set for a week frequency with Back Up start day on Monday 8th July and Time is set to 10:00 p.m. Backup and restore operation was done up to Wednesday 10th July and there was a failover on Thursday 11th July, then the next backup and restore cycle starts only on the coming Monday that is 15th July at 10:00 p.m. Because of the switchover of primary and secondary clusters due to failover, backup and restore operation did not happen on Friday 12th July, Saturday 13th July, and Sunday 14th July.

  If the backup operation fails for any reason, an alert is generated on the Analyze > Alerts & Events page for the COP Backup\Restore Operation Status category.

The following animation shows how to configure redundancy between clusters.