bridge or subnet connection to HA site ?

[stormlight]

Hello, we are starting to setup our HA site. We will be replicating some of or Vms to this site via Vision core vreplicator. Can someone tell me is it better to bridge the HA site or to have it be on its own subnet and have a differant AD site.

The only benifit i can see of bridging it is that when the replicated vms come up for some reason I wont need to change ip settings on these vms. Can anyone think of another reason to bridge over to subnet? I was thinking that subnetting it would be better to be able to controll replication of AD as well as what dc the user logs into.

thanks

[bradley4681]

This is more of a decision to be determined in your DR strategy. It appears you already know the differences between the two, so there's no real best practices reason to do one over the other. It's more about how fast you need your HA site to come up, and seeing how your calling it a HA site and not a DR site i would assume you need it to come up fast. Most of the DR sites using VMware i've seen have replicated the network subnet's so that there is no need to reconfigure to bring up the machines. You also have to think about your application and whether there is anything pointing to them by IP, which developers tend to do in a rush even though its not best practices.

Cheers,

Bradley Sessions

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

[stormlight]

Thank you. I did mean DR site. Not sure why I was thinking HA.

Even though I meant DR originally, can anyone confirm my concerns about bridging the site and people logging on to the DC in the remote site instead of the local and other problem like that.

thanks

[bradley4681]

Just replicate them but leave them powered off at the DR site until they are needed. Then all you have to do is log into the ESX boxes, or VC and turn on the guest. They'll power up and be ready to take over for the down or missing boxes without any need to reconfigure anything since they would have the same network and settings.

Cheers,

Bradley Sessions

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

[stormlight]

our dcs will not be virtualized and replicated. So we will have to put a dc on the other side and need it to be current with the dcs on the primary in case the promary where to go down. Is there a way to direct people not to use that dc if it is on the same subnet and have that dc always on

[bradley4681]

you could create a new subnet just for the DC's that will be at the DR site and then keep the users from using that in AD.

Cheers,

Bradley Sessions

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

[kjb007]

You should be able to setup different sites in AD Sites & Services and select which machines and users authenticate to which dc.

Good luck.

-KjB

[stormlight]

I must be missing something very basic here.

From what I read sites and services are based on different subnets. So if part of defining a site to control authentication is assigning it a differant subnet

There is no option for a bridge because a bridge joins two network that are in the same subnet

[MarkBK]

I think what was meant was that you should put your servers that are running on their own subnet at the DR site and define that in AD. Only bridge the subnet for the servers that you are replicating with vReplicator--which are left powered off.

So at least two subnets at the DR site. One bridged and one not.

[stormlight]

ah thanks. I didn't know you could choose to bridge one subnet and not the other on the DR side.

Can I ask generically, no real specifics as i need to do the research myself. How would you bridge the replicated vms only without bridging the DC as well.

How can you have 1 bridged and 1 not.

Are you implying two physical data connections or some type of vlan over VPN that goes back to the primary site?

[MarkBK]

Well I am not a network guy so maybe I did not state it clearly. If the networks are bridged then they are bridged. You only need one physical connection.

Any vLan (subnet) that you define will be available on both sides of the bridge. However, if you only put your Remote AD controller in the DR subnet then traffic won't go there from the other side if you configured AD to tell the clients to use the local DC.

AD does not know about the bridge. Right?

Your replicated VMs will try to use their normal AD domain controller when they come up, but if it down they will use the other one.

[bradley4681]

Let me see if I can make this a little clearer, but your going to need to talk with an actual network guy for the specific commands and config. Your going to need to bridge the two sites somehow which is basically going to connect the two sites networks. Now at the new site you can create a vlan for your new dc's and esx hosts there, but your also going to create the same VLAN's that you have for the servers you want to replicate. Now on the primary side in your router/switch device your going to make the network/routing tables/etc aware of the new vlan across the bridge but your also going to be trunking the existing VLANs across the bridge so that they are available when you need to turn your replicated machines on.

Cheers,

Bradley Sessions

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

[bradley4681]

Also to point out I suppose we're confusing bridging with just connecting the sites. You could bring them with a site to site vpn and tunnel everything over, or you could just get a connection from your provider that links a router at the primary to a router or switch at the secondary. That connection could be MPLS, DSL, Cable, whatever your flavor but an experienced network guy and/or your provider should be able to help you with this, its a pretty common setup.

Cheers,

Bradley Sessions

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

[stormlight]

thanks.. i think that's where my confusion was at

I thought

bridge = Primary site 1 and DR site 2 = the same subnet.

sites = Primary site = 172.16.1.x DR site = 192.16.1.x (notice dif subnet)

but in fact the bridge is just the connection and differant subnet's are fine if you are routing/Vlaning correctly between the two.

thanks

[stumpr]

One challenge you may have with bridging the sites (assuming you're using 802.1Q tunneling) is the mac addresses of your replicated VMs will, well, be replicated. You may end up seeing duplicate MACs, triggering STP, etc. Though you can address this by regenerating MACs for your VMs with a script or flushing your mac address tables on your network switches. You may have some performance issues if you have some heavy L2 traffic if you run with both sites active.

It is possible to use the same IP subnet at both sites, but you'll have to use L3 switches. You defined the DR site with a higher routing weight for the same network (so its effectively disabled while your primary site network is active). The VLAN interface in the DR site remains shutdown. When you "flip" you will disable the primary site's VLAN interface, turn on the secondary site's interface and the weighted, DR route should now take precedence. Obviously this will work best with dynamic routing protocols.

The VLAN is all or nothing, so you may have to redesign your network to separate 'protected' VMs and non-protected VMs (and physical hosts). You will also need to be doing quiescent snapshots of your VMs if you care about data consistency. You really need a well designed core network to make this work.

If you do different subnets you have to deal with all the IP/DNS remaps. I believe Site Manager from VMware will do re-iping for you, but haven't had a chance to see it in use yet. If you have two active subnets though, you can run a test/dev environment on your vmware hosts while you're not in failover mode. Helps justify the cost of idle hosts.