« Webcast Sharepoint and VMware Best Practices | Main | Additional EMC NFS Integration with VMware now GA »

March 08, 2010

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Mark

I would add HP C-Class with Fibre Channel Virtual Connect does not support direct attach to storage targets either. A junction device has to operate natively as a Fibre Channel switch to connect directly to an FC or FCoE array.

IP direct attach storage is similar because UCS operates its Ethernet connections in something called End Host Mode, also referred to as End-host Virtualizer and Ethernet Host Virtualizer in some documents. This is essentially an Ethernet version of Cisco NPV mode for Fibre Channel. It supports a static pinning of downlinks to uplinks, and appears to the network as a host, not a switch. Again, this is similar to HP's Ethernet Virtual Connect, and for the same reasons, an HP chassis with VC needs a switching infrastructure between it and another Ethernet host.

Veverything

This is a pretty interesting issue, and something we have debated internally as well.

As you pointed out, this is the number one issue in selling this solution to the entry level market. If the customer does NOT have 10G in their network, and existing SAN switches that can support NPIV, you have to sell a Nexus 5K (or other 10G switch and a seperate fabric switch such as a MDS, many possibilities here) along with it. There is actually another issue besides the NPIV mode which is that the UCS 6100 in addition to only operating in "switched/NPIV" mode on the FC side, does NOT have ANY fabric services (zoning, aliasing, etc). So even if it could operate in "switched mode" like the ethernet side, we would still be SOL on the FC direct connectivity.

The other side of the coin is, should those functions really be placed into the 6100 from an architecture perspective? The UCS concept never really intended for the 6100 to be a "switch". Not to overuse the term, but the 6100s were meant to manage, and serve as fabric interconnects. Meaning, if you buy into the way the system was designed to be used "stateless computing", 6100 fabric interconnects should do nothing more than aggregate unified I/O from the blades and split the I/O and send to more costly Layer 3 enabled / FC services enabled devices where the decisions can be made (routing, zoning, etc). The thought being you keep the "costly" switch ports in the core because there are fewer of them, versus keeping them at the edge where they are really not necessary with a proper design.

Utilizing NPIV GREATLY simplifies integrating a UCS into an existing FC fabric (no messy fabric merges, B2B credits to worry about, etc). There's always pros/cons to everything, but giving customers an option to have FC services/L3 on the 6100 would be great ....choice is always good!

I think the bottom line is that for large environments, the current design makes sense and the "limitations" aren't really "limitations" given how you would design the solution. But it does make it tough to sell 1-2 chassis solutions when there is lots of required parts to go with it beyond just the UCS itself.

/vijay

twitter.com/stevie_chambers

You guys are all on the money. When you've got 64 blades and more behind a pair of fabric interconnects, you really don't want to be overloading them with complex L3 and FC code :-) with a typical 60:1 Guest:Host ratio that's heading towards 4,000 VMs ... a lot of brains are behind UCS and so far if it doesn't do something there's usually a good reason for it...

Veverything

Stevie-- makes perfect sense.

I felt compelled to write a more detailed post delving a little deeper into my feelings on subject along with exploring the "WHY" portion a little more from a design perspective ... http://tiny.cc/U5JEW

direct response

I agree with that, the UCS concept never really intended for the 6100 to be a "switch".

Daniel Ferris

The comments to this entry are closed.

  • BlogWithIntegrity.com

Disclaimer

  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.