Cross Site Dag subnet question (Full Version)

All Forums >> [Microsoft Exchange 2010] >> High Availability



Message


hiten@ipsgroup.co.uk -> Cross Site Dag subnet question (28.Jun.2011 7:52:02 AM)

Hi,
we currently have a virtualized exchange 2010 environment consisting of the following
1  x Virtual DC - AD/DNS
1x Virtual MBX - mailbox only with 5 DB's
1 x Virtual CAS/HUB - CAS HUB.
they are all located a data centre on their own subnet. ( 10.1.0.0 / 24)
We would like to set up disaster recovery for the above on a single server within our office (CAS/HUB/MBX all on one box) which is on a different subnet 10.0.0.0/24.
and the two sites are connected via a managed MPLS network.
I am getting slightly confused on the networking, reading the forums and articles it says you cannot replicate over the MAPI network so therefore you need a different subnet for replication. if this is the case then I would end up with 4 subnets? (2 subnets in the data centre and 2 subnets in our office)
Is it possible to do this with the current set up of 2 subnets (1 subnet in the data centre and 1 subnet in the office) and then just set replication to go via a certain IP address?
EG.
In the data centre we have virtual mailbox with ip address 10.1.0.10 can we add another NIC to this server and give it IP address 10.1.0.11 (for replication)
In the office for DR we have 1 physical server running MBX/CAS/HUB which has ip address 10.0.0.10 and also a secondary nic with address 10.0.0.11
Would this set up be possible so replication occurs via 10.1.0.11 (data centre) to 10.0.0.11 (DR server in the office)

And the final question is when you assign an ip address to the DAG what subnet ip addresses do you give it? a 10.1.0.x address or a 10.0.0.x address?

Many Thanks

Hiten




mark@mvps.org -> RE: Cross Site Dag subnet question (28.Jun.2011 8:01:01 AM)

Assign it whatever you want. The entire network stack is abstracted from the cluster.
So long as the networks that you designate as the DAG network (if you even do that which in your case is probably marginal) can 'see' and route to each other you're ok. Just tell Exchange through PowerShell what the DAG network is and you're fine.

Important not to overthink these things and try to put complex enterprise designs into mon-n-pop environments; it helps nobody.




hiten@ipsgroup.co.uk -> RE: Cross Site Dag subnet question (28.Jun.2011 9:44:06 AM)

Thanks mark.

i posted this on the ms site and everyone kept saying that 2 subnets were needed on each site ( 2 in the data centre and 2 in the dr environment in our office)

i understand this might put extra load on our connection from our dr office to the data centre. do you know if  replication can be scheduled to happen out of hrs or over the wk end. or if it can be paused if the load get to much during office hours?

Thanks

Hiten




mark@mvps.org -> RE: Cross Site Dag subnet question (28.Jun.2011 9:56:17 AM)

Everyone is correct but what many responders sometimes forget is that not everyone is dealing with their corporate 5-10,000 solutions. I've seen some dumb 'enterprise' grade advice offered to some poor guy with a single Hyper-V host in each of two locations and four guests on each host. I've also seen some ridiculous advice for global 150,000 deployments.

You should not try to delay or prevent replication in any way. Sure, you can use the "suspend" commands but that's not great unless you maybe schedule your "suspend" and "resume" commands to prevent you forgetting. That would have the purists rolling their Rosaries but it's possible. However, and there always is one, if you can't properly cope with replication on the link you can't run the Exchange users over it if you need to invoke that copy.

Replication is lighter, smoother and more predictable than an invoked DR and that profile is what you need to plan and pay the WAN provider for.




hiten@ipsgroup.co.uk -> RE: Cross Site Dag subnet question (28.Jun.2011 10:13:10 AM)

Mark Many thanks for your advice. i thought this was the case as we are a small envirnoment with only 80-100 users.

i know suspend option is not very good its just a last option if the line cannot handle the replication and does need to be suspended.

could you let me know the command that i would need to run to get replication going via the interface set up for replication and how to disable replication over the mapi network

Thanks




mark@mvps.org -> RE: Cross Site Dag subnet question (28.Jun.2011 11:23:17 AM)

Suspend and Resume, from the Console and the Shell, in one page. Neat.
http://technet.microsoft.com/en-us/library/dd298159.aspx




hiten@ipsgroup.co.uk -> RE: Cross Site Dag subnet question (29.Jun.2011 4:23:57 AM)

Hi,

when is the DAG network set up. i have seen some articles say this is done automatically and some which the user has done it manually.

if you do it manually you have to put in the subnet that you want replication to occur over but it does say that enableing replication will stop MAPI traffic? as i only have a small environment i want replication to occur on the same subnet but just via a different network interface. so im slightly concerned that if i put the subnet in it will disable mapi traffic on the other interface.

Thanks




hiten@ipsgroup.co.uk -> RE: Cross Site Dag subnet question (29.Jun.2011 4:30:12 AM)

also another idea is if i set the subnet to be a single ip address

eg 10.50.0.133/32 so then it will be a single ip address for replication





mark@mvps.org -> RE: Cross Site Dag subnet question (29.Jun.2011 8:08:55 AM)

The DAG is automatic but you use the shell to set its IP address. You can also specify what interface replication traffic uses but Exchange can never disable 'user' traffic over that interface.




MyJuliet -> RE: Cross Site Dag subnet question (29.Jul.2011 10:40:32 PM)

Enableing MAPI traffic replication will stop? Because I only have a small environment, I want to copy in the same subnet.




myblogfull -> RE: Cross Site Dag subnet question (20.Mar.2012 5:08:51 AM)

Important not to overthink these things and try to put complex enterprise designs into mon-n-pop environments; it helps nobody.




Page: [1]