Deploying Virtual Servers

Sun Java System Web Server’s virtual server architecture is very flexible. A server instance can have any number of secure and non-secure listen socket. You can have both IP-address-based and URL-host-based virtual servers.

In addition, you can group virtual servers with similar settings into any number of virtual server classes. All virtual servers in a virtual server class share the same request processing instructions in obj.conf.

Every virtual server can (but does not have to) have its own list of ACLs, its own mime.types file, and its own set of Java Web Applications.

This design gives you maximum flexibility to configure the server for a variety of applications. The following examples discuss some of the possible configurations available for Sun Java System Web Server.

Example 1: Default Configuration

After a new installation of the Sun Java System Web Server, you have one server instance. This server instance has just one listen socket listening on port 80 (or whatever you selected at installation) of any IP address to which your computer is configured.

Some mechanism in your local network establishes a name-to-address mapping for each of the addresses to which your computer is configured. In the following example, the computer has two network interfaces: the loopback interface (the interface that exists even without a network card) on address 127.0.0.1, and an ethernet interface on address 10.0.0.1.

The name example.com is mapped to 10.0.0.1 via DNS. The listen socket is configured to listen on port 80 on any address to which that machine is configured ("ANY:80" or "0.0.0.0:80").

Figure 13–3 Default configuration

In this configuration, connections to the following reach the server and are served by virtual server VS1

• http://127.0.0.1/ (initiated on example.com)

• http://localhost/ (initiated on example.com)

• http://example.com/

• http://10.0.0.1/

Use this configuration for traditional web server use. You do not need to add additional virtual servers or listen sockets. You configure the settings of the server by changing the settings for defaultclass (VS1 is a member of defaultclass), and the VS1 itself.

Example 2: Secure Server

If you want to use SSL in the default configuration, you can simply change the listen socket to secure mode. Just as you set security in previous versions of the Sun Java System Web Server.

You can also add a new secure listen socket configured to ANY:443 and associate VS1 to the new listen socket. The virtual server now has listen sockets, one that uses SSL, and one that doesn’t. Now your server will serve the same content both with and without SSL, i.e. http://example.com/ and https://example.com/ deliver the same content.

Figure 13–4 Secure Server

Please note that the SSL parameters are attached to the listen socket. Therefore, there can only be one set of SSL parameters for all the virtual servers configured to a particular listen socket.

Example 3: Intranet Hosting

A more complex configuration of the Sun Java System Web Server is one in which the server hosts a few virtual servers for an intranet deployment. For example, you have three internal sites where employees can look up other users’ phone numbers, look at maps of the campus, and track the status of their requests to the Information Services department. Previously (in this example), these sites were hosted on three different computers that had the names phone.example.com, maps.example.com and is.example.com mapped to them.

To minimize hardware and administrative overhead, you want to consolidate all three sites into one web server living on the machine example.com. You could set this up in two ways: using URL-host-based virtual servers or using separate listen sockets. Both have their distinct advantages and disadvantages.

Figure 13–5 Intranet Hosting Using URL-host-based Virtual Servers

While URL-host-based virtual servers are easy to set up, they have the following disadvantages:

• Supporting SSL in this configuration requires non-standard setup using wildcard certificates. For more information see Chapter 5, J2SE-based Security for Web Container and Web Applications.

• URL-host-based virtual servers don’t work with legacy HTTP clients

You could also set up the IP-address-based configuration with one listen socket per address:

Figure 13–6 Intranet Hosting Using Separate Listen Sockets

The advantages to IP-address-based virtual servers are:

• They work with older clients that do not support the HTTP/1.1 Host header.

• Providing SSL support is straightforward.

The disadvantages are:

• They require configuration changes on the host computer (configuration of real or virtual network interfaces)

• They don’t scale to configurations with thousands of virtual servers

Both configurations require setting up name-to-address mappings for the three names. In the IP-address-based configuration, each name maps to a different address. The host machine must be set up to receive connections on all these addresses. In the URL-host-based configuration, all names can map to the same address, the one the machine had originally.

The configuration with multiple listen sockets could give you a minimal performance gain because the server does not have to find out the address the request came in on. However, using multiple listen sockets also results in additional overhead (memory and scheduling) because of the additional acceptor threads.

Example 4: Mass Hosting

Mass hosting is a configuration in which you enable several low-traffic virtual servers. For example, an ISP that hosts many low-traffic personal home pages would fall into this category.

The virtual servers are usually URL-host-based and are in one of multiple virtual server classes, depending on the level of service provided. For example, you could have one class that allows only static content, and another one that allows static content plus CGIs.

Figure 13–7 Mass Hosting

Notice that the virtual server installed when you installed the server, VS1, still exists in defaultclass.