Scaling, Mirroring and Distributed Serving

Introduction
Scaling
Setting Up a Source/Mirror Configuration
Setting Up a Distributed Configuration
Scaling Chat Configurations
Troubleshooting
Resources

Introduction

One of the many strengths of Web Crossing is its ability for linear scalability to meet increased loads. Scalability mean you can add more Web Crossing server machines to your site to share the load. Linearity means that if you have two servers running they can handle twice the load, three servers can handle three times the load, and so on.

Web Crossing accomplishes scalability by using multiple Web Crossing servers in a source/mirror configuration, as shown in figure 1. This configuration is also referred to as mirroring (i.e. master/slave serving) because each mirrored Web Crossing database is a perfect mirror of the source database.

Figure 1 - Web Crossing running in a mirrored configuration

Web Crossing can also share a common user database between two separate Web Crossing sites. This allows a site with a large database to break up a conference into smaller pieces yet share the same user directory. This kind of configuration is referred to as distributed serving because the conference resources are distributed among different machines, rather than all being held on one machine.

All Web Crossing servers (except for the free 1T version) support both mirroring and distributed serving. Only one license is required per cluster (same conference database). In other words, source/mirror serving only requires one Web Crossing license regardless of the number of server machines being used. Page views are counted as though the cluster was one large server. However, distributed serving requires a separate license for each Web Crossing server machine because the web conferencing database content is different for each server.

Note: The mirrored and distributed serving features are active in the free 1T version also, but the Web Crossing license restricts their use to testing only. Use in a production server is considered a violation of the license agreement.

In figure 1, the source database is automatically mirrored in two separate databases, under the control of two separate Web Crossing servers. Users can access any of the servers and participate using the same web conferencing content.

Scaling

How much load can a single Web Crossing server handle, and what are the limits of what can be handled by a very large Web Crossing multiple-server system?

Naturally the load that any single Web Crossing server is able to handle depends on various factors outside the control of Web Crossing, including:

Just to give you a feeling for the kinds of performance you can expect, here are some sample figures from a large site running Web Crossing (4.0):

That system's Web Crossing server runs on a 350 MHz Pentium machine using the Linux operating system. The server has 1 GB of physical RAM and a 9 GB hard disk installed. In benchmark tests we found that Web Crossing was serving a single page in a average of 30 ms (this includes pages with WCTL embedded). Assuming no bandwidth difficulties, such a system could serve over 1 million pages over the course of a 10 hour business day. If each user viewed 5 to 10 pages, such a server would have no problems serving 100,000 to 200,000 visitors over the course of a typical business day.

Now consider what you could do with Web Crossing's scaling features on top of that!

If you had 10 such servers handling the load, over the same 10 hour period you could serve over 10 million pages and handle between 1 million and 2 million users. This is a practical thing to accomplish, assuming your site has the bandwidth to support such activity. Perhaps the most active site on the Internet, Yahoo!, reports that it had 465 million page views per day in December, 1999. If your site had the bandwidth of Yahoo!, there is no reason you could not extend your Web Crossing system to 40 or 50 servers and handle that load over the 10 hour peak hours of a business day.

By now you should get the basic idea - Web Crossing will grow with you to meet your expanded needs.

Most people start with a single server and then add more as the need presents itself. Web Crossing also provides you with the ability to run stress tests, over a LAN or across the Internet, so you can see how well your particular configuration will hold up under various conditions.

There is also another reason to use Web Crossing's scaling features that has nothing to do with system load. Since each Web Crossing server automatically mirrors the main, or "source", server in real time, each server acts like a complete database and hardware backup. When running in a source/mirror configuration, should one server experience hardware failure, the other servers will continue to operate, giving you added assurance and redundancy to keep your system running "24 by 7" (as they say in the Internet sysop biz). (See Backups.)

Note: You can also scale Web Crossing to serve a huge number of simultaneous chatters. See the Chat Scaling section for more information.


Setting up a Source/Mirror Server Configuration

Setting up source/mirror servers is straightforward. First you install your various servers in direct service mode on your server machines. Make a note of the different IP addresses used by the different servers, then open the Control Panel > Distributed Servers form.

To set up a mirrored server system, fill in the top-most form, shown in figure 2.


Figure 2 - Setting up redundant (source/mirror) servers

.

After your source and mirrored servers have been configured this way, any server can be accessed and each will provide the same conferencing contents to users. Web Crossing will automatically keep the contents between the servers synchronized.

You can have all your users access the same location and just use the mirror servers as an extra backups. Or you can route your incoming users among the source and mirror servers to achieve load balance.


Note: And how, exactly do we do that? Now that the source and mirrored servers are configured and communicating with each other, how do we direct incoming users in a balanced way among the different servers?

Many large sites have special hardware called "routing servers" installed that are made for this purpose. These servers take incoming requests and route them to the next server on the list, in a round-robin fashion, allowing all the servers to share the load.

Fortunately, with Web Crossing, no extra special hardware is required. Web Crossing allows you to use one unlicensed copy of Web Crossing as a round-robin routing server. The details for setting up this feature are found in the section on Direct Web Service.

Setting up a Distributed Server Configuration

Setting up a distributed server configuration (sharing the same user directory among different Web Crossing servers with different content) is equally straightforward. First you install your various servers in direct service mode on your server machines. Make a note of the different IP addresses used by the different servers, then open the Control Panel > Distributed Servers form.

To set up a distributed server system, fill in the bottom-most form, shown in figure 3.

Figure 3 - Setting up a distributed server configuration using directory services

After setting up your Web Crossing servers in this way, users of the server Web Crossing server will automatically be considered users of the client servers. You can split up your conferencing in any way you like to share the resources among the different servers. Doing this, you can achieve unlimited database sizes for your conference.

It is important to understand what is happening here. Conceptually, the directory services operations are much like source/mirror server settings except only the user directories are being mirrored. Any user changes (such as registrations, deletions, password changes, etc.) are propogated throughout all the cooperating servers. If any server turns off directory services and decides to run independently, it will be left with the user directory up until that time.

Note: Once several Web Crossing servers are sharing the same user directory, how are the links between the different databases handled so users can move from one server to the other? There is currently no automatic way of accomplishing this. You must create links to folders manually and place them, for example, in the various site banners.

Troubleshooting

My mirrored servers don't seem to be getting updated content correctly synchronized with the source server, or my client-side distributed server doesn't seem to be correctly authenticating users who are registered on the server-side server.

Resources

Web Crossing FAQ:

Sysop Control Panel:

Sysop Documentation: