# Before You Install

Before you install ClusterCATS and begin creating your server clusters, perform the following pre-installation tasks.

- "Review the release notes"
- "Verify system requirements"
- "Configure your primary DNS server"
- "Configure your Web server's network settings"
- "Configure ClusterCATS for use across firewalls"

## Review the release notes

Frequently, users bypass the product release notes and go right to the install program so that they can get the product up and running as soon as possible. However, software issues, incompatibilities, and any workarounds are often discovered and documented just before the software ships, long after the official product documentation has been finished. As such, it's best to review the product release notes before you get started so that you save yourself time and unnecessary frustration.

## Verify system requirements

This section describes the platforms on which the ClusterCATS components run and their minimum system requirements.

### ClusterCATS Server system requirements

You must install the ClusterCATS Server component on each server in your cluster. Make sure your server meets the minimum system requirements for your platform as described below.

#### Windows NT system requirements for ClusterCATS Server

- Intel Pentium 200 Mhz or greater CPU
- 100 MB of free disk space
- 128 MB of RAM
- Windows NT operating system v4.0 or greater
- Windows NT Service Pack 4 or greater
- Internet Information Server v4.0 or greater or Netscape Enterprise Server v3.5.1
- Administrative privileges on each server
- An IP address assigned to each server
- Correct DNS entries and configurations (see "Configure your primary DNS server").

  Note | ClusterCATS Server does not run on Windows 98 or Windows 95.

#### Sun Solaris system requirements for ClusterCATS Server

- Sun SPARC workstation
- 100 MB of free disk space
- 128 MB of RAM (more recommended)
- Solaris operating system v.2.51 or greater with Patch 103582-18 or higher
- Netscape Enterprise Server v3.5.1 or greater or Apache Web Server v1.3.6 or greater
- Administrative root privileges on each server
- An IP address assigned to each server
- Correct DNS entries and configurations (see "Configure your primary DNS server")

#### Linux system requirements for ClusterCATS Server

- Intel Pentium 200 Mhz or greater
- 100 MB of free disk space
- 128 MB of RAM (more recommended)
- Red Hat operating system v.6.0
- Apache Web Server v1.3.6 or greater
- Administrative root privileges on each server
- An IP address assigned to each server
- Correct DNS entries and configurations (see "Configure your primary DNS server")

### ClusterCATS Explorer system requirements

You can install the ClusterCATS Explorer component on a computer separate from the cluster so that you can administer the cluster from a central location, but you don't have to. However, if you do, make sure the computer on which you install this component meets the minimum system requirements.

#### System requirements for the Windows-based Explorer

The Windows-based ClusterCATS Explorer runs from a Windows machine (NT, 98, or 95), regardless of the platform on which you install ClusterCATS Server. Its system requirements are as follows:

- Intel Pentium 166 Mhz or greater CPU
- 50 MB of free disk space
- 64 MB of RAM
- Windows NT operating system v4.0 or greater, or Windows 98, or Windows 95
- Windows NT Service Pack 4 or greater (if running Windows NT)
- Administrative privileges

#### System requirements for the ClusterCATS Web Explorer

Use the ClusterCATS Web Explorer if you have a UNIX-only environment and cannot obtain a Windows machine to run the Explorer. Install the ClusterCATS Web Explorer program on a UNIX server that meets the following requirements:

- Sun SPARC workstation
- 75 MB of free disk space
- 128 MB of RAM (more recommended)
- Solaris operating system v.2.51 or greater with Patch 103582-18 or higher
- Netscape Enterprise Server v3.5.1 or greater or Apache Web Server v1.3.6 or greater

Use a Web browser (Microsoft Internet Explorer 4.0 or greater or Netscape Navigator 3.0 or greater) from a Windows or UNIX machine to access the Web Explorer program you installed on the UNIX box. See "Using the ClusterCATS Web Explorer".

## Configure your primary DNS server

When you enter a URL into a Web browser and press Enter, the browser is able to locate the Web site 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.

Note | This section assumes that your primary DNS server is already set up correctly. If it is not, consult a DNS configuration book or a DNS consultant to help prepare your DNS server. We recommend that you do not use a Hosts file in a production environment, as it is less reliable than DNS.

This section addresses the following topics:

- "Understanding local and primary DNS servers"
- "Configuring DNS records on your primary DNS server"

