1. Introduction

zeus install

Riverbed software has been selected to provide a high-availability, application specific load balancing solution for use in conjunction with WANdisco Clustering products. This brief quick start guide shows you how to set up the "Zeus" Riverbed software to load balance between nodes in a Subversion MultiSite cluster.

1.1 Before you begin

You must install, configure and start Riverbed software as the Root user. Root privileges are necessary to bind to the restricted lower ports.

You may login as the Root user with the following:

su
Password: ********

Ensure that you have your Riverbed license key saved to your installation directory (e.g. /usr/local/zeus) before starting.
We would have sent you the license key via email. Contact WANdisco Support if you're unable to find your license key.
See Installing a new Riverbed license

2. Downloading Riverbed Software

This sections shows you how to get the Riverbed software.

3. Installing Riverbed Software

This section covers the software installation.

4. Integrate Riverbed Software with WANdisco

This section covers the software installation.

5. Basic Operations

Stopping Riverbed Software

You can stop the software running by running the following command (as root):

<ZEUSHOME>/stop-zeus

Starting Riverbed Software

The Zeus software starts automatically at the end of the configuration sequence. Having stopped the software you can restart it using the following command (as root):

<ZEUSHOME>/start-zeus

Changing the Riverbed Software configuration

You can re-run the configure script to change any or all of the settings that were chosen in section 4. or you can use it to remove the software cleanly from your machine and any cluster it was in, before clearing the installation files from your machine.

<ZEUSHOME>/zxtm/configure

Installing a new Zeus license

You don't need to have a valid license installed in order to start the Zeus service or web interface, however, you should use this procedure to install your license before going into production.

6. Setting up IP Sharing

With IP sharing you can ensure that the multi-hosted IP module shares incoming data traffic for an IP address across multiple hosts in a cluster. This has the advantage of evening out the load distributed across every active node, even when some nodes have failed.

Single-hosted traffic IPs often end up with an uneven distribution of load when failure occurs, as an entire IP's load is transferred to a single machine when the original host fails.

Requirements

Troubleshooting

The following articles may help you if you problems relating to your Zeus IP Sharing:

Why Can't users connect to my multi-host?
Multi-hosted IP addresses with Zeus Software
Zeus Timeout Settings

7. Installing the node monitoring script

WANdisco provides a script zeus_read_only_monitor.pl to monitor the status of each node in a cluster and detect if it becomes read-only. Should a node become read-only, the Zeus software will then drop the node from the pool to ensure continued load balancing of the remaining nodes.

You can find the script bundled with WANdisco's Subversion MultiSite 3.7 product, in the following location:

    <INSTALL DIRECTORY>/svn-replicator/bin/zeus_read_only_monitor.pl

The monitoring script has been tested on with Subversion MultiSite 3.7. Contact WANdisco technical support for updates and version compatibility.

Follow this procedure to install the script:

The monitor script is now installed. It's important that if you upgrade your version of the Zeus software that you check back with WANdisco to ensure that the script remains compatible.

8. Getting more help

Documentation

You can download a copy of the Zeus software User Manual for information about advanced configuration, function and troubleshooting.

Knowledge Hub

Go to the Zeus Knowledge Hub http://knowledgehub.zeus.com/docs for support, knowledgebase articles and further documentation.

9. Appendix

9.1 Connection sequence for a WEB-DAV transaction

This section illustrates the path that a WEB-DAV transaction takes in a setup that includes Riverbed Load balancing with a WANdisco Subversion MultiSite Replicator. To keep things simple the replication connections are not detailed.

zeus WEB-DAV Transactions
Connection ActivityApache / Zeus Connection Management
1. The Subversion client opens a connection through the Zeus Load balancer, (A).
2. Riverbed uses an available connection from its pool to connect to the Apache Reverse Proxy, (B).    
3. The Apache reverse proxy opens a connection to the WANdisco replicator, (C). 
4. WANdisco replicator opens connection to Apache DAV_SVN, (D). Apache starts the countdown on the connection using the Timeout and KeepAliveTimeout set in its config file.
5. WEB-DAV request streams from the SVN client, through the chain of connections show in the above illustration.  
6. The request streaming completes. Timeout and max_reply_time start countdown for connections (A) and (B) on Zeus.
Timeout and KeepAliveTimeout start countdown for connections (B) and (C) on Apache Reverse Proxy.
7. WANdisco replicator submits proposal for a Global Sequence Number (GSN) from its Agreement Manager and receives a response.  
8. WANdisco replicator streams a request to Apache DAV-SVN. Timeout and KeepAliveTimeout reset for the connection between the WANdisco Replicator and Apache DAV-SVN.
9. Apache DAV_SVN processes request.Apache begins a new countdown from connection (D) using Timeout and KeepAliveTimeout.
10. Apache DAV_SVN sends response to WANdisco replicator.Timeout and KeepAliveTimeout reset for connection (D) on Apache DAV-SVN.
11. WANdisco replicator forwards repsose to Apache Reverse Proxy.Timeout and KeepAliveTimeout reset for connection (C) on Apache Reverse Proxy.
12. Apache reverse proxy forwards response to Riverbed.Timeout and KeepAliveTimeout reset for connection (B) on Apache Reverse Proxy. Timeout and max_reply_time for connections (A) and (B) on Zeus.
13. Apache Reverse Proxy closes its connection with WANdisco replicator (C) because of proxy-nokeepalive environment variable. This leads the WANdisco replicator to close its connection to Apache DAV_SVN, (D). As a result, resources are freed up.  
14. Riverbed forwards the response to the client, returning its connection (B) to the available pool, ready for a new request.  
15. Connection (A) if finally closed.  

WEB-DAV write transactions

A. Connection (D) will be dropped if the total time to stream requests from the client to the WANdisco replicator, plus the time for the WANdisco replicator to get a GSN is greater than 7200s (2 hours).

Such a connection drop can occur when very large files are present within a commit on a limited bandwidth connection.

B. Connections (A),(B) and (C) will drop if the total time for WANdisco replicator to get a GSN, plus the time for Apache DAV_SVN to process the request os greater than 7200s (2 hours).

Such a connection drop can occur for a WEB-DAV MERGE with many new file versions present in a subversion commit.

These statements hold true when the following settings are used:

Riverbed Virtual Server timeout       = 7200s
Riverbed pool max_connect_time        = 7200s
Apache Timeout 	   		      = 7200s 
Apache KeepAliveTimeout               = 7200s
Apache SetEnv proxy-nokeepalive 1