May 17, 2012

Hello Hyper-V : Meet Reality

First off stop reading this and go read Eric Gray’s post on the new Microsoft Virtualization Team post. He does a great job of pointing out the hypocrisy of marketing speak from the MS Virtual Team.

I am writing this blog post to address some specific annoyances in reasoning. While I have made a career in being a Microsoft guy (along with VMware, Cisco, EMC, and Nissan sportscars) I have some serious problems with the marketing pitch around Hyper-V.

So let me attack these head on. First off Chris Steffen states:

VMWare claims to support 4x more OSes that Hyper-V, but what does that really mean? When Microsoft lists an OS as supported, they COMPLETELY support the actual OS installation in the VM and you can call Microsoft support on that OS. Microsoft has support agreements with Red Hat and Novell specifically for this purpose.

So let’s be clear. What does Microsoft support in this case? Do they have support staff on hand that will work with the customer on Red Hat or Novell OS configuration? Would you trust Microsoft to touch your device information files on your Linux host? And to be quite honest, since Red Hat and Novell fully supports their enterprise products within the VMware environment. What is the real difference?

So let’s sum this up.

On vSphere if I have a problem I can:

  1. Call VMware for hypervisor specific issues (experts on this layer)
  2. Call Red Hat or Novell to get full support for OS specific issues (experts on this layer)

On Hyper-V if I have a problem I can:

  1. Call Microsoft for hypervisor specific issues (experts on this layer)
  2. Call Microsoft for OS issues (not-experts) and likely be transferred to step 3
  3. Call Red Hat or Novell to get full support for OS specific issues (experts on this layer)

So the real benefit Chris Steffen points out is an extra possible step. In the end my support coverage is the same at worst. Although I would be very curious about the actual level of knowledge between Linux support/Hyper-V and Linux support/vSphere. But, I can’t prove that point yet. And outside of these two specific operating systems flavors vSphere is light-years ahead. According to the current checklist, vSphere supports 48 flavors of OS compared to Hyper-V’s paltry 13.

Now to the next item:

Also, many of the OSes that VMWare claims to support are only supported by the Linux community – not taking a shot at the Linux community here, but most do not have a formal support organization. This leads me to question why they would be used in an enterprise environment. Also, those Linux distributions can be run under Hyper-V, using the Linux Integration Components Microsoft has available for download and the drivers which are in the 2.6.32 Linux kernel release. In this case, customers wouldn’t be able to call Microsoft for support for the OS, but would work with the Linux community, just as they would with VMware.

So this is pretty simple. The point here is: don’t use open source software. He states that VMware and Microsoft have the same community support so it is just a case of commercial vs. OSS and not a hypervisor argument. I would point out that community support is not only robust for vSphere but also VMware has guides, links, and walkthroughs on their own site (in a very easy to use setup) for how to implement multiple flavors. I wonder how easy it is with the Hyper-V side of things. Since OSS is not the argument here feel free to post OSS success stories in the comments.

 

Now for the fun part:

Reality: The Microsoft solution does not allow for over subscription of critical resources, but you shouldn’t do it anyway.

Oh no! I did not know this. Well I hope he is going to explain why at least.

The core of the VMWare argument is that you can somehow get “something for nothing” – that there is some kind of magic that comes with the over subscription of RAM using VMWare that is the silver bullet regarding memory management.

Wait a second, the argument is “something for nothing”? So efficiency is zero sum result? So I guess there goes thin provisioning, thin-client computing, or any other “thin” (read: effecient) technology. I better go shutdown my Windows Terminal Services farm too because I must be not really gaining anything.

So without the sarcasm, this is utter nonsense. He does not actually attack the technology or approach. He does not talk about direct risk or that fact that all efficiency models require management. Just like you have to manage the amount of users on a Terminal Services server you have to manage use on a vSphere cluster (notice I said cluster, not host. DRS much?). There is always inherent risk in higher utilization rates. That risk is managed by proper operational abilities. With vSphere these are clustering with DRS which allows automated movement of VM’s across hosts based on utilization and vCenter alarms which set low water marks against memory utilization. So with vSphere I have the option to take on operational responsibility for risk in exchange for higher efficiency (see $$$). The reason this is not zero-sum is obvious. I manage out the risk with a mature hypervisor (vSphere) gaining benefit I can never get with Hyper-V. With VDI and newer deployment models using virtualization, this can be a huge cost savings.