### Understanding local and primary DNS servers

The two types of DNS servers involved in the name-to-IP mapping translation are primary DNS servers and local DNS servers.

The primary DNS server is a computer that runs DNS software, which provides the final mapping of your Web site name to the computer that your Web site actually resides on. The primary DNS server may 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 your Web servers and the Internet.

The primary DNS server contains tables of forward and reverse name translations. For example, forward translation entries (A records) would look like this:

www1.company.com | 192.168.0.1
www2.company.com | 192.168.0.2

Reverse translation entries (PTR records) are just the opposite and would look like this:

192.168.0.1 | www1.company.com
192.168.0.2 | www2.company.com

It's important that you configure your Web sites to have both forward and reverse DNS entries on your primary DNS server. If you are not responsible for maintaining your primary DNS server, be sure to tell your DNS administrator to add both forward and reverse entries for your explicit Web server names (www1.company.com, www2.company.com, etc.). If both forward and reverse translations aren't configured for each explicit Web server, ClusterCATS won't operate correctly.

A local DNS server usually resides at the Web hosting facility. The local DNS server stores its own local table of name translations for the Web sites that the browser has visited. If a user enters a URL of a site 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.

1. A user enters a Web site URL in his or her browser and presses Enter.
2. The browser checks the local DNS server for the name-to-IP address mapping. The local DNS server typically resides at the facility where the Web servers are hosted.
3. If the local DNS server does not have the mapping, it goes out to the Internet and locates the primary DNS server to look up the name-to-IP address mapping.

   If round-robin DNS is being used, the primary DNS server determines which server in the cluster is next in line to receive the request.

4. The primary DNS server sends back the translation to the local DNS server, which in turn sends it to the user's browser.
5. The browser is now able to send an HTTP request to the correct Web server hosting the site.

The following diagram illustrates this process.

### Configuring DNS records on your primary DNS server

You must configure DNS so that both the forward and reverse lookup translation entries are entered and registered correctly with your primary DNS server. To accomplish this, you must define required DNS records (A records and PTR records) for your Web servers on your primary DNS server.

Besides standard name translations, your primary DNS server can also distribute HTTP requests sequentially across clustered servers using a technique called round-robin DNS. This service allows DNS to return a list of multiple servers back to the browser that requests a name translation.

Round-robin DNS and ClusterCATS work well together. You don't want to 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 is unable to react to increases in server traffic. It also cannot detect server failures nor redirect requests among available servers. ClusterCATS compensates for these limitations.

Allaire recommends that you use round-robin DNS or a hardware load balancing device to distribute requests initially to the Web servers in your cluster. Following the initial distribution, the ClusterCATS load management and failover features automatically take over and ensure that your ColdFusion applications remain up and running.

#### Using ClusterCATS with round-robin DNS

So that ClusterCATS operates effectively with round-robin DNS, you need to ensure that round-robin DNS entries are configured correctly on your primary DNS server. For example, for a single-location server cluster consisting of four servers, you need to configure round-robin DNS across all four servers for the domain name and individual IP addresses for each explicit server name. As an example, your DNS tables on your primary DNS server would look similar to the tables that follow.

Forward DNS Entries with Round Robin Enabled
Host Name | IP Address
--- | ---
www.company.com | 193.168.0.1
193.168.0.2
193.168.0.3
193.168.0.4
www1.company.com | 193.168.0.1
www2.company.com | 193.168.0.2
www3.company.com | 193.168.0.3
www4.company.com | 193.168.0.4

Reverse DNS Entries for Explicit Server Names
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. Only define forward mappings (A records) for www.company.com. However, define both A records and PTR records for all of the explicit servers (www1, www2,...) in the cluster. This configuration ensures that requests cycle through the servers sequentially in round-robin fashion.

Round-robin DNS distributes the initial domain-level requests across all four servers. Thereafter, ClusterCATS distributes load to avoid failed or overloaded servers.

| To configure DNS records on your Windows NT DNS server:

1. On your primary DNS server, click Start>Administrative Tools>DNS Manager.

   The DNS Manager utility appears.

2. Right-click the zone created for your site and choose New Host.

   The New Host dialog box appears.

3. Enter `www` in the Host Name field and enter the IP address of a server that will host the site in the Host IP Address field.

   Note | Do not enable the Create Associated PTR Record check box. You only want forward mappings associated with the site name and no reverse mappings for round-robin DNS to work properly.

