► Peer-to-peer architecture with no single point of failure.

► Not master-slave or multi-master.

• Repositories at every site are fully readable and writeable.

► Subversion repositories connected over aWAN synchronize automatically with eachwrite operation.

► Developers at all locations experience LAN speed performance over a WAN for both read and write operations.

► Built-in hot backup and automated disaster recovery features make third party solutions completely unnecessary.

► Transparent implementation doesn’t change Subversion’s behavior, so there’s no retraining.

Key Features

► Replicator implemented as a transparent network proxy at each site.

• Normally installed on the same serveras Apache at each location.

• Listens on same port clients use to connect to Subversion:

• Port 80 for HTTP.

• Port 443 for HTTPS.

• No client configuration changes.

• No changes to Subversion server.

Architecture

LAN-speed performance over a WAN resultsfrom a combination of Subversion MultiSite’s:

► Active-active replication capability:

• Subversion servers become active nodes on a network.

• Each node works cooperatively with its peers to agree on transaction ordering.

• Each node’s repository becomes an exactreplica of every other.

► Quorum Configuration

• Only a quorum of nodes have to agree on transaction ordering.

• Quorum based on distribution of users/activity across sites for best performance.

► Network Architecture

• Minimizes number of WAN roundtrips and bandwidth usage.

Architecture

How it works:

► The replicator generates a proposal (header) for each write at its location and sends it to its peers.

• The proposal contains a globally unique transaction id and other data used to determine if conflicts exist.

• The proposal’s unique transaction id is used at every location to guarantee consistent transaction order.

► Users experience LAN speed performance.

• Once agreement is received from a quorum of nodes, the write goes forward at the site where it originated.

• No waiting for other sites to complete the write.

• Agreement takes less than half a second between US and India over a typical E-1 line.

• All reads are local and generate no WAN traffic.

Active-Active Replication

Quorum Configuration

How it works:

► Quorum configuration options:

• Majority - Only 51% of nodes required to respond to proposal.

• Distinguished Node – node used as tie-breaker with an even number of nodes

• Singleton - The Distinguished Node is the quorum.

• Ideal if one site has many more users and activity than others.

– Superior performance at the quorum site.

• Responses from remote nodes are not required at the Distinguished node

– No WAN traffic generated for agreement process.

– Writes get sent to other nodes after agreement process completesat distinguished node.

• Unanimous - Responses required from all nodes

► Follow-the-sun quorum rotation

• Optimizes performance for each region’s normal working hours.

Network Optimization

How it works:

► Reduces network traffic and bandwidth usage and costs

► All reads are local and generate no WAN traffic

► Streaming on Persistent connection between servers

• Connection pooling used for multiplexing

• TCP 3-Way Handshake Eliminated

► Uses WANdisco’s own protocol over the WAN

• Eliminates normal Subversion chattiness over the WAN

• WAN roundtrip times are significantly reduced

► Overcomes WAN performance issues with HTTP WebDAV Protocol

• Entire commit with multiple files can be sent over one connection.

• Other solutions open and close connections for each file.

Demo

Built-in Backup and Recovery

► Active-Active replication delivers continuous hot backup by default.

► Subversion MultiSite leverages this to provide automated recovery.

• Catch up from any other live node on restart after a network outage or server crash.

• Maintains a database-like redo log/pending transaction journal for recovery.

• Split brain is impossible.

► Users can failover to another site’s Subversion server while theirs is down and continue working.

► Makes full 24x7 operation possible in a globally distributed environment.

• Servers can be taken offline for maintenance without disrupting user access.

► Third party disk mirroring solutions are completely unnecessary.

► Server Versions Supported

• Subversion server versions 1.3 and above are supported.

► Backend Support:

• FSFS and Berkeley DB are supported.

► Supported Clients

• Subversion command line, SmartSVN, RapidSVN, TortoiseSVN, Subclipse, and any HTTP client that works with Subversion.

► System Requirements

• WANdisco for Subversion will run in any J2SE 1.5 or above compliant Java runtime environment. A minimum of 64 MB of RAM and 450MHz CPU is recommended for the server

System Requirements

► Unique technology allows distributed development teams to work as one at LAN-speed over a WAN, instead of working in silos.

► Dramatically reduces development time and cost.

► Peer-to-peer architecture with no single point of failure.

► All servers can be monitored and administered from a single location.

► Built-in continuous hot backup and self-healing capabilities eliminate risk in a disaster recovery scenario.

► Makes full 24X7 operation possible in a globally distributed environment.

► Transparent implementation eliminates retraining.

► Most cost effective multi-site solution available.

Summary