| |
This section contains information about the following topics:
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 address (for example, 10.1.1.1) are valued resources that are managed with great care. Opening port numbers can be especially time-consuming and political because of firewall and security issues.
For example, imagine using iChain to accelerate 100 backend origin Web servers. Each of these web servers will have their own IP address. In order to grant access to these Web servers through iChain, a DNS server must map each Web server name to an 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.
It is possible for iChain to multi-home all 100 backend 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-homed accelerators listening on one IP address.
There are four ways that iChain can multi-home origin Web servers on a single IP address port. Before these features are explained, some terms must be defined:
Host name --- In the URL http://www.novell.com/products/iChain, the host name is www.novell.com. The host name is used to name a Web server.
DNS name --- A DNS name is a host name that has been mapped to an IP address using a DNS server or DNS mapping table. A browser may use the "hosts" file on the local drive as a DNS mapping table.
Cookie Domain --- The cookie domain represents a group of host names that have in common two or more of the right-end piece of the host name. For example, "novell.com" is a cookie domain for both www.novell.com and download.novell.com.
Origin Web Server --- The origin Web server is a Web server that iChain accelerates through defining a Web Server Accelerator. A browser will not have direct access to an origin Web server and must obtain data from the Web server through iChain. The host name of an origin Web server may be different than the DNS name used by the browser. In fact, most iChain installations have a different DNS name than the host name of the origin Web server.
A multi-homing Web server is a Web server that can listen on a single IP address and multi-home the host name into multiple logical Web servers on the same machine. This is an easy way of having multiple alias names representing one host name. At the Web Server Accelerator screen, the user should select the radio button, "Use host name sent by browser (multi-homing web server". If a request is made on the accelerator IP address and port, the host name sent by the browser will not be checked against the DNS name of the accelerator.
This kind of multi-homing has some potential problems with iChain. The first issue is that any host name can come through that is unknown to iChain's Protected Resource List or Access Control List. iChain could restrict more URL references than the administrator's name.
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 a number of uncommon 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 will be three accelerators defined where each of the accelerators will read from three origin Web servers. See the table below:
Table 4.
Perhaps this configuration looks ready for customer use. A problem will arise, however, when either authentication is enabled or Secure Exchange is enabled for two or more of the above accelerators. When authentication or Secure Exchange is enabled, an SSL listening port will be 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 wild card host name (*.novell.com). A single certificate cannot be served to secure both www.a.com and www.b.com. Usually each accelerator will have its own unique SSL listening port for an IP address. See Table 5.
Table 5.
| DNS Name | Accelerator IP Address | Accelerator Proxy Port | SSL Listening Port |
|---|---|---|---|
www.a.com |
100.1.1.1 |
80 |
443 |
www.b.com |
100.1.1.1 |
80 |
444 |
www.c.com |
100.1.1.1 |
80 |
445 |
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 Table 6).
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. In the initial iChain 2.1 version, the master also defines the authentication and Secure Exchange options.
Table 6.
The same SSL port can be used for a group of domain-based accelerators if the SSL certificate supports wild card host names. In Table 6, the SSL certificate would be "*.acme.com".
NOTE: There are some browser versions that will give a warning that the host name doesn't match the certificate name when a wild card certificate is used. If the AUTO certificate is used, iChain will create a wild card certificate using the cookie domain value.
Path-based multi-homing is selectable when "Enable multi-homing" is checked. 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 wild card 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 or ending 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. In the initial iChain 2.1 version, the master also defines the authentication and Secure Exchange options.
Table 7.
There are three types of options for a path-based multi-homing child. Table 8, Table 9, and Table 10 outline the URL requested from the browser and the URL that will be submitted to the origin Web server.
Table 8. "Starts with" option, sub-path match string = /Bstuff, remove sub-path from URL checked
URL from browser |
URL to web server |
http://a.acme.com/Bstuff/index.html |
http://b.internal.com/index.html |
This first example is the most common use of path-based multi-homing. A base path is used to tell 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 so that the sub-path is present. For example, a reference in the HTML page may have "href=/index.html". The rewriter will rewrite this reference as "href=/Bstuff/index.html" so that the browser will set the correct GET request and iChain will map the request to the correct accelerator.
Table 9. "Starts with" option, sub-path match string = /Bstuff
URL from browser |
URL to web server |
http://a.acme.com/Bstuff/index.html |
http://b.internal.com/Bstuff/index.html |
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 Table 8.
Table 10. "Ends with" option, sub-path match string = jpg
URL from browser |
URL to web server |
http://a.acme.com/logos/companyLogos.jpg |
http://b.internal.com/logos/companyLogos.jpg |
The ZXY Company wants to accelerate its support and sales Web sites as a single external Web site.
The administrators sets up two accelerators for www.zxy.org on the same IP address and port number, and configures them with path-based multi-homing rules.
One accelerator has a rule for paths that start with /sales, the other has a rule for paths that start with /support.
Customers can now access the single www.zxy.org Web site and have all requests starting with www.zxy.org/sales be directed to the sales Web server farm, and all requests starting with xxx.zxy.org/support be directed to the support Web server farm.
The ZXY Company can decide whether a URL such as www.zxy.org/sales/newproducts.html gets sent to the Web server with sales included in the path (www.zxy.org/sales/newproducts.html) or without sales included in the path (www.zxy.org/newproducts.html) by selecting whether the matching starting substring is removed from the path.
CAB Unlimited has a Web site consisting of the following components:
CAB Unlimited sets up four accelerator services for www.cab.org on the same IP address and port, and configures them with path-based multi-homing rules.
One accelerator has a rule for paths that end with .ASP. The second has a rule for paths that end with JPEG. The third accelerator has a rule for paths that end with GIF. The fourth accelerator is configured as the default for all other paths.
Browsers can now access the single www.cab.org Web site and have requests for www.cab.org/main.asp get directed to the ASP Web server farm, requests for www.cab.org/logo.gif and www.cab.com/photo.jpg get directed to the graphics Web server farm, and requests for www.cab.com/directory.html get directed to the third Web server farm.
| |