4. Click Add Host.
5. Repeat steps 3 and 4 for each server hosting the site that will be in your cluster.
6. Click Done to close the New Host dialog box.

   Your entries should look similar to the following entries when you're done.

7. Right-click the zone for your Web site again and select New Record.

   The New Resource Record dialog box appears.

8. Ensure that the A Record record type is selected from the Record Type list box.

   Note | ClusterCATS requires that the explicit servers you use to host your Web site have associated A records defined for them in DNS, not CNAME records.

   A Records correlate to Address records for your hosts, CNAME Records correlate to aliases you want to use for your hosts, and PTR records correlate to reverse name translations (IP address to Host name).

9. Enter the Host name and corresponding IP address for an explicit Web server that will host your Web site in the Host Name and IP Address fields, respectively.

   For example, your explicit Host Name entry might be www1 and the IP Address for that server might be 193.168.03.1.

10. Leave the Create Associated PTR Record check box enabled to automatically create the required reverse mapping record (IP address to host name) for each explicit server.
11. Click OK.
12. Repeat steps 6 through 10 for each explicit server hosting the site that will be in your cluster.

    The DNS record entries for your site should look similar to the following entries when you're done.

#### To configure DNS records on your UNIX-based DNS server

See the operating system documentation that came with your UNIX server for specific procedures about how to define DNS records on your UNIX-based DNS server.

## Configure your Web server's network settings

Successful clustering depends highly on whether you've configured your Web server's network settings properly. To understand how specific network configurations affect clustering, let's review important server failover concepts.

ClusterCATS uses an "IP keep alive" strategy to accomplish transparent server failover when a Web server fails. This process involves each server in the cluster listening for an IP signal from each server. If a server stops emitting the signal, ClusterCATS assumes there is a problem with the server and restricts it from processing any additional requests. The least loaded available server in the cluster assumes the IP address of the restricted server, and all subsequent requests are redirected to the failover server until the restricted server's problems are fixed. This process of moving a Web site IP address from one server to another in the cluster is known as dynamic addressing.

In order for ClusterCATS to perform dynamic addressing, your Web server must have a specific network name and IP address configured for it. Additionally, it must reference a valid local DNS server so that it can properly translate names to correct IP addresses.

This section describes the following Web server network configuration procedures:

- "Configuring your Web server to point to your local DNS server"
- "Configuring ClusterCATS offline maintenance support (NT only)"

### Configuring your Web server to point to your local DNS server

You must configure each Web server in your cluster to reference your local DNS server so that name to IP address mapping resolutions can occur.

| To configure Windows NT Web servers to reference your DNS server:

1. Click Start>Settings>Control Panel.
2. Open the Network icon.
3. Click the Protocols tab and select the TCP/IP protocol from the list of Network Protocols.
4. Click Properties.

   The Microsoft TCP/IP Properties dialog box appears.

5. Click the DNS tab.

6. Enter the name of the server that is hosting the Web application in the Host Name field.
7. Enter the domain name (yourcompany.com) in the Domain Name field.
8. In the DNS Service Search Order area, click Add to enter the IP addresses of your local DNS server(s).

   You may have several local DNS servers if you have different subnets on your network. If so, add each IP address individually by clicking the Add button for each server.

9. After adding the IP address(es), use the arrows on the right if applicable to specify the order in which the DNS servers will be accessed.
10. Click OK in all open dialog boxes and close the Windows Control Panel.

#### To configure UNIX-based Web servers to reference your DNS server

See the UNIX operating system documentation that came with your server for specific procedures about how to configure your Web server to reference your local DNS server.

### Configuring ClusterCATS offline maintenance support (NT only)

Before attempting to configure the ClusterCATS offline maintenance support feature, review the first two sections below thoroughly to understand what offline maintenance support is and how static and dynamic IP addresses enable this functionality. Then proceed with the configuration procedures.

This section describes the following topics:

- "The ClusterCATS offline maintenance mode defined"
- "Understanding static and dynamic IP address configurations"
- "Configuring offline maintenance support (Windows NT only)"

#### The ClusterCATS offline maintenance mode defined

ClusterCATS provides an offline maintenance feature (available on the Windows NT platform only) that requires you to perform some initial IP address configurations before being able to use the feature. You are not required to configure maintenance addresses in order to use ClusterCATS. However, Allaire highly recommends that you do so because maintenance IP addresses:

