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 theAdmin