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):
||Enabled the YP-HA feature
||Set the HA role from the CLI at boot-time (for debugging only)
||Configure a server in the YP-HA server pool
||String identifying the HA server pool for the server
||Enable edit callbacks (SIL, SIL-SA, HOOK) in YP-HA standby mode
Identifies a server within a YP-HA pool, default value is server1
||The YControl socket type must be set to “tcp”
||The YControl socket address must be set
||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 email@example.com ha-server firstname.lastname@example.org ha-server email@example.com ha-server-key ha-pool1 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 firstname.lastname@example.org ha-server email@example.com ha-server firstname.lastname@example.org ha-server-key ha-pool1 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 email@example.com ha-server firstname.lastname@example.org ha-server email@example.com ha-server-key ha-pool1 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.