High availability deployment best practices

Turbonomic takes advantage of high availability functions in Kubernetes. All Turbonomic pods are stateless and decoupled, and any component can be stopped at any time. If a component is stopped, Kubernetes restarts the component and Turbonomic is fully operational without human interference.

Deploying Turbonomic on Kubernetes with an external database

The preferred method to deploy Turbonomic is on your supported Kubernetes environment with an external database, including Red Hat OpenShift, Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE).

Turbonomic pod architecture

Key considerations

In plan rich deployments where multiple plans run concurrently, Turbonomic recommends scaling the market pod horizontally.
MySQL stores historical consumption data for all entities in Turbonomic. This component uses the most storage space in Turbonomic (typically 500 GB for a large enterprise).
Turbonomic recommends externalizing the MySQL database, preferably that uses your organization DBaaS. With this configuration, you can backup, restore, or failover the database the same way that you would allow other mission-critical applications. Port 443 (HTTPS) and port 3306 (MySQL) need to be allowed outbound, and port 443 (HTTPS) sends back to the Turbonomic server.
ArangoDB stores historical plan results, which are not used in Turbonomic for live market decisions.

Deploying Turbonomic in a Kubernetes cluster running inside a virtual machine

If you do not have a Kubernetes platform that you can use, Turbonomic can supply an OVA with a Kubernetes cluster that is running on it.

Important:

While Turbonomic can deliver the software inside an OVA, Turbonomic does not provide a “Black box appliance” (that is, you need to handle all OS maintenance). If your environment does not allow this approach, Turbonomic can deploy onto your Kubernetes cluster that is built on your approved Operating System.

Hot and Cold configuration

In this case, deploy two VMs in a hot and cold configuration, and externalize the MySQL database (preferably that uses your organization DBaaS). With this configuration, you can backup, restore, failover the database the same way you would other mission-critical applications. Consul data (stored encrypted target information) should be regularly copied in between instances (typically less that 1 MB, this value changes if target list changes). If the main VM fails, the cold VM points to the database and starts automating actions.

Note:

Both instances cannot work with the same database at the same time.

Hot and Warm configuration

A hot and warm configuration requires two separate databases. If the main VM fails, the warm VM starts automating actions immediately.