June 2010

You are currently browsing the monthly archive for June 2010.

Some time ago I posted a “how to” article on how to configure FCoE on a Nexus 5000 switch. At that time, I did not put the Nexus 5000 into NPV mode but rather connected it to a Cisco MDS Fibre Channel switch without using NPV. In this entry, I’d like to follow up on that article and show you how to configure NPV on a Nexus 5000.

If you aren’t familiar with NPV (N_Port Virtualization) and how it’s different than NPIV (N_Port ID Virtualization), check out this article titled “Understanding NPIV and NPV”; It should help clear things up. Because NPV makes the Nexus 5000 look like an NPIV-enabled host, one potential use for NPV, as in this case, is when connecting the Nexus 5000 to a non-Cisco Fibre Channel switch. Using NPV helps ease interoperability concerns. In this instance, I’m connecting the Nexus 5000 to a Brocade Fibre Channel switch (actually an EMC Connectrix).

Note that I tested these instructions on a Nexus 5010 using both NX-OS 4.1(3)N2(1) as well as NX-OS 4.2(1)N1(1).

The first step is to enable NPV on the Nexus 5000. As far as I can tell, in order to enable NPV you must first enable FCoE using the feature command:

switch(config)# feature fcoe

This loads various Fibre Channel modules and makes possible other features, including NPV and NPIV. Enabling NPV erases the switch configuration and reboots the switch, so be sure you are connected via a console connection before enabling NPV with the feature command:

switch(config)# feature npv

Immediately after enabling NPV, the Nexus 5000 will reboot (you’re warned and given the option to proceed or cancel). The warning indicates that the switch’s configuration will be removed, but the minimally-configured switches I used in my testing retained their configuration. Granted, I hadn’t performed any Fibre Channel or FCoE configurations yet, so perhaps that’s the configuration to which the warning was referring.

Once NPV is enabled on the switch, you can then configure Fibre Channel uplink ports as NP ports (proxy N_ports); these are also referred to as external interfaces. To configure a Fibre Channel port as an NP port, use these commands:

switch# config t
switch(config)# interface fc slot/port
switch(config-if)# switchport mode np
switch(config-if)# no shut
switch(config-if)# exit
switch(config)# exit

You should then be ready to physically connect to the upstream Fibre Channel switch, which—if you recall correctly from my earlier NPV/NPIV post—needs to be NPIV-enabled. In this particular case, I was uplinking the Nexus 5010 to an EMC-rebranded Brocade switch (a Connectrix DS-300B running Fabric OS 6.1.0). To show whether the port on the Connectrix was enabled for NPIV, I used the portcfgshow command:

rtp-fc-sw-01:admin> portcfgshow port number

Look for the line that says “NPIV Capability”; the value should be reported as “ON”. If the value is not “ON”, you’ll need to use the portcfgnpivport command to enable NPIV on the specified port, like this:

rtp-fc-sw-01:admin> portcfgnpivport port number 1

The “1″ at the end of that command enables NPIV; a “0″ would disable NPIV for that port.

Once NPIV is enabled on the upstream Fibre Channel switch, when you physically connect the configured external interface then the Fibre Channel link should come up. I used the show int fc slot/number command on the Nexus to verify that the port was up; on the Connectrix, I used the portshow port command. In addition, I was also able to see the Nexus switch logged into the Fibre Channel fabric on the Connectrix using the nsshow command.

Once you have Fibre Channel connectivity via the external interfaces, then configuring FCoE to hosts connected to the Nexus follows the same set of instructions laid out in my earlier FCoE how-to article.

From that point on, it’s only a matter of configuring zones (see here for help with zones on a Cisco MDS) and presenting storage. Those are different posts for a different day…

Tags: , , , , , ,

Hiatus

I just wanted to let everyone know I’m taking a blogging hiatus for a while. I don’t know yet how long. I do know that things are busy at work, I have a VMworld session to prepare, there are books to work on, and I have a family to enjoy while there is still time.

After five years of creating content for the site, it has become part of me. As such, I’m sure that I will pick up writing here again soon. For now, though, I’m going to take a break.

I do appreciate everyone who has read and responded to my work anytime over the last five years. I’m glad that I was able to help in some small way.

God bless!

Tags: ,

The Future of NetApp

