Colin McNamara – CCIE 18233 , VCP, RHCE, GCIH, GEEK

Cisco EMC and VMware announced a joint partnership called the Virtual Computing Environment Coalition (VCE) . The key goal of the VCE is to accelerate customer migration to virtualization and cloud infrastructures. The Virtual Computing Environment will accomplish this in four different ways.

VBlock Infrastructure Packages

VBlock infrastructure packages are pre-configured bundles that are sized to support specific workloads. These packages are available to run both on the customer site, as well as in a hosted (cloud) facility. If you have been listening to anything that has come out of VMware in the past couple years, it has been centered around the unification of private and public clouds. VBlock is a building block of this integrated cloud.

The VBlock infrastructure packages are offered in “bundles”. These bundles are numbered 0-2 at the time of writing.

VBlock 0 is an entry level package supporting 300-800 virtual machines. This is built on Cisco UCS, EMC Celerra Unified Storage, VMware vSphere and the Nexus 1000v.

VBlock 1 is a mid level package supporting 800 – 3000 virtual machines. This is built on Cisco UCS, Cisco MDS, EMC Clarion, VMware vSphere and the Nexus 1000V

Vblock 2 is a high end package supporting 3000 – 6000 virtual machines. This is buit on Cisco UCS, Cisco MDS, EMC Symmetrix V-Max, VMware vSphere and the Nexus 1000V

Integrated Pre-Sales, Service and Support – Fighting the skill silo

The defining factor in the successfully sales and deployment of virtualization infrastructure has been cross platform knowledge and experience. Storage, Network, and Virtualization vendors, as well as partners have struggled to attract and train engineering and sales forces with this cross functional skillset. Partners who have engineering teams with skills that cross these functional areas have seen success even in this down economy. Cisco EMC and VMware are smart enough to recognize this trend and have linked sales teams at the hips in engagements. Nothing makes this more apparent than John Chambers himself addressing Field Sales in the VCE webcast and requiring that these teams coordinate and act as one cohesive unit.

Acadia

Cisco, EMC and VMware have jointly funded a venture called Acadia. This venture, initially staffed at 120 employees is charted with the development and validation of cross platform solutions. They are focused on a “build operate transfer” model for service providers and large enterprise customers. The target date for Acadia’s launch is Q1 2010.

Partner Ecosystem

This was my biggest worry about this release. Does Cisco, VMware and EMC funding Acadia mean that they are going to go direct and bypass their channel? The party line is no, that all three partners will still utilize the channel to sell and distribute the VBlocks. An interesting new twist however is that there is not one master partner certification to sell “validated” VBlock solutions. To participate a partner has to be certified at reasonably high levels with all three partners to have the ability to register and sell deals under the VBlock mantra.

What hasn’t been clearly answered is what happens when a workload is moved to the “cloud”. Does that go through the channel? What if that cloud infrastructure is built onsite but maintained by Acadia? It sounds like we have to wait till January 2010 to get that answer. In the end time will tell whether Cisco will hold true to the success they have found in the channel, or whether Cisco will end up in an MBA case study of what not to do.

Want to learn more ?

Enterprise Strategy Groups write up

Scott Lowe – VCE quick thoughts

Joint Offering Portal – Privatecloud.com

Chad Sakac – an insiders view of VCE

Cisco Press Release on VCE

Cisco’s vision of the unified data center took another step forward today with the announcement of the Nexus 4000 series blade center switches. This switch is another step forward  in Cisco’s view of a true multiprotocol network.

What does this mean?  In Cisco’s view of the world this means supporting the transport of Fibre Channel, Fibre Channel over Ethernet, iSCSI, NFS and CIFS in a scalable and dependable fashion.

What is the Nexus 4000?

The Nexus 4000 is the 5th release of the Nexus line of switches (counting the UCS 6100 as a release).  This switch fits in the blade center form factor. It is intended to be used in the place of the Catalyst 3000 and 3100 series blade switches. It is a full featured Nexus switch, very similar to it’s big brother the Nexus 5000.

