ToL

You are currently browsing articles tagged ToL.

Thinking Out Loud: What is multi-hop FCoE?

Wednesday, April 21, 2010 in Networking by slowe | 10 comments

It’s been a while since I last posted a “Thinking Out Loud” post, but a Twitter discussion this morning prompted me to post this one. Last night, I posted a question to Brad Hedlund (@bradhedlund on Twitter and a great data center networking resource) regarding the Nexus 2232PP fabric extender. My tweet to Brad was this: does the Nexus 2232PP make “multi-hop FCoE” possible via NIV?

(If you haven’t already read my post on the relationship between FCoE and NIV, go read it now as it provides a good background and context for this discussion.)

Brad responded, confirming my assessment and stating that FIP snooping wasn’t necessary. I wasn’t sure about the FIP snooping part but after seeing the response I now understand. In any event, a number of others starting questioning my use of “multi-hop FCoE” in conjunction with the 2232PP fabric extender, stating that it wasn’t a hop because ti does not actually switch any traffic.

Strictly speaking, all of these individuals are absolutely correct; for more information, go read this post on NIV. In this case, the Nexus 5000 is the interface virtualization (IV)-capable bridge and the Nexus 2232PP is the interface virtualizer (IV). The IV doesn’t switch any traffic; all switching occurs on the IV-capable bridge. Therefore, from a switching perspective, a Nexus 5000 and any or all associated fabric extenders are a single hop.

My response is this: what is multi-hop, anyway? Is it the presence of multiple switches in a data path between an initiator and a target? Or is it the presence of multiple physical devices, chained together, between an initiator and a target? In the first definition, using a fabric extender isn’t multi-hop; in the second definition, it is. More to the point, should a customer really care which definition is correct? Why is multi-hop FCoE important, anyway? I would say the answer to that question is scalability. Customers want to be able to scale the FCoE fabrics larger than they can today. Multi-hop FCoE—however you want to define it—makes that possible. So does it really matter how we get there? Besides which point, using the fabric extender approach means only a single point of management instead of multiple points of management. Isn’t that better?

What do you think? Do your own “thinking out loud” in the comments below.

Tags: , , , ,

Thinking Out Loud: It’s Not Just the Technology

Tuesday, January 19, 2010 in Collaboration, Virtualization by slowe | 11 comments

I had a quick thought this morning while browsing this post by Lori MacVittie. She, in turn, was referring back to a post published on VMBlog.com about a virtualization prediction that 2010 would be the year that the network becomes fluid and virtual. (As a side note, the original article on VMBlog.com appears to be primarily a marketing exercise for a company that purports to help make the network fluid and virtual.)

Lori’s post, titled “A Fluid Network is the Result of Collaboration Not Virtualization,” clearly disagrees with the original VMBlog.com post and states that there’s more to creating a fluid network than just virtualization:

The network will become fluid—I absolutely agree—but that metamorphosis will not [happen] solely because of virtualization.

At first, I thought the post was about how organizations needed more than just technology to create an efficient, fluid, dynamic infrastructure; the title says “Collaboration Not Virtualization.” And it is—sort of. Really, Lori is focusing on the “collaboration of infrastructure through integration based on standards-based control planes.”

OK, I’ll agree with her that integration of infrastructure is required to bring about the fluidity that is the “Holy Grail” of data centers. But here’s my thought: what about the human factor? What about operations? What about processes and procedures? I’ve seen so many companies virtualize their infrastructure and fail to see the huge benefits they thought they would reap. Why? Because it was “status quo”: keep doing the backups the way you’ve always done it, keep patching the machines the way you’ve always done it, keep managing the OS instances—yes, you guessed it—the way you’ve always done it. Sure, virtualization is great in that you can keep these processes and procedures the same during and after consolidation through virtualization. But in my opinion, organizations will see a much larger impact if they pay close attention to the processes and procedures. By optimizing their processes and procedures for virtualization, organizations can take advantage of all that virtualization has to offer.

So what do you think? Do organizations really need to optimize their operations for virtualization? I’d love to hear your thoughts, so sound off in the comments. Thanks!

Tags: , ,

Thinking Out Loud: Is VMware Legitimizing the Competition?

Monday, November 16, 2009 in Microsoft, Virtualization by slowe | 14 comments

I was reading a completely unrelated post on Alessandro’s site this morning about how VKernel is reacting to VMware’s release of CapacityIQ when a thought occurred to me: is VMware legitimizing the competition?

Here’s the excerpt from Alessandro’s post that started me thinking:

And of course VKernel now is also in hurry to clarify that support for Microsoft Hyper-V and Citrix XenServer is coming.

Now, let me ask you this question: what is one of the largest complaints about products like Microsoft Hyper-V and Citrix XenServer? It’s the size of the partner ecosystem. Customers are a bit more hesitant to deploy these other solutions in part because there aren’t as many partner solutions out there to complement the virtualization solutions.

So, as VMware expands into new markets like capacity management and monitoring, backups, etc., former VMware-only partners are forced to adapt their products to work with Hyper-V and XenServer in order to protect themselves. This causes the size of the partner ecosystem for VMware’s competitors to grow, eliminating that complaint and removing one of VMware’s competitive advantages. In effect, VMware’s own actions are building out the partner ecosystem for their competitors and thus legitimizing the competition.

Am I crazy? Am I wrong? What is a company like VMware to do, if anything? I’d love to hear your thoughts.

UPDATE: Some readers have pointed out, rightfully so, that “legitimizing” isn’t really the best word to use here. Perhaps “assisting” or “helping” is a better word?

Tags: , , , , , , ,

Thinking Out Loud: HP Flex-10 Design Considerations

Friday, August 28, 2009 in Networking, Virtualization by slowe | 10 comments

Along with a number of other projects recently, I’ve also been spending time working with HP Virtual Connect Flex-10. You may have seen these (relatively) recent Flex-10 articles:

Using VMware ESX Virtual Switch Tagging with HP Virtual Connect
Using Multiple VLANs with HP Virtual Connect Flex-10
Follow-Up About Multiple VLANs, Virtual Connect, and Flex-10

As I began to work up some documentation for internal use at my employer, I asked myself this question: what are the design considerations for how an architect should configure Flex-10?

Think about it for a moment. In a “traditional” VMware environment, architects will place port groups onto vSwitches (or dvPort groups onto dvSwitches) based on criteria like physical network segregation, number of uplinks, VLAN support, etc. In a Flex-10 environment, those design criteria begin to change:

  • The number of uplinks doesn’t matter anymore, because bandwidth is controlled in the Flex-10 configuration. You want 1.5Gbps for VMotion? Fine, no problem. You want 500Mbps for the Service Console? Fine, no problem. You want 8Gbps for IP-based storage traffic? Fine, no problem. As long as it all adds up to 10Gbps, architects can subdivide the bandwidth however they desire. So the number of uplinks, from a bandwidth perspective, is no longer applicable.
  • Physical network segregation is a non-issue, because all the FlexNICs share the same LOM and will (as far as I know) all share the same uplinks. (In other words, I don’t think that LOM1:a can use one uplink while LOM1:b uses a different uplink.) You’ll physically distinct NICs in order to handle physically segregated networks. Of course, physically segregated networks will present a bit of challenge for blade environments anyway, but that’s beside the point.
  • VLAN support is a bit different, too, because of the fact that you can’t map overlapping VLANs to FlexNICs on the same LOM. In addition, because of the way VLANs work within a Virtual Connect environment, I don’t see VLANs being an applicable design consideration anyway; there’s too much flexibility in how VLANs are presented to servers for that to drive how networking should be set up.

So what are the design considerations for Flex-10 in VMware environments, then? What would drive an architect to specify multiple FlexNICs per LOM instead of just lumping everything together in a single 10Gbps pipe? Is bandwidth the only real consideration? I’d love to hear what others think. Let me hear your thoughts in the comments—thanks!

Tags: , , , ,

Thinking Out Loud: Why Deploy FCoE?

Tuesday, June 30, 2009 in Networking, Storage by slowe | 31 comments

This is another one of my “thinking out loud” posts. This time, the question I’m mulling is this one: why deploy FCoE?

I haven’t hid the fact that I’m not really a fan of FCoE (see here or here), but I was starting to warm to the technology and thought that I was beginning to see some benefits to deploying FCoE. Namely, the fact that FCoE is inherently very compatible with “traditional” FCP, allowing organizations to leverage their existing FCP installation while transitioning to FCoE. Some hands-on time I’d recently spent with a Cisco Nexus 5000 switch showed me just how closely aligned the two technologies are and how (relatively) easy it was to extend an FC fabric using FCoE. OK, I think I get this.

Then, a few days ago, I read this article on FCoE divergence. Given that The Register can sometimes be quite sensationalist (and that’s putting it mildly), I contacted a colleague of mine whose input and knowledge I trust. He informed me that FCoE was currently limited in that FCoE is not multi-hop enabled—meaning, you can’t connect FCoE initiators on one switch to FCoE targets on another switch. (Apparently, this shortcoming is due to be corrected shortly.)

Whoa! That’s a limitation of which I was not aware. And with that limitation in mind, knowing that FCoE will—for the time being at least—be limited to convergence at the edge, I have to ask: why deploy FCoE at all? What real and specific benefits does an organization seek to gain by deploying FCoE as opposed to just deploying FC? Is the edge convergence really that worthwhile and valuable?

Tags: , , , ,