As I was sitting in London’s Heathrow Airport this morning catching up on RSS feeds before boarding my plane back to the United States, an article headline caught my eye: Why NetApp Must Seek Acquisition.

I can’t tell you how glad I am to see this article published, because it gives me the opportunity to share something I’ve been thinking about for a while, even before I joined EMC. I’m sure that everything I have to say about NetApp will be colored by the fact that I now work for EMC, and—whether I like it or not—all comments about any other storage vendor or technology are immediately suspect. Recent comments to my VPLEX article proved that point; it will take time to re-establish objectivity and prove to my readers that I’m not an EMC shill.

But I digress; back to the article. In the article, the author (“secretcto”) states why he believes that NetApp must seek acquisition in order to survive. The crux of his article is this:

Now lets take a look at the market cap of each of these players. A company’s market cap is a good place start in order to identify which of these companies will have money to invest in tomorrow. I am not saying that ‘cloud’ is the IT of tomorrow, but if it is the direction of tomorrow, then one thing is certain, the folks in that list that have more of the necessary ‘cloud’ pieces (or the money to invest in building out a portfolio of integrated cloud components) will be the most successful competitors.

The author states that NetApp has a few key problems:

  • NetApp only owns one component (storage) of the multiple components (the others being servers, networking, software, and security) necessary to continue to be a key competitor moving forward.
  • NetApp doesn’t own any software that drives customers to its products.
  • NetApp lacks the bankroll to acquire the technologies necessary to build out their portfolio in order to compete with more “full-featured” competitors.
  • NetApp has a history of difficulty integrating their acquisitions. Even if the bankroll was present, there is no indication that additionsl to their portfolio could be successfully integrated into the company.

I would add an additional weakness. Being on the outside—and not only on the outside, but working for a competitor that NetApp fiercely detests—I lack any inside knowledge of what might be going on at NetApp. I know they have a ton of very smart, talented folks over there, and those smart folks have engineered the heck out of their WAFL and snapshot technologies. But the reality is that NetApp is a one-trick pony. Look at their products: every single one is in some way based on the same underlying technologies. Kudos to them for getting as much mileage about of these technologies as they have; that’s a huge testament to the skill of their engineering staff.

However, it appears to me (again, lacking any inside knowledge I could be completely wrong) that they have reached the end of the road. I get the feeling that NetApp has done everything they possibly could do with WAFL and snapshots, and now that they have no more mileage with this pony and no more ponies in the stable, where does that leave them?

Again, I’m sure that everyone will take these comments as me bashing NetApp. My intent here is most definitely not to bash NetApp, but to simply state my observations. I’d love to hear others’ thoughts on the matter; my only request is that you fully disclose your affiliations. Speak up in the comments and let me know what you think! All courteous comments are welcome.

Tags: , , ,

The quite popular GigaOm site recently published an article titled “The VMotion Myth”, in which the author, Alex Benik, debunks the myth of vMotion and the live migration of virtual machines (VMs).

In his article, Benik states that the ability to dynamically move workloads around inside a single data center or between two data centers is, in his words, “far from an operational reality today”. While I’ll grant you that inter-data center vMotion isn’t the norm, vMotion within a data center is very much an operational reality of today. I believe that Benik’s article is based on some incorrect information and incomplete viewpoints, and I’d like to clear things up a bit.

To quote from Benik’s article:

Currently, moving a VM from a one physical machine to another has two important constraints. First, both machines must share the same storage back end, typically a Fibre Channel/iSCSI SAN or network-attached storage. Second, the physical machines must reside in the same VLAN or subnet. This means that inside a single data center, one can only move a VM across a relatively small number of physical machines. Not exactly what the marketing guys would have you believe.

Benik is correct in that shared storage is required in order to use vMotion. The use of shared storage in VMware environments is quite common for this very reason. Note also that shared storage is required in order to leverage other VMware-specific functionality such as VMware High Availability (HA), VMware Distributed Resource Scheduler (DRS), and VMware Fault Tolerance (FT).

On the second point—regarding VLAN requirements—Benik is not entirely correct. You see, by their very nature VMware ESX/ESXi hosts tend to have multiple network interfaces. The majority of these network interfaces, in particular those that carry the traffic to and from VMs, are what are called trunk ports. Trunk ports are special network interfaces that carry multiple VLANs at the same time. Because these network interfaces carry multiple VLANs simultaneously, VMware ESX/ESXi hosts can support VMs on multiple VLANs simultaneously. (For a more exhaustive discussion of VLANs with VMware ESX/ESXi, see this collection of networking articles I’ve written.)

