February 4, 2012

The VCE Model : Yes, it is different

This post comes out of a slide deck I authored last week for a partner event. I decided I was going to try and illustrate why the VCE model really is such a different approach to other datacenter and private cloud models.

Normally my blog is light on vendor specific commentary. I see myself more as a virtualization geek who just happens to work for an awesome company (EMC) than a hardcore analysis/blogger. But I have seen so much messaging lately that distorts the VCE message, I really felt the need to offer my own perspective. [Read more...]

Don’t Panic : Mirror Positions

What happens to a VM that is hosted on a VMFS datastore when you physically remove both of the mirrored drives from the array? Kernel panic/blue screen right?

What if you were replicating that LUN to another site using array based replication? Would the VM still crash?

Not if you’re using Symmetrix Remote Data Facility, Synchronous mode (SRDF-S).

Let’s rewind a bit. One of the main architectural attributes that distinguish an enterprise array from a mid-range array is the connectivity and cache model. In a midrange array you will typically see an active/passive controller from a LUN path ownership perspective, while an enterprise array provides an active/active controller model for because the front-end adapters don’t “own” the LUN per-se (Yes, I’m oversimplifying this a wee bit, but only to skip past this detail and get to my point!).

Mid-Range Array

Enterprise ArrayAs you can see in the simplified images, enterprise arrays provide a complete cache abstraction layer between front end controllers (host side) and back end controllers (drive side). In other words, if you want to send a command or piece of data from the host to the drive, you must do so through cache.

This kind of abstraction, much like the server abstraction provided by VMware ESX, is a key enabler for much of the genius that occurs in all shared storage platforms.

In the world of Symmetrix, a mirror-position is a device in the system that a segment of cache refers to. When a write occurs, it is acknowledged by cache, then the system will deliver the write to all of the necessary mirror-positions. If it is a “2 Way Mirror” (RAID1) it will write to mirror-position 1 (first RAID1 device) and mirror-position 2 (second RAID1 device).

Two Way Mirror

When you create a RAID1 configuration on a Symmetrix DMX or VMAX the system refers to it as a “2-Way-Mir” (two way mirror). That is the systems way of saying that each cache segment responsible for staging IO within this volume has two positions to write to – each of which are on a physical device (this architecture allows RAID1 volumes to stretch far beyond the capacity limits of a single drive – neato!) (By the way, with Virtual Provisioning technology implemented in the VMAX, the virtual pool’s device is the mirror position, and the pool takes care of RAID – the idea here is still the same though).

What if you wanted a “3-Way-Mir”? Well technically, that’s what SRDF-S is; it’s a three-way mirrored volume. The first two mirror positions are local devices, and the third is a device on the remote array.

Three Way Mirror

So what happens when you simultaneously remove both of the drives in a two drive two way mirror with SRDF-S configured?

Pull Both Drives

Your VMs stay online. Read latency will suffer as reads are now being serviced by the remote site, but writes are the same speed because they were limited by the inter-site latency anyway.

How awesome is that?

Hello Hyper-V : Meet Reality (part deux)

Well my blog post yesterday drew way more attention that I thought it would. Part of the attention was a comment from the esteemed Ben Armstrong (twitter & blog).

He provided wonderful feedback and I have decided to highlight it here with my response. Not sure if I am breaking a blogosphere rule but, I shall claim etiquette ignorance and proceed.

Here are Ben’s comments:

Ben Armstrong
January 22nd, 2010 at 12:27 am

Hi Nick,

Just thought I would drop in to clarify some of the issues you raise around the issue of operating system support.

What we often talk about on the Hyper-V team is “Support versus support”. Hyper-V can run Windows NT 4.0 – and I would love it if we said that we support it, but we cannot say that – because Microsoft as a whole does not support Windows NT 4.0. And it really changes the story when you are the OS maker.

For example – let’s imagine that we did state that we supported Windows NT 4.0 on Hyper-V, and we compared the support experience between Microsoft and VMware:

VMware:

Customer encounters a problem with Windows NT 4.0 on ESX. They contact VMware – who after investigating the issue declares that “sorry – this is a bug in Windows NT 4.0, you should contact Microsoft”. When the customer contacts Microsoft they are told that Windows NT 4.0 is not supported. The customer still has a problem, but they do not feel lied to.

Microsoft:

Customer encounters a problem with Windows NT 4.0 on Hyper-V. They contact Microsoft – who after investigating the issue declares that “sorry – this is a bug in Windows NT 4.0, and even though we said we supported Windows NT 4.0 on Hyper-V we did mean that we supported Windows NT 4.0″.