To leverage memory management in ESX to the fullest, one would have to fully burden the host beyond the physical memory. If you don’t, you really aren’t using memory overcommit.

Burden. Got to love that word. Puts an emotional spin on it. You can picture it right? The poor ESX host crawling across the data center will all the VM’s on it’s poor weary back.

Efficiency = lower total cost of ownership. The “burden” is your host doing more work for less money. I wonder if trucking companies talk about weight loads as “burdens” upon their poor MAC trucks.

 

Ok, one more:

Let’s go back to Basic Computer Architecture 101, and the example of the water pipe. There are limits to how much water you can push through a pipe at any given time, and the more taps that you add to the pipe, the longer it will take to fill up a bucket at each of the pipes. Hyper-V uses the best practice of moving a single VM as quickly as possible, using the entire bandwidth available to complete the transfer. Also, it is important to point out that without a modification of the host setting, VMWare would limit the migration to 4 VMs at a time (presumably for the same bandwidth considerations). The idea of moving 40 VMs all at the same time (as mentioned in the article) is not something that would be recommended, ever, regardless of platform.

Nice of him to explain throughput constraints for a kindergarten class. I would like to show a comparison of VMotion vs. Live Migration speeds (especially on my 10GE FCoE stuff) but instead I will keep it simple.

Why? Why can’t I do this with Hyper-V? Isn’t it because they don’t trust me? Or it is because they can’t make it work without sacrificing stability?
vSphere lets you not only do more but, also lets you do less. In other words, the mechanism is stable enough that throughput is the limitation (the water pipe) and not the stability of the mechanism (Hyper-V Live migration). Microsoft’s limitation on this points out a possible stability flaw and not a risky endeavor. What is also fascinating is the focus on making it “quicker“. Why does it have to be so quick? Are they afraid the VM’s won’t get there on Hyper-V if it takes to long?

 

There is a lot more to point out but, instead I will let someone else have the fun. I am not an anti-Hyper-V guy. I am an anti-F.U.D. guy. I would much rather Microsoft focus on providing a cheap product for small shop markets. In my mind that is what they designed with their product in both cost and feature-set. Even though VMware has some nice offerings also – see here & here

Also, I claim originality rights to the term: “DRS much?”. Feel free to tweet it like crazy :)

Comments and criticisms are welcome and appreciated.
.nick

 

Reblog this post [with Zemanta]

Virtualization & Abstraction : The New Paradigm

This post is inspired by this outstanding post by Chuck Hollis (@chuckhollis) and this one by Chad Sakac (@sakacc).

Chuck mentions my favorite way to summarize what virtualization encompasses: “abstracts logical from physical”. What makes abstraction critical is that it breaks historical dependencies that develop as technologies are built over time. I have said this phrase hundreds of times over the last four years of my career and in my mind it translates into an incredible paradigm shift in data center approach over the next ten years.

A good example of this is the push to service-oriented architecture design principles in the enterprise application space over the last decade. The whole gist was to enable business functionality to achieve independence and agility by breaking hard coded dependencies to platforms and systems. A loosely-integrated system can provide value to multiple business units by removing the overhead of inherited designs. Any ability to move quickly to market with business features brings competitive advantage. In simple terms, removing boundaries opens more opportunities.

Virtualization is the same approach with the end goal of the four food groups (CPU, memory, storage, networking) becoming commodities that can used as needed and where needed.  The status quo has been large CapEx investments in infrastructure where efficiency was limited by the boundaries of the physical needs and the return on labor cost to optimize. Even with a large team invested in tuning and sizing, the organic growth of the business can waste resources quickly as usage patterns change and new infrastructure is purchased.

The virtualization of hardware resources, effectively coupled with the ability to treat hardware as single pools, removes that physical boundary. This allows single investment in infrastructure resources to be carved up for multiple needs. It also allows the refactoring and control of these resources without the large operational cost and risk that physical resources historically bring. This abstraction means that a single server is no more special to an application than another; which means I can move, change, add, remove, or make a host of operational changes without risk. The virtual machine is coupled with the service that needs it and therefore applies fewer boundaries.

With the release of VMware’s vSphere product, critical aspects have been added. This includes the extending of network control to the virtual machine with Cisco’s Nexus 1000v. Now, both management and security of this layer can follow standard process of governance and operational models.

