VPLEX

You are currently browsing articles tagged VPLEX.

Technology Short Take #15

Monday, October 3, 2011 in Networking, Storage, Virtualization by slowe | 4 comments

Welcome to Technology Short Take #15, the latest in my irregular series of posts on various articles and links on networking, servers, storage, and virtualization—everything a growing data center engineer needs!

Networking

My thoughts this time around are pretty heavily focused on VXLAN, which continues to get lots of attention. I talked about posting a dissection of VXLAN, but I have failed miserably; fortunately, other people smarter than me have stepped up to the plate. Here are a few VXLAN-related posts and articles I’ve found over the last couple of weeks:

  • There is a three-part series over at Coding Relic that does a great job of explaining VXLAN, the components of VXLAN, and how it works. Here are the links to the series: part 1, part 2, and part 3. One note of clarification: in part 3 of the series, Denny talks about a VTEP gateway. Right now, the VTEP gateway is the server itself; anytime a packet on a VXLAN-enabled network leaves the physical server to go to a different physical server, it will be VXLAN-encapsulated. It won’t be decapsulated until it hits the destination VTEP (the ESXi server hosting the destination VM). If (when?) VXLAN awareness hits physical switches, then the possibility of a VTEP gateway existing outside the server exists. Personally, it kind of makes sense—to me, at least—to build VTEP gateway functionality into vShield Edge.
  • Some people aren’t quite so enamored with VXLAN; one such individual is Greg Ferro. I respect Greg a great deal, so it was interesting to me to read his article on why VXLAN is “full of fail”. Some of his comments are only slightly related to VXLAN (the rant over IEEE vs. IETF, for example), but Greg’s comment about VMware building a new standard instead of “leveraging the value of networking infrastructure” echoes some of my own thoughts. I understand that VXLAN accomplishes things that existing standards apparently do not, but was a new standard really necessary?
  • Omar Sultan of Cisco took the time to compile some questions and answers about VXLAN. One thing that is made more clear—for me, at least—in Omar’s post is the fact that VXLAN doesn’t address connectivity to the vApps from the “outside” world. While VXLAN provides a logical isolated network segment that can span multiple Layer 3 networks and allow applications to communicate with each other, VXLAN doesn’t address the Layer 3 addressing that must exist outside the VXLAN tunnel. In fact, in my discussions with some of the IETF draft authors at VMworld, they indicated that VXLAN would require a NAT device or a DNS update in order to address changes in externally-accessible applications. This, by the way, is why you’ll still need technologies like OTV and LISP (or their equivalents); see this post for more information on how VXLAN, OTV, and LISP are complementary. If I’m wrong, please feel free to correct me.
  • In case you’re still unclear about the key problem that VXLAN attempts to address, this quote from Ivan Pepelnjak might help (the full article is here):

    VXLAN tries to solve a very specific IaaS infrastructure problem: replace VLANs with something that might scale better. In a massive multi-tenant data center having thousands of customers, each one asking for multiple isolated IP subnets, you quickly run out of VLANs.

  • Finally, you might find this PDF helpful. Ignore the first 13 slides or so; they’re marketing fluff, to be honest. However, the remainder of the slides have some useful information on VXLAN and how it’s expected to be implemented.

Servers

I didn’t really stumble across anything strictly server hardware-related; either I’m just not plugged into the right resources (anyone want to make some recommendations?) or it was just a quiet period. I’ll assume it was the former.

Storage

Virtualization

  • Did you see this post about new network simulation functionality in VMware Workstation 8?
  • Here’s a good walk-through on setting up vMotion across multiple network interfaces.
  • VMware vSphere Design co-author Maish Saidel-Keesing has a post here on how to approximate the functionality of netstat on ESXi.
  • William Lam has a “how to” on installing the VMware VSA with running VMs.
  • Fellow vSpecialist Andre Leibovici did a write-up on a proof of concept that the vSpecialists did for a customer involving Vblock, VPLEX, and VDI. This was a pretty cool use case, in my opinion, and worth having a look if you need to design a highly available environment.
  • Thinking about playing with vShield 5? That’s a good idea, but check here to learn from the mistakes of others first. You’ll thank me later.
  • The question of defragmenting guest OS disks has come up again and again; here’s the latest take from Cormac Hogan of VMware. He makes some great points, but I suspect that this question is still far from settled.

