Planning Replication for Branch Office Environments

Operating System

Chapter 3

Planning Replication for Branch Office Environments

Planning Guide

Abstract

This chapter presents the basic elements of replication in the context of the two types of replication: Microsoft® Windows®2000 Active Directory™ service replication and File Replication service (FRS) system volume replication. It outlines the replication issues to be considered before setting up sites. After reviewing these considerations, you should be able to decide how and where to place hub sites, when and where to create connection objects, and where to place bridgehead servers.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Ó 2000 Microsoft Corporation. All rights reserved.

Microsoft, Windows, WindowsNT, the Windows logo, Active Directory, and Visio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries/regions.

1200

Contents

Introduction 1

Resource Requirements 1

What You Will Need 1

What You Should Know 1

Process Flowchart 2

Replication fundamentals 3

Comparison of Active Directory and FRS Replication 3

Active Directory 4

Inbound Replication 4

Outbound Replication 4

File Replication System 4

Components of the replication topology 6

Connection Objects 6

Intra-Site 6

Inter-Site 6

Site Links 7

Site Link Bridges 8

Sites and Domains 8

More Information 9

Determining the choice of bridgehead servers 10

Inbound Versus Outbound Replication 10

Determining Inbound Replication Partners for a Bridgehead Server 10

Overhead for Replication 13

Estimating the Replication Payload 13

Determining Outbound Replication Partners for a Bridgehead Server 14

Outbound Replication Calculation 15

Inbound Replication Calculation 15

Determining the number of bridgehead servers 17

Configuring replication topology for large branch office deployments 19

Non-KCC Creation of Connection Objects 19

Disable Inter-Site Topology Generator 19

Planning Staggered Replication Schedules 21

The Hub-Topology Scripts 22

Connection Schedules and Load Balancing 23

Scheduling Hub Server Load Balanced Replication 24

Scripting Load Balancing 24

using kcc with a small number of sites (< 100) 26

KCC Configuration 26

KCC Generation of Connection Objects 26

Hub Sites 27

Summary 29

More Information 29

Introduction

This chapter guides you through the process of planning replication for your branch office environment.

Resource Requirements

Individuals from the following teams will be required to participate during this phase of the planning:

·  Windows 2000 Active Directory Architecture

·  Windows 2000 Active Directory Administration

·  Infrastructure Administration

·  Network Administration

What You Will Need

Before you start replication planning process, you need to finish the forest, domain, and Domain Name Service (DNS) planning as presented in the previous chapters. Having a tool like Microsoft Visio® drawing and diagramming software will enable you to lay out the plan graphically, including the individual steps.

What You Should Know

You should have a thorough familiarity with the basics of Microsoft Windows®2000 Active Directory™ service, sites, replication, and bridgehead servers. This information is available in the Windows 2000 Server Resource Kit, Distributed Systems Guide.

Process Flowchart

Replication fundamentals

Microsoft Windows 2000 operating system domain and forest-wide replication consists of two major components:

·  Active Directory replication

·  SYSVOL replication which utilizes the File Replication System (FRS)

Administrators planning for a branch office deployment need to understand Active Directory replication and the separate FRS system volume (SYSVOL) replication used to replicate group policy changes. This guide assumes a familiarity with the topics covered in the chapters on Active Directory, FRS replication, and related topics in the Windows 2000 Server Resource Kit, specifically the Distributed Services Guide. There are some additional implications for branch office deployments. A brief review of the important concepts is therefore provided here, followed by the specific considerations and issues encountered in branch office deployments.

Comparison of Active Directory and FRS Replication

Active Directory replication and FRS replication used for SYSVOL are different processes that use the same replication topology, but run independently from each other. There are two major differences between how an available replication window is utilized by Active Directory and by FRS SYSVOL replication: start time and replication behavior. Active Directory replication chooses a start time randomly within the first 15 minutes of a replication window to distribute the concurrence factor across the window. FRS SYSVOL replication, on the other hand, starts the moment the window opens. This means that while Active Directory replication with multiple partners starts at different times within a 15-minute window, FRS SYSVOL replication with multiple partners starts at the same time for all partners.

Active Directory / SYSVOL – FRS
Scope / Forest / Domain
Type / Pull (notify/pull within site) / Notify/Push/Ack
Concurrent partners - Inbound / Serialized / Parallel
Concurrent partners – outbound / Parallel / Parallel
Threading model / Single thread per replication partner / Multiple threads per replication partner
Versioning / Per attribute version number / Per file timestamp

Table 3.1: Comparison of Active Directory and FRS replication

Active Directory

Active Directory replication is always a one-way pull replication; the domain controller that needs updates (target domain controller) contacts a replication partner (source domain controller). The source domain controller then selects the updates that the target domain controller needs, and copies them to the target domain controller. Since Active Directory uses a multi-master replication model, every domain controller works as both source and target for its replication partners. From the perspective of a domain controller, it has both inbound and outbound replication traffic, depending on whether it is the source or the destination of a replication sequence.

Inbound Replication

Inbound replication is the incoming data transfer from a replication partner to a domain controller. For a hub domain controller, inbound traffic is data that is replicated from a branch office domain controller. This replication traffic is serialized, meaning that the hub domain controller can handle inbound replication with only a single branch domain controller at a time. This fact is critical in determining the number of bridgehead servers (hub servers) that will be used in the organization. Assuming that replication with each branch domain controller takes two minutes, the hub domain controller can handle a maximum of 30 branch domain controllers in one hour.

