Planning for Dispatcher

This chapter describes what the network planner should consider before installing and configuring the Dispatcher component.

This chapter includes the following sections:

Note:
For previous versions, when the product was known as Network Dispatcher, the Dispatcher control command name was ndcontrol. The Dispatcher control command name is now dscontrol.

Planning considerations

Dispatcher consists of the following functions:

The three key functions of Dispatcher (executor, manager, and advisors) interact to balance and dispatch the incoming requests between servers. Along with load balancing requests, the executor monitors the number of new connections, active connections, and connections in a finished state. The executor also does garbage collection of completed or reset connections and supplies this information to the manager.

The manager collects information from the executor, the advisors, and a system-monitoring program, such as Metric Server. Based on the information the manager receives, it adjusts how the server machines are weighted on each port and gives the executor the new weighting for use in its balancing of new connections.

The advisors monitor each server on the assigned port to determine the server’s response time and availability and then give this information to the manager. The advisors also monitor whether a server is up or down. Without the manager and the advisors, the executor does round-robin scheduling based on the current server weights.

Forwarding methods

With Dispatcher, you can select one of three forwarding methods specified at the port level: MAC forwarding, NAT/NAPT forwarding, or CBR (content-based routing) forwarding.

Dispatcher's MAC-level routing (mac forwarding method)

Using Dispatcher's MAC forwarding method (the default forwarding method), Dispatcher load balances the incoming request to the selected server and the server returns the response directly to the client without any involvement of the Dispatcher. With this forwarding method, Dispatcher only looks at the inbound client-to-server flows. It does not need to see the outbound server-to-client flows. This significantly reduces its impact on the application and can result in improved network performance.

The forwarding method can be selected when adding a port using the dscontrol port add cluster:port method value command. The default forwarding method value is mac. You can specify the method parameter only when the port is added. When you add the port, you cannot change the setting of the forwarding method. See dscontrol port -- configure ports for more information.

Linux limitation: Linux systems employ a host-based model of advertising hardware addresses to IP addresses using ARP. This model is incompatible with the back-end server or the high availability collocation server requirements for Load Balancer's mac forwarding method. See Linux loopback aliasing alternatives when using Load Balancer's mac forwarding, which describes a number of solutions to alter the Linux system's behavior to make it compatible with Load Balancer's mac forwarding.

Linux limitation when using zSeries or S/390 servers: There are limitations when using zSeries or S/390 servers that have Open System Adapter (OSA) cards. See Problem: On Linux, Dispatcher configuration limitations when using zSeries or S/390 servers that have Open System Adapter (OSA) cards, for possible workarounds.

Dispatcher's NAT/NAPT (nat forwarding method)

Using Dispatcher's Network Address Translation (NAT) or Network Address Port Translation (NAPT) capability removes the limitation for load-balanced servers to be located on a locally attached network. When you want to have servers located at remote locations, you can use the NAT forwarding method technique rather than using a GRE/WAN encapsulation technique. You can also use the NAPT feature to access multiple server daemons residing on each load-balanced server machine, where each daemon listens on a unique port.

You can configure a server with multiple daemons in two different ways:

This application works well with upper-level application protocols such as HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, and so on.

Limitations:

You will need three IP addresses for the Dispatcher machine - nfa, cluster, and return address. To implement NAT/NAPT, do the following (see also Sample steps for configuring Dispatcher's nat or cbr forwarding methods):

Dispatcher's content-based routing (cbr forwarding method)

The Dispatcher component allows you to perform content-based routing for HTTP (using the "content" type rule) and HTTPS (using SSL session ID affinity) without having to use Caching Proxy. For HTTP and HTTPS traffic, the Dispatcher component's cbr forwarding method can provide faster content-based routing than the CBR component, which requires Caching Proxy.

For HTTP: Server selection for Dispatcher's content-based routing is based upon the contents of a URL or an HTTP header. It is configured using the "content" type rule. When configuring the content rule, specify the search string "pattern" and a set of servers to the rule. When processing a new incoming request, this rule compares the specified string with the client's URL or with the specified HTTP header in the client request.

If Dispatcher finds the string in the client request, Dispatcher forwards the request to one of the servers within the rule. Dispatcher then relays the response data from the server to the client ("cbr" forwarding method).

If Dispatcher does not find the string in the client request, Dispatcher does not select a server from the set of servers within the rule.

Note:
The content rule is configured in the Dispatcher component the same way it is configured in the CBR component. Dispatcher can use the content rule for HTTP traffic. However, the CBR component can use the content rule for both HTTP and HTTPS (SSL) traffic.

For HTTPS (SSL): Dispatcher's content-based routing load balances based on the SSL ID session field of the client request. With SSL, a client request contains the SSL session ID of a prior session, and servers maintain a cache of their prior SSL connections. Dispatcher's SSL ID session affinity allows the client and server to establish a new connection using the security parameters of the previous connection with the server. By eliminating the renegotiation of SSL security parameters, such as shared keys and encryption algorithms, the servers save CPU cycles and the client gets a quicker response. In order to enable SSL session ID affinity: the protocol type specified for the port must be SSL and port stickytime must be set to a nonzero value. When stickytime has been exceeded, the client may be sent to a different server from the previous.

You will need three IP addresses for the Dispatcher machine - nfa, cluster, and return address. To implement Dispatcher's content-based routing (see also Sample steps for configuring Dispatcher's nat or cbr forwarding methods):

Note:
The connection record replication feature of high availability (which ensures that a client's connection will not drop when a backup Dispatcher machine takes over for the primary machine) is not supported with Dispatcher's content-based routing.

Sample steps for configuring Dispatcher's nat or cbr forwarding methods

Figure 12. Example for using Dispatcher's nat or cbr forwarding methods
Configuration for using Dispatcher's nat or cbr forwarding

You will need at least three IP addresses for the Dispatcher machine. For Figure 12, the following are the necessary steps to minimally configure Dispatcher's nat or cbr forwarding methods:

1.Start the executor
  dscontrol executor start

2.Define the client gateway
  dscontrol executor set clientgateway 1.2.3.5
  NOTE: If your subnet does not have a local router, then you must
        configure a machine to do IP forwarding and use that as the
        clientgateway. Consult your operating system documentation 
        to determine how to enable IP forwarding.

3.Define the cluster address
  dscontrol cluster add 1.2.3.44

4.Configure the cluster address
  dscontrol executor configure 1.2.3.44

5.Define the port with a method of nat or cbr
  dscontrol port add 1.2.3.44:80 method nat
  or
  dscontrol port add 1.2.3.44:80 method cbr protocol http

6.Configure an alias return address on Load Balancer (using ethernet card 0)
  NOTE: On Linux systems, you do not need to alias the return address if using
  nat forwarding on a collocated machine.

  dscontrol executor configure 10.10.10.99

  or use the ifconfig command (for Linux or UNIX only):
  AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0
  HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up
  Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up
  Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up

7.Define the backend servers
  dscontrol server add 1.2.3.4:80:192.10.10.10
    router 10.10.10.6 returnaddress 10.10.10.99 

The client gateway (1.2.3.5) is the router 1 address between Load Balancer and the client. The router (10.10.10.6) is the router 2 address between Load Balancer and the backend server. If you are unsure of the clientgateway or router 2 address, you can use a traceroute program with the client (or server) address to determine the router address. The exact syntax of this program will differ based on the operating system you are using. You should consult your operating system documentation for more information regarding this program.

If the server is on the same subnet as Load Balancer (that is, no routers are returned using traceroute) enter the server address as the router address. However, if the server is located on the same machine as Load Balancer, the router address should be entered in the router field instead of the server address. The router address is the address used in the "server add" command on the Load Balancer machine in step 7.

Server Partitioning: logical servers configured to one physical server (IP address)

With server partitioning, you can further distinguish between particular URLs and their specific applications. For example, one Web server can serve JSP pages, HTML pages, GIF files, database requests, and so on. Load Balancer now provides the ability to partition one cluster and port specific server into several logical servers. This allows you to advise on a particular service on the machine to detect if a servlet engine or a database request is running faster, or not running at all.

Server partitioning allows Load Balancer to detect, for example, that the HTML service is serving pages rapidly, but the database connection has gone down. This allows you to distribute load based on more granular service-specific workload, rather than server-wide weighting alone.

Server partitioning using HTTP or HTTPS advisors

Server partitioning can be useful when used in conjunction with the HTTP and HTTPS advisors. For example, when you have an HTML server that handles HTML, GIF, and JSP pages, if you define (by adding) the server once under port 80, you receive just one load value for the whole HTTP server. This might be misleading because it is possible that the GIF service might not be functioning on the server. Dispatcher still forwards GIF pages to the server, but the client sees a timeout or a failure.

If you define the server three times (for example, ServerHTML, ServerGIF, ServerJSP) under the port and define the server advisorrequest parameter with a different string for each logical server, then you can query the health of the particular service on the server. ServerHTML, ServerGIF and ServerJSP represent three logical servers that have been partitioned from one physical server. For ServerJSP, you can define the advisorrequest string to query the service on the machine that handles JSP pages. For ServerGIF, you can define the advisorrequest string to query the GIF service. And for ServerHTML, you define the advisorrequest to query the HTML service. So, if the client gets no response from the advisorrequest to query the GIF service, Dispatcher will mark that logical server (ServerGIF) as down, while the other two logical servers may be healthy. Dispatcher does not forward any more GIFs to the physical server, but it can still send JSP and HTML requests to the server.

For more information on the advisorrequest parameter, see Configuring the HTTP or HTTPS advisor using the request and response (URL) option.

Example for configuring a physical server into logical servers

Within the Dispatcher configuration, you can represent a physical server or a logical server using the cluster:port:server hierarchy. The server can be a unique IP address of the machine (physical server) in either a symbolic name or IP address format. Or, if you define the server to represent a partitioned server, then you must provide a resolvable server address for the physical server on the address parameter of the dscontrol server add command. See dscontrol server -- configure servers for more information.

Following is an example of partitioning physical servers into logical servers to handle different types of requests.

Cluster: 1.1.1.1
        Port:  80
             Server: A (IP address 1.1.1.2)
                       HTML server
             Server: B (IP address 1.1.1.2)
                       GIF server
             Server: C (IP address 1.1.1.3)
                       HTML server
             Server: D (IP address 1.1.1.3)
                       JSP server
             Server: E (IP address 1.1.1.4)
                       GIF server
             Server: F (IP address 1.1.1.4)
                       JSP server
        Rule1: /*.htm
             Server: A
             Server: C
        Rule2: /*.jsp
             Server: D
             Server: F
        Rule3: /*.gif
             Server: B
             Server: E                

In this example, server 1.1.1.2 is partitioned into 2 logical servers: "A" (handling HTML requests) and "B" (handling GIF requests). Server 1.1.1.3 is partitioned into 2 logical servers: "C" (handling HTML requests) and "D" (handling JSP requests). Server 1.1.1.4 is partitioned into 2 logical servers: "E" (handling GIF requests) and "F" (handling JSP requests).

High availability

Simple high availability

Figure 13. Example of a Dispatcher using simple high availability
Dispatcher using simple high availability configuration

The high availability feature involves the use of a second Dispatcher machine. The first Dispatcher machine performs load balancing for all the client traffic as it does in a single Dispatcher configuration. The second Dispatcher machine monitors the "health" of the first, and takes over the task of load balancing if it detects that the first Dispatcher machine has failed.

Each of the two machines is assigned a specific role, either primary or backup. The primary machine sends connection data to the backup machine on an ongoing basis. While the primary is active (load balancing), the backup is in a standby state, continually updated and ready to take over, if necessary.

The communication sessions between the two machines are referred to as heartbeats. The heartbeats allow each machine to monitor the health of the other.

If the backup machine detects that the active machine has failed, it will take over and begin load balancing. At that point the statuses of the two machines are reversed: the backup machine becomes active and the primary becomes standby.

In the high availability configuration, both primary and backup machines must be on the same subnet with identical configuration.

For information about configuring high availability, see High availability.

Mutual high availability

Figure 14. Example of a Dispatcher using mutual high availability
Dispatcher using mutual high availability configuration

The mutual high availability feature involves the use of two Dispatcher machines. Both machines actively perform load balancing of client traffic, and both machines provide backup for each other. In a simple high availability configuration, only one machine performs load balancing. In a mutual high availability configuration, both machines load balance a portion of the client traffic.

For mutual high availability, client traffic is assigned to each Dispatcher machine on a cluster address basis. Each cluster can be configured with the NFA (nonforwarding address) of its primary Dispatcher. The primary Dispatcher machine normally performs load balancing for that cluster. In the event of a failure, the other machine performs load balancing for both its own cluster and for the failed Dispatcher's cluster.

For an illustration of a mutual high availability configuration with shared "cluster set A" and shared "cluster set B," see Figure 14. Each Dispatcher can actively route packets for its primary cluster. If either Dispatcher were to fail and could no longer actively route packets for its primary cluster, then the other Dispatcher could take over routing packets for its backup cluster.

Note:
Both machines must configure their shared cluster sets the same. That is, the ports used and the servers under each port must be identical in the two configurations.

For information about configuring high availability and mutual high availability, see High availability.