In my last post I discussed the need for software to be able to make decisions—and how having a full-stack understanding of Pivotal Cloud Foundry with the underlying infrastructure is critical to accurately determining the right actions. If the actions aren’t specific and accurate, you can’t automate them! So, let’s dig into these actions and how they map back to Turbonomic’s unique analysis of the full stack.
Managing the Infrastructure
Operating shared virtualized infrastructure allows for better efficiency, but poses challenges if only managed from one perspective. Too often we see customers managing their container deployments separately from the underlying (traditional) infrastructure when the reality is these layers of the stack are very interdependent—a change here can trigger risk there (and vice versa). Turbonomic’s full stack analysis manages the underlying infrastructure and defines VM/Diego Cell scaling with an understanding of how much of the required resources are truly available.
- Continuous Control of Infrastructure via the Hypervisor: VM placement to avoid congestion, increase efficiency, and maintain HA goals. Deeper insight to know when to provision more compute or storage.
- Full-Stack Control of PCF on that Infrastructure: When PCF is stitched to the underlying infrastructure, Turbonomic understands performance risks and bottlenecks, as well as cost implications (public cloud) and opportunities to save or be more efficient.
Therefore when Turbonomic provides actions relating to VM/Diego Cell placement or scaling, these actions will account for:
- Fluctuating demand (current and historical) of the container workload
- Infrastructure utilization and availability (host compute, storage, network, public cloud cost)
- Compliance with policies (ex. HA, affinity/anti-affinity, data sovereignty, etc.)
In other words, Turbonomic manages the trade-offs between performance, policy compliance and efficiency/cost in public cloud IaaS. Actions which automatically scale up/out resources when demand increases and scale them back when demand subsides. And the actions can be executed through the proper PCF mechanisms: Diego Cell scaling will be executed by BOSH, made possible by direct integration with Pivotal Ops Manager.
An additional benefit that Turbonomic provides through its ability to stitch the stack together is giving the DevOps user visibility to the PCF deployment’s environment based on the Job Name, PCF Deployment Identifier stitched with the underlying IaaS VM name PLUS performance or cost data from the IaaS layer. As seen in Figure 3 the user can easily identify these jobs, and associate them directly with the vCenter VM, AWS Instance, Azure VM, etc. This allows the user to define policies based on Job, PCF Deployment and flexible reporting grouping options.
More importantly, having Turbonomic stitch PCF to your IaaS platform allows you to quickly and easily see the performance risks that Turbonomic sees as well as the specific automatable actions that can avoid that performance degradation altogether. Navigate from service à container à any PCF VM by job and see performance details such as ready queue, swapping, ballooning, IOPS latencies. This saves organizations time and money to avoid labor of having multiple people pulling metrics from different places.
Turbonomic’s analytics engine also provides a way to define policies that can help you manage your PCF infrastructure’s high availability, licensing compliance and/or access to resources in a shared cluster. One use case is to help PCF customers leverage shared clusters using Resource Pools as PCF Availability Zones (AZs). Turbonomic would make sure that VMs are separated on physical hosts for high availability. The approach will be to have PCF AZ’s defined as vCenter resource pools, and a Turbonomic policy will map the resource pools to physical hosts, so that there would be a HA based distribution of PCF VMs across specific hosts. This mapping is enforced with a Turbonomic placement policy, so when Turbonomic is controlling VM placement, we can assure performance while staying compliant with high availability goals while leveraging the efficiency of a shared cluster.
Turbonomic’s analysis will also identify actions that will avoid congestion by recommending Application and Container scaling without requiring you to manage static, single metric thresholds. Additionally, it drives a more efficient environment, understanding exactly how many containers can fit in a VM/Diego Cell, and how to plan for growth, by managing the trade-offs of performance and efficiency.
Figure 6: Turbonomic scaling actions on applications and containers
Turbonomic and Cloud Foundry
As with all Turbonomic integrations, the platform leverages Pivotal Cloud Foundry APIs. Nothing is installed. Turbonomic simply targets what’s in your environment to gather data that’s already being collected. Its analytics use that data to determine the right actions and then through APIs executes those actions. Turbonomic uses Cloud Foundry App Manager to discover applications, containers / droplets, import affinity/anti-affinity rules, and gather monitored data. It uses the PCF Ops Manager API to gather VM Cluster (Diego) details and use this interface to orchestrate Cluster Scale actions using BOSH. Likewise, Turbonomic gathers data about the underlying infrastructure from the hypervisor, such as vCenter, or public cloud IaaS providers, all with remote APIs. The beauty of the Turbonomic data model is that it can stich all this information from multiple sources together for the purpose of accurately determining the specific actions that will assure performance, while maintaining compliance and minimizing cost. When you automate these actions, you achieve self-managing nirvana.