It’s time to wrap up now; I hope that you found something useful. As always, thanks for reading! Feel free to share your views or thoughts in the comments below.

Tags: , , , , , , , , ,

Stretched Clusters, Distance vMotion and L2 Adjacency

Thursday, May 12, 2011 in Networking, Storage, Virtualization by slowe | 11 comments

Beth Pariseau recently published an article discussing the practical value of long-distance vMotion, partially in response to EMC’s announcement of VPLEX Geo at EMC World 2011. In that article, Beth quotes some text from a tweet I posted as well as some text from Chad Sakac’s recent post on VPLEX Geo. However, there are a couple inaccuracies from Beth’s article that I really feel need to be cleared up:

  1. Long-distance vMotion and stretched clusters are not the same thing.
  2. L2 adjacency for virtual machines is not the same as L2 adjacency for the vMotion interfaces.

Regarding point #1, in her article, Beth implies that Chad’s statement “Stretched vSphere clusters over [long] distances are, as of right now, still not supported” is a statement that long-distance vMotion is not supported. Long-distance vMotion, over distances with latencies of less than 5 ms round trip time (RTT), is fully supported. What’s not supported is a stretched cluster, which is not a prerequisite for long-distance vMotion (as I pointed out in the stretched clusters presentation Beth also referenced). If you want to do long-distance vMotion, you don’t need to set up a stretched cluster, so statements of support for stretched clusters cannot be applied as statements of support for long-distance vMotion. Let’s not confuse the two, as they are separate and distinct.

Regarding point #2, the L2 adjacency for virtual machines (VMs) is absolutely necessary for distance vMotion. As I explained here, it is possible to use a Layer 3 protocol to handle the actual VMkernel (vMotion) traffic, but the VMs themselves still require Layer 2 adjacency. If you don’t maintain a single Layer 2 domain for the VMs, then VMs would have to change their IP addresses on a live migration. That’s REALLY BAD and it completely breaks live migration. Once again, there is a very separate and distinct behavior that you’re trying to modify with large L2 domains.

Am I off? Speak your mind in the comments below.

Tags: , , , , ,

Changing the IP Address on a VPLEX Management Server

Tuesday, January 18, 2011 in Storage by slowe | No comments

EMC VPLEX leverages a Linux-based management server as an integral part of the overall architecture. The management server, as the name implies, provides the management interfaces—both HTTPS (web-based) and CLI—for managing the VPLEX cluster(s). In a VPLEX Local configuration, changing the IP address is a single-step process; in a VPLEX Metro configuration, there is an additional step required. In this post I’ll walk you through both situations.

All in all, it’s a pretty simple process, but the one thing that might trip you up is the different CLI environments involved. Some commands are run from the management server’s native Linux-based CLI, while other commands are run from the Vplexcli. Remember that you’ll access the management server’s Linux-based CLI by simply opening an SSH session to the management server. You’ll access the Vplexcli by running either the vplexcli or telnet localhost 49500 commands once you’ve logged into the management server.

VPLEX Local

When you are running in a VPLEX Local configuration, changing the IP address of the management server is a single-step process. From the Vplexcli, a single command is all you need:

management-server set-ip -i <IP address:Netmask> -g <Gateway IP address> -p eth3

This command changes the IP address on the management server and you’re done.

VPLEX Metro

In addition to providing the management interfaces for the VPLEX cluster(s), in a VPLEX Metro configuration each management server is also responsible for creating and maintaining an IPSec-based VPN between itself and its peer management server in a VPLEX Metro configuration. The management servers use this VPN as a private connection between them in order to communicate with the directors in the remote cluster. Therefore, changing the IP address of a management server in a VPLEX Metro configuration could impact more than just the address used to access the VPLEX cluster(s).

