1.9 Deployment checklist

Though you may have referred to the Deployment Checklist prior to an evaluation of Subversion MultiSite we strongly recommend that you revisit the checklist and confirm that you're system still meets all requirements.

System Setup
Supported Operating Systems
All nodes must use the same operating system

We've tested the following operating systems:

Fedora (32 or 64 bit): 6, 7, 8, 9, 10, 11
Red Hat Linux Enterprise Server (32 or 64 bit): 4, 5.2, 5.3, 5.4
Sun Solaris (32 or 64 bit): 9, 10
Linux: Linux kernel 2.6 or higher
CentOS-4 (5.2, 5.3, 5.4)
Windows Server, (32 or 64 bit) 2003, 2008

In principle, any operating system that can support a Java environment, Apache and Subversion.
Subversion Server Version
1.4 and above, through 1.6.11. Run the Apache Portable Runtime that matches your Subversion version.

Certified Subversion Binaries are now available from WANdisco. Providing the latest builds, without the risks associated with Open Source distribution.

Subversion Client Version
Compatible with local Subversion servers.
Pre-commit triggers are not recommended.
Use pre-replication hooks instead.
Any pre-replication hooks must be deterministic, i.e. have the same exact behavior and outcome at every node.
Post-commit triggers can be tested at only one node.
System Memory
Ensure RAM and swapping containers are at least four times larger than the largest Subversion file.
Recommended: 2 GB RAM; 4 GB swapping container
Disk Space
Subversion: Match to projects and issues.
MultiSite Transaction Journal: Equivalent of seven days of changes.

To estimate your disk requirements, you need to quantify some elements of your deployment:

  • overall size of all of your SVN repositories.
  • frequency of commits in your environment.
  • types of files being modified - text,binaries (SVN clients only send deltas for text).
  • number and size of files being changed.
  • rate that new files are being added to the repository.

    Checkouts You need sufficient disk space to handle large, in-transit checkouts which may get buffered to a tmp directory beneath the replicator installation until that checkout has been completed. The required space can be calculated using the following guideline:

    Recommended storage = Number of clients checking out files(N) x average checkout sizes (Kilobytes)
  • File Descriptor limit
    Ensure hard and soft limits are set to 64000 or higher. Check with the ulimit or limit command.
    Journaling File System
    Replicator logs should be on a journaling file system, for example, ext3 on Linux or VXFS from Veritas.

    NTFS is not a journaling file system: ext4 is a journaling file system, however WANdisco does not support its use because of its deferred writes.

    Maximum User Process Limit
    At least three times the number of Subversion users.
    Install JDK 1.6 or higher. We recommend using Oracle JDK 1.6.

    Ensure there are NO spaces or control characters in the path where Java is installed.

    For example, c:\Program Files\java will not work as a JAVA install directory.

    Install version 5.6.1 or later.
    For Access Control: Perl::DBI module for Audit Reports other than Users and Groups.
    Network Settings
    Reserved Ports
    MultiSite needs a dedicated port for DConENet (replication protocol) as well as HTTP protocol (for the Admin Console). We recommend having a port available in case you have to copy (rsync) the repository from one node to another. If your network has a firewall, notify the firewall of the port numbers.
    Firewall or virus scanner
    Notify the firewall and any virus scanners of the Subversion MultiSite port numbers.
    Set up IPsec tunnel, and ensure WAN connectivity.
    Persistent Connection Keep Alive
    Ensure VPN doesn't reset persistent connections for MultiSite.
    Understand the available bandwidth for testing, and set user expectations.
    DNS Setup
    Use IP addresses instead of DNS hostnames, due to performance and DNS server unavailability issues. If using DNS hostname is the only option, then ensure DNS availability.
    Apache 2 Setup
    (for http:// access)
    Apache version
    All nodes have the same version, 2.2.3 or above.
    Apache modules version
    All nodes have the same version of mod_dav and mod_svn_dav
    Turn KeepAlive On
    Keep-alive must be set to ON. See Using HTTP with Apache, Apache and SVNKit, and http://httpd.apache.org/docs/2.2/mod/core.html
    mod_deflate.c for SVN_DAV
    DO NOT USE mod_deflate.
    Location URI
    Ensure that all nodes' apache conf files have the same location URI for Subversion repository access
    Require valid user for write methods
    Ensure that all WebDAV methods require authentication for SVN-DAV protocol
    Use port 80 for WANdisco
    Standard Port 80 avoids confusion, change default Apache port if using 80.
    Apache server port
    Use non-standard Apache server port to avoid conflict with replicator port. See Dedicated Apache - Changing Subversion Port On Unix Flavor and Sharing Apache, and Using HTTPS.
    File Permissions in svnroot
    See this article (http://www.reallylongword.org/articles/svn/)
    WANdisco Setup
    Default is singleton. Trade off availability with performance.
    Rotating Quorum Schedule
    Ensure the distinguished node is in the active time zone.
    Agreement Threads
    Tune based on number of concurrent Subversion writers
    Reader/Writer Network IO Thread Pool
    Tune based on Subversion client connection rate, file transfer rate
    ConnectionKeepAlive timeout
    Tune inactivity timeout for persistent DConENet/DFTP connections based on VPN/WAN router set up
    Message Queue Max Thread Pool Size
    Tune based on Subversion write concurrency
    Maximum connections per IO thread
    Tune if active Subversion user population is large (greater than 100)
    Disk space for recovery journal
    Provision large disk for svn-replicator/systemdb, at least number of commits within a two to four hour window
    Batch Processing
    If there are any batch processes that interact with WANdisco, turn the deferred-writes to false.
    Access Control
    Audit Reports
    For reports other than Users and Groups, you'll need to use a database such as MySQL, and php.
    Optional but recommended. See Access Control - Using the AuthZ Module. Module may be bundled with your version of Apache.