Configuring Failover for Linux App Console in DDI Central

DDI Central now facilitates implementing failover capabilities for DDI app console, for providing consistent service during server down scenarios. App console can be installed in both primary and secondary servers for a complete failover mechanism, where if the primary goes down, the secondary server would step up and take full control over the service providing.

To configure failover in DDI Central application,

  • Two installations are required. The DDI Central app console must be installed in both primary and secondary servers.
  • Both primary or secondary servers should run on the same HTTPS port.
  • Both servers should be in sync, and they should have consistent connectivity.
  • Both servers should be installed with the same app console version(Ex: Linux BIND version should be installed in both primary and secondary servers).
  • Both servers should run on the same version of the app console.

When configuring the failover in DDI Central, users need to provide secondary server's client ID and client secret in the fields.

To get the client ID and client secret, Log in to the secondary server.

Click on the Profile, where you can find the Client credentials section. Select View option would display the client ID and client secret.

Database Replication

In this section, users need to provide the password for the replication process, as the username field will be auto-filled with a constant username called "replicator" and cannot be changed.

You can provide any secure password or you can generate a random one on DDI Central's suggestion by clicking on the Suggest button.

Note: The replication password must be alphanumerical.

Once the password is added, admins cannot edit or change the password, as it would cut-down the connectivity between the servers.

Note: In case you forgot the password, please contact DDI Central support.

The main purpose for the data replication section is to keep both database servers in sync and enable data reflection, i.e., changes made in primary server reflects in secondary server.

When the primary server fails, the secondary server gets promoted as the primary after 2 mins.

High Availability

High availability in DDI app console will be implemented through keepalived, which is a Linux package commonly used to provide high availability (HA) between two servers. It does this by monitoring postgres service and httpd service health and managing a shared Virtual IP (VIP) between two servers. HA can be enabled or disabled for the app console.

How Keepalived Works

  • It keeps one server "active" and another "standby"
  • Both servers are configured to monitor each other by communicating with each other.

Note: Virtual IP, and the IP address of both Primary and Secondary servers, all should be configured in the same subnet.

Also, VIP and the IPs of both primary and secondary servers should be configured in exclusion range, it should not be configured for any static or dynamic DHCP leases.

The IPs deployed for the primary and secondary servers must be in fixed or reserved state in DDI Central.

Keepalived requires a Virtual IP (VIP) which is a shared IP address used by clients. It makes sure that only the Primary console server holds the VIP at any moment.

When the active server fails, the standby immediately takes over the VIP. This ensures that clients always reach the service through the same IP—even if the underlying server changes.

VRRP (Virtual Router Redundancy Protocol) is the protocol used by keepalived to manage which server owns the VIP. Operates by sending "heartbeat" packets between the HA pair.

Note:

Before Failover occurs, Web login for the secondary server will be restricted when the primary is up. The secondary server will be available only in a "read only" mode, and no configurations or data changes can be implemented through the secondary server.

After providing the client ID and client secret of secondary server, and configuring app console failover in primary server, the secondary server need to be restarted with the following command:

systemctl restart DDI    

Maintenance mode:

While upgrading a service pack or PPM, or starting a service, network admins must enable the maintenance mode in the primary server. Maintenance mode pauses the data replication process between primary and secondary servers, which allows admins to do configurations and changes in the servers, such as upgrading PPM.

Enabling maintenance mode in the primary server will reflect in secondary server.

Note: Maintenance mode needs to be manually enabled in the primary server.

During maintenance mode, service takeover will not occur, but the data syncing continues. As a result, the sync status will display "synced" and also shows the "last synced time."

Promoting servers

When the current secondary server is up and ready, if the admin wants to promote it as the primary for handling the service, they can be promoted by clicking on the Promote button.

Once you click on Yes in the promotion confirmation dialog box, It will trigger a log-out, you'll have to wait for sometime. The waiting time depends on the size of your database.