Outbound Replication

Outbound replication is the data transfer from a domain controller to its replication partner. For a hub domain controller, this is the replication from the central hub to the branch office domain controller. Outbound replication is not serialized, it is multithreaded. During outbound replication the branch office domain controllers pull changes from the hub domain controller.

Recommendations for Optimum Performance

For Active Directory replication, a rule of thumb is that a given domain controller that acts as a bridgehead server should not have more than 50 active simultaneous replication connections at any given time in a replication window. (This was determined on a reference server that had four Pentium III Xeon processors with 2 gigabytes (GB) of RAM and 2 megabytes (MB) of L2 cache.) Adjusting this rule to a limit of fewer than 50 servers will have significant positive impact on CPU utilization, network throughput, and I/O throughput on this domain controller. Additional performance improvement can be achieved by putting the components of Active Directory on different physical drives.

File Replication System

System policies and logon scripts stored in SYSVOL use FRS to replicate. Each domain controller keeps a copy of SYSVOL for network clients to access. (FRS is also used for Distributed File System (DFS). Because this guide is not concerned with DFS replication, no further mention will be made of this area of FRS replication.) FRS can copy and maintain shared files and folders on multiple servers simultaneously. When changes occur, content is synchronized immediately within sites, and by schedule between sites.

FRS is a multithreaded, multi-master replication engine that replaces the LMRepl service which is used in the Microsoft Windows NT® operating system. Multithreaded means that several replication sessions can run at the same time to handle multiple tasks. This allows FRS to replicate different files between different computers simultaneously. Multi-master replication means that changes to the SYSVOL can be made on any domain controller, and this domain controller will then replicate the changes out to the other domain controllers using a store-and-forward mechanism. FRS SYSVOL replication uses the same Active Directory replication topology defined by connection objects. In contrast to Active Directory replication, FRS SYSVOL replication uses a timestamp on a file to determine which version is the newer version and should be kept on a domain controller and replicated out to partners.

FRS does not guarantee the order in which files arrive. FRS begins replication in sequential order based on when the files are closed, but file size and link speed determine the order of completion. Because FRS replicates only whole files, the entire file is replicated even if you change only a single byte in the file. By default, FRS can transfer up to 8 files per partner, in parallel.

Key points to know when maximizing the performance of a bridgehead server in a hub site with regard to FRS are to:

·  Place SYSVOL on its own physical disk drive.

·  Split the FRS database files and logs across different physical disk drives.

·  Place the FRS staging area on its own physical disk drive.

Components of the replication topology

Components of the replication topology include the Knowledge Consistency Checker (KCC), connection objects, site links, and site link bridges. Basic information on these components as it relates to replication and the branch office scenario is presented here. The information is presented so that you will understand the implications of decisions you will be making in the scenario with large number of sites, (for example, turning off the Inter-Site Topology Generator (ISTG) between sites, and disabling the KCC generation of intra-site replication topology in the staging site.)

Connection Objects

In a configuration with 100 or more sites the KCC will not scale. With more replication partners, you must either create a staggered replication schedule, or manual connection objects, or both. Your replication topology design should take into account load balancing for hub or bridgehead servers. After this design is implemented you will need to continually monitor the replication traffic and server behavior to ensure that your design continues to be optimum for your organization.

Since you will only use the KCC in small (<100 sites) deployments, the KCC background information is presented in the section on <100 sites, at the end of this chapter.

Several key factors that limit the functionality and scalability of the KCC include the:

·  Number of sites

·  Number of domains

·  Transitiveness of site-links

·  Usage of site-link-bridges

Intra-Site

When the KCC generates the intra-site topology for the site in which it resides, the KCC creates a one-way connection object in the Active Directory only when a connection object is required for the local computer. These changes propagate to other domain controllers through the normal replication process. Each domain controller uses the same algorithm to compute the replication topology, and in a state of equilibrium among domain controllers, each should arrive at the same result with respect to the target replication topology. In the process, each domain controller creates its own connection objects.

Recommendation for Intra-Site Replication

For intra-site replication, always use the KCC to create and manage the replication topology. (The only exception is presented during the discussion of the staging site, which is a special case.) The intra-site replication topology generation is not a very costly operation. Disabling the KCC for this task can create unpredictable and unmanageable results.

Inter-Site

For every site, one domain controller, known as the Inter-Site Topology Generator (ISTG), is responsible for managing the inbound replication connection objects for all bridgehead servers in the site in which it is located. If the server holding the ISTG role is taken offline, the role is automatically transferred to another domain controller in that site by the system. Unlike the transfer of the Operations Master roles, this transfer does not require any intervention by the administrator. For inter-site replication the administrator creates the connection objects by using scripts, third-party tools, or by hand.

For both inter-site and intra-site replication, the KCC periodically creates and checks connection objects to maintain directory connectivity. Sometimes, the administrator may want to supplement the least cost spanning tree topology of connection object that is created by the KCC, for example, to add more connectivity to improve replication latency. In those cases, the administrator can use a script or manually create additional connections. If you create a connection that is identical to the one the KCC would create, the KCC will not create an additional one, nor will it delete or alter any connections that it has not created.

There are three types of connection objects. Look in the Active Directory Sites and Services console, and focus on a particular connection object. Now look in the details pane under the name column. The three types of objects are displayed differently: