Going ‘Under the Hood’ to get a closer look at the Intersight Workload Optimizer Decision Engine – Blog 1 of 3 in a weekly series where we dig a little deeper into the technology behind the Workload Optimizer service of Intersight.
A little over a year ago, Cisco debuted a new service on the Intersight Platform: Intersight Workload Optimizer (IWO). At its core, IWO is a powerful decision engine that constantly acts to assure workload performance and minimize cost. If you are unfamiliar with IWO, Vishwanath Jakka provided a great overview of its capabilities in this previous blog.
In framing the IT challenge that IWO addresses, he noted that “To optimize an environment end-to-end, you need access to a constant stream of telemetry data from dozens, hundreds, perhaps thousands of sources” and that IWO “… leverages telemetry data from a broad third-party ecosystem across a range of endpoints including hypervisors, compute platforms (including Cisco UCS and Cisco HyperFlex), container platforms, public clouds, applications and more, to deliver intelligent recommendations for where to place and how to size and scale resources.” But how? How is IWO able to ingest all this information in an easy, secure, consistent fashion, regardless of whether the sources of data are in the public cloud or behind the corporate firewall, on-premises?
The answer is the subject of our discussion today: targets. Let’s take a deeper look at Intersight targets and how IWO uses them to collect the data it needs to assure workload performance while simultaneously minimizing cost and maximizing utilization.
What are Intersight targets?
Intersight targets are hardware or software infrastructure components from which Intersight receives information and, in many cases, to which Intersight can send relevant actions. Hardware targets include infrastructure such as servers, Fabric Interconnects (FIs), HyperFlex clusters, network switches, APIC clusters, or other hardware endpoints. Software targets may be hypervisors, Kubernetes clusters, public cloud services, an Intersight Appliance, or other software endpoints. Intersight targets aren’t specific to IWO – for example, a VMWare vCenter target can be used both by IWO and by Intersight Cloud Orchestrator (ICO).
In order to be managed by Intersight, each target must have both of the following:
- A mechanism to securely establish and maintain a logical connection to the Intersight service
- A northbound API for the target to receive commands from Intersight
In the case of public cloud services such as Amazon Web Services, Microsoft Azure, and Cisco AppDynamics, both of the above criteria are easily achieved. These cloud services have well-established public APIs and straightforward, secure mechanisms for invoking them directly from Intersight.
For all other targets, however, the means of establishing a secure, durable communication path poses a significant challenge. These targets invariably reside behind an opaque, non-permeable firewall and security infrastructure designed to prevent exactly the kind of external access required to invoke their powerful APIs. A new connection vehicle is needed.
Device Connector
For targets whose design Cisco has direct control over (such as UCS servers, Fabric Interconnects, and HyperFlex clusters), the on-premises connectivity problem has been solved with a lightweight, robust software module called the Device Connector. The Device Connector code is embedded in supported Cisco hardware at the factory and has one simple job: establish and secure a durable websocket connection to intersight.com, as shown in Figure 2.
When a hardware device with an embedded Device Connector is powered on and connected to the network, the Device Connector will attempt to reach out to intersight.com and make itself available to be claimed by a unique Intersight account. Once claimed, the Device Connector will maintain the secure connection and attempt to re-establish it wherever the connection is severed by a network outage, device reboot, etc.
(Note: Device Connector maintenance is a hands-off operation, and it is self- maintained as part of the Intersight service. When updates to the Device Connector are available, they are published through Intersight, and the Device Connector is automatically upgraded.)
Assist Service
While the hardware-embedded Device Connector is an excellent solution for Cisco devices, the problem of connecting to non-Cisco hardware and software on-premises remains. The solution is to take the same Device Connector logic and, rather than try to coax third parties into embedding it in their targets, make it available through an on-premises virtual appliance as its own function: the Assist Service, sometimes referred to as Intersight Assist.
This Assist Service can both maintain the necessary durable, secure link to Intersight and proxy the target-specific API calls necessary for Intersight management. The Intersight Appliance will receive the necessary functions from Intersight to add and manage any supported targets on-premises, as shown in Figure 3. These functions are delivered as microservices to the appliance and can make API calls to the desired targets.
In this manner, all the benefits of the hardware-embedded Device Connector carry over to managing non-Cisco targets, and Intersight administrators are provided a single, consistent mechanism for claiming and managing targets regardless of where they reside. Additionally, once an Appliance is claimed, there is nothing for an administrator to manage — Intersight will automatically update the Appliance and any needed target functions. As support for new targets are released in Intersight, those capabilities are immediately made available to connected Appliances. Furthermore, multiple Intersight Appliances can be claimed under the same account, enabling administrators to deploy multiple appliances in separate locations as they see fit. This flexibility helps avoid potentially significant issues with providing network connectivity between separate sites and can also help with scalability by sharing the target load across multiple Appliances.
Claiming Targets
On-premises targets
The process for claiming Cisco hardware targets with native device connectors is beyond the scope of this blog but is well covered at http://intersight.com/help/.
As described above, access to on-premises, non-Cisco targets that lack a native Device Connector occurs through the Assist Service within the Intersight Appliance. The general process to claim such targets is to use the wizard via the Admin → Targets → Claim a New Target button (the exact steps for IWO targets are well documented in the Cisco Intersight Workload Optimizer Target Configuration Guide). After selecting the desired target (for example, vCenter) the wizard will request some basic information such as the target’s IP/hostname, and a username/password combination for Intersight to use for communicating with the target, as well as the desired Intersight Appliance through which the claiming process and subsequent target management should occur.
Public cloud SaaS targets
Public cloud SaaS-based targets are perhaps the most straightforward of all targets to add since they do not depend on a Device Connector or even the Assist Service. Essentially Intersight can speak directly to the public cloud services via their public APIs. To add such a target, again navigate to Admin → Targets → Claim a New Target button and launch the Add Target wizard. Choose the desired service, such as Amazon Web Services, and supply the required credentials (e.g., Access Key, Secret Key, etc.). Once claimed, no further manual intervention is required.
It is therefore possible to use Intersight Workload Optimizer as a purely SaaS customer — no Intersight Appliance is needed if all the targeted workloads and infrastructure reside in the public cloud.
Kubernetes targets
While all communication to targets occurs via API calls, without any traditional agents required on the target side, Kubernetes clusters do require a unique setup step: deploying the Kubernetes Collector on a node in the target cluster. The Collector runs with a service account that has a cluster- admin role and contains its Device Connector, essentially proxying communications to and commands from Intersight and the native cluster kubelet or node agent. In that respect, the Collector serves a somewhat analogous role as the Intersight Appliance does for enabling secure Intersight communications with third-party hardware on-premises. We’ll explore the Kubernetes Collector setup and configuration in a future blog.
Wrapping Up
Intersight Workload Optimizer relies on data – metrics, telemetry, etc. – from a vast array of software and hardware endpoints, both on-premises and in the public cloud, to analyze and generate its actions. Intersight targets allow IWO decision engine to gather that information in real-time, and where appropriate, execute actions that assure workload performance while simultaneously optimizing for cost. A combination of Intersight Device Connector, Intersight Assist, and public cloud API compatible technologies enables this powerful capability in a secure, durable, low maintenance fashion.
Look for blog 2 in our series next week!
Note: portions of this blog were excerpted from the book Cisco Intersight: A Handbook for Intelligent Cloud Operations, this frequently updated handbook can be accessed via our Intersight Resources Help Center.
Resources:
Access the Cisco Intersight Handbook via our Help Center
Try Cisco Intersight Workload Optimizer
AWS blog on Intersight Workload Optimizer
Cisco Intersight Workload Optimizer Target Configuration Guide
CONNECT WITH US