4.7.1 What Is Multi-Homing?

Multi-homing is the ability to read from multiple origin Web servers over the same IP address and IP port.

Within a large company or corporation, IP addresses (for example, 10.1.1.1) are valued resources that are carefully managed. Opening additional ports can be time-consuming and political because of firewall and security issues.

For example, imagine using iChain to accelerate 100 back-end origin Web servers. Each of these Web servers has its own IP address. In order to grant access to these Web servers through iChain without multi-homing, a DNS server must map each Web server name to a separate IP address that iChain is listening on. A simple mapping would mean that 100 IP addresses would be needed by iChain to map to 100 backend Web servers.

With multi-homing, it is possible for iChain to provide access to all 100 back-end origin Web servers through one IP address and port. Most installations, however, will organize the origin Web servers into a handful of groups where each group is a group of multi-homing accelerators listening on one IP address.

There are four ways that iChain can multi-home origin Web servers on a single IP address and port. Before these features are explained, some terms must be defined:

4.7.2 Multi-Homing Web Server

A multi-homing Web server is a Web server that listens on a single IP address and directs incoming requests to multiple logical Web servers running on the same machine. This is an easy way of having multiple alias names representing one host name. At the Web Server Accelerator page, you should select the Use Host Name Sent by Browser (Multi-homing Web Server) option. If a request is made on the accelerator IP address and port, the host name sent by the browser is not checked against the DNS name of the accelerator.

4.7.3 Host-Based Multi-Homing

Host-based multi-homing is not one of the standard multi-homing options for an accelerator. Host-based multi-homing is a way to listen for requests to a number of different host names on a single IP address and port. For example, www.a.com, www.b.com, and www.c.com can have the same DNS table entry of 100.1.1.1. There would be three accelerators defined, where each of the accelerators reads from three origin Web servers. See the table below:

If either authentication is enabled or Secure Exchange is enabled for two or more of the above accelerators, you must specify a unique SSL listening port. When authentication or Secure Exchange is enabled, an SSL listening port is issued to the accelerator. Two or more accelerators cannot listen on the same SSL port unless multi-homing is enabled. This is because a certificate must be used to establish an SSL connection. The certificate has the host name or a wildcard host name (*.novell.com). A single certificate cannot be served to secure both www.a.com and www.b.com. Usually each accelerator has its own unique SSL listening port for an IP address. See the table below.

4.7.4 Domain-Based Multi-Homing

Domain-based multi-homing is selectable when Enable Multi-Homing is checked. To be more specific, this feature could be named Cookie-Domain-Based Multi-Homing because all of the DNS names for the accelerators in the multi-homing have the same cookie domain (see acme.com in the table below).

There must be a master accelerator already defined. A master accelerator is not part of a host-based multi-homing group and is not a child of a multi-homing group. The master defines the cookie domain, accelerator IP address, accelerator proxy port, SSL listening port, and certificate.

The same SSL port can be used for a group of domain-based accelerators if the SSL certificate supports wild card host names. In the table above, the SSL certificate would be *.acme.com.

4.7.5 Path-Based Multi-Homing

Path-based multi-homing is available when you select Enable Multi-Homing. Path-based multi-homing could be considered the most secure option because an SSL certificate containing a host name is used. The belief exists that wildcard certificates are less secure than a certificate with just a host name. All accelerators that participate in a path-based group have the same DNS name. All children must have a unique starting path.

The same rules apply as they do for a domain-based multi-homing master: There must be a master accelerator already defined. A master accelerator is not part of a host-based multi-homing group and is not a child or a multi-homing group. The master defines the cookie domain, accelerator IP address, accelerator proxy port, SSL listening port, and certificate.

There are two types of options for a path-based multi-homing child. The next two tables outline the URL requested from the browser and the URL that will be submitted to the origin Web server.

Sub-Path Match String = /Bstuff, Remove Sub-Path from URL

This first example is the most common use of path-based multi-homing. A base path tells iChain that a specific accelerator is to be used to service the request. The base path is stripped when requesting the page from the Web server. Within the HTML pages that come from the Web server, all absolute and some relative references are rewritten by iChain so that the sub-path is present. For example, a reference in the HTML page might have href=/index.html. The rewriter rewrites this reference as href=/Bstuff/index.html so that the browser sets the correct GET request and iChain maps the request to the correct accelerator.

iChain can easily locate absolute path references because only the data coming from a path-based multi-homed accelerator is considered for this kind of rewriting. The word parser in iChain then locates all of the valid URL tags (href, src, action, etc.) and adds the subpath if the reference is an absolute-path reference. Absolute-path references that are outside of these tags are not considered for rewriting because there are too many variations of what the sub-path information could be.

Sub-Path Match String = /Bstuff

This second example expects the sub-path match string to be present as a valid path on the origin Web server. The rewriter doesn't need to update the absolute references as it did in the previous table.

4.7.6 Path-Based Multi-Homing Example

The information in the following example uses the Multi-homing Options dialog box.