And now with EMC’s new FAST and the deployment models around the V-Max unit, the approach to storage is following the same design principles. If my data workloads are no longer bound to physical boundaries then I can deploy, react, and manage with less risk and more efficiency. I can focus higher expense storage at specific business needs when they need them and maintain cost effective use with lower cost storage on workloads that are diminishing. This translates directly into higher efficiency and lower total cost. Better yet, with approaches like NPIV, virtual machines can be matched to security, quality of service, and metrics. These features extend management, service-levels, and security on the storage layer to the virtual machine as well. Storage abstraction is the last great milestone to the virtual machine becoming the foundation of a data center. EMC is making a huge investment in both technology and people to make this a reality.

Despite the “coolness” factor in abstraction, the one important benefit is simple. Virtualization of servers, storage, networking, and ultimately business functionality brings efficiency. With vSphere I can take a set of CapEx impacting infrastructure and achieve higher utilization, less operational management, and be faster to market with features. To the business, this translates into a competitive advantage that can be measured. Because this hardware can be incrementally grown (EMC V-Max, vSphere), I can horizontally scale with growth demands and bring agility to change as well. And with new models like the VCE vBlocks even the large and complex standup cost in time/effort can be drastically reduced.

In the end only the goal of making people and business more successful is important. The abstraction that virtualization brings opens possibilities where they have not existed before.

As always, comments and criticism  are welcomed.

Reblog this post [with Zemanta]

Virtualizing the Data Warehouse : VMware, SQL Server 2005, and EMC Clariion

VMware Inc.

At my current employer we use a custom built ETL process for building business reporting and analysis data. Originally this started as a medium-sized Dell server with a full rack of local storage. As the criticality and scale of this resource grew, it outgrew the hardware it was on.  The key to this server was that the build process ran overnight and the server was accessed by multiple departments throughout the day.  This left very little time for hardware maintenance. I had helped move all development environment servers to a VMware cluster months before. Using this momentum I pitched the idea of solving the criticality and scalability with a VMware-based solution. The argument was four-fold:

  1. The company wanted to avoid the licensing and hardware expense of moving to a Microsoft clustering solution.
  2. VMware HA provided resumption of services in the case of a hardware failure and hardware maintenance would not require downtime.
  3. The RTO was satisfied by an automatic HA fail over.
  4. The additional cost of VMware licenses and new hosts would be spread over future planned provisioning and actually reduce costs by introducing consolidation.

After playing the part of VMware sales rep. I was able to get endorsements from the CTO, Data Services, and Executive groups. This would be the first time we would attempt to put a business critical service on a VMware platform. I was the only individual in IT at the time that had any exposure to VMware and needless to say my reputation and job was likely on the line.  The success (and to a greater extent stability) of the development environments was the key to get my foot in the door but now it was time to change our culture.

We opted to purchase additional Dell 2950 servers and EMC Clariion enclosures and dedicate a single DAE of fibre-channel 146GB x 15 for database drives. We did a few weeks of testing SQL loads that matched the ETL process (at the time) and determined that the optimal configuration was a single RAID10 of 14 disks with 3 separate VMDKs for data, log, and temp db.
The critical decision was “how do we move it?”.  At the time, P2V of SQL, Active Directory, and Exchange was not very common. I pitched the idea of a cold P2V using VMware converter. My justification was that the virtual could be brought up in parallel and everything tested completely. It took a few meetings to explain the process and give everyone a level of comfort
The P2V was successful and the virtualization has proved to be extremely valuable to the management of this server since. Here are just a few examples of VMware features that we have leveraged:

  • Storage VMotion – Moving the OS drive
  • Snapshots – Before a critical change
  • VMotion – Ability to add to, repair, or restructure hardware without having to involve a outage
  • Scale Up & Scale Out – Again without impacting service availability
  • DRS – Resource balancing servers of mixed workloads

Our company IT culture has changed in many ways over the last few years. VMware has become a central part in our Infrastructure foundation and has brought both stability and agility. We have virtualized Exchange, OCS, web servers, application databases, and many other services sucessfully since. Now we have ambitious goals of leveraging advanced SOA-based platforms coupled with business continuity and scalability using a VMware infrastructure. Looking back, this initial server was our first step.

I will be adding more posts soon on lessons we learned post-virtualization. If you have comments or even disagreements please leave comments below.