You don’t want to micromanage the cloud

by ken.henault on 08-26-2010 04:47 PM

I’ve been in some interesting discussions lately about how we design and manage our infrastructures.  There’s one school of thought that wants to build in structure and control at every conceivable point in the infrastructure so that it can be monitored, measured and adjusted.  The other school of thought looks to a design a flexible infrastructure that can support most applications without micromanaging them, we call this the cloud.

 

Structure and control are hallmarks of the old purpose built infrastructures we’ve been building for decades.  In the past this was required because the equipment we’ve had was barely up to the task.  Over the last decade we’ve seen the equipment get ahead of the performance requirements of most applications.  Leveraging this excess capacity so we don’t have to micromanage our infrastructure is the best way to reduce complexity and cost.  There are some applications that still need to be carefully designed, measured and monitored because of their mission critical nature, or stringent performance requirements.  But let’s not add the complexity and cost where it’s not needed.

 

As always these views are my own, and do not necessarily represent the views of HP.

 

Follow me on Twitter.  http://twitter.com/bladeguy

We encourage you to share your comments on this post. Comments are moderated and will be reviewed and posted as promptly as possible during regular business hours.

To ensure your comment is published, please follow our community guidelines.

Comments
by ken.henault on 08-27-2010 02:12 PM

I was asked to provide an example of the micromanagement I believe we need to avoid.  Let me share part of a discussion I had with a colleague on the role of FCFs in an end-to-end FCoE network.  The micromanaging view was that you wanted an FCF in each hop so the SAN administrator can have all the control and visibility they're used to.

 

1)      First, I agree that if you were to place an FCF at each and every hop, then you would not be able to use QCN because by FC-BB-5 FC-BB-_E definitions you would be constructing a multi-hop FC like network (DCB Ethernet to FCoE/FC conversion layer, to FC switch element, to FC/FCoE conversion layer, to DCB Ethernet) with independent DCB networks (links) in between each. Thus, you could not use QCN because QCN is designed to operate on a single DCB network.

 

2)      However, now you are constructing a multi-hop FC network all over again. And how is this supposed to help my persistent end to end congestion problems? This is the same reason that people do not deploy more than one to two hops in their FC networks today. >90% of FC SAN topologies utilize either SAN-island or edge-core designs. A very small fraction use edge-core-edge. Anything more is used to support long distance data replication or disaster recovery networks (i.e. not your primary data path).

 

3)      Why do people avoid multi-hop FC networks? Oh let me count the ways…

  1. because of the persistent end-to-end congestion problems and inability to plan for storage traffic flows
  2. large numbers of switches and switch domain ID consumption complicates SAN management and stability
  3. extremely large zone sets and zone configurations caused by the large size and diameter of the SAN fabric
  4. VSANs don’t help because this is another layer of management which may contain some problems like fabric stability, but add a whole other layer of management complexity on top of the SAN fabric.

4)      In addition, this type of topology forces me to use the old tried and true vendor lock in and “unoperability” that SAN administrators have come to hate. This is my gravest concern.  We seem to be on a path to create the same vendor lock-in for FCoE that exists with Fibre Channel. 

 

5)      The whole premise of FCoE and the spirit of FC-BB-5 was to provide a DCB enabled Ethernet network between E_Nodes (CNAs) and the FCFs such that we could experience the benefits of ubiquitous Ethernet multivendor connectivity with just the last leg being the dusty old FC model with all of its warts. Now you are telling us that the preferred model is to drag all that is bad about FC and spread it clear across my data center…you have got to be kidding, right? 

 

by J Metz(anon) on 08-27-2010 06:18 PM

Ken,

 

I agree with you that micromanagement is rarely a good thing, and while I agree with some of your points, I disagree on others, and am not sure what you mean with at least one of your points.

 

For instance, on 1) you say that placing an FCF on each hop prevents the use of QCN. QCN is an Ethernet enhancement and does not need an FCF to operate. Likewise, as an Ethernet enhancement, FCFs don't need QCN to operate. Either way, QCN and FCFs don't interact with each other (from an Ethernet perspective, QCN is L2 and FCFs operate at L3). See Claudio DeSanti's comment here:  http://bit.ly/9Naabu for a more detailed technical explanation.

 

You raise some good points with 2) and 3). Crossing FC domains (which you do with multiple FCFs) can be a PITA for administration purposes, so obviously there should be a good reason for expanding a FC network (including FCoE) beyond a domain. Joe Onisick has a fantastic review of the decision processes surrounding this: http://bit.ly/bOkRzF

 

Joe also has a really good response, published yesterday, on the difference between "lock-in" and "foothold." I believe he makes some extremely valid points in differentiating between the two.

 

I'm not sure I can agree with your statement 5), though. I'm not sure that the "whole premise... and spirit" was to provide vendor interoperability. As someone who has spent some enlightening moments working with FCoE standards I can tell you from first hand experience that isn't the *first* priority at all. If it was, standards such as PFC would have been accepted *long* ago (it was originally introduced in 2002 and was held up not by technical discussions, but political ones).

 

Nevertheless, I think your points on the dangers of micromanagement are really useful, and I'm glad I read your article.

 

(OB Transparency Disclaimer: I'm a PM for FCoE for Cisco, but my comments and opinions are my own).

 

- J

by ken.henault on 08-28-2010 01:46 PM

J,

 

Thanks for stopping by.  I appreciate you taking the time to comment.  My reply on another thread applies to this discussion as well.  Take a look at:

 

http://h30507.www3.hp.com/t5/Eye-on-Blades-Blog-Trends-in/This-is-not-the-10Gb-network-you-re-lookin...

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.

Find HP in Social Media

Facebook Twitter YouTube SlideShare Flickr
About the Author
  • Cynthia is part of the BCS marketing team. Interested in all things mission-critical and what's next on the horizon.
  • Ken is a cloud Architect in the CloudSystem team. Ken focuses on software, servers, Virtual Connect, networking and server virtualization to enable cloud solutions. Ken also develops white papers and best practices as part of the BladeSystem Readiness Team. You can find him on Twitter as @BladeGuy.
  • Hello! I am on the HP Enterprise Servers, Storage and Networking team, focused on Interactive Web and Social Media Marketing for (ISS) Industry Standard Servers. I will be sharing relevant ISS and HP news & info as it crosses my path.
  • Greetings! I am in the HP Converged Infrastructure team focused on Server, Storage & Networking group at HP and will be sharing news & info as it crosses my path.
  • Network industry experience for more than 20 years - Data Center, Voice over IP, security, remote access, routing, switching and wireless, with companies such as HP, Cisco, Juniper Networks and Novell.
Labels