What protocols will it support?

In keeping with Cisco’s vision of a Unified IO platform in the data center the Nexus 4000 will support Converged Enhanced Ethernet (CEE) (yes, they finally caved on the naming) as well as providing the same reliable transport of iSCSI, NFS, and CIFS that you get with the Nexus 5000.

What blade centers will it work with?

Cisco is playing close to the chest announcing what blade server vendors will support this product.

My initial gut reaction was that HP would not be supporting this product, however I just saw that HP is OEM’ing the Nexus 5020. It would make sense that they would support the Nexus 4000 in their C Class blade centers, though only time will tell.

IBM however has been very supportive of integrating Cisco technology, as well as OEM’ing the Nexus 5000 switch in their portfolio. I fully expect the Nexus 4000 to be supported in the IBM BladeCenter platform, though again I cannot confirm.

Dell also has resold Cisco blade switches, and although they do not OEM the nexus 5000 they have been large proponents of the Nexus solution and unification of IO workloads throughout their platforms.

Is it the same as a Fabric Extender?

The Nexus 4000 is not a Fabric Extender. What is the difference? A Fabric Extender is a really efficient multiplexer. While using a Fabric Extender the main goal is vast simplification. What you end up with is a dumbed down remote line card that provides simple, fast services to your access layer. This is great for most uses, however there are instances where you need to provide richer services. A full function switch like the Nexus 4000 is appropriate in this case.

What does it run?

The Nexus 4000 runs NX-OS, Cisco’s data center switching operating system. This is the fourth release of what was previously named SAN-OS which ran on Cisco’s MDS line of SAN switches. This operating system is shared between the Nexus 7000, 5000, 4000, 1000v,UCS Fabric Interconnect and MDS line of SAN switches. Now you can have a consistent operating system platform from your data center core, all the way down through your blade switches and into your virtualization layer.

When will it be available?

Just like when the 3000 and 3100 series blade switches got announced, we are going to have to wait on the individual server manufactures to announce support at their own pace. My gut feel says we will be waiting a couple months for units to get out, and for the vendor certification process to complete. Though with business picking back up, this product may get out sooner.

Intellectual capital driving the cloud

It is wise to follow the movements of thought leaders in Silicon Valley. Why is that? Because when enough smart people land at the same company, it is only a matter of time something great happens. This “human network” of intellectual capital has been the seed of many successful tech companies, and will continue to be true in the future.

One of these tech companies with a wealth of intellectual capital is Arista Networks. There are A LOT of ex Cisco folks walking the halls of Arista. Many of them come from the Granite Systems acquisition (Cisco’s 4500 platform). This platform, while designed with line card oversubscription to keep it between the 3560 and 6500 platforms in price and performance has an extremely elegant internal architecture. Case in point, the 4500 platform has had in service software upgrade (ISSU) for over two years, something that the 6500 still struggles with.

Now that this team, and key leaders from Cisco and other tech companies are putting together a network platform, what can they do? And more importantly, what will they do?

Before I dive into that answer, I think it is important to take a quick overview of the two major camps of network platform development, and what the advantages and drawbacks of each method is.

Creating your own ASICS in house

The first way is to create your own ASICS that handle switching and security functions. In this case, you are effectively a chipset manufacturer, who then bundles your own chipsets into routing, switching and security platforms. On one hand, developing your own ASICS can give you a competitive advantage by rolling in features that are not available to your competitors.

On the downside however because of the high cost of developing these chipsets you are forced to design for a very long lifecycle (7+ years). Another downside is that if you have any problems with manufacturing, you cannot just call up another supplier and change your sourcing strategy because you are that supplier. In the case of any Fab issues you are forced to slip your product delivery dates.

Utilizing market silicon

The second way is to utilize routing, switching, and security ASICS that are commercially available through many manufacturers and wrap your own software and chassis integration around them. This is commonly referred to as “market silicon”. In this case, your focus is end to end integration of commodity ASICS and most importanly creating  software differentiation to add value to your product.

