Open your eyes to a new approach to IT infrastructure

It seems to come as a shock to people who are new to Cisco UCS to find that it is not just capable of running vSphere.  A UCS blade can run any Intel workload on all the mainstream OS’s – Windows, Linux, Solaris, vSphere, Oracle, SAP etc.  Each of those workloads will require a different OS and application build, different network connections and different storage connections.  Cisco UCS can apply those different builds to the same blade, or any blade, in the system.  This, at last after years of marketing hype from competitors, provides truly agile infrastructure.  But what do I mean, and how does it work?

This post explains how Cisco UCS offers IT infrastructure a new way of working with stateless computing.  You could manage UCS the way you manage any other compute platform with the minimum of change, just like you can drive a Ferrari the same way you’d drive a pick up truck.  But should you?  No, you shouldn’t, you’d be wasting a fantastic opportunity.  So how does UCS change how you drive your infrastructure?

Update: there will be six follow-on posts to provide practical examples of each of the six UCS features – WOW-A, Unified Fabric, Over-commitment, Service Profile, Virtualized CNA and Stateless Computing.

Let’s start with a brief description of four types of workloads and then explain how they can all run on the same blade type without any human having to reconfigure the compute, network or storage.  Imagine a simple, 48GB blade with one CNA connecting to two redundant Unified Fabrics with no internal disk, but access over the fabric to LAN and SAN.  Cisco UCS Service Profiles reconfigure the blade to access the different OS, network and storage connections with one-click.

  • Oracle RAC database.  Needs four ethernet connections for LAN/clustering and two fibre-channel HBAs to access the shared storage on a SAN.  The OS is installed on a boot LUN on the SAN.  Oracle also works very well on Linux and using NFS, and to enable this (instead of FC) through UCS is a simple configuration change to modify the presented ethernet NICs and the appropriate VLANs.
  • IBM Websphere.  The popular Java middleware / application server platform, this is installed on Linux on a boot LUN on the SAN.  It only requires access to two ethernet NICs.
  • Microsoft Windows 2008.  This OS can run any profiles and workloads, be it SQL Server 2008 or Hyper-V.  In this case it requires a couple of trunked vNICs to access the LAN and it also requires a couple of vNICs for DFS access.
  • VMware vSphere 4.  A number of ethernet connections are required for the VM, vMotion and other Nexus 1000V interfaces.  Additionally, storage can be provided via NFS, iSCSI or FC.  The ESX4 installation is on the FC SAN.

These are just four examples and of course you can run many more workloads than these four.  For a list of certified operating systems and enterprise applications, check out Cisco Unified Computing System at Work.

Here’s a simple illustration of these four workloads and how they can all run on the same simple blade hardware.  UCS provides the virtualization of the compute hardware components, plus network (VLANs) and storage (VSANs).

Cisco UCS Workloads

Four very varied workloads requiring quite different OS and app installs and different connections to the LAN and SAN, but all of these workloads can run on the same blade type – but how?  It can only work because of these six UCS capabilities that I help customers exploit every week:

  1. Wire once and walk away architecture
  2. Unified Fabric
  3. Over-commitment instead of Pipe Carving
  4. Service Profile, Pools, Policies and Templates operational capability
  5. Palo MK81KR Converged Network Adapter component
  6. Stateless Computing

Wire Once and Walk Away (or WOW-A!) is about making the physical configuration simple and handling the complexity in logical configurations instead where it’s easier to manipulate.  Gone are the CD installations of software, banished are the complex plethora of physical cables and port connections for all the different LAN and SAN types. Using network and storage virtualization and logical configurations, you can sit at your warm desk drinking your hot coffee and click and drag to modify the virtual LAN and SAN configurations: no cabling changes required.  Data center visits are virtually eliminated.  Different workload, different virtual architecture, same blade.  Simple.

With Unified Fabric you have a drastically reduced amount of physical connections: instead, you run multiple workloads over the same bit of string and separate them using network and storage virtualization.  On one 10GbE pipe you can run IP, NFS, iSCSI, FC.  Remember those “which protocol is best?” arguments: consign them to the bin, you can now run whatever you want over Ethernet.  Just tell a Service Profile what VLAN or VSAN to present to an OS, with a click of the mouse, and you’re done.  No cabling or network card work required.  Different workload, different network connections, same blade.  Simple.

Over-commitment is about reducing admin headaches and increasing ROI.  Instead of making life difficult for the infrastructure team, UCS does not ask you to Pipe Carve: this is the act of putting artificial limits on a network channel, such as carving up a 10GbE into four 2.5GbE channels.  Instead, any workload sharing the same pipe can in theory use all the bandwidth, but in reality and practice – just as we learned over the years with virtualization – that 10GbE bandwidth is enough for everyone.  In the rare cases where the 10GbE is not enough, there are two things that UCS does out of the box.  First, you can easily add more 10GbE pipes into a port channel and make them available to the workloads without a disruptive change.  Second, the system has Class of Service and Quality of Service “knobs” you can turn to influence who gets what bandwidth WHEN AND ONLY WHEN there is contention.  Don’t Pipe Carve, it’s wasteful.  Different workload, different capacity requirements, same blade.  Simple.

Service Profiles are the classic “simple idea, powerful capability”.  Building on the WOW-A approach, your esteemed and highly paid architects create pools and policies and templates that codify the best practices around compute, LAN and SAN configurations.  This means that managing the day-to-day, BAU lifecycle of a workload is made really, really easy.  A Service Profile pulls the configurations it needs from the pools (e.g. what pWWN can I use for my vHBA?), policies (e.g. if I’m running vSphere, I need to enable Cisco Discovery Protocol on my vNIC), and templates (e.g. what should I call my vNICs, and what trunked VLANs should they access?).  You create one Service Profile per workload (e.g. Oracle RAC node), provision the OS onto a boot LUN on the SAN, tell it what vNICs and vHBAs to present and what behaviour to adopt from the pools, policies and templates – and that’s it.  Different workload, different Service Profile, same blade. Simple.

The Palo MK81KR Converged Network Adapter brings virtualization to the network.  This device virtualizes interfaces so it can present the combination of ethernet NICs and FC HBAs that your workload requires.  Need four vNICs and two vHBAs?  Need 2 vNICS and no vHBAs?  Different workload, different network connections, same blade. Simple.

Stateless Computing is about moving the workload bits (OS install, application install) from a disk local to the compute node (internal disks) to a shared storage area that all compute nodes can access so that any compute node can run that workload.  Today this is done on UCS by installing the workload on a boot LUN on the FC SAN.  The Service Profile tells the blade where to boot from.  Different workload, different boot LUN, same blade.  Simple.

Last thought:  Cisco UCS is not about “is this blade better than that blade?”  It’s about doing infrastructure in a different, more fluid, more agile way.  It’s about increasing ROI and reducing complexity, and therefore reducing OpEx.  It’s about making your infrastructure more productive by running more workloads on the same compute nodes.  Imagine from 8am-8pm you run VDI on vSphere, but 8pm-8am you run batch workloads on Oracle: on the same blade, without operator intervention.  That’s what Cisco UCS is about.