But that’s only part of the picture. It is true that there is one specific type of interface on a VMware ESX/ESXi host that must reside in the same VLAN on all the hosts between which live migration is required. This port is a VMkernel interface that has been enabled for vMotion. Without sharing connectivity between VMkernel interfaces on the same VLAN, vMotion cannot take place. I suppose it is upon this that Benik bases his statement.

However, the requirement that a group of physical systems share a common VLAN on a single interface is hardly a limitation. First, let’s assume that you are using an 8:1 consolidation ratio; this is an extremely conservative ratio considering that most servers have 8 cores (thus resulting in a 1:1 VM-to-core ratio). Still, assuming an 8:1 consolidation ratio and a maximum of 253 VMware ESX/ESXi hosts on a single Class C IP subnet, that’s enough physical systems to drive over 2,000 VMs (2,024 VMs, to be precise). And remember that these 2,024 VMs can be distributed across any number of VLANs themselves because the network interfaces that carry their traffic are capable of supporting multiple VLANs simultaneously. This means that the networking group can continue to use VLANs for breaking up broadcast domains and segmenting traffic, just like they do in the physical world.

Bump the consolidation ratio up to 16:1 (still only 2:1 VM-to-core ratio on an 8 core server) and the number of VMs that can be supported with a single VLAN for vMotion is over 4,000. How is this a limitation again? Somehow I think that we’d need to pay more attention to CPU, RAM, and storage usage before being concerned about the fact that vMotion requires Layer 2 connectivity between hosts. And this isn’t even taking into consideration that organizations might want multiple vMotion domains!

Clearly, the “limitation” that a single interface on each physical host share a common VLAN isn’t a limitation at all. Yes, it is a design consideration to keep in mind. But I would hardly consider it a limitation and I definitely don’t think that it’s preventing customers from using vMotion in their data centers today. No, Mr. Benik, there’s no vMotion myth—only vMotion reality.

Tags: , , , ,

This will be a very quick blog post just to address a growing trend I’ve noticed. It started with the wave of prominent bloggers getting hired by EMC for the vSpecialist team. With the recent VMware vExpert 2010 awards, this trend has gotten even bigger. What is the trend? The trend I’m seeing is people starting blogs just to get attention in the industry.

Of course everyone wants to be noticed in their industry. I understand that. I respect that. I want to be noticed in my industry, too—there’s nothing wrong with that. But I cannot stress strongly enough that if you are starting a blog simply to make some noise in the industry, maybe win an award, or get hired by <Insert Company Name Here>, you are blogging for all the wrong reasons.

If you’re going to blog (or tweet), do it for the right reasons. I mentioned this in my recent chinwag with Mike Laverick. The successful bloggers are the bloggers who blog because of their passion for the topic(s) about which they are blogging. Consider some of the well-known and well-respected bloggers out there:

Why do these guys blog and/or tweet? Well, I’m not privy to their thoughts, but what I get out of their writing is that they are passionate about their topics. That passion comes through in their writing, it infects the readers, and their popularity grows. But I don’t think they started out with the intent of becoming popular or well-known. They started out because there was a topic that they were interested in or knowledgeable about and for which they had a passion.

So if you’re going to start a blog, fine. Do it. It’s fun (hard work, but fun). But be sure to do it for the right reasons.

UPDATE: If, for whatever reason, I didn’t list your name above, it doesn’t mean anything! Those names just jumped out of my head as some of the many virtualization-focused blogs that I follow. In addition, I know the writers of these sites on a more personal basis than the writers of most other sites. There are so many other excellent virtualization sites that I would be remiss to try to list them all. I’ll leave that to Eric Siebert!

Tags: ,

I’ve been promising a post on VPLEX for quite some time now, and now it’s finally here. Having spent some hands-on time with VPLEX this past week, I think I’m finally ready to discuss VPLEX in some detail.

The Basics

First, I need to cover the basics of what VPLEX is as well as what it isn’t. VPLEX is another step in delivering EMC’s vision of Virtual Storage and storage federation. There has been quite a bit of discussion over the difference between storage federation vs. storage virtualization (see here and here for two examples). Personally, like the phrase that Joe Kelly used in a VPLEX post (emphasis mine):

This is the ability to create a consistent view of a volume, independent of its location. This is the core behind Storage Federation.

With this definition in mind, you can see that EMC has already delivered and will be delivering a number of technologies that support storage federation. Take sub-LUN FAST, for example; sub-LUN FAST presents a consistent view of a LUN regardless of the specific storage tier hosting the underlying blocks for that LUN. Blocks can (and will) be migrated automatically between tiers, yet the consistent view of the volume remains unchanged.

VPLEX accomplishes this definition of storage federation through in-band storage virtualization, which I personally think is why so many people are comparing it directly to IBM SVC, HDS USP-V, and NetApp V-Series. Yes, VPLEX does perform storage virtualization—but it’s storage virtualization as part of delivering storage federation.

So, what is VPLEX exactly, then? Using in-band storage virtualization, VPLEX acts as a scale-out cluster delivering both local (within a data center) storage federation and metro (between data centers at synchronous distances) storage federation. A single VPLEX cluster can scale up to four engines; each engine contains two directors. Each director is equipped with loads of RAM (64GB of RAM, if I recall correctly), eight front-end 8Gb Fibre Channel ports, and eight back-end 8Gb Fibre Channel ports. This means a four-engine cluster offers 512GB of cache, 64 front-end 8Gb Fibre Channel ports, and 64 back-end 8Gb Fibre Channel ports. A single VPLEX cluster can support up to 8,000 virtualized LUNs.

VPLEX clusters can be combined into a metro-plex to provide storage federation between two data centers at synchronous data replication distances (less than 100km today). A metro-plex would consist of eight engines (sixteen directors), 1TB of cache, 128 front-end 8Gb Fibre Channel ports, and 128 back-end 8Gb Fibre Channel ports.

In addition to understanding what VPLEX is, it’s also important to understand what VPLEX isn’t. It’s not a replacement for Invista, EMC’s out-of-band storage virtualization solution. It’s not a solution meant only for EMC arrays; VPLEX is also supported for non-EMC arrays, with support for more arrays in the works. And finally, it’s not a VMware-only solution; VPLEX fully supports physical instances of Windows Server, Linux, Solaris, AIX, and other operating systems.

Making it Real: Specifics in the Real World

If I were reading this post, I’d be asking myself right now,”OK, that’s all great and wonderful, but what does it really mean?” I’m glad you asked.

Storage federation as provided by VPLEX means that the storage managed by VPLEX is active, read-writable storage across the entire VPLEX cluster or metro-plex (remember that a metro-plex is a pair of VPLEX clusters separated by synchronous replication distances). This means that if you have a VPLEX Local configuration with 2 engines, all the storage managed by this VPLEX Local cluster is read-writable across the entire cluster. Similarly, if you have a VPLEX Metro configuration with 4 engines (2 in each site), you can have storage that is read-writable in both locations simultaneously.

Consider a traditional storage replication solution: data exists in Site A and the array replicates the data to Site B. While the data is present at both sites, it’s only writable at Site A. Site B is read-only. This is true of every replication solution of which I am aware on the market today. EMC’s own replication products—like SRDF or RecoverPoint—behave this way. Sure, there are workarounds to that limitation, like image access with RecoverPoint. In the end, though, these are workarounds to the underlying replication model. VPLEX breaks that model by allowing you to have writable storage in Site A and Site B at the same time. The same LUN visible in two sites at the same time, writable in both locations.

Just think about that for a moment. You’ll need a clustered file system to take advantage of this underlying storage functionality, but imagine something like Windows Server with Sanbolic’s Melio FS to provide writable Windows LUNs in multiple sites at the same time. Of course, there’s also the VMware use case where VPLEX provides writable access to a VMFS datastore between multiple data centers. Talk about making the hybrid cloud a reality—consider the use of VPLEX Metro between your on-site data center and a vCloud provider’s data center. It would be the ultimate in workload mobility.

