Clustering Hyper-V VM's

Hello Everyone,

If anyone has any suggestions to my problem below that would be greatly appreciated!

My Setup

Two hosts running Hyper-V and setup as a cluster. The hosts are tied back to a SAN using Fiber. I have two VM's (one running on each host) that I want to setup as a cluster to failover my DHCP service. It appears I need to configure a LUN for shared storage first before I can setup my service to failover except I'm can't figure out how to attach my LUN to a VM within a clustered host using hyper-v. I'm pretty sure I could do this if I was using iSCSI, but I'm pretty unfamiliar with how HBA / Fiber works.

Any suggestions?

Thanks,

Find more posts tagged with

Comments

hypnotoad

When you use live migration, the VHD file (and associated files) live on the LUN and are mounted through the failover clustering management tool in a method called Cluster Shared Volumes (CSVs). By default they mount to the virtual NTFS directory c:\clusterstorage. Live Migration requires that the architecture on both systems be pretty close to the same.

You can do this in iSCSI and FC. I prefer FC because its one less NIC to deal with.

This requires R2 by the way.

Zaits

hypnotoad wrote: »

When you use live migration, the VHD file (and associated files) live on the LUN and are mounted through the failover clustering management tool in a method called Cluster Shared Volumes (CSVs). By default they mount to the virtual NTFS directory c:\clusterstorage. Live Migration requires that the architecture on both systems be pretty close to the same.

You can do this in iSCSI and FC. I prefer FC because its one less NIC to deal with.

This requires R2 by the way.

My VM's are setup on the cluster in the manner you described, but I'm basically looking to create a cluster within a cluster to protect my VLAN from DHCP failing. The trouble I'm having is attaching my HBA LUN directly to both VM's (not the host) so I can configure failover clustering for my DHCP service.

Claymoore

Zaits wrote: »

I'm pretty sure I could do this if I was using iSCSI, but I'm pretty unfamiliar with how HBA / Fiber works.

Any suggestions?

Thanks,

You are correct that you can only create a Pass-Thru disk with iSCSI in Hyper-V.

I'm trying to understand the problem as well as your proposed solution. I understand that you want your DHCP service to be highly available. Is there a reason why Hyper-V live/quick migration isn't good enough? You could also create 2 DHCP servers and split the scope between them.

Zaits

Claymoore wrote: »

You are correct that you can only create a Pass-Thru disk with iSCSI in Hyper-V.

I'm trying to understand the problem as well as your proposed solution. I understand that you want your DHCP service to be highly available. Is there a reason why Hyper-V live/quick migration isn't good enough? You could also create 2 DHCP servers and split the scope between them.

Live / quick migration would save me if my host goes down but not if my VM goes down. My Provisioning servers rely heavily on scope options 66/67. If the DHCP services goes down I'm out of luck. Another problem I'm facing is due to the fact scope option 66 can only support one IP address. I need to purchase a load balancer or script something to change scope option 66 on the fly. Either way my original question was answered so thanks for your support!

erpadmin

Zaits wrote: »

Either way my original question was answered so thanks for your support!

Can you share what the answer was that you're going to be going with?

undomiel

I would go with Claymoore's suggestion of splitting DHCP between 2 servers as well.

Zaits

erpadmin wrote: »

Can you share what the answer was that you're going to be going with?

The answer wasn't really the one I wanted to hear, but it turns out you can only pass through iSCSI directly to a VM using Hyper-V. If someone has a suggestion how to connect using HBA please share your secrets

A split scope solution would work, but I'm not quite sure what the consequences would be if the servers fail over. Its something I'm going to have to test throughly.

MentholMoose

A split scope setup is active-active; both servers assign IP addresses from a pool, but different ranges of the pool controlled using exclusions. For example on both servers you have the scope 192.168.1.0/24, with a pool containing addresses 192.168.1.101-200. On server 1 you exclude 192.168.1.151-200 (so it assigns 101-150), and on server 2 you exclude 192.168.1.101-150 (it assigns 151-200).

Since both servers are active, when clients send DHCP requests, the fastest server to respond will assign the IP address. If that server goes down, when clients try to renew the other server will respond and assign a new address from it's own range of the pool. The main problem with this is address exhaustion. If in the above example server 1 has 50 active leases when server 2 goes down, server 1 won't assign any addresses to clients that had been serviced by server 2. This issue doesn't matter during scheduled maintenance since you can temporarily delete the exclusions beforehand. But for an unplanned outage you will have to delete the exclusion manually, or setup some process to do it. Basically you will want to avoid this altogether, so just ensure that the leases don't max out by making the pools larger that otherwise would be necessary.

The DHCP Server in 2008 R2 now has a split scope feature built-in. You setup two DHCP Servers, one primary and one backup. The backup is configured to delay responding to DHCP clients so that only the primary issues addresses under normal circumstances. That way, when the primary goes down, the backup (probably) has no existing leases and has enough addresses to assign during the outage. Therefore you can make the pools somewhat smaller than with previous versions.

If you want to save some Windows licenses and get even better failover functionality, consider setting up ISC DHCP on Linux. It has failover built-in. The servers communicate with each other during normal operation so they know about each other's active leases, and if one goes down the other will take over all the leases. This has the advantage that all clients will keep their IP addresses during an outage. Another advantage is that a typical Linux server almost never needs to be rebooted. Basically you only reboot it for kernel upgrades, and you only update the kernel if it's absolutely necessary (mainly remote security or DOS issues, which are rare). For a critical infrastructure service like DHCP, it is nice to not have to bring it down all the time for patches. At my work we have quite a lot of DHCP clients and want to avoid downtime and hassle, so our DHCP servers are on Linux and have 1+ years uptime... I work at a residential college, so each student seriously may have a desktop, laptop, iPad, iPod Touch, iPhone, Xbox 360, Wii, PS3, Slingbox, and more.