Improve company productivity with a Business Account.Sign Up


2 server rooms on one "site" or 2 sites

Posted on 2013-01-27
Medium Priority
Last Modified: 2013-02-20
Hi, sorry for the vague title.

I have inherited a setup where we have a single site with 2 server rooms. This is good; dual core, dual fabric san, etc nearly everything is replicated however moving forward - new SAN and hypervisor we need to decide whether we are going to treat each server room as a separate site. As far as I see it:

1 Site:
+ storage available to both server rooms
+ easy to live migrate VMs
- difficult to determine what is running where
- can be a challenge to manage

2 Sites
+ you know what service/server is running in each
+ theoretically easier management
- how to live migrate vms between clusters
- more thought required when planning clustered services

We would be looking at an active/active setup, hence the difficultly in deciding.

Any thoughts? We're going Hyper V 2012 btw.

Question by:gmbaxter
  • 4
  • 3
  • 2
  • +2
LVL 23

Assisted Solution

by:Ayman Bakr
Ayman Bakr earned 200 total points
ID: 38824499
Usually when thinking of a different site, you are thinking of distances, disaster recovery, branch offices etc...

With the factors you have put forth in your question you still can have ease of management in one site if for example you had a naming convention that will allow you to determine in what room your server is in, and what is running on what.

I would really think of creating a second site when I am concerned with WAN speed connections, management of different resources (departments in different sites/branch offices) or disaster recovery (two sites close to each other is not a good disaster recovery strategy)!
LVL 126
ID: 38824518
normally you would considered two seperate sites if the Server Rooms are in different buildings, at least 6km apart.

If you had a disaster in your case both servers room would be out of action, fire, flood, explosion, hurricane etc

But you can easily use Hyper-V 2012 to replicate VMs between servers and storage.
LVL 10

Assisted Solution

millardjk earned 200 total points
ID: 38826538
As long as the two rooms are connected by high speed networks, what difference does it make whether they're 10m or 10km apart when dealing with virtual resources? That's half the beauty of virtualization: it doesn't matter whether you can touch the host or it's half a world away: it's all remote access.

Use good naming practices on the physical gear to make it obvious at a glance which room is being addressed (for managing the physical side, like blown hard drives), and treat the virtual resources as independent: ignore their physical location.

However, if you have sufficiently high latency that there is a distinct difference between the experience of running out of one space versus the other, then by all means, treat them as geographically different sites--even if they're only separated by 10cm!
NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

LVL 10

Expert Comment

ID: 38827858
I "third" the opinion..  There is NO NEED to create a second site, unless you have a slow or unreliable link in between 2 locations.. It's just not worth the headaches, unless you have some other strange reason to create a site...  I have 2 data centers that are in different states, but we have fiber directly between them w/ multi-gig speed and 2ms latency, and  I have those in the same site, and support 30k users out of them, and have no problems at all, even for (or maybe ESPECIALLY FOR) Exchange replication..

I have had to create separate sites when:
1:  Management demanded that the users and Exchange servers use separate DCs to authenticate, so we were forced to create an "Exchange site" which was eventually done away with because there was no benefit, and a lot of added replication complexity and extra DCs.
2:  During an Exchange migration we had a strange need to proxy external OWA, and the CAS servers wont proxy to another CAS Server unless they think they're in a different site, so I had new DCs built and put host addresses (/32) in the separate site to force 2 specific CAS servers to THINK they're in a different site so they'd proxy instead of redirect..  This was a total kludge created by some security requirements and the certificates/URLs we were forced to use, and was ONLY for the duration of the migration..

Aside from that, ALWAYS make one site unless you can prove a need otherwise..  You'll be happier in the end!!
LVL 11

Author Comment

ID: 38829070
I have a 10gb ip data network and an 8gb SAN data network, so latency and bandwidth are fine.

I've been looking at Hyper V 2012 multi-site clusters with the idea that site 1 replicates to site 2 and site 2 replicates to site 1, as both have active resources within them, however I can't figure out the storage setup for this. How does each site know when the other has failed to turn the replica storage into active?

I agree 1 site is easier to manage, but with that I can have VMs running on a san from either location with no logical separation.
LVL 10

Assisted Solution

