Cisco Overcomes Incompatibilities Impeding Datacenter Virtualization

Dave Ward, CTO and chief architect, Cisco

David Ward, CTO & chief architect, service provider division, Cisco Systems

Workflows Operate Seamlessly across VMs, Containers and Bare Metal

By Fred Dawson

August 22, 2017 – Cisco Systems has found a way to orchestrate use of datacenter resources that could provide the flexibility that’s been missing when it comes to getting the most out of virtualization technology.

As described by Dave Ward, Cisco’s CTO and chief architect, the company has created an adaptor layer that frees workflows to work with multiple iterations of virtualization across in-house and external cloud resources. “We can orchestrate across bare metal, containers and VMs (virtual machines) all in the same workflow,” Ward said.

With growing reliance on IP-based software systems running on datacenter rather than purpose-built hardware, producers and distributors of high-value video content know they can save money on infrastructure by using virtualization technology to enable dynamic use of those resources for multiple applications as needs ebb and flow, even to the point of being able to tap public cloud resources for extra capacity on an as-needed basis. Indeed, high-density multi-core processors merging CPU and GPU functionalities have expanded the range and volume of applications that can run on any server blade to the point where failure to implement virtualization amounts to a huge waste of resources.

The problem is, as each major advance in virtualization technology proves more effective at cutting costs and enabling dynamic versatility than the last, it’s hard to commit to implementing any given mode knowing a better one is likely in the pipeline. And when a company does choose to put different generations of virtualization technology into play as better options come along, silos emerge where workflows are locked in to one or another virtualization environment.

Cisco hopes to put such concerns to rest. “We’re working on virtualizing the entire datacenter – storage objects, orchestration optimization, etc. for ultimate results,” Ward said. But, of course, being virtualization, it’s always a work in progress, which, in this case, involves deep engagement on the part of a growing list of partners who are making it possible to interface their workflows and specific solutions with the adaptor layer developed by Cisco.

“You need partnerships to get over these hurdles,” he said. “There are a lot of end points and capture devices, and we have to be able to do the entire feature set and take assigned tasks across the entire datacenter infrastructure. We’re working as fast as we can to enable ecosystems around us.”

The emphasis is on enabling optimum use of facilities rather than competing at the workflow level, he added. “We’re the infrastructure company, not the orchestration company,” he said, citing a recently consummated partnership with broadcast production supplier Evertz as a case in point. “Combining our control layer with their orchestration layer is big news for broadcasters, because it puts workflow management in possession of the entire datacenter.”

Such fluidity not only bridges facilities that have been provisioned with different approaches to virtualizing hardware resources over time. Equally important, it frees users to choose the best compute environment for each application in any given workflow. While there is a lot of “religion” in IT circles where debates over the benefits of one approach over another can get intense, the truth is the optimum environment is one where users have complete flexibility of choice.

“We don’t want to let technology barriers or religion get in the way of making the best use of datacenter infrastructure,” Ward said. “We’re making it possible to get past these issues with a solution that ensures absolute frame accuracy across all A/V feeds with high tolerance and availability.”

The Need for Multiple Options

Right now there’s a lot of momentum behind virtualization based on container technology as the successor to virtualization based on VMs running on hypervisors. Hypervisor-based virtualization is a multi-layered technology. Hypervisors, relying on a host multi-server OS like OpenStack to interact with the bare-metal server OSs, enable VMs to operate like independent servers with their own OSs and middleware.

With container technology a server runs an OS that creates semi-autonomous software modules (containers) to load applications directly onto bare metal. Containers use less computing for a given task and are more easily scaled.

In some cases container technology is not only seen as a better option; it’s seen as the only practical option for virtualizing use of resources for certain applications. In those situations performance degradation resulting from the additional processing overhead required with use of hypervisors simply cannot be tolerated.

More generally, there’s much excitement over container technology and its support for microservices. A specific functionality performed by a containerized microservice can be applied across multiple applications, greatly adding to the overall efficiency.

