If you want to enable or disable High Availability for your cloud, please contact your account manager.
High availability (HA) is the capability of a system to operate continuously for a desirably long period of time despite the possible failure of one or several of its components. HA significantly decreases the extent of downtime. OnApp High Availability brings new opportunity to deploy more than one Control Panel within one cloud. This allows you to improve cloud load balancing, minimize server downtime in case of CP issues and enhance scalability of the whole infrastructure. High availability keeps virtual servers, daemon, and statistics live even if the physical box where they are running fails. In this case the required component keeps working on the box which is live in the cluster. This is the optional functionality.
OnApp introduces sever possible High Availability configurations depending on your infrastructure and resources. OnApp High availability is based on Pacemaker + Corosync clustering stack, using multicast as a messaging backend. At this stage OnApp introduces high availability for the following components:
- UI (httpd, onapp-vnc-proxy services)
- Background services (onapp-engine, onapp-ssh-agent services)
- Cloudboot (nfs, xinetd, dhcpd services)
- Load Balancer
- Message Queue
High availability introduces accessibility for services and communication between OnApp components:
- Database and Redis are deployed separately from CPs by cloud owner. You can deploy DB and Redis on the same or separate servers. In OnApp, we refer to this server as the Database&Transactions server.
- Compute resources and backup servers are configured to accept connections from any Control Panel.
- UI and CloudBoot operates in Active/Standby or Active/Active mode.
OnApp Engine, onapp-engine service (onapp daemon) operates in load balancing mode.
In case when service in active node becomes unavailable, the corresponding virtual IP address is being moved from the active node's to the other node's network interface with the highest priority. The network interface priority defines to which node the virtual IP address will be moved first, if the node where it is running gets broken.
- Make sure to create a dedicated network for control panels and DB/Redis server connection.
- Do not use the control panel server as the backup/template server. Make sure that the Use SSH file transfer option is disabled at Settings > Configuration menu.
- Logs and templates are stored on Database&Transactions server. Ensure that all the required directories are shared correctly.
- It is important that you add the IPs of CP servers into the config files for Compute resources and backup servers.
- Compute resources accept API calls by StorageAPI from multiple IP Addresses only after reconfiguration.
- SNMP Traps are being sent to control panels.