172pilotSteve earned 400 total points
ID: 38829708
I might have to bow out on that one - I've got a lot more VMWare experience than any recent version of HyoerV, but I'd take a look at what they offer, and I'd be surprised if what you're needing is a different AD Site to make it do what you're trying to do.  I know in particular with VMWare, the failover options you have within a cluster are a lot better than those which you have when you're talking about poorly connected systems in different "sites" (meaning in this case not a physical site, but more of what AD considers a site..

I guess my point is that although you might have found a feature that Microsoft is proud of in regard to what they can do with a remote, far-away data center, there's almost certainly BETTER functionality for local, well-connected standby systems, and it may be that it is only because the marketing department is more proud of their new "remote" features that they're more boldly advertised.

I'm also not sure if "site" in a HyperV terminology is the same as an AD "site".  I would hope that it is, because both products are Microsoft, but dont assume that.

Now - Just from a generic point of view, for the storage, you will likely need off-box storage, such as a SAN (Fiber Channel or iSCSI for example) that can be used by both hosts.  In otherwords, if "host 1" in site 1 has a VM on a locally connected volume, it makes no sense that in the case of a failure of host 1, that any other host in another datacenter (or even in a the same datacenter, for that matter) would have access to that locally attached volume.

In the case of VMWare, the hosts have a communication network betwen each other, used like a "heartbeat" and they decide between each other which host is going to mount and run the VM.  

In the case of a host failure, the heartbeat of the active node will stop responding, and the standby node will start the VM.  

SO..  If your datacenter is remote, you'll need to make sure the storage is available over the WAN.  Usually a WAN is too slow to run the VM on the far-side storage, plus if the whole site is down, having a remote host to run a VM on a dead SAN doesn't do much good, so usually you rely on a SAN-centric mirroring technology to do an asynchronous, but as close to real-time as possible mirroring of the SAN to another SAN at the remote location.  Usually since the network is potentially susceptible to failure too, you wouldn't  auto-start a remote replica when the heartbeat fails because you might have lost connection because the WAN went down, NOT the remote host, and therefore bringing up a second replica of the same server would probably cause problems when the WAN comes back up, since it's no longer clear which server has the "correct" version of any data on the server.  

For this reason, if the two nodes aren't local to each other, usually the failover mechanism isn't automatic, and relies on the administrator to make the determination that it's worth bringing up the remote copies of the servers.  Note that since it's in a remote location, usually that means doing IP Address changes too, waiting for DNS cache timeouts, etc. so it's not a decision made lightly.

I hope these concepts help - I know it's more general than Hyper-V specific, and doesn't really answer the question of the different sites, but it seems to be more where you were going with this..??
LVL 11

Author Comment

ID: 38856217
Thanks for the input.

By "Site", I'm trying to establish as to whether we should do a multi-site cluster of hyper V (basically 2 clusters, 2 sans with san replication) or just group all nodes into one well-named and documented cluster for ease of management.

System Center VMM will allow us to manage the two clusters as a multi-site cluster, but automatic failover will still depend on us breaking the san lun mirroring.

We could also look at "live" volumes where the SANs decide which SAN holds the RW copy of a particular lun, but this may introduce split brain nightmares.

If i try to clarify my question:

Considering two equal server rooms on a single site with 10gb data and 8Gb fibre (SAN) links which appear to have been designed for active/active operation, should my new virtualised environment based on hyper v 2012 be configured as one cluster per server room, or a large cluster which spans both server rooms?

LVL 126

Assisted Solution

by:Andrew Hancock (VMware vExpert / EE MVE^2)
Andrew Hancock (VMware vExpert / EE MVE^2) earned 200 total points
ID: 38856443
large cluster which spans both server rooms.
LVL 10

Accepted Solution

172pilotSteve earned 400 total points
ID: 38857813
I agree -  There's no sense putting two SANs next to each other, and then not being able to fail over without breaking the replication..  Let both [sets of] hosts share the same multi-access SAN, and fail over directly, and if you want to protect the SAN, that's fine, but dont make it hard on yourself artificially to fail over regularly.  You'll want to fail over for hardware upgrades and maintanence, patching, etc.. and to require breaking the replication of the SAN and then re-seeding it somehow (probably replicating the opposite direction) would be more work than you need to do..
LVL 11

Author Comment

ID: 38911443
Thanks everyone for your input.

We're going with one large cluster and single site with GOOD documentation and naming on cluster nodes, luns, etc purely for the ease of management and failover etc.
LVL 11

Author Closing Comment

ID: 38911466
Thanks for the opinions.

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

In this article will go through how to backup a vPostgres DB from a broken vCenter Appliance and restore to a new vCenter Appliance.
Virtualization software lets you run different versions of Windows, Ubuntu Linux and other versions of Linux all at the same time, rather than running each one directly from your computer's hard drive.
This Micro Tutorial will teach you how to reformat your flash drive. Sometimes your flash drive may have issues carrying files so this will completely restore it to manufacturing settings. Make sure to backup all files before reformatting. This w…
NetCrunch network monitor is a highly extensive platform for network monitoring and alert generation. In this video you'll see a live demo of NetCrunch with most notable features explained in a walk-through manner. You'll also get to know the philos…

606 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question