But there are instances where reliance on VMs with hypervisors is the better choice. For example, there may be situations where there’s a need for a wide choice of OSs to ensure that a given application in the workflow benefits from the latest and greatest innovations flowing out of different OS environments.

VMs run independently of each other on shared commodity hardware and so can be optimized to use whatever OS is best for their assigned application, whereas containers are designed as incremental instances of a specific OS. A cluster of Linux-based containers will only work for applications that run on Linux, or one consisting of Windows-based containers will only work for applications running on Windows.

Moreover, VM technology is more mature, which means some users will prefer to wait awhile before implementing containers, and, when they do, they may want to do so for some applications while leaving others to run in VMs. And there are some situations where it’s better to run an application on a server dedicated to that application, i.e., the bare-metal option, rather than in a virtualized environment.

One case in point where bare metal is the widely preferred option involves use of Apache Hadoop, which, rather than using proprietary computer systems to process and store data, provides an open-sourced means of clustering commodity hardware to enable analysis of massive data sets in parallel. Hadoop has major implications for the media and entertainment space where aggregations of vast data sets flowing in from multiple sources are being used for diagnostics, advanced discovery, personalization, addressable advertising and much else. As an I/O-intensive application focused on reading and writing to storage, Hadoop is sensitive to any performance degradations caused by accessing disks through a virtualized layer.

A New Approach to Using Virtualization

For all these reasons and many more, the emergence of an adaptor layer that allows a given workflow to operate across a mix of virtualization and non-virtualization modes whether in private or public cloud environments or in hybrid combinations of both could represent an important breakthrough in service providers’ and broadcasters’ progression to virtualization.

“The industry needs an infrastructure orchestration framework that can tune to support whatever the workflow requires without pre-planning,” Ward said.

At NAB in April Cisco demonstrated the implications of this capability with seamless operation of production workflows across three cloud environments in its booth. One of those clouds was physically supported by servers in the booth of broadcast production systems supplier Blackmagic Design, which was connected to Cisco’s booth by a dedicated fiber link to underscore the ability to work across dispersed resources.

This and cloud-hosted solutions of other vendors tied to the demo highlighted the ability to leverage virtualization as the broadcast industry is transitioning from traditional hardware-based solutions to an all-IP environment utilizing COTS (commodity off-the-shelf) facilities. A key factor in smoothing the process has been agreement on adoption of multiple protocols under the SMPTE 2110 umbrella.

These include SMPTE 2206, through which payloads utilizing SDI (Serial Digital Interface), the traditional mode of connectivity in the production workflow, are bridged to IP devices over RTP (Real-time Transport Protocol) streams. Cisco demonstrated how its platform brings SMPTE 2206 feeds into the virtualization process, ensuring that virtualization can proceed wherever COTS facilities are in use while allowing legacy cameras and other traditional elements of the production workflow to remain in operation.

“With SDN (software-defined networking) we can bring age-old job routing with cameras and other equipment into the datacenter workflow,” Ward said. Using high-speed switches under SDN controller management “we can automate topologies; for example, how customers connect their cameras to the network,” he added.

Another aspect to the tight compatibility between production workflows utilizing the SMPTE 2110 portfolio and the Cisco adaptor layer has to do with the all-important timing mechanisms embodied in the TR-03 protocol, which includes Precision Timing Protocol (PTP) and IEEE 1588, to ensure frame-by-frame synchronization of all streams comprising each piece of content. “Synchronization through PTP and1588 is built into our controllers,” Ward said, noting that such capabilities have been invaluable for virtualizing datacenters used in lightning fast financial transaction environments.

“Synching up stream, load management, workflow management – the financial industry has a great need for all these things,” he said. “In all cases, it comes down to how you time the orchestration of systems and fully account for all variables.”

The Proof-of-Concept

The impact such capabilities can have in a traditional TV production environment became clear during the Cisco demo. Each application in the workflow made optimum use of whatever resources were available so that, from the dashboard view of a production manager, everything was running just as it would in a single cloud tied to a single mode of facilities utilization, whether virtual or bare metal.

