The VS192 2-Port 4K DisplayPort Splitter is perfect for anyone who needs to send one source of DisplayPort high definition video to two or four DisplayPort displays. The VS192 can split and also expand DisplayPort audio/video signal on two or four DisplayPort monitors.
Solved
Hyper-V DAS to SAN Solution Topology Questions - High Availability?
Posted on 2011-09-16
I am new to using SAN and expanding our environment and have several questions. We just installed an EMC VNXe 3100 with 12 disk SAN in our environment. I want to convert our single Hyper-V server with DAS to a two-server high availability solution using the SAN. All servers are HP DL360 G5. After my redesign I will have 3 of the same servers to use as I wish with Hyper-V and Windows Server 2008 R2 Enterprise, but for right now I only have plans for the two. All servers have two NICs with teaming. In short, what is the best way to leverage the hardware? Here are several subset questions:
Should I install another PCIe Teamed NIC to separate the SAN traffic? More than that needed?
Should the SAN traffic be on its own switch and/or subnet? Managed or unmanaged matter much here?
How should Server 2008 R2/Hyper-V be configured for high availability of all virtual machines? Failover clustering, other options?
Thank you in advance!
-Matt
Should I install another PCIe Teamed NIC to separate the SAN traffic? More than that needed?
Should the SAN traffic be on its own switch and/or subnet? Managed or unmanaged matter much here?
How should Server 2008 R2/Hyper-V be configured for high availability of all virtual machines? Failover clustering, other options?
Thank you in advance!
-Matt
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2
3 Comments
Hi Matt,
That's a lot of questions :)
If you want to implement Hyper-V, it advisable to have a second NIC team to secure your access to the storage. But you must bear in mind that Microsoft does not support NIC teaming for iSCSI access. Hardware vendors do support it though.
Instead of teaming you could also implement MPIO (multipath) to ensure redundancy in the access to your storage. It is very import to have redundant access to iSCSI storage.
It is also important to isolate your iSCSI traffic it should not be sharing the same subnet as the private heartbeat or the public network. So yes, implement your servers with isolated iSCSI network. Also note that once the Hyper-V cluster is built you will be able to see the iSCSI network from the failover clustering console. You'll have to right click this network in this console and then access to its properties. From the properties, specify that you do not want this network being used for the cluster traffic...
Regarding your Hyper-V cluster architecture:
1. Present the iSCSI storage to the servers (at least 2 LUN, one small as witness disk and one big for the VM storage)
2. Once the storage is accessible then format it in NTFS using GPT format (to be able to have disk bigger than 2 To)
3. Install the failover clustering feature on both nodes
4. Access to the failover console and validate the cluster you want to build. You will generate a validation report showing the different problem impacting your cluster implementation (there is often warning, check them but you can often install the cluster even with warnings in the validation reports. Though if you see failures then it is fundamental not to implement the cluster without solving it)
5. Build the cluster from the clustering management console
6. Once the cluster is build you will see the cluster node (with the name of your cluster) in the right pane of your clustering management console. Please right click on it and select "Enable cluster shared volume". You will then have to choose which volume you want to use as CSV. After its creation, the CSV volume will be seen from the Hyper-V machine as a directory c:\clusterstorage\volume..
You will have to place your VM on this volume to be able to run VMs from both nodes.
CSV will allow both nodes to access the same LUN at the same time (without CSV you would have disk level access and you would need to build a LUN per VM to be able to run the VM from both hosts).
You'll find more information there:
http://blogs.technet.com/b/pfe-ireland/archive/2008/05/16/how-to-create-a-windows-server-2008-cluster-within-hyper-v-using-simulated-iscsi-storage.aspx
http://blogs.msdn.com/b/clustering/archive/2008/01/18/7151154.aspx
I hope my answer is clear enough.
That's a lot of questions :)
If you want to implement Hyper-V, it advisable to have a second NIC team to secure your access to the storage. But you must bear in mind that Microsoft does not support NIC teaming for iSCSI access. Hardware vendors do support it though.
Instead of teaming you could also implement MPIO (multipath) to ensure redundancy in the access to your storage. It is very import to have redundant access to iSCSI storage.
It is also important to isolate your iSCSI traffic it should not be sharing the same subnet as the private heartbeat or the public network. So yes, implement your servers with isolated iSCSI network. Also note that once the Hyper-V cluster is built you will be able to see the iSCSI network from the failover clustering console. You'll have to right click this network in this console and then access to its properties. From the properties, specify that you do not want this network being used for the cluster traffic...
Regarding your Hyper-V cluster architecture:
1. Present the iSCSI storage to the servers (at least 2 LUN, one small as witness disk and one big for the VM storage)
2. Once the storage is accessible then format it in NTFS using GPT format (to be able to have disk bigger than 2 To)
3. Install the failover clustering feature on both nodes
4. Access to the failover console and validate the cluster you want to build. You will generate a validation report showing the different problem impacting your cluster implementation (there is often warning, check them but you can often install the cluster even with warnings in the validation reports. Though if you see failures then it is fundamental not to implement the cluster without solving it)
5. Build the cluster from the clustering management console
6. Once the cluster is build you will see the cluster node (with the name of your cluster) in the right pane of your clustering management console. Please right click on it and select "Enable cluster shared volume". You will then have to choose which volume you want to use as CSV. After its creation, the CSV volume will be seen from the Hyper-V machine as a directory c:\clusterstorage\volume..
You will have to place your VM on this volume to be able to run VMs from both nodes.
CSV will allow both nodes to access the same LUN at the same time (without CSV you would have disk level access and you would need to build a LUN per VM to be able to run the VM from both hosts).
You'll find more information there:
http://blogs.technet.com/b/pfe-ireland/archive/2008/05/16/how-to-create-a-windows-server-2008-cluster-within-hyper-v-using-simulated-iscsi-storage.aspx
http://blogs.msdn.com/b/clustering/archive/2008/01/18/7151154.aspx
I hope my answer is clear enough.
Ok thank you for your thorough answer. In regards to the heartbeat connection.. do I need 6 NICs in each server to accomplish this?
2 NICs for iSCSI multi=path
2 NICS for Teamed LAN Access
and at least 1 NIC for heart beat?
and as far as the witness disk... that should be a small iSCSI volume on the SAN, yes?
2 NICs for iSCSI multi=path
2 NICS for Teamed LAN Access
and at least 1 NIC for heart beat?
and as far as the witness disk... that should be a small iSCSI volume on the SAN, yes?
Hi Njmatt,
Sorry for the delay I didn't see your feedback before.
This article is about networking configuration in a hyper-v cluster:
http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx
Regarding the NIC for heartbeat, it should be fine if you configure the cluster to be able to use the public network in case of a problem with the heartbeat network. This is the default configuration anyway, the cluster would redirect its heartbeat traffic through the public interface if heartbeat network is down.
Regarding the witness disk it does not need to be big:
http://technet.microsoft.com/en-us/library/cc770620(WS.10).aspx
Specifically this section:
"Use a small Logical Unit Number (LUN) that is at least 512 MB in size."
I would use a witness disk of 1 or 2 Go to be sure to avoid problems...
Let me know if you have other questions.
Sorry for the delay I didn't see your feedback before.
This article is about networking configuration in a hyper-v cluster:
http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx
Regarding the NIC for heartbeat, it should be fine if you configure the cluster to be able to use the public network in case of a problem with the heartbeat network. This is the default configuration anyway, the cluster would redirect its heartbeat traffic through the public interface if heartbeat network is down.
Regarding the witness disk it does not need to be big:
http://technet.microsoft.com/en-us/library/cc770620(WS.10).aspx
Specifically this section:
"Use a small Logical Unit Number (LUN) that is at least 512 MB in size."
I would use a witness disk of 1 or 2 Go to be sure to avoid problems...
Let me know if you have other questions.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Data center, now-a-days, is referred as the home of all the advanced technologies. In-fact, most of the businesses are now establishing their entire organizational structure around the IT capabilities.
Finding original email is quite difficult due to their duplicates. From this article, you will come to know why multiple duplicates of same emails appear and how to delete duplicate emails from Outlook securely and instantly while vital emails remai…
This tutorial will walk an individual through the process of installing the necessary services and then configuring a Windows Server 2012 system as an iSCSI target.
To install the necessary roles, go to Server Manager, and select Add Roles and Featu…
In this video, Percona Director of Solution Engineering Jon Tobin discusses the function and features of Percona Server for MongoDB.
How Percona can help
Percona can help you determine if Percona Server for MongoDB is the right solution for …
Suggested Courses
Course of the Month4 days, 19 hours left to enroll
670 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.