How to maximize redundancy and flexibility with Hyper-V Server on two physical boxes?
- I have two identical Dell PowerEdge 2950s, each with a PERC5 RAID controller and plenty of disk space -- at present they're full of 500GB SATA drives (six per machine) but I could switch over to SAS if needed. I will be hosting around 4 virtual machines, all of them low resource usage. They can get by with <2GB of memory each, they aren't CPU intensive, and each is around 100GB in disk storage.My question is, with this limited amount of hardware, how can I take advantage of some of the high availability functionality available in Hyper-V Server R2?Specifically, is it possible on this hardware to run all 4 VMs on just one of the two servers, but with the ability to shift one or more of the VMs over to the second server with minimal downtime (a few minutes is OK; even a reboot would be fine; however, shutting down and copying the 100GB VHD over the network would take too long)?From what I've read, in order to accomplish this using Quick Migration, Live Migration, Quick Storage Migration, etc. I would have to be running in a clustered environment with shared storage. My understanding is that an entry level "shared storage" device that would have full redundancy would set me back thousands of dollars (easily $10k).I've seen plenty of documentation for these "enterprise grade" setups. I'm wondering how far I can push it with just two boxes.(Again, to reiterate, the resource usage of all of my VMs is expected to be very low -- the key thing I'm trying to understand is how I can shift disks over the network without having to copy the full set of data every time.)Lastly, I *can* simulate what I want to do here with Virtual Server 2005, though in a very manual fashion:1. Shut the VM down.2. Enable differencing disks and boot it back up.3. Copy the main VHD file over the network to the new server (may take hours).4. Shut the VM down again.5. Copy the difference file(s) over the network to the new server (will only take seconds or minutes).6. Boot the VM on the new server.In the above scenario, while it might take several hours from the time I decide I want to migrate to to the time I'm finished, my downtime is only a few minutes -- bound by the amount of time it takes to copy just the *differences* over the network (plus two reboots).Thanks in advance for any advice.Adam Swann
Answers
- I would caution against using a generic iSCSI target for clustering in a production environment. If you do so, you have just moved your single point of failure away from your Hyper-V host servers and made the the single point of failure the server that is hosting your storage. I blogged about this very issue here...
http://clusteringformeremortals.wordpress.com/2009/08/26/you-are-the-weakest-link-goodbye/
You can create a a clustered Hyper-V environment without shared storage by using a host based replication solution such as SteelEye DataKeeper Cluster Edition and Windows Server Failover Clustering. This configuration gives you all the same benefits of single copy clustering (Live Migration, Quick MIgration, Automatic Failover) but has the added benefit of removing shared storage as a single point of failure. Here is a video demonstration of the solution.
http://www.steeleye.com/downloads/videos/datakeeper-and-hyper-v-wsfc/index.html
If you are interested, request more information here and I will be glad to discuss the solution with you.
David A. Bermingham, Director of Product Management, SteelEye Technology- Proposed As Answer byDavid Bermingham Friday, September 18, 2009 11:14 PM
- Marked As Answer byVincent HuMSFT, ModeratorFriday, November 20, 2009 6:53 AM
All Replies
Hi,
To be honest, it’s hard to achieve your goal.
If you want to maximize redundancy and flexibility with Hyper-V Server on two physical boxes, the method should be Hyper-V Failover Cluster. However, this need a storage device to keep the VMs.
Based on your current environment, you can only set redundancy and flexibility on VM level, not Hyper-V host level. You can perform the following steps:
1. Install iSCSI target software on one of your physical computer
2. Create a target for the second physical computer and then add storage for it.
3. Configure iSCSI imitator on the second physical computer.
4. Create two VMs.
5. Configure failover cluster inside the two VMs using the storage on the first physical computer.
If you want to set redundancy and flexibility on Hyper-V host level, you don’t have two buy a dedicate storage for VMs if you are out of budget. If you buy another computer with plenty of disk space. Install iSCSI target software on this machine and then configure this machine as a storage device, you can configure RAID 5 or RAID 10 for disk redundancy.(It will be much cheaper than a dedicate storage device) Now you can configure Hyper-V Failover Cluster between the first two Hyper-V host machine.
For more information about Hyper-V Failover Cluster, you can refer to :
Hyper-V: Using Hyper-V and Failover Clustering
http://technet.microsoft.com/en-us/library/cc732181(WS.10).aspx
Step-by-Step Guide for Testing Hyper-V and Failover Clustering
http://h20341.www2.hp.com/ERC/downloads/4AA2-2983ENW.pdf
In addition, there are some iSCSI target software you can use, for your convenience, I have list the related link as followed.
MySAN iSCSI Server Software
http://www.nimbusdata.com/products/mysan.php
StarWind iSCSI Target
http://www.starwindsoftware.com/
NOTE: This response contains a reference to a third party World Wide Web site. Microsoft can make no representation concerning the content of these sites. Microsoft is providing this information only as a convenience to you: this is to inform you that Microsoft has not tested any software or information found on these sites and therefore cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software on the Internet.
Vincent Hu
- I would caution against using a generic iSCSI target for clustering in a production environment. If you do so, you have just moved your single point of failure away from your Hyper-V host servers and made the the single point of failure the server that is hosting your storage. I blogged about this very issue here...
http://clusteringformeremortals.wordpress.com/2009/08/26/you-are-the-weakest-link-goodbye/
You can create a a clustered Hyper-V environment without shared storage by using a host based replication solution such as SteelEye DataKeeper Cluster Edition and Windows Server Failover Clustering. This configuration gives you all the same benefits of single copy clustering (Live Migration, Quick MIgration, Automatic Failover) but has the added benefit of removing shared storage as a single point of failure. Here is a video demonstration of the solution.
http://www.steeleye.com/downloads/videos/datakeeper-and-hyper-v-wsfc/index.html
If you are interested, request more information here and I will be glad to discuss the solution with you.
David A. Bermingham, Director of Product Management, SteelEye Technology- Proposed As Answer byDavid Bermingham Friday, September 18, 2009 11:14 PM
- Marked As Answer byVincent HuMSFT, ModeratorFriday, November 20, 2009 6:53 AM
- Hello,
The best-out of box way to accomplish high availability is with Live Migration / Failover Clustering. That said, if you're looking to accomplish basic recoverability with only two boxes, you could consider a nightly backup process from one host machine to another. I've done this for companies who are basically running their small network on one host, but want their machines to be bootable off another host machine in a disaster scenario. Windows Server Backup does this well, as it can target a network share. Obviously a real-time replication solution is a far better solution than this, but if you're looking to do something out of box, I'd check this out.
Thanks,
Nathan Lasnoski- Proposed As Answer byNathan Lasnoski Saturday, September 19, 2009 1:00 PM
- Any thoughts on whether these two solutions are helping you?
- I am looking at an almost identical situation. I was thinking about putting a virtual SAN server in each host with their own HA, so all data should automatically be replicated, and any VM on either host could theoretically see that data no matter what. Is anyone else doing this in a production environment? Which SAN software is being used to do this? Is there any way in such a setup to make sure that all the VMs running in a single host access the storage VM in the same host instead of going over the wire to the other one if possible?
Thanks.
---H If you were leaning towards purchasing an inexpensive box with lots of storage to run an iSCSI target, that would just move your single point of failure from your servers to your SAN. But you could purchase TWO inexpensive boxes and set them to replicate with one another.
Also, not sure what you have running on those VM's, but maybe the VM's themselves have some replication technology that you can take advantage of by creating additional (rather than duplicate) VM's on your second server. I guess you could think of it as role or service-level redundancy. For example, if one of your VM's is a domain controller, you could just run another domain controller on your 2nd host, they would replicate the AD info even though they would not necessarily be duplicate copies of one another. If one went down, the other one could take over.Not sure of any virtual SAN solution that will run in an Active/Active configuration like that. You may just need to set up two Active/Passive pairs; although I don't think you could guarantee that any one VM would always be using the local SAN.
The alternative is to skip the whole virtual SAN solution and just use a WSFC integrated host based replication, such as SteelEye DataKeeper, in a multi-site cluster configuration. Multi-site is really a misnomer as the nodes do not have to be in seperate sites; it just really means that the storage is replicated so there is no need for a SAN. This configuration guarantees the VM is always accessing the local attached storage and removes the extra layer of the virtual SAN so that the VM has direct access to the storage on the server.
We have customers who would be glad to speak with you regarding their experience if you contact us through www.steeleye.com
David A. Bermingham, Director of Product Management, SteelEye Technology- Edited byDavid Bermingham Thursday, November 19, 2009 8:34 PMtypo
The alternative is to skip the whole virtual SAN solution and just use a WSFC integrated host based replication, such as SteelEye DataKeeper , in a multi-site cluster configuration. Multi-site is really a misnomer as the nodes do not have to be in seperate sites; it just really means that the storage is replicated so there is no need for a SAN. This configuration guarantees the VM is always accessing the local attached storage and removes the extra layer of the virtual SAN so that the VM has direct access to the storage on the server.
Interesting. Can both nodes still be used for different workloads while backing each other up in such a configuration?- Yes, just as you would in a regular shared storage cluster.
David A. Bermingham, Director of Product Management, SteelEye Technology
