WANdisco's CVS MultiSite


Published on

CVS MultiSite (http://www.wandisco.com) leverages WANdisco's unique replication technology to immediately synchronize CVS repositories connected over a wide area network (WAN). Users at every location experience local area network (LAN) speed performance for both read and write operations. CVS MultiSite also provides continuous hot backup and self-healing capabilities that automate disaster recovery, so that downtime is virtually eliminated.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • <number>
  • <number>
  • WANdisco's CVS MultiSite

    1. 1. ► 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. ► CVS repositories connected over a WAN synchronize automatically with each write operation. ► Developers at all locations experience LAN speed performance 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 CVS behavior, so there’s no retraining. Key Features
    2. 2. ► Replicator implemented as a transparent network proxy at each site. • Normally installed on the same server as CVS at each location. • Listens on same port clients use to connect to CVS: • Default Port 2401. • SSH is also supported. • Client configurations don’t change. • No changes to CVS. Architecture
    3. 3. LAN-speed performance over a WAN results from a combination of CVS MultiSite’s: ► Active-active replication capability: • CVS 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 exact replica of every other. ► Quorum Configuration • Quorum based on distribution of users/activity across sites for best performance. • Only a quorum of nodes have to agree on transaction ordering. ► Network Architecture • Minimizes number of WAN roundtrips and bandwidth usage. Architecture
    4. 4. 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
    5. 5. 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 completes at distinguished node • Unanimous - Responses required from all nodes ► Follow-the-sun quorum rotation • Optimizes performance for each region’s normal working hours.
    6. 6. 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 CVS chattiness over the WAN • WAN roundtrip times are significantly reduced ► Eliminates tag explosion problem • Only the tag command and the associated metadata is sent. • Other solutions send all of the tagged files as well.
    7. 7. Demo
    8. 8. Built-in Backup and Recovery ► Active-Active replication delivers continuous hot backup by default. ► CVS 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 CVS 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.
    9. 9. ► Server Versions Supported • CVS Server versions 1.11.17 to 1.11.21 are supported ► Supported Clients • CVS command line, WinCVS, TortoiseCVS, SmartCVS, Eclipse and IntelliJ. ► System Requirements • CVS MultiSite 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
    10. 10. ► 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 distributed environment. ► Transparent implementation eliminates retraining. ► Most cost effective multi-site solution available for CVS. Summary