| Using ClusterCATS |
|
|
Installing ClusterCATS |
|
| Using ClusterCATS |
|
|
Installing ClusterCATS |
|
Before installing ClusterCATS and creating server clusters, you must perform the following pre-installation tasks:
To update the ClusterCATS application while preserving your configuration settings, re-install ClusterCATS using the instructions in this chapter. The ClusterCATS installation detects that a configuration is available for use and prompts you by asking whether you want to use the configuration in the new installation. You can use the ClusterCATS Server setup options, or keep the existing cluster configurations.
ClusterCATS software requires that both the forward lookup (host name-to-address translation) and reverse lookup (address-to-host name translation) be registered with your DNS server. For evaluation purposes, you can use host files, but this is not recommended in a production environment.
Note: ClusterCATS does not support Dynamic Host Configuration Protocol (DHCP). A unique IP address must be assigned to each web server.
This section addresses the following topics:
When you enter a URL into a web browser, the browser is able to locate the website you want to visit because of the name-to-IP address translation that the Internet Domain Name System (DNS) performs. This section reviews two important components of the DNS infrastructure that enable this capability - primary DNS servers and local DNS servers.
The primary DNS server provides the final mapping of a website name to the computer on which a website resides. The primary DNS server can be located anywhere on the Internet, but most reside either in the same physical location as the web servers or at the ISP that provides the connection between the web servers and the Internet.
The primary DNS server contains tables of forward and reverse name translations. For example, forward translation entries (A records) look like this:
| www1.company.com |
192.168.0.1 |
| www2.company.com |
192.168.0.2 |
Reverse translation entries (PTR records) are opposite, and look like this:
| 192.168.0.1 |
www1.company.com |
| 192.168.0.2 |
www2.company.com |
Configure your websites with forward and reverse DNS entries on your primary DNS server. If you are not responsible for maintaining your primary DNS server, tell your DNS administrator to add forward and reverse entries for your explicit web server names (www1.company.com, www2.company.com, and so on).
Note: ClusterCATS does not operate correctly unless both forward and reverse translations are configured for each explicit web server.
A local DNS server usually resides at a web hosting facility. The local DNS server stores its own local table of name translations for the websites that the browser visits. If a user enters a URL in a browser that the browser has already visited, it retrieves the host name-to-IP address translation from the local DNS server's table. However, if a user enters a URL for a site that the browser on that computer has never visited, the local DNS server must access the primary DNS server on the Internet to resolve the name-to-IP mapping before the browser can send a request to the appropriate web server.
To summarize, primary and local DNS servers work together to resolve name-to-IP address mappings in the following way:
If round-robin DNS is in use, the primary DNS server determines which server in the cluster is next in line to receive the request.
The following diagram shows this process:
You must configure DNS so the forward and reverse lookup translation entries are entered and registered correctly with your primary DNS server. To do this, you must define DNS A and PTR DNS records for the web servers on your primary DNS server.
Besides standard name translations, your primary DNS server can distribute HTTP requests sequentially across clustered servers, using a technique called round-robin DNS. This service lets DNS return a list of multiple servers to the browser that requests a name translation.
Round-robin DNS and ClusterCATS work well together. You should not rely on just round-robin DNS for distributing load for your business-critical sites, because DNS functionality is limited. In short, DNS is a good load distribution technique, but it cannot manage load because it cannot react to increases in server traffic. It also cannot detect server failures, nor redirect requests among available servers. ClusterCATS compensates for these limitations.
Macromedia recommends that you use round-robin DNS or a hardware load-balancing device to distribute requests initially to the web servers in your cluster. After the initial distribution, ClusterCATS load management and failover features automatically take over and ensure that your web applications remain up and running.
For high-volume sites, you should use round robin DNS to initially distribute requests to the web servers in your cluster. The load management component of ClusterCATS enhances round-robin DNS by eliminating its two major limitations:
You must ensure that round-robin DNS entries are configured correctly on your primary DNS server so ClusterCATS operates effectively with round-robin DNS. For example, for a single-location server cluster consisting of four servers, you must configure round-robin DNS across all four servers for the domain name, and individual IP addresses for each explicit server name.
For example, the DNS table forward entries on your primary DNS server would be similar to these:
The DNS table reverse entries on your primary DNS server would be similar to these:
| IP Address |
Host Name |
|---|---|
| 193.168.0.1 |
www1.company.com |
| 193.168.0.2 |
www2.company.com |
| 193.168.0.3 |
www3.company.com |
| 193.168.0.4 |
www4.company.com |
Note: When using round-robin DNS, do not define a reverse mapping (PTR record) for the site name (www.company.com); the cluster will not operate properly if you do. Define only forward mappings (A records) for www.company.com. Define A records and PTR records for all explicit servers (www1, www2,...) in the cluster. This configuration ensures that requests cycle through the servers sequentially, or "round-robin."
Round-robin DNS distributes the initial domain-level requests across all four servers. Thereafter, ClusterCATS distributes load to avoid failed or overloaded servers.
ClusterCATS protects clusters from server hardware and software failures. When a server is no longer sending or receiving packets from the network, its IP address (and, therefore, its HTTP requests) are assumed by another cluster member, which picks up HTTP traffic originally addressed to the failed server. Server failover services are provided per subnet.
Server failover is an option to select during the installation process. If you do not do so, you must reinstall ClusterCATS and select that option. On Windows systems, preparing your site for ClusterCATS Server failover can require uninstalling your web server software. For more information, see "Using Server Failover".
You can set up your website so ClusterCATS dynamically assigns IP addresses to your web servers. This addressing scheme includes a static maintenance address for each server that lets you and ClusterCATS contact the server at any time, even during a web server failure.
The setup for ClusterCATS dynamic IP addressing varies depending on your cluster's operating system:
Many corporate environments today rely on firewalls to securely control access to proprietary knowledge that resides on public Internet sites, internal intranet sites, or private extranet sites. You can configure ClusterCATS to work seamlessly across one or more firewalls.
A common technique is to use NAT as a security precaution on your firewall. This configuration segregates internal and external resources and facilitates extra control and monitoring of web traffic. For more information, see Macromedia Knowledge Base Article 15339.
If multiple, distributed server clusters support a domain, you must open appropriate ports on each firewall to ensure that the server clusters' load-balancing and failover features work. For example, if you cluster multiple, distributed web servers that have a firewall between them, you must open ports 9123 and 9129 on the firewall that separates them to enable server-to-server communications. Also, if you will manage your cluster from behind another firewall, you must open both ports so the ClusterCATS Explorer can communicate with the cluster.
The following diagram shows this scenario:
This scenario involves Company ABC, which has East Coast and West Coast server groups connected to the Internet, protected by several firewalls. The ClusterCATS Explorer resides at the corporate headquarters behind a firewall with a direct connection to the Internet.
You must open and configure the appropriate communication ports on your firewalls to allow server-to-server communication in a distributed setting and server-to-client communication.
Note: You must open both ports on all affected firewalls.
These ports include the following:
All web servers, virtual servers, or websites in a cluster must have identical content.
You should specify the same default document for each web server in the cluster. For example, set the default document to default.jsp.
If you use Windows NT Domain server authentication, each web server in a cluster must participate as a member NT server in a domain. Do not set a server in your cluster as the primary domain controller (PDC). ClusterCATS Server failover will interfere with the function of the PDC. An NT server can be a backup domain controller, but this is not the recommended configuration.