- Guarantee that you can always access servers in your cluster remotely if they fail or become unavailable.

  Binding a static IP address to the server ensures that you can always access the box even if the Web server on it fails.

- Allows you to perform maintenance and server-update tasks without disconnecting servers from the network.

  By placing a clustered server in maintenance mode, you can perform necessary software updates or configurations while ensuring that your site remains up and servicing your customers.

- Prevents your site from experiencing long down times on failover recovery.

  Without maintenance addresses your site will experience three to five minutes of downtime on failover recovery due to an automatic system reboot that occurs when a system comes back online following failover.

Once you put a server in maintenance mode, all inbound HTTP traffic heading for the affected server is redirected to the most available server in the cluster. After you complete your maintenance tasks and take the server out of maintenance mode, the servers that temporarily assumed the restricted server's IP address and HTTP traffic return the IP address back to the affected server so that it can receive and process HTTP requests.

#### Understanding static and dynamic IP address configurations

Each server that you add to a cluster must have an Internet protocol (IP) address defined for it. Because the Internet operates on a TCP/IP network protocol for sending and receiving packets of data to and from networked computers, you must correctly define your servers' IP addresses so that they can send and receive network data as intended.

The static address must be assigned to the server itself -- the physical box. You do so by making an entry in the server's IP stack. On Windows servers, you add this IP stack entry using the Network icon in the Windows Control Panel. This Network icon is also commonly referred to as your Network Interface Card (NIC). In addition to assigning the server's static address, you must make sure that the Web sites' static IP addresses that reside on the Web server on this machine get removed from the IP stack (also via the Network icon in the Control Panel). Typically, you or someone else added the Web site IP addresses to the server's IP stack before installing ClusterCATS and creating clusters. You now need to manually remove those IP addresses so that ClusterCATS can dynamically create them in the IP stack according to server load and availability in the cluster.

Understanding the roles of static and dynamic IP addresses can be confusing, so let's look at an example. Suppose I have a Web site, www.website.com, on my Web server that I created months ago before I acquired and began using ClusterCATS. I now want to cluster several Windows NT servers and configure them for maintenance support.

1. On one of the servers I plan to cluster, I enter a static IP address for the server in its IP stack (via the NIC) if one doesn't already exist.
2. I then remove the Web site's IP address from the server's IP stack also via the NIC.
3. I open the appropriate Web server administration utility (Internet Service Manager for IIS; Netscape Enterprise Manager for Netscape) and add my Web site's IP address in the appropriate IP address field for the site's properties.
4. Lastly, I verify that the server's host name listed on the NIC is not the same name that the Web site uses. If it is, I change one because the names must be unique.

   Typically, it's easier to change the server's host name so that you don't cause DNS mapping resolution problems for your customers. However, weigh this against how often the server's physical location might change. If you relocate the server at some point from its current location and plug it back into the network, your configuration may no longer work.

The following diagram illustrates this process.

See the next section for step-by-step procedures about how to perform these required IP configurations for using the ClusterCATS offline maintenance support feature.

#### Configuring offline maintenance support (Windows NT only)

Configuring offline maintenance support involves the following tasks:

1. "Assigning a static IP address to each server's NIC"
2. "Removing Web site IP addresses from the NIC"
3. "Adding your Web sites' IP addresses to your Web server"
4. "Verifying that the server's host name is not the same as the Web site's name"

#### Assigning a static IP address to each server's NIC

If your cluster consists of Windows NT servers, assign a static IP address to each server's Network Interface Card (NIC) to take advantage of the ClusterCATS offline maintenance support feature.

The static maintenance IP address that you assign to the NIC is independent of the IP address that the Web sites residing on the Web server use.

| To add a static IP address to your Windows-based Web server:

1. Click Start>Settings>Control Panel.
2. Open the Network icon.
3. Click the Protocols tab and select the TCP/IP protocol from the list of Network Protocols.
4. Click Properties.

   The Microsoft TCP/IP Properties dialog box appears.

5. Choose the Specify an IP Address option.
6. Enter an IP address for the server in the IP Address field along with the corresponding Subnet Mask and Default Gateway.

   See your network administrator if you don't know this information.

