Windows 2008 R2 host clustering versus VM clustering

I have been reading up on host clustering versus VM clustering with Windows 2008 R2.   Let's assume I have two VM's for which I want to have hardware redundancy. It seems I have two choices: I can cluster two physical servers hosting the two VMs at the host level or I can have two physical servers and can cluster at the VM level.
I have a couple of questions:

I understand I need 2008 R2 Enterprise or better or HyperV server to be able to do host clustering - I can't use 2008 R2 standard. What about VM clustering? Can I use 2008 R2 standard?

Regardless of the above, why would I ever choose to cluster the VM's individually as opposed  to simply clustering the host? Wouldn't I need  a separate shared cluster disk for each VM as opposed to a single shared cluster disk with host clustering?




lineonecorpAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

kevinhsiehCommented:
The requirements for Windows failover clustering are the same for physical servers and VMs - Windows Enterprise/Datacenter and shared storage. That said, the free Hyper-V Server product does have failover clustering, so you can use it in the parent partition instead of Windows Enterprise/Datacenter.

Clustering at the VM and host level buy you different things. Clustering at the host level gives you the ability to recover from a hardware failure, and is pretty easy to setup. Host clustering does not protect against OS failure, application failure, database corruption, etc.

Clustering at the VM level gets you the same protections that you get from clustering physical machines - it is the same thing. Failover from node to node should be faster than failing a VM from one host to another, but you need to setup the clustering for every application, and not all applications can be clustered. You would probably want to cluster Exchange 2010 nodes so you have DAG protection. I am working on clustering many of my new VMs so I can have 2 VMs, and I am able to work on one node without taking down the services from being available.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SHBSystems ArchitectCommented:
I'd recommend to do cluster between two physical servers and install Hyper V in CSV (Clustered shared volume) with 2008 R2 Enterprise. You can leverage the benefit of running two VMs in two hosts for different applications in redundancy.
0
lineonecorpAuthor Commented:
kevinhsieh:

Thanks for the quick response.

If I understand you correctly, when I have two servers that are running a clustered File Server at the host level and physical server A crashes I will failover to server B; however if the situation is that the File Server VM fails - not hardware, some OS issue - then nothing will happen with host clustering only VM clustering would deal with that situation by failing over to the clustered VM node - the host wouldn't notice anything wrong at all - it only notices when its OS is corrupted or if the server hardware fails?

I can definitely see the value of clustering/DAG for Exchange.

What about VM clustering for the following specific situations:

File server?

A server that is running a single critical app that is SQL-server based?

A server that is running a single critical app that is not SQL-server based?

A Web server?

A Terminal Server/Remote Desktop Server?

Finally let's say I have two different kinds of VM's that I am hosting on a server and I want to cluster them at the VM level, will I need two separate shared clustered volumes for each VM?
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

kevinhsiehCommented:
You are correct in that if you have host level clustering only and a file server VM fails, (the Server service crashes, or even a blue screen) the hypervisor won't know that there is a problem and you will need manual intervention. The hypervisor cluster knows when the host nodes have gone down or are otherwise unavailable due to networking issues and will take action. They can even know when the VM has crashes and lost its heartbeat (I don't yet know how you actually DO anything about that in Hyper-V). I believe that System Center Operations Manager can look deep into the server (physical or virtual) and take action if something is amiss.

You can do failover clustering for file servers, SQL servers, and other services as well. You can combine host clustering and failover clustering inside the VMs.

Web servers and remote desktop session hosts typically use different clustering technologies because you want to be able to have multiple active nodes at the same time.

You can put all of your VMs onto the same single CSV. This includes the VMs in VM level failover clusters.  For failover clustering using VMs, each cluster will need its own dedicated access to cluster storage LUNs. This is for storing application data and another LUN for disk quorum (if needed for an even number of cluster nodes). This requirement is the same as for physical Windows failover clusters. It isn't a CSV because because that is a special type of volume only available for clustering the Hyper-V service. When using Hyper-V today, these cluster LUNs for the VM cluster must be iSCSI, even though the Hyper-V hosts can also use FC and SAS.
0
lineonecorpAuthor Commented:
kevinhsieh::

Thanks for the additional detail. It gets my brain chugging. You write:

You are correct in that if you have host level clustering only and a file server VM fails, (the Server service crashes, or even a blue screen) the hypervisor won't know that there is a problem and you will need manual intervention. The hypervisor cluster knows when the host nodes have gone down or are otherwise unavailable due to networking issues and will take action. They can even know when the VM has crashes and lost its heartbeat (I don't yet know how you actually DO anything about that in Hyper-V). I believe that System Center Operations Manager can look deep into the server (physical or virtual) and take action if something is amiss.

By Hypervisor cluster above you mean the VM cluster?

Also you make references above to crashes in the VM  and the HyperVisor knowing. And earlier you state that the host cluster can't deal with:
OS failure, application failure, database corruption

 I am unclear how it would be that in any of the above circumstances why the fail-over wouldn't fail over to a VM that has the same problems - aren't the VM's in synch?

