High Availability for YumaPro Servers (YP-HA)


In YumaPro SDK version 16.10 and later, the netconfd-pro server supports the following hardware-based high-availability features:

  • The configuration data on the active server can be replicated on multiple standby servers.
  • The module and bundle configuration on the active server can be replicated on multiple standby servers, even if modules or bundles are loaded or unloaded at run-time.
  • An HA server pool is configured through the CLI or configuration file. Only servers specified in the configuration are allowed to join the YP-HA server pool.
  • Each HA server operates in a specific HA Role:
    • active: There is one active server in the HA pool providing full service and management features.
    • standby: All but one server can be in Standby mode. Only superuser sessions are allowed in this mode. Notifications are disabled. The server will connect to the active server and participate in the YP-HA protocol.
    • none: The server is waiting its HA role. It is not attempting to connect to any active server. Only superuser sessions are allowed in this mode. Notifications are disabled.
  • The server HA Role (Active, Standby, or None) can be switched in several ways:
    • yp-system library init1 function callback (to set initial role)
    • agt_timer callbacks at run-time
    • DB-API subsystem using the <yp-ha-mode> subsystem event message
    • yp-ha-app program
      • yp-ha-app --go-active
      • yp-ha-app --go-standby=new-active
      • yp-ha-app --go-none
  • Management sessions and notification processing are disabled if the server is in HA standby mode
    • Management sessions are enabled for the “superuser” user name if configured
  • SIL-SA and DB-API sessions are always allowed, even if YP-HA is in standby mode
  • DB-API edit requests for system edits will be enabled in a future release
  • DB-API edit requests for user edits are disabled if the server is in HA standby mode
  • The --ha-sil-standby parameter can be used to enable edit callbacks (SIL, SIL-SA, HOOK) on a server running in HA standby mode. The server callback code must understand that YP-HA is enabled and the server is running in HA standby mode.


If YP-HA is enabled, then the server will wait for its HA role unless the --ha-initial-active CLI parameter is set.

The --ha-initial-active parameter should only be used for debugging because if the server reboots it will use the assigned role.


In normal operation all YP-HA roles are set and changed by external code (external process of same process).


If the server boots waiting for its HA role, then an empty factory default configuration will be loaded in order to validate the YANG modules loaded.

If the server starts the HA active role, then the configuration will be loaded for real before management sessions and notifications are enabled.

If the server starts the HA standby role, then it will get its configuration from the active server.


Setting up a YP-HA server pool


There are several mandatory parameters to configure on each when setting up YP-HA.

The following table summarizes what parameters must be set in netconfd-pro's configuration file (/etc/yumapro/netconfd-pro.conf is the default file location):


Parameter
Description
ha-enabled
Enabled the YP-HA feature
ha-initial-active
Set the HA role from the CLI at boot-time (for debugging only)
ha-server
Configure a server in the YP-HA server pool
ha-server-key
String identifying the HA server pool for the server
ha-sil-standby
Enable edit callbacks (SIL, SIL-SA, HOOK) in YP-HA standby mode
server-id

Identifies a server within a YP-HA pool, default value is server1

socket-type=tcp
The YControl socket type must be set to “tcp”
socket-address
The YControl socket address must be set
socket-port
The YControl socket port number must be set


Let's take a look at an example. Here we have three separate systems, each running netconfd-pro:



Configuration Parameters for Server ha-1:


ha­-enabled true 
ha­-server ha­[email protected]
ha­-server  ha­[email protected]
ha­-server ha­[email protected] 
ha­-server­-key ha-­pool­1 
server­-id ha-1 
socket­-type tcp 
socket­-address 192.168.0.100 
socket­-port 8088


Configuration Parameters for Server ha-2:


ha­-enabled true 
ha­-server ha­[email protected]
ha­-server  ha­[email protected]
ha­-server ha­[email protected] 
ha­-server­-key ha-­pool­1 
server­-id ha-2
socket­-type tcp 
socket­-address 192.168.0.105
socket­-port 8088


Configuration Parameters for Server ha-3:


ha­-enabled true 
ha­-server ha­[email protected]
ha­-server  ha­[email protected]
ha­-server ha­[email protected] 
ha­-server­-key ha-­pool­1 
server­-id ha-3 
socket­-type tcp 
socket­-address 192.168.0.108 
socket­-port 8088


In this configuration, all three servers will be neither active nor standby at boot time and will instead start waiting for an HA role.


It is expected that one server will be assigned the HA active role and the other two servers will be assigned the HA standby role.