So, in a VPLEX Metro configuration there’s a second step you must also follow in order to update the configuration for the VPN between the two management servers.

First, you’ll change the management server’s IP address using the management-server set-ip command I described above.

After changing the IP address using the management-server set-ip command, you then need to edit the /etc/ipsec.conf file on the other management server to reflect the new IP address you just assigned. For example, if you changed the IP address on management server 1 to 172.16.100.100, then you would edit the /etc/ipsec.conf file on management server 2 to show that management server 1 is now reachable at a new address. This ensures that the VPN configuration on each management server properly reflects the correct IP address of its peer.

To do this, open an SSH session to the peer management server—whose VPN configuration needs to be updated—and use vi to edit the /etc/ipsec.conf file. The specific line in the file that needs to be changed is the “right=” line, where the IP address indicates the remote server (“right” means “remote” in this case). Save your changes and return to the management server’s Linux-based CLI.

You’ll then need to re-enter the Vplexcli (again, using the vplexcli or telnet localhost 49500 commands). Once in the Vplexcli, restart the VPN using the vpn restart command. Restart the VPN on both management servers using this process.

To verify that the VPN is working properly, from the Vplexcli you can use the vpn status command like this:

vpn status -l <Local cluster ID> -n <Number of engines in local cluster> -c <Remote cluster ID> -e <Number of engines in remote cluster> -r <IP address of remote management server>

The output of that command should show that each director in each engine, both local and remote, is reachable.

If you need to change the IP addresses of both management servers in a VPLEX Metro configuration, then change one at a time following the process I described above.

Tags: , ,

An Introduction to the VPLEX CLI

Wednesday, December 22, 2010 in Storage by slowe | 3 comments

The VPLEX command line interface (CLI) is a bit different than a lot of other CLIs with which I’ve worked. In some respects, it’s similar to the scope-based CLI that Cisco uses with Unified Computing System (UCS). In this post, I’d like to explore the VPLEX CLI a bit and provide a brief introduction to the VPLEX CLI. Keep in mind that this is just an introduction—for a complete reference to the VPLEX CLI, I’ll refer you to the VPLEX product area on EMC PowerLink where a complete VPLEX CLI User’s Guide is available in PDF.

In my opinion, there are two things to know about the VPLEX CLI that will help you understand how to use it:

  1. First, the CLI is a lot like navigating a directory tree, except that you’re navigating through contexts instead of directories. In the VPLEX CLI, you move between contexts using the cd command and list the contents of a context using the ls and ll commands. Just as with a typical filesystem, if you’re in the right context, you can just run a command (say, like the unclaim command). If you’re not in the right context, you simply specify the full context before the command (I’ll show you some examples later in this post).
  2. Second, the VPLEX CLI supports wildcards and globbing, much like a typical filesystem. Use the asterisk (*) character to represent anything in a context, and use the double asterisk (**) to represent multiple matches across multiple contexts. You can use regular expressions as well.

With these concepts in mind, the real key to using the VPLEX CLI is simply learning where all the various objects reside. For example, in an earlier post on VPLEX storage objects, I discussed the building blocks of storage in a VPLEX environment: storage volumes, extents, devices, and virtual volumes. These reside in different places in the VPLEX contextual tree:

Storage volumes: /clusters/<cluster name>/storage-elements/storage-volumes
Extents: /clusters/<cluster name>/storage-elements/extents
Devices: /clusters/<cluster name>/devices
Distributed devices: /distributed-storage/distributed-devices
Virtual volumes: /clusters/<cluster name>/virtual-volumes

Within each of these contexts, you can use the ls and ll commands to view the contents of that context. The help command will show you what other commands are available in each context.

Here’s my first example. When you first log into the VPLEX CLI, you’ll get dropped into a “root context”. Running ls here will produce output something like this:

VPlexcli:/> ls
clusters    data-migrations  distributed-storage  engines  management-server
monitoring  notifications    system-defaults