Can you see why we (Microsoft) do not feel that we can make such statements? Meanwhile VMware currently states that they support every Microsoft OS from MS-DOS 6.22 onwards.

In regards to Linux support – when we state that we support a Linux distribution on Hyper-V, it means that we have signed formal support agreements with the owner of that Linux distribution. For example – if you have an issue running SuSE on Hyper-V, you can contact Microsoft product support. They will then work with Novel support engineers directly to solve the issue – without requiring you to bounce back and forth between the two companies.

As an aside – the problem with this approach is that it makes it hard to support versions of Linux like CentOS, where there is not a corporate entity who can sign a support agreement. That was one of the motivating points releasing our integration components under GPL – so that community supported distributions could provide the same level of support for Hyper-V as they provide for other platforms.

Cheers,
Ben

First off, thanks for the comments Ben. I appreciate your providing clarity and participating in a discussion

I completely understand the predicament around legacy Windows versions. Because of the dual ownership, Microsoft does have to maintain standards around support.

But, I disagree that at a higher-level this is a problem. I see this as the difference between strategic and tactical viewpoints with hypervisors (great post on this from Steve Kaplan here).
Here is an example:

Let’s say we have a customer that has 20 legacy servers running Windows NT 4.0.
They don’t have the budget to purchase replacement software, the original application creator is gone (and they didn’t have the source in escrow), and it is completely incompatible with new OS server versions.

With Hyper-V not only will they not be able to P2V (physical to virtual migration) these servers. They also would get zero support from Microsoft for Hyper-V hosts that encounter issues with these VM‘s. There is a built-in out for the support person on the other end of the phone. This translates into an implementation impossibility and extreme operational risk.

With VMware vSphere, not only is the P2V actually supported (allowing abstraction of the OS) but the VM’s themselves are supported on the hypervisor. That means if there is a specific issue with hypervisor configuration VMware will support, fix, and help with making this successful. I know people that have not only successfully virtualized legacy operating systems but, have also done it with extremely proprietary configurations (@tscalzott).

The hypervisor is a layer and a toolkit meaning the intent is to provide abstraction as well as options for business needs. Hyper-V is missing these options which, because of the tactical approach MS has, make it more limited in application. My points is the missing options and not an effort to downplay the features it does possess.

Microsoft’s (and your focus) on integrated support is because of the tactical approach to the hypervisor. Hyper-V it is built on the same platform as the server product and blends layers rather than abstracts. Support can be integrated but, in an abstraction model that is done successfully (empirically proven with VI3 & vSphere) this is not a critical need. When layers are abstracted you break the dependencies that exist in blended/tactical models. Integrated support is a core marketable value in tightly coupled dependency situations like hypervisor to storage, networking, and server components. In fact, that is one of the primary reasons VMware tightly maintains and accelerates their hardware compatibility list (HCL). Where abstraction does not exist this is essential and with vSphere is assumed by the ESX host. With Hyper-V the HCL is much broader because it is based on the underlying server operating system. But that is because Microsoft has abstracted hardware using the operating system (Windows Server). Problem is, that means all you have done is create another dependency upon a relocated layer. In fact if you think about it, the operating system with Hyper-V is now a layer above and below the hypervsior. This is a completely different approach to virtualization.

I am not saying Hyper-V has taken the wrong approach, I am just trying to clarify the real value of each product and the completely different approach. Microsoft has invested interest in businesses moving operating systems to newer Server version from a revenue perspective. Their motivation is inherit in their approach and marketing as evidenced by both the blog & your comments. Why would Microsoft invest major effort in reducing their ability to consume operation system market share?

On the other hand VMware’s interest in providing a extremely stable hypervisor with a robust feature-set that will work for as many possible deployment models as possible. They are successful despite the operating system choices of their customers. Being a customer I can testify that VMware support is extremely helpful in supporting guest OS’s on their platforms. While they won’t make changes application configurations (not stated at least), they do posses a massive knowledge base of how to successfully virtualize their long list of possible options.

However, in forward looking design scenarios Hyper-V does stand differently against newer Windows Server versions. With an apples to apples design using Windows Server 2008 and beyond, the battle is more over the cost, operational capability, and long-term value than support or compatibility choices.
Hyper-V does not have options that compete against VMware in heterogeneous operating system space and once you cross that line and make statements against operating system approaches, you have broadened the argument beyond an apples to apples comparison.

I really do appreciate the feedback and feel free to hit me back.

 

.nick

Reblog this post [with Zemanta]