Click on our Sponsors to help Support SunWorld
Webmaster by Chuck Musciano

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

SunWorld
January  1997
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
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)


Mail this
article to
a friend
Running a Web server is like eating potato chips: It's hard to stop after just one. As soon as that first site is up, you can think of a dozen good reasons to start another. In the early days of the Web, this was little more than a dream because starting another site meant buying another machine. In those days, Web servers could not co-exist peacefully on a single machine.

Happy Birthday!

As 1997 starts, I'm pleased to see my column turn one year old. With twelve of these articles under my belt, I'm looking forward to another year of tips, tricks, and advice. More than anything else, I appreciate your support and interest as this column has evolved and grown. In the past year, the Webmaster column has focused on technology, with a nuts-and-bolts approach to building, running, and improving Web servers. Reader feedback has been good, but I want to make sure I'm hitting all the right topics as we move forward through the coming year. Is there a topic you'd like to see covered? A burning question you need answered? A gripe you need addressed? Let me know, and I'll work it into an upcoming column. I've appreciated your feedback in the past year, and I'm soliciting it now to shape the coming year. So, take a moment, drop me a line, and give me your two cents worth. I'll look forward to hearing from you! --Chuck Musciano

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.

Advertisements

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.
As always, I'll be covering the specifics for NCSA and Apache servers running under Solaris. If you run another server or operating system, consult your documentation for the details about your server.

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 le0, meaning that it is the first Lance Ethernet device on the machine. If you install additional Ethernet interfaces, they'll be named le1, 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 name le0:1. The next virtual interface would be le0:2. You can keep going up to le0:255, if 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 up: 

     ifconfig le0:1 128.195.10.31 -trailers up

Adjust the 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:

  1. Add an entry in /etc/hosts for the interface. This will look something like 
         128.195.10.31   virthost1
    Of 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.

  2. Create /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 in /etc/hosts, and brings up the physical or virtual interface.

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 ifconfig to work at boot is difficult. The quick fix is to bring the interfaces up by hand using multiple invocations of ifconfig: 

     ifconfig le0:1 128.195.10.31
     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 ifconfig command. 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 httpd.conf file: 

     BindAddress name

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, change the 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 conf, cgi-bin, and logs. Each 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 du command 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 httpd.conf 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 VirtualHost section 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 virtual hosts.

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.


Click on our Sponsors to help Support SunWorld

Resources

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.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-01-1997/swol-01-webmaster.html
Last modified: