Version 3.0 for Multiplatforms
Document Number GC31-8496-05
Note |
---|
Before using this information and the product it supports, be sure to read the general information under Appendix F, Notices. |
Sixth Edition (May 2000)
© Copyright International Business Machines Corporation 2000. All rights reserved.
Note to U.S. Government Users -- Documentation related to restricted rights -- Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule contract with IBM Corp.
Chapter 1. Getting started...quickly!
Chapter 2. Installing IBM Network Dispatcher
Chapter 3. Introducing IBM Network Dispatcher
Chapter 4. Planning for the Dispatcher component
Chapter 5. Configuring the Dispatcher component
Chapter 6. Planning for the Content Based Routing component
Chapter 7. Configuring the Content Based Routing component
Chapter 8. Advanced Dispatcher and CBR Functions
Chapter 9. Planning for the Interactive Session Support component
Chapter 10. Configuring the Interactive Session Support component
Chapter 11. Operating and managing IBM Network Dispatcher
Appendix A. How to read a syntax diagram
Appendix B. Command reference for Dispatcher and CBR
Appendix C. Command reference for ISS
Appendix D. Rule types for CBR
Appendix E. Sample configuration files
This book explains how to plan for, install, configure, use, and troubleshoot IBM(R) Network Dispatcher for AIX, Red Hat Linux, Solaris, Windows NT, and Windows 2000. Previously, this product was called SecureWay Network Dispatcher, eNetwork Dispatcher, and Interactive Network Dispatcher.
The most current version of this book is available in HTML and PDF formats on the IBM Network Dispatcher Web site. To access the online book, go to the following URL:
http://www.software.ibm.com/network/dispatcher/library/
The IBM Network Dispatcher Web site gives you the latest details on how you can use this product to maximize the performance of your servers. Configuration examples and scenarios are included. To access this Web site, go to the following URL:
http://www.software.ibm.com/network/dispatcher
How quickly can you make IBM Network Dispatcher work for you? Consider the following:
Assume you're the webmaster for the Intersplash Corporation. You manage a local web site with two HTTP servers. You've been using a round-robin approach to manage the load on the two servers, but business has picked up recently and customers are starting to complain about not being able to access the site. What do you do?
Go out to http://www.software.ibm.com/network/dispatcher and download the latest version of IBM Network Dispatcher. This product has three components: Dispatcher, Interactive Session Support, and Content Based Routing. For the time being, we'll just discuss the Dispatcher component.
Figure 1. A simple Dispatcher configuration
This quick-start example shows how to configure three workstations using the Dispatcher component to load-balance web traffic between two web servers. The configuration would be essentially the same for balancing any other TCP or stateless UDP application traffic.
Note: | With the AIX, Red Hat Linux, or Solaris version of Dispatcher, the configuration could be completed using only two workstations with Dispatcher located on one of the web server workstations. This represents a collocated configuration. Procedures for setting up more complex configurations can be found at Setting up the Dispatcher machine. |
For the quick-start example, you will need three workstations and four IP addresses. One workstation will be used as the Dispatcher; the other two workstations will be used as web servers. Each web server requires one IP address. The Dispatcher workstation requires one actual address, and one address to be load balanced.
Workstation | Name | IP Address |
---|---|---|
1 | server1.intersplash.com | 9.67.67.101 |
2 | server2.intersplash.com | 9.67.67.102 |
3 | server3.intersplash.com | 9.67.67.103 |
Netmask = 255.255.255.0 |
Each of the workstations contains only one standard Ethernet network interface card.
Name= www.intersplash.com IP=9.67.67.104
Add an alias for www.intersplash.com to the loopback interface on server2.intersplash.com and server3.intersplash.com.
ifconfig lo0 alias www.intersplash.com netmask 255.255.255.0
ifconfig lo0:1 www.intersplash.com 127.0.0.1 up
You have now completed all configuration steps that are required on the two webserver workstations.
With Dispatcher, you can create a configuration by using the command line, the configuration wizard, or the graphical user interface (GUI).
If you are using the command line, follow these steps:
ndserver
ndcontrol executor start
ndcontrol cluster add www.intersplash.com
ndcontrol port add www.intersplash.com:80
ndcontrol server add www.intersplash.com:80:server2.intersplash.com
ndcontrol server add www.intersplash.com:80:server3.intersplash.com
ndcontrol cluster configure www.intersplash.com
ndcontrol manager start
Dispatcher will now do load balancing based on server performance.
ndcontrol advisor start http 80
ndcontrol manager proportions 60 39 1 0
Dispatcher will now make sure that client requests are not sent to a failed web server. Your basic configuration is now complete.
If you are using the configuration wizard, follow these steps:
ndserver
The wizard guides you step by step through the process of creating a basic configuration for the Dispatcher component. You will be asked questions about your network. You will be guided through the setup of a cluster for Dispatcher to load balance traffic between a group of servers.
With the configuration wizard, you will see the following panels:
For an example of the GUI, see Figure 2.
To start the graphical user interface, follow these steps:
ndserver
For AIX, Solaris, and Windows, the left side of the panel displays a tree structure with IBM Network Dispatcher at the top level, and Dispatcher, ISS, and CBR as components.
Note: | For Red Hat Linux, the tree structure displays the Dispatcher and CBR components. The system-specific metrics function provided by ISS is replaced by the Server Monitor Agent (SMA), which is unique for Red Hat Linux. |
All of the components can be configured from the GUI. You can select elements in the tree structure by clicking mouse button one (normally the left button) and display pop-up menus by clicking mouse button two (normally the right button). The pop-up menus for the tree elements are also accessible from the menu bar located at the top of the panel.
Each item in the tree is marked with a + (plus) or a - (minus). Click on the plus to expand the items within it and the minus to compact the items.
The right side of the panel displays status indicator tabs for the element currently selected. The Current Statistics tab presents statistical information about the element. The Refresh Statistics button displays the latest statistical data. The Configuration Settings tab presents configuration parameters that can be set using the procedures outlined in the configuration chapters for each of the components. The Update Configuration button applies the latest changes to the configuration currently running. The Lists tab presents additional details about the selected tree element. The Remove button deletes highlighted items as selected in a list box. The Lists tab does not appear for all elements in the tree structure.
You can access Help by clicking the question mark icon in the upper right hand corner of the Network Dispatcher window.
Figure 2. The graphical user interface (GUI)
Test to see if the configuration is working.
This chapter instructs you on the hardware requirements and installation of IBM Network Dispatcher on AIX, Red Hat Linux, Solaris, and Windows. Follow these instructions beginning at:
Note: | If you are migrating from a previous version, note that the directory structure has changed and you should be sure to move any of your own configuration files and scripts (such as goIdle and goStandby) into the appropriate '/bin' directory of each component (ISS, CBR or Dispatcher). |
Note: | Additional disk space will be needed for logs. |
Table 1 lists the installp images to install for Network Dispatcher for
AIX.
Dispatcher (component, adminstration, license, and messages) | intnd.nd.driver intnd.nd.rte intnd.ndadmin.rte intnd.nd.license intnd.msg.nd.<language>.nd.rte intnd.msg.<language>.ndadmin.rte intnd.admin.rte intnd.msg.<language>.admin.rte |
ISS (component, administration, license, and messages) | intnd.iss.rte intnd.issadmin.rte intnd.iss.license intnd.msg.<language>.iss.rte intnd.msg.<language>.issadmin.rte intnd.admin.rte intnd.msg.<language>.admin.rte |
CBR (component, administration, license, and messages) | intnd.cbr.rte intnd.cbradmin.rte intnd.cbr.license intnd.msg.<language>.cbr.rte intnd.msg.<language>.cbradmin.rte intnd.admin.rte intnd.msg.<language>.admin.rte |
User's Guide | intnd.doc.<language> |
where <language> is one of:
If you are downloading an evaluation copy of the product from the Web site, use the installation instructions on (http://www.software.ibm.com/network/dispatcher/downloads/).
When you install the product, you are given the option of installing any or all of the following:
It is necessary that you install the ISS component on every machine on which you plan to run either the ISS monitor function or the ISS agent function. For more about the monitor and agent functions, see Chapter 9, Planning for the Interactive Session Support component.
Note: | If you have an earlier version installed, you should uninstall that copy before installing the current version. First, ensure that both the Dispatcher executor and server are stopped. Then, to uninstall the entire product, enter installp -u intnd. To uninstall specific filesets, list them specifically instead of specifying the package name. |
Follow these steps to install IBM Network Dispatcher for AIX:
Using SMIT:
When the command completes, press Done,and then select Exit Smit from the Exit menu or press F12. If using SMITTY, press F10 to exit the program.
Using the Command Line:
If installing from a CD, you must enter the following commands to mount the CD:
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Refer to the following table to determine which command(s) to enter to
install the desired IBM Network Dispatcher for AIX components:
Dispatcher (with msgs) | installp -acXgd device intnd.nd.rte intnd.msg.<language>.nd.rte intnd.msg.<language>.ndadmin.rte intnd.msg.<language>.admin.rte |
ISS (with msgs) | installp -acXgd device intnd.iss.rte intnd.msg.<language>.iss.rte intnd.msg.<language>.issadmin.rte intnd.msg.<language>.admin.rte |
Content Based Routing (with msgs) | installp -acXgd device intnd.cbr.rte intnd.msg.<language>.cbr.rte intnd.msg.<language>.cbradmin.rte intnd.msg.<language>.admin.rte |
Dispatcher, ISS, and Content Based Routing (with msgs) | installp -acXgd device intnd.nd.rte intnd.msg.<language>.nd.rte intnd.msg.<language>.ndadmin.rte intnd .msg.<language>.admin.rte intnd.iss.rte intnd.msg.<language>.iss.rte intnd.msg.<language>.issadmin.rte intnd.cbr.rte intnd.msg.<language>.cbr.rte intnd.msg.<language>.cbradmin.rte |
Dispatcher, ISS, and CBR (with msgs and documentation) | installp -acXgd device intnd.nd.rte intnd.msg.<language>.nd.rte intnd.msg.<language>.ndadmin.rte intnd .msg.<language>.admin.rte intnd.iss.rte intnd.msg.<language>.iss.rte intnd.msg.<language>.issadmin.rte intnd.cbr.rte intnd.msg.<language>.cbr.rte intnd.msg.<language>.cbradmin.rte intnd.doc.<language> |
Documentation only | installp -acXgd device intnd.doc.<language> |
where device is:
Ensure that the result column in the summary contains SUCCESS for each part of IBM Network Dispatcher that you are installing (APPLYing). Do not continue until all of the parts you wish to install are successfully applied.
Note that if you are using ISS, it must also be installed on each server machine.
Note: | To generate a list of filesets in any installp image, including all available
message catalogs, enter
installp -ld device where device is:
|
To unmount the CD, type:
unmount /cdrom
lslpp -h | grep intnd
If you installed the full product, this command returns the following:
intnd.admin.rte intnd.cbr.rte intnd.cbradmin.rte intnd.cbr.license intnd.iss.rte intnd.issadmin.rte intnd.iss.license intnd.msg.en_US.admin.rte intnd.msg.en_US.cbr.rte intnd.msg.en_US.cbradmin.rte intnd.msg.en_US.iss.rte intnd.msg.en_US.issadmin.rte intnd.msg.en_US.nd.rte intnd.msg.en_Us.ndadmin.rte intnd.nd.driver intnd.nd.license intnd.nd.rte intnd.ndadmin.rte intnd.doc.en_US
Note: | Additional disk space will be needed for logs. |
This section explains how to install IBM Network Dispatcher on Red Hat Linux using the product CD or the downloaded evaluation copy of the product from the Web site. Installation instructions can be found on the Web site (http://www.software.ibm.com/network/dispatcher/downloads/).
Before beginning the installation procedure, ensure that you have root authority to install the software.
Note: | If you have an earlier version installed, you should uninstall that copy before installing the current version. First, ensure that both the Dispatcher executor and server are stopped. Then to uninstall the entire product, enter rpm -e pkgname. When uninstalling, reverse the order used for package installation ensuring the administration packages are last to be uninstalled. |
To install IBM Network Dispatcher:
The following is a list of the RPM installable packages.
The command to install the packages should be issued from the same directory where the RPM files reside. Issue the following command to install each package: rpm -i package.rpm.
Note: | At least one of the RPM files requires that Java be installed and registered
in the RPM database. If Java is installed but not registered in the RPM
database, use the install command with a 'no dependencies' option as
follows:
rpm -i --nodeps package.rpm |
rpm -qa | grep ibmnd
Installing the full product should produce a listing like the following:
Note: | Additional disk space will be needed for logs. |
This section explains how to install IBM Network Dispatcher on Solaris using the product CD. If you are downloading an evaluation copy of the product from the internet, use the installation instructions on the Web site (http://www.software.ibm.com/network/dispatcher/downloads/).
Before beginning the installation procedure, ensure that you have root authority to install the software.
Note: | If you have an earlier version installed, you should uninstall that copy before installing the current version. First, ensure that you have stopped both the executor and the server. Then, to uninstall Network Dispatcher enter pkgrm pkgname. |
To install IBM Network Dispatcher:
At the command prompt, enter pkgadd -d pathname, where -d pathname is the device name of the CD-ROM drive or the directory on the hard drive where the package is located; for example: pkgadd -d /cdrom/cdrom0/.
You will be given a list of packages to install. They are:
If you would like to install all of the packages, simply type 'All' and press return. If you would like to install some of the components, enter the number(s) corresponding to the packages to be installed separated by a space or comma and press return. You may be prompted to change permissions on existing directories or files. Simply press return, or answer " yes." You need to install prerequisite packages (because it installs in alphabetical order not prerequisite order). If you say 'all' then just answer 'yes' to all prompting and the install will complete successfully.
All of the packages depend on the common ND package, ibmndadm. This common package must be installed along with any of the other packages.
If you want to install the entire Dispatcher component, you must install four pieces: ibmndadm, ibmdsp, ibmdspadm, and ibmdsplic. If you want to install the remote administration for the Dispatcher component, you only have to install three pieces: ibmndadm, ibmdsplic, and ibmdspadm. The same is true for the packages ISS and CBR.
The installed components reside in the following directories:
Installing the full product should produce a listing like the following:
Note: | Additional disk space will be needed for logs. |
This section explains how to install IBM Network Dispatcher on Windows 2000 or Windows NT using the product CD. If you are downloading an evaluation copy of the product from the Web site, use the installation instructions on the Web site (http://www.software.ibm.com/network/dispatcher/downloads/).
Note: | When downloading from the Web site, you can obtain the Windows 2000 install package and/or the Windows NT install package. |
You will be given a choice of packages to install.
They are:
Windows 2000 version of IBM Network Dispatcher is supported on the following:
Windows NT version of IBM Network Dispatcher is supported on the following:
Note: | The Windows 2000 and Windows NT versions of IBM Network Dispatcher will not run on Windows 98 or any other version of Windows. |
Before beginning the installation procedure, ensure you have logged in as the Administrator or as a user with administrative privileges.
If you have an earlier version installed, you should uninstall that copy before installing the current version. To uninstall using the Add/Remove Program, do the following:
To install IBM Network Dispatcher:
E:\setup
This chapter gives an overview of IBM Network Dispatcher and includes the following sections:
The IBM Network Dispatcher is the next generation of server load balancing software. It boosts the performance of servers by directing TCP/IP session requests to different servers within a group of servers; in this way, it balances the requests among all the servers. This load balancing is transparent to users and other applications. IBM Network Dispatcher is useful for applications such as e-mail servers, World Wide Web servers, distributed parallel database queries, and other TCP/IP applications.
When used with Web servers, IBM Network Dispatcher can help maximize the potential of your site by providing a powerful, flexible, and scalable solution to peak-demand problems. If visitors to your site can't get through at times of greatest demand, IBM Network Dispatcher can automatically find the optimal server to handle incoming requests, thus enhancing your customers' satisfaction and your profitability.
IBM Network Dispatcher consists of three components that can be used separately or together to provide superior load-balancing results:
When used for load-balancing, ISS works in conjunction with the DNS name server to map DNS names of ISS services to IP addresses. When used to provide server load information, a name server is not required.
Note: For Red Hat Linux, ISS is not supported. Instead, the Server Monitor Agent (SMA) provides server load information to the Dispatcher in the form of system-specific metrics.
For IMAP or POP3 protocols, CBR (without WTE) is a proxy which chooses an appropriate server based on userid and password provided by the client.
For more information, see Chapter 7, Configuring the Content Based Routing component.
For more information on the Dispatcher, ISS and CBR components, see What are the components of IBM Network Dispatcher?.
The number of users and networks connected to the global Internet is growing exponentially. This growth is causing problems of scale that can limit users' access to popular sites.
Currently, network administrators are using numerous methods to try to maximize access. Some of these methods allow users to choose a different server at random if an earlier choice is slow or not responding. This approach is cumbersome, annoying, and inefficient. Another method is standard round-robin, in which the domain name server selects servers in turn to handle requests. This approach is better, but still inefficient because it blindly forwards traffic without any consideration of the server workload. In addition, even if a server fails, requests continue to be sent to it. For more information on approaches to managing server workload, including animated examples, go to the following URL:
http://www.software.ibm.com/network/dispatcher/about/features/examples.html
The need for a more powerful solution has resulted in IBM Network Dispatcher. It offers numerous benefits over earlier and competing solutions:
As the number of client requests increases, you can add servers dynamically, providing support for tens of millions of requests per day, on tens or even hundreds of servers.
Load balancing ensures that each group of servers makes optimum use of its hardware by minimizing the hot-spots that frequently occur with a standard round-robin method.
IBM Network Dispatcher uses standard TCP/IP protocols. You can add it to your existing network without making any physical changes to the network. It is simple to install and configure.
Dispatcher needs only to look 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 compared with other approaches and can result in improved network performance.
Dispatcher does not modify any packets, nor does it require any modifications to the operating system on which it runs.
Dispatcher offers built-in high availability, utilizing a backup machine that remains ready at all times to take over load balancing should the primary Dispatcher machine fail. Dispatcher also offers mutual high availability which allows two machines to be both active and standby for each other. See How about high availability?.
ISS is intrinsically highly available. All the nodes in an ISS configuration work together to eliminate any single point of failure. For more information, see Configure high availability.
For HTTP, CBR gives a WTE administrator the ability to proxy requests to specific servers based on the content requested. For example, if a request contains the string '/cgi-bin/' in the directory portion of the URL, and the server name is a local server, CBR can direct the request to the best server in a set of servers specifically allocated to handle cgi requests.
For IMAP or POP3, CBR (without WTE) is a proxy which chooses an appropriate server based on userid and password provided by the client.
Version 3.0 of IBM Network Dispatcher contains a number of new features. The most significant new features are listed here.
This feature applies to the Dispatcher, CBR, and ISS components.
Version 3.0 introduces support for installing and running IBM Network Dispatcher on a new platform -- Windows 2000. Support is provided for both the Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server versions of this platform. See Requirements for Windows 2000 or Windows NT, for more information.
This feature applies to the CBR component.
The CBR wizard allows you to create a CBR configuration quickly. When you have completed the wizard, you will be able to load balance HTTP or IMAP and POP3 traffic. See Configuration wizard, for more information.
This feature applies to the CBR component.
The CBR component is now able to support proxying IMAP and POP3 protocols. See Overview of Content Based Routing (CBR) and CBR proxy (for IMAP or POP3), for more information.
This feature applies to the Dispatcher component.
Mutual high availability is a feature that allows both Dispatcher machines to actively load balance a portion of the client traffic, while also backing up each other. See Mutual high availability, for more information.
This feature applies to the Dispatcher component.
Cross port affinity is a sticky feature enhancement that allows different ports to direct client requests to the same server. See Cross port affinity, for more information.
This feature applies to the Dispatcher component.
Affinity address mask is a sticky feature enhancement to group clients based upon common subnet address. A mechanism allows you to mask the common high-order bits of the IP address. When this feature is enabled, for all subsequent connections coming in from the same subnet address, the same server will be selected. See Affinity address mask, for more information.
This feature applies to the Dispatcher and CBR components.
With rule affinity override, you can override the stickiness of a port for a specific server. For example, you are using a rule to limit the amount of connections to each application server, and you have an overflow server with an always true rule that says "please try again later" for that application. However, you don't want the client to be sticky to that server, so you can now change the overflow server to override that affinity normally associated with that port. The next time the client requests the cluster, it is load balanced to the best available application server, not the overflow server. See Rule affinity override, for more information.
This feature applies to the Dispatcher component.
TOS rule allows you to load balance across servers based on the content of the "type of service" field in the IP header. See Using rules based on type of service (TOS), for more information.
This feature applies to the Dispatcher and CBR components.
Manager fixed weight provides you the option to run the advisors, without the function of having the manager update the server weights. See Manager fixed weights, for more information.
This feature applies to the Dispatcher component for all platforms with the exception of Windows.
Multiple address collocation allows you to set up the address of the collocated server to an address other than the NFA. Collocation refers to the Network Dispatcher residing on the same server that it is load balancing. See Using Collocated Servers, for more information on collocated servers. See page ***, for more information on multiple address collocation.
This feature applies to the Dispatcher and CBR components.
A new sample advisor specifically for monitoring the state of WAS servers being load balanced is provided. See WebSphere Application Server (WAS) advisor, for more information.
This feature applies to the Dispatcher and CBR components.
This is a new advisor for monitoring IMAP protocol. See List of advisors, for more information on the IMAP advisor.
The three components of IBM Network Dispatcher are Dispatcher, Interactive Session Support (ISS), and Content Based Routing (CBR). IBM Network Dispatcher gives you the flexibility of using these components separately or together depending on your site configuration. This section gives an overview of the Dispatcher, ISS, and CBR.
Note: | For Red Hat Linux, ISS is replaced by the Server Monitor Agent (SMA). Similar to ISS, SMA provides a system-specific metrics function, reporting on the health of the servers. SMA is unique to IBM Network Dispatcher for Red Hat Linux and can not be used on any other platform. For information on SMA see Server Monitor Agent (SMA). |
For configuration examples, go to Which component should I use: Dispatcher, ISS, CBR or all three?.
The Dispatcher component does not use a domain name server for load balancing. It balances traffic among your servers through a unique combination of load balancing and management software. The Dispatcher can also detect a failed server and forward traffic around it.
All client requests sent to the Dispatcher machine are directed to the most optimal server according to certain dynamically set weights. You can use the default values for those weights or change the values during the configuration process.
The server sends a response back to the client without any involvement of the Dispatcher. No additional code is required on your servers to communicate with the Dispatcher.
The Dispatcher component is the key to stable, efficient management of a large, scalable network of servers. With the Dispatcher, you can link many individual servers into what appears to be a single, virtual server. Your site thus appears as a single IP address to the world. Dispatcher functions independently of a domain name server; all requests are sent to the IP address of the Dispatcher machine.
The Dispatcher brings distinct advantages in balancing traffic load to clustered servers, resulting in stable and efficient management of your site.
ISS periodically monitors the level of activity on a group of servers and detects which server is the least heavily loaded. It can also detect a failed server and forward traffic around it. Once every monitoring period, ISS ensures that the information used by the domain name server or the Dispatcher accurately reflects the load on the servers. The load is a measure of how hard the server is working. The system ISS administrator controls both the type of measurement used to measure the load and the length of the load monitoring period. You can configure ISS to suit your environment, taking into account such factors as frequency of access, the total number of users, and types of access (for example, short queries, long-running queries, or CPU-intensive loads).
In addition to the functions already mentioned, ISS can perform load balancing and can feed information to Dispatcher as it is performing load balancing.
You can use the ISS component with or without a DNS name server:
CBR can be configured with WTE for HTTP servers. Or, it can be configured as a CBR proxy (without WTE) for IMAP and POP3 servers. However, CBR cannot be configured for both in the same Network Dispatcher machine.
CBR with WTE (for processing HTTP traffic):
CBR works with IBM Web Traffic Express (WTE) to proxy client requests to specified servers. WTE is a caching proxy server. It allows you to manipulate caching details for faster Web document retrieval with low network bandwidth requirements. CBR along with WTE filters Web page content using specified rule types.
CBR gives you the ability to specify a set of servers that should handle a request based on regular expression matching of the content of the request. Because CBR allows you to specify multiple servers for each type of request, the requests can be load balanced for optimal client response. CBR will also detect when one server in a set has failed, and stop routing requests to that server. The load balancing algorithm used by the CBR component is identical to the proven algorithm used by the Dispatcher component.
When a request is received by the WTE proxy, it is checked against the rules that have been defined in the CBR component. If a match is found, then one of the servers associated with that rule is chosen to handle the request. WTE then performs its normal processing to proxy the request to the chosen server.
CBR has the same functions as Dispatcher with the exception of high availability, subagent, wide area, and a few other configuration commands. For more information, see Chapter 7, Configuring the Content Based Routing component.
WTE must be running before any CBR configuration can be performed.
CBR proxy (for processing IMAP or POP3 traffic):
CBR (without WTE) can provide a single point of presence for many IMAP or POP3 servers. Each server can have a subset of all user mailboxes serviced by the point of presence. For IMAP and POP3, CBR is a proxy that chooses an appropriate server based on user ID and password provided by the client. The CBR proxy does not support rules-based load balancing.
The Dispatcher component offers a built-in high availability feature. This feature involves the use of a second Dispatcher machine that monitors the main, or primary, machine and stands by to take over the task of load balancing should the primary machine fail at any time. The Dispatcher component also offers mutual high availability which allows two machines to be both active and standby for each other. See Configure high availability.
ISS is intrinsically highly available. All the nodes in an ISS configuration work together to eliminate any single point of failure. Should the monitor machine fail, the survivors elect a new monitor to take over automatically. When using ISS to perform the NameServer replace function, high availability can be enhanced by nominating more than one server to act as a nameserver.
Use the questions in Table 3 to help you determine how to use the three components of IBM
Network Dispatcher.
Table 3. Guidelines for using the components of IBM Network Dispatcher
| |
Question | Related information |
---|---|
Do you plan to manage servers on a local network and want to evaluate the Dispatcher component? | If yes, go to Chapter 1, Getting started...quickly!. |
Are you managing servers on different subnets? |
If yes, you can use the wide area support provided by the Dispatcher. See Configure wide area Dispatcher support. Alternatively, you could use both ISS and Dispatcher, in particular if you make heavy use of Telnet or TN3270. For an example, go to Managing local and remote servers with ISS and Dispatcher. To manage servers on a local area network, you can use either Dispatcher or ISS to perform the load-balancing function. Note that ISS requires a domain name server.
|
Is high availability important? |
Dispatcher has a High Availability feature. See High availability. ISS is intrinsically highly available.
|
What type of applications are you running? |
Dispatcher supports HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, and any
other TCP- or stateless UDP-based application. In addition, it permits
you to write your own advisors (see Create custom (customizable) advisors). For any other IP-based application in a domain name
server environment, use ISS.
|
Is application server feedback important? |
If yes, use the Dispatcher advisor functions to collect information from
HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, or Telnet application servers.
You can also write your own advisor (see Create custom (customizable) advisors.)
|
Do you expect a high volume of requests? |
If yes, and you are running TCP or stateless UDP applications, use
Dispatcher.
|
Is load feedback about the machines on which the servers are running important? |
If yes, use Dispatcher for load balancing and run ISS or SMA (for Red Hat
Linux) on the server machines to provide load information. For an
example w/ISS, go to Managing local servers with ISS and Dispatcher. For an example w/SMA, go to Managing local servers with Server Monitor Agent (SMA) and Dispatcher. To write your own advisors, see Create custom (customizable) advisors.
|
Is Server Directed Affinity or state preservation important? |
If yes, use Dispatcher. You can set up a port that sends the initial
and all subsequent requests from a client to the same server by using the
ndcontrol port set stickytime command option when configuring the
port. For more information on this command, see ndcontrol port -- configure ports.
|
Do you need to send HTTP requests to different servers, depending on the content of the request? | If yes, use the CBR rules. For more information about rules, see Chapter 7, Configuring the Content Based Routing component. |
Do you need to send IMAP or POP3 requests to servers based on userid and password? | If yes, use the CBR proxy. For more information about the CBR proxy, see Chapter 7, Configuring the Content Based Routing component |
Figure 3. Example of a logical representation of a site using the Dispatcher to manage local servers
Figure 3 shows a logical representation of a site in which all servers are on a local network. The Dispatcher component is used to forward client requests to the servers.
Figure 4 shows a physical representation of the site using an Ethernet network configuration. The Dispatcher machine can be installed without making any physical changes to the network. After a client request is directed to the optimal server by the Dispatcher, the response is then sent directly from server to client with no involvement by the Dispatcher.
Figure 5. Example of a site using ISS to manage local servers
Figure 5 illustrates a site in which all servers are on a local network. The ISS daemon is installed on all servers. The ISS daemon running as a monitor feeds either the DNS NameServer (ISS in DNS-update mode) or a server which is running the ISS NameServing function (ISS in DNS-replace mode) updated information. When acting as an agent, the ISS daemon provides the monitor with server load information.
Figure 6. Example of a site using CBR to manage local servers
Figure 6 shows a logical representation of a site in which CBR is being used to proxy some content from local servers. For HTTP requests, the CBR component uses WTE to forward client requests to the servers based on the content of the URL. For IMAP or POP3, the CBR component (without WTE) proxies the client requests to the appropriate server based on userid and password.
Figure 7. Example of a site using the Dispatcher and ISS to manage local servers
Figure 7 illustrates a site in which all servers are on a local network. The Dispatcher component is used to forward requests and the ISS component is used to provide system load information to the Dispatcher machine. A domain name server is not needed.
In this example, the ISS daemon is installed on each server. The administrator can configure which machine is used as the monitor. There is a priority ordering so that a lower-priority machine will take over as monitor only if the primary monitor has failed.
Figure 8. Example of a site using the Dispatcher and SMA to manage local servers
Figure 8 illustrates a site in which all servers are on a local network. The Dispatcher component is used to forward requests and the Server Monitor Agent (SMA) is used to provide system load information to the Dispatcher machine.
Note: | In this example, the SMA agent is installed on each server. SMA can only be installed on servers running on a Linux platform. For Network Dispatcher machines running on a Red Hat Linux platform, SMA replaces the ISS system monitoring function for load balancing based on system-specific metrics. |
Figure 9. Example of a site using Dispatcher to manage local and remote servers
Wide area support in Dispatcher enables you to use both local and remote servers. Figure 9 shows a configuration where one "local" Dispatcher serves as the entry point for all requests. It distributes these requests among its own local servers (a, b, and c) and to the remote Dispatcher, which will load balance to its local servers (d, e, and f).
Figure 10. Example of a site using ISS and Dispatcher to manage local and remote servers
Figure 10 illustrates a site in which servers are located on local and remote networks. The ISS component is used, in conjunction with a domain name server, to forward requests to the best Dispatcher machine; the Dispatcher component is used to forward requests to the optimal server.
Optionally, the ISS daemon can be installed on all the servers to provide system load information to the Dispatcher machines. The ISS monitor function must be used to send the ISS agent information to the Dispatcher. The ISS monitor can be a Dispatcher machine or on a different machine.
This chapter describes what the network planner should consider before installing and configuring the Dispatcher component. If you want to plan for the Interactive Session Support (ISS) component, see Chapter 9, Planning for the Interactive Session Support component. If you want to plan for the Content Based Routing (CBR) component, see Chapter 6, Planning for the Content Based Routing component. This chapter includes the following sections:
Note: | Additional disk space will be needed for logs. |
Note: | Additional disk space will be needed for logs. |
Note: | Additional disk space will be needed for logs. |
Note: | Additional disk space will be needed for logs. |
Dispatcher consists of the following functions:
The attributes of any object in the executor can be configured using ndcontrol. Setting the value of a default attribute causes succeeding objects created to have that attribute value, but does not affect the values of existing objects.
Using the manager is optional. However, if the manager is not used, load balancing will be performed using weighted round-robin scheduling based on the current server weights, and advisors will not be available.
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; does garbage collection of completed or reset connections and supplies this information to the manager.
Note: | For AIX, Red Hat Linux, and Solaris, Dispatcher may be set up on a server machine. If you are using Windows, Dispatcher may not be set up on a server machine. |
Figure 11. Dispatcher product components
The manager collects information from the executor, the advisors, and a system-monitoring program, such as ISS or SMA (unique to the Red Hat Linux platform). 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.
There are many ways that you can configure Dispatcher to support your site. If you have only one host name for your site to which all of your customers will connect, you can define a single cluster of servers. For each of these servers, you configure a port through which the Dispatcher communicates. See Figure 12.
Figure 12. Example of Dispatcher configured with a single cluster and 2 ports
In this example, at www.productworks.com, one cluster is defined. This cluster has two ports: port 80 for HTTP and port 443 for SSL. A client making a request to http://www.productworks.com (port 80) would go to a different server than a client requesting https://www.productworks.com (port 443).
Another way of configuring Dispatcher would be appropriate if you have a very large site with many servers dedicated to each protocol supported. In this case, you might want to define a cluster for each protocol with a single port but with many servers, as shown in Figure 13.
Figure 13. Example of Dispatcher configured with two clusters, each with one port
In this example, two clusters are defined: www.productworks.com for port 80 (HTTP) and www.testworks.com for port 443 (SSL).
A third way of configuring the Dispatcher would be necessary if your site does content hosting for several companies or departments, each one coming into your site with a different URL. In this case, you might want to define a cluster for each company or department and any ports to which you want to receive connections at that URL, as shown in Figure 14.
Figure 14. Example of the Dispatcher configured with 2 clusters, each with 2 ports
For example, two clusters are defined with port 80 for HTTP and port 23 for Telnet for each of the sites at www.productworks.com and www.testworks.com.
Figure 15. Example of a Dispatcher using simple high availability
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 would in a single Dispatcher configuration. The second Dispatcher machine monitors the "health" of the first, and will take 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.
For information about configuring high availability, see High availability.
Figure 16. Example of a Dispatcher using mutual 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 16. Dispatcher 1 can actively route packets for its primary Cluster A, while Cluster B is considered the backup for the corresponding Cluster B in Dispatcher 2. At the same time, Dispatcher 2 can actively route packets for its primary Cluster B, while Cluster A is considered the backup for the corresponding Cluster A in Dispatcher 1. If Dispatcher 2 were to fail and could no longer actively route packets for its primary Cluster B, Dispatcher 1 could take over routing packets for Cluster B.
Note: | Both machines must configure their shared cluster sets the same. |
For information about configuring high availability and mutual high availability, see High availability.
On AIX and Solaris, Network Dispatcher can reside on the same machine as a server for which it is load balancing requests. This is commonly referred to as collocating a server. This feature is supported on Red Hat Linux, but only in the absence of using high availability. The Windows platform does not support collocation.
In older releases, it was necessary to specify the collocated server address to be the same as the nonforwarding address (NFA) in the configuration. That restriction has been lifted.
To configure a server to be collocated, the ndcontrol server command provides an option called collocated which can be set to yes or no. The default is no. The address of the server must be a valid IP address of a network interface card on the machine. See ndcontrol server -- configure servers, for more information on ndcontrol server command syntax.
Note: | A collocated server competes for resources with Network Dispatcher during times of high traffic. However, in the absence of overloaded machines, using a collocated server offers a reduction in the total number of machines necessary to set up a load-balanced site. |
The ISS component may be used, in conjunction with a domain name server, to load balance requests among several Dispatcher machines. The Dispatcher machines would then load balance the requests to the optimal server. This creates a two-tiered form of load balancing. For a graphical overview and further explanation, see Using ISS and Dispatcher in a two-tiered configuration.
Before following the steps in this chapter, see Chapter 4, Planning for the Dispatcher component. This chapter explains how to create a basic configuration for the Dispatcher component of IBM Network Dispatcher. For more complex configurations or functions, see Chapter 8, Advanced Dispatcher and CBR Functions.
Note: | Before you begin the configuration steps in this table, ensure that your Dispatcher machine and all server machines are connected to the network, have valid IP addresses, and are able to ping one another. |
Table 4. Configuration tasks for the Dispatcher function
Task | Description | Related information |
---|---|---|
Set up the Dispatcher machine. |
Set up your load balancing configuration.
| Setting up the Dispatcher machine |
Set up machines to be load-balanced. | Alias the loopback device, check for an extra route, and delete any extra routes. | Setting up server machines for load balancing |
There are four basic methods of configuring the Dispatcher:
This is the most direct means of configuring the Dispatcher. The procedures in this manual assume use of the command line. The command is ndcontrol. For more information about commands, see Appendix B, Command reference for Dispatcher and CBR.
The commands for configuring the Dispatcher can be entered into a configuration script file and executed together. See Sample Network Dispatcher configuration files.
For an example of the GUI, see Figure 2.
To start the graphical user interface (GUI), follow these steps:
ndserver
In order to configure the Dispatcher component from the GUI, you must first select Dispatcher in the tree structure. You can start the executor and manager once you connect to a Host. You can also create clusters containing port and server, and start advisors for the manager.
The GUI can be used to do anything that you would do with the ndcontrol command. For example, to define a cluster using the command line, you would enter ndcontrol cluster add cluster command. To define a cluster from the GUI, you would click button number two on the mouse on executor, then in the pop-up menu, click on add cluster. Enter the cluster address in the pop-up window, then click OK.
Pre-existing Dispatcher configuration files can be loaded using the Load New Configuration and Append to Current Configuration options presented in the Host pop-up menu. You should save your Dispatcher configuration to a file periodically using the Save Configuration File As option also presented in the Host pop-up menu. The File menu located at the top of the GUI will allow you to save your current host connections to a file or restore connections in existing files across all IBM Network Dispatcher components.
The configuration commands can also be run remotely. For more information, see Remote Authenticated Administration.
You can access Help by clicking the question mark icon in the upper right hand corner of the Network Dispatcher window.
For more information about using the GUI, see General Instructions for using the GUI.
For more information about using the configuration wizard, see Configuring using the configuration wizard.
Before setting up the Dispatcher machine, you must be the root user (for AIX, Red Hat Linux, or Solaris) or the Administrator on Windows.
For AIX, Red Hat Linux, and Solaris only, the Network Dispatcher can have a collocated server. This simply means that the Network Dispatcher can physically reside on a server machine which it is load balancing.
You will need at least two valid IP addresses for the Dispatcher machine:
This IP address is the primary IP address of the Dispatcher machine and is called the nonforwarding address (NFA). This is by default the same address as that returned by the hostname command. Use this address to connect to the machine for administrative purposes, such as doing remote configuration via Telnet or accessing the SNMP subagent. If the Dispatcher machine can already ping other machines on the network, you do not need to do anything further to set up the nonforwarding address.
A cluster address is an address that is associated with a host name (such as www.yourcompany.com). This IP address is used by a client to connect to the servers in a cluster. This is the address that is load balanced by the Dispatcher.
Solaris Only: By default, Dispatcher is configured to load balance traffic on 100Mbps Ethernet network interface cards. To use a 10Mbps Ethernet adapter, you need to edit the /opt/nd/dispatcher/ibmnd.conf file. The ibmnd.conf file, which specifies the interface cards used to support Dispatcher, provides input to the Solaris autopush command and must be compatible with the autopush command. The default 100Mbps Ethernet adapter is specified in /opt/nd/dispatcher/ibmnd.conf as hme. To use a 10Mbps Ethernet adapter, replace hme with le. To support multiple types of adapters, replicate the line in the ibmnd.conf file and modify each line to match your device type. For example, if you plan to use two 100Mbps Ethernet adapters, the ibmnd.conf file should have a single line specifying the hme device. If you plan to use one 10Mbps Ethernet adapter and one 100Mbps Ethernet adapter, you will have two lines in the ibmnd.conf file: one line specifying the le device and one line specifying the hme device.
Windows Only: Ensure that IP forwarding is not enabled for the TCP/IP protocol. (See your Windows TCP/IP configuration.)
Figure 17 shows an example of Dispatcher set up with a single cluster, two ports, and three servers.
Figure 17. Example of the IP addresses needed for the Dispatcher machine
For help with commands used in this procedure, see Appendix B, Command reference for Dispatcher and CBR.
For a sample configuration file, see Sample Network Dispatcher configuration files.
AIX, Red Hat Linux, and Solaris: To start the server function, enter ndserver.
Windows: The server function starts automatically as a service.
To start the executor function, enter the ndcontrol executor start command. You may also change various executor settings at this time. See Appendix B, Command reference for Dispatcher and CBR.
The nonforwarding address is used to connect to the machine for administrative purposes, such as using Telnet or SMTP to this machine. By default, this address is the hostname.
To define the nonforwarding address, enter the ndcontrol executor set nfa IP_address command or edit the sample configuration file. IP_address is either the symbolic name or the dotted-decimal address.
Dispatcher will balance the requests sent to the cluster address to the corresponding servers configured on the ports for that cluster.
The cluster is either the symbolic name, the dotted decimal address, or the special address 0.0.0.0 that defines a wildcard cluster. To define a cluster, issue the command ndcontrol cluster add. To set cluster options, issue the command ndcontrol cluster set or you can use the GUI to issue commands. Wildcard clusters can be used to match multiple IP addresses for incoming packets to be load balanced. See Use wildcard cluster to combine server configurations, Use wildcard cluster to load balance firewalls, Use wildcard cluster with WTE for transparent proxy for more information.
Once the cluster has been defined, you normally must configure the cluster address on one of the network interface cards of the Dispatcher machine. To do this, issue the command ndcontrol cluster configure cluster_address. This will look for an adapter with an existing address that belongs on the same subnet as the cluster address. It will then issue the system's adapter configuration command for the cluster address, using the adapter found and the netmask for the existing address found on that adapter.
ndcontrol cluster configure 204.67.172.72
Circumstances where you would not want to configure the cluster address are for clusters added to a standby server in high-availability mode, or clusters added to a wide-area dispatcher acting as a remote server. You also do not need to run the cluster configure command if, in stand-alone mode, you use the sample goIdle script. For information on the goIdle script, see Using scripts.
In rare cases you may have a cluster address that does not match any subnet for existing addresses. In this case, use the second form of the cluster configure command and explicitly provide the interface name and netmask. Use ndcontrol cluster configure cluster_address interface_name netmask.
Some examples are:
ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (AIX) ndcontrol cluster configure 204.67.172.72 eth0:1 255.255.0.0 (Red Hat Linux) ndcontrol cluster configure 204.67.172.72 le0:1 255.255.0.0 (Solaris) ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (Windows)
In order to use the second form of the cluster configure command on Windows, you must determine the interface name to use.
If you have only one Ethernet card in your machine, the interface name will be en0. Likewise, if you have only one Token Ring card, the interface name will be tr0. If you have multiple cards of either type, you will need to determine the mapping of the cards. Use the following steps:
The network interface adapters are listed under Network Cards. Click each one to determine whether it is an Ethernet or Token Ring interface. The type of interface is listed in the Description column. The names assigned by ndconfig map to the interface types. For example, the first Ethernet interface in the list is assigned by ndconfig to en0, the second to en1, and so on; the first Token Ring interface is assigned to tr0, the second to tr1, and so on.
Note: | The Windows registry begins numbering adapters with 1, not 0. |
After you obtain this mapping information, you can create an alias on the network interface to the cluster address.
The cluster configure command merely runs ifconfig (or ndconfig on NT) commands, so you can still use the ifconfig (ndconfig) commands if you wish.
The ndconfig command is supplied with the Dispatcher component to configure cluster aliases using the command line. The ndconfig command has the same syntax as a UNIX ifconfig command.
ndconfig en0 alias 204.67.172.72 netmask 255.255.0.0
Note: | The netmask parameter is required. It should be in dotted-decimal (255.255.0.0) or hex (0xffff0000) form. |
To determine the interface name, use the same technique as for the second form of the cluster configure command.
When using bind-specific server applications that bind to a list of IP addresses that do not contain the server's IP, use arp publish command instead of ifconfig to dynamically set an IP address on the Network Dispatcher machine. For example:
arp -s <cluster> <Network Dispatcher MAC address> publish
To define a port, enter the ndcontrol port add cluster:port command, edit the sample configuration file, or use the GUI. Cluster is either the symbolic name or the dotted-decimal address. Port is the number of the port you are using for that protocol.
Port number 0 (zero) is used to specify a wildcard port. This port will accept traffic for a port that is not destined for any of the defined ports on the cluster. See Use wildcard port to direct unconfigured port traffic for more information about when you might want to use a wildcard port.
You may also change various port settings at this time. See Appendix B, Command reference for Dispatcher and CBR. You must define and configure all servers for a port. The wildcard port will be used to configure rules and servers for any port. This function could also be used if you have an identical server/rule configuration for multiple ports. The traffic on one port could then affect the load-balancing decisions for traffic on other ports.
To define a load-balanced server machine, enter the ndcontrol server add cluster:port:server command, edit the sample configuration file, or use the GUI. Cluster and server are either the symbolic name or the dotted-decimal address. Port is the number of the port you are using for that protocol. You must define more than one server to a port on a cluster in order to perform load balancing.
Multiple address collocation: In a collocated configuration, the address of the collocated server machine does not have to be identical to the nonforwarding address (NFA). You can use another address if your machine has been defined with muliple IP addresses. For the Dispatcher component, the collocated server machine must be defined as collocated using the ndcontrol server command.
For more information on ndcontrol server command syntax, see ndcontrol server -- configure servers.
For more information on collocated servers, see Using Collocated Servers.
The manager function improves load balancing. To start the manager, enter the ndcontrol manager start command, edit the sample configuration file, or use the GUI.
The advisors give the manager more information about the ability of the
load-balanced server machines to respond to requests. The
advisors currently available are listed below along with their default
ports:
Advisor Name | Protocol | Port |
---|---|---|
ftp | FTP | 21 |
telnet | Telnet | 23 |
smtp | SMTP | 25 |
http | HTTP | 80 |
imap | IMAP | 143 |
pop3 | POP3 | 110 |
nntp | NNTP | 119 |
ssl | SSL | 443 |
Workload Manager | private | 10,007 |
WTE | HTTP | 80 |
PING | ping | 0 |
To start the advisors, enter the ndcontrol advisor start name port command, edit the sample configuration file, or use the GUI. name refers to the protocol that you want to monitor. port is the number of the port you are using for that protocol. The FTP advisor should advise only on the FTP control port (21). Do not start an FTP advisor on the FTP data port (20).
If you have started any advisors, you must change the manager proportions to allow the advisor information to be included in the load balancing decisions. You should use the ndcontrol manager proportions command. See Proportion of importance given to status information.
If your server is collocated on your Dispatcher machine, do not perform the following procedure.
Follow the steps in this section to set up the load-balanced server machines.
For the load-balanced server machines to work, you must set (or preferably alias) the loopback device (often called lo0) to the cluster address. The Dispatcher component does not change the destination IP address in the TCP/IP packet before forwarding the packet to a TCP server machine. By setting or aliasing the loopback device to the cluster address, the load balanced server machines will accept a packet that was addressed to the cluster address.
If you have an operating system that supports network interface aliasing (such as AIX, Linux, Solaris, Windows NT or Windows 2000), you should alias the loopback device to the cluster address. The benefit of using an operating system that supports aliases is that you have the ability to configure the load-balanced server machines to serve multiple cluster addresses.
Note: | For Linux servers only, in order to alias the loopback device a specific patch is required for Linux kernel versions 2.2.5, 2.2.12, and 2.2.13. See Installing the Linux kernel patch (for aliasing the loopback device), for more information. |
If you have a server with an operating system that does not support aliases, such as HP-UX and OS/2, you must set the loopback device to the cluster address.
Use the command for your operating system as shown in Table 5 to set or alias the loopback device.
Table 5. Commands to alias the loopback device (lo0) for Dispatcher
Using the example shown in Figure 17, and setting up a load-balanced server machine that is running Solaris, the command would be:
ifconfig lo0:1 204.67.172.72 127.0.0.1 up
On some operating systems, a default route may have been created and needs to be removed.
route print
netstat -nr
Windows Example:
Active Routes: Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 9.67.128.1 9.67.133.67 1 9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1 9.67.128.0 255.255.248.0 9.67.133.67 9.67.133.67 1 9.67.133.67 255.255.255.255 127.0.0.1 127.0.0.1 1 9.67.133.158 255.255.255.255 127.0.0.1 127.0.0.1 1 9.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 9.67.133.158 9.67.133.158 1 224.0.0.0 224.0.0.0 9.67.133.67 9.67.133.67 1 255.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1
9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1
You must delete the extra route. Use the command for your operating system shown in Table 6 to delete the extra route.
Example: To delete the extra route as shown in the example, enter:
route delete 9.0.0.0 9.67.133.158
Table 6. Commands to delete any extra route for Dispatcher
HP-UX | route delete cluster_address cluster_address | ||
Windows 2000/ NT | route delete network_address cluster_address (at an
MS-DOS prompt)
|
Using the example shown in Figure 17, and setting up a server machine that is running AIX, the command would be:
route delete -net 204.0.0.0 204.67.172.72
For Linux servers only, in order to alias the loopback device a specific patch (depending on the Linux kernel version) is required. A patch for Linux kernel versions 2.2.5, 2.2.12, and 2.2.13 can be downloaded at the following website: http://www.ibm.com/developer/linux.
Note: | This Linux kernel patch is not code written by IBM. It was written by members of the open source community. IBM cannot warrant this code as suitable for your specific environment, because the conditions of its use are beyond IBM's control. It was used to test the IBM product and was found to be satisfactory in the IBM testing environment. You should evaluate the usefulness of this code in your own environment, and decide if it meets your needs. This code may or may not be included in future versions of the Linux base source code. |
The following are the steps for installing the Linux kernel patch for versions 2.2.12 and 2.2.13 on your Linux server machines:
patch -p0<patchfile
echo 1 >> /proc/sys/net/ipv4/conf/lo/arp_invisible
This command will only last until the machine is rebooted. Once rebooted it will be necessary to follow this and the subsequent steps again.
ifconfig lo:1 cluster netmask 0.0.0.0 up
This chapter describes what the network planner should consider before installing and configuring the CBR component. If you want to plan for the Dispatcher component, see Chapter 4, Planning for the Dispatcher component. If you want to plan for the ISS component, see Chapter 9, Planning for the Interactive Session Support component. This chapter includes:
Note: | Additional disk space will be needed for logs. |
Note: | Additional disk space will be needed for logs. |
Note: | Additional disk space will be needed for logs. |
Note: | Additional disk space will be needed for logs. |
The CBR component allows you to:
Note: | CBR cannot be configured for both (HTTP and IMAP/ POP3) types of traffic on the same Network Dispatcher machine. |
CBR can be configured via the command line (cbrcontrol) or the graphical user interface (ndadmin).
CBR is very similar to Dispatcher in its component structure. CBR consists of the following functions:
Using the manager is optional. However, if the manager is not used, load balancing will be performed using weighted round-robin scheduling based on the current server weights, and advisors will not be available.
The three key functions of CBR (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 and active connections and supplies this information to the manager.
To start CBR in proxy mode, issue the cbrserver command from the command prompt.
CBR (without WTE) can provide a single point of presence for many IMAP or POP3 servers. Each server can have a subset of all mailboxes serviced by the point of presence. For IMAP and POP3, CBR is a proxy that chooses an appropriate server based on user ID and password provided by the client.
Note: | The CBR proxy does not support rules-based load balancing. |
An example of a method for distributing requests based on client user ID is the following. If you have two (or more) POP3 servers, you can choose to divide the mailboxes alphabetically by user ID. Client requests with user ID's beginning with letters A-I can be distributed to server 1. Client requests with user ID's beginning with letters J-R can be distributed on server 2, and so on.
You can also choose to have each mailbox represented on more than one server. In that case, the content of each mailbox must be available to all servers with that mailbox. In the event of a server failure, another server can still access the mailbox.
In order to have only one address representing multiple POP3 mail servers, the CBR proxy can be configured with a single cluster address that becomes the POP3 mail server address for all clients. The commands to configure this are the following:
cbrcontrol cluster add pop3MailServer cbrcontrol port add pop3MailServer:110 protocol pop3 cbrcontrol server add pop3MailServer:110:pop3Server1+pop3Server2+pop3Server3
In this example, pop3MailServer represents the cluster address. Port 110 with proxy protocol POP3 is added to the pop3MailServer. Pop3Server1, pop3Server2, and pop3Server3 represent POP3 mail servers which are added to the port. With this configuration, you can configure your mail clients' incoming POP3 requests with the pop3MailServer cluster address.
When a POP3 request arrives at the proxy, the proxy attempts to contact all the configured servers for the port using the client's user ID and password. The client's request is directed to the first server that responds. You should use the sticky/affinity feature in conjunction with the CBR proxy for IMAP or POP3 servers. The affinity feature allows subsequent requests from the same client's user ID to be directed to the same server. Set stickytime for the port to a value greater than zero to enable this affinity feature. For more information on the affinity feature, see How classical ND affinity works.
The inactivity autologout timer for POP3 and IMAP protocols is a minimum of 10 minutes and 30 minutes respectively. This timeout is the number of seconds during which there can be no activity on a connection before that connection is removed. To optimize performance, the CBR proxy overrides the inactivity timeout value to 60 seconds. In order to change the inactivity timeout, change the staletimeout value on the cbrcontrol port command. For information on configuring this command, see ndcontrol port -- configure ports.
The CBR component gives you the ability to specify a set of servers that will handle a request based on regular expression matching the content of the request. CBR allows you to partition your site so that different content or application services can be served by different sets of servers. This partitioning will be transparent to clients accessing your site. Because CBR allows you to specify multiple servers for each type of request, the requests can be load balanced for optimal client response. By allowing multiple servers to be assigned to each type of content, you are protected if one workstation or server fails. CBR will recognize the failure and continue to load balance client requests to the other servers in the set.
One way to divide your site would be to assign some servers to handle only cgi requests, and another set of servers to handle all other requests. This would stop compute intensive cgi scripts from slowing down the servers for normal html traffic, allowing clients to get better overall response time. Using this scheme, you could also assign more powerful workstations for normal requests. This would give clients better response time without the expense of upgrading all your servers.
You could also assign more powerful workstations for cgi requests.
Another possibility for partitioning your site could be to direct clients who are accessing pages requiring registration to one set of servers, and all other requests to a second set of servers. This would keep casual browsers of your site from tying up resources that could be used by clients who have committed to your registration. It would also allow you to use more powerful workstations to service those clients who have registered.
You could of course combine the methods above for even more flexibility, and improved service.
CBR runs as a subprocess of WTE, the caching proxy server, which must be installed on the same machine. CBR along with WTE filters Web page content using specified rule types. When running, WTE accepts client requests and queries the CBR component for the best server. Upon this query, CBR matches the request to a set of prioritized rules. When a rule is matched, an appropriate server is chosen from a preconfigured server set. Finally, CBR informs WTE which server was chosen and the request gets proxied there.
Once you have defined a cluster to be load balanced, you must make sure that all requests to that cluster have a rule that will choose a server. If no rule is found that matches a particular request, the client will receive an error page from WTE. The easiest way to ensure that all request will match some rule, is to create an always true rule at a very high priority number. Make sure that the servers used by this rule can handle all the requests not explicitly handled by the rules with lower priority numbers.
Before following the steps in this chapter, see Chapter 6, Planning for the Content Based Routing component. This chapter explains how to create a basic configuration for the CBR component of IBM Network Dispatcher. For more complex configurations or functions, see Chapter 8, Advanced Dispatcher and CBR Functions.
Note: | Before you begin the configuration steps in this table, ensure that your CBR machine and all server machines are connected to the network, have valid IP addresses, and are able to ping one another. |
Table 7. Configuration tasks for the CBR component
Task | Description | Related information |
---|---|---|
Set up the CBR machine. | Finding out about the requirements. | Setting up the CBR machine |
Set up machines to be load-balanced. | Set up your load balancing configuration. | Step 5. Define load balanced server machines |
To create a basic configuration for the CBR component of Network Dispatcher, there are three basic methods:
This is the most direct means of configuring CBR. The procedures in this manual assume use of the command line. The command is cbrcontrol. For more information about commands, see Appendix B, Command reference for Dispatcher and CBR.
Note: | To start CBR in proxy mode for IMAP or POP3, first issue the cbrserver command from the command prompt. Then issue cbrcontrol commands you want to set up your configuration. |
The commands for configuring CBR can be entered into configuration script file and executed together.
For a diagram of the GUI, see Figure 2.
For IMAP or POP3, prior to starting the GUI, start the CBR proxy by issuing cbrserver command from the command prompt.
For HTTP, prior to starting the GUI, Web Traffic Express (WTE) must be running. To start the GUI:
In order to configure the CBR component from the GUI, you must first select Content Based Routing in the tree structure. You can start the manager once you connect to a Host. You can also create clusters containing ports and servers, and start advisors for the manager.
The GUI can be used to do anything that you would do with the cbrcontrol command. For example, to define a cluster using the command line, you would enter cbrcontrol cluster add cluster command. To define a cluster from the GUI, you would click button number two of the mouse on Executor, then in the pop-up menu, click on add cluster. Enter the cluster address in the pop-up window, then click OK.
Pre-existing CBR configuration files can be loaded using the Load New Configuration and Append to Current Configuration options presented in the Host pop-up menu. You should save your CBR configuration to a file periodically using the Save Configuration File As option also presented in the Host pop-up menu. The File menu located at the top of the GUI will allow you to save your current host connections to a file or restore connections in existing files across all Network Dispatcher components.
You can access Help by clicking the question mark icon in the upper right hand corner of the Network Dispatcher window.
For more information about using the GUI, see General Instructions for using the GUI.
If you are using the configuration wizard, follow these steps:
You can launch this wizard from the command prompt by issuing the cbrwizard. Or, select the Configuration Wizard from the CBR component menu as presented in the GUI.
The CBR wizard guides you step-by-step through the process of creating a basic configuration for the CBR component. It asks you questions about your network and guides you as you setup a cluster that enables CBR to load balance traffic between a group of servers.
With the CBR configuration wizard, you will see the following panels:
Before setting up the CBR machine, you must be the root user (for AIX, Red Hat Linux, or Solaris) or the Administrator on Windows.
You will need one IP address for each cluster of servers that will be set up. A cluster address is an address that is associated with a host name (such as www.company.com). This IP address is used by a client to connect to the servers in a cluster. Specifically, this address is found in the URL request from the client. All requests made to the same cluster address are load balanced by CBR.
WTE must be installed, and the WTE configuration file must be edited to use CBR. There are four entries:
Each entry must be on a single line. The location of these four entries should be after the first instance of "ServerInit," which is commented out in the configuration file.
The comma delimited set of parameters refer to the following:
Note: | This set of parameters cannot contain spaces. |
Figure 18. CBR configuration file for AIX
ServerInit /usr/lpp/nd/cbr/lib/libndcbr.so:ndServerInit CBR_CLIENT_KEYS_DIRECTORY=/usr/lpp/nd/admin/keys/cbr, CBR_SERVER_KEYS_DIRECTORY=/usr/lpp/nd/cbr/key, END_INSTALL_PATH=/usr/lpp/nd,/usr/lpp/nd/cbr/lib:/usr/lpp/ nd/cbr/lib/ibmcbr.jar:/usr/lpp/nd/admin/lib/ChartRuntime.jar, 11099,/usr/lpp/nd/cbr/logs/,/usr/lpp/nd/cbr/ configurations/ PreExit /usr/lpp/nd/cbr/lib/libndcbr.so:ndPreExit PostExit /usr/lpp/nd/cbr/lib/libndcbr.so:ndPostExit ServerTerm /usr/lpp/nd/cbr/lib/libndcbr.so:ndServerTerm
Figure 19. CBR configuration file for Red Hat Linux
#NOTE: replace /usr/local/J1.1.8 with the directory where Java is installed. ServerInit /opt/nd/cbr/lib/libndcbr.so:ndServerInit CBR_CLIENT_KEYS_DIRECTORY=/opt/nd/admin/keys/cbr, CBR_SERVER_KEYS_DIRECTORY=/opt/nd/cbr/key,END_INSTALL_PATH= /opt/nd,/usr/local/J1.1.8/lib/classes.zip:/opt/nd/cbr/lib:/opt/ nd/cbr/lib/ibmcbr.jar:/opt/nd/admin/lib/ChartRuntime.jar, 11099,/opt/nd/cbr/logs/,/opt/nd/cbr/configurations/ PreExit /opt/nd/cbr/lib/libndcbr.so:ndPreExit PostExit /opt/nd/cbr/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/cbr/lib/libndcbr.so:ndServerTerm
Figure 20. CBR configuration file for Solaris
ServerInit /opt/nd/cbr/lib/libndcbr.so:ndServerInit CBR_CLIENT_KEYS_DIRECTORY=/opt/nd/admin/keys/cbr, CBR_SERVER_KEYS_DIRECTORY=/opt/nd/cbr/key,END_INSTALL_PATH= /opt/nd,/opt/nd/cbr/lib:/opt/ nd/cbr/lib/ibmcbr.jar:/opt/nd/admin/lib/ChartRuntime.jar, 11099,/opt/nd/cbr/logs/,/opt/nd/cbr/configurations/ PreExit /opt/nd/cbr/lib/libndcbr.so:ndPreExit PostExit /opt/nd/cbr/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/cbr/lib/libndcbr.so:ndServerTerm
Figure 21. CBR configuration file for Windows
ServerInit c:\Progra~1\IBM\nd\cbr\lib\libndcbr.dll: ndServerInit CBR_CLIENT_KEYS_DIRECTORY=c:\Progra~1\IBM\nd\ admin\keys\cbr,CBR_SERVER_KEYS_DIRECTORY= c:\Progra~1\IBM\nd\cbr\key,END_INSTALL_PATH= c:\Progra~1\IBM\nd,c:\wspp\IBM\nd\cbr\lib; c:\Progra~1\IBM\nd\cbr\lib \ibmcbr.jar;c:\Progra~1\IBM\nd\admin\lib\ChartRuntime.jar, 11099, c:\Progra~1\IBM\nd\cbr\logs\, c:\Progra~1\IBM\nd\cbr\configurations\ PreExit c:\Progra~1\IBM\nd\cbr\lib\libndcbr.dll:ndPreExit PostExit c:\Progra~1\IBM\nd\cbr\lib\libndcbr.dll:ndPostExit ServerTerm c:\Progra~1\IBM\nd\cbr\lib\libndcbr.dll: ndServerTerm
In the new environment, start WTE.
In the new environment, start WTE.
In the new environment, start WTE.
From the start button select Start->Programs->IBM Web Traffic Express or start the Web Traffic Express service from the services panel.
CBR will balance the requests sent for the cluster address to the corresponding servers configured on the ports for that cluster.
The cluster address is either a symbolic name or a dotted decimal address. For HTTP, this address will be located in the host portion of the URL.
To define a cluster, issue the following command:
cbrcontrol cluster add cluster
To set cluster options, issue the following command:
cbrcontrol cluster set cluster option value
For more information, see Appendix B, Command reference for Dispatcher and CBR.
The port number is the port that the server applications are listening on. For CBR with WTE running HTTP traffic, this is typically port 80. For CBR proxy with IMAP traffic, this is typically port 143. And, for CBR proxy with POP3 traffic, this is typcially port 110.
For CBR w/WTE, to define a port to the cluster you defined in the previous step, issue the following:
cbrcontrol port add cluster:portFor CBR proxy, to define a port to the cluster you defined in the previous step, issue the following:
cbrcontrol port add cluster:port protocol [pop3|imap]
To set port options, issue the following:
cbrcontrol port set cluster:port option value
For more information, see Appendix B, Command reference for Dispatcher and CBR.
The server machines are the machines running the applications that you want load balanced. The server is the symbolic name or dotted decimal address of the server machine. To define a server on the cluster and port from step 3, issue the following command:
cbrcontrol server add cluster:port:server
You must define more than one server per port on a cluster in order to perform load balancing.
This is the key step in configuring CBR w/WTE for HTTP protocol. A rule defines how a URL request will be distinguished and sent to one of the appropriate set of servers. The special rule type used by CBR is called a content rule. To define a content rule, issue the following command:
cbrcontrol rule add cluster:port:rule type content pattern=pattern
The value pattern is the regular expression that will be compared to the URL in each client request. For more information on how to configure the pattern, see Appendix D, Rule types for CBR.
Some other rule types defined in Dispatcher can also be used in CBR for HTTP. For more information, see Configure rules-based load balancing.
When a rule is matched by a client request, the rule's set of servers is queried for which server is best. The rule's server set is a subset of the servers defined in the port. To add servers to a rule's server set, issue the following command:
cbrcontrol rule useserver cluster:port:rule server
The manager function improves load balancing. To start the manager, issue the following command:
cbrcontrol manager start
The advisors give the manager more information about the ability of the load balanced server machines to respond to requests. An advisor is specific to a protocol. The Network Dispatcher supplies HTTP, IMAP, and POP3 advisors for the three CBR supported protocols. For example, to start the HTTP advisor, issue the following command:
cbrcontrol advisor start http port
If you have started any advisors, you must change the manager proportions to allow the advisor information to be included in the load balancing decisions. To set manager proportions, issue the cbrcontrol manager proportions command. For more information, see Proportion of importance given to status information.
To configure CBR with WTE for HTTP follow these steps:
To configure CBR proxy for IMAP or POP3 follow these steps:
This chapter explains how to configure the load balancing parameters of
Dispatcher and CBR and how to set up Dispatcher and CBR for advanced
functions.
Table 8. Advanced configuration tasks for the Dispatcher and CBR functions
Task | Description | Related information |
---|---|---|
Optionally, change load-balancing settings |
You can change the following load-balancing settings:
| Optimizing the load balancing provided by Dispatcher and CBR |
Configure high availability or mutual high availability | Set up a second Dispatcher machine to provide a backup. | High availability |
Configure wide area Dispatcher support | Set up a remote Dispatcher to load balance across a wide area network. | Configure wide area Dispatcher support |
Create custom advisors | Write your own advisors for reporting on specific statuses of your servers. | Create custom (customizable) advisors |
Use Server Monitor Agent | For Red Hat Linux, SMA provides server load information to the Dispatcher. | Server Monitor Agent (SMA) |
Configure rules-based load balancing | Define conditions under which a subset of your servers will be used. | Configure rules-based load balancing |
Use explicit linking | Avoid bypassing the Dispatcher in your links. | Using explicit linking |
Use a private network | Configure the Dispatcher to load balance servers on a private network. | Using a private network configuration |
Use wildcard cluster to combine common server configurations | Addresses that are not explicitly configured will use the wildcard cluster as a way to load balance traffic. | Use wildcard cluster to combine server configurations |
Use wildcard cluster to load balance firewalls | All traffic will be load balanced to firewalls. | Use wildcard cluster to load balance firewalls |
Use wildcard cluster with WTE for transparent proxy | Allows Dispatcher to be used to enable a transparent proxy. | Use wildcard cluster with WTE for transparent proxy |
Use wildcard port to direct unconfigured port traffic | Handles traffic that is not configured for any specific port. | Use wildcard port to direct unconfigured port traffic |
Use sticky affinity feature to configure a cluster's port to be sticky | Allows client requests to be directed to the same server. | How classical ND affinity works |
Use Server Directed Affinity API | Provides an API which allows an external agent to influence the Dispatcher affinity behavior | Server Directed Affinity API to control client-server affinity |
Use cross port affinity to expand the sticky (affinity) feature across ports | Allows client requests received from different ports to be directed to the same server. | Cross port affinity |
Use affinity address mask to designate a common IP subnet address | Allows clients requests received from the same subnet to be directed to the same server. | Affinity address mask |
Use rule affinity override to provide a mechanism for a server to override the port sticky feature | Allows a server to override the stickytime setting on its port. | Rule affinity override |
Use Cookie Affinity to load balance servers for CBR | Allows a session to maintain affinity for a particular server. | Cookie affinity |
Use binary logging to analyze server statistics | Allows server information to be stored in and retrieved from binary files. | Using binary logging to analyze server statistics |
The manager function of Dispatcher and CBR performs load balancing based on the following settings:
You can change these settings to optimize load balancing for your network.
The manager may use the following external factors in its weighting decisions:
Along with the current weight for each server and some other information required for its calculations, the manager gets the first two values from the executor. These values are based on information that is generated and stored internally in the executor.
You can change the relative proportion of importance to the manager of the four values. Think of the proportions as percentages; the sum of the relative proportions must equal 100%. The default ratio is 50/50/0/0, which ignores the advisor and system information. You may need to try different proportions to find the combination that gives the best performance.
The number of active connections is dependent upon the number of clients as well as the length of time necessary to use the services that are being provided by the load balanced server machines. If the client connections are quick (such as small Web pages served using HTTP GET), then the number of active connections will be fairly low. If the client connections are slower (such as a database query), then the number of active connections will be higher.
You should avoid setting the first two values too low. You will disable Dispatcher's load balancing and smoothing unless you have the first two values set to at least 20 each.
Weights are set by the manager function based upon internal counters in the executor, feedback from the advisors, and feedback from a system-monitoring program, such as ISS. If you want to set weights manually, do not run the manager.
Weights are applied to all servers on a port. For any particular port, the requests will be distributed between servers based on their weights relative to each other. For example, if one server is set to a weight of 10, and the other to 5, the server set to 10 should get twice as many requests as the server set to 5.
To specify the maximum weight boundary that any server can have, enter the ndcontrol port set maxweight command. This command affects how much difference there can be between the number of requests each server will get. If you set the maximum weight to 1, then all the servers can have a weight of 1, 0 if quiesced, or -1 if marked down. As you increase this number, the difference in how servers can be weighted is increased. At a maximum weight of 2, one server could get twice as many requests as another. At a maximum weight of 10, one server could get 10 times as many requests as another. The default maximum weight is 20.
If an advisor finds that a server has gone down, it tells the manager, which sets the weight for the server to zero. As a result, the executor will not send any additional connections to that server as long as that weight remains zero. If there were any active connections to that server before the weight changed, they will be left to complete normally.
Without the manager, advisors cannot be run and cannot detect if a server is down. If you choose to run the advisors, but do not want the manager to update the weight you have set for a particular server, use the fixedweight option on the ndcontrol server command. For example:
ndcontrol server set cluster:port:server fixedweight yes
Once fixedweight is set to yes, you can use the ndcontrol server set weight command to set the weight to the value you desire. The server weight value remains fixed while the manager is running until you issue another ndcontrol server command with fixedweight set to no. For more information, see ndcontrol server -- configure servers.
To optimize overall performance, the manager is restricted in how often it can interact with the executor. You can make changes to this interval by entering the ndcontrol manager interval and ndcontrol manager refresh commands.
The manager interval specifies how often the manager will update the server weights that the executor uses in routing connections. If the manager interval is too low, it can mean poor performance as a result of the manager constantly interrupting the executor. If the manager interval is too high, it can mean that the executor's request routing will not be based on accurate, up-to-date information.
For example, to set the manager interval to 1 second, enter the following command:
ndcontrol manager interval 1
The manager refresh cycle specifies how often the manager will ask the executor for status information. The refresh cycle is based on the interval time.
For example, to set the manager refresh cycle to 3, enter the following command:
ndcontrol manager refresh 3
This will cause the manager to wait for 3 intervals before asking the executor for status.
Note: | The advisor defaults should work efficiently for the great majority of possible scenarios. Be careful when entering values other than the defaults. |
The advisor interval sets how often an advisor asks for status from the servers on the port it is monitoring and then reports the results to the manager. If the advisor interval is too low, it can mean poor performance as a result of the advisor constantly interrupting the servers. If the advisor interval is too high, it can mean that the manager's decisions about weighting will not be based on accurate, up-to-date information.
For example, to set the interval to 3 seconds for the HTTP advisor for port 80, enter the following command:
ndcontrol advisor interval http 80 3
It does not make sense to specify an advisor interval that is smaller that the manager interval.
To make sure that out-of-date information is not used by the manager in its load-balancing decisions, the manager will not use information from the advisor whose time stamp is older than the time set in the advisor timeout. The advisor timeout should be larger than the advisor polling interval. If the timeout is smaller, the manager will ignore reports that logically should be used. By default, advisor reports do not time out.
The product provides other methods for you to optimize load balancing for your servers. To work at top speed, updates to the weights for the servers are only made if the weights have changed significantly. Constantly updating the weights when there is little or no change in the server status would create an unnecessary overhead. When the percentage weight change for the total weight for all servers on a port is greater than the sensitivity threshold, the manager updates the weights used by the executor to distribute connections. Consider, for example, that the total weight changes from 100 to 105. The change is 5%. With the default sensitivity threshold of 5, the manager will not update the weights used by the executor, because the percentage change is not above the threshold. If, however, the total weight changes from 100 to 106, the manager will update the weights. To set the manager's sensitivity threshold to a value other than the default (for example, 6), enter the following command:
ndcontrol manager sensitivity 6
In most cases, you will not need to change this value.
The manager calculates the server weights dynamically. As a result, an updated weight can be very different from the previous one. Under most circumstances, this will not be a problem. Occasionally, however, it may cause an oscillating effect in the way the requests are load balanced. For example, one server can end up receiving most of the requests due to a high weight. The manager will see that the server has a high number of active connections and that the server is responding slowly. It will then shift the weight over to the free servers and the same effect will occur there too, creating an inefficient use of resources.
To alleviate this problem, the manager uses a smoothing index. The smoothing index limits the amount that a server's weight can change, effectively smoothing the change in the distribution of requests. A higher smoothing index will cause the server weights to change less drastically. A lower index will cause the server weights to change more drastically. The default value for the smoothing index is 1.5. At 1.5, the server weights can be rather dynamic. An index of 4 or 5 will cause the weights to be more stable. For example, to set the smoothing index to 4, enter the following command:
ndcontrol manager smoothing 4
In most cases, you will not need to change this value.
The high availability feature is only available for the Dispatcher component.
To improve Dispatcher availability, the Dispatcher high availability function uses the following mechanisms:
Note: | For an illustration and description of a mutual high availability configuration, where two Dispatcher machines sharing two cluster sets provide backup for each other, see Mutual high availability. Mutual high availability is similar to high availability but is based specifically on cluster address rather than on a Dispatcher machine as a whole. Both machines must configure their shared cluster sets the same. |
Complete syntax for ndcontrol highavailability is in Appendix B, Command reference for Dispatcher and CBR.
For a more complete discussion of many of the tasks below, see Setting up the Dispatcher machine.
Windows only: In addition, configure each nonforwarding address using the ndconfig command. For example:
ndconfig en0 nfa_addr netmask netmask
Note: | For mutual high availability configuration (Figure 16),
for example, configure the cluster sets shared between the 2 Dispatchers as
follows:
|
ndcontrol highavailability heartbeat add sourceaddress destinationaddress
Note: | Sourceaddress and destinationaddress are the IP addresses
(either DNSnames or dotted-decimal addresses) of the Dispatcher
machines. The values will be reversed on each machine.
Example:
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3For mutual high availability, at least one heartbeat pair must have the NFAs of the pair as the source and destination address. |
ndcontrol highavailability reach add 9.67.125.18Reach targets are recommended but not required. See Failure detection capability using heartbeat and reach target, for more information.
ndcontrol highavailability backup add primary [auto | manual] portnum
ndcontrol highavailability backup add backup [auto | manual] portnum
ndcontrol highavailability backup add both [auto | manual] portnum
Note: | Select an unused port on your machines as the portnum. Your two machines will communicate over this port. |
ndcontrol highavailability statusThe machines should each have the correct role (backup, primary, or both), states, and substates. The primary should be active and synchronized; the backup should be in standby mode and should be synchronized within a short time. The strategies must be the same.
Notes:
Besides the basic criteria of failure detection (the loss of connectivity between active and standby Dispatchers, detected through the heartbeat messages), there is another failure detection mechanism named "reachability criteria." When you configure the Dispatcher you provide a list of hosts that each of the Dispatchers should be able to reach in order to work correctly.
You should choose at least one host for each subnet your Dispatcher machine uses. The hosts could be routers, IP servers or other types of hosts. Host reachability is obtained by the reach advisor, which pings the host. Switchover takes place either if the heartbeat messages cannot go through, or if the reachability criteria are met better by the standby Dispatcher than by the primary Dispatcher. To make the decision based on all available information, the active Dispatcher regularly sends the standby Dispatcher its reachability capabilities. The standby Dispatcher then compares those capabilities with its own and decides whether to switch.
Two Dispatcher machines are configured: the primary machine, and a second machine called the backup. At startup, the primary machine sends all the connection data to the backup machine until that machine is synchronized. The primary machine becomes active, that is, it begins load balancing. The backup machine, meanwhile, monitors the status of the primary machine, and is said to be in standby state.
If the backup machine at any point detects that the primary machine has failed, it performs a takeover of the primary machine's load balancing functions and becomes the active machine. After the primary machine has once again become operational, the machines respond according to how the recovery strategy has been configured by the user. There are two kinds of strategy:
The strategy parameter must be set the same for both machines.
The manual recovery strategy allows you to force the routing of packets to a particular machine, using the takeover command. Manual recovery is useful when maintenance is being performed on the other machine. The automatic recovery strategy is designed for normal unattended operation.
For a mutual high availability configuration, there is no per cluster failure. If any problem occurs with one machine, even if it affects just one cluster, then the other machine will take over for both clusters.
For Dispatcher to route packets, each cluster address must be aliased to a network interface device.
Since the Dispatcher machines will change states when a failure is detected, the commands above must be issued automatically. Dispatcher will execute user-created scripts to do that. The following scripts may be used. These scripts can be found in the dispatcher/samples subdirectory and must be moved to the bin subdirectory to be run.
Note: | For a mutual high availability configuration, each "go" script will be called by the Dispatcher with a parameter identifying the primary Dispatcher address. The script must query this parameter and perform the ifconfig commands for those cluster addresses associated with that primary Dispatcher. |
This feature is only available for the Dispatcher component.
If you are not using the Dispatcher's wide area support, a Dispatcher configuration requires that the Dispatcher machine and its servers all be attached to the same LAN segment (see Figure 22). A client's packet comes into the ND machine and is sent to the server, and then from the server directly back to the client.
Figure 22. Example of a configuration consisting of a single LAN segment
The Wide Area Dispatcher enhancement adds support for offsite servers, known as remote servers. Servers on the same LAN segment as the Dispatcher machine will be referred to as local servers. A remote server consists of a remote Dispatcher machine and its locally attached servers. All the Dispatcher machines must be on the same operating system. A client's packet can now go from the Internet to a Dispatcher machine, from there to a geographically remote Dispatcher machine to one of its locally attached servers, and from the server directly back to the Internet and the client.
Figure 23. Example of configuration using local and remote servers
This allows one cluster address to support all worldwide client requests while distributing the load to servers around the world.
The Dispatcher machine initially receiving the packet can still have local servers attached to it and it can distribute the load between its local servers and the remote servers. See Figure 23.
Wide area commands are not complex. To configure wide area support :
ndcontrol executor set wideportnumber <port>
ndcontrol server add cluster:port:server router <address>
On entry-point Dispatchers, advisors will work correctly without any special configuration. On remote Dispatchers, you will need to perform the following configuration steps for each remote cluster address. For a high-availability configuration at the remote ND location, you must perform these steps on both machines.
AIX
ifconfig lo0 alias 9.67.34.123 netmask 255.255.240.0
Note: | Advisors running on both the local and remote Dispatcher machines are necessary. |
Red Hat Linux
ifconfig lo:1 alias 9.67.34.123 netmask 255.255.240.0 up
Note: | Advisors running on both the local and remote Dispatcher machines are necessary. |
Solaris
Windows
arp -a
arp -d 9.67.34.123
Note: | To determine the MAC address of your interface, enter:
and look for the address of your machine. |
arp -s 9.67.34.123 00-01-5a-42-34-56
Figure 24. Wide area example configuration
This example applies to the configuration illustrated in Figure 24.
Here is how to configure the Dispatcher machines to support cluster address xebec on port 80. ND1 is defined as the "entry point," and port 12345 is the wide area port. A token-ring LAN is assumed. Note that ND1 has five servers defined: three local and two remote. Remotes ND2 and ND3 each have three local servers defined.
At the console of the first Dispatcher (ND1), do the following:
ndcontrol executor set nfa ND1
ndcontrol executor set wi 12345
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND1 and also configure xebec as clusteraddr.
ndcontrol cluster configure xebec
At the console of the second Dispatcher (ND2):
ndcontrol executor set nfa ND2
ndcontrol executor set wi 12345
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND2
At the console of the third Dispatcher (ND3):
ndcontrol executor set nfa ND3
ndcontrol executor set wi 12345
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND3
You can use the Dispatcher along with ISS to do load balancing across a wide area network. See Figure 28.
Advisors are agents within the Dispatcher and CBR components. Their purpose is to assess the health and loading of server machines. They do this with a proactive client-like exchange with the servers. Advisors can be considered as lightweight clients of the application servers.
The product provides several protocol-specific advisors for the most popular protocols. It does not make sense to use some of the provided advisors with the CBR component (such as: Telnet). Since version 2.0, the product has supported the concept of a "custom advisor" that allows users to write their own advisors.
Advisors periodically open a TCP connection with each server and send a request message to the server. The content of the message is specific to the protocol running on the server. For example, the HTTP advisor sends a "HEAD" request to the server.
Advisors then listen for a response from the server. After getting the response, the advisor makes an assessment of the server. To calculate this "load" value, most advisors measure the time for the server to respond, and then use this value (in milliseconds) as the load.
Advisors then report the load value to the manager function, where it appears in the manager report in the "Port" column. The manager then calculates aggregate weight values from all its sources, per its proportions, and sets these weight values into the executor function. The Executor will then use these weights for load balancing new incoming client connections.
If the advisor determines that a server is alive and well, it will report a positive, non-zero load number to the Manager. If the advisor determines that a server is not active, it will return a special load value of negative one (-1). The Manager and the Executor will not forward any further connections to that server.
Note: | The SSL advisor has no dependency upon key management or certificates. |
Note: | When using WTE advisor, WTE needs to be running on all servers being load balanced. The machine on which the IBM Network Dispatcher resides does not need to have WTE installed unless it is on the same machine it is load balancing. |
The custom (customizable) advisor is a small piece of Java code, which you provide as a class file, that gets called by the base code. The base code provides all administrative services, such as starting and stopping an instance of the custom advisor, providing status and reports, and recording history information in a log file. It also reports results to the manager component. Periodically the base code will perform an advisor cycle, where it individually evaluates all servers in its configuration. It starts by opening a connection with a server machine. If the socket opens, the base code will call the "getLoad" method (function) in the custom advisor. The custom advisor then performs whatever steps are necessary to evaluate the health of the server. Typically, it will send a user-defined message to the server and then wait for a response. (Access to the open socket is provided to the custom advisor.) The base code then closes the socket with the server and reports the load information to the Manager.
The base code and custom advisor can operate in either normal or replace mode. Choice of the mode of operation is specified in the custom advisor file as a parameter in the constructor method.
In normal mode, the custom advisor exchanges data with the server, and the base advisor code times the exchange and calculates the load value. The base code then reports this load value to the manager. The custom advisor needs only return a zero (on success) or negative one (on error). To specify normal mode, the replace flag in the constructor is set to false.
In replace mode, the base code does not perform any timing measurements. The custom advisor code performs whatever operations are desired for its unique requirements, and then returns an actual load number. The base code will accept the number and report it to the manager. For best results, normalize your load number between 10 and 1000, with 10 representing a fast server, and 1000 representing a slow server. To specify replace mode, the replace flag in the constructor is set to true.
With this feature, you can write your own advisors that will provide the precise information about servers that you need. A sample custom advisor is provided with the Network Dispatcher product. After installing Dispatcher or CBR components, you may find the sample code in /samples/CustomAdvisors/ADV_sample.java.
The default install directories are:
Sample custom advisor files specifically for the WebSphere Application Server (WAS) advisor are also provided in the install directory for both the Dispatcher and the CBR components.
The WAS advisor sample files reside in the same samples directory as the ADV_sample.java file.
Your custom advisor file name must be in the form "ADV_myadvisor.java." It must start with the prefix " ADV_" in uppercase. All subsequent characters must be in lowercase letters.
As per Java conventions, the name of the class defined within the file must match the name of the file. If you copy the sample code, be sure to change all instances of "ADV_sample" inside the file to your new class name.
Custom advisors are written in Java language. You must obtain a Java compiler for your machine, and be able to run its compiler, javac. These files are referenced during compilation:
Your classpath must point to all three of these files during the compile.
For Windows, a compile command might look like this:
c:\temp>c:\jdk1.1.8\bin\javac -classpath .;ibmnd.jar;c:\jdk1.1.8\lib\classes.zip ADV_fred.java
where:
The output for the compilation is a class file, for example
ADV_fred.class
Note: | If you wish, custom advisors may be compiled on one operating system and run on another. For example, you may compile your advisor on Windows, copy the class file (in binary) to an AIX machine, and run the custom advisor there. |
For AIX, Red Hat Linux, and Sun, the syntax is similar.
To run the custom advisor, you must first copy the class file to the proper subdirectory of the Dispatcher or CBR component:
samples/CustomAdvisors/ADV_fred.class
Configure the component, start its manager function, and issue the command to start your custom advisor:
ndcontrol advisor start fred 123 or cbrcontrol advisor start fred 123
where:
Like all advisors, a custom advisor extends the function of the advisor base, called ADV_Base. It is the advisor base that actually performs most of the advisor's functions, such as reporting loads back to the manager for use in the manager's weight algorithm. The advisor base also performs socket connect and close operations and provides send and receive methods for use by the advisor. The advisor itself is used only for sending and receiving data to and from the port on the server being advised. The TCP methods within the advisor base are timed to calculate the load. A flag within the constructor in the ADV_base overwrites the existing load with the new load returned from the advisor if desired.
Note: | Based on a value set in the constructor, the advisor base supplies the load to the weight algorithm at specified intervals. If the actual advisor has not completed so that it can return a valid load, the advisor base uses the previous load. |
These are base class methods:
Dispatcher and CBR first look at the list of native advisors that it provides. If it does not find a given advisor there, Dispatcher and CBR then look at the customer's list of customized advisors.
/usr/lpp/nd/dispatcher/samples/,/usr/lpp/nd/cbr/samples
/opt/nd/dispatcher/samples/,/opt/nd/cbr/samples
/opt/nd/dispatcher/samples/,/opt/nd/cbr/samples
C:\Program Files\IBM\nd\dispatcher\samples\,C:\Program Files\ IBM\nd\cbr\samples
The program listing for a sample advisor is included in Sample advisor. After installation, this sample advisor can be found in the samples\CustomAdvisors directory.
This feature is only available for the Dispatcher component.
WLM is code that runs on MVS mainframes. It can be queried to ask about the load on the MVS machine.
When MVS Workload Management has been configured on your OS/390 system, Dispatcher can accept capacity information from WLM and use it in the load balancing process. Using the WLM advisor, Dispatcher will periodically open connections through the WLM port on each server in the Dispatcher host table and accept the capacity integers returned. Since these integers represent the amount of capacity that is still available and Dispatcher expects values representing the loads on each machine, the capacity integers are inverted by the advisor and normalized into load values (i.e. a large capacity integer but a small load value both represent a healthier server). The resulting loads are placed into the System column of the manager report.
There are several important differences between the WLM advisor and other Dispatcher advisors:
Like ISS and SMA (for Red Hat Linux), the WLM agent reports on server systems as a whole, rather than on individual protocol-specific server daemons. ISS, SMA, and WLM place their results into the system column of the manager report. As a consequence, running both the WLM advisor and ISS, or running both the WLM advisor and SMA at the same time is not supported.
This feature is only available for the Dispatcher component.
For Red Hat Linux only, the Server Monitor Agent (SMA) replaces the ISS system monitor. SMA provides server load information to the Dispatcher in the form of system-specific metrics, reporting on the health of the servers. The ND manager queries the Server Monitor Agent residing on each of the servers, assigning weights to the load balancing process using the metrics gathered from the agents. The results are placed into the manager report. Unlike ISS, SMA provides no DNS-based load balancing capabilities.
For a configuration example see Figure 8.
Like the WLM advisor, the SMA agent reports on server systems as a whole, rather than on individual protocol-specific server daemons. Both WLM and SMA place their results into the system column of the manager report. As a consequence, running both the WLM advisor and SMA at the same time is not supported.
The Server Monitor Agent can only be installed on servers running on the Red Hat Linux platform. Therefore, in order for Dispatcher to load balance correctly with SMA, all the servers in the configuration must have the agent installed and must be running on a Red Hat Linux platform.
port is the RMI port chosen for all agents to run on.
scriptname is the name of the script (stored on the server) which should run on each of the servers in the configuration. Two scripts are provided for the customer - cpuload and memload. The script contains a command which should return a numeric value in the range of 0-100. For more information on systemscript command, see ndcontrol manager -- control the manager.
Note: | Ensure Security --
|
The following two scripts are already provided for the customer: cpuload (returns the percentage of cpu in use ranging from 0-100) and memload(returns the percentage of memory in use ranging from 0-100). These scripts reside in the previously stated directory.
You can use rules-based load balancing to fine tune when and why packets are sent to which servers. The Dispatcher and CBR components review any rules you add from first priority to last priority, stopping on the first rule that it finds to be true, then load balancing the content between any servers associated with the rule. It already balances the load based on destination and port, but using rules expands your ability to distribute connections.
You should use rules-based load balancing with the Dispatcher component when you want to use a subset of your servers for some reason. You must always use rules with the CBR component. You can use the following types of rules:
We recommend that you make a plan of the logic that you want the rules to follow before you start adding rules to your configuration.
All rules have a name, type, priority, begin range, and end range, and may have a set of servers. In addition, the content type rule in the CBR component has a matching regular expression pattern associated with it. Rules are evaluated in priority order, with lower priority rules evaluated first. In other words, a rule with a priority of 1 will be evaluated before a rule with a priority of 2. The first rule that is satisfied will be used. Once a rule has been satisfied, no further rules are evaluated.
For a rule to be satisfied, it must meet two conditions:
If a rule has no servers associated with it, the rule only needs to meet condition one to be satisfied. In this case, Dispatcher will drop the connection request, and CBR will cause WTE to return an error page. If no rules are satisfied, Dispatcher will select a server from the full set of servers available on the port, and CBR will cause WTE to return an error page.
You may want to use rules based on the client IP address if you want to screen the customers and allocate resources based on where they are coming from.
For example, you have noticed that your network is getting a lot of unpaid and therefore unwanted traffic from clients coming from a specific set of IP addresses. You create a rule using the ndcontrol rule command, for example:
ndcontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
This rule would screen out any connection from IBM clients. You would then add to the rule the servers which you wanted accessible to IBMers, or if you do not add any servers to the rule, requests coming from 9.x.x.x addresses would not be served by any of your servers.
You may want to use rules based on the time of day for capacity planning reasons. For example, if your Web site gets hit most during the same group of hours every day, you might want to dedicate five servers to HTTP during full-time, then adding another five during the peak time period.
Another reason you might use a rule based on the time of day is when you want to take some of the servers down for maintenance every night at midnight, so you would set up a rule that excludes those servers during the necessary maintenance period.
Note: | The manager must be running for the following to work. |
You may want to use rules based on connections per second on a port if you need to share some of your servers with other applications. For example, you set two rules:
Or you might be using Telnet and want to reserve two of your five servers for Telnet, except when the connections per second increase above a certain level. This way, Dispatcher would balance the load across all five servers at peak times.
Note: | The manager must be running for the following to work. |
You may want to use rules based on active connections total on a port if your servers get overloaded and start throwing packets away. Certain Web servers will continue to accept connections even though they do not have enough threads to respond to the request. As a result, the client requests time out and the customer coming to your Web site is not served. You can use rules based on active connections to balance capacity within a pool of servers.
For example, you know from experience that your servers will stop serving after they have accepted 250 connections. You can create a rule using the ndcontrol rule command or the cbrcontrol rule command, for example:
ndcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 or cbrcontrol rule add 130.40.52.153.80:pool2 type active beginrange 250 endrange 500
You would then add to the rule your current servers plus some additional servers, which will otherwise be used for other processing.
This rule type is only available in the Dispatcher component.
You may want to use rules based on the client port if your clients are using some kind of software that asks for a specific port from TCP/IP when making requests.
For example, you could create a rule that says that any request with a client port of 10002 will get to use a set of special fast servers because you know that any client request with that port is coming from an elite group of customers.
A rule may be created that is "always true." Such a rule will always be selected, unless all the servers associated with it are down. For this reason, it should ordinarily be at a lower priority than other rules.
You can even have multiple "always true" rules, each with a set of servers associated with it. The first true rule with an available server is chosen. For example, assume you have six servers. You want two of them to handle your traffic under all circumstances, unless they are both down. If the first two servers are down, you want a second set of servers to handle the traffic. If all four of these servers are down, then you will use the final two servers to handle the traffic. You could set up three "always true" rules. Then the first set of servers will always be chosen as long as at least one is up. If they are both down, one from the second set will be chosen, and so forth.
As another example, you may want an "always true" rule to ensure that if incoming clients do not match any of the rules you have set, they will not be served. You would create a rule using the ndcontrol rule command like:
ndcontrol rule add 130.40.52.153:80:jamais type true priority 100
Then you would not add any servers to the rule, causing the clients packets to be dropped with no response.
Note: | You do not need to set a beginrange (b) or endrange (e) when creating an always true rule. |
You can define more than one "always true" rule, and thereafter adjust which one gets executed by changing their priority levels.
This rule type is only available in the Dispatcher component.
You may want to use rules based on the content of the "type of service" (TOS) field in the IP header. For example, if a client request comes in with one TOS value that indicates normal service, it can be routed to one set of servers. If a different client request comes in with a different TOS value that indicates a higher priority of service, it can be routed to a different set of servers.
The TOS rule allows you to fully configure each bit in the TOS byte using the ndcontrol rule command. For significant bits that you want matched in the TOS byte, use 0 or 1. Otherwise, the value x is used. The following is an example for adding a TOS rule:
ndcontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
This rule type is only available in the CBR component.
You will want to use content type rules to send requests to sets of servers specifically set up to handle some subset of your site's traffic. For example, you may want to use one set of servers to handle all cgi-bin requests, another set to handle all streaming audio requests, and a third set to handle all other requests. You would add one rule with a pattern that matches the path to your cgi-bin directory, another that matches the file type of your streaming audio files, and a third always true rule to handle the rest of the traffic. You would then add the appropriate servers to each of the rules. For further information about configuring content type rules, see Chapter 7, Configuring the Content Based Routing component.
You can add rules using the ndcontrol or cbrcontrol rule add command, by editing the sample configuration file, or with the graphical user interface (GUI). You can add one or more rules to every port you have defined.
It is a two-step process: add the rule, then define which servers to serve to if the rule is true. For example, our system administrator wanted to track how much use the proxy servers were getting from each division on site. She knows which IP addresses are given to each division. She would create the first set of rules based on client IP address to separate each division's load:
ndcontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 ndcontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 ndcontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
Next, she would add a different server to each rule, then measure the load on each of the servers in order to bill the division properly to the services they are using. For example:
ndcontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 ndcontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 ndcontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
In general, the load-balancing functions of the Dispatcher work independently of the content of the sites on which the product is used. There is one area, however, where site content can be important, and where decisions made regarding content can have a significant impact upon the Dispatcher's efficiency. This is in the area of link addressing.
If your pages specify links that point to individual servers for your site, you are in effect forcing a client to go to a specific machine, thus by-passing any load balancing function that might otherwise be in effect. For this reason, it is recommended that you always use the address of Dispatcher in any links contained in your pages. Note that the kind of addressing used may not always be apparent, if your site uses automated programming that dynamically creates HTML. To maximize your load-balancing, you should be aware of any explicit addressing and avoid it where possible.
You can set up Dispatcher and the TCP server machines using a private network. This configuration can reduce the contention on the public or external network that can affect performance.
For AIX, this configuration can also take advantage of the fast speeds of the SP High Performance Switch if you are running Dispatcher and the TCP server machines on nodes in an SP Frame.
To create a private network, each machine must have at least two LAN cards, with one of the cards connected to the private network. You must also configure the second LAN card on a different subnet. The Dispatcher machine will then send the client requests to the TCP server machines through the private network.
Windows Only: Execute the following command:
ndconfig en1 10.0.0.x netmask 255.255.255.0
Where en1 is the name of the second interface card in the Dispatcher machine, 10.0.0.x is the network address of the second interface card, and 255.255.255.0 is the netmask of the private network.
The servers added using the ndcontrol server add command must be added using the private network addresses; for example, referring to the Apple server example in Figure 25, the command should be coded as:
ndcontrol server add cluster_address :80:10.0.0.1,
not
ndcontrol server add cluster_address :80:9.67.131.18
If you are using ISS to provide load information to Dispatcher, you must configure ISS to report loads on the private addresses.
Figure 25. Example of a private network using Dispatcher
Using a private network configuration only applies to the Dispatcher component.
The "wildcard" refers to the cluster's ability to match multiple IP addresses (i.e. acts as a wildcard). Cluster address 0.0.0.0 is used to specify a wildcard cluster.
If you have many cluster addresses to load-balance, and the port/server configurations are identical for all your clusters, you can combine all the clusters into one star configuration.
You must still explicitly configure each cluster address on one of the network adapters of your Dispatcher workstation. You should not add any of the cluster addresses to the Dispatcher configuration using the ndcontrol cluster add command however.
Add only the wildcard cluster (address 0.0.0.0), and configure the ports and servers as required for load balancing. Any traffic to any of the adapter configured addresses will be load balanced using the wildcard cluster configuration.
An advantage of this approach is that traffic to all the cluster addresses is taken into account when determining the best server to go to. If one cluster is getting a lot of traffic, and it has created many active connections on one of the servers, traffic to other cluster addresses will be load balanced using this information.
You can combine the wildcard cluster with actual clusters if you have some cluster addresses with unique port/server configurations, and some with common configurations. The unique configurations must each be assigned to an actual cluster address. All common configurations can be assigned to the wildcard cluster.
Using wildcard cluster to combine server configurations only applies to the Dispatcher component.
Using wildcard cluster to load balance firewalls only applies to the Dispatcher component. Cluster address 0.0.0.0 is used to specify a wildcard cluster.
The wildcard cluster can be used to load balance traffic to addresses that are not explicitly configured on any network adapter of the Dispatcher workstation. In order for this to work, the Dispatcher must at least be able to see all the traffic it is to load balance. The dispatcher workstation will not see traffic to addresses that have not been explicitly configured on one of its network adapters unless it is set up as the default route for some set of traffic.
Once Dispatcher has been configured as a default route, any TCP or UDP traffic through the Dispatcher machine will be load balanced using the wildcard cluster configuration.
One application of this is to load balance firewalls. Since firewalls can process packets for any destination address and any destination port, you need to be able to load balance traffic independent of the destination address and port.
Firewalls are used to handle traffic from non-secure clients to secure servers, and the responses from the secure servers, as well as traffic from clients on the secure side to servers on the non-secure side, and the responses.
You must set up two Dispatcher machines, one to load balance non-secure traffic to the non-secure firewall addresses and one to load balance secure traffic to the secure firewall addresses. Since both of these Dispatchers must use the wildcard cluster and wildcard port with different sets of server addresses, the two Dispatchers must be on two separate workstations.
Using wildcard cluster with WTE for transparent proxy only applies to the Dispatcher component. Cluster address 0.0.0.0 is used to specify a wildcard cluster.
The wildcard cluster function also allows Dispatcher to be used to enable a transparent proxy function for a Web Traffic Express (WTE) server residing on the same box as Dispatcher. This is an AIX feature only, as there must be communication from the dispatcher component to the TCP component of the operating system.
To enable this feature, you must start WTE listening for client requests on port 80. You then configure a wildcard cluster. In the wildcard cluster, you configure port 80. In port 80, you configure the NFA of the Dispatcher machine as the only server. Now any client traffic to any address on port 80 will be delivered to the WTE server running on the Dispatcher workstation. The client request will then be proxied as usual, and the response will be sent back from WTE to the client. In this mode, the Dispatcher component is not performing any load balancing.
The wildcard port can be used to handle traffic that is not for any explicitly configured port. One use of this is for load balancing firewalls. A second use is to ensure that traffic to an unconfigured port is handled appropriately. By defining a wildcard port with no servers, you will guarantee that any request to a port that has not been configured will be discarded rather than delivered back to the operating system. Port number 0 (zero) is used to specify a wildcard port, for example:
ndcontrol port add cluster:0
You enable the affinity feature when you configure a cluster's port to be sticky. Configuring a cluster's port to be sticky allows subsequent client requests to be directed to the same server. This is done by setting "port stickytime" to some number of seconds. The feature is disabled by setting stickytime to zero.
Interaction with cross port affinity: If you are enabling cross port affinity, stickytime values of the shared ports must be the same (nonzero) value. See Cross port affinity, for more information.
With the feature disabled, whenever a new TCP connection is received from a client, Dispatcher picks the right server at that moment in time and forwards the packets to it. If a subsequent connection comes in from the same client, Dispatcher treats it as an unrelated new connection, and again picks the right server at that moment in time.
With the feature enabled, if a subsequent request is received from the same client, the request is directed to the same server.
Over time, the client will finish sending transactions, and the affinity record will go away. Hence the meaning of the sticky "time. " Each affinity record lives for the "stickytime" in seconds. When subsequent connections are received within the stickytime, the affinity record is still valid and the request will go to the same server. If a subsequent connection is not received within stickytime, the record is purged; a connection that is received after that time will have a new server selected for it.
The Server Directed Affinity API only applies to the Dispatcher component.
The SDA feature provides an API that allows an external agent to influence the Dispatcher affinity behavior.
SDA Features
Your application may have indicated that their server systems have the knowledge to direct client requests to particular server machines better than Dispatcher can. Rather than having a client be "directed" to the same server as selected by Dispatcher's load balancing selection, you may want the client to be "directed" to the server of your choosing. The SDA feature provides this API. You can now write your own software to implement an SDA agent, which communicates with a listener in Dispatcher. It can then manipulate the Dispatcher affinity tables to:
Records inserted in an affinity table by an SDA agent remain in the table indefinitely. They do not timeout. They are removed only when the SDA agent removes them or if a Dispatcher advisor detects that the server is dead.
Dispatcher's SDA components
Dispatcher implements a new socket listener to accept and handle requests from an SDA agent. When an SDA agent opens a connection with Dispatcher, the listener will accept it and leave the connection open. Multiple requests and responses can flow over this persistent connection. The socket will close when the SDA agent closes it or if Dispatcher detects an unrecoverable error. Inside Dispatcher, the listener takes each request from the SDA agent, communicates with the appropriate affinity table in the Dispatcher executor kernel, and prepares a response for the SDA agent.
For more information, refer to the following files after the Dispatcher has been installed. The files appear in the Dispatcher's install directory tree.
The files are:
Cross port affinity only applies to the Dispatcher component.
Cross port affinity is the sticky feature that has been expanded to cover multiple ports. For example, if a client request is first received on one port and the next request is received on another port, cross port affinity allows the dispatcher to send the client request to the same server. In order to use this feature, the ports must:
More than one port can link to the same crossport. When subsequent connections come in from the same client on the same port or a shared port, the same server will be accessed. The following is an example of configuring multiple ports with a cross port affinity to port 10:
ndcontrol port set cluster:20 crossport 10 ndcontrol port set cluster:30 crossport 10 ndcontrol port set cluster:40 crossport 10
After cross port affinity has been established, you have the flexibility to modify the stickytime value for the port. However, it is recommended that you change the stickytime values for all shared ports to the same value, otherwise unexpected results may occur.
To remove the cross port affinity, set the crossport value back to its own port number. See ndcontrol port -- configure ports, for detailed information on command syntax for the crossport option.
Affinity address mask only applies to the Dispatcher component.
Affinity address mask is a sticky feature enhancement to group clients based upon common subnet addresses. Specifying stickymask on the ndcontrol port command allows you to mask the common high-order bits of the 32-bit IP address. If this feature is enabled, when a client request first makes a connection to the port, all subsequent requests from clients with the same subnet address (represented by that part of the address which is being masked) will be directed to the same server.
For example, if you want all incoming client requests with the same network Class A address to be directed to the same server, you set the stickymask value to 8 (bits) for the port. To group client requests with the same network Class B address, set the stickymask value to 16 (bits). To group client requests with the same network Class C address, set the stickymask value to 24 (bits).
For best results, set the stickymask value when first starting the Network Dispatcher. If you change the stickymask value dynamically, results will be unpredictable.
Interaction with cross port affinity: If you are enabling cross port affinity, stickymask values of the shared ports must be the same. See Cross port affinity, for more information.
To enable affinity address mask, issue an ndcontrol port command similar to the following:
ndcontrol port set cluster:port stickymask 8
Possible stickymask values are 8, 16, 24 and 32. A value of 8 specifies the first 8 high-order bits of the IP address (network Class A address) will be masked. A value of 16 specifies the first 16 high-order bits of the IP address (network Class B address) will be masked. A value of 24 specifies the first 24 high-order bits of the IP address (network Class C address) will be masked. If you specify a value of 32, you are masking the entire IP address which effectively disables the affinity address mask feature. The default value of stickymask is 32.
See ndcontrol port -- configure ports, for detailed information on command syntax for stickymask (affinity address mask feature).
With rule affinity override, you can override the stickiness of a port for a specific server. For example, you are using a rule to limit the amount of connections to each application server, and you have an overflow server with an always true rule that says "please try again later" for that application. The port has a stickytime value of 25 minutes, so you don't want the client to be sticky to that server. With rule affinity override, you can change the overflow server to override the affinity normally associated with that port. The next time the client requests the cluster, it is load balanced to the best available application server, not the overflow server.
See ndcontrol server -- configure servers, for detailed information on command syntax for the rule affinity override, using the server sticky option.
The cookie affinity feature applies only to CBR with WTE (for HTTP), which supports load balancing based on rules. It provides a new way to make clients "sticky" to a particular server. This function is enabled by setting the stickytime of a rule to a positive number, and setting the affinity to "cookie." This can be done when the rule is added, or using the rule set command. Seendcontrol rule -- configure rules, for detailed information on command syntax.
Once a rule has been enabled for cookie affinity, new client requests will be load-balanced using standard CBR algorithms, while succeeding requests from the same client will be sent to the initially chosen server. The chosen server is stored as a cookie in the response to the client. As long as the client's future requests contains the cookie, and each request arrives within the stickytime interval, the client will maintain affinity with the initial server.
Cookie affinity is used to ensure that a client continues to be load balanced to the same server for some period of time. This is accomplished by sending a cookie to be stored by the clients browser. The cookie contains the cluster:port:rule that was used to make the decision, the server that was load balanced to, and a timeout timestamp for when the affinity is no longer valid. Whenever a rule fires that has cookie affinity turned on, the cookies sent by the client are examined. If a cookie is found that contains the identifier for the cluster:port:rule that fired, then the server load balanced to, and the expires timestamp are extracted from the cookie. If the server is still in the set used by the rule, and its weight is greater than zero, and the expires timestamp is greater than now, then the server in the cookie is chosen to load balance to. If any of the preceding three conditions are not met, a server is chosen using the normal algorithm. Once a server has been chosen (using either of the two methods) a new cookie is constructed, with the five pieces of information. (IBMCBRcluster:port:rule=timestamp), the timestamp will be the time that affinity expires. The "cluster:port:rule, and the server_chosen" are encoded so that no information about the CBR configuration is revealed. An "expires" parameter is also inserted in the cookie. This parameter is in a format the browser can understand, and causes the cookie to become invalid two hours after the expires timestamp. This is so the client's cookie database isn't cluttered up.
This new cookie is then inserted in the headers that go back to the client, and if the client's browser is configured to accept cookies, it will send back subsequent requests.
To enable cookie affinity for a particular rule, use the "rule set" command:
rule set cluster:port:rule stickytime 60 rule set cluster:port:rule affinity cookie
Stickiness is set per rule. Two different rules can send the same client to two different servers. Within one rule the client will be sent to one server, for another rule the client could be sent to a different server. This is a requirement, and for CBR, the servers for rules will be different, so a server using a rule will probably not even exist in another rule. This is desirable because you can make your rule for handling cgi or servlet requests (for example) sticky. Your rule for normal http requests will use normal load balancing.
Making a rule sticky would normally be used for CGI or servlets that store client state on the server. The state is identified by a cookie ID (these are server cookies). Client state is only on the selected server, so the client needs the cookie from that server to maintain that state between requests.
Normal client IP affinity for CBR is set by rule. To enable normal affinity use:
rule set cluster:port:rule stickytime 300 rule set cluster:port:rule affinity clientip
The default for rule affinity is client IP, so if you have never set it to "cookie" you do not need to set it to "clientip."
The binary logging feature allows server information to be stored in binary files. These files can then be processed to analyze the server information that has been gathered over time.
The following information is stored in the binary log for each server defined in the configuration.
Some of this information is retrieved from the executor as part of the manager cycle. Therefore the manager must be running in order for the information to be logged to the binary logs.
Use ndcontrol log command set to configure binary logging.
The start option starts logging server information to binary logs in the logs directory. One log is created at the start of every hour with the date and time as the name of the file.
The stop option stops logging server information to the binary logs. The log service is stopped by default.
The set interval option controls how often information is written to the logs. The manager will send server information to the log server every manager interval. The information will be written to the logs only if the specified log interval seconds have elapsed since the last record was written to the log. By default, the log interval is set to 60 seconds. There is some interaction between the settings of the manger interval and the log interval. Since the log server will be provided with information no faster than manager interval seconds setting the log interval less than the manager interval effectively sets it to the same as the manager interval. This logging technique allows you to capture server information at any granularity. You can capture all changes to server information that are seen by the manager for calculating server weights. However, this amount of information is probably not required to analyze server usage and trends. Logging server information every 60 seconds gives you snapshots of server information over time. Setting the log interval very low can generate huge amounts of data.
The set retention option controls how long log files are kept. Log files older than the retention hours specified will be deleted by the log server. This will only occur if the log server is being called by the manager, so stopping the manager will cause old log files not to be deleted.
The status option returns the current settings of the log service. These settings are whether the service is started, what the interval is, and what the retention hours are.
A sample Java program and command file have been provided in the nd/dispatcher/samples/BinaryLog and nd/cbr/samples/BinaryLog directories. This sample shows how to retrieve all the information from the log files and print it to the screen. It can be customized to do any type of analysis you want with the data. An example using the supplied script and program for the dispatcher would be:
ndlogreport 1999/05/01 8:00 1999/05/01 17:00
to get a report of Dispatcher server information from 8:00 AM to 5:00 PM on May 1, 1999.
This chapter describes what the network planner should consider before installing and configuring the Interactive Session Support (ISS) component. This chapter includes the following sections:
The ISS component is not available for the Red Hat Linux platform. It is replaced by another system monitor - Server Monitor Agent (SMA). For information on using SMA for Red Hat Linux, see Server Monitor Agent (SMA).
Note: | Additional disk space will be needed for logs. |
Note: | Additional disk space will be needed for logs. |
Interactive Session Support can run on Windows 2000 or NT, Professional/Workstation or Server
Note: | Additional disk space will be needed for logs. |
Note: | If Network Dispatcher is unable to locate the JRE that is installed, then
define an environment variable IBMND_JRE_LOCATION which should be set to the
fully qualified path to the javai.dll file. An example of the
syntax could be:
IBMND_JRE_LOCATION="c:\Program Files\ibm\JRE\1.1.8\bin\javai.dll" |
ISS creates an environment in which to function. In this environment, a controlling node:
This environment is defined in a configuration file, which you will need to write or modify. For more information, see Chapter 10, Configuring the Interactive Session Support component. The implementation of this environment will determine how effectively requests are load balanced. This section discusses the following planning considerations for the ISS component:
Figure 26. Example of the ISS component
Each host or machine in your site that will participate in ISS is considered a node. Any IP address or DNS name associated with a node that will be used must also be defined using the node parameters: InternalNet or Interface.
A cell is a group of nodes administered as a single logical unit. One of the nodes is elected the leader, or monitor, in accordance with its priority level within the cell. All other nodes are then considered to be agents. The nodes in a cell must be close enough together, geographically and on the network that the monitor can quickly and reliably communicate with each of them. In general, you will have one cell for each geographical site on your network. There should be a cell name to identify each cell created.
If you plan to use ping triangulation (see Ping Triangulation Considerations) between global sites, you will need to set up multiple cells, one at each site. Each site configuration must contain the local and global cell information.
The load on a node can be determined by measuring various resources such as a CPU usage, disk availability, or process count. Since the same type of resource may be used for several services/applications, we define resources by the ResourceType parameter. A ResourceType is further defined using the Metric, MetricNormalization, MetricLimits, and Policy keywords.
In general, a group of servers that are measured by the same ResourceTypes are defined as a service. A node or interface can be a member of a single service or many services. If you are familiar with the earlier versions of ISS, you can think of a service as similar to a Pool, which was defined as a group of machines performing the same function. Service parameters include NodeList and ResourceList, which tell the service which node(s) and resource(s) to use respectively.
When you set up an individual service for an ISS cell, all the nodes in that service should be equivalent. It is recommended that you create a common data space and common name space. This means that regardless of the server a user is connected to, the user will be able to log in using a consistent user name and password, and will be able to access the appropriate data. You can accomplish this by using a distributed file system such as AFS, DFS, or NFS, or by using a shared disk architecture.
After configuring nodes, services, resourcetypes, and their parameters, you should configure observers. This will determine the implementation of ISS. The concept of the observer is described below.
The observer type that is defined in the configuration specifies the mode of implementation of ISS. An observer is a load balancer or any other network process that uses information about the status of nodes in the cell. ISS supports three types of observers (implementation mode) that can subscribe to reports on a cell and/or perform load balancing for that cell.
Three implementation modes of ISS are:
An observer (implementation mode) is configured using one of three keywords:
This corresponds to DNS-Update mode. If you have a small local DNS area, then you could potentially use ISS in "DNS-update" mode, in which it will update the main site DNS nameserver. These updates are frequent (possibly as often as every heartbeat) so this configuration is only recommended in a DNS environment that wholly or mainly dedicated to the ISS servers. ISS works in conjunction with the nameserver to map DNS names of ISS services to IP addresses of the servers considered to be the "best" candidate. ISS assists the nameserver by:
This corresponds to DNS-Replace mode. ISS functions as a nameserver (it performs nameserver functions) for a limited subset of the network, but does not contain all the functions of a standard DNS. You need to be able to configure a separate subnet for ISS to use with DNS-replace. Entries should be added to the primary site DNS nameserver to redirect requests for services balanced by ISS to the ISS nameservers. ISS then works transparently as part of the normal DNS protocols.
This corresponds to DNS-Ignore mode. ISS works in conjunction with the Dispatcher to perform the load-balancing function. ISS does not make any load balancing decisions itself. The ISS monitor collects server load information from the ISS agents running on the individual servers and forwards it to the Dispatcher. The Dispatcher uses this load information, along with other sources of information, to perform load balancing.
Each observer must have a servicelist specified, which defines to which service the observer subscribes. Every cycle the services are updated and provide the updated results to the subscribed observers. With these updated results, the observer either:
See Chapter 10, Configuring the Interactive Session Support component for detailed configuration information.
In an advanced configuration, such as a two-tier configuration,DNS-Ignore mode can be implemented with DNS-Update mode or DNS-Replace mode in. For more information, see Load Balancing Dispatcher with ISS.
Another important factor in ISS load balancing is the SelectionMethod keyword. Each service maintains a ranking of the best nodes to perform the configured service. You can change the calculation that determines the best node by using the different selection methods. The SelectionMethod keyword must be one of the following values:
Round-robin selection performs no load balancing. Load figures are ignored, although a server will not be recommended if it appears to be down.
For each update period the monitor calculates the highest-ranking server to use during that period. The ranking is re-calculated once every update period. This is the default.
For each update period the monitor calculates the load on each server and assigns a proportion of tokens to that server. Each incoming request is assigned a token. If the number of tokens runs out before the next update, then the token levels are reset based on the last available figures.
For both the Best and Statistical Round-Robin selection methods, you can use two types of metric: Internal and External.
Each service may have a different selection method without affecting any other services. A node may belong to more than one service and each of those services may have different selection methods without affecting any other. Refer to Table 9 to determine which configuration method best suits your needs.
Note: | For all selection methods, ISS detects if a server fails and does not schedule requests for that server. |
Table 9. ISS configuration methods
Select this method: | If these circumstances apply: |
---|---|
Round-Robin |
You do not want to measure the actual loads on the servers in the cell, and simply cycling through them will provide a good distribution of load for the types of activity that will be performed on the servers. For more information, see Round-robin configuration.
|
Best | You want to direct requests to the server with the least load.
For more information, see Best Configuration. |
Statistical Round-Robin |
You receive extremely frequent requests and you want to balance them in a ratio that is proportional to the server loads For more information, see Statistical Round-robin configuration.
|
With a round-robin configuration, ISS balances the load across a group of servers by assigning requests to the servers in a round-robin fashion. ISS selects each server for a specific length of time, which you specify using the HeartbeatInterval and HeartBeatsPerUpdate keywords. During this time interval, it will recommend that server. It will not recommend a server that has been identified as having failed. This method ignores the load on each of the servers.
There are advantages and disadvantages to using the round-robin method. The main advantage is that using round-robin avoids the overhead (on the servers) associated with other measurement types. The main disadvantage of round-robin measurement is that ISS does not notice if a particular server is getting very busy. For example, ISS could continue to use a busy server as the server to which new users connect. Round-robin scheduling works well provided the client load has reasonably uniform access frequency and duration.
Using the "Best" selection method, ISS routes requests during a specific heartbeat interval to the server with the lowest load at the start of that interval. It will not recommend a server that has been identified as having failed. This selection method works well for any duration of the connections, provided the frequency of new connections is low relative to the heartbeat interval.
ISS gathers load statistics for all the servers and uses them to build up a profile of the most and least heavily loaded servers. Requests within a heartbeat interval are shared between the servers in proportion to their loading. This selection method works well where there is a high frequency of short-lived connections.
It is not appropriate to define any metrics for use with the RoundRobin selection method, unless you are using ISS in a two-tier scenario and the loading information is required to be passed on to Dispatcher.
For both Best and Statistical Round-Robin, you must have a metric specified.
To define a ResourceType, ISS provides two methods for collecting load
information: internal and external metrics. Internal metrics are
supplied by ISS, whereas external metrics are calculated by executing a
defined command string on the server that returns a single number result to
ISS.
Select this Metric: | If these circumstances apply: |
Internal | ISS supplies a few pre-defined metrics that can be used to measure the load on a server. |
External | You may define any command string as a metric to measure server load. This metric should return a single number as the result. |
There are two Internal metrics that ISS supplies: CPULoad and FreeMem. CPULoad measures the percentage of the CPU that is being utilized. CPULoad requires the Policy to be Min. FreeMem measures the amount of free physical memory as a percentage. FreeMem requires the Policy to be Max. See "External Metrics" below for an explanation of the Policy keyword. Both of these metrics can reasonably be expected to return a value between 0 and 100. This should be defined with the MetricNormalization keyword.
Note: | FreeMem is not available on the Solaris version of ISS. |
With an external metric, you can use any load measurement method that you choose. To create an external metric, you can either write a command string directly into the configuration files or store a command or series of commands in an executable file. Typical files would be a shell script on Unix, or a batch file on Windows. The command or series of commands must return a single numeric result. If you are using multiple operating systems there must be an equivalent command for all the environments used.
For example, you would write the executable filename (including path) in the configuration file as follows:
ResourceType UnixScript Metric External "\etc\script1" or ResourceType NTScript Metric External "C:\nd\yourBin\yourScript.bat"
The Policy parameter in the ISS configuration file determines how the result is interpreted. When you want higher numbers to represent lower loading, set the Policy to Max, which indicates that a higher value returned is desirable.
When you want lower numbers to represent lower loading, set the Policy to Min, which indicates that a lower value is desirable. The default value is Min. See the description of the Policy keyword in Configuration file keywords for ISS for more details.
The following example illustrates an external metric that counts the number of processes running on a system. Standard UNIX commands are used to create this metric:
ps -ef | wc -l
If there were 50 processes running on your system, this external metric would generate a numeric value of 50. The complete coding in the configuration would be something like:
ResourceType CPUprocess Metric External ps -ef | wc -1 MetricNormalization 0 100 MetricLimits 90 95 Policy Min
See How a configuration file is created for details on MetricLimit.
Another popular external metric measures the percentage of idle CPU (the inverse of CPULoad). Standard UNIX commands are used to create this metric:
vmstat 3 2 | tauk -1 awk '{print $16}'
Note: | This example is for AIX. On Solaris, use: vmstat 3 2 | tail --1 awk '{print $22}'. |
This returns the percentage of idle CPU time during a 3 second sampling period. This value should be maximized when you want to identify the least loaded server. If the CPU is 85% idle, this external metric would generate a numeric value of 85. The complete coding in the configuration would be something like:
ResourceType IdleCPU Metric External vmstat 3 2 | tail -1 | awk '{print $16}' MetricNormalization 0 100 MetricLimits 60 20 Policy Max
Windows Note: Windows does not provide the same commands as UNIX for creating custom metrics. However, tools providing similar results can be obtained from sources on the Internet. Windows users can also use the custom configuration option by writing their own programs, as long as those programs write only a number to standard output.
Multiple ResourceTypes, hence the associated metric, can be listed in the ResourceList of a service. The results returned by the metrics are combined using the metric weight. This allows multiple factors to be considered in the load balancing decision.
Imagine three machines, alien, snowy, and sunny: each has several network adapters and multiple IP addresses. Some IP addresses are aliases on a single network adapter, and some are unique to a particular adapter. For simplicity, assume that each machine has only one DNS name, mapping to one of its IP addresses.
Figure 27. A diagram of an ISS interface
Summary of the network configuration:
alien.foo.com 10.1.1.1 A 10.1.1.2 B 10.1.1.3 F snowy.foo.com 10.1.1.4 C 10.1.1.5 D 10.1.1.6 G sunny.foo.com 10.1.1.7 E 10.1.1.8 H
Using the three nodes, we can supply several different services, and we may wish to recommend different IP addresses externally depending on which service we are advertising.
For example:
We also want to be able to use the extra adapters on each machine for internal communications between the machines (for instances, for ISS to send internal packets on) and so we have:
Using ISS with the above scenario, you will need the following lines in your config file:
# ISS Config file for Cell ISSCell Cell ISSCell Local # Nodes Node alien.foo.com 1 InternalNet 10.1.1.3 Interface 10.1.1.2 Node snowy.foo.com 2 InternalNet 10.1.1.6 Interface 10.1.1.5 Node sunny.foo.com 3 Interface 10.1.1.8 # Information about metrics would be included here Service HTTPService www.foo.com NodeList alien 10.1.1.4 sunny Service FTPService ftp.foo.com NodeList 10.1.1.2 10.1.1.5 10.1.1.7
Note: | ISS will be able to perform normal DNS resolution to map the hostname [e.g. alien.foo.com] to one of the IP address [e.g. 10.1.1.1]. You only need to specify an interface if you wish the same machine to use multiple IP addresses. |
The InternalNet address will be used by ISS for its internal communications transparently: you do not need to configure anything else to make this work.
When defining an interface, (using the Interface keyword, ISSControl add Interface, or the GUI), you may identify either the IP address, or the hostname. If you supply the hostname, then ISS will look up the IP address which matches it. If you supply the IP address, then there will be no further resolution.
As shown in Figure 28, IBM Network Dispatcher supports the concept of a two-tiered architecture. For a complete sample configuration, see A Two Tier Sample configuration file for ISS. Using this configuration, two components of IBM Network Dispatcher are used together to maximize load balancing for your server network. This approach is especially useful if you need to provide load balancing for servers that are located in different geographical areas. ISS is supplied with information from each of the local Dispatchers and uses an intelligent round-robin or user-specified metric to determine which Dispatcher IP address is returned to the client. The combination of the ISS and Dispatcher functions maximizes the potential load for your worldwide network.
Figure 28. Example of a two-tiered configuration using IBM Network Dispatcher
In this example:
Optionally, the ISS agent can run on the servers to provide system load information to the Dispatchers.
Configuring ISS to work with highly available Dispatchers should be similar to the sample shown in A Two Tier Sample configuration file for ISS with just the following modifications:
There are some restrictions in getting this configuration to work.
For example, the ISS configuration file would initially contain the following node and service definitions:
Node ISSMonitor 01 Node dispatcherA 02 Node dispatcherB 03 Service Top_Tier www.PickActiveDispatcher.com ResourceList checkND SelectionMethod BEST NodeList
The Dispatcher's goActive script would also contain the following isscontrol commands (example for Node dispatcherA):
/usr/bin/isscontrol delete interface clusterAddr from node dispatcherB /usr/bin/isscontrol add interface clusterAddr to node dispatcherA /usr/bin/isscontrol add interface clusterAddr to service Top_Tier
Since dispatcherB doesn't have an interface in the initial configuration file, an error message will be written to the ISS log, but ISS will continue to run. Once the active Dispatcher starts, these commands will be issued. The configuration file should contain the following:
Node ISSMonitor 01 Node dispatcherA 02 Interface clusterAddr Node dispatcherB 03 Service Top_Tier www.PickActiveDispatcher.com ResourceList checkND SelectionMethod BEST NodeList clusterAddr
In order for ISS to recommend only the active Dispatcher and not the standby, a Dispatcher resource is needed to "fail" the standby Dispatcher. This resource should call an external metric that determines the state of the Dispatcher. If it is active, a "good" value is returned. If it is standby, a "failed" value is returned. For the previous example, the resource could be defined as follows:
ResourceType checkND Metric external /usr/lpp/nd/dispatcher/NdState MetricNormalization 0 10 MetricLimits 5 8 Policy Min
One implementation of the NdState script would search the machine's list of interfaces using the netstat -ni command (for Unix based platforms) or using the ipconfig command (for Windows). A return value of 1 results if clusterAddr is aliased on a NIC (tr0 or en0). A return value of 9 results if clusterAddr is aliased on the loopback adapter. Due to the MetricLimits configured, ISS would fail the node which returned a value of 9 and recommend only the node that returned a value of 1.
Note: | Undesirable results will occur if the cluster address is defined with multiple Interface keywords or if defined multiple times in the Service's NodeList. The order in which ISS and Dispatcher are started is very important. All ISS nodes will only be updated with the configuration file changes once initialization has completed. |
Since ISS is started without any nodes in the Service's (Top_Tier) NodeList, the metric is not running. To ensure that the metric is running, an additional Service is needed which includes the dispatchers' hostnames, like the following:
Service runMetrics placeholder ResourceList checkND SelectionMethod Best NodeList dispatcherA dispatcherB
None of the dispatcher observers should include this Service (runMetrics) in any of the ServiceList definitions.
Ping triangulation is a process by which client requests can be routed to the cell which is geographically closest. Ping triangulation technology uses a process of "echo location " performed on a remote Internet client, allowing you to perform load balancing across multiple synchronized sites. Upon receiving a request, ISS sends an Internet ICMP echo (ping) packet to that host, and times the echo response. It also asks the other sites to perform such a measurement, and inform it of their results.
From this information, the most appropriate site is determined, and future requests may be redirected. Note that ISS will not forward requests to another cell if the local cell is unable to supply the desired service. In ISS, ping triangulation is active only if you have one or more global cells defined and a PingCache defined of size 1kb or greater. Each local cell's configuration file must include the information about the other cells, their nodes, the services to be used, and the ISSNameServer that is being used. Between all the cells, exactly one ISSNameServer should be configured. The node information is used to maintain a connection with the remote cell. The service information is used to defined which services are enabled for ping triangulation. Enabling ping triangulation for a service will allow requests to be redirected according to which cell is located relatively close to the client's location. If the ISSNameServer used in the configuration is in the other cell, it also must be defined in the global cell's definition. An example global cell definition with the ISSNameServer could be:
Cell Hursley Global Node spnode1.hursley.ibm.com 01 Node spnode2.hursley.ibm.com 02 Node spnode3.hursley.ibm.com 03 NotMonitor Service WWWService www.ourservice.com SelectionMethod Best NodeList spnode2.hursley.ibm.com spnode3.hursley.ibm.com ISSNameserver spnode1.hursley.ibm.com 53
Note: | In order for an ISSNameServer to function in a ping triangulation configuration, the ISSNameServer must be located on the monitor. This allows the ISSNameServer to reference the PingCache on that machine. |
To configure ping triangulation, you define, in the configuration of each cell, each of the other cells. For example, if you have two cells in the configuration for cell 1, you define cell 1 as a local cell and cell 2 as a global cell. Similarly, cell 2 defines itself as local and cell 1 as global. For a complete sample configuration, see Ping Triangulation Sample configuration file for ISS.
Note: | Maintenance and synchronization of the configuration files between cells must be handled manually by the ISS administrator(s). ISSControl and GUI updates will only be sent to the local cell members. |
StickyTime allows an ISSNameServer to control the client-server affinity.
Note: | The ISSNameServer affinity is not based on or an application of the TTL (Time To Live) function configured in a name server. This affinity feature creates its own affinity records and functions independently of any TTL settings. |
When this affinity feature is disabled, the ISSNameServer chooses the right server according to the configuration and provides that server address to the requesting client. The subsequent request from that client will be received as a new connection and the right server address at that moment will be supplied to the client.
When this feature is enabled, the ISSNameServer chooses the right server according to the configuration and provides that server address to the requesting client. An entry is made in the ISS affinity table for that client IP. When the same client makes subsequent requests, the ISSNameServer queries the ISS affinity table for that client IP entry. If the entry has not expired according to the StickyTime configured, then the same address that was previously returned to the client is sent again.
Garbage collection is run to clean out all the timed-out affinity table entries. The frequency of garbage collection is configured by the approximate number of requests that must be made before it should occur. A small garbage collection interval will cause it to occur more frequently.
Note: | For this feature to work properly, the ISSNameServer must be located on the active ISS monitor. This allows the ISSNameServer to access the ISS affinity table. |
To configure StickyTime and StickyGarbageCollectionInterval, use the isscontrol command line to set the values. To enable the affinity feature, configure an ISSNameServer by setting a StickyTime that is greater than zero. The feature is disabled by setting StickyTime to zero (the default). For more information on these isscontrol keywords, see isscontrol -- control iss.
This chapter explains how to configure the ISS component of IBM Network Dispatcher. Before following the steps in this chapter, see Chapter 9, Planning for the Interactive Session Support component.
Table 11. Configuration tasks for the ISS function
Task | Description | Related information |
---|---|---|
Define each cell. | A cell requires a name and various attributes. | Defining a Cell |
For each cell, define the nodes in the cell. | Nodes are the machines in the cell, identified by id number and IP address or DNS name. | Defining a Node |
For each cell, specify one or more resource types. | A resource type is a type of object on which a metric measures load. For example, CPU. | Defining a Resource |
For each cell, specify one or more services. | A service corresponds to a group of servers measured by the same resource(s). Each service is identified by an id and a DNS name. | Defining a Service |
For each cell, specify the observers that will subscribe to services in that cell. | An observer may be:
| Defining an Observer |
You will need to create an ISS configuration file to define your configuration. A minimal configuration default file iss.cfg has been provided, or you can use an example file. To create the configuration file, see Modify iss.cfg file or an example file.
There are two basic methods of configuring the ISS component:
Edit the default configuration file iss.cfg provided, or modify an example configuration file. Examples of configuration files are in Dispatcher Sample configuration file for ISS and in the <nd_installation_path>/iss/samples directory.
Prior to issuing ISS commands, you must modify an ISS configuration file and then start the ISS daemon. Edit the default configuration file iss.cfg . Or, for a sample configuration, see Dispatcher Sample configuration file for ISS. To start the ISS daemon, enter iss followed by the appropriate parameters. Parameters for the iss command are listed in start iss.
Note: | For Windows -- When issuing the iss command from the command prompt to start the ISS daemon, the -i (interactive) option must always be included. |
Use isscontrol commands once the ISS daemon has been started with a configuration file containing the CELL keyword and a list of nodes. The isscontrol command line can be used to configure the ISS function. These commands allow you to modify a configuration file that defines the resources, services, and observers for a give cell. For more information, see Appendix C, Command reference for ISS for isscontrol commands.
For an example of the GUI, see Figure 2.
Prior to starting the GUI, you must modify an ISS configuration file and then start the ISS daemon.
Modify an ISS configuration file: You can edit the minimimal configuration default file iss.cfg, or you can edit a sample configuration file found in the <nd_installation_path>/iss/samples directory.
Start the ISS daemon: For AIX, Solaris, and Windows, enter iss followed by the appropriate parameters. Parameters for the iss command are listed in start iss. The -g option is required for the administration of the GUI.
Note: | For Windows -- When issuing the iss command from the command prompt to start the ISS daemon, the -i (interactive) option must always be included. |
Alternatively for Windows, you can start the ISS daemon using the following steps:
In the Startup Parameters window, if you want to code a backslash (\), you must specify a double backslash (\\). For example, if the full path name of your configuration file is d:\ibmiss\iss_config.cfg, then you would type: d:\\ibmiss\\iss_config.cfg.
Note: | The -c option for the iss command will enable
you to use a file other than the default iss.cfg
configuration file. The default paths are:
|
In order to configure the ISS component from the GUI, you must first select Interactive Session Support in the tree structure. This component does not appear on the Red Hat Linux platform. For Red Hat Linux, ISS is replaced by Server Monitor Agent (SMA). (For information on SMA, see Server Monitor Agent (SMA).
The GUI can be used to do anything that you would do with the isscontrol command. For example, to define a cell using the command line, you would enter isscontrol add cell <name> command. To define a cell from the GUI, you would click button number two of the mouse on Host, then in the pop-up menu, click on add cell. Enter the cell name in the pop-up window, then click OK.
The File menu located at the top of the GUI will allow you to save your current host connections to a file or restore connections in existing files across all Network Dispatcher components.
You can access Help by clicking the question mark icon in the upper right hand corner of the Network Dispatcher window.
For more information about using the GUI, see General Instructions for using the GUI.
ISS uses a configuration file to define the cells, resources, services, and observers. A minimal configuration file iss.cfg has been provided. The name of any configuration file can be supplied as a command line argument when ISS is run. Sample configuration files are also provided with ISS. See Sample ISS configuration files.
The ISS configuration file is an ASCII file consisting of a series of definitions. Each definition must be at the start of a line, and must start with a keyword that may be followed by further keywords and then a value. Blank lines are ignored and lines that begin with semicolons (;) or hash-symbols (#) are treated as comments. All keywords are case-insensitive. The case of parameters is preserved, since they may contain custom metrics or host names. Each keyword definition in the configuration file refers to a particular object being configured: a cell, node, service, resourcetype, or observer. Any entry for a particular type of object refers to the most recent instance of that type in the file. For example, a definition for the keyword Portnumber--which always refers to a given Cell--may appear anywhere in the configuration file. It always refers to the most recently defined cell.
A copy of a sample file can be found in Dispatcher Sample configuration file for ISS. It resides in the <nd_installation_path>/iss/samples directory. You can edit it to specify your configuration. With this basic configuration, items in the isscontrol commands or the ISS GUI can be used to add/set/delete the configuration. You may have a variety of configuration files for different workloads and other requirements.
The keywords that relate to a specific cell can occur in any order within the cell definition. A complete list of keywords can be found in Configuration file keywords for ISS.
If you plan to use the ISS GUI to develop your configuration, you need a basic configuration file containing the Cell keyword and at least the Node keyword and their respective definitions.
You may or may not need to create a wholly new configuration. The steps to do so are included below to help you understand how the configuration file works.
Adding and deleting sub cell entities for Global cells is limited to the following:
All other changes to a global cell must be made locally, where that cell is the local cell.A local cell is the cell that the node will be a member of. There must be one and only one local cell defined in the configuration file.
Example:
Cell Hursley Local
Optionally, the following cell attributes may be specified. If you
prefer to change the default values, see the table below.
Attribute | Default value |
PortNumber | 7139 |
LogLevel | INFO |
LogSize | unlimited |
HeartbeatInterval | 10 |
HeartbeatsPerUpdate | 2 |
HeartbeatsToNetFail | 4 |
HeartbeatsToNodeFail | 6 |
PingCache | 0 |
AuthKey | 0 |
Specify each of the nodes (host machines) in the cell, using the keyword Node, the id number and the IP address or DNS name.
Node Monitor1.hursley.ibm.com 01
Note: | The id number is used in two ways: |
Optionally, the following node attribute may be specified:
For more information about these keywords, see Configuration file keywords for ISS.
Specify each resource for the cell with the keyword ResourceType and a name to identify the resource.
ResourceType CPU
For each ResourceType define the following attributes:
This specifies how to measure load for this resource, either with an internal or external metric. See ISS Metrics for more details.
This specifies how the Metric will be interrupted by ISS. When you want higher numbers to represent higher loading, set the Policy to Max, which indicates that a higher value returned is desirable. When you want lower numbers to represent lower loading, set the Policy to Min, which indicates that a lower value returned is desirable. The default value is Min.
This is a range between the lower and upper limits of measurement, indicated as whole numbers. The units referred to depend upon the metric you are using. For example, if you were measuring CPU usage, the units would be percentage points. The range would therefore be 0 to 100. Any metrics coming into the monitor outside this range would be corrected by being clipped to fit within these limits.
You can set these limits to prevent a server from failing totally by having too many requests assigned to it. ISS measures the loads on servers periodically. If the loads are within predefined limits, it judges them okay and continues on. If the loads are outside the limits, ISS removes the server from the ranking for that service. (If the server is handling more than one service, it may still be included in the ranking for the other service or services.) There are two levels defined here:
This specifies the priority of the metric and the default is 1. See Configuration file keywords for ISS for more details.
For example, the following coding specifies a metric for finding the CPU load.
Metric Internal CPULoad Policy Min MetricNormalization 0 100 MetricLimits 90 95 MetricWeight 1.0 ResourceType CPU
Specify each service in the cell by the keyword Service, a name to identify the service (such as Service WWWService www.issdev.hursely.ibm.com 129.40.161.74 21), and a DNS name to which the client will make requests and to which ISS will respond. Services are dependent on a resource(s) and the node(s) that have the resource(s). The following service attributes must be defined for the service to be useful:
specifies the ResourceType name(s) from which this service will collect information.
specifies the node(s) on which the resource(s) are available.
specifies which method ISS should use to determine which node to recommend. For more information, see Selection methods.
Optionally, two more attributes can be defined on the Service keyword line. Those are the Dispatcher cluster address and the Dispatcher port. These two attributes must be defined when a Dispatcher Observer is configured. Although these attributes may identify a specific cluster and port, ISS does not report cluster or port specific information to the Dispatcher. A Dispatcher's ServiceList should only have one service for each set of servers. If there are two or more services for the same set of servers, the Dispatcher will only use the loads from the last service ISS reports on.
the address on which Dispatcher is expecting client requests.
a port defined in the dispatcher configuration for this cluster address.
Service myServiceName placeholder dispatch.ral.ibm.com 80
Note: | The DNSname attribute of the Service keyword is not used in this scenario; however, the configuration file must have a placeholder string such as "placeholder." |
Other optional service attributes are:
a node to default to if all the other nodes in the NodeList are not available.
a command, which will vary according to the operating system, to execute if the Overflow node is resorted to.
Specify each observer in the cell by one of the following keywords:
followed by the DNS name for this node and the port number on which the DNS protocol communicates, usually port 53.
For each of the observers specified, the observer attribute, ServiceList, must specify to which services the observer subscribes. When a NameServer observer is defined, the NamedData and NamedRev keywords must be specified. For more information, see Configuration file keywords for ISS.
If you are modifying an older configuration file (from Version 1.1 or earlier), below are some important points to keep in mind:
The configuration file must be protected from alteration under any circumstances. If authentication keys are used, it must also be protected from reading by anyone other than the administrator. It should therefore be kept in a secure area of the node's file system to prevent unauthorized access.
If you are migrating from v1.2 or later, your old configuration file should be fully compatible. There are some new keywords which you may decide to make use of, see Configuration file keywords for ISS.
Use the questions in Table 13 to help you set up the TCP/IP name server used by
ISS.
Table 13. Guidelines for setting up the name server used by ISS
| |||
Question | Related Information | ||
---|---|---|---|
Do you want to add your ISS service names to an existing domain name server? |
If no, go to the next question. If yes, you can either:
If you do not want to set up a new subdomain, simply add the ISS service names to your name server data file. For instructions on setting up a new subdomain, go to Setting up a subdomain for your ISS service DNS names.
| ||
How do you want to set up your ISS name server? | You can set up the ISS name server in either of the following ways:
| ||
Do you want to set up a backup for your ISS DNS name server? | If yes, go to Do I need an ISS backup?. |
The DNS name server files presented in this section are designed to work in conjunction with the following ISS configuration file:
Cell RTP_site local # ... # ... Node issmon1.site.corp.com 01 Node server1.site.corp.com 10 Node server2.site.corp.com 11 Node server3.site.corp.com 12 # ResourceType CPULoad_1 Metric Internal CPULoad Policy Min # Service service1 pool1.rtp.site.corp.com NodeList server1.site.corp.com server2.site.corp.com server3.site.corp.com ResourceList CPULoad_1 SelectionMethod Best # NameServer issmon1.site.corp.com ServiceList service1 NamedData /etc/named.data NamedRev /etc/named.rev
The service service1 has the DNS name pool1.rtp.site.corp.com associated with it. Also associated with service1 are the nodes server1, server2, and server3. Since the type of observer is NameServer, ISS will work in conjunction with the DNS name server running on node issmon1 to resolve the DNS name pool1.rtp.site.corp.com to the IP address of either server1, server2, or server3. Note that the name of the DNS NameServer must be listed in the named.data file (see Editing the Data File).
Since the SelectionMethod is Best, ISS will attempt to map pool1 to the "best" of the three servers using the ISS internal metric CPULoad. The DNS name server running on the node issmon1 has authority over the subdomain rtp.site.corp.com. Note that the server nodes associated with service1 are not designated as being part of the subdomain rtp.site.corp.com. This may seem to contradict a statement made earlier in Table 13 that the server nodes must be part of this subdomain. However, that requirement can be relaxed. It is not necessary to change the server machines in order for ISS to provide load balancing for those machines.
The three files that determine the behavior of the DNS name server are the boot file, the data file and the reverse data file. The following sections describe each file and include editing guidelines.
AIX and Solaris: The boot file is normally called named.boot. If you are starting named daemon from the command line, you can specify the name of this file as a command line parameter. If you do not supply the name, then the named daemon uses the /etc/named.boot file. As root, copy the ISS sample boot file to the appropriate directory and modify it to match your system configuration. Make sure to make a backup copy of your existing named.boot file before performing this operation.
On AIX or Solaris systems, the following lines must be in the boot file:
primary rtp.site.corp.com /etc/named.data primary in-addr.arpa /etc/named.rev
This file is normally called the named.data file and is identified in the boot file. You should copy the sample data file to the chosen directory (for example, /etc for AIX and Solaris) and modify it to match your system configuration.
For the ISS configuration in the example, the associated named.data file contains resource records similar to the following:
; ; The SOA (Start of Authority) record ; rtp.site.corp.com. IN SOA issmon1.site.corp.com. root.issmon1.site.corp.com. ( 1000 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 86400 ) ; Minimum ; ; The NS (Name Server) records ; rtp.site.corp.com. IN NS issmon1.site.corp.com. site.corp.com. IN NS siteserv.site.corp.com. ; ; The A (address) records ; loopback.site.corp.com. IN A 127.0.0.1 localhost.site.corp.com. IN A 127.0.0.1 pool1.rtp.site.corp.com. IN A 9.117.17.23 issmon1.site.corp.com. IN A 9.117.17.31 siteserv.site.corp.com. IN A 9.117.32.254 server1.site.corp.com. IN A 9.117.17.21 server2.site.corp.com. IN A 9.117.17.22 server3.site.corp.com. IN A 9.117.17.23
This file specifies that the DNS name server running on the node issmon1.site.corp.com is authoritative for the subdomain rtp.site.corp.com and contains mostly host name to IP address mappings (forward resolution). For completeness, the A records of server1, server2, and server3 are included here although this is really redundant. Any name that the DNS name server running on issmon1 cannot resolve and belongs to the parent domain site.corp.com is passed on to the DNS name server running on siteserv. ISS will periodically modify the IP address of the resource record pool1.rtp.site.corp.com. IN A 9.117.17.23 to that of the "best" of the three servers (server1, server2, and server3). After this modification, ISS asks the DNS name server running on issmon1 to re-read its configuration files. In this way, load balancing is achieved since the name pool1.rtp.site.corp.com is always mapped to the "best" server. Note that $INCLUDE statements in named.data file are not supported by ISS.
This file is normally called the named.rev file and is identified in the boot file. You should copy the sample reverse data file to the chosen directory (for example, /etc for AIX and Solaris) and modify it to match your system configuration.
For the ISS configuration in the example, the associated named.rev file contains resource records similar to the following:
; ; The SOA (Start of Authority) record ; @ IN SOA issmon1.site.corp.com. root.issmon1.site.corp.com. ( 1000 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 86400 ) ; Minimum ; ; Name Servers ; 17.117.9 IN NS issmon1.site.corp.com. 117.9 IN NS siteserv.site.corp.com. ; ; Pointer records. Reverse address mappings ; 1.0.0.127 IN PTR localhost.site.corp.com. 1.0.0.127 IN PTR loopback.site.corp.com. 23.17.117.9 IN PTR pool1.rtp.site.corp.com. 254.32.117.9 IN PTR siteserv.site.corp.com. 31.17.117.9 IN PTR issmon1.site.corp.com.
ISS will periodically modify the "reverse IP address" of the record 23.17.117.9 IN PTR pool1.rtp.site.corp.com to that of the "best" of the three servers (server1, server2, and server3). This is followed by a request to the DNS name server running on issmon1 to refresh itself with new configuration data.
Once you have finished editing the boot file, reverse data file, and data file, you can start the name server:
Example: /etc/named -b named.boot
Example: startsrc -s named -a "-b named.boot"
/usr/sbin/in.named -b /full_path_directory/named.boot_file
Example: /usr/sbin/in.named -b /opt/ibmiss/named.boot
To resolve an ISS DNS service name such as pool1.rtp.site.corp.com, it is normally not necessary to make changes to the client machines. The site DNS name server running on siteserv.site.corp.com can be configured to pass along resolution requests for the subdomain rtp.site.corp.com to the DNS name server running on issmon1.site.corp.com. However, if you want to modify the client machine so that the DNS name server running on issmon1 is the primary name server, it is possible to do so. In the following, we will call the name server running on issmon1 the ISS name server.
To configure the client machines:
When you are finished, ensure that the /etc/resolv.conf file has the name server entries in the following order:
To test the operation of the ISS name server, make a name resolution request from a client machine.
This returns the dotted-decimal Internet address for pool1 that is specified in the named.data file. Note that if the /etc/resolv.conf file of the client machine contains the statement
search rtp.site.corp.com site.corp.com corp.com
then ping pool1.rtp.site.corp.com can be abbreviated to ping pool1.
ISS handles high availability internally: all nodes (except those labelled "NotMonitor" "NotISSAgent") can take on a monitor role, and thus there will always be an ISS presence unless all of those nodes are unavailable. Therefore it is not necessary to configure an ISS backup. In DNS-replace mode, you may choose to configure more than one ISS NameServer in order to increase the DNS availability. In DNS-update mode, you may choose to list more than an NameServer to increase availability.
When configuration is completed, go to Using the Interactive Session Support component for instructions on how to start ISS.
This chapter explains how to use the components of IBM Network Dispatcher and includes the following sections:
This section explains how to use the Dispatcher component.
To start the Dispatcher component, you can either enter commands from the command line, use the GUI, or put the commands into a configuration file, for example mysample.cmd. For a description of the required commands, go to Setting up the Dispatcher machine.
Stop all functions of the Dispatcher by:
A client sends a FIN packet after it has sent all its packets so that the server will know that the transaction is finished. When Dispatcher receives the FIN packet, it marks the transaction from active state to FIN state. When a transaction is marked FIN, the memory reserved for the connection can be cleared by the garbage collector built into the executor.
You can use the FIN timeout and count to set how often the executor will perform garbage collection and how much it will perform. The executor periodically checks the list of connections it has allocated. When the number of connections in the FIN state is greater than or equal to the FIN count, the executor will attempt to free the memory used to hold this connection information. You can change the FIN count by entering the ndcontrol executor set fincount command.
The garbage collector frees the memory for any connection that is in the FIN state and is older than the number of seconds specified in the FIN timeout. You can change the FIN timeout by entering the ndcontrol executor set fintimeout command.
The FIN count also affects how often "stale" connections are removed. A connection is considered stale when there has been no activity on that connection for the number of seconds specified in the ndcontrol port set staletimeout command. If you have little memory on your Dispatcher machine, you should set the FIN count lower. If you have a busy Web site, you should set the FIN count higher.
Dispatcher posts entries to a server log, a manager log, a log for each advisor you use, and a subagent log. You can set the logging level to define the expansiveness of the messages written to the log. At level 0, only errors are logged. At level 1 (the default), Dispatcher also logs headers and records of events that happen only once (for example, a message about an advisor starting to be written to the manager log). Level 2 includes ongoing information, and so on, with level 5 including every message produced to aid in debugging a problem if necessary.
You can also set the maximum size of a log. When you set a maximum size for the log file, the file will wrap; when the file reaches the specified size, the subsequent entries will be written at the top of the file, overwriting the previous log entries. You cannot set the log size to a value that is smaller than the current one. Log entries are timestamped so you can tell the order in which they were written.
The higher you set the log level, the more carefully you should choose the log size. At level 0, it is probably safe to leave the log size to the default of unlimited. However, when logging at level 3 and above, you should limit the size without making it too small to be useful.
By default, the logs generated by the Dispatcher will be stored in the logs directory of the Dispatcher installation. This path can be changed by setting the nd_logdir variable in the ndserver script.
AIX, Red Hat Linux, and Solaris: The ndserver script is found in /usr/bin/ndserver. In this script, the variable nd_logdir is set to the default directory. You can modify this variable to specify your log directory. Example:
ND_LOGDIR=/path/to/my/logs/
Windows: The ndserver.cmd script is found in the Windows system directory, typically C:\WINNT\SYSTEM32. In ndserver.cmd, the variable nd_logdir is set to the default directory. You can modify this variable to specify your log directory. Example:
set ND_LOGDIR=c:\path\to\my\logs\
For all operating systems, make sure that there are no spaces on either side of the equal sign and that the path ends in a slash ("/" or "\" as appropriate).
The binary logging feature of Dispatcher uses the same log directory as the other log files. See Using binary logging to analyze server statistics.
Various charts can be displayed based on information seen by the executor and relayed to the manager:
Network Dispatcher provides an option to run its configuration programs on a machine other than the one running the Network Dispatcher servers.
Communication between the configuration programs (ndcontrol, cbrcontrol, isscontrol, ndwizard, ndadmin) is performed using Java Remote Method Invocation (RMI) calls. The command to connect to a Network Dispatcher machine for remote administration is ndcontrol host:remote_host. If the RMI call comes from a machine other than the local machine, a public key/private key authentication sequence must occur before the configuration command will be accepted.
Communication between the control programs running on the same machine as the component servers are not authenticated.
Use these commands to generate these public and private keys to be used for remote authentication:
These commands run only on the same machine as the Network Dispatcher.
The create option causes a public key to be created in the components key directory and a private key to be created in the components administration keys directory. The private key is created with the address of the server and the RMI port it is listening on as the file name. These private keys must then be transported to the remote clients and placed in the appropriate components administration keys directory.
For example if the ndserver process has been started on a machine with hostname address 10.0.0.25 and is listening on RMI port 10099, the ndkeys create command generates two files:
The public key /usr/lpp/nd/dispatcher/key/authorization.key The private key /usr/lpp/nd/admin/keys/dispatcher/10.0.0.25- 10099.key
The administration fileset has been installed on another machine. The 10.0.0.25-10099.key file must be placed in /usr/lpp/nd/admin/keys/dispatcher/ on the remote client machine.
The remote client will now be authorized to configure ndserver on 10.0.0.25.
This same key must be used on all remote clients that you want to authorize to configure ndserver on 10.0.0.25.
If you were to run the ndkeys create command again, a new set of public/private keys would be generated. This would mean that all remote clients who tried to connect using the previous keys would not be authorized. The new key would have to be placed in the correct directory on those clients you want to reauthorize.
The ndkeys delete command deletes the public and private keys on the server machine. If these keys are deleted, no remote clients will be authorized to connect to the servers.
Note: | For Red Hat Linux, SNMP is not supported on IBM Network Dispatcher. |
A network management system is a program that runs continuously and is used to monitor, reflect status of, and control a network. Simple Network Management Protocol (SNMP), a popular protocol for communicating with devices in a network, is the current network management standard. The network devices typically have an SNMP agent and one or more subagents. The SNMP agent talks to the network management station or responds to command line SNMP requests. The SNMP subagent retrieves and updates data and gives that data to the SNMP agent to communicate back to the requester.
Dispatcher provides an SNMP Management Information Base (ibmNetDispatcherMIB) and an SNMP subagent. This allows you to use any network management system, such as -- Tivoli NetView, Tivoli Distributed Monitoring, or HP OpenView -- to monitor the Dispatcher's health, throughput, and activity. The MIB data describes the Dispatcher being managed and reflects current Dispatcher status. The MIB will be installed in the /nd/admin/MIB/ subdirectory.
The network management system uses SNMP GET commands to look at MIB values on other machines. It then can notify you if specified threshold values are exceeded. You can then affect Dispatcher performance, by modifying configuration data for Dispatcher, to proactively tune or fix Dispatcher problems before they become Dispatcher or Web server outages.
The system usually provides an SNMP agent for each network management station. The user sends a GET command to the SNMP agent. In turn, this SNMP agent sends a GET command to retrieve the specified MIB variable values from a subagent responsible for those MIB variables.
Dispatcher provides a subagent that updates and retrieves MIB data. The subagent responds with the appropriate MIB data when the SNMP agent sends a GET command. The SNMP agent communicates the data to the network management station. The network management station can notify you if specified threshold values are exceeded.
The Dispatcher SNMP support includes an SNMP subagent that uses Distributed Protocol Interface (DPI) capability. DPI is an interface between an SNMP agent and its subagents.
Figure 29. SNMP commands for AIX and Solaris
AIX provides an SNMP agent that uses SNMP Multiplexer protocol (SMUX). You must also use an SNMP agent on Solaris that is SMUX-enabled. DPID2 is an additional executable that works as a translator between DPI and SMUX.
For Solaris, DPID2 is provided in the /opt/nd/dispatcher/samples/dpid2 directory.
The DPI agent must run as a root user. Before you execute the DPID2 daemon, update the /etc/snmpd.peers file and the /etc/snmpd.conf file as follows:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Refresh snmpd so that it will reread the /etc/snmpd.conf file:
refresh -s snmpd
Start the DPID SMUX peer:
dpid2
The daemons must be started in the following order:
Figure 30. SNMP commands for Windows
To get a DPI-capable SNMP agent for Windows, install the IBM SystemView Agent toolkit from http://www.support.tivoli.com/sva/shasdk.html.
Before you start the SystemView SNMPD process, you must disable the Microsoft Windows SNMP support. The SystemView snmpd supports DPI subagents and Microsoft-compliant agents.
To disable the Windows NT SNMP support:
To disable the Windows 2000 SNMP support:
Note: | If you do not disable the Microsoft Windows SNMP support, the Dispatcher SNMP subagent will not be able to connect to the snmpd agent. |
You can create community names (passwords). The default SNMP community name is public. In UNIX systems, this is set up in a file named /etc/snmpd.conf.
For Windows, before creating passwords for server communities, configure the SystemView SNMP agent.
This step allows any host in any network to access the SNMP MIB variables. After you have verified that these values work, you can change them according to your requirements.
Use the ndcontrol subagent start command to define the password used between the Dispatcher DPI subagent and the SNMP agent. The default is public. If you change this value, you must also add the new community name to the SystemView Agent snmpcfg.
SNMP communicates by sending and receiving traps, messages sent by managed devices to report exception conditions or the occurrence of significant events, such as a threshold having been reached.
The subagent uses two traps:
The indHighAvailStatus trap announces that the value of the high-availability status state variable (hasState) has changed. The possible values of hasState are:
The indSrvrGoneDown trap announces that the weight for the server specified by the csAddr, psNum, ssAddr portion of the Object Identifier has gone to zero. The last known number of active connections for the server is sent in the trap. This trap indicates that, as far as the Dispatcher can determine, the specified server has gone down.
Due to a limitation in the SMUX API, the enterprise identifier reported in traps from the ibmNetDispatcher subagent may be the enterprise identifier of dpid2, instead of the enterprise identifier of ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. However, the SNMP management utilities will be able to determine the source of the trap because the data will contain an object identifier from within the ibmNetDispatcher MIB.
The ndcontrol subagent start command turns the SNMP support on. The ndcontrol subagent stop command turns the SNMP support off.
For more information about the ndcontrol command, see ndcontrol subagent -- configure SNMP subagent.
This section explains how to use the Interactive Session Support (ISS) component and includes the following information:
ISS operates as either monitor or agent depending on the parameters entered. Use the iss command to start the ISS daemon.
The iss command can be used with the following parameters:
Use the specified file as the configuration file. Each node should have the same configuration file. The default paths are:
Enables the administration GUI either on default port 12099 or the <portnum> specified.
Displays a help message.
Run iss interactively.
Use the specified file as the log file instead of /etc/iss.log. If you are using a shared file system, each log file should be given a unique name. The default paths are:
Use the specified port number for control traffic.
AIX and Solaris: You can run iss in the foreground or the background. To start iss, as root, enter:
bin/iss
followed by any of the parameters listed above.
Notes:
tail -f <logfile>
Windows: iss runs as a Windows service. To start iss, as administrator:
For Windows 2000: Click Start->Programs->Administrative Tools->Services.
In the Startup Parameters window, if you want to code a backslash (\), you must specify a double backslash (\\). For example, if the full path name of your configuration file is d:ibmiss\iss_config.cfg, then you would type: d:\\ibmiss\\iss_config.cfg.
When started, ISS displays an opening message. If it does not find any errors in the ISS configuration file, it begins to load balance TCP/IP connections transparently across the cells defined in the configuration file. If there are problems with the cell definitions in the configuration file, a message is generated and ISS exits. If that occurs, modify the configuration file and try again. Refer to the sample configuration file for guidance.
ISS is designed to run unattended in normal operation, although sites under heavy load will inevitably need administrators to restart failed services and nodes. In normal operation, each node may be started and stopped independently. (See Controlling ISS.) When a node starts, it parses the configuration file and creates entries for each object it will interact with, including its peer nodes. From that list, it works out the preferred order of monitor machines from the node numbers and starts attempting to contact them all at once. The highest-priority node that responds will be chosen as the monitor. If a given higher-priority node does not respond within the timeout period, it is considered out of service and a node with a lower priority is chosen as the monitor.
The monitor has the power to change the configuration of each node and to start and stop it from sampling metrics. While agents are sending metric information to the monitor, they expect regular acknowledgments. If an acknowledgment is not received within the timeout period, the agents consider the monitor out of service and another monitor is selected.
To reconfigure ISS while it is running, use the isscontrol command or the ISS GUI. See Appendix C, Command reference for ISS.
An interactive session can be established with any standard TCP/IP application such as Telnet, RSH, FTP, or rlogin. When the application expects you to provide the machine name or Internet address of the remote host to which you want to connect, enter instead the name of the service to which you want to connect, as in the following example:
telnet dept_pool
dept_pool is the DNS name of the ISS-defined service. By using the service name, the user is automatically connected to a least-loaded server providing that service, using the leveling metric defined in the configuration file.
Applications that specify TCP/IP machine names or Internet addresses for client server connections should specify the service name in their TCP/IP configuration files.
Depending on the way your site name server is set up and the relationship between the TCP/IP domains in which the client and server machines are located, you may need to specify the service name more fully. For example, dept_pool.sp or even dept_pool.sp.site.corp.com. This may be necessary if your client is served by AFS.
You can end interactive sessions in the same manner as you would in the absence of ISS. For example, to end an FTP session, enter quit at the FTP prompt.
AIX and Solaris: As root, enter:
isscontrol shutdown <nodename>
When ISS is not running, access requests directed to the service names will be resolved to the machine address that was current for each service when ISS was terminated.
Windows: To stop ISS, as administrator:
For Windows 2000: Click Start->Programs->Administrative Tools->Services.
ISS is controlled through the isscontrol command. The complete syntax of this command is described in Appendix C, Command reference for ISS. Some example uses are listed here.
isscontrol add node dart.hursley.ibm.com 1
The above command adds the machine named dart to the cell, and specifies that it is the first machine to be considered as the monitor.
isscontrol delete node dart.hursley.ibm.com
The above command deletes the machine dart from the cell.
isscontrol add node wingnut 3 isscontrol add node wingnut service CorpHTTP
The above commands perform the following sequence:
This section explains how to use the CBR component of Network Dispatcher.
CBR proxy (for IMAP or POP3 protocol)
CBR proxies request for IMAP or POP3 mail requests. To start CBR proxy, issue cbrserver command at the command prompt. After issuing cbrserver, CBR proxy can be configured as described in CBR configuration example. To stop CBR, issue cbrserver stop command at the command prompt.
CBR with WTE (for HTTP protocol)
CBR is a subprocess of WTE. Before you start WTE, CBR must be configured as described in CBR configuration example. Once configured correctly, CBR is started and stopped by starting and stopping the WTE application.
The logs used by CBR are similar to those used in Dispatcher. For more description, see Using Dispatcher logs. One difference is how you change the directory where the logs are stored. This directory is set in the WTE configuration file. One of the four entries is ServerInit. This is the entry containing many comma delimited arguments. The second to last argument is the log directory. To change the log directory, change this argument and restart WTE.
This chapter helps you detect and resolve problems associated with IBM Network Dispatcher. Find the symptom you are experiencing in Troubleshooting tables. Find Using ISS trace and debug facilities.
These are the troubleshooting tables for Dispatcher, ISS, and
CBR.
Table 14. Dispatcher troubleshooting table
Symptom | Possible Cause | Go to... |
---|---|---|
Dispatcher not running correctly | Conflicting port numbers | Checking Dispatcher port numbers |
Configured a collocated server and it will not respond to load balanced requests | Wrong or conflicting address | Problem: Dispatcher and server will not respond |
Connections from client machines not being served or connections timing out |
| Problem: Dispatcher requests are not being balanced |
High availability not working | Client machines are not being served or are timing out | Problem: Dispatcher high-availability function is not working |
Unable to add heartbeat (Windows) | Source address is not configured on an adapter | Problem: Unable to add heartbeat (Windows) |
Server not serving requests (Window) | An extra route has been created in the routing table. | Problem: Extra routes (Windows only) |
Advisors not working correctly with wide area | Advisors are not running on remote machines | Problem: Advisors not working correctly |
SNMPD will not start or will not continue to run (Windows) | The community name passed in the SNMP commands does not agree with the community name with which the subagent was started. | Problem: SNMPD does not run correctly (Windows only) |
Dispatcher, Microsoft IIS, and SSL are not working or will not continue | Unable to send encrypted data across protocols. | Problem: Dispatcher, Microsoft IIS, and SSL do not work (Windows only) |
Connection to remote machine refused | Older version of the keys is still being used. | Problem: Dispatcher connection to a remote machine |
The ndcontrol or ndadmin command fails with 'Server not responding' or 'unable to access RMI server' message | Commands fail due to socksified stack. | Problem: ndcontrol or ndadmin command fails |
Network Dispatcher machine locks when attempting to collocate the server | Linux kernel patch for aliasing the loopback device prevents collocation | Problem: Network Dispatcher machine locks up when attempting to collocate |
"Cannot Find the File..." error message, when running Netscape as default browser to view online help (Windows) | Incorrect setting for HTML file association | Problem: "Cannot find the file... error message when trying to view online Help |
Table 15. CBR Troubleshooting table
Symptom | Possible Cause | Go to... |
CBR not running correctly | Conflicting port numbers | Checking CBR port numbers |
Server is not responding (CBR w/WTE) | CBR server did not get started within WTE. | Problem: Server not responding (CBR w/WTE) |
URL rule doesn't work (CBR w/WTE) | Syntactical or configuration error | Problem: Syntactical or configuration error |
The cbrserver command returns a "java.rmi.RMISecurityExce ption: security.fd.read" exception (CBR proxy) | The system's limit on file descriptors is too small for the number of requests that cbrserver is trying to service. | Problem: The cbrserver command is stopped |
Receive proxy error when trying to add a port (CBR proxy) | The cluster address was not configured on a NIC before the proxy was started. | Problem: Receive CBR proxy error when trying to add a port |
Table 16. ISS troubleshooting table
Symptom | Possible Cause | Go to... |
---|---|---|
ISS not running correctly | Conflicting port number | Checking ISS port numbers |
Starting ISS from the Services panel produces an error message (Windows) |
| Problem: Starting ISS from the Services panel produces an error |
"Error communicating with server" results when attempting to connect to Host using ISS GUI | ISS is not running | Problem: Unable to get ISS GUI to "Connect to Host |
All sessions assigned to one machine |
| Problem: All interactive sessions for ISS are assigned to one machine |
ISS Trace Message: "Cannot rename 'file 1' to 'file 2'. Permission denied." | ISS may not be running. | Problem: ISS trace shows "Cannot rename 'file 1' to 'file 2'. Permission denied." |
ISS not recognizing isscontrol or GUI commands | ISS may not be running on localhost. | Problem: ISS is not recognising the isscontrol or GUI commands |
ISS Log file reports: "Config: Could not find local node in the config file." | There are more than two addresses on the machine and the localhost is not used in the ISS configuration. | Problem: Log file reports "Config: Could not find local node in the config file" |
ISS sends loads, but Dispatcher reports wrong values |
| Problem: ISS is sending loads to Dispatcher, but Dispatcher is reporting the wrong values |
If you are experiencing problems running the Dispatcher, it may be that one of your applications is using a port number that the Dispatcher normally uses. Be aware that the Dispatcher server uses the following port numbers:
If another application is using one of the Dispatcher port numbers, you can change the Dispatcher's port number by doing the following:
If you are experiencing problems running the ISS component, it may be that one of your applications is using a port number that ISS normally uses. Be aware that ISS uses the following port numbers:
To change the port number that the monitor and agents communicate on use the -p option when starting ISS.
If you are experiencing problems running the CBR with WTE, it may be that one of your applications is using a port number that CBR normally uses. Be aware that CBR uses the following port numbers:
If another application is using one of the CBR port numbers, you can change the CBR's port number by doing the following: Edit the changes made to the WTE configuration file. Specifically, the port numbers are listed in the ServerInit entry. Near the end of the parameter string, otherwise known as INIT_STRING, the two numbers are the communication port and the SDA port. Change them to be the desired port numbers. If changes need to be made to the metric port number, then the manager can be restarted with a specific manager start command which allows you to specify the metric port used.
If you are experiencing problems running the CBR proxy using cbrserver, it may be that one of your applications is using a port number that CBR normally uses. Be aware that CBR uses the following port numbers:
If another application is using one of the CBR port numbers, you can change the CBR's port number by doing the following:
This problem can occur when another application is using one of the ports used by the Dispatcher. For more information, go to Checking Dispatcher port numbers.
This problem occurs when another address is being used other than the address specified. When collocating the Dispatcher and server, be sure that the server address used in the configuration is the NFA address or is configured as collocated.
This problem has symptoms such as connections from client machines not being served or connections timing out. Check the following to diagnose this problem:
This problem appears when a Dispatcher high-availability environment is configured and connections from the client machines are not being served or are timing out. Check the following to correct or diagnose the problem:
This Windows error occurs when the source address is not configured on an adapter. Check the following to correct or diagnose the problem.
ndconfig tr0 <ip address> netmask <netmask> or ndcontrol cluster configure
After setting up server machines, you may find that you have inadvertently created one or more extra routes. If not removed, these extra routes will prevent the Dispatcher from operating. To check for and delete them, see Setting up server machines for load balancing.
If you are using wide area support, and your advisors do not seem to be working correctly, make sure that they are started on both the local and the remote Dispatchers. See Using remote advisors with wide area support.
When using SNMP subagents, if the SystemView Agent SNMP daemon does not start and stay up, be sure that you have configured your SNMP community using the snmpcfg program. To access SNMP data from the Dispatcher subagent, the community name passed in the SNMP commands must agree with the community name with which the subagent was started.
When using Dispatcher, Microsoft IIS, and SSL, if they do not work together, there may be a problem with enabling SSL security. For more information about generating a key pair, acquiring a certificate, installing a certificate with a key pair, and configuring a directory to require SSL, see the Microsoft Information and Peer Web Services Information and Planning Guide, which comes with Windows. For Windows NT: Click start->programs->microsoft peer web services (common)->product documentation. For Windows NT and Windows 2000, the local URL for the document, which is viewed by a web browser, is: file:///C|/WINNT/system32/inetsrv/iisadmin/htmldocs/inetdocs.htm.
For Windows NT, Click on Chapter 5: "Securing Data Transmissions with Secure Sockets Layer (SSL)." Scroll down to the section entitled "Installing a certificate with a Key Pair" and there is a subsection called Installing a certificate.
In the Installing a certificate section, add the following two steps after step five:
You must now choose a server connection for this key to become fully activated on the target machine
is displayed, and click OK.
Dispatcher uses keys to allow you to connect to a remote machine and configure it. The keys specify an RMI port for the connection. It is possible to change the RMI port for security reasons or conflicts. When you change the RMI ports, the filename of the key is different. If you have more than one key in your keys directory for the same remote machine, and they specify different RMI ports, the command line will only try the first one it finds. If it is the incorrect one, the connection will be refused. The connection will not occur unless you delete the incorrect key.
The ndcontrol (or cbrcontrol) command returns: "Error: Server not responding." Or, the ndadmin command returns: "Error: unable to access RMI server." These errors can result when your machine has a socksified stack. To correct this problem, edit the socks.cnf file to contain the following lines:
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
For Red Hat Linux, this problem occurs if the server machine has the Linux kernel patch installed for aliasing the loopback device. When collocating the Network Dispatcher on the same server machine that it is load balancing, the patch for aliasing the loopback (if installed) must be removed. The patch prevents the Red Hat Linux machine from being collocated. Red Hat Linux supports collocation but only in the absence of high availability.
For Windows when using Netscape as your default browser, the error message which results with this problem is: Cannot find the file '<filename>.html' (or one of its components). Make sure the path and filename are correct and that all required libraries are available." The problem is due to an incorrect setting for HTML file association.
The solution is the following:
This problem can occur when another application is using one of the ports used by CBR. For more information, go to Checking CBR port numbers.
For CBR w/WTE only, if the server does not respond, the problem could be that CBR did not get started within WTE. Determine whether WTE is correctly configured on your machine. Make the following checks to resolve this problem:
For CBR w/WTE, if the URL rule does not work, this can be a result of either a syntactical or configuration error. For this problem check the following:
On a UNIX platform, this problem occurs when cbrserver is used to load balance a large number of IMAP/POP3 client requests and the system's limit on file descriptors is too small for the number of requests that cbrserver is trying to service. The cbrserver produces the following exception and then is stopped:
java.rmi.RMISecurityException: security.fd.read
The protocol specific proxy log file reports:
SocketException=java.net.SocketException: Socket closed
The solution is to modify the nofiles (AIX, Red Hat Linux) or the open files (Solaris) limit in the shell where cbrserver is started. Increase the nofiles limit to a reasonable number larger than the current nofiles limit. Use ulimit -a to display the current nofiles limit, and use ulimit -n value to increase the value.
For CBR proxy (cbrserver) only, the cbrcontrol port add command produces the following error message: "The proxy on cluster <cluster>, port <port> did not start." The solution is to configure the cluster address on a NIC before the proxy can be started.
This problem can occur when another application is using one of the ports used by ISS. For more information, go to Checking ISS port numbers.
For Windows only, the error message for this problem is the following: "Could not start IBM Interactive Session Support service on \\hostname Error 2140: An internal Windows error occurred." After receiving this error message, check the iss.log file for error messages and debug the ISS configuration file according to the errors in the log file. If iss.log file is not created, then ISS was unable to find the configuration file. For ISS to find the configuration file, use the -c option in the 'Startup Parameters' to specify the full path of the configuration file. For information on setting options for the 'Startup Parameters', see ISS GUI. For information on 'start iss' command options see, Appendix C, Command reference for ISS
The error message that results is "Error communicating with server." The solution to this problem is to verify that the ISS daemon is running by looking at the log file or process list. To use the ISS GUI, the iss command must be issued with the -g option. For Windows, the iss command should be issued with both the -g (GUI) and the -i (interactive) options if started from the command prompt.
This problem may occur due to one of the following reasons:
If this condition does occur, try measuring the loads on the servers manually, and verify that ISS is failing to pick the best one.
Check that the load on the machines is not skewed to the extent that the metric being used to load-balance across the cell would result in the same machine being selected every time. For Unix-based operating systems, you can do this by looking at the amount of idle time each CPU is experiencing (using vmstat or sar) or by looking at the list of active processes (using ps). For Windows platforms, from the Task Manager, select Performance tab to view CPU usage and select Processes tab to view list of active processes. You can test a CUSTOM metric by manually running it on the server.
Also, turn on LogLevel Trace to determine what ISS is doing. See Using ISS trace and debug facilities for details.
Ensure that ISS is being run by the administrator (for Windows) or the root user (for AIX or Solaris). For AIX, also check the permissions on the files named in the error message.
Isscontrol commands, which can also be issued from the GUI, are always sent to the localhost on which they are being executed. Be sure that ISS is running on this node. If an InternalNet is defined and it is not the localhost, then ISS will not accept the isscontrol commands or GUI updates. There is a parameter that can be added to the isscontrol or ndadmin script to force it to send the command to the InternalNet address defined.
For isscontrol, edit the PARM2 line in the isscontrol file to the following: PARM2='-DISSCONTROL_DEBUG=FALSE -DISSCONTROL_HOST=address' where address is the defined InternalNet address.
For the GUI, edit ndadmin and add the following to the END_ACCESS parameter: -DISSCONTROL_HOST=address where address is the defined InternalNet address.
ISS is unable to find the localhost defined in the configuration file. The localhost address must be defined by either the Node or InternalNet address. If there are more than two addresses on the machine and the localhost is not one that is being used in the ISS configuration, then define the localhost as the Node and use an Interface to define the additional desired address.
There could be several things wrong in this scenario. The following are steps for solving the problem:
If the ISS component does not appear to be working as you would expect, then try enabling the Trace or Debug facilities available with the LogLevel keyword. It is recommended that you first try to resolve problems using lower values. After examining the output produced by this parameter, if you cannot determine the cause of the problem, consider using loglevel=4. This parameter generates significantly more output than the trace parameter.
The syntax for the LogLevel keyword is:
LogLevel 0-4
where:
Note: | Loglevel 0 is invalid in the configuration file. |
1999/11/14 20:51:05 Monitor: All nodes for service MyService have failed
1999/11/14 20:51:05 monitor.ibm.com: Received recommendation of <none> for service MyCell/MyService
1999/11/14 20:51:06 Monitor: Load updated for 9.37.64.144/MyResource: -1.000000
1999/11/14 20:52:35 Monitor: Marking server 9.37.64.144 as FAILED
1999/11/14 20:52:35 dispatch: 2541-327 Invalid service configuration
1999/11/14 20:51:50 monitor.ibm.com: Received recommendation of 9.37.64.144 for service MyCell/MyService
The syntax diagram shows you how to specify a command so that the operating system can correctly interpret what you type. Read the syntax diagram from left to right and from top to bottom, following the horizontal line (the main path).
The following symbols are used in syntax diagrams:
You must include all punctuation such as colons, quotation marks, and minus signs that are shown in the syntax diagram.
The following types of parameters are used in syntax diagrams.
Parameters are classified as keywords or variables. Keywords are displayed in lowercase letters and can be entered in lowercase. For example, a command name is a keyword. Variables are italicized and represent names or values you supply.
In the following example, the user command is a keyword. The required variable is user_id, and the optional variable is password. Replace the variables with your own values.
>>-user--user_id--+----------+--------------------------------->< '-password-'
Required keywords: required keywords and variables appear on the main path line.
>>-required_keyword--------------------------------------------><
You must code required keywords and values.
Choose one required item from a stack: If there is more than one mutually exclusive required keyword or variable to choose from, they are stacked vertically in alphanumeric order.
>>-+-required_parameter_1-+------------------------------------>< '-required_parameter_2-'
Optional values: Optional keywords and variables appear below the main path line.
>>-+---------+------------------------------------------------->< '-keyword-'
You can choose not to code optional keywords and variables.
Choose one optional keyword from a stack: If there is more than one mutually exclusive optional keyword or variable to choose from, they are stacked vertically in alphanumeric order below the main path line.
>>-+-------------+--------------------------------------------->< +-parameter_1-+ '-parameter_2-'
Variables: A word in all italics is a variable. Where you see a variable in the syntax, you must replace it with one of its allowable names or values, as defined in the text.
>>-variable----------------------------------------------------><
Nonalphanumeric characters: If a diagram shows a character that is not alphanumeric (such as colons, quotes, or minus signs), you must code the character as part of the syntax. In this example, you must code cluster:port.
>>-cluster:port------------------------------------------------><
Repeat If a diagram shows an arrow it means you have a choice to repeat that operand or get out of the text.
.----------------------. V | >>-ndcontrol--cluster----add--cluster+c2+...----+-maxports--size--+--+---> '-----------------' >--------------------------------------------------------------><
This appendix describes how to use the following Dispatcher ndcontrol commands and the cbrcontrol commands for CBR. CBR uses a subset of these commands.
You can enter a minimized version of the ndcontrol command parameters. You only need to enter the unique letters of the parameters. For example, to get help on the file save command, you can enter ndcontrol he f instead of ndcontrol help file.
If you are running CBR with WTE or CBR proxy (using cbrserver), you can configure via the command line or the GUI. The CBR configuration interface is for the most part a subset of the interface of Dispatcher. Use the cbrcontrol command instead of ndcontrol to configure the CBR component. Some of the commands that are omitted in CBR are listed below.
>>-ndcontrol--advisor--+-interval--name--port--seconds--------------+-> +-list---------------------------------------+ +-loglevel--name--port--level----------------+ +-logsize--name--port--+-unlimited---------+-+ | '-number of records-' | +-report--name--port-------------------------+ +-start--name--port--+-----------+-----------+ | '-log file--' | +-status--name--port-------------------------+ +-stop--name--port---------------------------+ +-timeout--name--port--+-unlimited-+---------+ | '-seconds---' | '-version--name--port------------------------' >--------------------------------------------------------------><
Advisor Name | Protocol | Port |
---|---|---|
ftp | FTP | 21 |
telnet | Telnet | 23 |
smtp | SMTP | 25 |
http | HTTP | 80 |
imap | IMAP | 143 |
pop3 | POP3 | 110 |
nntp | NNTP | 119 |
ssl | SSL | 443 |
WLM | private | 10,007 |
WTE | HTTP | 80 |
PING | PING | 0 |
The default file is advisorname_port.log, for example, http_80.log. To change the directory where the log files will be kept, see Changing the log file paths.
Set the manager proportions to ensure that the advisor information is used.
Examples
ndcontrol advisor interval ftp 21 6
ndcontrol advisor listThis command produces output similar to:
------------------------------ | ADVISOR | PORT | TIMEOUT | ------------------------------ | http | 80 | unlimited | | ftp | 21 | unlimited | ------------------------------
ndcontrol advisor loglevel http 80 0
ndcontrol advisor logsize ftp 21 5000
ndcontrol advisor report ftp 21This command produces output similar to:
-------------------------------------------- | ADVISOR: Ftp | | PORT: 21 | -------------------------------------------- | CLUSTER | SERVER | LOAD | -------------------------------------------- | 9.67.131.18 | 9.67.129.230 | 8 | | 9.67.131.18 | 9.67.131.215 | -1 | --------------------------------------------
ndcontrol advisor start ftp 21 ftpadv.log
ndcontrol advisor status ssl 443This command produces output similar to the following:
Advisor Status: --------------- Interval (seconds) ............ 7 Advisor Log File Name ......... Ssl_443.log Logging Level ................. 1 Log Size ...................... Unlimited
ndcontrol advisor stop http 80
ndcontrol advisor timeout ftp 21 5
ndcontrol advisor version ssl 443
>>-ndcontrol--cluster--+-add--cluster+c2+...--+-----------------------------+-+-> | +-maxports--size--------------+ | | +-maxservers--size------------+ | | +-stickytime--time------------+ | | +-weightbound--weight---------+ | | +-porttype--type--------------+ | | +-primaryhost--address--------+ | | '-staletimeout--staletimeout--' | +-set--cluster+c2+...--+-maxports--size--------------+-+ | +-maxservers--size------------+ | | +-stickytime--time------------+ | | +-weightbound--weight---------+ | | +-porttype--type--------------+ | | +-primaryhost--address--------+ | | '-staletimeout--staletimeout--' | +-remove--cluster--------------------------------------+ +-report--cluster--------------------------------------+ +-status--cluster--------------------------------------+ +-configure--cluster--+-------------------------+------+ | '-interfacename - netmask-' | '-unconfigure--cluster---------------------------------' >--------------------------------------------------------------><
Note: | Additional clusters are separated by a plus sign (+). |
Note: | Porttype does not apply to CBR. |
If you change the primaryhost of a cluster once the primary and backups are already started and running mutual high availability, you also must force the new primary host to takeover. And, you need to update the scripts and manually unconfigure and configure the cluster correctly. See Mutual high availability for more information.
Note: | Report does not apply to CBR. |
Note: | Configure does not apply to CBR. |
Note: | Unconfigure does not apply to CBR. |
Examples
ndcontrol cluster add 130.40.52.153
ndcontrol cluster remove 130.40.52.153
ndcontrol cluster add 0.0.0.0
ndcontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
ndcontrol cluster status 9.67.131.167This command produces output similar to:
Cluster Status: --------------- Address ........................... 9.67.131.167 Number of target ports ............ 3 Max Number of Ports ............... 8 Default Max Number of Servers ..... 32 Default Port Sticky Time .......... 0 Default Port Weight Bound ......... 20 Default Port Type ................. tcp/udp Default stale time ................ 30 Primary Host Address .............. 9.67.131.167
>>-ndcontrol--executor--+-report-------------------------------+-> +-set--+-nfa--IP address-------------+-+ | +-maxclusters--size-----------+ | | +-maxports--size--------------+ | | +-fincount--fincount----------+ | | +-fintimeout--fintimeout------+ | | +-maxservers--size------------+ | | +-staletimeout--staletimeout--+ | | +-stickytime--time------------+ | | +-weightbound--weight---------+ | | +-porttype--type--------------+ | | '-wideportnumber--port--------' | +-start--------------------------------+ +-status-------------------------------+ '-stop---------------------------------' >--------------------------------------------------------------><
Note: | Report does not apply to CBR. |
Note: | NFA does not apply to CBR. |
Note: | Fincount does not apply to CBR. |
Note: | Fintimeout does not apply to CBR. |
Note: | Porttype does not apply to CBR. |
Note: | Wideportnumber does not apply to CBR. |
Note: | Start does not apply to CBR. |
Note: | Stop does not apply to CBR. |
Examples
ndcontrol executor status Executor Status: ---------------- Nonforwarding Address .......... 9.67.131.151 Cluster Max Ports .............. 8 Fin Count ...................... 4,000 Fin Time Out ................... 60 Port Max Servers ............... 32 Port Stale Time Out ............ 30 Port Sticky Time ............... 0 Port Weight Bound .............. 20 Port Type ...................... tcp/udp Max Number of Clusters ......... 100 Wide area network port number .. 2,001
ndcontrol executor set nfa 130.40.52.167
ndcontrol executor set maxclusters 4096
ndcontrol executor start
ndcontrol executor stop
>>-ndcontrol--file--+-delete--file[.ext]------+---------------->< +-appendload--file[.ext]--+ +-report------------------+ +-save--file[.ext]--------+ '-newload--file[.ext]-----'
The file extension (.ext) can be anything you like and can be omitted.
Note: | Files are saved into and loaded from NDROOT/configurations, where
NDROOT is, by default:
|
Examples
ndcontrol file delete file3 File (file3) was deleted.
ndcontrol file newload file1.sv File (file1.sv) was loaded into the Dispatcher.
ndcontrol file appendload file2.sv File (file2.sv) was appended to the current configuration and loaded.
ndcontrol file report FILE REPORT: file1.save file2.sv file3
ndcontrol file save file3 The configuration was saved into file (file3).
>>-ndcontrol--help--+-help--------------+---------------------->< +-executor----------+ +-manager-----------+ +-advisor-----------+ +-cluster-----------+ +-port--------------+ +-rule--------------+ +-server------------+ +-subagent----------+ +-highavailability--+ +-file--------------+ +-set---------------+ +-status------------+ '-log---------------'
Examples
ndcontrol helpThis command produces output similar to:
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help cluster help - print complete help text executor - help on executor command manager - help on manager command advisor - help on advisor command cluster - help on cluster command port - help on port command rule - help on rule command server - help on server command subagent - help on subagent command highavailability - help on high availability command file - help on file command set - help on set command status - help on status command log - help on log commandNotice that parameters within <> are variables.
fintimeout <cluster address>|all <time> -Change FIN timeout (Use 'all' to change all clusters)
Note: | The ndcontrol high availability syntax diagram does not apply to CBR. |
>>-ndcontrol--highavailability--+-status----------------------------------------+-> +-backup--+-add--+-primary-+---+-auto---+---p-+-+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete----------------------------' | +-reach--+-add----+---address--mask-------------+ | '-delete-' | +-heartbeat--+-add--srcaddress--dstaddress--+---+ | '-delete--dstaddress-----------' | +-takeover--------------------------------------+ '-address---------------------------------------' >--------------------------------------------------------------><
In addition, the status keyword returns information about various substates:
Note: | For mutual high availability, the srcaddress and dstaddress must be the NFAs of the machines for at least one heartbeat pair. |
Mutual high availability configuration (role of each Dispatcher machine is both):
Notes:
Examples
ndcontrol highavailability status
Output:
High Availability Status: ------------------------- Role ........................primary Recovery Strategy ........... manual State ....................... Active Sub-state.............. Synchronized Primary host........... 9.67.131.151 Port .........................12,345 Preferred Target....... 9.67.134.223 Heartbeat Status: ----------------- Count ................ 1 Source/Destination ... 9.67.131.151/9.67.134.223 Reachability Status: -------------------- Count ................ 1
ndcontrol highavailability backup add primary auto 80
ndcontrol highavailability reach add 9.67.125.18
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3
ndcontrol highavailability takeover
>>-ndcontrol--host:----remote_host-----------------------------><
ndcontrol host:remote_name
After this command has been issued on the command prompt, enter any valid ndcontrol command you want issued to the remote Network Dispatcher machine.
>>-ndcontrol--log--+-start-------------------------+----------->< +-stop--------------------------+ +-set--+-retention-hours------+-+ | '---interval-seconds---' | '-status------------------------'
>>-ndcontrol--manager--+-interval--seconds-----------------------+-> +-loglevel--level-------------------------+ +-logsize--+-unlimited-+------------------+ | '-bytes-----' | +-proportions--active--new--port--system--+ +-quiesce--host---------------------------+ +-reach set--+-interval-seconds-----+-----+ | '-+-loglevel-level---+-' | | '---logsize-size---' | +-refresh--refresh cycle------------------+ +-report--+-----------------+-------------+ | '-cluster+c2+...--' | +-restart--message------------------------+ +-sensitivity--weight---------------------+ +-smoothing--smoothing index--------------+ +-start--+------------------------+-------+ | '-log file--metric_port--' | +-status----------------------------------+ +-stop------------------------------------+ +-sytemscript--filename-------------------+ +-unquiesce--host-------------------------+ '-version---------------------------------' >--------------------------------------------------------------><
Note: | Additional clusters are separated by a plus sign (+). |
The default file will be installed in the logs directory. See Appendix E, Sample configuration files. To change the directory where the log files will be kept, see Changing the log file paths.
Examples
ndcontrol manager interval 5
ndcontrol manager loglevel 0
ndcontrol manager logsize 1000000
ndcontrol manager proportions 60 35 5 0
ndcontrol manager quiesce 130.40.52.153
ndcontrol manager refresh 3
ndcontrol manager reportThis command produces output similar to:
---------------------------------- | HOST TABLE LIST | STATUS | ---------------------------------- | 9.67.129.221| ACTIVE| | 9.67.129.213| ACTIVE| | 9.67.134.223| ACTIVE| ---------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| WEIGHT | ACTIVE % 48| NEW % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 80 |NOW | NEW |WT | CONN |WT | CONN | WT | LOAD | WT | LOAD | ----------------------------------------------------------------------------------- | 9.67.129.221| 8 | 8 | 10 | 0| 10 | 0 | 7 | 29 | 0 | 0| | 9.67.134.223| 11 | 11 | 10 | 0| 10 | 0 | 12 | 17 | 0 | 0| ----------------------------------------------------------------------------------- | PORT TOTALS:| 19 | 19 | | 0| | 0 | | 46 | | 0| ----------------------------------------------------------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| WEIGHT | ACTIVE % 48| NEW % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 23 |NOW | NEW |WT | CONN |WT | CONN | WT | LOAD | WT | LOAD | ----------------------------------------------------------------------------------- | 9.67.129.213| 10 | 10 | 10 | 0| 10 | 0 | 10 | 71 | 0 | 0| | 9.67.134.223| 0 | 0 | 10 | 0| 10 | 0 |-9999 | -1 | 0 | 0| ----------------------------------------------------------------------------------- | PORT TOTALS:| 10 | 10 | | 0| | 0 | | 70 | | 0| ----------------------------------------------------------------------------------- -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | -------------------------------- |
ndcontrol manager restart Restarting the manager to update codeThis command produces output similar to:
320-14:04:54 Restarting the manager to update code
ndcontrol manager sensitivity 10
ndcontrol manager smoothing 2.0
ndcontrol manager start ndmgr.log
ndcontrol manager statusThis command produces output similar to the following example.
Manager status: ============= Metric port........................... 10,004 Manager log filename.................. manager.log Manager log level..................... 1 Maximum log Size...................... unlimited Sensitivity level..................... 0.05 Smoothing index....................... 1.5 Interval (seconds).................... 2 Weights Refresh Cycle................. 2 Active connections proportion......... 0.5 New connections proportion............ 0.5 Port specific proportion.............. 0 System proportion..................... 0 Reach log level....................... 1 Reach maximum log size (bytes)........ unlimited Reach interval (seconds).............. 7
ndcontrol manager stop
ndcontrol manager unquiesce 130.40.52.153
ndcontrol manager version
>>-ndcontrol--port--+-add--cluster:port--+-----------------------+-+-> | +-crossport--otherport--+ | | +-maxservers--size------+ | | +-stickymask--value-----+ | | +-stickytime--time------+ | | +-staletimeout--value---+ | | +-weightbound--weight---+ | | +-porttype--type--------+ | | '-protocol--type--------' | +-set--cluster:port--+-crossport--otherport--+-+ | +-maxservers--size------+ | | +-stickymask--value-----+ | | +-stickytime--time------+ | | +-staletimeout--value---+ | | +-weightbound--weight---+ | | '-porttype--type--------' | +-remove--cluster:port-------------------------+ +-report--cluster:port-------------------------+ '-status--cluster:port-------------------------' >--------------------------------------------------------------><
Note: | Additional clusters are separated by a plus sign (+). |
Note: | Additional ports are separated by a plus sign (+). |
To remove the crossport feature, set the crossport value back to its own port number. For more information on cross port affinity feature, see Cross port affinity.
Note: | Crossport only applies to the Dispatcher component. |
Note: | The stickymask keyword only applies to the Dispatcher component. |
Note: | For the CBR POP3 or IMAP proxy, staletimeout corresponds to the inactivity autologout timer for these protocols. Staletimeout, for CBR proxy, defaults to 60 seconds, which overrides the inactivity timeouts for POP3 and IMAP. For more information on staletimeout for CBR proxy, see CBR proxy (for IMAP or POP3). |
Note: | Porttype does not apply to CBR. |
Note: | Protocol only applies to the CBR proxy (CBR without WTE). For more information, see CBR proxy (for IMAP or POP3). |
Examples
ndcontrol port add 130.40.52.153:80+23
ndcontrol port set 130.40.52.153:0
cbrcontrol port add 9.37.60.91:20 protocol pop3
ndcontrol port set 130.40.52.153:80 weightbound 10
ndcontrol port set 130.40.52.153:80+23 stickytime 60
ndcontrol port set 130.40.52.153:80 crossport 23
ndcontrol port remove 130.40.52.153:23
ndcontrol port status 9.67.131.153:80This command produces output similar to:
Port Status: ------------ Port Number .................... 80 Cluster Address ................ 9.67.131.153 Number of Servers .............. 2 Stale Timeout .................. 30 Weight Bound ................... 20 Maximum Number of Servers ...... 32 Sticky Time .................... 0 Port Type ...................... tcp/udp Cross Port Affinity ............ 80
Note: | The ndcontrol rule (configure rules) does not apply to CBR proxy (CBR without WTE). |
>>-ndcontrol--rule--+-add--cluster:port:rule--type--type--| opts |--+-> +-dropserver--cluster:port:rule--server---------+ +-remove--cluster:port:rule---------------------+ +-report--cluster:port:rule---------------------+ +-set--cluster:port:rule--| opts |--------------+ +-status--cluster:port:rule---------------------+ '-useserver--cluster:port:rule--server+s2+...---' >-------------------------------------------------------------->< opts |---+----------------------------------+------------------------| +-beginrange--low--endrange--high--+ +-priority--level------------------+ +-pattern=--pattern----------------+ +-tos--value-----------------------+ +-stickytime--time-----------------+ '-affinity--affinity_type----------'
Note: | Additional clusters are separated by a plus sign (+). |
Note: | Additional ports are separated by a plus sign (+). |
Note: | Additional rules are separated by a plus sign (+). |
Note: | Port does not apply to CBR. |
Note: | Service only applies to the Dispatcher component. |
Note: | When defining the beginrange and endrange of time intervals, note that each value must be an integer representing only the hour portion of the time; portions of an hour are not specified. For this reason, to specify a single hour--say, the hour between 3:00 and 4:00 am-- you would specify a beginrange of 3 and an endrange also of 3. This will signify all the minutes beginning with 3:00 and ending with 3:59. Specifying a beginrange of 3 and an endrange of 4 would cover the two-hour period from 3:00 through 4:59. |
Note: | Pattern does not apply to Dispatcher. |
Note: | TOS only applies to the Dispatcher component. |
Note: | Additional servers are separated by a plus sign (+). |
Examples
ndcontrol rule add 9.37.67.100:80:trule type true priority 100
ndcontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
ndcontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 ndcontrol rule useserver cluster1:80:timerule server05
ndcontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
>>-ndcontrol--server--+-add--cluster:port:server--+---------------------+-+-> | +-collocated--value---+ | | +-sticky--value-------+ | | +-weight--value-------+ | | +-fixedweight--value--+ | | '-router--addr--------' | +-set--cluster:port:server--+-collocated--value---+-+ | +-sticky--value-------+ | | +-weight--value-------+ | | +-fixedweight--value--+ | | '-router--addr--------' | +-down--cluster:port:server-------------------------+ +-remove--cluster:port:server-----------------------+ +-report--cluster:port:server-----------------------+ +-up--cluster:port:server---------------------------+ '-status--cluster:port:server-----------------------' >--------------------------------------------------------------><
Note: | Additional clusters are separated by a plus sign (+). |
Note: | Additional ports are separated by a plus sign (+). |
Note: | Additional servers are separated by a plus sign (+). |
Note: | Collocated applies to the Dispatcher component only. |
Note: | Router does not apply for CBR. |
Examples
ndcontrol server add 130.40.52.153:80:27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 sticky no
ndcontrol server down 130.40.52.153:80:27.65.89.42
ndcontrol server remove ::27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
ndcontrol server set 130.40.52.153:80:27.65.89.42 weight 10
ndcontrol server up 130.40.52.153:80:27.65.89.42
ndcontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
>>-ndcontrol--set--+-loglevel--level--------+------------------>< '-logsize--+-unlimited-+-' '-size------'
>>-ndcontrol--status-------------------------------------------><
Examples
ndcontrol statusThis command produces output similar to:
Executor has been started. Manager has been started. -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
Note: | Ndcontrol subagent does not apply to CBR. |
>>-ndcontrol--subagent--+-loglevel--level---------------------+->< +-logsize--+-bytes-----+--------------+ | '-unlimited-' | +-report------------------------------+ +-start--+--------------------------+-+ | '-community_name--logfile--' | +-status------------------------------+ +-stop--------------------------------+ '-version-----------------------------'
Examples
ndcontrol subagent start bigguy bigguy.log
This appendix describes how to use the following ISS commands and the configuration keywords for the ISS component of Network Dispatcher:
>>-iss--+--d------------+-------------------------------------->< +--c--filename--+ +--g--portnum---+ +--h------------+ +--i------------+ +--l--filename--+ '--p--portnum---'
>>-isscontrol--+-add--| add operands |--------+---------------->< +-delete--| delete operands |--+ +-set--| set operands |--------+ '-shutdown--nodename-----------' add operands |---+-cell--name-------------------------------------------+----| +-node--name--+-id--+--------------------+-+-----------+ | | '-to cell--cellname--' | | | '-to service--servicename----' | +-service--name--+-DNSName--+--------------------+---+-+ | | '-to cell--cellname--' | | | '--+-to ISSNameServer-+---nodename--' | | +-to NameServer----+ | | '-to dispatcher----' | +-resourcetype--name--+--------------------------+-----+ | '-to service--servicename--' | +--+-ISSNameServer-+---port--to node--nodename---------+ | +-NameServer----+ | | '-dispatcher----' | '----interface-----to node--nodename-------------------' delete operands |---+-cell--name-----------------------------------------+------| +-node--name--+----------------------------+---------+ | +-from cell--cellname--------+ | | '-from service--servicename--' | +-service--name--+-------------------------------+---+ | +-from cell--cellname-----------+ | | +-from ISSNameServer--nodename--+ | | +-from NameServer--nodename-----+ | | '-from dispatcher--nodename-----' | +-resourcetype--name--+----------------------------+-+ | '-from service--servicename--' | +--+-ISSNameServer-+---port--from node--nodename-----+ | +-NameServer----+ | | '-dispatcher----' | '----interface-----from node--nodename---------------' set operands |---+-cell--name--+-HeartbeatsPerUpdate--+---value-----------------------------------------------+-> | +-HeartbeatInterval----+ | | +-HeartbeatsToNetFail--+ | | +-HeartbeatsToNodeFail-+ | | +-PingCache------------+ | | +-Port-----------------+ | | +-AuthKey--------------+ | | +-LogLevel-------------+ | | '-LogSize--------------' | +-node--<nodename>--+--+-CanMonitor-+---+-true--+-+------------------------------------------+ | | '-IssAgent---' '-false-' | | | '--+-NodeWeight--+---value----' | | '-InternalNet-' | +-service--name--+-Alarm--Command------------------+-----------------------------------------+ | +-Overflow--nodename--------------+ | | +-SelectionMethod--+-Best-------+-+ | | | +-RoundRobin-+ | | | | '-StatRR-----' | | | +-ClusterAddress--address---------+ | | '-Port--value---------------------' | +-resourcetype--name--+-Policy--+-Min-+-------------------------------+----------------------+ | | '-Max-' | | | +-Metric--+-Internal--+-CPULoad-+-+-------------+ | | | | '-FreeMem-' | | | | | '-External-Metric-------' | | | +-MetricNormalization--lowerLimit--higherLimit--+ | | +-MetricLimits--recoverLimit--failLimit---------+ | | '-MetricWeight--value---------------------------' | +----NameServer-----on node--nodename----+-NamedData-+---value-------------------------------+ | '-NamedRev--' | '----ISSNameServer-----on node--nodename----+-StickyGarbageCollectionInterval-+---value------' '-StickyTime----------------------' >---------------------------------------------------------------|
The keywords are placed in alphabetical order.
Contains a command string to execute if the service runs out of available nodes. The command string is operating-system dependent.
The syntax is:
ALARM CommandString
This is a default authorization key that will be used by nodes that do not have their own authorization key specified.
The syntax is:
AUTHKEY HexString
For convenience, the HexString may be broken up by white space as long as it all fits on one line, and as long as every digit is paired off so the parser may read a byte (two characters) at a time.
For example:
AUTHKEY 036454DC 65739CB2 23C68DF1 129C4D61
If this keyword is not specified, the authentication will default to a value of all '0's. This value will still be encrypted, but you may find your security is reduced.
If a node does not have a specific AuthKey defined, it will inherit the AuthKey for the cell.
The syntax is:
CELL Name [Global | Local ]
Name must be a Latin-1 string; it will be used as an identifier for the cell when communicating with other cells. The second parameter determines whether the cell described is the local cell that the node will be a member of, or a separate, remote cell that you may wish to communicate with.
A valid config always has 1 local cell. For more information on this keyword, see Updating the ISS configuration file.
This keyword identifies a Dispatcher as the recipient of ISS load information.
The syntax is:
DISPATCHER DNSName [PortNumber]
The DNSName specifies a node on which to connect a Dispatcher. The PortNumber optionally specifies the port on which to start this service. The default PortNumber is 10004.
For example:
DISPATCHER sp1n1
Indicates the time in seconds that ISS allows to elapse before it checks the well-being of the nodes configured in that cell. At every heartbeat, ISS checks that each server is functional by issuing an ICMP ping command; this is the same as if you enter ping at a UNIX or Windows command line. While this does not test the state of everything on the server, it does at least ensure that the server is reachable at the IP level. If the server fails to respond, ISS will not recommend it.
If you have configured one or more metrics, the ISS agent for each node will send out load information at each heartbeat interval, which allows the ISS monitor to determine the load on each server in the cell, and, if necessary, to remove a node from the recommended list.
The syntax is:
HeartbeatInterval heartbeatinterval
For example, to initiate a heartbeat every 30 seconds, enter the following:
HeartbeatInterval 30
If this keyword is not specified, the heartbeat interval will default to 10 seconds.
Note that the product of HeartbeatInterval and HeartbeatsPerUpdate is considered the update interval.
Accepts a non-negative integer that indicates the number of heartbeats after which ISS will determine whether a domain name server update or a Dispatcher update is required. This allows you to configure an update interval that is relatively large while using a relatively fast heartbeat, so that the well-being of the top-ranked server is checked frequently, but without putting too much load on the name server by updating it too often. The update interval is determined from the product of HeartbeatInterval and HeartbeatsPerUpdate.
You can use this keyword to optimize the overall responsiveness of the service in specific user workload scenarios. The syntax is:
HeartbeatsPerUpdate heartbeat_count
For example, to prevent the name server updates from occurring more frequently than once every three heartbeats, enter the following:
HeartbeatsPerUpdate 3
In this example, if HeartbeatInterval is 10 seconds, you have limited the frequency of updates of the name server or the Dispatcher to once every 30 seconds.
If this keyword is not specified, the HeartbeatsPerUpdate factor will default to 3.
The number of heartbeats after which a node will be regarded as unreachable and will not be recommended; it will, however, continue to be regarded as running.
The syntax is:
HeartbeatsToNetFail number
The number of heartbeats after which a node is considered to have failed completely. HeartbeatsToNodeFail must be equal to or greater than HeartbeatstoNetFail.
ISS will still heartbeat to a failed node, the failed status triggers two things: packets and service updates will no longer be routed to a failed node. If the failed node is the monitor, then an election will be held. Since there is still a heartbeat ping being sent to a failed node, it if returns to life it will be brought back into the cell.
The syntax is:
HeartbeatsToNodeFail number
A DNS name or internet address (in dotted decimal notation) that specifies a particular network adapter card or alias address on a machine with multiple adapters or aliases. Addresses specified via this Interface keyword can then be added to the NodeList of a service in order to specify which interface of a node that a service should use.
The syntax is:
Interface IPAddress
where IPAddress is in dotted decimal notation or a DNSName.
A DNS name or Internet address (in dotted decimal notation) that specifies the network interface of a machine used for ISS network traffic (communications with the ISS monitor). This keyword allows you to define separate network interfaces for ISS monitor traffic and for normal service traffic.
The syntax is:
InternalNet DNSName
This keyword identifies an ISS replacement nameserver as an Observer. ISSD must be running on that node. The ISSD daemon will start the nameserver automatically. The default PortNumber is 53.
The syntax is:
ISSNameServer DNSName [ PortNumber]
The syntax is:
LogLevel [0 | 1 | 2 | 3 | 4]
Where:
The syntax is:
METRIC [Internal | External ] string
Where:
Internal identifies a given measurement method as being provided by the system. The following metrics are internally specified:
Note: | All internal metrics may not be available on all operating systems. |
External is a user-defined metric.
If Internal, String is the name of one of the system-provided measurement methods. If External, String is a command to execute to take a load measurement. That command must return a number as its only output. If multiple operating systems are being used, you must ensure that the command returns appropriate results on each platform.
The first parameter sets the point at which the node should be returned to active participation. The second parameter of this keyword sets the point at which the node resource should be removed from active participation in the Cell, because the load has reached a critical stage. The former is usually significantly lower than the latter, to avoid the phenomenon of resources returned to service too soon, only to quickly rise again to the fail limit.
The syntax is:
MetricLimits RecoverLimit FailLimit
For example, in defining the limits of our CPU load metric, we might code:
MetricLimits 90 95
This would cause the resource to be removed at 95 percent utilization, and returned only when it was back down to 90 percent.
Use this keyword to refer to a ResourceType.
This keyword sets reasonable limits for the metric to which it applies. The first parameter sets the lower limit; the second parameter sets the upper limit. The units indicated are specific to the object of the metric. For example, in measuring CPU load, which is stated in percentage points, reasonable limits on the lower and upper ends would be 0 and 100, respectively.
The syntax is:
MetricNormalization LowerLimit UpperLimit
For example:
MetricNormalization 0 100
The syntax is:
MetricWeight <number>
Defines the path and filename of the datafile where the DNS NameServer configuration data is stored which ISS needs to know about.
The syntax is:
NamedData pathname
Defines the path and filename of the datafile for ISS to update in order to update reverse name-to-address mappings. This keyword must be provided if reverse datafile updates are required. The omission of this keyword from a cell definition indicates to ISS that reverse updates are not required. The syntax is:
NamedRev pathname
This keyword identifies a DNS nameserver as an Observer. The default PortNumber is 53.
The syntax is:
NameServer DNSName [PortNumber]
Note: | Adding and deleting namservers can be changed in a global cell using the GUI or the command line. |
The syntax is:
Node DNSName IDNumber
Where DNSName is the hostname that will resolve to the correct service IP address for that node, and IDNumber is a unique number that identifies the node and determines its priority level for being selected as monitor.
For example:
Node dart 3
Note: | Adding and deleting nodes can be changed in a global cell using the GUI or the command line. |
Lists the nodes that a Service may use.
The syntax is:
NodeList DNSName [DNSName...]
The names of the nodes must be separated by white space. At least one node must be listed. This keyword may occupy as many lines as necessary.
For example:
Nodelist dart esme delta
The syntax is:
NodeWeight Number
The NodeWeight is a floating-point number used in calculating the node's priority. After an aggregate load score has been calculated for each node, each of these load scores is then multiplied by the appropriate NodeWeight to determine that node's priority. Thus, a higher NodeWeight will result in a higher priority.
NodeWeight 3.3
When present, this keyword specifies that the node is not running ISS and so it cannot return load information (or run the monitor function). This should only be used together with the RoundRobin Selection Method, and is not recommended unless it is not possible to run ISS on the node.
If you modify from the GUI or isscontrol and set issagent=true for that node, then all other nodes should be updated to reflect that change.
When present, this keyword specifies that the node is not to be used as the ISS monitor.
The syntax is:
NotMonitor
This keyword identifies a server on which to fall back if all the other nodes in the NodeList are unable to provide the service.
The syntax is:
Overflow DNSName
For example:
Overflow delta
Specifies that ISS should limit the size of the ping triangulation cache to the number of kilobytes specified. If Ping cache is set to 0, ping triangulation will not operate in that cell. The default is 0.
The syntax is:
PingCache number
For example:
PingCache 10
Indicates whether a metric function is to be minimized or maximized. The syntax is:
POLICY { MIN | MAX }
The default value is MIN.
For example, a metric based on the number of active users would regard the smallest value as the best and would have the following entry:
POLICY MIN
A metric function based on CPU idle time, on the other hand, would regard the maximum value as best and, therefore, the policy would be specified as the following:
POLICY MAX
Place this keyword at the start of any line in the configuration file to tell ISS the port number you used when you configured the Cell.
Note: | This keyword performs the same function as ISS_Port did in previous versions. If fact, ISS_Port may still be used, if desired. |
It is recommended you put this entry near the top of the ISS Configuration file, together with the other general definitions.
You can choose any port which is not already in use. Ports which are used are listed in the Services file. The services can be found in the following directories.
You should add an entry for the port you select for the ISS cell.
If this keyword is not specified, the port number will default to 7139.
The syntax is:
PortNumber port_number
This keyword lists the resources, required by a given service, that reside on a given node. As with the NodeList keyword, these parameters may number from one to many, and may take up as many lines as necessary.
The syntax is:
Resourcelist ResourceTypeName [ResourceTypeName...]
For example:
Resourcelist CPU NetworkInterface VMPages
The syntax is:
ResourceType Name
Here is an example of a user-defined ResourceType:
ResourceType CPUprocess Metric External ps -ef | wc -1 MetricLimits 800 1000 Policy Min
This keyword specifies how the ISS Monitor is to select the best node currently able to provide a Service. For more information about this keyword, see Updating the ISS configuration file.
The syntax is:
SelectionMethod [RoundRobin | Best] | StatRR]
For example:
SelectionMethod RoundRobin
The syntax is:
Service Name DNSName [cluster address] [PortNumber]
For example:
Service WWWService www.issdev.hursley.ibm.com. 129.40.161.74 21
Note: | Adding and deleting services can be changed in a global cell using the GUI or the command line. |
A list of services to be performed.
The syntax is:
Servicelist ServiceName [ServiceName...]
For example:
Servicelist WWWService
This appendix describes how to use the following CBR rule types.
In the rule (pattern) syntax, there cannot be any spaces and special characters.
CBR reserved keywords are always followed by an equal sign ('=').
Here are some of the examples.
url=http://*/*.gif client=9.32.* !(path=*.jpeg) (path=index/*.gif & protocol=httpd)| (client=9.1.2.3)
This appendix contains sample configuration files for the Dispatcher and the ISS functions of IBM Network Dispatcher.
Sample files are located in the /dispatcher/samples/ directory.
#!/bin/ksh # # configuration.sample - Sample configuration file for the Dispatcher component # # # Ensure the root user is the one executing this script. # # iam=`whoami` # if [ "$iam" != "root" ]if [ "$iam" != "root" ] # then # echo "You must login as root to run this script" # exit 2 # fi # # First start the server # # ndserver start # sleep 5 # # Then start the executor # # ndcontrol executor start # # The Dispatcher can be removed at any time using the # "ndcontrol executor stop" and "ndserver stop" commands to # stop the executor and server respectively prior to removing # the Dispatcher software. # # The next step in configuring the Dispatcher is to set the # NFA (non-forwarding address) and the cluster address(es). # # The NFA is used to remotely access the Dispatcher machine # for administration or configuration purposes. This # address is required since the Dispatcher will forward packets # to the cluster address(es). # # The CLUSTER address is the hostname (or IP address) to # which remote clients will connect. # # Anywhere in this file, you may use hostnames and IP # addresses interchangeably. # # NFA=hostname.domain.name # CLUSTER=www.yourcompany.com # echo "Loading the non-forwarding address" # ndcontrol executor set nfa $NFA # # The next step in configuring the Dispatcher is to create # a cluster. The Dispatcher will route requests sent to # the cluster address to the corresponding server machines # defined to that cluster. You may configure and server # multiple cluster address using Dispatcher. # Use a similar configuration for CLUSTER2, CLUSTER3, etc. # # echo "Loading first CLUSTER address " # ndcontrol cluster add $CLUSTER # # Now we must define the ports this cluster will use. Any # requests received by the Dispatcher on a defined port will # be forwared to the corresponding port of one of the server # machines. # # echo "Creating ports for CLUSTER: $CLUSTER" # ndcontrol port add $CLUSTER:20+21+80 # # The last step is to add each of the server machines to the # ports in this cluster. # Again, you can use either the hostname or the IP address # of the server machines. # # SERVER1=server1name.domain.name # SERVER2=server2name.domain.name # SERVER3=server3name.domain.name # echo "Adding server machines" # ndcontrol server add $CLUSTER:20+21+80: # $SERVER1+$SERVER2+$SERVER3 # # We will now start the load balancing components of the # Dispatcher. The main load balancing component is called # the manager and the second load balancing components are the # advisors. If the manager and advisors are not running the # Dispatcher sends requests in a round-robin format. Once the # manager is started, weighting decisions based on the number # of new and active connections is employed and incoming # requests are sent to the best server. The advisors give the # manager further insight into a servers ability to service # requests as well as detecting whether a server is up. If # an advisor detects that a server is down it will be # marked down (providing the manager proportions have been # set to include advisor input) and no further requests will be # routed to the server. # The last step in setting up the load balancing components # is to set the manager proportions. The manager updates the # weight of each of the servers based on four policies: # 1. The number of active connections on each server. # 2. The number of new connections to each server. # 3. Input from the advisors. # 4. Input from the system level advisor (ISS). # These proportions must add up to 100. As an example, setting # the manager proportions to # ndcontrol manager proportions 48 48 0 0 # will give active and new connections 48% input into the # weighting decision, the advisors will contribute 4% and # the system input will not be considered. # # NOTE: By default the manager proportions are set to 50 50 0 0 # # echo "Starting the manager..." # ndcontrol manager start # echo "Starting the FTP advisor on port 21 ..." # ndcontrol advisor start ftp 21 # echo "Starting the HTTP advisor on port 80 ..." # ndcontrol advisor start http 80 # echo "Starting the Telnet advisor on port 23 ..." # ndcontrol advisor start telnet 23 # echo "Starting the SMTP advisor on port 25 ..." # ndcontrol advisor start smtp 25 # echo "Starting the POP3 advisor on port 110 ..." # ndcontrol advisor start pop3 110 # echo "Starting the NNTP advisor on port 119 ..." # ndcontrol advisor start nntp 119 # echo "Starting the SSL advisor on port 443 ..." # ndcontrol advisor start ssl 443 # # echo "Setting the manager proportions..." # ndcontrol manager proportions 58 40 2 0 # # The final step in setting up the Dispatcher machine is to # alias the Network Interface Card (NIC). # # NOTE: Do NOT use this command in a high availability # environment. The go* scripts will configure the NIC and # loopback as necessary. # ndcontrol cluster configure $CLUSTER # If your cluster address is on a different NIC or subnet from the NFA use the following format for the cluster configure command. # ndcontrol cluster configure $CLUSTER tr0 0xfffff800 # where tr0 is your NIC (tr1 for the second token ring card, en0 # for the first ethernet card) and 0xfffff800 is a valid # subnet mask for your site. # # # The following commands are set to the default values. # Use these commands as a guide to change from the defaults. # ndcontrol manager loglevel 1 # ndcontrol manager logsize unlimited # ndcontrol manager sensitivity 5.000000 # ndcontrol manager interval 2 # ndcontrol manager refresh 2 # # ndcontrol advisor interval ftp 21 5 # ndcontrol advisor loglevel ftp 21 1 # ndcontrol advisor logsize ftp 21 unlimited # ndcontrol advisor timeout ftp 21 unlimited # ndcontrol advisor interval telnet 23 5 # ndcontrol advisor loglevel telnet 23 1 # ndcontrol advisor logsize telnet 23 unlimited # ndcontrol advisor timeout telnet 23 unlimited # ndcontrol advisor interval smtp 25 5 # ndcontrol advisor loglevel smtp 25 1 # ndcontrol advisor logsize smtp 25 unlimited # ndcontrol advisor timeout smtp 25 unlimited # ndcontrol advisor interval http 80 5 # ndcontrol advisor loglevel http 80 1 # ndcontrol advisor logsize http 80 unlimited # ndcontrol advisor timeout http 80 unlimited # ndcontrol advisor interval pop3 110 5 # ndcontrol advisor loglevel pop3 110 1 # ndcontrol advisor logsize pop3 110 unlimited # ndcontrol advisor timeout pop3 110 unlimited # ndcontrol advisor interval nntp 119 5 # ndcontrol advisor loglevel nntp 119 1 # ndcontrol advisor logsize nntp 119 unlimited # ndcontrol advisor timeout nntp 119 unlimited # ndcontrol advisor interval ssl 443 5 # ndcontrol advisor loglevel ssl 443 1 # ndcontrol advisor logsize ssl 443 unlimited # ndcontrol advisor timeout ssl 443 unlimited #
The following is a sample Network Dispatcher configuration file called configuration.cmd.sample for use with Window.
@echo off rem configuration.cmd.sample - Sample configuration file for the rem Dispatcher component. rem rem ndserver must be started via Services rem rem rem Then start the executor rem rem call ndcontrol executor start rem rem The next step in configuring the Dispatcher is to set the rem NFA (non-forwarding address) and to set the cluster rem address(es). rem rem The NFA is used to remotely access the Dispatcher rem machine for administration configuration purposes. This rem address is required since the Dispatcher will forward rem packets to the cluster address(es). rem rem The CLUSTER address is the hostname (or IP address) to which rem remote clients will connect. rem rem Anywhere in this file, you may use hostnames and IP rem addresses interchangeably. rem NFA=[non-forwarding address] rem CLUSTER=[your clustername] rem rem set NFA=hostname.domain.name rem set CLUSTER=www.yourcompany.com rem echo "Loading the non-forwarding address" rem call ndcontrol executor set nfa %NFA% rem rem The following commands are set to the default values. rem Use these commands to change the defaults rem call ndcontrol executor set fintimeout 30 rem call ndcontrol executor set fincount 4000 rem rem The next step in configuring the Dispatcher is to create rem a cluster. The Dispatcher will route requests sent to rem the cluster address to the corresponding server machines rem defined to that cluster. You may configure and server rem multiple cluster addresses using Dispatcher. rem Use a similar configuration for CLUSTER2, CLUSTER3, etc. rem rem echo "Loading first CLUSTER address " rem call ndcontrol cluster add %CLUSTER% rem rem Now we must define the ports this cluster will use. Any rem requests received by the Dispatcher on a defined port rem will be forwarded to the corresponding rem port of one of the server machines. rem rem echo "Creating ports for CLUSTER: %CLUSTER%" rem call ndcontrol port add %CLUSTER%:20+21+80 rem rem The last step is to add each of the server machines to rem the ports in this cluster. Again, you can use either the rem hostname or the IP address of the server machines. rem rem set SERVER1=server1name.domain.name rem set SERVER2=server2name.domain.name rem set SERVER3=server3name.domain.name rem echo "Adding server machines" rem call ndcontrol server add %CLUSTER%:20+21+80: rem %SERVER1%+%SERVER2%+%SERVER3% rem rem We will now start the load balancing components of the rem Dispatcher. The main load balancing component is called rem the manager and the second load balancing components are the rem advisors. If the manager and advisors are not rem running the Dispatcher sends requests in a round-robin rem format. Once the manager is started, weighting decisions rem based on the number of new and active connections is rem employed and incoming requests are sent to the best rem server. The advisors give the manager further insight rem into a servers ability to service requests as well as rem detecting whether a server is up. If an advisor detects rem that a server is down it will be marked down (providing the rem manager proportions have been set to include advisor rem input) and no further requests will be routed to the server. rem The last step in setting up the load balancing rem components is to set the manager proportions. The rem manager updates the weight of each of the servers based rem on four policies: rem 1. The number of active connections on each server rem 2. The number of new connections for each server rem 3. Input from the advisors. rem 4. Input from the system level advisor (ISS). rem rem These proportions must add up to 100. As an example, rem setting the manager proportions to ndcontrol manager rem proportions 48 48 0 0 will give active and new rem connections 48% input into the weighting decision, rem the advisor will contribute 4% and the system input will rem not be considered. rem rem NOTE: By default the manager proportions are set to 50 50 rem 0 0 rem echo "Starting the manager..." rem call ndcontrol manager start rem echo "Starting the FTP advisor on port 21 ..." rem call ndcontrol advisor start ftp 21 rem echo "Starting the HTTP advisor on port 80 ..." rem call ndcontrol advisor start http 80 rem echo "Starting the Telnet advisor on port 23 ..." rem call ndcontrol advisor start telnet 23 rem echo "Starting the SMTP advisor on port 25 ..." rem call ndcontrol advisor start smtp 25 rem echo "Starting the POP3 advisor on port 110 ..." rem call ndcontrol advisor start pop3 110 rem echo "Starting the NNTP advisor on port 119 ..." rem call ndcontrol advisor start nntp 119 rem echo "Starting the SSL advisor on port 443 ..." rem call ndcontrol advisor start ssl 443 rem rem echo "Setting the manager proportions..." rem call ndcontrol manager proportions 58 40 2 0 rem rem The final step in setting up the Dispatcher machine is rem to alias the Network Interface Card (NIC). rem rem NOTE: Do NOT use this command in a high availability rem environment. The go* scripts will configure the NIC and rem loopback as necessary. rem rem ndcontrol cluster configure %CLUSTER% rem If you cluster address is on a different NIC or subnet rem from the NFA use the following format for the cluster rem configure command. rem ndcontrol cluster configure %CLUSTER% tr0 0xfffff800 rem where tr0 is your NIC (tr1 for the second token ring card, rem en0 for the first ethernet card) and 0xfffff800 is rem a valid subnet mask for your site. rem rem rem The following commands are set to the default values. rem Use these commands to guide to change from the defaults. rem call ndcontrol manager loglevel 1 rem call ndcontrol manager logsize unlimited rem call ndcontrol manager sensitivity 5.000000 rem call ndcontrol manager interval 2 rem call ndcontrol manager refresh 2 rem rem call ndcontrol advisor interval ftp 21 5 rem call ndcontrol advisor loglevel ftp 21 1 rem call ndcontrol advisor logsize ftp 21 unlimited rem call ndcontrol advisor timeout ftp 21 unlimited rem call ndcontrol advisor interval telnet 23 5 rem call ndcontrol advisor loglevel telnet 23 1 rem call ndcontrol advisor logsize telnet 23 unlimited rem call ndcontrol advisor timeout telnet 23 unlimited rem call ndcontrol advisor interval smtp 25 5 rem call ndcontrol advisor loglevel smtp 25 1 rem call ndcontrol advisor logsize smtp 25 unlimited rem call ndcontrol advisor timeout smtp 25 unlimited rem call ndcontrol advisor interval http 80 5 rem call ndcontrol advisor loglevel http 80 1 rem call ndcontrol advisor logsize http 80 unlimited rem call ndcontrol advisor timeout http 80 unlimited rem call ndcontrol advisor interval pop3 110 5 rem call ndcontrol advisor loglevel pop3 110 1 rem call ndcontrol advisor logsize pop3 110 unlimited rem call ndcontrol advisor timeout pop3 110 unlimited rem call ndcontrol advisor interval nntp 119 5 rem call ndcontrol advisor loglevel nntp 119 1 rem call ndcontrol advisor logsize nntp 119 unlimited rem call ndcontrol advisor timeout nntp 119 unlimited rem call ndcontrol advisor interval ssl 443 5 rem call ndcontrol advisor loglevel ssl 443 1 rem call ndcontrol advisor logsize ssl 443 unlimited rem call ndcontrol advisor timeout ssl 443 unlimited rem
The following is a sample advisor file called ADV_sample.
/** * ADV_sample: The Network Dispatcher HTTP advisor * * * This class defines a sample custom advisor for Network Dispatcher. Like all * advisors, this custom advisor extends the function of the advisor base, called ADV_Base. * It is the advisor base that actually performs most of the advisor's functions, * such as reporting loads back to the Network Dispatcher for use in the * Network Dispatcher's weight algorithm. The advisor base also performs socket connect * and close operations and provides send and receive * methods for use by the advisor. The advisor itself is used only for * sending and receiving data to and from the port on the server being advised. * The TCP methods within the advisor base * are timed to calculate the load. A flag within the constructor in the ADV_base * overwrites the existing load with the new load returned from the advisor if desired. * * Note: Based on a value set in the constructor, the advisor base supplies * the load to the weight algorithm at specified intervals. If the actual * advisor has not completed so that it can return a valid load, the advisor base uses * the previous load. * * NAMING * * The naming convention is as follows: * * - The file must be located in the following Network Dispatcher directories: * * - For dispatcher - nd/dispatcher/lib/CustomAdvisors/ (nd\dispatcher\lib\CustomAdvisors on NT) * - For CBR - nd/cbr/lib/CustomAdvisors/ (nd\cbr\lib\CustomAdvisors on NT) * * - The Advisor name must be preceded with "ADV_". The advisor can * be started with only the name, however; for instance, the "ADV_sample" * advisor can be started with "sample". * * - The advisor name must be in lowercase. * * With these rules in mind, therefore, this sample is referred to as: * * <base directory>/samples/CustomAdvisors/ *
* * Advisors, as with the rest of Network Dispatcher, must be compiled with the prereq version of Java. * To ensure access to Network Dispatcher classes, make sure that the ibmnd.jar * file (located in the lib subdirectory of the base directory) is included in the system's CLASSPATH. * * * Methods provided by ADV_Base: * * - ADV_Base (Constructor): * * - Parms * - String sName = Name of the advisor * - String sVersion = Version of the advisor * - int iDefaultPort = Default port number to advise on * - int iInterval = Interval on which to advise on the servers * - String sDefaultLogFileName = Unused. Must be passed in as "". * - boolean replace = True - replace the load value being calculated by the advisor base * False - add to the load value being calculated by the advisor base * - Return * - Constructors do not have return values. * * Because the advisor base is thread based, it has several other methods available * for use by an advisor. These methods can be referenced using the CALLER parameter passed in getLoad(). * * These methods are as follows: * * - send - Send a packet of information on the established socket connection to the server on * the specified port. * - Parms * - String sDataString - The data to be sent is sent in the form of a string * - Return * - int RC - Whether the data was sucessfully sent or not: zero indicates data was * sent; a negative integer indicates an error. * * - receive - Receive information from the socket connection. * - Parms * - StringBuffer sbDataBuffer - The data received during the receive call * - Return * - int RC - Whether the data was successfully received or not; zero indicates data was * sent; a negative integer indicates an error. * * If the function provided by the advisor base is * not sufficient, you can create the appropriate function within the advisor and * the methods provided by the advisor base will then be ignored. * * An important question regarding * the load returned is whether to apply it to the load being generated * within the advisor base, or to replace it; there are valid instances of both situations. * * This sample is essentially the Network Dispatcher HTTP advisor. It functions very simply: * a send request--an http head request--is issued. Once a response is received, the * getLoad method terminates, flagging the advisor base to stop timing the request. The method * is then complete. The information returned is not parsed; the load is based on the time required * to perform the send and receive operations. */ package CustomAdvisors; import com.ibm.internet.nd.advisors.*; public class ADV_sample extends ADV_Base implements ADV_MethodInterface { String COPYRIGHT = "(C) Copyright IBM Corporation 1997, All Rights Reserved.\n"; static final String ADV_NAME = "Sample"; static final int ADV_DEF_ADV_ON_PORT = 80; static final int ADV_DEF_INTERVAL = 7; // Note: Most server protocols require a carriage return ("\r") and line feed ("\n") // at the end of messages. If so, include them in your string here. static final String ADV_SEND_REQUEST = "HEAD / HTTP/1.0\r\nAccept: */*\r\nUser-Agent: " + "IBM_Network_Dispatcher_HTTP_Advisor\r\n\r\n"; /** * Constructor. * * Parms: None; but the constructor for ADV_Base has several parameters that must be passed to it. * */ public ADV_sample() { super( ADV_NAME, "2.0.0.0-03.27.98", ADV_DEF_ADV_ON_PORT, ADV_DEF_INTERVAL, "", // not used false); super.setAdvisor( this ); } /** * ADV_AdvisorInitialize * * Any Advisor-specific initialization that must take place after the advisor base is started. * This method is called only once and is typically not used. */ public void ADV_AdvisorInitialize() { return; } /** * getLoad() * * This method is called by the advisor base to complete the advisor's operation, based * on details specific to the protocol. In this sample advisor, only a single send and receive are * necessary; if more complex logic is necessary, multiple sends and receives * can be issued. For example, a response might be received and parsed. Based on the information * learned thereby, another send and receive could be issued. * * Parameters: * * - iConnectTime - The current load as it refers to the length of time it took to * complete the connection to the server through the specified port. * * - caller - A reference to the advisor base class where the Network Dispatcher-supplied * methods are to perform simple TCP requests, mainly send and receive. * * Results: * * - The load - A value, expressed in milliseconds, that can either be added to the existing load, * or that can replace the existing load, as determined by the constructor's "replace" flag. * * The larger the load, the longer it took the server to respond; therefore, the higher * the weight will be within Network Dispatcher regarding load balancing. * * If the value is negative, an error is assumed. An error from an advisor indicates that * the server the advisor is trying to reach is not accessible and has been identified as being down. * Network Dispatcher will not attempt to load balance to a server that is down. * Network Dispatcher will resume load balancing to the server when a positive value is received. * * A value of zero is typically not returned; Network Dispatcher handles a load of zero in a special way. * Zero is assumed to indicate an unknown status, and Network Dispatcher gives the server a high weight in * response. */ public int getLoad(int iConnectTime, ADV_Thread caller) { int iRc; int iLoad = ADV_HOST_INACCESSIBLE; // -1 // Send tcp request iRc = caller.send(ADV_SEND_REQUEST); if (iRc >= 0) { // Perform a receive StringBuffer sbReceiveData = new StringBuffer(""); iRc = caller.receive(sbReceiveData); // If the receive is successful, a load of zero is returned. This is because the "replace" flag // is set to false, indicating that the load built within the base advisor is to be used. // Since nothing was done with the returned data, additional load is not necessary. // Note: it is known that the advisor base load will not be zero, therefore a zero load will // not be returned for use in calculating the weight. if (iRc >= 0) { iLoad = 0; } } return iLoad; } } // End - ADV_sample
The sample files can be found in the /iss/samples/ directory.
# This is a sample configuration file used to supply an # additional load value to IBM Network Dispatcher. # There is only one (local) cell, and one service running. # Two Metrics are combined to create the load value for # the service. Since there are two Dispatcher machines # running in a Highly Available configuration, # both dispatchers are listed as observers. # Parameters for the whole cell # In this cell, ITL, the Monitor will attempt to reach # each node every 5 seconds (HeartbeatInterval). After 3 # Intervals, or 15 seconds, each service will be executed. Cell ITL local AuthKey 10043572 ADE4F354 7298FAE3 1928DF54 12345678 LogLevel INFO HeartbeatInterval 5 HeartbeatsPerUpdate 3 PortNumber 7139 # Individual node data # The node dispatch1 has ISS monitor priority 1 and will # run the iss process in ISS monitor mode. The node dispatch2 # has monitor priority 2 and can run as a backup ISS monitor # when dispatch1 is down. The last node, server2, is # declared NotMonitor. The iss processes on this node will run # as ISS agents, collecting load statistics, but cannot # assume the role of an ISS monitor. # The nodes dispatch2 and server1 are equipped with # additional resources and are considered to have an # advantage over the other servers and should be # recommended more often than the others. # Therefore they are given a higher weight. Node dispatch1.raleigh.ibm.com 001 Node dispatch2.raleigh.ibm.com 002 NodeWeight 1.5 Node server1.raleigh.ibm.com 003 NodeWeight 1.5 Node server2.raleigh.ibm.com 098 NotMonitor NodeWeight 1.0 # The service is configured to depend on two resources -- CPU # availability and the process count. Load balancing is # therefore performed based on CPU utilization and the number # of processes currently running. However, ISS will not # schedule work for nodes that are unreachable on the network. # In this configuration, CPU utilization has more value than # the process count for determining a better performance # from a server. Therefore, the CPU value will be considered # 2.0 times more valuable than the ProcessCount. # Definition of "CPU" ResourceType # The specified MetricLimits indicate that a node will # not be used if its CPU usage goes over 95% and will not # be put back in the list until CPU usage goes back down # to 80%. ResourceType CPU Metric Internal CPULoad MetricNormalization 0 100 MetricLimits 80 95 Policy Min MetricWeight 2.0 # Definition of "ProcessCount" ResourceType # The metric associated with ProcessCount is assigned a range # of (0-250). If "ps -fe | wc -l" returns a value greater # than 250, the metric is assigned the upper limit of 250. # When the value of this metric on a node from active # participation in the Service that it is associated with. # The node is returned to active participation when the # metric has a value less than or equal to 200. ResourceType ProcessCount Metric External ps -ef | wc -l MetricNormalization 0 250 MetricLimits 200 225 Policy Min MetricWeight 1.0 # The one configured service, eNDService, is an identifying # string for the service, and is used when balancing between # cells. In this configuration, it is used simply to identify # what the service is for and define which servers to collect # the selected metric values from. # The name PlaceHolder is not needed when you are using ISS # to update the Dispatcher. The "cluster address", # Dispatch_cluster, and port 80, are used to signify which # set of Dispatcher servers are relevant to this service, and # where ISS should send the load information to. ISS itself # does no load balancing in this scenario. Service eNDService PlaceHolder Dispatch_cluster 80 NodeList dispatch2.raleigh.ibm.com server1.raleigh.ibm.com server2.raleigh.ibm.com ResourceList CPU ProcessCount SelectionMethod Best # The machine dispatch1.raleigh.ibm.com and # dispatch2.raleigh.ibm.com have an eNetwork Dispatcher # configured to listen for load values on port 10004. Since # Dispatcher is running in a High Availability configuration, # both Dispatchers need to be listed. Dispatcher dispatch1.raleigh.ibm.com 10004 ServiceList eNDService Dispatcher dispatch2.raleigh.ibm.com 10004 ServiceList eNDService
# This ISS configuration file illustrates how ISS can be # used with as a limited DNS name server to perform load # balancing for two clusters of servers. A different load # balancing method (RoundRobin and Best) is used for each # cluster. StatRR is another possible Selection Method to # consider using. # Basic parameters of ITL cell. Cell ITL local AuthKey 036454DC 65739CB2 23C68DF1 129C4D61 LogLevel Trace HeartbeatInterval 15 HeartbeatsPerUpdate 2 PortNumber 11364 # Nodes in ITL cell # The node monitor1 has ISS monitor priority 1 and will # run the iss process in ISS monitor mode. The node monitor2 has # monitor priority 2 and can run as a backup ISS monitor when # monitor1 is down. The other nodes are declared NotMonitor. # The iss processes on these nodes will run as ISS agents or # perform other special ISS functions. They can not assume # the role of an ISS monitor. Node monitor1.raleigh.ibm.com 01 Node monitor2.raleigh.ibm.com 02 Node nameserver.raleigh.ibm.com 31 NotMonitor # Definition of "Memory" ResourceType # The metric associated with Memory is an Internal metric of # ISS, FreeMem, that is available on AIX and NT. It is # assigned a range of (0-100). It returns the percentage of # free memory. Since a higher percentage would be desirable, # the policy should be Max. When the value of this metric # on a node is less than 10, the node is removed from active # participation in the Service that it is associated with. # The node is returned to active participation when the # metric has a value greater than or equal to 20. ResourceType Memory Metric Internal FreeMem MetricNormalization 0 100 MetricLimits 20 10 Policy Max # Definition of Services available in ITL cell. # The first service, service1, has the DNS name # cluster1.raleigh.ibm.com associated with it. ISS will serve # requests which are addressed to cluster1.raleigh.ibm.com. # Also associated with service1 are the nodes monitor1 and # monitor2. # Since the observer is an ISSNameServer, ISS will allow # the ISS name server running on the nameserver node to # resolve the DNS name cluster1.raleigh.ibm.com to the IP # address of either monitor1 or monitor2 and then send the # resovled address back to the DNS name server. # Since the SelectionMethod is RoundRobin, this mapping of the # name cluster1 to one of the two IP addresses is done using a # simple round-robin algorithm. A new address is selected once # every 60 seconds (HeartbeatInterval * HeartbeatsPerUpdate) # and once every 20 seconds (HeartbeatInterval) ISS checks # that the server whose address is currently recommended # is functional at its ICMP layer, and not too heavily # loaded. # If at any time there are no servers available, the name # cluster1 will be removed from the service and the alarm # triggered, which in this case makes an entry into a file # called /tmp/issalarm.log. Service service1 cluster1.raleigh.ibm.com NodeList monitor1.raleigh.ibm.com monitor2.raleigh.ibm.com SelectionMethod RoundRobin Alarm echo "cluster1 ran out of servers at `date`" >> /tmp/issalarm.log # The second service, service2, has the DNS name # cluster2.raleigh.ibm.com associated with it. Also associated # with service2 are the nodes monitor1 and monitor2. Since # the observer is an ISSNameServer, ISS will allow the # ISS nameserver running on the nameserver node to resolve # the DNS name cluster2.raleigh.ibm.com to the IP address of # either monitor1 or monitor2 and then send the resovled # address back to the client. # Since the SelectionMethod is Best and the ResourceList # keyword specifies Memory, the name cluster2.raleigh.ibm.com # will be mapped to the IP address of the best of the 2 # servers. The best server in this case is the one with # the highest percentage of free memory as reported by the # internal metric FreeMem. # If all the servers in cluster2 have exceeded the free memory # limit then the IP address of the overflow server # (nameserver) will be used. Service service2 cluster2.raleigh.ibm.com NodeList monitor1.raleigh.ibm.com monitor2.raleigh.ibm.com ResourceList Memory SelectionMethod Best Overflow nameserver.raleigh.ibm.com # Defining a NameServer Observer # The ISSNameServer observer running on the node nameserver # subscribes to both services defined in this file. ISS will # use the ISS name server to load balance the two clusters of # servers. ISSNameServer nameserver.raleigh.ibm.com 53 ServiceList service1 service2 # End of ISS configuration file -------------------------
# This ISS configuration file illustrates how ISS can be # used with the Dispatcher in a 2-tiered architecture. The # bottom tier consists of two clusters of servers. Each # cluster itself has two servers. Two Dispatchers are used # to load balance these clusters. The top tier consists of # the two Dispatcher nodes. In this example, ISS performs two # functions: 1. Performs DNS load balancing for the top tier. 2. Provides the Dispatchers with additional server load information so that they can load balance the bottom tier more accurately. # ------------------------------------------------------------- # Basic parameters of ITL cell. Cell ITL local AuthKey 036454DC 65739CB2 23C68DF1 129C4D61 LogLevel Info HeartbeatInterval 15 HeartbeatsPerUpdate 2 PortNumber 11364 # Nodes in ITL cell # The node monitor1 has ISS monitor priority 1 and will # run the iss process in ISS monitor mode. The node monitor2 # has monitor priority 2 and can run as a backup ISS monitor # when monitor1 is down. The other nodes are declared # NotMonitor. # The iss processes on these nodes will run as ISS agents or # perform other special ISS functions. They can not assume # the role of an ISS monitor. The IP addresses 9.67.128.101 # and 9.67.128.102 are the "cluster addresses" of the two # Dispatcher nodes. Node monitor1.raleigh.ibm.com 01 Node monitor2.raleigh.ibm.com 02 Node server1.raleigh.ibm.com 51 NotMonitor Node server2.raleigh.ibm.com 52 NotMonitor Node 9.67.128.101 81 NotMonitor InternalNet dispatch1.raleigh.ibm.com Node 9.67.128.102 82 NotMonitor InternalNet dispatch2.raleigh.ibm.com # Definition of "CPU" ResourceType # On AIX, "vmstat 3 2 | tail -1 | awk '{print $16}'" returns # the percentage of CPU Idle time during a 3 seconds # sampling period. This value should be maximized when you # want to identify the least loaded server. # (On Solaris, use: "vmstat 3 2 | tail -1 | awk # '{print $22}'"). # When the value of this metric on a node is less than 20, # the node is removed from active participation in the # Service that it is associated with. The node is returned # to active participation when the metric has a value # greater than or equal to 60. ResourceType CPU Metric External vmstat 3 2 | tail -1 | awk '{print $16}' MetricNormalization 0 100 MetricLimits 60 20 Policy Max # Definition of Services available in ITL cell. # The service dispatch1_http is intended to be used by # a Dispatcher observer. # The DNS name pool1 of this service is needed as a place # holder but is not significant and will be ignored by ISS # and the Dispatcher. However, "cluster address" and the port # number are significant and must be specified. # The service top_tier will be used only by the ISSNameServer # or NameServer types of observer. In this case, the DNS name # pool1.raleigh.ibm.com is significant but "cluster address" # and port number specifications are not required. Service dispatch1_http pool1 9.67.128.101 80 NodeList server1.raleigh.ibm.com server2.raleigh.ibm.com ResourceList CPU Service top_tier pool1.raleigh.ibm.com NodeList 9.67.128.101 9.67.128.102 ResourceList CPU SelectionMethod Best # Definition of Observers in ITL cell # The type of the first observer is ISSNameServer. This # observer subscribes to the service top_tier. The ISS # replacement name server will be started on the node # monitor1 and will attempt to resolve the DNS name # pool1.raleigh.ibm.com to the IP address of the best of the # two servers of the top_tier service (9.67.128.101 and # 9.67.128.102). The "best" server in this case is the one # with the highest amount of idle cpu as reported by the # "vmstat 3 2 | tail -1 | awk '{print $16}'" command. # It should be noted that 9.67.128.101 and 9.67.128.102 are # the "cluster addresses" of the Dispatcher nodes # dispatch1.raleigh.ibm.com and dispatch2.raleigh.ibm.com # respectively. # The type of the other observers in the ITL cell is # Dispatcher. # For these observers, the role of ISS is to gather # information. # Since the Dispatcher running on the node # dispatch1.raleigh.ibm.com subscribes to the service # dispatch1_http, ISS will evaluate the metrics associated # with service dispatch1_http (CPU) once every 30 seconds # (HeartBeatInterval HeartbeatsPerUpdate) and send the # results to this Dispatcher. The Dispatcher running on the # node dispatch1 will use this load information, along with # other sources of information, to perform load balancing. # ISS performs similar information gathering functions # for the Dispatcher running on node dispatch2. # Assuming that all the appropriate DNS data files have been # set up correctly, when a client attempts to connect to port # 80 of pool1.raleigh.ibm.com, the ISS replacement name server # running on the node monitor1.raleigh.ibm.com will be asked # to resolve the name pool1.raleigh.ibm.com. This name # server will return the "cluster address" of the "best" # Dispatcher in the top tier. We will assume for the present # that this address is 9.67.128.101. # When the client attempts to connect to port 80 of # 9.67.128.101, the Dispatcher running on the node # dispatch1.raleigh.ibm.com (whose cluster address is # 9.67.128.101) will perform the appropriate actions so that # the client is connected to port 80 of its "best" server. # For this setup, ISS does the load balancing at the top tier # and the Dispatcher does the load balancing at the bottom tier. ISSNameServer monitor1.raleigh.ibm.com 53 ServiceList top_tier Dispatcher dispatch1.raleigh.ibm.com 10004 ServiceList dispatch1_http Dispatcher dispatch2.raleigh.ibm.com 10004 ServiceList dispatch1_http # End of ISS configuration file --------------------------------
# Ping Triangulation Sample Configuration File for ISS # -------------------------------------------------------------------- # This text shows two config files. One should be used by nodes in # the Hursley cell, which describes Hursley as a local cell and # Raleigh as a global cell. The other should be used by nodes in the # Raleigh cell, which describes Raleigh as a local cell and Hursley # as global. # # In this way, a particular machine can communicate with all the other # nodes in its cell, and knows enough about the remote cells to # exchange ping information with them, and redirect traffic to them. # -------------------------------------------------------------------- # # SAMPLE FILE ONE -- for use in cell Hursley. Raleigh is nominated "global", # because we communicate with the nodes in that cell only at a global, # wide-area network level Cell ITL global Node spnode1.raleigh.ibm.com 1 Node spnode2.raleigh.ibm.com 2 Node spnode3.raleigh.ibm.com 3 Node spnode4.raleigh.ibm.com 4 # Between all the cells, exactly one ISSNameServer should be configured. # Since the ISSNameServer is a part of the Raleigh (ITL) cell, it must # be specified in the global definition. The ISSNameserver must also # be configured on the same machine that has been designated as the monitor. ISSNameserver spnode1.raleigh.ibm.com 53 # For a given service to be redirected globally, we need to know that it is # available in the global cell we are redirecting to, as well as the local # cell we are redirecting from. # # This matching is done using the service identifying name, which is the first # parameter after the Service keyword. (It is recommended that this service # name be derived from the DNS name of the service). The SelectionMethod and # NodeList are also required. The SelectionMethod must be the same in all cells. Service WWWService www.ourservice.com SelectionMethod Best NodeList spnode1.raleigh.ibm.com spnode2.raleigh.ibm.com spnode3.raleigh.ibm.com spnode4.raleigh.ibm.com # Now we describe the Hursley cell: Cell Hursley local LogLevel info HeartbeatInterval 10 HeartbeatsPerUpdate 3 PortNumber 7139 PingCache 10 # Individual node data # # These nodes are all in the same local subdomain: hursley.ibm.com, so we do # not need to quote their fully qualified DNS names. Node spn1 1 Node spn2 3 Node spn3 4 Node spn4 5 # We are interested in the CPU load on these machines and use the Internal # CPULoad metric. Since it measures percentage utilization, the limits for # normalization are 0 and 100. ResourceType CPU Metric Internal CPULoad MetricNormalization 0 100 Policy Min Service WWWService www.ourservice.com NodeList spn2 spn3 spn4 spn1 ResourceList CPU SelectionMethod Best # --- End of config file for cell Hursley # SAMPLE FILE TWO -- for use in cell ITL # First we describe the Hursley cell. Since this config file is used in # Raleigh (ITL) cell, we describe Hursley as a global cell, and do not need # as much information about a global cell as we do for a local cell. However, # we do need fully-qualified DNS names for nodes which are not in our local # local subdomain. Cell Hursley global Node spn1.hursley.ibm.com 1 Node spn2.hursley.ibm.com 2 Node spn3.hursley.ibm.com 3 Node spn4.hursley.ibm.com 4 # Now we describe the required Service information. # The selectionmethod and nodelist are also required. Service WWWService www.ourservice.com SelectionMethod Best NodeList spn1.hursley.ibm.com spn2.hursley.ibm.com spn3.hursley.ibm.com spn4.hursley.ibm.com # Finally, we describe ITL, which is a local cell in this section Cell ITL local HeartbeatInterval 10 HeartbeatsPerUpdate 3 PortNumber 7139 PingCache 10 # Individual node data Node spnode1.raleigh.ibm.com 1 Node spnode2.raleigh.ibm.com 2 Node spnode3.raleigh.ibm.com 3 Node spnode4.raleigh.ibm.com 4 # We use a different metric here (AIX specific) - this is only for local use, # the Hursley cell does not need to know about it ResourceType CPU Metric External vmstat 3 2 | tail -1 | awk '{print $16}' MetricNormalization 0 100 Policy Max # The SelectionMethod is not defined explicitly for this service # because it will default to BEST. Service WWWService www.ourservice.com ResourceList CPU NodeList spnode1 spnode2 spnode3 spnode4 ISSNameserver spnode1.raleigh.ibm.com 53 ServiceList WWWService # End of config file for cell ITL. # End of ISS configuration file --------------------------------------------------------------------------------
References in this publication to IBM products, programs, or services do not imply that IBM intends to make them available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that IBM product, program or service may be used. Subject to IBM's valid intellectual property or other legally protectable rights, any functionally equivalent product, program, or service may be used instead of the IBM product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by IBM, are the responsibility of the user.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785, U.S.A.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between
independently created programs and other programs (including this one) and
(ii) the mutual use of the information which has been exchanged, should
contact:
Site Counsel
IBM Corporation
P.O. Box 12195
3039 Cornwallis Avenue
Research Triangle Park, NC 27709-2195
USA
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement.
This document is not intended for production use and is furnished as is without any warranty of any kind, and all warranties are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose.
This product includes computer software created and made available by CERN. This acknowledgement shall be mentioned in full in any product which includes the CERN computer software included herein or parts thereof.
The following terms are trademarks of IBM Corporation in the United States or other countries or both.
AIX
IBM
IBMLink
LoadLeveler
OS/2
NetView
HP is a trademark of the Hewlett-Packard Company.
Linux is a registered trademark of Linus Torvalds.
Microsoft, Windows 2000, and Windows NT are trademarks or registered trademarks of the Microsoft Corporation.
Red Hat is a registered trademark of Red Hat, Inc.
Solaris is a trademark of Sun Microsystems, Inc.
UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Limited.
Tivoli is a non-registered trademark for Tivoli
Other company, product, and service names, which may be denoted by a double asterisk (**), may be trademarks or service marks of others.
Note: | Collocated only applies to the AIX, Red Hat Linux, and Solaris operating systems. |