Let’s take a look at a few more examples. For example, the following two sets of commands will produce the same output:

cd /clusters
ll

and

ll /clusters

Remember that specifying the context in the command is the same as changing into that context and then running the command. That is why these two commands produce the same output.

To view the list of directors in a cluster:

ll /engines/*/directors

This is an example of using the asterisk to represent a wildcard that matches all entries in that context.

Let’s look at another example of two different commands that produce the same output. To view the status of the ports on a particular director in a cluster, you could use either of these two commands:

ll /engines/<engine name>/directors/<director name>/hardware/ports

or

cd /engines/<engine name>/directors/<director name>/hardware/ports
ll

By the way, if you haven’t figured it out yet, you can easily get the names of the engines (or the directors) by simply running the ll command against the engines context or the directors context within a specific engine.

But what if you wanted to see the status of the ports across multiple directors? Now you won’t want to use the cd command. You’ll want to use globbing with wildcards instead, like this:

ll /engines/**/ports

While the single asterisk matches anything within a context, the double asterisk matches across multiple contexts. So, in this case, it ends up matching multiple engines and directors within those engines.

And if you wanted to see only some of the front-end ports on all directors:

ls /engines/**/hardware/ports/*1-FC0[0-3]

In some cases, you might need to set an attribute on an object within a context. For example, you might need to enable a port by setting the enabled attribute on that port to True. Here’s how you would do that:

set /engines/<engine name>/directors/<director name>/hardware/ports/A0-FC00::enabled true

If you think about it, you could easily combine some globbing to enable multiple ports at the same time:

set /engines/**/hardware/ports/A0-FC0[0-3]::enabled true

You can then verify the operation by using the -t parameter to the ls command, which instructs it to include attributes:

ls -t /engines/**/hardware/ports/A0-FC0[0-3]::enabled

There are many, many more examples I could share with you, but this should get you started for now. I hope to have a post up soon with a CLI guide to setting up storage volumes, extents, devices, and virtual volumes.

As usual, feel free to speak up in the comments if you have any questions or clarifications. Thank you!

Tags: , , ,

Using VPLEX and Data Replication Together

Monday, December 20, 2010 in Storage by slowe | 4 comments

In my previous post on EMC VPLEX, I provided a review of the VPLEX storage objects. In that post, I discussed the difference between a storage volume, an extent, a device, and a virtual volume. If you are unclear on the distinctions between those terms, I suggest you go back and read that post again before proceeding.

The following diagram illustrates these various storage objects again:

As you can see from the diagram, VPLEX offers a number of different ways to combine these objects together:

  • You can slice a single storage volume into multiple extents, then use each of those extents to create a separate device (and then a virtual volume). The VPLEX device might only occupy one of the extents on the storage volume and other data might occupy other extents on the storage volume. This is the option on the left side of the figure.
  • You can combine extents from different storage volumes together into a single device (and then a virtual volume). This is the option on the right side of the figure.
  • Finally, you can create a single extent occupying all of a storage volume and use it to create a single device. This is the middle option illustrated above and, as you’ll see shortly, is the generally recommended way of doing it.

Now that I’ve reviewed the storage concepts again, let me delve into the real meat of this post. Since the introduction of EMC VPLEX and its storage federation functionality (which apparently I’m not supposed to call storage federation; see the comments here), organizations have another choice in their disaster avoidance/disaster recovery (DA/DR) plans. In addition to utilizing data replication solutions, organizations now have the option of integrating VPLEX’s data synchronization functionality into their DA/DR solution. Is there room for VPLEX in an organization’s DA/DR planning? The answer is yes! While there has been a great deal of confusion about how, if at all, VPLEX could be used in conjunction with (rather than instead of) existing replication solutions, it is possible and it is fully supported (with a few caveats). This post discusses how you can use both VPLEX and data replication in the same environment.

As a side note, a fair amount of the information in this post is derived from a white paper, published by EMC, on the use of array-based replication with EMC VPLEX. I do encourage you to read that white paper for more information and more details.

