Web Crossing/Platinum Sysop Documentation

» Redundant database architecture

Redundant database with 2 mirrors

All of the servers, including the source, can be used to process user requests. In very high-volume sites, the source may be dedicated to synchronizing the various mirror databases.

Each mirror may run as a separate process on the same machine as the source, or on its own machine. Each server, source or mirror, keeps its own copy of the discussion database. TCP/IP connections from the source to each mirror are used to synchronize all of the databases.

The mapping of a user request to a particular Web Crossing server is done outside of Web Crossing. For example, you could use DNS rotation to have domain-name lookups rotate among the various servers, or hardware such as Cisco's LocalDirector to transparently assign each request to an available server.

Because each server keeps its own copy of the database, most requests can be served locally, without accessing the source database. Requests that change the database, such as checking subscriptions or changing user preferences, are passed to the source and then from the source to the other mirrors. Requests that create a new database object, such as posting a message or creating a new discussion, are passed to the source to have the object's unique ID assigned centrally, and are then passed by the source to all mirrors.

Scaling and Load Issues

On Solaris Ultra2 machines, a single process can serve 250,000 to 1,000,000 page views per "day" over a 10-hour duty cycle. The duty cycle takes into account that server load varies dramatically during a 24 hour period, and figures for purposes of determining load capacity that the server is running full-out for 10 hours, idle for the rest.

So on Solaris Ultra2 machines, this means you can serve between 2.5 million and 15 million page views per day with multiple redundant servers, depending on typical post sizes, ratio of page-views to posts, and how much customization you do on the site.

» Configuring redundant servers

Each redundant server must have its own license certificate.

» Operations with redundant servers

Configure the additional mirror server, either as another process on an existing machine or on a new machine.

On the source server, use the Distributed servers panel to add the mirror server.

On the mirror server, use the Distributed servers panel to configure the mirror and connect it to the source.

Note that the source and mirror synchronize by copying the source's DB over the TCP/IP connection. Copying the source's database can take the source off-line for a few minutes, and it can take a few minutes for the mirror to receive the database and start processing requests. If possible, it is desirable to take the source and mirror off-line during this synchronization. For example, if you are using DNS rotation, the source and mirror Web servers could be configured to transparently forward requests to another server.

You can check on the progress of the synchronization by logging in to the mirror machine as the sysop. For the sysop, all pages include the current synchronization status at the top of the page (except pages served through the webx.tpl file).

The first step is to remove the mirror server from the request rotation. With DNS rotation, this means configuring the mirror's Web server to forward the mirror's requests to another machine.

Once the mirror is off-line, you can shut it down normally, as if it was a stand-alone Web Crossing server.

Moving the source server to one of the mirrors requires that service be shut down for a few minutes. After service is shut down and user requests are no longer being served, you can shut down the source server, configure one of the mirrors to be the source, and then configure the remaining mirrors to connect to the new source.

The new source will synchronize each of its mirrors to its database, and service can then be resumed.

With a large database, it can take a few minutes to make a backup copy. The recommended technique is to temporarily remove one of the mirror servers from the rotation for user requests, do the backup on that mirror server via the sysop Backup command, and then bring that mirror back into service.

The Backup command makes a backup of the current database called webxdb.1. This backup file can be copied to external storage to allow last-resort restarting of the discussion service.

If a mirror server shuts down unexpectedly, you can simply remove it from the rotation. If you are using DNS rotation, this requires a spare machine to forward requests to an available server; if you are using Cisco's LocalDirector or equivalent, the mirror server will be removed from service automatically.

If the source server shuts down unexpectedly, you need to make one of the available mirrors into the new source as described above. When the old source comes back on-line, you can reconfigure it to become a mirror of the new source.

» Shared user directory

You can use this to have a common user community across multiple sites, or to break a single large conference down into smaller pieces so that it can scale to much larger volume.

In this mode, all of the servers share the same member directory information, so that login certificates and preference settings are propagated throughout the cooperating servers.

Scaling with split areas is essentially unlimited, because you can keep splitting the site into smaller pieces as desired.

You configure shared directory service through the Distributed servers sysop control panel.

» Combined redundancy and shared user directory