7. Click OK.
8. Verify that you can access your server by its maintenance address using the nslookup command from a command prompt.

   For example:

   `nslookup wwwx.company.com`

   `nslookup nnn.nnn.nnn.nnn`

   where `wwwx` is the explicit server name and `nnn` represents the numeric values of that server's IP address.

To learn how to put a server in maintenance mode, see "Putting a cluster member in maintenance mode".

#### Removing Web site IP addresses from the NIC

Prior to configuring the maintenance IP address, you may have previously bound the IP addresses for your Web sites to the NIC. In order for the ClusterCATS offline maintenance support to work as intended, you need to remove these Web sites' IP addresses from the NIC.

If you do not want to remove the IP addresses of the Web sites that reside on the Web server from your NIC, ClusterCATS will still function properly but you will not be able to take advantage of the offline capabilities. Removing Web site IP addresses from the NIC is required if you are going to use offline maintenance support.

Note | If you use Netscape Enterprise Server as your Web server, you must create the cluster members before you delete the Web site IP addresses from the NIC. For IIS, you create cluster members after you have deleted Web site IP addresses from the NIC.

| To delete Web site IP addresses from the NIC:

1. Click Start>Settings>Control Panel to display the Windows Control Panel.
2. Open the Network icon, select the Protocols tab, and click Properties.

   The Microsoft TCP/IP Properties dialog box appears.

3. Click Advanced.

   The Advanced IP Addressing dialog box appears.

4. In the IP address section, select the Web site addresses that you want to remove from the NIC and click Remove.

   If there are no IP addresses, then they were not bound to the NIC or they were already removed.

5. Click OK in all open dialog boxes to apply your configuration and to close the Windows Control Panel.
6. Reboot your system for these changes to take affect.

#### Adding your Web sites' IP addresses to your Web server

You must assign a unique IP address to each Web Site that you want to participate in a cluster.

| To add Web site IP addresses to Windows/IIS:

1. Click Start>Programs>Windows NT 4.0 Option Pack>Microsoft Internet Information Server>Internet Service Manager.

   The Microsoft Management Console opens.

2. Locate the Web server and expand its tree structure.
3. Right-click the Web site for which you want to configure the IP address and choose Properties.

   The Web Site Properties dialog box appears.

4. Enter the Web site's IP address in the IP Address field.

   You must manually enter the address because it won't appear in the drop-down list at this time. ClusterCATS will dynamically add the address to the IP stack once you create the cluster.

5. Click OK on all open dialog boxes to apply your configuration.
6. Repeat the procedure for each Web site that you want to participate in the cluster.

#### To add Web site IP addresses to UNIX-based Web servers

See the documentation that came with your Web server for specific procedures about how to configure Web site IP addresses on your server.

#### Verifying that the server's host name is not the same as the Web site's name

The last step you must do is check that the server's host name listed on the NIC is not the same name that the Web site uses. If it is, you have to change one because ClusterCATS requires the names to be unique.

| To check the server's host name:

1. Click Start>Settings>Control Panel to display the Windows Control Panel.
2. Open the Network icon, select the Protocols tab, and click Properties.

   The Microsoft TCP/IP Properties dialog box appears.

3. Click the DNS tab.

4. Verify that the name that appears in the Host Name field is the name assigned to the server (www1) and not the name of your Web site (most likely, www.). If the names are the same (www.), change one.

   Typically, it's easier to change the server's host name so that you don't cause DNS mapping resolution problems for your customers when they type in your site's URL. However, weigh this against how often the server's physical location might change. If you relocate the server at some point from its current location and plug it back into the network, it's possible your configuration may no longer work.

## Configure ClusterCATS for use across firewalls

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.

If you have multiple, distributed server clusters supporting the same domain, you'll need to 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. Additionally, if you will be managing your cluster from behind another firewall, you must open both ports so that the ClusterCATS Explorer can communicate with the cluster.

The following diagram illustrates this scenario.

As you can see, this scenario involves Company ABC, which has an East Coast and a West Coast group of servers connected to the Internet via 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:

- Port 9123 (for TCP and UDP access)

  Opening port 9123 on your firewall allows multiple, distributed server clusters residing in different locations to communicate with one another across firewalls.

- Port 9129 (for TCP and UDP access)

  Opening port 9129 on a firewall allows the ClusterCATS Explorer to communicate with multiple, distributed server clusters across firewalls.