Increase your Web site's performance and reliability while saving money -- We show you how
Creating several Web servers on one machine is a snap, and can save you lots of headaches later
Running multiple Web servers doesn't mean you must have multiple machines. Creating several servers on a single physical machine is easy with virtual hosts. (2,400 words)
As the servers matured and learned cohabitation, the only impediment to a new server was the network connection: Each server needed its own IP address, which meant that the machine had to be multiply attached to a network with each network interface having its own IP address.
With the advent of virtual interfaces in the latest release of Solaris (and other operating systems), virtual hosts can be created without any additional hardware. This means the only thing stopping you from running several servers on a single machine is a few new lines in a few configuration files.
Since it's that easy, this month we'll cover virtual hosts -- why they're good, dealing with your operating system, and configuring your server.
The benefits of virtual hosting
The earliest users of virtual hosting were Internet service providers who sold Web space to clients. While some clients were happy to share the same server and distinguish their sites via a directory within the server, other clients were willing to pay more to have a unique domain name for their site. ISPs were more than happy to oblige, but wanted to avoid buying a new machine for every new client. Virtual hosting saved the day, both technologically and financially: ISPs could put a new server on an existing machine at virtually no additional cost, but could still charge the client as if they had bought a new machine.
For those of us with sites on real computers running Unix, we know that the typical Unix server is hardly bothered by a typical Web server. With oodles of additional bandwidth lying about, virtual hosting lets you place many servers on a single machine without investing in new hardware. In addition, you can often share configuration files and CGI directories among the virtual servers, saving on disk space and implementation time. At many companies, the intranet and Internet servers exist as virtual servers on a single machine, allowing the costs of the physical hardware to be shared between both servers.
Finally, virtual hosting lets you create logical servers for supporting load balancing in the future. For example, your existing server may be fairly small, but you have big plans. You might consider creating a virtual server for your documents and another for your CGI scripts. In the near term, your single machine can handle both easily. When success finally strikes and you've swamped that first machine, you can install a new machine, move one of the virtual servers to it, and instantly double your machine capacity without changing a single URL in any document. A little bit of planning with virtual servers now might pay off big in the future.
Depending on server load and machine size, you can put a lot of servers on a single machine. This may seem implausible to those of you running Windows, where "multitasking" is defined as "running Word and a screen saver," but Unix machines are perfect engines for running many Web servers.
As an example, consider my principle Web server at Harris Corp. This machine is a SPARC 20 with two 75-MHz processors and 128 megabytes of RAM. It supports 48 virtual Web servers, sustaining 1.7 million hits last month. The machine also supports a community of 350 Unix users with perhaps 100 users logged in at any given time. With all of this, the machine is typically 50 percent idle.
A SPARC 20, of course, is a creaky old thing nearing the end of its product life cycle. A snappy new Ultra-class server from Sun would run rings around it. Sun recently announced that a 200-MHz, two processor Ultra 2 server was able to sustain 18 million hits per day! The machine probably doesn't care if you have one server taking all those hits, or 180 servers sustaining 100,000 hits each.
The bottom line: Virtual hosting reduces hardware expenditures, extends your ability to support additional servers, and makes load balancing and capacity planning much easier.
Preparing your machine
The first step in creating a virtual host is to define one or more additional virtual network interfaces for your machine. You'll need root access for this step, but don't worry, this is easy stuff.
Every machine on the network has one or more physical network
interfaces -- hardware devices that attach to the network. On almost
all Solaris machines, this device is named
that it is the first Lance Ethernet device on the machine. If you
install additional Ethernet interfaces, they'll be named
le2, and so forth.
In Solaris 2.5, it is possible to use an extension of this naming
scheme to define virtual interfaces atop a single physical interface.
To reference the first virtual interface on
le0, use the
le0:1. The next virtual interface would be
le0:2. You can keep going up to
you want, for a total of 256 interfaces (one physical, 255 virtual) on
a single interface.
These virtual interface names can be used anywhere you would
normally use the regular interface. To configure the interface and
make it available for use, you'll need to allocate an IP address for
it. Then use the
ifconfig command to bring the interface
ifconfig le0:1 18.104.22.168 -trailers up
ifconfig parameters to match your site's
network configuration requirements. And don't forget to use
your IP address in the command.
More than likely, you'll want to bring this interface up each time you boot the machine. To make this happen, do two things:
/etc/hostsfor the interface. This will look something like
22.214.171.124 virthost1Of course, use your IP address and a better host name than this example. For multiple virtual servers, add an entry for each server. Make sure your local domain name server is configured to correctly resolve and reverse these names and IP addresses.
/etc/hostname.le0:1. This file should contain a single line with the name of the virtual server. In this case, we'd put the name "virthost1" in this file. For multiple virtual servers, create a separate file for each virtual interface.
When Solaris boots, it looks in
/etc for files named
hostname and ending in either a physical or virtual device
name. It extracts the server name from the file, looks up the address
/etc/hosts, and brings up the physical or virtual
For complete documentation on how to do all this, check Sun's own documentation. Sun FAQ document 1579 explains how to configure virtual interfaces in great detail. Sun customers can view the document through SunSolve Online (see Resources below).
Curiously, Sun's documentation claims that virtual interface support
is a feature of Solaris 2.5, even though people are running virtual
servers on Solaris 2.4. I have experienced problems creating virtual
interfaces under Solaris 2.4 running patch 101945-42 (or later). Once
created, the interfaces run fine, but getting
work at boot is difficult. The quick fix is to bring the interfaces up
by hand using multiple invocations of
ifconfig le0:1 126.96.36.199 ifconfig le0:1 -trailers ifconfig le0:1 up
There seems to be a timing problem in the Ethernet driver that prevents
all these options from being used in one
Breaking things up seems to help, especially if you wait about five
seconds between commands.
One or many processes?
Now that you've got all these interfaces defined, it's time to tell your Web server to use them. To do this, you need to make a decision: One server process or many?
Both the Apache and NCSA http daemons can run in two modes. In the first, the server listens for client connects at a single address. In the second, the server can listen for connections on multiple addresses and serve different documents based on the address used by the client.
Both methods have advantages and disadvantages. The single server per address mode is useful when your various servers have very different configuration parameters, or you want to start and stop individual servers without perturbing the other servers. Multiple servers are also handy if you are charging for your servers based on CPU utilization, since the usage of each daemon is easily tracked by Unix. The downside is that running all those server daemons consumes additional machine resources, so that the maximum throughput of the machine may be less when running multiple daemons.
A single daemon servicing multiple requests is handy when all the servers can share most of the configuration parameters. If you anticipate servicing a lot of requests, the lower overhead of a single daemon may benefit you as well.
Regardless of which configuration you choose, it is not difficult to convert between the two. If you begin with a single server and want to switch to multiple servers later, you won't waste much effort in the interim.
Using multiple server processes
To start a Web server that listens for connections on exactly one address, add this line to your server's
Replace the name with either the domain name or IP address on which the server is to listen. When the server starts, it will bind to this address and listen for requests.
To create another server, replicate the http configuration files,
BindAddress directive, and start the new
server. You might want to establish some file naming conventions to
make life a bit easier if you intend to manage many servers. At my
site, for instance, a single top-level directory
/usr/local/http) holds all the servers. Within this
directory, each server has its own directory. Within each server's
directory you'll find all of the standard server directories, like
server has appropriate configuration directives that identify these
directories. To start each server, I add the
-d option to
the invocation of
httpd, supplying the appropriate server
root directory for that server.
Each time I need to create a new server on my machine, I just
replicate a "template" directory structure, edit the various
configuration files, and I'm ready to run. Since we charge for our
servers based on disk utilization, a simple
makes it easy to assess charges against each of my customers. Best of
all, I've got the ownership permissions set so that customers can
edit anything in their piece of the server tree, including their
configuration files, without affecting the other servers.
Using a single server process
Going the single server route is a bit more complicated. Instead of adding a
BindAddress directive to the configuration file,
you add a
VirtualHost section to
for each virtual server managed by the single server process. This
section looks something like this:
<VirtualHost name> DocumentRoot /usr/local/http/docs/server1 ServerName server1.mycompany.com ErrorLog /usr/local/http/logs/server1/error_log </VirtualHost>
Replace the name with the domain name or IP address of the
server you are creating. Within the
you can place almost any server configuration directive. I've shown the
most important ones. Since the whole point of running a single server
process is to share configurations, you'll want to include only those
directives that are unique to this server. The remaining directives
common to all the servers should be placed outside of any
VirtualHost section so that they apply to all of the
When running in this mode, you only start a single server process to create all of your virtual servers. If you stop that process, all of your servers stop. Be careful while performing system maintenance -- you don't want to shut down all your servers inadvertently when you really only wanted to change one.
For more information
The easiest way to learn about virtual servers is to start one up and experiment. While I've touched on all the important steps in this column, nothing beats a little hands-on experience.
If you want to read further about virtual hosts, the online documentation for both Apache and NCSA cover the topic. The Apache Virtual Host Support documentation is quite good. The NCSA Multihome tutorial includes pointers to related Solaris information.
About the author
Chuck Musciano has been running Melmac and the HTML Guru Home Page since early 1994, serving up HTML tips and tricks to hundreds of thousands of visitors each month. He's been a beta-tester and contributor to the NCSA httpd project and speaks regularly on the Internet, World Wide Web, and related topics. His book, HTML: The Definitive Guide, is currently available from O'Reilly and Associates.
If you have technical problems with this magazine, contact firstname.lastname@example.org