So what would a supported configuration that uses both VPLEX and replication look like? This diagram graphically depicts a supported solution that integrates both EMC VPLEX and a data replication solution such as SRDF or RecoverPoint:

The key to a supported solution that combines VPLEX and replication lies in the phrase “single extent/single device”. In order to use both replication as well as VPLEX in the same solution, you must use a 1:1:1 mapping between storage volumes, extents, and devices. In other words, you must use a “single extent/single device” approach, where each storage volume has only a single extent (occupying the entire storage volume), and devices are built from that single extent on a single storage volume.

If you think about it for a minute, you can easily see why this is the case. Let’s consider a scenario in which you are wishing to combine VPLEX with RecoverPoint:

  • What is the smallest unit of replication for RecoverPoint? A single LUN. Sure, you can replicate multiple LUNs or groups of LUNs, but the smallest unit of replication is a single LUN. You can’t replicate part of a LUN.
  • What is the smallest unit of federation for VPLEX? An extent, which might be part of a back-end storage volume (a LUN). You can federate multiple extents or groups of extents, but you can’t federate a part of an extent.
  • How do we get these two units lined up with each other? If RecoverPoint works only on entire LUNs and VPLEX works on extents, then the way to line them up is to ensure that each extent represents an entire LUN. This makes RecoverPoint’s basic unit (an entire LUN) the same as VPLEX’s basic unit (an entire LUN).

With your replication solution replicating entire LUNs and VPLEX working on entire LUNs, this creates the sort of situation where I/O can pass through VPLEX to the back-end array, where the replication solution can pick it up and replicate it off to a third location. This gives organizations the best of both worlds—support for disaster avoidance using VPLEX at synchronous distances and support for disaster recovery using a replication solution such as RecoverPoint or SRDF at longer distances.

Your feedback is always welcome! Post any questions, corrections, or clarifications in the comments below.

Tags: , ,

A Quick Review of VPLEX Storage Objects

Monday, December 13, 2010 in Storage, Virtualization by slowe | 14 comments

Now that I’ve managed to get my VPLEX clusters up and running, I’m ready to start providing some posts on VPLEX and how it’s configured and used. To get things started, I want to first provide an overview of VPLEX storage objects and how they relate to each other.

<aside>The images shown in this post are being served from Dropbox. If your office blocks Dropbox (like EMC does), then these images might not appear. I apologize for the inconvenience.</aside>

Storage volumes: Storage volumes are the LUNs that are presented to the VPLEX back-end ports from the storage array. The screenshot below, taken from the VPLEX management GUI, shows a series of storage volumes taken from two separate back-end arrays.

Extents: Extents are created on storage volumes. You have the option of creating multiple extents on a single storage volume, but EMC generally recommends creating one extent per storage volume. (Future posts will discuss why this is beneficial.)

Devices: Devices are created from extents. You can combine multiple extents together to form a single device, or you can present a single extent up as a single device. As you can see in the screenshot, devices also have a geometry associated with them, like RAID-0 (no mirroring of devices together), RAID-1 (mirroring of devices), or RAID-C (concatenating devices).

Distributed devices: Distributed devices are mirrored devices that are spread across two VPLEX clusters connected together into a metro-plex. Distributed devices require extents from both VPLEX clusters in the metro-plex. Like “regular” devices, distributed devices also have a geometry. As far as I know, all distributed devices will automatically have a RAID-1 geometry. Note that because distributed devices aren’t confined to a single cluster, they reside in a different place in the hierarchy.

Virtual volume: Virtual volumes are built from devices. When a virtual volume is built from a device, it’s referred to just as a virtual volume. When the virtual volume is built from a distributed device, it’s referred to as a distributed virtual volume. Virtual volumes are what are exposed (exported in VPLEX parlance) to hosts via the VPLEX front-end ports.

In future VPLEX posts, I’ll provide information on managing these various storage objects (creating, renaming, and deleting objects) as well as information on integrating VPLEX with other data protection solutions. Stay tuned!

Tags: , , , ,

