This chapter describes what the network planner should consider before installing and configuring the Dispatcher component.
This chapter includes the following sections:
Dispatcher consists of the following functions:
Dispatcher also offers advisors that do not exchange protocol-specific information, such as the DB2® advisor that reports on the health of DB2 servers and the ping advisor that reports whether the server responds to a ping. For a complete list of advisors, see List of advisors.
You also have the option of writing your own advisors (see Create custom (customizable) advisors).
Using the advisors is optional but recommended.
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.
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.
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.
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):
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
This maps the client request's destination port number (which is for Dispatcher) to the server's port number that Dispatcher uses to load balance the client's request. Mapport allows Load Balancer to receive a client's request on one port and to transmit it to a different port on the server machine. With mapport you can load balance a client's requests to a server machine that might have multiple server daemons running. The default for mapport is the client request's destination port number.
The return address is a unique address or host name that you configure on the Dispatcher machine. Dispatcher uses the return address as its source address when load balancing the client's request to the server. This ensures that the server returns the packet to the Dispatcher machine rather than sending the packet directly to the client. (Dispatcher will then forward the IP packet to the client.) You must specify the return address value when adding the server. You cannot modify the return address unless you remove the server and then add it again. The return address cannot be the same as the cluster, server, or NFA address.
When you use nat or cbr forwarding methods, you must define a return address for communication between Load Balancer and the back-end servers. The number of connections that Load Balancer can keep active with the back-end server is limited by the number of return addresses that are defined. Load Balancer uses ports that are based upon the return address only; not the return address and server combination. When all the available ports are in use, additional connections fail. In a busy environment, use multiple return addresses to prevent a shortage of available ports.
The address of the router to the remote server. If this is a locally attached server, enter the server address, unless the server is located on the same machine as Load Balancer. In that case, continue to use the real router address.
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.
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):
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern pattern
Where pattern specifies the pattern to be used for the content type rule. For more information on the content rule type, see Using rules based on the request content. For more information on valid expressions for pattern, see Appendix B. Content rule (pattern) syntax.
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.
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 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.
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).
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.
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.
For information about configuring high availability and mutual high availability, see High availability.