Active/Passive High Availability
Kerio Control version 9.3 or newer support High Availability in Active/Passive mode. Having this configuration in place ensures that if the Master Kerio Control appliance fails, the Slave appliance automatically replaces it to ensure continued protection with no blockers or downtime.
Enabling High Availability
To set up Active/Passive High Availability, you need identical Kerio Control appliances as Master and Slave. This means that in case of hardware appliances the model number and version should be the same, and in case of software appliances, the versions should match. In addition to this, both appliances should have the same number of interfaces and their names configured, same admin credentials set and the disk partitioning details should also match.
You can use the diagram below while setting up High Availability using hardware boxes. The objective is to have a two identical Kerio Control appliances (both hardware or software supported) set up in a specific network configuration.
Hardware boxes configuration for High Availability
Follow these steps to configure High Availability:
- Set up two Kerio Control version 9.3 or newer appliances to be used as Master and Slave devices. For more information refer to Installation.
- Run both appliances.
- In the admin console of both appliances, go to the High Availability tab, and set the following fields:
| Field | Description |
|---|---|
| High Availability | Select the mode for High Availability configuration. At the moment only Active/Passive mode is supported in Kerio Control. |
| Instance Mode | Select Master for your primary appliance and Slave for your secondary appliance. |
| Sync/Status Interface |
Select an Ethernet interface to be used for synchronization between Master and Slave appliance to enable High Availability. |
| Device Name | Enter different device names for both Master and Slave appliances. |
| Shared Secret | Enter a key to be used for validation during synchronization between the Master and Slave appliance. The key should match in both appliances for successful synchronization. |
Master appliance settings
Slave appliance settings
- In the list of existing interfaces that appear in the grid below, select the interfaces that you want to be available at all time.
- Assign each selected interface a virtual IP. Virtual IP moves between Master and Slave and is given to clients as a floating gateway. Since this gateway is always up (either Master or Slave), the client is never disconnected. This virtual IP of interfaces should match in both Master and Slave appliance.
Example Master appliance interfaces
Example Slave appliance interfaces
- After performing this configuration on both Master and Slave appliances, click Apply to initiate synchronization between Master and Slave appliance.
While activating High Availability, the system runs a two-phase validation process before synchronizing Master and Slave appliances:
- Phase 1 - Validation of shared secret, device name, instance mode, identical Master and Slave appliance, etc.
- Phase 2 - Mapping interfaces between Master and Slave. Both Master and Slave appliances should have the same number of interfaces and same interface names as also shown in the above images.
The synchronization result can be seen through the Status and Health Check fields on the High Availability tab on both Master and Slave appliances.
Successful synchronization status
High Availability Statuses
| Status | Description |
|---|---|
| OK | This is shown when the High Availability is enabled, the Master appliance is up and functioning correctly, and the Slave appliance is also reachable. |
| Master Down | This is shown when the Master appliance is down and not responding but the Slave appliance is up and functioning correctly. |
| Failure (No Virtual IPs Assigned) | This is shown on the Master appliance when it is in a transient state where High Availability has been enabled but no virtual IP has been picked up yet. Shortly after the virtual IP is picked, the status changes to OK. |
| Failure (Master down, Slave no Virtual IPs) | This is shown on the Slave appliance when it is in a transient state where the Master appliance is down, and the high availability on the Slave appliance has been activated. As it picks the virtual IP the status changes to Master Down. |
| Failure (ucarp failed) |
This can appear on both Master and Slave appliance when the ucarp process is not running. To debug ucarp-related problems, you can enable syslog messages in Debug logs where ucarp logs can be found. |
| Disabled | This a default status that appears on both Master and Slave appliance when High Availability is disabled. |
Health Check Statuses
| Status | Description |
|---|---|
| Successful | This appears when no problem is found while synchronizing the appliances and the High Availability gets activated successfully. |
| Validation Failed (Secrets are not matching) | This appears when the Master and Slave appliance have different shared secret configured and they couldn't be matched during validation. |
| Validation Failed (Appliance type should be the same for Master and Slave.) | This appears when the Master and Slave hardware box models are not identical. |
| Validation Failed (Version should be the same for Master and Slave.) | This appears when the Master and Slave release build version is not same. |
| Validation Failed (Interface names are not matching.) | This appears when the Master and Slave appliance don't have the same number of interfaces or similar interface names configured. |
| Validation Failed (Both machines are in the same mode.) | This appears when both Master and Slave appliance are set to same High Availability Instance Mode. |
| Validation Failed (Peer token is invalid.) | This appears when High Availability is enabled and it is in a transient state sending some old token that is unknown to the system. Shortly after the token is automatically renewed the status changes to Successful. |
| Validation Failed (Master and Slave should have different device names.) | This appears when the Master and Slave appliance have the same the Device Name set. |
| Validation Failed (No response) | This appears when either the peer appliance is down, High Availability is disabled or High Availability Sync traffic is blocked. |
| Health check failed. | After validating the appliance configuration, the peer is then monitored with heart beat. This status appears when the validation was done successfully but later it lost connection to peer. |
On successful enabling the High Availability, all existing configuration - DHCPDynamic Host Configuration Protocol - A protocol that automatically gives IP addresses and additional configuration to hosts in a network. leases, Certificates, Users etc. get synchronized between the Master and Slave appliance. This however excludes High Availability and Interface configuration.
In case of failover, when the Slave appliance takeover, it takes ownership of the Virtual IP. The configuration changes done to the Slave device are not transferred to the Master device until it is up again.
High Availability Alert Management
In Kerio Control, you can activate alerts for Master and Slave up/down events from the Accounting and Monitoring > Alert Settings > System Alert page. These alerts are sent as emails to the registered email address from both Master and Slave appliance when its peer appliance goes up or down.