As far as types of servers that VM clustering can be used for, what about an AD server? I didn't list that. I know it might not be best/official practice but would it work at all?

You write:

"For failover clustering using VMs, each cluster will need its own dedicated access to cluster storage LUNs."

What do you mean by dedicated access?  Perhaps a 'picture' might help. Let us say I have two physical servers and I have two VM's that I want to failover cluster?  What will the storage look likein this situation? How many drives? How many ISCSI targets?






0
DaveCommented:
Are we talking VMWare or HYPERV clusters? With a VMWare cluster and HA  if a VMWare host fails the virtual machines will be restarted. If you are using Fault Tolerence then the two machines run in-step on separate hosts, but note Fault Tolerence only supports on CPU (i.e. core) per server.
0
kevinhsiehCommented:
When you use Windows HA clustering by VMs, it looks just like if you are doing it with physical machines. Each cluster requires a LUN for the disk quorum (if you are using an even number of nodes). The quorum disk LUN can be very small. Only the VMs participating in the cluster can access that LUN. Depending on what you are clustering, you may need additional LUNs for the data that the cluster is serving, such as for file servers and SQL servers.

You can not use Windows failover clustering for Active Directory. Use multiple domains controllers instead. You can run AD on a VM that is under hypervisor (host) clustering, because the VM has no idea that there is a clustering technology working at the more foundational virtualization layer. You anything you can cluster using physical servers you can cluster using multiple VMs.

0
lineonecorpAuthor Commented:
Sorry but I'm not understanding. I need something more specific.  Per my question I need a detailed example:

"Let us say I have two physical servers and I have two VM's - File Server, Terminal Server -  that I want to failover cluster?  What will the storage look like in this situation? How many drives? How many ISCSI targets?"  

So the File Server cluster requires a quorum LUN, let's call it LUN 1? Is this a dedicated ISCSI drive? Or just a partition on a dedicated ISCSI drive?

And the File Server cluster requires a separate  quorum LUN, let's call it LUN 2? Is this a dedicated ISCSI drive? Or just a partition on a dedicated ISCSI drive? Can an ISCSI drive host two quorum disks?  Or each quorum disk has to be  a separate physical drive?

As far as data for the cluster, do I need separate physical drives for the data for the File Server cluster and the data for the Terminal Server cluster? Or can I share a physical ISCSI drive with one partition for the File Server data and the other for the Terminal Server?

At the extremes could I just create one huge ISCSI drive with partition 1 for File Server quorum disk, partition 2 for for Terminal Server quorum disk, partition 3 for File Server data and partition 4 for Terminal Server data or do I need four separate physical drives to accomplish this?



0
kevinhsiehCommented:
What iSCSI storage are you using? What typically happens with storage is that you have a big pool, say 8 drives in a RAID10 that is 2.4 TB of storage (using 600 GB drives). You carve the 2.4 TB into LUNs. To the SAN, each LUN is like a virtual disk or partition. To the iSCSI client, each LUN looks like a separate disk. You can make LUNs of pretty much any size you want. Many systems allow you to grow them on the fly. LUNs generally don't have a direct relationship to physical drives.

Your file server cluster would require at least two iSCSI LUNs. A small 100 MB LUN can be used for the quorum, and then one or more larger LUNs to hold the actual files that are served by the file servers.

Each cluster needs its own set of LUNs.

Terminal servers are typically not used with Windows High Availability clustering, which generally only allows 1 active node at a time. Terminal server clusters don't share data.

Look at Using Terminal Server with Windows Load Balancing Service
http://support.microsoft.com/kb/243523/EN-US
0
lineonecorpAuthor Commented:
Thanks for the explanation - I am getting the picture.

You write:

"Each cluster needs its own set of LUNs."

So if I had two File Servers for some reason, each one would require two LUN's - one for the quorum and one for the data, a total of 4 LUN's that could reside on one physical ISCSI drive?

I don't have ISCSI setup yet - just looking at it. Do you have any recommendations?


0
kevinhsiehCommented:
If you have two file servers that are clustered together, that is 1 cluster. That single cluster will require at least 2 iSCSI LUNs. The LUN for the quorum is accessed by all nodes concurrently, while the LUNs holding files are owned and accessed by a single cluster node at a time.

To start getting experience with iSCSI, I would use the free Microsoft iSCSI Traget software.
http://www.microsoft.com/download/en/details.aspx?id=19867

For production that really depends on your requirements for availability, redudancy, support, performance, pricing, and advanced features.
0
lineonecorpAuthor Commented:
Thanks for the further info. What I was referring to was two different file servers I want clustered. For the sake of argument file server 1 has files that go from A-L and file server 2 has files that go from M-Z. So there are two clusters - File Server A-L and File Server M-Z. So in that case I need 4 LUN's on one physical ISCSI target?
0
kevinhsiehCommented:
A cluster requires that you have 2 or more machines making available the exact same service/files.

If Server1 has files A-L and Server2 has files M-Z, if you put them together you just have two file servers, and there is no cluster and no high availability.

If you want to have a cluster serving the A-L files, you need two file servers with the cluster service connected to the iSCSI LUN(s) that have the A-L files. Only one of the servers will actually be servicing file requests. The other server will be waiting to take over.

If you had files A-L and M-Z, there are two routes that you can take as I see it. You could put A-L and M-Z (two LUNs) onto the same file server cluster where one node at a time would service all of the requests. This is pretty reasonable because a single node can handle millions of files and many TB of data. You would need the 2 data LUNs and 1 quorum LUN, and at least two cluster nodes (I believe that you can have more than 2 nodes, but I am not sure if that makes any sense).

The second option is to have A-L on a pair of servers for cluster 1, and then M-Z on another pair of servers for cluster 2. This will require 4 servers and at least 4 LUNs.
0
lineonecorpAuthor Commented:
Thanks for your patient explanations.  

The second option is clear but as far as the first option let me explain back to see if I have the correct idea. I think you are saying that I would separate out files from system e.g. operating system files let's call it C so in effect I have one file server C drive that contains only OS with an A-L data drive attached to it and an M-Z data drive attached to it. I would then need one ISCSI physical device partitioned as follows:
one LUN for the system C drive
one LUN for the A-L data drive
one LUN for the M-Z data drive
one quorum LUN to allow clustering of the entire file server - C, A-L and M-Z - with another physical server

In this situation, if I understand it correctly, the entire file server is 'failed over' if there is a problem as opposed to option 2 where only one File Server would be failed over - the one that is having the problem?

If that's the case it's identical to host clustering in the situation where the file server VM's are the only VM's on the physical computer - yes?

0
kevinhsiehCommented:
Clustering at the VM level is different from clustering at the host level, but they complement each other.

Let's start with a single host HOSTA and two VMs that are clustered together. You would have VM1 and VM2, each with their own VHD stored on the host or on the iSCSI device. The VHDs can share the same storage. Windows Enterprise is installed on VM1 and VM2, and they have the Windows Failover Cluster role installed. VM1 and VM2 use the software iSCSI initiator to connect to three iSCSI LUNs, called LUN_A-L, LUN_M-Z, and LUN_QUORUM_VMS. The file shares are active on VM1, and say you want to patch VM1. You can failover the shares to VM2 with downtime of just a few seconds, and then you can patch and reboot VM1 with no issue. say that the shares are active on VM2 now, and VM2 blue screens for whatever reason. The shares will then fail over to VM1, and you should be back in business in maybe 30 seconds.

Let's say that HOSTA dies. Everything is now down.

Now let's add HOSTB into the mix. HOSTB is also running Windows 2008 R2 Enterprise/Datacenter or Hyper-V Server 2008 R2 and is clustered with HOSTA. The hosts are conencted to two LUNs, LUN_CSV (cluster shared volume, where the VHDs for the VMs are stored), and LUN_QUORUM_HOSTS. The VHDs for VM1 and VM2 are stored on C:\ClusterStorage\ClusterDisk1, which is readable and writeable by HOSTA and HOSTB at the same time. VM1 is currently running on HOSTA and VM2 is running on HOSTB. The way the VMs themselves are configured is identical to the single host model, with those same 3 LUNs, for there are now 5 LUNs total; 3 for the file server VM cluster, and 2 for the Hyper-V Host cluster.

Now, let's suppose that VM1 is active for the file share data and it is running on HOSTA, which crashes. Two failovers will then happen. First, VM2 will start serving the files, just like in the first case. Secondly, VM1 will get rebooted on HOSTB, because that is what happens to VMs when you cluster the hosts.

If you clustered the hosts but not the VMs, you would need to wait for VM1 to boot on HOSTB before the file shares became available again. Does this make sense?
0
lineonecorpAuthor Commented:
I will read through several times and get back to you if I have any further questions.
0
lineonecorpAuthor Commented:
Thanks for giving me the time to absorb this.  I think I understand the basic strategy.

At the end you write:  "Now, let's suppose that VM1 is active for the file share data and it is running on HOSTA, which crashes. Two failovers will then happen. First, VM2 will start serving the files, just like in the first case. Secondly, VM1 will get rebooted on HOSTB, because that is what happens to VMs when you cluster the hosts."

What I think you are saying is that with HOST A crashed, Host B is now running clustered VM's as in the single host situation with VM2 being the active VM and VM1 being the failover one. So in this case if for some reason VM2 bluescreened, VM1 would take over.


0
kevinhsiehCommented:
Yes, I think that is correct.
0
lineonecorpAuthor Commented:
Great.  Thanks for all the help.
0
lineonecorpAuthor Commented:
Excellent responses.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.