The bare-metal component of the demo datacenter was run in “metal-as-a-service” mode, which creates an elastic cloud-like environment by treating physical servers like VM instances in the cloud. VMs were set up to run three types of jobs tapping either the bare-metal approach or hypervisor-based virtualization as needs arose. The container environment utilized the scaling capabilities of Kubernetes, the open source technology that has made massive scaling possible by treating multiple servers as a single unit providing capacity to the clustered containers.

The live workflow compositor fed screens with the same views of any application in the workflow in both booth locations. Jobs could be programmed to run in whatever environment was most optimal with prioritization of resource allocations suited to each.

For example, a transcoding job could be assigned to the container segment of the virtualized server arrays where chunks of content were shunted off to individual containers for processing in parallel, reducing what might be a two-and-a-half hour process on dedicated servers to 11 seconds, with everything stitched into a single stream and verified for accuracy. Maximum efficiency was achieved with 100 percent dedication of the available container CPU capacity.

Alternatively, if the overall efficiency of execution in the workflow were to require only partial dedication of container capacity to transcoding, the system could be set to allocate capacity necessary to perform the transcoding job in whatever time frame was optimal in the context of execution of other elements in the workflow – say, five minutes instead of 11 seconds, said Andre Surcouf, distinguished engineer in Cisco’s Chief Technology and Architecture Office.

Such optimization, extending to any combination of applications running in any combination of virtual and non-virtual environments, can be arranged automatically, he added. “This is the efficient play,” he said. “You can run a separate optimization algorithm to pack all you can into the datacenter.”

With two bidirectional pipelines available into the VM-hypervisor and container virtualization environments the system was able to run the same application in both to meet high availability prioritization requirements with no disruption in execution. For example, one job running with the demonstrated workflow required use of the two virtualization pipelines to tile and upscale a video feed to UDI (Universal Display Interface) for insertion of logos in sync with the schedule set for the overall workload in a live production.

Similarly, users can set a second job while the first is running and use CPU as it comes available, all with the appropriate parameters set for each, Surcouf said. In the case of less time-sensitive transcoding jobs, the system can be set to execute them as capacity is freed up with completion of other tasks in the workflow, he added.

Surcouf also showed how, in the event of failure or under performance in one virtual environment, the system performs frame accurate switching of the processing into the other environment, subsequently switching the flow back into the first when the problem is solved with no phase jitter or other disruption. “When we do transcoding, we can take a large file and destroy the processing on one computer and pick it up on another with no interruption in the flow,” he said. “It’s about being able to efficiently use the notion of primary jobs and back-up jobs running hot as close to 100 percent as possible.”

Bringing Hyperconverged Infrastructure into the Workflow

A major development in datacenter efficiency that workflows will need to interact with is hyperconverged infrastructure (HCI), which can support VM or container approaches to virtualization but at a much more granular level than is possible with legacy infrastructure or converged systems. Unlike these other architectures, storage in HCI solutions is integrated with the computing and networking components within each module or node, typically consuming just one RU of datacenter space. Storage is tiered within each module to provide RAM, solid state and hard disk drive support as needed.

Each module is configured with proportionate allocations of compute and storage capacity as dictated by immediate needs, and users can make adjustments to those allocations as new modules are added to the cluster. Managers accessing the platform through a single user interface can set policies for each application dictating how much of the computing resources it requires and what data components will be instantly available on RAM, positioned for fast-cache access in Flash or offloaded to the FAS (Fabric Attached Storage) or SATA (Serial Advanced Technology Attachment) components of the storage stack.

“It’s a great advantage to have the compute network and storage integrated together with the ability to extend full orchestration across the virtualization and other facilities technology choices,” Ward said. But media and entertainment needs pose challenges related to the size of video file objects in the HCI environment, he added.

“Because video objects are so large, you have to optimize around moving files to where there’s enough CPU available,” he explained. “We’re working to optimize our engine for these workloads so that the principles of hyperconvergence become specific for media.”

And so it goes in the never-ending task of ensuring the datacenter adaptor layer can bring the workflows into whatever comes next. “We’ll find a way to support whatever comes along,” Ward said.