Replication failover and FRS VVJOIN

[Microsoft Punlic]

Hi,

Consider a branch office scenario based on W2K.
1000 DC's will replicate via a HUB layer with each HUB server in a seperate
site in order to create sitelinks with the branches.
Sitelink bridging and Intra site topology generation are disabled.
This allows us to let KCC calculate and create connection objects (via the
scheduler the ISTG is enabled and KCC calculation is triggered). In this
case we don't heave to work with manually created connection objects.
In case of a HUB server crash every other HUB server will get an extra 20
connection objects. I've heard that this could be an issue regarding the FRS
vv-join process.
This could also be a problem when reinstalling the HUB (the HUB will have to
do a vvjoin for 100 connection objects after the firs KCC calculation)? This
could consume too much CPU and 'crash the HUB server.
Does anyone have any experiance with this scenario?

Regards,
BP

 

[Jason Robarts [MSFT]]

The Windows 2000 Branch Office Deployment Guide recommends you use manual
connection objects instead of using the KCC when using a large scale
deployment. Windows Server 2003 has a new mode for the KCC that will create
redundant connection objects so failover doesn't happen.

Jason

 

[Jason Robarts [MSFT]]

To be clear in Windows Server 2003 turning on redundant topology on its own
may not turn off failover (that may be another switch). When you have
redundant connections the need for failover goes significantly down.

Jason

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

 

[BP]

I know that W2K3 is very well equipped to support branch offices. The
redundant objects and the loadbalancing reskit tool are very cool features,
however the implementation I am referring top is NOT a W2K3 implementation!
Technet Q244368 describes the possibility to work the way we do with a
scheduled KCC calculation. We provided 'redundant' sitelinks towards te
branches. Each branch is connected via a cost 100 and a cost 200 sitelink
with the central site. I just wan to know what will happen in case of a
failover or in case of a reinstallation when rejoining to the FRS replica
set.

BP

 

[Jason Robarts [MSFT]]

Any time a connection object is created FRS may perform a vv-join.

Jason
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

 

[BP]

Any idea what will be the effect on CPU and disk usage?
Will the joins be performed simultaneously for all conn obj?

 

[Jason Robarts [MSFT]]

I don't know. In this environment the recovery plan is to use control the
failover as opposed to letting it happen and potentially overloading FRS on
the DCs.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distsys/part1/dsgch06.asp
describes reg keys you can use to set the length of time a DC is down before
failover decides a new connection needs to be created. This should be at
least a few days. The KB article you cited describes reducing the frequency
the KCC runs. I would not run the KCC on all of the machines
simulataneously. You can run the KCC on batches of 10 DCs (not hub DCs),
monitoring the vv-joins complete using Sonar or Ultrasound after the
failover connection is established. Those 10 vv-joins should complete
before you start another batch. As you're constructing the new topology in
these small batches I'd work on getting the lost hub dc back up so you don't
need to failover.

As for whether the vv-joins will occur at the same time I don't know. In
Windows Server 2003 the schedule on the connection affects when the vv-join
will occur. I'm not sure if that is the case in Windows 2000. I wouldn't
risk it.

Jason
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm