Turbonomic High Availability Deployment Best Practices
Turbonomic’s is a micro services application design with resiliency and scalability in mind.
By design, the software takes advantage of high availability functionality in Kubernetes. All Turbonomic pods are stateless and decoupled. Any component can be killed at any time - Kubernetes will restart the component and Turbonomic will be fully operational without human interference.
Turbonomic’s preferred method of deployment is on top of the customer’s supported Kubernetes environment. The software can be deployed on any flavor including OpenShift, AKS, EKS, GKE etc.
Turbonomic’s pod architecture:
In plan rich deployments, i.e. if multiple plans will run concurrently, Turbonomic recommends scaling the market pod horizontally.
MySQL stores historical consumption data for all entities in the system. This will be the component consuming the most storage space in the system (Typically 500 GB for a large enterprise).
Turbonomic recommends externalizing the MySQL DB, preferably leveraging your organization’s DBaaS. This will allow you to backup / restore / failover the DB the same way you would other mission critical applications. Port 443 (HTTPS) and port 3306 (MySQL) needs to be allowed outbound, and port 443 (HTTPS) back to the Turbonomic server.
ArangoDB stores historical plan results. Those are not used in the system for live decisions by the market. HashiCorp Consul stores encrypted target data (i.e. the targets Turbonomic is pointing to), consuming typically less than 1 MB.
If you do not have a K8s platform you can take advantage of, Turbonomic can supply an OVA with a K8s cluster running on top of it.
IMPORTANT: While Turbonomic can deliver the software inside and OVA, Turbonomic doesn’t provide a “Black box appliance”; i.e. all OS maintenance needs to be handled by the customer etc. If the customer does not allow this approach, the Turbonomic application can easily deploy onto your K8s cluster that is built on your approved OS. See the Overview of Deploying Turbonomic on any multinode k8s cluster
In this case, we will recommend deploying 2 VMs in a hot / cold configuration. Again, we advise externalizing the MySQL DB, preferably leveraging your organization’s DBaaS. This will allow you to backup / restore / failover the DB the same way you would other mission critical applications.
Consul data (stored encrypted target information) should be regularly copied in between instances. (Again, typically less that 1 MB, only changes if target list changes).
In case the main VM fails, the cold VM can point to the Database and start automating the actions.
Important: both instances can’t work with the same database at the same time.
If you would like a hot / warm configuration you will need to have two separate databases:
In case the main VM fails, the warm VM can start automating actions immediately.