Enabling Autofailover

After pairing the HPE Aruba Networking Central On-Premises clusters for Datacenter Redundancy and scheduling the backup on both primary and secondary, enable the autofailover. For more information, see Configure Redundancy and Back up and Restore System Data.

To enable autofailover for HPE Aruba Networking Central On-Premises clusters, complete the following steps on both clusters:

In the HPE Aruba Networking Central On-Premises app Short form for application. It generally refers to the application that is downloaded and used on mobile devices. , set the filter to Global.
Under Global Settings, select System Management > Datacenter Redundancy.
The Datacenter Redundancy tab is displayed. Ensure both primary and secondary cluster are displayed in the Redundancy Status table.
Click the Auto Failover toggle switch to enable.

This ensures that automatically control is transferred to the peer cluster when a failure is detected. The automatic switch happens when the health status of the primary cluster continues to be poor or bad for the specified Time to Failover. A cluster is considered to be in poor state when more than one node is in the Down state.

When the auto failover is initiated after the specified Time to Failover, the switchover process takes approximately 60 minutes for the secondary cluster to attain the primary role. During this switchover operation, the WebUI displays This page is not working message.
Choose a value for Restore Frequency (Days) from the drop-down list.

By default, it is set to 3 days. This value indicates that there is a 3-day interval between two consecutive restore operations. For example, if the first restore is done on 6 June 2023, then after an interval of three days, the next restore is done on 10 June 2023.

After a failover, if a device displays an Out of Sync or Error state while updating device configuration to the UI User Interface. group, try this workaround.

Move that device to a different UI group.

For information about how to assign device to a group, see Assigning Devices to Groups.
Wait for the state of the device to display as Sync.
Move it back to the its old group.

Instant Access Point Status after Failover

After a failover, the correct operational status of the Instant AP does not reflect immediately. When the primary server becomes inactive, the secondary server waits approximately 30 minutes before declaring the primary as down before promoting itself. This is followed by an additional 30–40 minutes time to bring up infrastructure and application services, depending on the scale and node size.

In parallel, the secondary server attempts to connect using the 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. key (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. -option43). During this time, Instant APs continue to appear in their previous state until reconnection and data refresh are complete. As a result, the overall process may take approximately 90 to 120 minutes for the actual network conditions to be reflected on the new cluster.

Campus AP and Controller Status after Failover

During failover, the secondary server configured as management server in the controller attempts to connect using HTTP Hypertext Transfer Protocol. The HTTP is an application protocol to transfer data over the web. The HTTP protocol defines how messages are formatted and transmitted, and the actions that the w servers and browsers should take in response to various commands. and SNMP Simple Network Management Protocol. SNMP is a TCP/IP standard protocol for managing devices on IP networks. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and more. It is used mostly in network management systems to monitor network-attached devices for conditions that warrant administrative attention. profiles. controllers continue to display their status and stats in the secondary server. Consequently, it takes approximately 90 to 120 minutes for the updated network conditions to be accurately reflected on the new cluster.

Autofailover in Split-Brain (Communication Failure) Scenario

If there is communication failure between the two HPE Aruba Networking Central On-Premises clusters, then both clusters consider that the peer cluster is down. This is called a split-brain scenario. When autofailover is enabled and split-brain scenario is encountered, the secondary fails to reach primary and attains the primary role. This causes both the clusters to operate as primary. In such a case, the devices monitoring is split between the two clusters. After communication is resumed between the clusters, the old primary attains the secondary role.