The positives aspects of this model is that you are not locked into your own chipset design time lines. If your primary chipset supplier has a Fab issue, then you can easily change your supplier and hit your deployment time lines.

The downsides of this model is that every single networking manufacture in the world has access to the same chipsets. This forces a vendor to differentiate through better software, support, and integration of these “Market Silicon” ASICS into a superior platform.

Who uses what?

With all the talk of Market Silicon being evil, the reality is that the major networking manufacturers use a mix of home grown ASICS and market silicon to drive their products. I can’t say who uses what, but feel free to crack open your switch and take a look at the chipsets on the line cards. Don’t be surprised if you can find some market silicon sprinkled here and there. Now that doesn’t mean that these platforms are bad, it just means that for certain functions it is cheaper to source ASICS externally then to create them in house.

How does Arista approach this problem?

Aristas focus is to create an extensible network operating system that can manage and enable multiple switching ASICS and switching platforms (VMware Virtual Network Distributed Switch – vNDS).

Extensible Operating System (EOS/vEOS)

Arista created a new operating plaform, based on Linux that manages both the physical and virtual implementations of switching devices (ASIC and Virtual Switches). It is called the Extensible Operating System. This operating system has hooks into all the ASICS and vSwitches that it supports. Most importantly it provides one single operating system for all supported platforms both physical and virtual.

sysDB

Core to the functionality of EOS is the sysDB. What is the sysDB? It is a custom real time database written specifically for the interaction of individual system processes. These include routing, switching, security, management processes. By centralizing all of this information in a central location the time to react to events is minimized . This is especially true when compared to classic networking implementations where independent processes keep independent state.

vEOS

Virtual Extensible Operating system is just that – A virtualized instance of the items mentioned above. This can be run inside a vmware virtual machine. It is the same operating system, database, and daemons that run on Arista’s physical hardware. The only difference that it happens to run inside of your virtual infrastructure.

You may ask the question, why would you want to take a network operating system / hardware combination and split it apart?

vEOS and VMware Virtual Distributed Network Switch

EOS and vEOS have implemented a hook into VMware’s vNetwork Distributed Switch (vNDS) API. In effect, you can think of the vNDS as just another ASIC to the operating system. Instead of connected through a device driver, EOS and vEOS connect in through an XML API. This accomplished the function of both retrieving status and performance information that the vNDS provides, and creating policies inside EOS and publishing them into your VMware switching infrastructure.

If you have an Arista switch directly northbound of your ESX servers, you get this monitoring and configuration feature for free. If you don’t have Arista switches, (say you have Cisco, HP, Juniper or Foundary) you can use vEOS (the virtual instance) and pay a fee to get a cli interface into the VDS.

vEOS vs Nexus 1000V

This is a likely to be a highly contested item, complete with competing bumper stickers. In my opinion it isn’t that big of a deal. The reason being is that the 1000v and Arista’s vEOS implementation are completely different. Cisco’s 1000V is a dedicated piece of code running on your ESX servers that handles switching differently then VMware’s vNDS. Arista’s implementation of EOS and vEOS is more of a management interface to VMwares vNDS. vEOS does not replace the switch inside VMware, it configures and monitors it through the vNetwork API.

When comparing the two products head to head, the discussion is really a VMware vNDS vs Nexus 1000v discussion. If you have already decided to move to the 1000V because of the feature differential between the native vNDS then nothing really changes.

This doesn’t mean that vEOS does not add value. In smaller environments where the 1000V is not an option, or in an intercloud situation where state needs to be passed between disparate network instances vEOS’s vNDS implementation can be very valuable. If the vNDS features are all you need, but you would prefer a CLI for your VMware switching and cannot justify the expense for the 1000V licenses, then Arista might be right for you.

Want to learn more?

Arista Networks – Extensible Operating System

Andy Bechtolsheim’s opinion on Market ASICs

VMware Virtual Network Distributed Switch

Cisco Systems – Nexus 1000V