There's so much, and so little, in Cisco's announcement of its “unified computing” strategy that it's hard to know where to start.
However, regardless of what's eventually delivered, it's a very important strategy, so it's well worth understanding what's going on.
The importance of the strategy can be seen in two ways: either because it really does change the data centre, or because it works well as a blocking maneuver to stall the big names of blade servers – the HPs, Dells and IBMs of the world.
So what's in the announcement?
The Cisco Unified Computing Architecture comprises both hardware and software components.
On the hardware side, there are:
- Network adapters – These will be offered in three flavours, but details are scant apart from the obvious, that they will support 10 Gbps Ethernet and can be replaced when new flavours of Ethernet arrive.
- Blade servers – Will be based on Intel's upcoming Xeon Nehalem processors. They will be offered in two sizes sitting horizontally in the blade server chassis.
- The blade server chassis – Like all blade server chassis, it will provide power and connectivity to all the blades it houses.
- A “fabric interconnect” – The switching fabric at the centre of the system, comprising low-latency 10 Gbps Ethernet and Fibre Channel over Ethernet switches handling I/O in the system.
- A “fabric extender” – The extender provides up to four 10 Gbps connections from the blade servers to the fabric interconnect.
This is topped off with software from VMWare and BMC and an embedded manager from Cisco, and services from Accenture (which might give you a hint that Cisco's target is, at this stage, strictly the kind of enterprise that can afford to buy services from Accenture).
In the Beginning
OK, so what was all that about?
Actually, Cisco is entering a market that grew not from the server business, but from a failed market of the mid-1990s. At that time, while Cisco itself was strictly a vendor of routers, a number of LAN switch vendors tried to put the server platform and LAN switch together in a single chassis.
There were various reasons that the first attempts at this sort of integration failed: the server platforms of the day needed too much real estate in the chassis, for example. Another reason was that switch vendors found themselves unable to devote the necessary resources to PC platform development to keep up with the performance offered by PC specialists.
But most importantly, users had already become accustomed to fierce competition between Intel-based platform vendors. They were unwilling to commit to a single server vendor, sacrificing price competition as well as development speed.
The seeds of this idea, in other words, were planted in the 1990s, but have only begun to take root in light of the long, slow march of the blade server market.
Blade servers started as a means to consolidate physical assets: it's more efficient to run more devices from fewer power supplies; it's easier to share storage between servers if the severs and their storage are communicating over a single bus; and servers take up less space if they're all in a single rackable unit.
The next step, and one which has been pursued over recent years by a host of vendors, has been in making the management of blades smarter. This allows tricks like:
- Load-sharing – Improving application performance by spreading processing across several platforms;
- Virtualisation – Starting and stopping multiple instances of operating systems to better utilise the server platform.
Blade servers – including Cisco's announcement – still don't return to the old idea of an environment in which the switch and servers are integrated. There's no longer any need, as we'll discuss later.
Getting this to hang together depends on the management environment. Here, Cisco faces a considerable integration task. Its own long development managing the world of communications needs to be complemented with tools and techniques to manage the server environments.
Here's where the two highest-profile partners in the Cisco Unified Computing System come in – BMC Software, and VMWare.
BMC Software's contributions are through its BladeLogic service automation environment and its Atrium Configuration Management Database. These have been integrated into the Cisco UCS Manager.
The BladeLogic environment is, itself, a broad-based management environment covering operations, application releases, configuration automation, and Atrium, a process automation manager for IT administrators.
The aim, according to BMC, is to automate actions such as provisioning and configuration of both applications and their underlying resources through a single management console.
Virtualisation comes from the agreement with VMWare; its software will be the centerpiece of Cisco's blades' ability to support multiple virtual machines. VMWare says each Cisco UCS will “be able to support thousands of virtual machines”.
VMWare also stated that its V-Link will help provide “granular network visibility at the virtual machine level”. In other words, VN-Link will allow different virtual machines in the Cisco blades to be presented to the outside network as if each were a discrete machine.
Finally, the Cisco UCS will integrate VMWare's vCenter management products, for managing virtual network policies and resources.
There's no longer any need to try and integrate all of this with a LAN switch, however, because the biggest bottleneck of the 1990s is no longer a problem. When Ethernet was just reaching from 10 Mbps to 100 Mbps, the thin pipe that connected servers to the network as a whole was a serious problem. Putting the servers inside the switch meant the two environments could share a single backplane, and in those days, backplane speeds were much faster than LAN speeds.
Now, with 10 Gbps links, the blade platform and the network switch have plenty of room to communicate with each other.
Cisco's most immediate problem is that of avoiding the “blade” label. It wants to do this partly because some of the occupants of the blade market are long-time Cisco partners (such as Dell and HP).
But blade is what the Cisco UCS is all about, albeit with Cisco brains at the top of the communications application environment.
And that raises another problem: does Cisco have the credibility in this market to take on the heavyweights who not only launched the segment, but have several years head-start over Cisco in development?
The centerpiece of any blade computing environment is an Intel-based platform. It may be a higher-powered platform than is offered to mere mortals; it may have extra communications smarts to support the load-share and virtualisation functions that people expect from blade environments. It may have more memory, faster processing, and the ability to access bigger drives. But it remains an Intel-based server.
However, while analysts have been quick to dismiss Cisco's credentials in this market, there is something to consider.
At its inception, Cisco positioned itself as doing something nobody had done before: creating a specialist device out of general-purpose hardware. Before Cisco, routing was performed by the computers that were connected to the Internet; the host that terminated links from other computers also routed packets. Cisco saw an opportunity to dedicate more mundane machinery to the task.
So against the nay-sayers, it must be said that Cisco does have experience in working with general-purpose server platforms to run its software – and it has experience in building its chosen hardware into very high-powered systems.
It may have trouble convincing customers to either replace existing blade environments, or add another vendor into whatever their existing blade environments might be; but only time will tell whether that alone is enough to keep customers from deploying the Cisco UCS in greenfields environments.
Paradoxically, success from Cisco may be enough to change the blade server market in an unexpected way.
There is, at the moment, insufficient openness in the blade market. Vendors have paid lip service to open specifications, but they rely on proprietary and incompatible system components (such as backplanes) to lock customers up as far as possible.
Should the market see an overwhelming threat from Cisco, it's feasible that they might return to the standards bodies and get some movement on otherwise-stalled specifications.