Stretched Cluster Presentation from Denver VMUG

Thursday, September 30, 2010 in Networking, Storage, Virtualization by slowe | 10 comments

I had the honor of speaking in front of the Denver VMUG on Tuesday of this week. It was a blast, and I got to meet a great group of people. I received some positive feedback on the presentation that I gave at the VMUG, so I thought I’d share it here as well.

 

This is my first time using SlideShare, and I’ll probably go back and update the slide deck here since some of the builds and formatting get lost in the conversion. If it’s well-received by the readers, I’ll likely post some other presentations I’ve given as well. Let me know your thoughts—both on the idea of embedding more presentations here as well as any thoughts on this particular presentation—in the comments below. Thanks!

Tags: , , , , ,

VPLEX Webcast

Tuesday, August 3, 2010 in Storage, Virtualization by slowe | 1 comment

Next Thursday, August 12, I’ll be hosting an EMC Live webcast titled “Disaster Avoidance with VMware vSphere and VPLEX”. The webcast is part of EMC’s weekly VMware-focused webcasts. We’ll be starting next Thursday, August 12, at 8AM Pacific/11AM Eastern/4PM BST.

As you can tell by the name, I’ll be discussing EMC VPLEX and how you can use VPLEX to potentially build a DR-avoidance scenario for your virtualized environment. If you’re interested in learning more, register for the webcast here. Thanks!

Tags: , , ,

A Deeper Look at VPLEX

Monday, June 7, 2010 in Storage, Virtualization by slowe | 12 comments

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: , , ,

A Quick Look at VPLEX and VMware SRM

Monday, May 17, 2010 in Storage, Virtualization by slowe | 10 comments

The announcement of VPLEX last week at EMC World 2010 in Boston has introduced lots of new possibilities in how virtualized data centers should be designed and deployed. Of particular interest to a number of people is how VPLEX interacts with VMware Site Recovery Manager (SRM).

Jason Nash of Varrow mulls over VPLEX and VMware SRM in this post, where he asks if VMware SRM is even necessary:

If money was no object, or if you needed VPLEX anyway, where does that leave VMware’s Site Recovery Manager?

While many of Jason’s points are absolutely valid, there are some other very important things to keep in mind:

  1. First, and perhaps most importantly, VPLEX and VMware SRM is not an “OR” discussion, it’s an “AND” discussion. As noted by Chad Sakac’s response, there is a VPLEX SRA currently planned. There are some issues to work through—such as the current requirement by VMware SRM for two vCenter Server instances—but I’m confident these issues will be resolved.
  2. Second, the behavior of VPLEX in the event of an unplanned outage lends itself well to VMware SRM-like behavior. In the event that the VPLEX cluster in Site A (your primary site) loses connectivity to the VPLEX cluster in Site B (your secondary/DR/failover site), a set of rules defined by the user control which cluster will continue to have read/write access to distributed devices. The other cluster will suspend I/O to distributed devices until a user manually resumes I/O. This makes VPLEX behavior in an unplanned outage act a lot like VMware SRM already, and is probably one of the reasons why a VPLEX SRA is under development. As long as there are steps that can be automated in some programmatic way, there is continued value for VMware SRM.
  3. Third, it’s important to keep in mind that the requirements for vMotion over distance include spanned Layer 2 VLANs (using something like Overlay Transport Virtualization from Cisco); VMware SRM has no such requirement. Further, VPLEX is currently limited to synchronous distances; VMware SRM is limited only by the underlying replication mechanisms. This means that VMware SRM continues to be a very valid deployment option even in organizations that may also deploy VPLEX.

Jason does make one point that I absolutely agree with:

But, to me, this yet again adds more reasons to virtualize all the applications that you can. Virtualizing the tier 1 apps reduces your DR plan by a large amount with SRM and this would make it even simpler.

The more applications you virtualize, the more you will be able to take advantage of products like VMware SRM and VPLEX. So what are you waiting for? Get virtualizing!

Tags: , , , , , ,

« Older entries