Getting started with VDFS replication in an Active Directory environment

Applies to: VisualSVN Server 3.7 and later

Multisite Repository Replication feature is based on the VisualSVN Distributed File System (VDFS). Geared towards geographically distributed networks, the repository replication feature enables development teams from remote locations to work with the repositories at LAN speeds. To any Subversion client software each VDFS repository is a fully functional, writable Subversion repository. This article introduces some key VDFS concepts and deployment prerequisites, as well as provides a step-by-step instructions for configuring the VDFS replication across servers that reside in the same Active Directory domain or trusted domains.

Key concepts

From the Subversion client software standpoint, each VDFS repository — regardless of its master or slave role — looks and acts just like a regular writable Subversion repository. The replication is performed automatically and transparently.
A VDFS repository can be created as either a master or a slave, not both.
The terms master repository and slave repository refer to VDFS roles that govern the under-the-hood behavior of the replication mechanism. To Subversion clients each VDFS repository is always exposed as a standard Subversion repository.

Assumptions

For explanatory reasons, we will assume the following:

There are two instances of VisualSVN Server installed on the following servers in the example.com domain:
- Berlin-SVN.example.com. Master repository will be hosted here and we refer to this server as to the master server.
- NY-SVN.example.com. Slave repository will be hosted here and we will refer to this server as to the slave server.
Both VDFS services are running under built-in Network Service account.
Both VisualSVN Server instances reside in the same Active Directory domain. Consider the KB120: Getting started with VDFS replication in a non-domain environment article if you plan to deploy the replication on non-domain computer or in domains without trust relationship.

Prerequisites

Before deploying VDFS replication, please ensure that the following prerequisites are met:

All the VisualSVN Server instances must be at the same server version of 3.7 or newer. You may see the instruction that applies to older versions in the article KB68.
All the VisualSVN Server instances must have an Essential, Enterprise, Enterprise Multinode or Evaluation license. Feel free to request a 45-day evaluation license key.

Tip

The Enterprise Multinode license is available with VisualSVN Server 4.1 and later versions. Compared to other licenses, one Enterprise Multinode license key may be used on all nodes of the same VDFS replication cluster.

Step 1: Enable VDFS service on master and slave servers

The VisualSVN Distributed File System Service (also referred to as VDFS service) must be started on all the VisualSVN Server instances. The service is disabled by default. It can be enabled and started from the VisualSVN Server Manager by clicking the Enable link in the service status section of the dashboard. See the article KB74: Enabling and starting VDFS service for further details.

Step 2: Enable VDFS firewall rule on master server

An inbound firewall rule named VisualSVN Distributed File System Service must be enabled on the master server. The rule is created during the VisualSVN Server installation but it is not enabled by default. See the article KB73: Enabling the inbound firewall rule for a master VDFS service for further details.

Step 3: Authorize the slave server to connect to the master server

The slave server should be authorized to connect to the master server. Follow these steps to add the slave server into the list of authorized replication partners:

Start VisualSVN Server Manager console on the master Berlin-SVN server.
Click Action | Properties and click the Replication tab.
Click Add menu-button and then select the Add server authenticated by Active Directory command.
Add the computer account NY-SVN$. Click OK.

Note
Read the article KB70: Choosing correct accounts to grant the replication access for additional details.
Click Apply.

Note that this step authorizes slave server’s access to the local VDFS service, but not to the individual master repositories. Access to the particular master repository will be granted on the next step.

Step 4: Create a master repository

Creating a master VDFS repository in VisualSVN Server is very similar to creating a regular, FSFS-type repository. Follow these steps to create a new VDFS master repository:

Start VisualSVN Server Manager console on the master Berlin-SVN server.
Right-click Repositories and click Create New Repository. A wizard dialog opens.
Select Distributed VDFS repository and click Next.
Select Master repository and click Next.
Enter MyRepo as a name of the new master repository and click Next.
Choose suitable settings for the repository structure. You may leave these settings at their defaults. Click Next.
Choose suitable settings for the repository permissions. You may leave these settings at their defaults. Click Next.
Grant the replication access to slave servers. Click Add menu-button and then select the Add server authenticated by Active Directory command.
Add the computer account NY-SVN$. Click OK.
Click Create and then Finish to complete the wizard.

The new master repository will become available to all Subversion clients just like any other regular Subversion repository.

Instead of creating an empty repository, you may choose to populate it with data from an existing one. Simply select Import data from existing repository and specify the path of an existing FSFS repository to import.

In-place repository conversion from FSFS to VDFS

Existing FSFS repositories can be converted to VDFS format in-place. The in-place conversion operation is nearly instantaneous and reversible.

Note

It is highly recommended to run Verify Repository task prior to the conversion. To do so open a repository context menu and click All Tasks | Verify Repository. Although it may take some time, doing so will check the integrity of data stored in the repository, thereby preventing issues you may experience later on. Corrupted repository results in the initial replication issue and has to be repaired prior to the deployment of slave repositories.

Follow the instructions to perform the in-place conversion of a repository:

Stop VisualSVN Server services.
Start the VisualSVN Server Manager console.
Right-click on a repository name.
Click All Tasks | Convert to VDFS Format.

Step 5: Create a slave repository

When all the above steps are complete, you are ready to create a new slave VDFS repository:

Start VisualSVN Server Manager console on the slave NY-SVN server.
Right-click Repositories and click Create New Repository. A wizard dialog opens.
Select Distributed VDFS repository and click Next.
Select Slave repository and click Next.
On the Master Repository Connection Details page perform the steps below:
1. Enter Berlin-SVN.example.com as the Master server name.
2. Enter MyRepo as the Master repository name.
3. Make sure, that Active Directory is selected as the authentication method.
After you click Create, the new slave repository will be created and an initial sync with the master repository will start in the background.

The initial sync of a large repository may take time. During this period the slave repository will be valid and available but out-of-date. An alternative approach that works faster for huge repositories (or in environments with relatively low network bandwidths) is to deploy the slave repository using a replication seed. For additional details see the article KB101: Deploying VDFS slave repositories using replication seeds.