And those are just the VPLEX Metro examples. What about VPLEX Local? Ever had to migrate from one storage array to another storage array? Yes, you could use Storage vMotion. Or you could use VPLEX Local and not even have to get the VMware administrators involved—it would all happen under the covers. Think about being able to transparently migrate storage volumes among various arrays within your data center to meet the SLAs of the workload. Need Tier 1 storage? No problem, we’ll use VPLEX Local to transparently migrate you to a VMAX. Don’t need that level of performance or availability any more? No problem, we’ll use VPLEX Local again to transparently migrate to a midrange storage platform.

Want to really freak your brain out? Think about VPLEX with sub-LUN FAST integrated into it…

I have so much more about VPLEX to share, but in the interest of keeping this already long blog post from getting even longer, I’ll wrap it up here. Feel free to share your thoughts or questions about VPLEX in the comments below.

Tags: , , ,

While I was waiting in the airport last night to catch a flight back from Nashua, NH, where I’d been working with VPLEX at the EMC lab facility there, I received confirmation that I had been awarded a VMware vExpert 2010 award. I am humbled and honored by the award. Wow—thank you!

It is a tremendous honor to be included among those that VMware feels have (quoting from the vExpert landing page) “significantly contributed to the community of VMware users over the past year” and who “have gone above and beyond their day jobs to share their technical expertise”. I’m not so sure I’ve met those criteria, but I’m glad that VMware feels I have!

Looking at this year’s group of vExperts, I am truly honored to be included in their midst. There are some very gifted, very talented people who have been given a vExpert award this year. My heartfelt congratulations go to everyone who was bestowed a VMware vExpert award this year, and my sincere thanks and gratitude go to VMware and the VMware community for esteeming me so highly. I will do my best to continue to earn that respect and esteem in the coming year.

Tags: , ,

Storage Short Take #6

Welcome to Storage Short Take #6, the latest installation of my quite irregular collection of storage-related links, posts, and thoughts. You could call this the “EMC World” edition, since most of the items listed here stemmed from announcements that came out of EMC World a few weeks ago.

  • One of the announcements from EMC World was FAST Cache, a new feature that EMC is slated to include in the next version of FLARE. Mark Twomey aka Storagezilla has a good write-up of FAST Cache here. The nice thing about FAST Cache is that you don’t need new hardware to use it—if you already have a CX4-based array and EFDs, you can use FAST Cache when the next version of FLARE gets released. That’s pretty cool.
  • Mark also does a great job of describing the storage pool architecture that is the preferred way of provisioning storage in the future. Read this post on storage pools and this post on storage pool services for more information on new features like block compression (leveraging the EMC RecoverPoint compression engine), thick/thin LUNs, and sub-LUN FAST (Fully Automated Storage Tiering). These posts really help provide an idea of where EMC’s midrange arrays are headed.
  • An EMC Technical Consultant in the Seattle area also published a list of key changes in FLARE 30; it’s worth a look. Also listed are all the existing features in the midrange storage platforms.
  • Chad Sakac also tackled the changes to EMC’s midrange platforms in a pair of posts: first a post on next-generation simplicity (primarily focused around the new Unisphere management interface), then a post on next-generation efficiency. Both articles are good reads—almost all of Chad’s posts are good reads—and worth taking the time to read, understand, and apply. I have to say that Chad’s multi-dimensional discussion of efficiency is an excellent overview of how storage features or functions might help in one area (like capacity efficiency) but not necessarily others (such as performance efficiency). This need to be able to offer efficiencies in multiple dimensions is, in my mind, the reason for a broader product set. In other words, the idea of multi-dimensional efficiency is why one size doesn’t fit all.
  • Here’s a list of the “top ten revelations” from the conference.
  • Moving away from EMC World-related links, here’s a “quick hit” by Joe Kelly on various networking mechanisms for ensuring lossless behavior. It’s a pretty good intro to how some of the different mechanisms work.
  • Interesting discussion going on over at Dan Weiss’ site about a recent instance in which his company (an EMC reseller) was able to retain a customer against a competing NetApp configuration. Go read the post and the comments for full details.
  • The EMC Storage Info site has a “how to” post on performing backups/restores using TimeFinder BCV in Windows.
  • RecoverPoint is one of the technologies into which I’m trying to dig deeper, so I’ve been gathering information from whatever sources I can find. It turns out that the EMC RecoverPoint team has a YouTube channel with some videos. I’m curious to know—is this something you find useful?

As always, I welcome your feedback on this and other posts, so speak up the comments!

Tags: , ,