| 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
(or master/slave serving) because each mirrored Web Crossing
database is a perfect mirror of the source database.
Figure
1 - Web Crossing running in a master/slave 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:
- Server
machine hardware specs (speed, physical memory and hard disk
capacity)
- Server
machine platform (Linux, Solaris, Mac OS X Server or other Unix,
Windows or Mac OS)
- Network
configuration (switching hubs vs regular hubs, 100BaseT Vs 10BaseT)
- Bandwidth
(ISDN, T1, T3, etc.)
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:
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 "master",
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
 .
- If
you are not running this Web Crossing server as a mirror or
as a source, select No redundancy. In this case, the
port number setting does not matter.
- If
this Web Crossing server is a mirror server, then select Mirror
(slave) server and enter the IP address of the source Web
Crossing server. Also, make sure the port number is the same
for both this server and the source server. (If you are interested,
see the section on port numbers
for more information about what they are used for. If you don't
care, just make sure that the numbers in all your servers are
the same!) The save original mirror database can be selected
if you want to automatically backup the mirrored database when
synchronizing with the source database.
- If
this Web Crossing server is a source server, then select Source
(master) server and enter the IP addresses for all the 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
- If
you are not using directory services with this Web Crossing,
select No directory services. In this case, the port
number setting does not matter.
- If
this Web Crossing server is making use of another Web Crossing
server's user directory, then select Directory services client
and enter the IP address of the source Web Crossing server.
Also, make sure the port number is the same for both this server
and the source server. (If you are interested, see the section
on port numbers for more information
about what they are used for. If you don't care, just make sure
that the numbers in all your servers are the same!)
- If
this Web Crossing server is providing user directory information
to other Web Crossing servers, then select Directory services
server and enter the IP addresses for all the client servers.
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.
-
Make
sure that the source server and mirrored servers are all using
the same Port Number. If the Port Number is not set correctly,
the servers cannot communicate with each other. Also, make
sure the mirrored servers all have the source server address
set correctly and that the source server has all the mirrored
servers addresses set correctly. (A common mistake is to accidentally
switch the IP addresses in a two-server configuration.)
Resources
Web Crossing
FAQ:
Sysop
Control Panel:
Sysop
Documentation:
- syspro.htm
- other details about running your mirrored or distributed server.
|
