Version 6.0.2
Document Number GC31-6858-02
Note |
---|
Before using this information and the product it supports, be sure to read the general information under Appendix E, Notices. |
Third edition (June 2005)
This edition applies to:
and to all subsequent releases and modifications until otherwise indicated in new editions.
Order publications through your IBM representative or through the IBM branch office serving your locality.
(C) Copyright International Business Machines Corporation 2005. All rights reserved.
U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Content Based Routing (CBR) component
Cisco CSS Controller component
Nortel Alteon Controller component
Functions and advanced features for Load Balancer
Administering and troubleshooting Load Balancer
This book explains how to plan for, install, configure, use, and troubleshoot IBM(R) WebSphere(R) Application Server Load Balancer for AIX(R), HP-UX, Linux(TM), Solaris, and Windows(R) operating systems. Previously, this product was called Edge Server Network Dispatcher, SecureWay(R) Network Dispatcher, eNetwork Dispatcher, and Interactive Network Dispatcher.
The Load Balancer Administration Guide is written for experienced network and system administrators who are familiar with their operating systems and with providing Internet services. Prior exposure to Load Balancer is not required.
This book is not intended to support previous releases of Load Balancer.
The Edge Components Information Center Web site links to the current version of this book in HTML and PDF formats.
For the most current updates about Load Balancer, visit the Web site support page and link to the Technote site.
To access these and related Web pages, go to the URLs listed in Related documents and Web sites.
Accessibility features help a user who has a physical disability, such as restricted mobility or limited vision, to use software products successfully. These are the major accessibility features in Load Balancer:
Your feedback is important in helping to provide the most accurate and high-quality information. If you have any comments about this book or any other Edge components document:
This part provides an overview of Load Balancer and its components, a high-level description of configuration features that are available, a list of hardware and software requirements, and installation instructions. It contains the following chapters:
This chapter gives an overview of Load Balancer and includes the following sections:
For a high-level list of configuration features provided by each of the Load Balancer components, to assist you in planning which features to use for managing your network, see Managing your network: Determining which Load Balancer features to use.
Load Balancer is a software solution for distributing incoming client requests across servers. 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. Load Balancer 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, Load Balancer 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, use Load Balancer to automatically find the optimal server to handle incoming requests, thus enhancing your customers' satisfaction and your profitability.
IMPORTANT: If you are using Load Balancer for IPv6, only the Dispatcher component is available. See Deploying Dispatcher on Load Balancer for IPv6 for more information.
Load Balancer consists of the following five components that can be used separately or together to provide superior load-balancing results:
For HTTP protocol, you can also use the Dispatcher's content-based routing feature to load balance based on the content of the client request. The chosen server is the result of matching the URL to a specified rule. Dispatcher's content-based routing (cbr forwarding method) does not require Caching Proxy.
For more information on the Dispatcher, CBR, Site Selector, Cisco CSS Controller, and Nortel Alteon Controller components, see What are the components of Load Balancer?.
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.
The need for a more powerful solution has resulted in Load Balancer. 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.
Load Balancer uses standard TCP/IP or UDP/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.
Using simple mac level forwarding method, the Dispatcher component only looks at the inbound client-to-server flows. It does not need to see the outbound server-to-client flows. This significantly reduces its impact on the application compared with other approaches and can result in improved network performance.
The Dispatcher, Cisco CSS Controller, and Nortel Alteon Controller components offer built-in high availability, utilizing a backup machine that remains ready at all times to take over load balancing should the primary server machine fail. When one of the servers fails, requests continue to be serviced by the other server. This eliminates any server as a single point of failure and makes the site highly available.
For more information, see How about high availability?
In conjunction with Caching Proxy, the CBR component has the ability to proxy HTTP and HTTPS (SSL) 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.
The Dispatcher component also provides content-based routing, but it does not require the Caching Proxy to be installed. Because the Dispatcher component's content-based routing is performed in the kernel as packets are received, it can provide faster content-based routing than the CBR component. The Dispatcher component performs content-based routing for HTTP (using the "content" type rule) and HTTPS (using SSL session ID affinity).
The Dispatcher component offers a built-in high availability feature, eliminating Dispatcher as a single point of failure from your network. 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 primary and secondary (backup) for each other. See Configure high availability.
When using a two-tier configuration with a Dispatcher machine load balancing traffic across multiple servers that have either CBR or Site Selector, you can achieve a level of high availability for these components of Load Balancer.
The controllers have a high availability feature to eliminate the controller as a single point of failure. A controller on one machine may be configured as a primary and a controller on a different machine may be configured as a backup. The backup monitors the primary and stands by to take over the task of providing server weights to the switches should the primary fail. See High availability for more information.
Load Balancer for IBM WebSphere Application Server Version 6.0.2 includes all the new features and corrective updates from earlier V5 and V6 releases.
Load Balancer for IBM WebSphere Application Server Version 6.0.2 contains a number of new features. The most significant new features are listed here.
Load Balancer for IPv6 is now available. The Load Balancer for IPv6 installation contains only the Dispatcher component but can support both IPv4 and the extended IP addressing scheme of IPv6.
The original Load Balancer (which supports IPv4 only) is still available for v6.0.2 with full functionality of all components.
For information on the limitations and configuration differences of Dispatcher on Load Balancer for IPv6, see Deploying Dispatcher on Load Balancer for IPv6.
This feature applies to Dispatcher's nat or cbr forwarding method.
The maximum segment size (mss) is a new configurable setting for the executor command.
For more information, see dscontrol executor -- control the executor.
For information on supported hardware and software systems, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
Load Balancer for IBM WebSphere Application Server Version 6.0.1 contains a number of new features. The most significant new features are listed here.
This feature applies to all the Load Balancer components, except the CBR component.
Load Balancer is now available on platforms running a 64-bit JVM. For information on supported hardware and software systems, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
Load Balancer's CBR component is not available on platforms running a 64-bit JVM.
This feature applies to all the Load Balancer components.
The Java 2 SDK automatically installs with Load Balancer on all platforms.
This feature applies to all the Load Balancer components.
The default adapter type for Solaris is now eri as specified in the ibmlb.conf file. It was previously specified as hme.
Load Balancer for IBM WebSphere Application Server Version 6.0 contains a number of new features. The most significant new features are listed here.
This feature applies to the Dispatcher component.
On Windows systems, collocation is now supported on Dispatcher's mac forwarding method, in addition to collocation on cbr and nat forwarding. See Using collocated servers for more information.
This feature applies to the Dispatcher component.
Stopping the executor using the command line is now supported on Windows systems.
This feature applies to the Dispatcher component.
A new algorithm has been developed for the Dispatcher component to improve the performance of connection record allocation and reuse. Dispatcher no longer uses a separate system timer thread to cleanup stale connection records and therefore no longer needs the dscontrol executor set fincount command. This command has been deprecated and removed from the product. See Using fintimeout and staletimeout to control cleanup of connection records for more information.
IMPORTANT: Ensure you update all your previous script files to replace the use of the executor set fincount command.
This feature applies to the Dispatcher component.
The use of the dsconfig (ndconfig) command has been deprecated for IPv4 addresses. To replace it, use the dscontrol executor configure command.
IMPORTANT: Ensure you update all your previous script files to replace the use of the dsconfig (ndconfig) command.
This feature applies to the Dispatcher component.
The use of dscontrol replaces ndcontrol in command statements to configure the Dispatcher component. Use of ndcontrol has been deprecated. (Previous releases supported the use of both dscontrol or ndcontrol interchangeably.)
For example: dscontrol executor start (not, ndcontrol executor start).
IMPORTANT: Ensure you update all your previous script files to use dscontrol instead of ndcontrol.
This feature applies to all the Load Balancer components.
For information on the SDK software requirement for v6.0 Edge Components, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
This feature applies to all the Load Balancer components.
For information on supported hardware and software systems, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
Load Balancer for IBM WebSphere Application Server Version 5.1.1 contains a number of new features. The most significant new feature is listed here.
This feature applies to all the Load Balancer components.
On Linux and UNIX systems: For viewing helps, the default browser is Mozilla.
For information on supported browser versions, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
Load Balancer for IBM WebSphere Application Server Version 5.1 contains a number of new features. The most significant new feature is listed here.
This feature applies to the Dispatcher components.
With this enhancement, there is now support for configuring both an FTP port and wildcard port on the same cluster. See Use wildcard port to direct unconfigured port traffic and Wildcard port to handle FTP traffic for more information.
Load Balancer for IBM WebSphere Application Server Version 5.0.2 contains a number of new features. The most significant new features are listed here.
This feature applies to all the Load Balancer components.
In addition to support for running Load Balancer on Linux for Intel(TM), Load Balancer now runs on Linux for S/390 zSeries, iSeries and pSeries.
For supported platforms, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
This feature applies to all the Load Balancer components.
For information on supported hardware and software systems, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
This feature applies to all the Load Balancer components.
In addition to Windows 2000, Load Balancer now runs on Windows Server 2003.
For information on supported hardware and software systems, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
Load Balancer for IBM WebSphere Application Server Version 5.0.1 contains a number of new features. The most significant new features are listed here.
This feature applies to all the Load Balancer components.
In addition to support for AIX, Linux, Solaris, and Windows systems, Load Balancer now runs on HP-UX.
For information on supported hardware and software systems, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
This feature applies to all the Load Balancer components.
For information on supported hardware and software systems, refer to the following Web page, http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html.
Load Balancer for IBM WebSphere Application Server Version 5.0 contains a number of new features. The most significant are listed here.
The Cisco CSS Controller (formerly known as Cisco Consultant) is a Load Balancer component that calculates weights for servers being load balanced by the Cisco CSS switch. The Cisco CSS switch is a hardware based load balancer that supports SNMP. The controller enhances the server load-balancing function of the Cisco CSS switch with greater application and system awareness.
See Quick start configuration, Planning for Cisco CSS Controller, and Configuring Cisco CSS Controller for more information.
This feature is a new component for Load Balancer.
The Nortel Alteon Controller calculates weights for servers being load balanced by a Nortel Alteon Web Switch. The Nortel Alteon Web Switch is a hardware based load balancer with an SNMP interface for fetching connection information and setting weights. The Nortel Alteon Controller is a new Load Balancer component which monitors servers being load balanced by the Alteon switch and provides appropriate weights to ensure accurate load balancing. The controller enhances the server load-balancing function of the Nortel Alteon switch with greater application and system awareness.
See Quick start configuration, Planning for Nortel Alteon Controller, and Configuring Nortel Alteon Controller for more information.
This feature applies to the Cisco CSS Controller and Nortel Alteon Controller components.
Load Balancer now supports high availability for both the Cisco CSS Controller component and the Nortel Alteon Controller component. The customer can now install a controller on a backup server to take over if the primary controller fails.
For Cisco CSS Controller, see High availability for more information.
For Nortel Alteon Controller, see High availability for more information.
This feature applies to the Dispatcher and CBR components.
The enhancement to the connections per second rule allows the customer to specify the "upserversonrule" option. By specifying this option, you can ensure that the remaining servers will not be overloaded if one or more servers in the server set goes down.
See Using rules based on the connections per second for more information.
This feature applies to the CBR component.
The previous implementation of CBR active cookie affinity based client connections to a server on the cluster and port of the request. This can become a problem in configurations where there are multiple rules with different server sets. The enhancement will allow for multiple affinities within a single cluster and port, allowing a client to maintain affinity with potentially many different servers based on the context of the request.
See Active cookie affinity for more information.
This feature applies to the Dispatcher component.
Load Balancer now provides SNMP support on Linux platforms. See SNMP commands and protocol for more information.
This feature applies to all the components of Load Balancer.
Load Balancer now supports Remote Web-based administration in addition to remote administration via RMI (remote method invocation). Web-based administration provides secure, authenticated remote administration of Load Balancer, even when a a firewall is present. See Web-based administration for more information.
This feature applies to all the components of Load Balancer.
A command line ("Send command") can now be accessed from the Host node in the GUI tree. See page *** for more information.
This feature applies to the Dispatcher component.
For Load Balancer problem determination, a tool (lbpd) has been provided that will quickly and easily gather important information that the customer can send to IBM service. See Gathering troubleshooting information for more information.
This feature applies to the Dispatcher, CBR, and Site Selector components.
In addition to the "lightweight" SSL advisor, Load Balancer now provides a "heavyweight" HTTPS advisor. The HTTPS advisor opens full SSL connections which establishes a full SSL socket with the server. (In contrast, the lightweight SSL advisor does not establish a full SSL socket with the server.)
See List of advisors for more information on the HTTPS advisor.
This feature applies to all the Load Balancer components.
Load Balancer now provides an LDAP advisor that monitors the health of LDAP servers.
See List of advisors for more information.
This feature applies to all the Load Balancer components.
Advisors now have the ability to retry connections before marking a server as down.
See Advisor retry and Advisor retry for more information.
This feature applies to the Dispatcher component.
Dispatcher now has the ability to send a TCP reset to a down server. A TCP reset causes the connection to be immediately closed.
See Sending TCP reset to a down server (Dispatcher component only) for more information.
The following features have been removed from Load Balancer
This chapter gives an overview of Load Balancer components and includes the following sections:
For a high-level list of configuration features provided by each of the Load Balancer components, to assist you in planning which features to use for managing your network, see Managing your network: Determining which Load Balancer features to use.
The five components of Load Balancer are: Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller, and Nortel Alteon Controller. Load Balancer gives you the flexibility of using the components separately or together depending on your site configuration. This section gives an overview of these components.
IMPORTANT: If you are using Load Balancer for IPv6, only the Dispatcher component is available. See Deploying Dispatcher on Load Balancer for IPv6 for more information.
The Dispatcher component balances traffic among your servers through a unique combination of load balancing and management software. Dispatcher can also detect a failed server and forward traffic around it. Dispatcher supports HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, and any other TCP or stateless UDP based application.
All client requests sent to the Dispatcher machine are directed to the "best" server according to weights that are set dynamically. You can use the default values for those weights or change the values during the configuration process.
Dispatcher offers three forwarding methods (specified on the port):
The Dispatcher component is the key to stable, efficient management of a large, scalable network of servers. With 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.
Dispatcher brings distinct advantages in balancing traffic load to clustered servers, resulting in stable and efficient management of your site.
Figure 1. Example of a physical representation of a site using Dispatcher to manage local servers
Figure 1 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 when using MAC forwarding method.
Figure 2. Example of a site using Dispatcher and Metric Server to manage servers
Figure 2 illustrates a site in which all servers are on a local network. The Dispatcher component is used to forward requests, and the Metric Server is used to provide system load information to the Dispatcher machine.
In this example, the Metric Server daemon is installed on each back-end server. You can use Metric Server with the Dispatcher component or any of the other Load Balancer components.
Figure 3. 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 (servers on different subnets). Figure 3 shows a configuration where one local Dispatcher (Dispatcher 1) serves as the entry point for all requests. It distributes these requests among its own local servers (ServerA, ServerB, ServerC) and to the remote Dispatcher (Dispatcher 2), which will load balance to its local servers (ServerG, ServerH, ServerI).
When using Dispatcher's NAT forwarding method or using GRE support, wide area support with Dispatcher can also be achieved without using a Dispatcher at the remote site (where ServerD, ServerE, and ServerF are located). See Dispatcher's NAT/NAPT (nat forwarding method) and GRE (Generic Routing Encapsulation) support for more information.
CBR works with Caching Proxy to proxy client requests to specified HTTP or HTTPS (SSL) servers. It allows you to manipulate caching details for faster Web document retrieval with low network bandwidth requirements. CBR along with Caching Proxy examines HTTP requests using specified rule types.
CBR gives you the ability to specify a set of servers that 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 also detects when one server in a set has failed, and stops 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 Caching 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. Caching Proxy 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, SNMP subagent, wide area, and a few other configuration commands.
Caching Proxy must be running before CBR can begin load balancing client requests.
Figure 4. Example of a site using CBR to manage local servers
Figure 4 shows a logical representation of a site in which CBR is being used to proxy some content from local servers. The CBR component uses Caching Proxy to forward client requests (HTTP or HTTPS) to the servers based on the content of the URL.
Site Selector acts as a name server that works in conjunction with other name servers in a domain name system to load balance among a group of servers using measurements and weights that are gathered. You can create a site configuration to let you load balance traffic among a group of servers based on the domain name used for a client's request.
A client submits a request for resolution of a domain name to a name server within its network. Name server forwards the request to the Site Selector machine. Site Selector then resolves the domain name to the IP address of one of the servers that has been configured under the site name. Site Selector returns the IP address of the selected server to the name server. The name server returns the IP address to the client.
Metric Server is a system monitoring component of Load Balancer that must be installed in each load-balanced server within your configuration. Using Metric Server, Site Selector can monitor the level of activity on a server, detect when a server is the least heavily loaded, and detect a failed server. The load is a measure of how hard the server is working. By customizing system metric script files, you can control the type of measurements used to measure the load. You can configure Site Selector 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).
Figure 5. Example of a site using Site Selector and Metric Server to manage local and remote servers
Figure 5 illustrates a site in which the Site Selector component is used to answer requests. Server1, Server2, and Server3 are local. Server4, Server5, and Server6 are remote.
A client submits a request for resolution of a domain name to a client name server. The client name server forwards the request through the DNS to the Site Selector machine (Path 1). Site Selector then resolves the domain name to the IP address of one of the servers. Site Selector returns the IP address of the selected server to the client name server. The name server returns the IP address to the client.
After the client receives the IP address of the server, the client routes application requests directly to the selected server (Path 2).
Cisco CSS Controller forms a complementary solution in conjunction with Cisco's CSS 11000 series switches. The combined solution blends the CSS 11000 series' robust packet forwarding and content routing capabilities with Load Balancer's sophisticated awareness algorithms for determining load information and availability of the service (back-end server application or database). The Cisco CSS Controller function utilizes Load Balancer's weight calculation algorithm, standard and custom advisors, and Metric Server to determine the metrics, health, and load of the service. With this information Cisco CSS Controller generates service weights, which it sends to the Cisco CSS Switch for optimal service selection, load optimization, and fault tolerance.
Cisco CSS Controller tracks many criteria, including:
When a Cisco CSS Switch, without Cisco CSS Controller, is determining the health of a content-providing service, it uses response times for content requests or other network measures. With Cisco CSS Controller in place, these activities are offloaded from the Cisco CSS Switch to Cisco CSS Controller. Cisco CSS Controller influences the service's weight or ability to serve content, and activates or suspends a service as appropriate when the service regains or loses availability.
Cisco CSS Controller:
Figure 6. Example of a site using Cisco CSS Controller and Metric Server to manage local services
Cisco CSS Controller, in conjunction with the Cisco CSS Switch, delivers a "best of both worlds" solution that combines wire-speed content switching with sophisticated application awareness, fault tolerance, and service load optimization. Cisco CSS Controller is part of an overall complementary solution between the Cisco CSS Switch and IBM WebSphere Application Server Load Balancer.
Nortel Alteon Controller in conjunction with the Nortel Alteon family of Web switches provides a complementary solution that combines the switches' packet forwarding speed and capacity with the Load Balancer's sophisticated awareness algorithms for determining server weights.
Nortel Alteon Controller allows you to develop custom advisors that are capable of performing more intelligent, application-aware assessments of the availability and load of applications used to deploy services.
The Metric Server provides system load information, such as CPU and memory utilization information, and a framework for you to develop custom system load measurements.
Nortel Alteon Controller collects many types of metric data to determine weights for servers being load-balanced by Nortel Alteon Web Switches, including:
Nortel Alteon Controller uses SNMP to communicate with the switch. Configuration , state and connection information is retrieved from the switch. Once server weights are calculated by the controller, they are set on the switch. The switch uses the weights set by the controller to select the best server to handle client requests for a service.
Figure 7. Example of a site using Nortel Alteon Controller to manage local servers
You can manage the controller using a browser, a remote GUI, or a remote command line interface.
Nortel Alteon Controller combined with the Nortel Alteon family of Web switches delivers a "best of both worlds" solution that combines wire-speed packet switching with sophisticated application awareness, fault tolerance and server load optimization. Nortel Alteon Controller is part of a complementary solution between the Nortel Alteon family of Web switches and IBM's WebSphere.
This chapter lists the configuration features of the Load Balancer components so you can determine which features to use for managing your network:
IMPORTANT: If you are using Load Balancer for IPv6, only the Dispatcher component is available. See Deploying Dispatcher on Load Balancer for IPv6 for more information.
To optimize balancing the load across servers and ensure that the "right" server is chosen, see:
Dispatcher supports load balancing across your servers for HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, and any other TCP or stateless UDP based application.
_ To run Load Balancer configuration from a separate machine from the one on which the Load Balancer resides, see Remote administration of Load Balancer.
(If you are using the Load Balancer for IPv6 installation, this feature is not available.)
_ To run Dispatcher on the same machine as a Web server that you are load balancing, see Using collocated servers.
_ To use Dispatcher to remove single point-of-failure limitations in your network, see Simple high availability and Mutual high availability.
(If you are using the Load Balancer for IPv6 installation, the simple high availability feature is available, but mutual high availability is not.)
When load balancing SSL (HTTPS) traffic:
_ To ensure that the client uses the same SSL server for multiple connections, see How affinity feature for Load Balancer works.
_ To ensure that the client uses the same server for HTTP and SSL traffic, see Cross port affinity.
(If you are using the Load Balancer for IPv6 installation, the cross port affinity feature is not available.)
_ To ensure that the client uses the same server for multiple connections, see How affinity feature for Load Balancer works.
_ To ensure that a group of clients use the same server for multiple connections, see Affinity address mask (stickymask).
(If you are using the Load Balancer for IPv6 installation, the stickymask feature is not available.)
_ To remove a server from your configuration (for example, for maintenance purposes) without disrupting client traffic, see Quiesce server connection handling.
In order to direct clients to different sets of servers for the same Web address, you can add "rules" to your Dispatcher configuration. For more information, see Configure rules-based load balancing.
_ To direct clients to different sets of servers based on client source IP address, see Using rules based on the client IP address.
_ To direct clients to different sets of servers based on client port, see Using rules based on the client port.
_ To direct clients to different sets of servers based on time of day, see Using rules based on the time of day.
_ To direct clients to servers based on Type of Service (TOS) bits in network packets, see Using rules based on type of service (TOS).
_ To direct clients to different sets of servers based on site traffic:
_ Using connections per second, see Using rules based on the connections per second.
_ Using total active connections, see Using rules based on the total active connections.
_ Reserving and sharing bandwidth for different Web addresses, see Using rules based on reserved bandwidth and shared bandwidth.
_ Ensuring traffic is measured correctly for each of your sets of servers, see Server evaluation option for rules.
_ To direct overflow traffic to a default set of servers (for example, servers that will respond "site busy"), see Using rules that are always true.
_ To override client affinity to ensure that a client does not "stick" to an overflow server, see port affinity override.
If you are using the Load Balancer for IPv6 installation, rules-based load balancing is not available.
To ensure SSL clients return to the same SSL server, based on SSL ID in the client request
_ See page ***.
To direct HTTP clients to different sets of servers using rules based on matching the URL content of the client request, see Dispatcher's content-based routing (cbr forwarding method) and Using rules based on the request content for more information.
_ To distinguish between particular URLs and their service applications, see Server Partitioning: logical servers configured to one physical server (IP address).
_ To ensure clients return to the same server when requesting similar content in multiple connections using cookies created by your Web servers, see Passive cookie affinity.
_ To load balance Web traffic to caching-proxy servers that allow unique content to be cached on each server (thereby increasing the size of your site's cache by eliminating redundant caching of content on multiple machines), see URI affinity.
(If you are using the Load Balancer for IPv6 installation, Dispatcher's cbr forwarding method is not available.)
The advantage of using Dispatcher's cbr forwarding method is that it provides a faster response to client requests than the CBR component. Also, Dispatcher's cbr forwarding does not require the installation and use of Caching Proxy.
If your network includes fully secure SSL (client through server) traffic, the advantage of using the CBR component (in conjunction with Caching Proxy) is that it can process the encryption/decryption required in order to perform content-based routing. For fully secure connections, the Dispatcher's cbr forwarding can only be configured with SSL ID affinity because it cannot process the encryption/decryption to perform true content-based routing on the client request's URL.
Wide area load balancing can be achieved through several different methods.
_ To load balance to remote servers using the wide area feature of Dispatcher, see: Configure wide area Dispatcher support and GRE (Generic Routing Encapsulation) support.
_ To load balance to remote servers using Dispatcher's nat forwarding method, see Dispatcher's NAT/NAPT (nat forwarding method).
(If you are using the Load Balancer for IPv6 installation, wide area load balancing feature is not available.)
_ To load balance one Web address to multiple server daemons on the same machine, where each daemon listens on a unique port see Dispatcher's NAT/NAPT (nat forwarding method).
(If you are using the Load Balancer for IPv6 installation, this feature is not available.)
_ To put Dispatcher traffic on a different network than client traffic (to improve performance by reducing contention on the external network), see Using a private network configuration.
_ To combine multiple Web addresses into a single configuration, see Use wildcard cluster to combine server configurations.
_ To load balance firewalls, see Use wildcard cluster to load balance firewalls.
_ To direct traffic for all destination ports, see Use wildcard port to direct unconfigured port traffic.
_ To detect possible "denial of service" attacks, see Denial of service attack detection.
_ To analyze server traffic, see Using binary logging to analyze server statistics.
_ To generate alerts when servers are marked up or down, see Using scripts to generate an alert or record server failure.
CBR integrates load balancing with WebSphere Application Server's Caching Proxy to proxy client requests to specified HTTP or HTTPS (SSL) servers. To use CBR, Caching Proxy must be installed and configured on the same machine. For information on how to configure Caching Proxy in order to use CBR, see Step 1. Configure Caching Proxy to use CBR.
With the CBR component (or the Dispatcher component's cbr forwarding method), you can provide the following advantages to your clients:
_ Load balance client requests for different types of content to sets of servers. (See Load balancing requests for different types of content.)
_ Improve response time by optimally dividing your site's content among your Web servers. (See Dividing your site's content for better response time.)
_ Ensure uninterrupted client traffic during server failure by allowing multiple servers to be assigned to each type of content. (See Providing backup of Web server content.)
If your network requires fully secure SSL traffic (client through server), the advantage of using the CBR component (in conjunction with Caching Proxy) is that it can process SSL encryption/decryption in order to perform content-based routing.
For fully secure SSL connections, the Dispatcher's cbr forwarding can only be configured with SSL ID affinity because it cannot process the encryption/decryption to perform true content-based routing on the client request's URL.
For HTTP traffic, the advantage of using Dispatcher's cbr forwarding method is that it provides a faster response to client requests than the CBR component. Also, Dispatcher's cbr forwarding does not require the installation and use of Caching Proxy.
_ To run Load Balancer configuration from a separate machine from the one on which the Load Balancer resides, see Remote administration of Load Balancer.
_ CBR can run on the same machine as a server that you are load balancing. See Using collocated servers for more information.
_ To improve CPU utilization by using multiple Caching Proxy processes, see Using multiple Caching Proxy processes to improve CPU utilization.
To allow content-based routing of SSL traffic:
_ Using secure connection on both sides (client-to-proxy and proxy-to-server), see Load balancing across fully secure (SSL) connections.
_ Using secure connections only on the client-to-proxy side, see Load balancing client-to-proxy in SSL and proxy-to-server in HTTP.
_ To distinguish between particular URLs and their service applications, see Server Partitioning: logical servers configured to one physical server (IP address).
In order to direct clients to different sets of servers for the same Web address, you can add "rules" to your CBR configuration. For more information, see Configure rules-based load balancing.
_ To direct clients to different sets of servers based on the content of the requested URL, see Using rules based on the request content.
_ To direct clients to different sets of servers based on client source IP address, see Using rules based on the client IP address.
_ To direct clients to different sets of servers based on time of day, see Using rules based on the time of day.
_ To direct clients to different sets of servers based on site traffic:
Using connections per second, see Using rules based on the connections per second.
Using total active connections, see Using rules based on the total active connections.
_ To direct overflow traffic to a default set of servers (for example, server(s) that will respond "site busy"), see Using rules that are always true.
_ To override client affinity to ensure that a client does not "stick" to an overflow server, see port affinity override.
_ To ensure that a client returns to the same server for multiple connections, see How affinity feature for Load Balancer works.
_ To remove a server from your configuration (for example, for maintenance purposes) without disrupting client traffic, see Quiesce server connection handling.
_ To ensure that clients return to the same server when requesting similar content in multiple connections without relying on cookies created by your Web servers, see Active cookie affinity.
_ To ensure that clients return to the same server when requesting similar content in multiple connections using cookies created by your Web servers, see Passive cookie affinity.
_ To load balance Web traffic to caching-proxy servers that allow unique content to be cached on each server (thereby increasing the size of your site's cache by eliminating redundant caching of content on multiple machines), see URI affinity.
_ To remove single point of failure limitations in your network using Dispatcher in a two-tier configuration with CBR, see How about high availability?.
_ To analyze server traffic, see Using binary logging to analyze server statistics.
_ To generate alerts when servers are marked up or down, see Using scripts to generate an alert or record server failure.
Site Selector load balances a name service request across a group of servers.
_ To run Load Balancer configuration from a separate machine from the one on which the Load Balancer resides, see Remote administration of Load Balancer.
_ Site Selector can run on the same machine as a server that you are load balancing with no additional configuration steps required.
_ High availability is inherently available through Domain Name System (DNS) methodologies using multiple redundant Site Selectors, assuming correct configuration of the parent name server and normal DNS recovery methods are in place. Examples of normal DNS recovery methods are: retransmission of queries and retrying zone transfers.
_ To remove single point of failure limitations in your network using Dispatcher in a two-tier configuration with Site Selector, see How about high availability?.
_ To ensure that the client uses the same server for multiple name server requests, see How affinity feature for Load Balancer works.
_ To ensure client to server affinity using the standard DNS method of setting the Time To Live (TTL), see TTL considerations.
To direct client requests to different sets of servers for domain name resolution, you can add "rules" to your Site Selector configuration. For more information, see Configure rules-based load balancing.
_ To direct clients to different sets of servers based on client source IP address, see Using rules based on the client IP address.
_ To direct clients to different sets of servers based on time of day, see Using rules based on the time of day.
_ To direct clients to different sets of servers based on the metric load values of the server set, see:
_ To direct overflow traffic to a default set of servers (for example, server(s) that will respond "site busy"), see Using rules that are always true.
Site Selector can run in both a local area network (LAN) or a wide area network (WAN).
In a WAN environment:
_ To load balance client name server requests using a weighted round-robin selection method, no additional configuration steps are required.
_ To consider the network proximity of the client name server to the servers providing the application requested (the destination servers), see Using the Network Proximity feature.
_ To generate alerts when servers are marked up or down, see Using scripts to generate an alert or record server failure.
Cisco CSS Controller enhances the Cisco switches' server load-balancing capabilities with greater application and system awareness. The controller uses more application sensitive and system sensitive metrics to calculate server weights dynamically. The weights are provided to the switch using SNMP. The switch uses the weights when processing client requests resulting in server load optimization and improved fault tolerance.
To optimize balancing the load across servers and ensure that the "right" server is chosen, see:
_ Optimizing the load balancing provided by Load Balancer
_ Advisors and Create custom (customizable) advisors
_ To run Load Balancer configuration from a separate machine from the one on which the Load Balancer resides, see Remote administration of Load Balancer.
_ Cisco CSS Controller can run on the same machine as a server that you are load balancing with no additional configuration steps required.
_ To remove single point of failure limitations in your network, both the Cisco CSS Switch and the Cisco CSS Controller have high availability capabilities. For the switch, high availability capabilities are possible using the CSS redundancy protocol. For the the Cisco CSS Controller, a proprietary protocol is used that allows the hot-standby configuration of two controllers.
For more information about configuring high availability, see High availability.
_ To analyze server traffic, see Using binary logging to analyze server statistics.
_ To generate alerts when servers are marked up or down, see Using scripts to generate an alert or record server failure.
Nortel Alteon Controller enhances the Nortel Alteon switches' server load-balancing capabilities with greater application and system awareness. The controller uses more application sensitive and system sensitive metrics to calculate server weights dynamically. The weights are provided to the switch using SNMP. The switch uses the weights when processing client requests resulting in server load optimization and improved fault tolerance.
To optimize balancing the load across servers and ensure that the "right" server is chosen, see:
_ Optimizing the load balancing provided by Load Balancer
_ Advisors and Create custom (customizable) advisors
_ To run Load Balancer configuration from a separate machine from the one on which the Load Balancer resides, see Remote administration of Load Balancer.
_ Nortel Alteon Controller can run on the same machine as a server that you are load balancing with no additional configuration steps required.
_ To remove single point of failure limitations in your network, both the Nortel Alteon Web Switch and the Nortel Alteon Controller have high availability capabilities. For the switch, high availability is possible using redundancy protocol for connections to servers and for services. Nortel Alteon Controller provides high availability using a proprietary protocol that allows a hot-standby configuration of two controllers.
For more information about configuring high availability, see High availability.
_ To analyze server traffic, see Using binary logging to analyze server statistics.
_ To generate alerts when servers are marked up or down, see Using scripts to generate an alert or record server failure.
This chapter instructs you on Load Balancer installation using system packaging tools and requirements for all supported operating systems.
Depending on the Load Balancer installation, you will not always be provided the same number of packages that are listed within this chapter.
For Installation instructions using the product setup program, refer to the Concepts, Planning, and Installation for Edge Components document.
The Java 2 SDK automatically installs with Load Balancer on all platforms.
Tip: If you are migrating from a previous version of Load Balancer, or re-installing an operating system, prior to installation, you can save any of your previous configuration files or script files for Load Balancer.
For information on hardware and software requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
Table 1 lists the installp images for Load
Balancer.
Administration (with messages) | ibmlb.admin.rte ibmlb.msg.language.admin |
Base | ibmlb.base.rte |
Device Driver | ibmlb.lb.driver |
License | ibmlb.lb.license |
Load Balancer components (with messages) | ibmlb.component.rte ibmlb.msg.language.lb |
Documentation (with messages) | ibmlb.doc.rte ibmlb.msg.language.doc |
Metric Server | ibmlb.ms.rte |
Where component can be: disp (Dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller), or nal (Nortel Alteon Controller). Optionally select which component(s) you want to install.
Where language can be:
If you have an earlier version installed, you should uninstall that copy before installing the current version. First, ensure that all the executors and all the servers are stopped. Then, to uninstall the entire product, enter installp -u ibmlb (or previous name, for example, intnd). To uninstall specific filesets, list them specifically instead of specifying the package name.
When you install the product, you are given the option of installing any or all of the following:
Follow these steps to install Load Balancer 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 Load Balancer packages for AIX:
Administration (with messages) | installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin |
Base | installp -acXgd device ibmlb.base.rte |
Device Driver | installp -acXgd device ibmlb.lb.driver |
License | installp -acXgd device ibmlb.lb.license |
Load Balancer components (with msgs). Includes: Dispatcher, CBR, Site Selector, Cisco CSS Controller, and Nortel Alteon Controller | installp -acXgd device ibmlb.component.rte ibmlb.msg.language.lb |
Documents (with messages) | installp -acXgd device ibmlb.doc.rte ibmlb.msg.language.lb |
Metric Server | installp -acXgd device ibmlb.ms.rte |
where device is:
Ensure that the result column in the summary contains SUCCESS for each part of Load Balancer that you are installing (APPLYing). Do not continue until all of the parts you want to install are successfully applied.
installp -ld device
where device is:
To unmount the CD, type:
unmount /cdrom
lslpp -h | grep ibmlb
If you installed the full product, this command returns the following:
ibmlb.admin.rte ibmlb.base.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.language.admin.rte ibmlb.msg.language.doc ibmlb.msg.language.lb.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.<component>.rte
Load Balancer install paths include the following:
For remote administration of Load Balancer, using Remote Method Invocation (RMI), you will need to install the administration, base, component, and license packages on the client. For information on RMI, see Remote Method Invocation (RMI).
For information on hardware and software requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
This section explains how to install Load Balancer on HP-UX using the product CD.
Before beginning the installation procedure, ensure that you have root authority to install the software.
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 Load Balancer see Instructions for uninstalling the packages.
Table 3 lists the names of the installation packages for Load
Balancer and the required order to install the packages using the
system's package installation tool.
Table 3. HP-UX package installation details for Load Balancer
Package description | HP-UX package name |
Base | ibmlb.base |
Administration | ibmlb.admin |
Load Balancer License | ibmlb.lic |
Load Balancer components | ibmlb.component |
Documentation | ibmlb.lang |
Metric Server | ibmlb.ms |
Notes:
|
The following procedure details the steps necessary to complete this task.
su - root Password: password
Issue the install command
swinstall -s source/ package_name
where source is the absolute directory path for the location of the package, and package_name is the name of the package.
For example, the following installs the base package for Load Balancer (ibmlb.base), if you are installing from the root of the CD
swinstall -s lb/ ibmlb.base
Issue swlist command to list all the packages that you have installed. For example,
swlist -l fileset ibmlb
Use the swremove command to uninstall the packages. The packages should be removed in the reverse order they were installed. For example, issue the following:
swremove ibmlb
To uninstall an individual package (for example the Dispatcher component)
swremove ibmlb.disp
For on hardware and software requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
This section explains how to install Load Balancer on Linux using the product CD.
Before beginning the installation procedure, ensure that you have root authority to install the software.
If you have an earlier version installed, you should uninstall that copy before installing the current version. First, ensure that all the executors and all the servers 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 Load Balancer:
The installation image is a file in the format eLBLX-version:tar.z.
The following is a list of the RPM installable packages.
Where --
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.
rpm -i --nodeps package.rpm
rpm -qa | grep ibmlb
Installing the full product should produce a listing like the following:
For remote administration of Load Balancer, using Remote Method Invocation (RMI), you will need to install the administration, base, component, and license packages on the client. For information on RMI, see Remote Method Invocation (RMI).
For information on hardware and software requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
This section explains how to install Load Balancer on Solaris using the product CD.
Before beginning the installation procedure, ensure that you have root authority to install the software.
If you have an earlier version installed, you should uninstall that copy before installing the current version. First, ensure that you have stopped all the executors and the servers. Then, to uninstall Load Balancer enter pkgrm pkgname.
To install Load Balancer:
At the command prompt, enter pkgadd -d pathname, where 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:
Where the variable lang refers to the substitution of one of the following language-specific codes: deDE, esES, frFR, itIT, jaJP, koKR, ptBR, zhCN, zhTW. For English, the variable lang refers to the substitution of doc.
If you want to install all of the packages, simply type "all" and press return. If you want to install some of the components, enter the name(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 package, ibmlbadm. This common package must be installed along with any of the other packages.
For example, if you want to install just the Dispatcher component with the documentation and Metric Server, you must install: ibmlbadm, ibmlbbase, ibmlblic, ibmdisp, ibmlbms, and ibmlbdoc.
For remote administration of Load Balancer, using Remote Method Invocation (RMI), you will need to install the administration, base, component, and license packages on the client. For information on RMI, see Remote Method Invocation (RMI).
The Load Balancer components reside in /opt/ibm/edge/lb/servers install directory.
For information on hardware and software requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
This section explains how to install Load Balancer on Windows using the product CD.
You will be given a choice of packages to install.
They are:
For remote administration of Load Balancer, using Remote Method Invocation (RMI), you will need to install the administration, base, component, and license packages on the client. For information on RMI, see Remote Method Invocation (RMI).
Restrictions: The Windows version of Load Balancer cannot be installed on the same machine with IBM Firewall.
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 Load Balancer:
E:\setup
Load Balancer install paths include the following:
This part provides information on a quick start configuration, planning considerations, and describes the methods of configuring Load Balancer's Dispatcher component. It contains the following chapters:
This quick-start example shows how to configure three locally-attached workstations using the Dispatcher component's mac forwarding method 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.
IMPORTANT: If you are using Load Balancer for IPv6, see also Deploying Dispatcher on Load Balancer for IPv6.
Figure 8. A simple local Dispatcher configuration
The mac forwarding method is the default forwarding method whereby Dispatcher load balances incoming requests to the server, and the server returns the response directly to the client. For more information on Dispatcher's MAC forwarding method, see Dispatcher's MAC-level routing (mac forwarding method).
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 two addresses: the nonforwarding address (NFA), and the cluster address (the address which will be load balanced) that you provide to clients to access your Web site.
Workstation | Name | IP Address |
---|---|---|
1 | server1.Intersplashx.com | 9.47.47.101 |
2 | server2.Intersplashx.com | 9.47.47.102 |
3 | server3.Intersplashx.com | 9.47.47.103 |
Netmask = 255.255.255.0 |
Each of the workstations contains only one standard Ethernet network interface card.
Name= www.Intersplashx.com IP=9.47.47.104
Add an alias for www.Intersplashx.com to the loopback interface on server2.Intersplashx.com and server3.Intersplashx.com.
ifconfig lo0 alias www.Intersplashx.com netmask 255.255.255.0
ifconfig lo0:1 plumb www.Intersplashx.com netmask 255.255.255.0 up
You have now completed all configuration steps that are required on the two Web server 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:
dscontrol executor start
dscontrol cluster add www.Intersplashx.com
dscontrol port add www.Intersplashx.com:80
dscontrol server add www.Intersplashx.com:80:server2.Intersplashx.com
dscontrol server add www.Intersplashx.com:80:server3.Intersplashx.com
dscontrol executor configure www.Intersplashx.com
dscontrol manager start
Dispatcher will now do load balancing based on server performance.
dscontrol advisor start http 80
Dispatcher will now make sure that client requests are not sent to a failed Web server.
Your basic configuration with locally attached servers is now complete.
Test to see if the configuration is working.
For information about using the Dispatcher GUI, see GUI and Appendix A, GUI: General instructions.
For information about using the configuration wizard, see Configuring using the configuration wizard.
There are many ways that you can configure Load Balancer 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, configure a port through which Load Balancer communicates. See Figure 9.
Figure 9. Example of Dispatcher configured with a single cluster and 2 ports
In this example for the Dispatcher component, one cluster is defined at www.productworks.com. 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) goes to a different server than a client requesting https://www.productworks.com (port 443).
Another way of configuring Load Balancer might 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 10.
Figure 10. Example of Dispatcher configured with two clusters, each with one port
In this example for the Dispatcher component, two clusters are defined: www.productworks.com for port 80 (HTTP) and www.testworks.com for port 443 (SSL).
A third way of configuring Load Balancer might 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 then define any ports to which you want to receive connections at that URL, as shown in Figure 11.
Figure 11. Example of Dispatcher configured with 2 clusters, each with 2 ports
In this example for the Dispatcher component, 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.
This chapter describes what the network planner should consider before installing and configuring the Dispatcher component.
This chapter includes the following sections:
IMPORTANT: If you are using Load Balancer for IPv6, see also Deploying Dispatcher on Load Balancer for IPv6.
Dispatcher consists of the following functions:
Using the manager is optional. However, if the manager is not used, load balancing is performed using weighted round-robin scheduling based on the current server weights, and advisors are not available.
Dispatcher also offers advisors that do not exchange protocol-specific information, such as the DB2(R) advisor that reports on the health of DB2 servers and the ping advisor that reports whether the server responds to a ping. For a complete list of advisors, see List of advisors.
You also have the option of writing your own advisors (see Create custom (customizable) advisors).
Using the advisors is optional but recommended.
The three key functions of Dispatcher (executor, manager, and advisors) interact to balance and dispatch the incoming requests between servers. Along with load balancing requests, the executor monitors the number of new connections, active connections, and connections in a finished state. The executor also does garbage collection of completed or reset connections and supplies this information to the manager.
The manager collects information from the executor, the advisors, and a system-monitoring program, such as Metric Server. Based on the information the manager receives, it adjusts how the server machines are weighted on each port and gives the executor the new weighting for use in its balancing of new connections.
The advisors monitor each server on the assigned port to determine the server's response time and availability and then give this information to the manager. The advisors also monitor whether a server is up or down. Without the manager and the advisors, the executor does round-robin scheduling based on the current server weights.
With Dispatcher, you can select one of three forwarding methods specified at the port level: MAC forwarding, NAT/NAPT forwarding, or CBR (content-based routing) forwarding.
Using Dispatcher's MAC forwarding method (the default forwarding method), Dispatcher load balances the incoming request to the selected server and the server returns the response directly to the client without any involvement of the Dispatcher. With this forwarding method, Dispatcher only looks at the inbound client-to-server flows. It does not need to see the outbound server-to-client flows. This significantly reduces its impact on the application and can result in improved network performance.
The forwarding method can be selected when adding a port using the dscontrol port add cluster:port method value command. The default forwarding method value is mac. You can specify the method parameter only when the port is added. Once you add the port, you cannot change the setting of the forwarding method. See dscontrol port -- configure ports for more information.
Linux limitation: Linux employs a host-based model of advertising hardware addresses to IP addresses using ARP. This model is incompatible with the back-end server or the high availability collocation server requirements for Load Balancer's mac forwarding method. See Linux loopback aliasing alternatives when using Load Balancer's mac forwarding, which describes a number of solutions to alter the Linux system's behavior to make it compatible with Load Balancer's mac forwarding.
Using Dispatcher's Network Address Translation (NAT) or Network Address Port Translation (NAPT) capability removes the limitation for load-balanced servers to be located on a locally attached network. When you want to have servers located at remote locations, you can use the NAT forwarding method technique rather than using a GRE/WAN encapsulation technique. You can also use the NAPT feature to access multiple server daemons residing on each load-balanced server machine, where each daemon listens on a unique port.
You can configure a server with multiple daemons in two different ways:
This application works well with upper-level application protocols such as HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, etc.
Limitations:
You will need three IP addresses for the Dispatcher machine - nfa, cluster, and return address. To implement NAT/NAPT, do the following (see also Sample steps for configuring Dispatcher's nat or cbr forwarding methods):
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
This maps the client request's destination port number (which is for Dispatcher) to the server's port number that Dispatcher uses to load balance the client's request. Mapport allows Load Balancer to receive a client's request on one port and to transmit it to a different port on the server machine. With mapport you can load balance a client's requests to a server machine that might have multiple server daemons running. The default for mapport is the client request's destination port number.
The return address is a unique address or host name that you configure on the Dispatcher machine. Dispatcher uses the return address as its source address when load balancing the client's request to the server. This ensures that the server returns the packet to the Dispatcher machine rather than sending the packet directly to the client. (Dispatcher will then forward the IP packet to the client.) You must specify the return address value when adding the server. You cannot modify the return address unless you remove the server and then add it again. The return address cannot be the same as the cluster, server, or NFA address.
The address of the router to the remote server. If this is a locally-attached server, enter the server address.
The Dispatcher component allows you to perform content-based routing for HTTP (using the "content" type rule) and HTTPS (using SSL session ID affinity) without having to use Caching Proxy. For HTTP and HTTPS traffic, the Dispatcher component's cbr forwarding method can provide faster content-based routing than the CBR component, which requires Caching Proxy.
For HTTP: Server selection for Dispatcher's content-based routing is based upon the contents of a URL or an HTTP header. It is configured using the "content" type rule. When configuring the content rule, specify the search string "pattern" and a set of servers to the rule. When processing a new incoming request, this rule compares the specified string with the client's URL or with the specified HTTP header in the client request.
If Dispatcher finds the string in the client request, Dispatcher forwards the request to one of the servers within the rule. Dispatcher then relays the response data from the server to the client ("cbr" forwarding method).
If Dispatcher does not find the string in the client request, Dispatcher does not select a server from the set of servers within the rule.
For HTTPS (SSL): Dispatcher's content-based routing load balances based on the SSL ID session field of the client request. With SSL, a client request contains the SSL session ID of a prior session, and servers maintain a cache of their prior SSL connections. Dispatcher's SSL ID session affinity allows the client and server to establish a new connection using the security parameters of the previous connection with the server. By eliminating the renegotiation of SSL security parameters, such as shared keys and encryption algorithms, the servers save CPU cycles and the client gets a quicker response. In order to enable SSL session ID affinity: the protocol type specified for the port must be SSL and port stickytime must be set to a nonzero value. When stickytime has been exceeded, the client may be sent to a different server from the previous.
You will need three IP addresses for the Dispatcher machine - nfa, cluster, and return address. To implement Dispatcher's content-based routing (see also Sample steps for configuring Dispatcher's nat or cbr forwarding methods):
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern pattern
Where pattern specifies the pattern to be used for the content type rule. For more information on the content rule type, see Using rules based on the request content. For more information on valid expressions for pattern, see Appendix B, Content rule (pattern) syntax.
Figure 12. Example for using Dispatcher's nat or cbr forwarding methods
You will need at least three IP addresses for the Dispatcher machine. For Figure 12, the following are the necessary steps to minimally configure Dispatcher's nat or cbr forwarding methods:
1.Start the executor dscontrol executor start 2.Define the client gateway dscontrol executor set clientgateway 1.2.3.5 NOTE: If your subnet does not have a local router, then you must configure a machine to do IP forwarding and use that as the clientgateway. Consult your operating system documentation to determine how to enable IP forwarding. 3.Define the cluster address dscontrol cluster add 1.2.3.44 4.Configure the cluster address dscontrol executor configure 1.2.3.44 5.Define the port with a method of nat or cbr dscontrol port add 1.2.3.44:80 method nat or dscontrol port add 1.2.3.44:80 method cbr protocol http 6.Configure an alias return address on Load Balancer (using ethernet card 0) NOTE: On Linux, you do not need to alias the return address if using nat forwarding on a collocated machine. dscontrol executor configure 10.10.10.99 or use the ifconfig command (for Linux or UNIX only): AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up 7.Define the backend servers dscontrol server add 1.2.3.4:80:192.10.10.10 router 10.10.10.6 returnaddress 10.10.10.99
The client gateway (1.2.3.5) is the router 1 address between Load Balancer and the client. The router (10.10.10.6) is the router 2 address between Load Balancer and the backend server. If you are unsure of the clientgateway or router 2 address, you can use a traceroute program with the client (or server) address to determine the router address. The exact syntax of this program will differ based on the operating system you are using. You should consult your operating system documentation for more information regarding this program.
If the server is on the same subnet as Load Balancer (that is, no routers are returned using traceroute) type the server address as the router address. The router address is the address used in the "server add" command on the Load Balancer machine in step 7.
With server partitioning, you can further distinguish between particular URLs and their specific applications. For example, one Web server can serve JSP pages, HTML pages, GIF files, database requests, and so on. Load Balancer now provides the ability to partition one cluster and port specific server into several logical servers. This allows you to advise on a particular service on the machine to detect if a servlet engine or a database request is running faster, or not running at all.
Server partitioning allows Load Balancer to detect, for example, that the HTML service is serving pages rapidly, but the database connection has gone down. This allows you to distribute load based on more granular service-specific workload, rather than server-wide weighting alone.
Server partitioning can be useful when used in conjunction with the HTTP and HTTPS advisors. For example, when you have an HTML server that handles HTML, GIF, and JSP pages, if you define (by adding) the server once under port 80, you receive just one load value for the whole HTTP server. This might be misleading since it is possible that the GIF service might not be functioning on the server. Dispatcher still forwards GIF pages to the server, but the client sees a timeout or a failure.
If you define the server three times (for example, ServerHTML, ServerGIF, ServerJSP) under the port and define the server advisorrequest parameter with a different string for each logical server, then you can query the health of the particular service on the server. ServerHTML, ServerGIF and ServerJSP represent three logical servers that have been partitioned from one physical server. For ServerJSP, you can define the advisorrequest string to query the service on the machine that handles JSP pages. For ServerGIF, you can define the advisorrequest string to query the GIF service. And for ServerHTML, you define the advisorrequest to query the HTML service. So, if the client gets no response from the advisorrequest to query the GIF service, Dispatcher will mark that logical server (ServerGIF) as down, while the other two logical servers may be healthy. Dispatcher does not forward any more GIFs to the physical server, but it can still send JSP and HTML requests to the server.
For more information on the advisorrequest parameter, see Configuring the HTTP or HTTPS advisor using the request/response (URL) option.
Within the Dispatcher configuration, you can represent a physical server or a logical server using the cluster:port:server hierarchy. The server can be a unique IP address of the machine (physical server) in either a symbolic name or IP address format. Or, if you define the server to represent a partitioned server, then you must provide a resolvable server address for the physical server on the address parameter of the dscontrol server add command. See dscontrol server -- configure servers for more information.
Following is an example of partitioning physical servers into logical servers to handle different types of requests.
Cluster: 1.1.1.1 Port: 80 Server: A (IP address 1.1.1.2) HTML server Server: B (IP address 1.1.1.2) GIF server Server: C (IP address 1.1.1.3) HTML server Server: D (IP address 1.1.1.3) JSP server Server: E (IP address 1.1.1.4) GIF server Server: F (IP address 1.1.1.4) JSP server Rule1: /*.htm Server: A Server: C Rule2: /*.jsp Server: D Server: F Rule3: /*.gif Server: B Server: E
In this example, server 1.1.1.2 is partitioned into 2 logical servers: "A" (handling HTML requests) and "B" (handling GIF requests). Server 1.1.1.3 is partitioned into 2 logical servers: "C" (handling HTML requests) and "D" (handling JSP requests). Server 1.1.1.4 is partitioned into 2 logical servers: "E" (handling GIF requests) and "F" (handling JSP requests).
Figure 13. 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 does in a single Dispatcher configuration. The second Dispatcher machine monitors the "health" of the first, and takes over the task of load balancing if it detects that the first Dispatcher machine has failed.
Each of the two machines is assigned a specific role, either primary or backup. The primary machine sends connection data to the backup machine on an ongoing basis. While the primary is active (load balancing), the backup is in a standby state, continually updated and ready to take over, if necessary.
The communication sessions between the two machines are referred to as heartbeats. The heartbeats allow each machine to monitor the health of the other.
If the backup machine detects that the active machine has failed, it will take over and begin load balancing. At that point the statuses of the two machines are reversed: the backup machine becomes active and the primary becomes standby.
In the high availability configuration, both primary and backup machines must be on the same subnet with identical configuration.
For information about configuring high availability, see High availability.
Figure 14. 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 14. Each Dispatcher can actively route packets for its primary cluster. If either Dispatcher were to fail and could no longer actively route packets for its primary cluster, then the other Dispatcher could take over routing packets for its backup cluster.
For information about configuring high availability and mutual high availability, see High availability.
Before following the steps in this chapter, see Planning for Dispatcher. This chapter explains how to create a basic configuration for the Dispatcher component of Load Balancer.
IMPORTANT: If you are using Load Balancer for IPv6, see Deploying Dispatcher on Load Balancer for IPv6.
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 command parameter values must be entered in English characters. The only exceptions are host names (used in cluster, server, and highavailability commands) and file names (used in file commands).
To start the Dispatcher from the command line:
You can use a minimized version of the dscontrol command parameters by typing the unique letters of the parameters. For example, to get help on the file save command, you can type dscontrol he f instead of dscontrol help file.
To start up the command line interface: issue dscontrol to receive an dscontrol command prompt.
To end the command line interface: issue exit or quit.
The commands for configuring the Dispatcher can be entered into a configuration script file and executed together. See Sample Load Balancer configuration files.
dscontrol file appendload myscript
dscontrol file newload myscript
To save the current configuration into a script file (for example, savescript), run the following command:
dscontrol file save savescript
This command will save the configuration script file in the ...ibm/edge/lb/servers/configurations/dispatcher directory.
For general instructions and an example of the graphical user interface (GUI), see Figure 41.
To start the GUI, follow these steps
dsserver
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 ports and servers, and start advisors for the manager.
The GUI can be used to do anything that you would do with the dscontrol command. For example, to define a cluster using the command line, you would enter dscontrol cluster add cluster command. To define a cluster from the GUI, right-click Executor, then in the pop-up menu, left-click 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(for completely replacing the current configuration) and Append to Current Configuration (for updating the 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 Load Balancer components.
The configuration commands can also be run remotely. For more information, see Remote Method Invocation (RMI).
In order to execute a command from the GUI: highlight the Host node from the GUI tree and select Send command.... from the Host pop-up menu. In the command entry field, type the command that you want to execute, for example: executor report. The results and history of the commands run in the current session and appear in the window provided.
You can access Help by clicking the question mark icon in the upper right hand corner of the Load Balancer window.
For more information about using the GUI, see Appendix A, GUI: General instructions.
If you are using the configuration wizard, follow these steps:
dsserver
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.
Before setting up the Dispatcher machine, you must be the root user (for AIX, HP-UX, Linux, or Solaris) or the Administrator on Windows.
On all supported platforms, the Load Balancer can have a collocated server. This means that the Load Balancer can physically reside on a server machine which it is load balancing.
For the Dispatcher machine, when using the mac forwarding method, you will need at least two valid IP addresses. For cbr or nat forwarding method, you will need at least three valid IP addresses:
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.
Dispatcher uses the return address as its source address when load balancing the client's request to the server. This ensures that the server returns the packet to the Dispatcher machine rather than sending the packet directly to the client. (Dispatcher will then forward the IP packet to the client.) You must specify the return address value when adding the server. You cannot modify the return address unless you remove the server and then add it again.
Solaris Only:
For example, if you plan to use two 100Mbps Ethernet adapters, the ibmlb.conf file should have a single line specifying the eri device. If you plan to use one 10Mbps Ethernet adapter and one 100Mbps Ethernet adapter, you will have two lines in the ibmlb.conf file: one line specifying the le device and one line specifying the eri device.
The ibmlb.conf file provides input to the Solaris autopush command and must be compatible with the autopush command.
For example, if clusters X and Y are configured for use by the CBR component on any of the adapters listed in ibmlb.conf, clusters X and Y are unconfigured when the dscontrol executor start or dscontrol executor stop commands are issued. This may not be the desired result. When clusters X and Y are configured in the goAliases script, the clusters are automatically reconfigured after the Dispatcher executor starts or stops.
Windows only: Ensure that IP forwarding is not enabled for the TCP/IP protocol. (See your Windows TCP/IP configuration.)
Figure 15 shows an example of Dispatcher set up with a single cluster, two ports, and three servers.
Figure 15. Example of the IP addresses needed for the Dispatcher machine
For help with commands used in this procedure, see Command reference for Dispatcher and CBR.
For a sample configuration file, see Sample Load Balancer configuration files.
AIX, HP-UX, Linux, or Solaris: To start the server function, type dsserver.
Windows: The server function starts automatically as a service.
To start the executor function, enter the dscontrol executor start command. You may also change various executor settings at this time. See 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 dscontrol executor set nfa IP_address command or edit the sample configuration file. IP_address is either the symbolic name or the IP address.
Dispatcher will balance the requests sent to the cluster address to the 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 dscontrol cluster add. To set cluster options, issue the command dscontrol 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, and Use wildcard cluster with Caching Proxy 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 dscontrol executor 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 operating system's adapter configuration command for the cluster address, using the adapter found and the netmask for the existing address found on that adapter. For example:
dscontrol executor 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 executor 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 executor configure command and explicitly provide the interface name and netmask. Use dscontrol executor configure cluster_address interface_name netmask.
Some examples are:
dscontrol executor configure 204.67.172.72 en0 255.255.0.0 (AIX) dscontrol executor configure 204.67.172.72 eth0:1 255.255.0.0 (Linux) dscontrol executor configure 204.67.172.72 eri0 255.255.0.0 (Solaris) dscontrol executor configure 204.67.172.72 en1 255.255.0.0 (Windows)
In order to use the second form of the executor 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 the executor configure command map to the interface types. For example, the first Ethernet interface in the list is assigned 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.
After you obtain this mapping information, you can create an alias on the network interface to the cluster address.
On Linux or UNIX(R), the executor configure command runs ifconfig commands, so you can still use the ifconfig commands.
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 Load Balancer machine. For example:
arp -s <cluster> <Load Balancer MAC address> pub
To define a port, enter the dscontrol port add cluster:port command, edit the sample configuration file, or use the GUI. Cluster is either the symbolic name or the IP address. Port is the number of the port you are using for that protocol. You may also change various port settings at this time. You must define and configure all servers for a port. See Command reference for Dispatcher and CBR.
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. 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. See Use wildcard port to direct unconfigured port traffic for more information about when you might want to use a wildcard port.
To define a load-balanced server machine, enter the dscontrol 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 IP 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.
Bind-specific servers: If the Dispatcher component is load balancing to bind-specific servers, then the servers must be configured to bind to the cluster address. Since the Dispatcher forwards packets without changing the destination IP address, when the packets reach the server, the packets will still contain the cluster address as the destination. If a server has been configured to bind to an IP address other than the cluster address, then the server will be unable to accept packets/requests destined for the cluster.
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 multiple IP addresses. For the Dispatcher component, the collocated server machine must be defined as collocated using the dscontrol server command. For more information on collocated servers, see Using collocated servers.
For more information on dscontrol server command syntax, see dscontrol server -- configure servers.
The manager function improves load balancing. To start the manager, enter the dscontrol 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. An advisor is specific to a protocol. For example, to start the HTTP advisor, issue the following command:
dscontrol advisor start http portFor a list of advisors along with their default ports, see Command reference for Dispatcher and CBR. For a description of each advisor, see List of advisors.
If you start advisors, you may modify the proportion of importance given to advisor information being included in the load balancing decisions. To set the cluster proportions, issue the dscontrol cluster set cluster proportions command. For more information, see Proportion of importance given to status information.
Perform the following steps if one of these conditions is true:
Notes:
When using mac forwarding method, Dispatcher will only load balance across servers that allow the loopback adapter to be configured with an additional IP address, for which the backend server will never respond to ARP (address resolution protocol) requests. 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. When using the mac forwarding method, 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, HP-UX, Linux, Solaris, or Windows), 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.
IMPORTANT: For Linux, see Linux loopback aliasing alternatives when using Load Balancer's mac forwarding.
If you have a server with an operating system that does not support aliases 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
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 "Active Routes" example table for Step 2, 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 | route delete network_address cluster_address (at an
MS-DOS prompt)
|
Using the example shown in Figure 15, 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
To verify if a backend server is properly configured, perform the following steps from a different machine on the same subnet when the Load Balancer is not running and cluster is unconfigured:
arp -d cluster
ping cluster
There should be no response. If there is a response to the ping, ensure that you did not ifconfig the cluster address to the interface. Ensure that no machine has a published arp entry to the cluster address.
arp -a
In the output from the command, you should see the MAC address of your server. Issue the command:
arp -s cluster server_mac_address
arp -d cluster
Some versions of Linux issue ARP responses for any IP address configured on the machine on any interface present on the machine. It may also choose an ARP source IP address for ARP who-has queries based on all IP addresses present on the machine, regardless of the interfaces on which those addresses are configured. This causes all cluster traffic to be directed to a single server in an indeterminate manner.
When using Dispatcher's mac forwarding method, a mechanism must be employed to ensure that cluster-addressed traffic can be accepted by the stacks of the back-end servers, including the collocated high availability standby machine, when both high availability and collocation are in use.
In most cases, you must alias the cluster address on the loopback; therefore, back-end servers must have the cluster aliased on the loopback, and if you use high availability and collocation, the standby load-balancing servers must have clusters aliased on the loopback.
To ensure that Linux does not advertise addresses on the loopback, you can use any one of the following four solutions to make Linux compatible with Dispatcher's mac forwarding.
# sysctl -w net.ipv4.conf.all.hidden=1 net.ipv4.conf.lo.hidden=1Clusters can then be aliased in the normal way, such as:
# ifconfig lo:1 $CLUSTER_ADDRESS netmask 255.255.255.255 up
# sysctl -w net.ipv4.conf.all.arp_ignore=3 net.ipv4.conf.all.arp_announce=2Clusters must then be aliased with the following command:
# ip addr add $CLUSTER_ADDRESS/32 scope host dev loA similar command must be in the go* scripts in high availability collocation configurations.
# iptables -t nat -A PREROUTING -d $CLUSTER_ADDRESS -j REDIRECTThis causes Linux to do destination NAT on each packet, converting the cluster address to the interface address. This method has about a 6.4% connections-per-second throughput penalty. This method works on any supported stock distribution; no kernel module or kernel patch+build+install is needed.
# modprobe noarp # noarpctl add $CLUSTER_ADDRESS nic-primary-addrwhere nic-primary-addr is an address in the same subnet as the cluster address. Clusters can then be aliased in the normal way, such as:
# ifconfig lo:1 cluster address netmask 255.255.255.255 up
Support for the extended IP addressing scheme of IPv6 is available with Load Balancer for IPv6. Load Balancer for IPv6 is a separate installation image consisting of only the Dispatcher component. This installation type provides load balancing for both IPv4 and IPv6 traffic to servers configured within your network using Dispatcher's MAC-based packet forwarding.
It is important to note that with the Load Balancer for IPv6 installation, the syntax for the Dispatcher command (dscontrol) is identical with one exception. The delimiter for dscontrol commands is an at symbol (@), instead of a colon (:), when using Load Balancer for IPv6. When referencing commands throughout other chapters of this document, remember to substitute (@) for (:) as the delimiter within dscontrol commands.
For general information about the Dispatcher component, refer to the following chapters:
This chapter describes configuration differences and limitations for Dispatcher on the Load Balancer for IPv6 installation of this product and includes the following sections:
Load Balancer for IPv6 installations are available for all supported platforms with the exception of Windows 2000.
For information on hardware and software system requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
On Load Balancer for IPv6, the installation steps and package names are the same as the installation steps and package names for Load Balancer that supports only IPv4 server addresses. However, there are fewer Load Balancer component packages provided, because only the Dispatcher component is available.
On AIX systems, for example, the following Load Balancer for IPv6 packages are provided:
If installing from a CD, a license package is also provided.
It is important to note that any previous Load Balancer must be uninstalled, before installing Load Balancer for IPv6. Two Load Balancers cannot be installed on the same machine.
For product installation instructions, see Installing Load Balancer.
On Load Balancer for IPv6 installations, the Dispatcher component offers many, but not all, of the functions available with the Dispatcher component on Load Balancer installations that support only IPv4 server addressing schemes. The following topics discuss the special configuration differences and functional limitations for Dispatcher provided with Load Balancer for IPv6.
When configuring Load Balancer for IPv6, all servers must be homogeneous within the cluster. For example, if Cluster1 is defined with an IPv4 address, then all the servers under Cluster1 must be IPv4. If Cluster2 is defined with an IPv6 address, then all the servers defined under Cluster2 must be IPv6. In addition, the protocol that is used by the client to send IP packets needs to match the cluster IP format.
Supporting a mixed IPv4 and IPv6 client environment requires that for each logical cluster definition, two actual cluster definitions must be defined - an IPv4 cluster and an IPv6 cluster. Clients sending IPv4 packets are routed by Load Balancer to the logical cluster using IPv4 addresses configured for the cluster. Clients sending IPv6 packets are routed by Load Balancer to the logical cluster using IPv6 addresses configured for the cluster.
Many of the Dispatcher features described in Planning for Dispatcher and the Dispatcher features described in Advanced features for Dispatcher, CBR, and Site Selector are available on Load Balancer for IPv6.
The following list is a summary of the Dispatcher features that are not supported on Load Balancer for IPv6:
See Dispatcher component features for a high-level description of Dispatcher features that are available for managing your network.
On Load Balancer for IPv6 installations, configuring for a high availablity Dispatcher machine is supported with the following limitations or special considerations:
For more information on the high availability feature, see High availability.
On Windows systems, collocation is not supported: Collocation is a configuration in which Load Balancer can reside on the same machine as a server for which it is load balancing requests. When using Load Balancer for IPv6 installations, the collocation feature is available on all supported operating systems except on Windows systems.
For more information on collocating servers, see Using collocated servers.
On Windows systems: If you are using IPv6 protocol on your machine and want to use advisors, you must modify the protocol file that resides in the C:\windows\system32\drivers\etc\ directory.
For IPv6, insert the following line in the protocol file:
ipv6-icmp 58 IPv6-ICMP # IPv6 interface control message protocol
For more information on advisors, see Advisors.
On Windows systems: For Load Balancer for IPv6, in order to run Metric Server, you must edit the metricserver.cmd file as follows:
start /min /wait %IBMLBPATH%\java\jre\bin\java -Djava.rmi.server.hostname="hostname" -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Stack=true -Xrs -cp %LB_CLASSPATH% com.ibm.internet.nd.sma.SMA_Agent %RMI_PORT% %LOG_LEVEL% %LOG_SIZE% %LOG_DIRECTORY% %KEYS_DIRECTORY% %SCRIPT_DIRECTORY% goto done :stop %IBMLBPATH%\java\jre\bin\java -Djava.rmi.server.hostname="hostname" -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Stack=true -cp %LB_CLASSPATH% com.ibm.internet.nd.sma.SMA_AgentStop %RMI_PORT% :done
For more information, see Metric Server.
On AIX, Linux, and Windows systems: Prior to starting the executor (dscontrol executor start), the following must be issued from the command line as root,
These commands enable processing of IPv6 packets in the respective operating systems. It is necessary to issue the command only once. Thereafter, you can start and stop the executor as often as you need.
If you do not issue the command to enable processing of IPv6 packets on these systems, the executor does not start.
On HP-UX and Linux systems: Using the ifconfig command, IPv6 addresses must be plumbed and an interface configured in order for Dispatcher to inspect IPv6 packets. Prior to starting the executor (dscontrol executor start), issue the following from the command line as root,
ifconfig device inet6 up
ifconfig device inet6 plumb ifconfig device inet6 address/prefix up
If you do not issue these commands, the executor will start, but no IPv6 packets can be viewed.
To configure the cluster address on a network interface card (NIC) of the Dispatcher machine, you can issue the command dscontrol executor configure cluster_address. The dscontrol executor configure command runs the operating system's adapter configure comands (for example, ifconfig, dsconfig (IPv6 only), or ip commands). Alternatively, to alias the NIC of the Dispatcher machine you can choose to issue the operating system's adapter configure commands directly, instead of using the executor configure command.
To alias the loopback (lo0) device on servers that are being load-balanced, you must use the operating system's adapter configure commands.
For the Load Balancer for IPv6 installation, the following commands can be used to alias the network interface and the loopback device (interface_name).
On AIX (5.x) systems,
ifconfig interface_name inet6 cluster_address/prefix_length alias
For example, to alias the loopback device on servers that are being load-balanced:
ifconfig lo0 inet6 2002:4a::541:56/128 alias
On HP-UX systems:
ifconfig interface_name:alias inet6 cluster_address up prefix prefix_length
For example, to alias the loopback device on servers that are being load-balanced:
ifconfig lo0:1 inet6 3ffe:34::24:45 up prefix 128
On Linux systems:
ip -version addr add cluster_address/prefix_length dev interface_name
For example, to alias the loopback device on servers that are being load-balanced:
ip -6 addr add 3ffe:34::24:45/128 dev lo0 ip -4 addr add 12.42.38.125/32 dev lo0
On Solaris 8, 9 and 10 systems:
ifconfig interface_name inet6 addif cluster_address/prefix_length up
For example, to alias the loopback device on servers that are being load-balanced:
ifconfig lo0 inet6 addif 3ffe:34::24:45/128 up
On Windows 2003 systems (Windows 2000 and Windows NT do not support IPv6):
dsconfig interface_name cluster_address prefix_length up
For example, to alias the loopback device on servers that are being load-balanced:
dsconfig lo0 3ffe:34::24:45 128 up
On OS/2 systems:
On OS/390 systems:
Because Load Balancer for IPv6 does not support all of the component features, valid dscontrol commands for this installation are a subset of the dscontrol commands for Load Balancer installations that support only IPv4. This section discusses command syntax differences and lists all supported dscontrol commands for the Dispatcher component on Load Balancer for IPv6.
With the Load Balancer for IPv6 installation, the syntax for the Dispatcher command (dscontrol) is identical with one important exception. The delimiter for dscontrol commands is an at symbol (@), instead of a colon (:), when using Load Balancer for IPv6.
It was necessary to define a delimiter other than a colon because the IPv6 format uses a colon within its addressing scheme.
The following illustrates the dscontrol command using an at (@) delimiter
dscontrol server add 30::100@80@30::200
dscontrol server add 192.4.40.30@80@192.4.20.35
IMPORTANT: When referencing commands throughout this document, remember to substitute (@) for (:) as the delimiter within dscontrol commands.
For detailed information and examples of the syntax for all dscontrol commands, see Command reference for Dispatcher and CBR.
The following is a summary of all supported commands for Dispatcher in the Load Balancer for IPv6 installation:
dscontrol executor configure interface_address interface_name prefix_lengthFor example:
dscontrol executor configure 2002:092a:8f7a:4226:9:37:240:99 en0 112
The following key values are the only valid values for the port and set arguments on the dscontrol port command:
The following key values are the only valid values for the add argument for the dscontrol server command:
The following key values are the only valid values for the set argument for the dscontrol server command:
The following commands are not available for Dispatcher in the Load Balancer for IPv6 installation:
This part provides information on a quick start configuration, planning considerations, and describes the methods of configuring Load Balancer's CBR component. It contains the following chapters:
This quick start example shows how to configure three locally-attached workstations using CBR along with Caching Proxy to load-balance Web traffic between two Web servers. (For simplicity, this example illustrates servers on the same LAN segment, however with CBR there is no restriction for using servers on the same LAN.)
Figure 16. A simple local CBR configuration
For the quick start example, you will need three workstations and four IP addresses. One workstation will be used as the CBR; the other two workstations will be used as Web servers. Each Web server requires one IP address. The CBR workstation requires one actual address, and one address to be load balanced.
To use CBR, Caching Proxy must be installed on the same server. To configure Caching Proxy for CBR, see Step 1. Configure Caching Proxy to use CBR.
Workstation | Name | IP Address |
---|---|---|
1 | server1.mywebsite.com | 9.27.27.101 |
2 | server2.mywebsite.com | 9.27.27.102 |
3 | server3.mywebsite.com | 9.27.27.103 |
Netmask = 255.255.255.0 |
Each of the workstations contains only one standard Ethernet network interface card.
Name= www.mywebsite.com IP=9.27.27.104
With CBR, you can create a configuration by using the command line, the configuration wizard, or the graphical user interface (GUI). For this quick start example, configuration steps are demonstrated using the command line.
From a command prompt, follow these steps:
cbrcontrol executor start
ibmproxy
cbrcontrol cluster add www.mywebsite.com
cbrcontrol port add www.mywebsite.com:80
cbrcontrol server add www.mywebsite.com:80:server2.mywebsite.com
cbrcontrol server add www.mywebsite.com:80:server3.mywebsite.com
cbrcontrol rule add www.mywebsite.com:80:memberRule type content pattern uri=*/member/*
cbrcontrol rule add www.mywebsite.com:80:guestRule type content pattern uri=*/guest/*
In this example, using the content rule, client requests to Web site www.mywebsite.com are sent to a different server based on a directory in their URI request path. See Appendix B, Content rule (pattern) syntax for more information.
cbrcontrol rule useserver www.mywebsite:80:memberRule server2.mywebsite.com
cbrcontrol rule useserver www.mywebsite:80:guestRule server3.mywebsite.com
CBR will now do load balancing based on content-based rule. A client with a URL request containing /member/ will be directed to server2.mywebsite.com. A client with a URL request containing /guest/ will be directed to server3.mywebsite.com.
cbrcontrol manager start
cbrcontrol advisor start http 80
CBR will now make sure that client requests are not sent to a failed Web server.
Your basic configuration with locally attached servers is now complete.
Test to see if the configuration is working.
cbrcontrol server report www.mywebsite.com:80:The total connections column of the two servers should add up to "2."
For information on using the CBR GUI, see GUI and see Appendix A, GUI: General instructions.
For information on using the CBR wizard, see Configuration wizard.
There are many ways that you can configure CBR 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 CBR communicates. See Figure 9.
Figure 17. Example of CBR configured with a single cluster and 2 ports
In this example for the CBR component, one cluster is defined at www.productworks.com. 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 CBR 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 10.
Figure 18. Example of CBR configured with two clusters, each with one port
In this example for the CBR component, two clusters are defined: www.productworks.com for port 80 (HTTP) and www.testworks.com for port 443 (SSL).
A third way of configuring CBR 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 then define any ports to which you want to receive connections at that URL, as shown in Figure 11.
Figure 19. Example of CBR configured with 2 clusters, each with 2 ports
In this example for the CBR component, two clusters are defined with port 80 (HTTP) and port 443 (SSL) for each of the sites at www.productworks.com and www.testworks.com.
This chapter describes what the network planner should consider before installing and configuring the CBR component with Caching Proxy.
This chapter includes the following section:
The CBR component allows you to load balance HTTP and SSL traffic using Caching Proxy to proxy the request. With CBR, you can load balance servers that you configure from your CBR configuration file using cbrcontrol commands.
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.
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 client 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.
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.
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.
Caching Proxy communicates with a CBR process through its plug-in interface. CBR must be running on the local machine for this to work. Because these are two separate processes, multiple instances of the Caching Proxy can be running and working with a single instance of CBR. This setup might be configured in order to segregate addresses or functionality between the Caching Proxies, or to improve the resource utilization of the machine by having several Caching Proxies handling client traffic. The proxy instances can be listening on different ports or binding to unique IP addresses on the same port, depending on what best suits the traffic requirements.
CBR along with Caching Proxy examines HTTP requests using specified rule types. When running, Caching Proxy 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 Caching Proxy 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 Caching Proxy. The easiest way to ensure that all requests 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 that have a lower-numbered priority. (Note: The lower-numbered priority rules are evaluated first.)
For more information see Configure rules-based load balancing.
CBR with Caching Proxy can receive SSL transmission from the client to the proxy (client-to-proxy side) as well as support transmission from the proxy to an SSL server (proxy-to-server side). By defining an SSL port on a server in the CBR configuration to receive the SSL request from the client, you have the ability to maintain a fully secure site, using CBR to load balance across secure (SSL) servers.
In addition to other ibmproxy.conf file changes for CBR, another configuration statement needs to be added to the ibmproxy.conf file for IBM Caching Proxy to enable SSL encryption on the proxy-to-server side. The format must be:
proxy uri_pattern url_pattern address
where uri_pattern is a pattern to match (for example: /secure/*), url_pattern is a replacement URL (for example: https://clusterA/secure/*), and address is the cluster address (for example: clusterA).
CBR with Caching Proxy can also receive SSL transmission from the client and then decrypt the SSL request before proxying the request to an HTTP server. For CBR to support client-to-proxy in SSL and proxy-to-server in HTTP, there is an optional keyword mapport on the cbrcontrol server command. Use this keyword when you need to indicate that the port on the server is different from the incoming port from the client. The following is an example of adding a port using the mapport keyword, where the client's port is 443 (SSL) and the server's port is 80 (HTTP):
cbrcontrol server add cluster:443 mapport 80
The port number for mapport can be any positive integer value. The default is the port number value of the incoming port from the client.
Since CBR must be able to advise on an HTTP request for a server configured on port 443 (SSL), a special advisor ssl2http is provided. This advisor starts on port 443 (the incoming port from the client) and advises on the server(s) configured for that port. If there are two clusters configured and each cluster has port 443 and servers configured with a different mapport, then a single instance of the advisor can open the appropriate port accordingly. The following is an example of this configuration:
Executor Cluster1 Port:443 Server1 mapport 80 Server2 mapport 8080 Cluster2 Port:443 Server3 mapport 80 Server4 mapport 8080 Manager Advisor ssl2http 443
Before following the steps in this chapter, see Planning for Content Based Routing. This chapter explains how to create a basic configuration for the CBR component of Load Balancer.
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 7. Define load balanced server machines |
To create a basic configuration for the CBR component of Load Balancer, there are four basic methods:
To use CBR, Caching Proxy must be installed.
This is the most direct means of configuring CBR. The command parameter values must be entered in English characters. The only exceptions are host names (used, for example, in cluster and server commands) and file names.
To start CBR from the command line:
You can enter an abbreviated version of the cbrcontrol 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 type cbrcontrol he f instead of cbrcontrol help file.
To start up the command line interface: issue cbrcontrol to receive a cbrcontrol command prompt.
To end the command line interface: issue exit or quit.
Notes:
( ) right and left parentheses
& ampersand
| vertical bar
! exclamation point
* asterisk
The operating system's shell may interpret these as special characters and convert them to alternate text before cbrcontrol evaluates them.
The special characters in the above list are optional characters on the cbrcontrol rule add command, and are used when specifying a pattern for a content rule. For example, the following command might be valid only when using the cbrcontrol>> prompt.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern client=181.0.153.222&uri=/nipoek/*
For this same command to work at the operating system's prompt, double quotation marks (" ") must be placed around the pattern as follows:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "client=181.0.153.222&uri=/nipoek/*"
If the quotation marks are not used, some of the pattern might be truncated when the rule is saved in CBR. Note that quotation marks are not supported when using the cbrcontrol>> command prompt.
The commands for configuring CBR can be entered into a configuration script file and executed together.
cbrcontrol file appendload myscript
cbrcontrol file newload myscript
To save the current configuration into a script file (for example, savescript), run the following command:
cbrcontrol file save savescript
This command will save the configuration script file in the ...ibm/edge/lb/servers/configurations/cbr directory.
For general instructions and an example of the graphical user interface (GUI), see Figure 41.
To start the GUI, follow these steps
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, right-click Executor, then in the pop-up menu, left-click 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 (for completely replacing the current configuration) and Append to Current Configuration (for updating the 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 Load Balancer components.
You can access Help by clicking the question mark icon in the upper right hand corner of the Load Balancer window.
In order to execute a command from the GUI: highlight the Host node from the GUI tree and select Send command... from the Host pop-up menu. In the command entry field, type the command that you want to execute, for example: executor report. The results and history of the commands run in the current session appear in the window provided.
For more information about using the GUI, see Appendix A, GUI: General instructions.
If you are using the configuration wizard, follow these steps:
Launch the wizard from the command prompt by issuing the cbrwizard. Or, select the Configuration Wizard from the CBR component menu as presented in the GUI.
For AIX, HP-UX, Linux, or Solaris: To start Caching Proxy, enter ibmproxy
For Windows: To start Caching Proxy, go to the Services panel: Start > Settings (for Windows 2000) > Control Panel > Administrative Tools > Services
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.
Before setting up the CBR machine, you must be the root user (for AIX, HP-UX, Linux, or Solaris) or the Administrator (for 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.
For Solaris only: Before using the CBR component, the system defaults for IPCs (Inter-process Communication) must be modified. The maximum size of a shared memory segment and the number of semaphore identifiers need to be increased. To tune your system to support CBR, edit the /etc/system file on your system to add the following statements and then reboot:
set shmsys:shminfo_shmmax=0x02000000 set semsys:seminfo_semmap=750 set semsys:seminfo_semmni=30 set semsys:seminfo_semmns=750 set semsys:seminfo_semmnu=30 set semsys:seminfo_semume=30
If you do not increase the shared memory segment to the values shown above, cbrcontrol executor start command will fail.
To use CBR, Caching Proxy must be installed.
You must make the following modifications to the Caching Proxy configuration file (ibmproxy.conf):
Ensure the incoming URL directive CacheByIncomingUrl is "off" (default).
In the mapping rules section of the configuration file, for every cluster, add a mapping rule similar to:
Proxy /* http://cluster.domain.com/* cluster.domain.com
There are four entries that must be edited for the CBR Plug-in:
The specific additions to the configuration file for each of the operating systems follow.
Figure 20. CBR configuration file for AIX, Linux, and Solaris
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerTerm
Figure 21. CBR configuration file for HP-UX
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerTerm
Figure 22. CBR configuration file for Windows
ServerInit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerInit PostAuth C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostAuth PostExit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostExit ServerTerm C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerTerm
To start the CBR server function, type cbrserver on the command line.
A default configuration file (default.cfg) gets automatically loaded when starting cbrserver. If you decide to save the CBR configuration in default.cfg, then everything saved in this file will be automatically loaded next time cbrserver gets started.
To start the executor function, enter the cbrcontrol executor start command. You may also change various executor settings at this time. See dscontrol executor -- control the executor.
CBR will balance the requests sent for the cluster to the corresponding servers configured on the ports for that cluster.
The cluster is the symbolic name located in the host portion of the URL and should match the name used in the Proxy statement of the ibmproxy.conf file.
Clusters defined in CBR should be defined to match the incoming request. A cluster must be defined using the same hostname or IP address that the incoming request will contain. For example, if the request will enter as the IP address, the cluster must be defined as the IP address. If there is more than one hostname that resolves to a single IP address (and requests can arrive with any one of those hostnames) then all the hostnames should be defined as clusters.
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 Command reference for Dispatcher and CBR.
If you are running Caching Proxy configured as a reverse proxy, when load balancing for multiple Web sites, you must add the cluster address for each Web site to at least one of the network interface cards of the Load Balancer machine. Otherwise, this step can be omitted.
For AIX, HP-UX, Linux, or Solaris: To add the cluster
address to the network interface, use the ifconfig command. Use the
command for your operating system as shown in Table 8.
Table 8. Commands to alias the NIC
AIX | ifconfig interface_name alias cluster_address netmask netmask |
HP-UX | ifconfig interface_name cluster_address netmask netmask up |
Linux | ifconfig interface_name cluster_address netmask netmask up |
Solaris 8, Solaris 9, and Solaris 10 | ifconfig interface_name addif cluster_address netmask netmask up |
For Windows 2000: To add the cluster address to the network interface, do the following:
For Windows 2003: To add the cluster address to the network interface, do the following:
The port number is the port that the server applications are listening on. For CBR with Caching Proxy running HTTP traffic, this is typically port 80.
To define a port to the cluster you defined in the previous step, issue the following:
cbrcontrol port add cluster:port
To set port options, issue the following:
cbrcontrol port set cluster:port option value
For more information, see 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, 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 with Caching Proxy. 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 B, Content rule (pattern) syntax.
Some other rule types defined in Dispatcher can also be used in CBR. 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. For example, to start the HTTP advisor, issue the following command:
cbrcontrol advisor start http port
If you start advisors, you may modify the proportion of importance given to advisor information being included in the load balancing decisions. To set the cluster proportions, issue the cbrcontrol cluster set cluster proportions command. For more information, see Proportion of importance given to status information.
/opt/ibm/edge/lb/servers/lib
/opt/ibm/edge/lb/servers/lib
C:\Program Files\IBM\edge\lb\servers\lib
In the new environment, start Caching Proxy: From the command prompt, issue ibmproxy
To configure CBR follow these steps:
This part provides information on a quick start configuration, planning considerations, and describes the methods of configuring Load Balancer's Site Selector component. It contains the following chapters:
This quick start example shows how to create a site name configuration using Site Selector to load balance traffic among a set of servers based on the domain name used on a client request.
Figure 23. A simple Site Selector configuration
For this quick start configuration example, you will need the following:
For this quick start example, the company's site domain is mywebshop.com. Site Selector will be responsible for a subdomain within mywebshop.com. Therefore, you need to define a subdomain within mywebshop.com. For example: apps.mywebshop.com. Site Selector is not a fully implemented DNS, such as BIND, and acts as a leafnode in a DNS hierarchy. Site Selector is authoritative for the apps.mywebshop.com subdomain. Subdomain apps.mywebshop.com will include the following site names: marketing.apps.mywebshop.com and developer.apps.mywebshop.com.
apps.mywebshop.com. IN NS siteselector.mywebshop.com
With Site Selector, you can create a configuration by using the command line, the configuration wizard, or the graphical user interface (GUI). For this quick start example, configuration steps are demonstrated using the command line.
From a command prompt, follow these steps:
sscontrol sitename add marketing.apps.mywebshop.com
sscontrol sitename add developer.apps.mywebshop.com
sscontrol server add marketing.apps.mywebshop.com:server1+server2
sscontrol server add developer.apps.mywebshop.com:server3+server4
sscontrol manager start
sscontrol advisor start http marketing.apps.mywebshop.com:80
sscontrol advisor start ftp developer.apps.mywebshop.com:21
Site Selector will now make sure that client requests are not sent to a failed server.
sscontrol nameserver start
Your basic Site Selector configuration is now complete.
Test to see if the configuration is working.
sscontrol server status marketing.apps.mywebshop.com:
sscontrol server status developer.apps.mywebshop.com:
The total hits entry of each server should add up to the ping and application request
For information on using the Site Selector GUI, see GUI and Appendix A, GUI: General instructions.
For information on using the Site Selector wizard, see Configuration wizard.
This chapter describes what the network planner should consider before installing and configuring the Site Selector component.
This chapter includes the following sections:
Site Selector works in conjunction with a domain name server to load balance among a group of servers using measurements and weights that are gathered. You can create a site configuration to let you load balance traffic among a group of servers based on the domain name used for a client's request.
Figure 24. Example of a DNS environment
When setting up a subdomain for Site Selector within your DNS environment, Site Selector should have authority over its own subdomain. For example (see Figure 24), your company has been assigned authority over company.com domain. Within the company, there are several subdomains. Site Selector would have authority for siteload.company.com, while the DNS server(s) would still maintain authority for atlanta.company.com and boston.company.com.
In order for company's name server to recognize Site Selector as having authority for the siteload subdomain, a name server entry will need to be added to its named data file. For example, on AIX, a name server entry would look like the following:
siteload.company.com. IN NS siteselector.company.com.
Where siteselector.company.com is the hostname of the Site Selector machine. Equivalent entries would need to be made in any other named database files for use by DNS servers.
A client submits a request for resolution of a domain name to a name server within its network. Name server forwards the request to the Site Selector machine. Site Selector then resolves the domain name to the IP address of one of the servers that has been configured under the site name. Site Selector returns the IP address of the selected server to the name server. Name server returns the IP address to the client. (Site Selector acts as a non-recursive (leaf node) name server, and it will return an error if it does not resolve the domain name request.)
Refer to Figure 5 which illustrates a site in which Site Selector is used in conjunction with a DNS system to load balance across local and remote servers.
Site Selector 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.
With Metric Server, Site Selector can monitor the level of activity on a server, detect when a server is the least heavily loaded, and detect a failed server. The load is a measure of how hard the server is working. The system Site Selector administrator controls the type of measurement used to measure the load. You can configure Site Selector 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).
Load balancing is based on server weights. For Site Selector, there are four proportions which the manager uses to determine weights:
CPU and memory values are all supplied by Metric Server. Consequently, use of Metric Server is recommended with the Site Selector component.
See Metric Server for more information.
The four key functions of Site Selector (name server, manager, Metric Server, and advisors) interact to balance and resolve the incoming requests between servers.
Using DNS-based load balancing requires that caching of name resolutions be disabled. The TTL (time to live) value determines the effectiveness of DNS-based load balancing. TTL determines how long another nameserver will cache the resolved response. Small TTL values allow for subtle changes in the server or network load to be realized more quickly. However, disabling caching requires that clients contact the authoritative name server for every name resolution request, thus potentially increasing the client latency. When choosing a TTL value, careful consideration should be given to the impact that disabled-caching has on an environment. Also be aware that DNS-based load balancing is potentially limited by client-side caching of name resolutions.
TTL can be configured using the sscontrol sitename [add | set] command. See sscontrol sitename -- configure a sitename for more information.
Network proximity is the calculation of each server's nearness to the requesting client. To determine network proximity, the Metric Server agent (which must reside on each load-balanced server) sends a ping to the client IP address and returns the response time to Site Selector. Site Selector uses the proximity response in the load-balancing decision. Site Selector combines the network proximity response value with the weight from the manager to create a combined final weight value for the server.
Use of the network proximity feature with Site Selector is optional.
The Site Selector provides the following network proximity options that can be set per site name:
If set to yes, the Metric Server pings the client to obtain the proximity response time. Name server waits for all Metric Servers to respond or for a time-out to occur. Then, for each server, the name server combines the proximity response time with the weight the manager calculated to create a "combined weight" value for each server. Site Selector will supply the client with the server IP address with the best combined weight. (It is expected that most client name servers have a 5 second time-out. Site Selector tries to respond before that time-out is exceeded.)
If set to no, a name resolution will be provided to the client based on the current manager weights. Then, the Metric Server pings the client to obtain the proximity response time. The name server caches the response time it receives from the Metric Server. When the client returns for a second request, the name server combines the current manager weight with the cached ping response value for each server to obtain the server with the best "combined weight." Site Selector returns this server's IP address to the client for its second request.
Network proximity options can be set on the sscontrol sitename [add | set] command. See Command reference for Site Selector for more information.
Before following the steps in this chapter, see Planning for Site Selector. This chapter explains how to create a basic configuration for the Site Selector component of Load Balancer.
Table 9. Configuration tasks for the Site Selector component
Task | Description | Related information |
---|---|---|
Set up the Site Selector machine. | Finding out about the requirements. | Setting up the Site Selector machine |
Set up machines to be load-balanced. | Set up your load balancing configuration. | Step 4. Define load balanced server machines |
To create a basic configuration for the Site Selector component of Load Balancer, there are four basic methods of configuring the Site Selector component:
This is the most direct means of configuring Site Selector. The command parameter values must be entered in English characters. The only exceptions are host names (used, for example, in site name and server commands) and file names.
To start Site Selector from the command line:
You can enter a minimized version of the sscontrol 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 type sscontrol he f instead of sscontrol help file.
To start up the command line interface: issue sscontrol to receive an sscontrol command prompt.
To end the command line interface: issue exit or quit.
The commands for configuring Site Selector can be entered into a configuration script file and executed together.
sscontrol file appendload myscript
sscontrol file newload myscript
To save the current configuration into a script file (for example, savescript), run the following command:
sscontrol file save savescript
This command will save the configuration script file in the ...ibm/edge/lb/servers/configurations/ss directory.
For general instructions and an example of the GUI, see Figure 41.
To start the GUI, follow these steps
In order to configure the Site Selector component from the GUI, you must first select Site Selector in the tree structure. Once you connect to a host running ssserver, you can create site names containing servers, start the manager, and start advisors.
The GUI can be used to do anything that you would do with the sscontrol command. For example, to define a site name using the command line, you would enter sscontrol sitename add sitename command. To define a site name from the GUI, right-click Name Server, then in the pop-up menu, left-click Add Site Name. Enter the site name in the pop-up window, then click OK.
Pre-existing Site Selector configuration files can be loaded using the Load New Configuration (for completely replacing the current configuration) and Append to Current Configuration (for updating the current configuration) options presented in the Host pop-up menu. You should save your Site Selector 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 the Load Balancer components.
In order to execute a command from the GUI: highlight the Host node from the GUI tree and select Send command.... from the Host pop-up menu. In the command entry field, type the command that you want to execute, for example: nameserver status. The results and history of the commands run in the current session appear in the window provided.
You can access Help by clicking the question mark icon in the upper right hand corner of the Load Balancer window.
For more information about using the GUI, see Appendix A, GUI: General instructions.
If you are using the configuration wizard, follow these steps:
ssserver
You can launch this wizard from the command prompt by issuing the sswizard. Or, select the Configuration Wizard from the Site Selector component menu as presented in the GUI.
The Site Selector wizard guides you step-by-step through the process of creating a basic configuration for the Site Selector component. It asks you questions about your network and guides you as you setup a site name that enables Site Selector to load balance traffic between a group of servers.
Before setting up the Site Selector machine, you must be the root user (for AIX, HP-UX, Linux, or Solaris) or the Administrator (for Windows).
You will need an unresolvable fully qualified hostname to use as a site name for a group of servers that you set up. The site name is the name that the clients use to access your site (such as www.yourcompany.com). Site Selector will load-balance traffic for this site name among the group of servers using DNS.
To start the Site Selector server function, type ssserver on the command line.
To start the Name Server, enter the sscontrol nameserver start command.
Optionally, start the Name Server using the bindaddress keyword to bind only to the specified address.
Site Selector will balance the requests sent for the site name to the corresponding servers configured to it.
The site name is an unresolvable host name that the client will request. The site name must be a fully qualified domain name (for example, www.dnsdownload.com). When a client requests this site name, one of the server IP addresses associated with the site name will be returned.
To define a site name, issue the following command:
sscontrol sitename add sitename
To set site name options, issue the following command:
sscontrol sitename set sitename option value
For more information, see Command reference for Site Selector.
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 site name from step 3, issue the following command:
sscontrol server add sitename:server
You must define more than one server under a site name in order to perform load balancing.
The manager function enhances load balancing. Prior to starting the manager function, ensure that the metric server is installed in all the load-balanced machines.
To start the manager, issue the following command:
sscontrol 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 Load Balancer supplies many advisors. For example, to start the HTTP advisor for a specific site name, issue the following command:
sscontrol advisor start http sitename:port
See Metric Server for information on using system metrics and Metric Server.
If you start advisors, you may modify the proportion of importance given to advisor (port) information being included in the load balancing decisions. To set the site name proportions, issue the sscontrol sitename set sitename proportions command. For more information, see Proportion of importance given to status information.
It is recommended to use Metric Server with the Site Selector component. Refer to Metric Server for information on setting up Metric Server on all server machines that Site Selector is load balancing.
This part provides information on a quick start configuration, planning considerations, and describes the methods of configuring Load Balancer's Cisco CSS Controller component. It contains the following chapters:
This quick start example shows how to create a configuration using the Cisco CSS Controller component. Cisco CSS Controller provides server weight information that assists Cisco CSS Switch in determining optimal server selection for load balancing decisions.
Figure 25. A simple Cisco CSS Controller configuration
For this quick start configuration example, you will need the following:
Ensure the following steps are complete before beginning configuration for this example:
With Cisco CSS Controller, you can create a configuration by using the command line or the graphical user interface (GUI). For this quick start example, configuration steps are demonstrated using the command line.
From a command prompt, follow these steps:
ccocontrol consultant add SwConsultant-1 address 9.17.32.50 community public
This will check connectivity to Cisco CSS Switch and will verify that the SNMP read-write community name is working properly.
ccocontrol ownercontent add SwConsultant-1:OwnerContent-1 ownername OwnerName-1 contentrule ContentRule-1
These values must match the corresponding attributes on the Cisco CSS Switch.
Cisco CSS Controller can now communicate with the switch over SNMP and will obtain the necessary configuration information from the switch. After this step, you should see information in the Cisco CSS Controller about which services are configured on Cisco CSS Switch for the specified ownercontent.
ccocontrol ownercontent metrics SwConsultant-1:OwnerContent-1 activeconn 45 connrate 45 http 10
This command will configure which metric information and proportion you want to collect from the services to be used for weight calculation. The total proportion of all the metrics must equal 100.
ccocontrol consultant start SwConsultant-1
With this command, all the metric collectors will start, and service weight calculations will begin. Cisco CSS Controller communicates the results of its service weight calculations to Cisco CSS Switch via SNMP.
Your basic Cisco CSS Controller configuration is now complete.
Test to see if the configuration is working.
For information on using the Cisco CSS Controller GUI, see GUI and Appendix A, GUI: General instructions.
This chapter describes what a network planner should consider before installing and configuring the Cisco CSS Controller component.
This chapter includes:
For hardware and software requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
You will also need
The Cisco CSS Controller manages a set of switch consultants. Each consultant determines weights for services that are load balanced by a single switch. The switch for which the consultant provides weights is configured for content load balancing. The consultant uses the SNMP protocol to send the calculated weights to the switch. The switch uses the weights to select a service for the content rule it is load balancing when the load balancing algorithm is weighted round-robin. To determine weights, the consultant uses one or more of the following pieces of information:
See the Cisco Content Services Switch Getting Started Guide for a description of content load balancing and for detailed information on configuring the switch.
For a consultant to obtain the information it needs to determine service weights, you must have:
As indicated in Figure 26, we recommend that the consultant be connected to the network behind the switch or switches for which it provides weights. Some parameters must be configured on the switch and some on the controller to enable connectivity between the controller, the switch, and the services.
In Figure 26:
Refer to the Cisco Content Services Switch Getting Started Guide for detailed information about configuring VLANs and IP routing on the switch.
Figure 26. Example of a consultant connected behind the switches
You can manage the Cisco CSS Controller using any of the following interfaces:
For remote management, in Figure 27 :
Refer to Cisco Content Services Switch Getting Started Guide for detailed information.
Controller high availability enhances the fault tolerance capabilities of Load Balancer. Designed with packet-forwarding high availability in mind, controller high availability involves two controllers running simultaneously, one in the primary role, the other in the secondary role.
Each controller is configured with identical switch information, and only one controller is active at a time. This means that, as determined by the high availability logic, only the active controller calculates and updates the switch with new weights.
Controller high availability communicates with its partner using simple user datagram protocol (UDP) packets over an address and port that you configure. These packets are used to exchange information between controllers as it pertains to high availability (reach information), and to determine partner controller availability (heartbeats). If the standby controller determines that the active controller has failed for any reason, the standby controller takes over from the failed active controller. The standby controller then becomes the active controller, and begins calculating and updating the switch with new weights.
In addition to partner availability, reach targets can be configured for high availability. Controller high availability uses the reach information to determine which controller is active and which is standby. The active controller is the controller that can ping more targets and is reachable from its partner.
See High availability for more information.
If the consultant determines that a service is unavailable, it will suspend that service on the switch to prevent the switch from considering the server when it load balances requests. When the service is available again, the consultant activates the service on the switch so that it is considered for load balancing requests.
Cisco CSS Controller posts entries to the following logs:
These logs are located in the following directories:
In each log, you can set the log size and logging level. See Using Load Balancer logs for more information.
Before following the steps in this chapter, see Planning for Cisco CSS Controller. This chapter explains how to create a basic configuration for the Cisco CSS Controller component of Load Balancer.
Before you begin any of the configuration methods in this chapter:
Table 10. Configuration tasks for the Cisco CSS Controller component
Task | Description | Related information |
---|---|---|
Set up the Cisco CSS Controller machine | Finding out about the requirements | Setting up the Controller for Cisco CSS Switches machine |
Test your configuration | Confirm that the configuration is working | Testing your configuration |
To create a basic configuration for the Cisco CSS Controller component of Load Balancer, there are three methods:
This is the most direct means of configuring Cisco CSS Controller. The procedures in this manual assume use of the command line. The command parameter values must be entered in English characters. The only exceptions are host names (used, for example, in the consultant add command) and file names.
To start Cisco CSS Controller from the command line:
Notes:
You can enter an abbreviated version of the ccocontrol 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 type ccocontrol he f instead of ccocontrol help file.
To start up the command line interface: issue ccocontrol to receive an ccocontrol command prompt.
To end the command line interface: issue exit or quit.
The currently-defined configuration can be saved to an XML file. This enables the configuration to be loaded at a later time when you want to quickly recreate the configuration.
To execute the content of an XML file (for example, myscript.xml), use either of the following commands:
ccocontrol file save XMLFilename
ccocontrol file load XMLFileName
Use the load command only if you have previously done a file save.
The XML files are save in the ...ibm/edge/lb/servers/configurations/cco/ directory.
For general instructions and an example of the graphical user interface (GUI), see Figure 41.
To start the GUI, follow these steps
ccoserver.
To configure the Cisco CSS Controller component from the GUI:
You can use the GUI to do anything that you would do with the ccocontrol command. For example:
To run a command from the GUI:
The results and history of the commands that you run in the current session appear in the Result box.
To access Help click the question mark icon in the upper right corner of the Load Balancer window.
For more information about using the GUI, see Appendix A, GUI: General instructions.
Before setting up the Cisco CSS Controller machine, you must be the root user (for AIX, HP-UX, Linux , or Solaris) or the Administrator (for Windows).
Consultant must be able to connect to the Cisco CSS Switch as a Cisco CSS Switch administrator.
When configuring the consultant, you must configure the address and SNMP community name to match the corresponding attributes on the Cisco CSS Switch.
For help with commands used in this procedure, see Command reference for Cisco CSS Controller.
If the ccoserver is not already running, type ccoserver as root to start it now.
Type ccocontrol to start the command line interface.
You must configure the switch address and SNMP community name. These values must match the corresponding attributes on the Cisco CSS Switch.
To add a consultant, type:
consultant add switchConsultantID address switchIPAddress community communityName
An ownercontent is a representation of a content rule for an owner, which is defined on the Cisco CSS Switch. The owner name and content rule name must match how it is defined on the switch.
To define an ownercontent, type:
ownercontent add switchConsultantID:ownercontentID ownername ownerName contentrule contentRuleName
When the ownercontent is defined, the consultant completes the configuration by retrieving the services configured on the switch. Compare the configuration on the switch with the configuration for the consultant to ensure that the services match.
Metrics are the measurements used to determine the service weights and associated proportions (importance of one metric compared to another), and can be any combination of connection data metrics, application advisor metrics, and metric server metrics. The proportions must always total 100.
When the ownercontent is configured, the default metrics are defined as activeconn and connrate. If you want additional metrics, or if you want metrics that are altogether different from the defaults, type:
ownercontent metrics switchConsultantID:ownercontentID metric1 proportion1 metric2 proportion2...metricN proportionN
To start the consultant, type:
consultant start switchConsultantID
This starts the metric collectors, and weight calculation begins.
If system metrics are defined in Step 5, the metric server must be started on the service machines. See Metric Server for information on using the metric server.
To configure high availability, type:
highavailability add address IPaddress partneraddress IPaddress port 80 role primary
In a high availability environment, you can configure multiple switches. To ensure that weight information is always available when one switch takes over for another switch, the Cisco CSS Controller must be configured to provide weights for all switches and their backups.
See Advanced features for Cisco CSS Controller and Nortel Alteon Controller for detailed information on how to use and configure controller high availability.
Test to see if the configuration is working.
This part provides information on a quick start configuration, planning considerations, and describes the methods of configuring Load Balancer's Nortel Alteon Controller component. It contains the following chapters:
This quick start example shows how to create a configuration using the Nortel Alteon Controller component. Nortel Alteon Controller provides server weights to the Nortel Alteon Web Switch. These weights are used to select servers for services that the switch is load balancing.
Figure 28. A simple Nortel Alteon Controller configuration
For this quick start configuration example, you will need the following:
Ensure the following steps are complete before beginning configuration for this example:
With Nortel Alteon Controller, you can create a configuration by using the command line or the graphical user interface (GUI). For this quick start example, configuration steps are demonstrated using the command line.
From a command prompt, follow these steps:
nalcontrol consultant add Consultant-1 address 9.87.32.50
This will check connectivity to Nortel Alteon Web Switch and will verify that the SNMP community names are working properly.
nalcontrol service add Consultant-1:Service-1 vsid 1 vport 80
Nortel Alteon Controller will communicate with the switch over SNMP and will obtain the necessary configuration information from the switch. After this step, you should see information in the Nortel Alteon Controller about what servers are configured on Nortel Alteon Web Switch for the service.
nalcontrol service metrics Consultant-1:Service-1 http 40 activeconn 30 connrate 30
This command will configure which metric information you want to collect from the servers and the relative importance of those metrics during weight calculation.
nalcontrol consultant start Consultant-1
With this command, all the metric collectors will start, and server weight calculations will begin. Nortel Alteon Controller communicates the results of its server weight calculations to Nortel Alteon Web Switch via SNMP.
Your basic Nortel Alteon Controller configuration is now complete.
Test to see if the configuration is working.
For information on using the Nortel Alteon Controller GUI, see GUI and Appendix A, GUI: General instructions.
This chapter describes what a network planner should consider before installing and configuring the Nortel Alteon Controller component.
This chapter includes:
For hardware and software requirements, refer to the following Web page: http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
You will also need
The Nortel Alteon Controller manages a set of switch consultants. Each consultant determines weights for servers that are load balanced by a single switch. The switch for which the consultant provides weights is configured for server load balancing. The consultant uses the SNMP protocol to send the calculated weights to the switch. The switch uses the weights to select a server for the service it is load balancing. To determine weights, the consultant uses one or more of the following pieces of information:
See your Nortel Alteon Web OS Application Guide for a description of server load balancing and for detailed information on configuring the switch.
For a consultant to obtain the information it needs to determine server weights, you must have:
The consultant can be connected to the network in front of or behind the switch or switches for which it provides weights. Some parameters must be configured on the switch and some on the controller to enable connectivity between the controller, the switch, and the servers.
In Figure 29:
Refer to your Nortel Alteon Web OS Application Guide or Command Reference for detailed information about configuring VLANs and IP routing on the switch.
Figure 29. Example of a consultant connected behind the switch
In Figure 30:
Figure 30. Example of consultant connected through an intranet in front of switch
You can manage the Nortel Alteon Controller using any of the following interfaces:
In Figure 31:
Figure 31. Example of consultant behind switch and user interface in front of switch
When a consultant calculates weights for servers that provide a service that is load balanced by a switch, the consultant disables the normal server health checking at the switch to reduce unnecessary traffic to the servers. The consultant re-enables the health checking when it stops providing weights for the service. The server health check interval corresponds to MIB variable slbNewCgRealServerPingInterval.
If the consultant determines that a server is unavailable, the consultant sets the server's maximum number of connections to zero to prevent the switch from considering the server when it load balances requests. When the server is available again, the maximum number of connections is restored to its original value. The server maximum connections value corresponds to MIB variable slbNewCfgRealServerMaxCons.
When a weight is calculated for a real server, the weight is set for the server. The server weight value corresponds to MIB variable slbNewCfgRealServerWeight.
The switch allows the configuration of some servers as backups to others. If the switch determines that a server that has a backup is unavailable, the switch might start sending requests to the backup. When the consultant calculates weights for a service with a backup, it calculates weights for both the backup and the primary servers, and subsequently has weights to use for server selection when the backup is required.
The weight for a backup server might be higher than the weight for a primary server. This is because no requests are forwarded to it, so it has low loads until the switch decides to use it.
To avoid idle server resources, it is common practice that servers assigned to one service be used as backups for servers assigned to a different service. When implementing a configuration like this, avoid assigning the same real servers to multiple concurrently-active services. If this occurs, the weight for the server is overwritten by the consultant for each service in which the server is a part.
Each real server is identified by an integer and has a weight and IP address attribute. Two real servers might have the same IP address. In this case, two real servers are associated with the same physical server machine. The real servers identified as backups should only be configured as backups for a single service. If the same physical server machines will backup servers assigned to multiple services, they must be configured once for each service and be given a server identification that is unique for each service. This allows the backups to have a unique weight assigned to them for each service they are backing up.
Figure 32. Example of consultant configured with backup servers
Servers on a switch can be configured as part of multiple groups, and groups on the switch can be configured to service multiple services.
Because it is possible to configure the same server for multiple services, the weight will be calculated for each service in which the server is a part. It is possible, therefore, for the weight to be incorrect because it is unknown at any time for which service the weight is intended.
In addition, if the consultant is determining weights for one service and not for another, it is possible that the service that the consultant is not calculating weights for has server health checking disabled. In this case, the switch might not properly load balance that service.
Because of these possibilities, you must ensure that a real server is not assigned to multiple services that are being load balanced. This does not mean that the same server machine cannot be servicing requests for multiple services. It means that a real server with a unique identifier must be configured on the switch for each service that the server machine will handle requests for.
Both the Nortel Alteon Controller and the Nortel Alteon Web Switch have high availability capabilities.
You can configure two controllers to run on different systems in a hot-standby configuration.
Two or more switches can back each other up when you configure them to act as a virtual IP interface router (VIR) or as a virtual IP server router (VSR).
One consultant (managed by the controller) provides weights for only one switch. Since at any time a backup switch might take over for the master, you must configure the controller with one consultant for each switch that has the possibility of becoming master. In this way, when a switch becomes master, it is ensured of being provided with weights.
In addition, when the controllers are connected to a VIR, they are ensured of communication with the servers, the switches, and the backup controller, should it lose connectivity to one of the switches.
Refer to your Nortel Alteon Web OS Application Guide for information about high availability on the switch.
Controller high availability enhances the fault tolerance capabilities of Load Balancer. Designed with classic packet-forwarding high availability in mind, controller high availability involves two controllers running simultaneously, one in the primary role, the other in the secondary role.
Each controller is configured with identical switch information. Similar to classic high availability, only one controller is active at a time. This means that, as determined by the high availability logic, only the active controller calculates and updates the switch with new weights.
Controller high availability communicates with its partner using simple user datagram protocol (UDP) packets over an address and port that you configure. These packets are used to exchange information between controllers as it pertains to high availability (reach information), and to determine partner controller availability (heartbeats). If the standby controller determines that the active controller has failed for any reason, the standby controller takes over from the failed active controller. The standby controller then becomes the active controller, and begins calculating and updating the switch with new weights.
In addition to partner availability, reach targets can be configured for high availability. As with classic high availability, controller high availability uses the reach information to determine which controller is active and which is standby. The active controller is the controller that can ping more targets and is reachable from its partner.
See High availability for more information.
In Figure 33:
Figure 33. Example of Nortel Alteon Controller and Nortel Alteon Web Switch high availability
To avoid changing weights too often, you can configure the consultant with a sensitivity threshold. The sensitivity threshold specifies the amount of change that must take place between the old and new weights before the weight can change. See Sensitivity threshold for more information.
If the switch becomes too busy updating weights, you can increase the consultant sleeptime to reduce the traffic between the controller and the servers and the switch. Sleeptime sets the number of seconds to sleep between weight-setting cycles.
If the servers are handling too many monitoring requests from the consultant, you can modify the metric collectors' sleeptime. See Weight calculation sleeptimes for a detailed description.
Cisco CSS Controller posts entries to the following logs:
These logs are located in the following directories:
In each log, you can set the log size and logging level. See Using Load Balancer logs for more information.
Before following the steps in this chapter, see Planning for Nortel Alteon Controller. This chapter explains how to create a basic configuration for the Nortel Alteon Controller component of Load Balancer.
Before you begin any of the configuration methods in this chapter, ensure that your Nortel Alteon Web Switch and all server machines are properly configured.
Table 11. Configuration tasks for the Nortel Alteon Controller component
Task | Description | Related information |
---|---|---|
Configure the Nortel Alteon Web Switch and the servers | Configuring the switch. | Configure the switch, on page (SETSWITCH) |
Set up the Nortel Alteon Controller machine | Configuring the controller. | Step 1. Start the server function |
Test your configuration | Confirm that the configuration is working | Testing your configuration |
To create a basic configuration for the Nortel Alteon Controller component of Load Balancer, there are three methods:
This is the most direct means of configuring Nortel Alteon Controller. The procedures in this manual assume use of the command line.
To start Nortel Alteon Controller from the command line:
Notes:
You can use an abbreviated version of the nalcontrol command parameters by typing the unique letters of the parameters. For example, to get help on the file save command, you can type nalcontrol he f instead of nalcontrol help file.
To end the command line interface: type exit or quit.
Notes:
The currently-defined configuration can be saved to an XML file. This enables the configuration to be loaded at a later time when you want to quickly recreate the configuration.
To execute the content of an XML file (for example, myscript.xml), use the following commands:
nalcontrol file save XMLFilename
Use the load command only if you have previously done a file save.
nalcontrol file load XMLFileName
Use the load command only if you have previously done a file save.
The XML files are save in the ...ibm/edge/lb/servers/configurations/nal/ directory.
For an example of the graphical user interface (GUI), see Figure 41.
To start the GUI:
To configure the Nortel Alteon Controller component from the GUI:
You can use the GUI to do anything that you would do with the nalcontrol command. For example:
To run a command from the GUI:
The results and history of the commands that you run in the current session appear in the Result box.
To access Help, click the question mark icon in the upper right corner of the Load Balancer window.
For more information about using the GUI, see Appendix A, GUI: General instructions.
For help with commands used in this procedure, see Command reference for Nortel Alteon Controller.
Before setting up the Nortel Alteon Controller machine:
If the nalserver is not already running, type nalserver as root to start it now.
Type nalcontrol to start the command line interface.
To add a switch consultant, type:
consultant add switchconsultantID address switchIPAddress
To add a service, type:
service add switchConsultantID:serviceID vsid virtualServerID vport virtualPortNumber
A service is identified by a virtual server identifier (VSID) and a virtual port (VPORT) number, both of which are associated with a virtual server previously configured on the switch.
Metrics is the information used to determine the server weights. Each metric is assigned a proportion to indicate its importance relative to other metrics. Any combination of metrics can be configured: connection data metrics, application advisor metrics, and metric server metrics. The proportions must always total 100.
When a service is configured, the default metrics are defined as activeconn and connrate. If you want additional metrics, or if you want metrics that are altogether different from the defaults, type:
service metrics switchConsultantID:serviceID metricName 50 metricName2 50
To start the consultant, type:
consultant start switchConsultantID
This starts the metric collectors, and weight calculation begins.
To configure high availability, type:
highavailability add address IPaddress partneraddress IPaddress port 80 role primary
SeeAdvanced features for Cisco CSS Controller and Nortel Alteon Controller for detailed information on how to use and configure controller high availability.
If system metrics are defined in Step 5, the metric server must be started on the service machines. See Metric Server for information on using the metric server.
If you modify the configuration on the Nortel Alteon Web Switch, you can refresh the controller configuration. Type:
service refresh
We recommend that before you do a refresh of the configuration, you stop the consultant. After the refresh command updates the configuration, restart the consultant.
Test to see if the configuration is working.
This part provides information on functions and advanced configuration features that are available for Load Balancer. It contains the following chapters:
This chapter explains how to configure the load balancing parameters and how to set up the manager, advisors, and Metric Server functions of Load Balancer.
IMPORTANT: If you are using the Load Balancer for IPv6
installation, see Deploying Dispatcher on Load Balancer for IPv6 for limitations and configuration differences before viewing
the contents of this section.
Table 12. Advanced configuration tasks for Load Balancer
Task | Description | Related information |
---|---|---|
Optionally, change load-balancing settings |
You can change the following load-balancing settings:
| Optimizing the load balancing provided by Load Balancer |
Use scripts to generate an alert or record server failure when manager marks server(s) down/up | Load Balancer provides user exits that trigger scripts that you can customize when the manager marks server(s) down/up | Using scripts to generate an alert or record server failure |
Use advisors | Describes and lists the advisors, which report on specific statuses of your servers | Advisors |
Use HTTP or HTTPS advisor request/response (URL) option | Define a unique client HTTP URL string, specific for a service that you want to query on the machine | Configuring the HTTP or HTTPS advisor using the request/response (URL) option |
Use self advisor | Provides backend server load status in a Load Balancer two-tiered WAN configuration | Using Self Advisor in a two-tiered WAN configuration |
Create custom advisors | Describes how to write your own custom advisors | Create custom (customizable) advisors |
Use Metric Server agent | Metric Server provides system load information to Load Balancer | Metric Server |
Use Workload Manager advisor (WLM) | WLM advisor provides system load information to Load Balancer | Workload Manager advisor |
The manager function of Load Balancer performs load balancing based on the following settings:
You can change these settings to optimize load balancing for your network.
The manager can use some or all of the following external factors in its weighting decisions:
Or --
Cpu: The percentage of CPU in use on each load balanced server machine (input from Metric Server agent). For Site Selector only, this proportion appears in place of the active connection proportion column.
Or --
Memory: The percentage of memory in use (input from Metric Server agent) on each load balanced server. For Site Selector only, this proportion appears in place of the new connection proportion column.
Along with the current weight for each server and some other information required for its calculations, the manager gets the first two values (active and new connections) 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 of the four values on a per cluster (or site name) basis. 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. In your environment, you may need to try different proportions to find the combination that gives the best performance.
When adding the WLM advisor, if the system metric proportion is zero, then the manager increases this value to 1. Since the sum of the relative proportions must total 100, the highest value is then decreased by 1.
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 active and new connections proportions values too low. You will disable load balancing and smoothing unless you have these first two values set to at least 20 each.
To set the proportion of importance values use the dscontrol cluster set cluster proportions command. See dscontrol cluster -- configure clusters for more information.
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 Metric Server. If you want to set weights manually while running the manager, specify the fixedweight option on the dscontrol server command. For a description of the fixedweight option, see Manager fixed weights.
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, use the dscontrol port set port weightbound weight command. This command affects how much difference there can be between the number of requests each server will get. If you set the maximum weightbound 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 weightbound of 2, one server could get twice as many requests as another. At a maximum weightbound of 10, one server could get 10 times as many requests as another. The default maximum weightbound 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.
If all the servers are down, the manager sets the weights to half the weightbound.
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 dscontrol server command. For example:
dscontrol server set cluster:port:server fixedweight yes
After fixedweight is set to yes, use the dscontrol 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 dscontrol server command with fixedweight set to no. For more information, see dscontrol server -- configure servers.
If TCP reset is activated, Dispatcher will send a TCP reset to the client when the client has a connection to a server whose weight is 0. A server's weight may be 0 if it is configured 0 or if an advisor marks it down. A TCP reset will cause the connection to be immediately closed. This feature is useful for long-lived connections where it hastens the client's ability to renegotiate a failed connection. To activate TCP reset, use the dscontrol port add|set port reset yes command. The default value for reset is no.
A useful feature to configure, in conjunction with TCP reset, is advisor retry. With this feature, an advisor has the ability to retry a connection before marking a server down..This would help prevent the advisor from marking the server down prematurely which could lead to connection-reset problems. That is, just because the advisor failed on the first attempt dosen't necessarily mean that the existing connections are also failing. See Advisor retry for more information.
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 dscontrol manager interval and dscontrol 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:
dscontrol 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:
dscontrol manager refresh 3
This will cause the manager to wait for 3 intervals before asking the executor for status.
Other methods are available 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:
dscontrol 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:
dscontrol manager smoothing 4
In most cases, you will not need to change this value.
Load Balancer provides user exits that trigger scripts that you can customize. You can create the scripts to perform automated actions, such as alerting an Administrator when servers are marked down by the manager or simply record the event of the failure. Sample scripts, which you can customize, are in the ...ibm/edge/lb/servers/samples install directory. In order to run the files, you must move them to the ...ibm/edge/lb/servers/bin directory and remove the "sample" file extension. The following sample scripts are provided:
If all servers on a cluster are marked down (either by the user or by the advisors), the managerAlert (if configured) is executed, and Load Balancer attempts to route traffic to the servers using a round-robin technique. The serverDown script does not execute when the last server in the cluster is detected as offline.
By design, Load Balancer attempts to continue to route the traffic in case a server comes back online and responds to the request. If Load Balancer instead dropped all traffic, the client would receive no response.
When Load Balancer detects that the first server of a cluster is back online, the managerClear script (if configured) is executed, but the serverUp script (if configured) is not executed until an additional server is brought back online.
Considerations when using serverUp and serverDown scripts:
Advisors are agents within Load Balancer. 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. However, it does not make sense to use all of the provided advisors with every component of Load Balancer. (For instance, you would not use the Telnet advisor with the CBR component.) Load Balancer also supports the concept of a "custom advisor" that allows users to write their own advisors.
For Linux, limitation on using bind-specific server applications: Load Balancer does not support the use of advisors when load-balancing servers with bind-specific server applications (including other Load Balancer components such as CBR or Site Selector) when they are binding to the cluster IP address.
For HP-UX and Solaris, limitation on using bind-specific server applications: If using arp publish instead of ifconfig alias command, Load Balancer will support the use of advisors when load-balancing servers with bind-specific server applications (including other Load Balancer components such as CBR or Site Selector) when they are binding to the cluster IP address. However, when using advisors against bind-specific server application, do not collocate Load Balancer on the same machine with the server application.
-DND_ADV_SRC_ADDR=IP_address
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 an HTTP "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 until that server has come back up.
You can start an advisor for a particular port across all clusters (group advisor). Or, you can choose to run different advisors on the same port, but on different clusters (cluster/site specific advisor). For example, if you have Load Balancer defined with three clusters (clusterA, clusterB, clusterC), each having port 80 you can do the following:
dscontrol advisor start http clusterA:80This command will start the http advisor on port 80 for clusterA. The http advisor will advise on all servers attached to port 80 for clusterA.
dscontrol advisor start ADV_custom 80This command will start the ADV_custom advisor on port 80 for clusterB and clusterC. Your custom advisor will advise on all servers attached to port 80 for clusterB and clusterC. (For more information on custom advisors, see Create custom (customizable) advisors.)
Using the above configuration example for the group advisor, you can choose to stop the custom advisor ADV_custom for port 80 on just one of the clusters or for both clusters (clusterB and clusterC).
dscontrol advisor stop ADV_custom clusterB:80
dscontrol advisor stop ADV_custom 80
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:
dscontrol advisor interval http 80 3
It does not make sense to specify an advisor interval that is smaller than the manager interval. The default advisor interval is seven seconds.
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 report timeout. The advisor report 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 timeout -- the default value is unlimited.
For example, to set the advisor report timeout to 30 seconds for the HTTP advisor for port 80, enter the following command:
dscontrol advisor timeout http 80 30
For more information on setting the advisor report timeout, see dscontrol advisor -- control the advisor.
For Load Balancer, you can set the advisor's timeout values at which it detects a particular port on the server (a service) is failed. The failed-server timeout values (connecttimeout and receivetimeout) determine how long an advisor waits before reporting that either a connect or receive has failed.
To obtain the fastest failed-server detection, set the advisor connect and receive timeouts to the smallest value (one second), and set the advisor and manager interval time to the smallest value (one second).
For example, to set the connecttimeout and receivetimeout to 9 seconds for the HTTP advisor on port 80, type the following command:
dscontrol advisor connecttimeout http 80 9 dscontrol advisor receivetimeout http 80 9
The default for connect and receive timeout is 3 times the value specified for the advisor interval time.
Advisors have the ability to retry a connection before marking a server down. The advisor will not mark a server down until the server query has failed the number of retries plus 1. It is recommended that the retry value should be no larger than 3. The following command sets a retry value of 2 for the LDAP advisor on port 389:
dscontrol advisor retry ldap 389 2
The URL option for the HTTP or HTTPS advisor is available for the Dispatcher and CBR components.
After you have started an HTTP or HTTPS advisor, you can define a unique client HTTP URL string, specific for the service that you want to query on the server. This allows the advisor to assess the health of the individual services within a server. You can do this by defining logical servers with unique server names that have the same physical IP address. See Server Partitioning: logical servers configured to one physical server (IP address) for more information.
For each defined logical server under the HTTP port you can specify a unique client HTTP URL string, specific for the service that you want to query on the server. The HTTP or HTTPS advisor uses the advisorrequest string to query the health of the servers. The default value is HEAD / HTTP/1.0. The advisorresponse string is the response that the advisor scans for in the HTTP response. The advisor uses the advisorresponse string to compare to the real response that is received from the server. The default value is null.
Important: If a blank is contained within the HTTP URL string:
server set cluster:port:server advisorrequest "head / http/1.0" server set cluster:port:server advisorresponse "HTTP 200 OK"
dscontrol server set cluster:port:server advisorrequest "\"head / http/1.0\"" dscontrol server set cluster:port:server advisorresponse "\"HTTP 200 OK\""
When you create the request that the HTTP or HTTPS advisor sends to back-end servers to see if they are functioning, you type the start of the HTTP request and Load Balancer completes the end of the request with the following:
\r\nAccept: */*\r\nUser-Agent:IBM_Network_Dispatcher_HTTP_Advisor\r\n\r\n
If you want to add other HTTP header fields before Load Balancer appends this string to the end of the request, you can do so by including your own \r\n string in the request. The following is an example of what you might type to add the HTTP host header field to your request:
GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
See dscontrol server -- configure servers for more information.
The self advisor is available on the Dispatcher component.
For Load Balancer in a two-tiered WAN (wide area network) configuration, Dispatcher provides a self advisor that collects load status information on backend servers.
Figure 34. Example of a two-tiered WAN configuration using the self advisor
In this example, the self advisor along with Metric Server reside on the two Dispatcher machines that are being load balanced by the top tier Load Balancer. The self advisor specifically measures the connections per second rate on backend servers of the Dispatcher at the executor level.
The self advisor writes the results to the dsloadstat file. Load Balancer also provides an external metric called dsload. The Metric Server agent on each Dispatcher machine runs its configuration that calls the external metric dsload. The dsload script extracts a string from the dsloadstat file and returns it to the Metric Server agent. Subsequently, each of the Metric Server agents (from each of the Dispatchers) returns the load status value to the top-tiered Load Balancer for use in determining which Dispatcher to forward client requests.
The dsload executable resides in the ...ibm/edge/lb/ms/script directory for Load Balancer.
See Configure wide area Dispatcher support for more information on using Dispatcher in WAN configurations. See Metric Server for more information on Metric Server.
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, ADV_sample.java, is provided with the Load Balancer
product. After installing Load Balancer, you may find the sample code
in
...<install
directory>/servers/samples/CustomAdvisors install directory.
The default install directory is:
If the custom advisor references additional Java classes, the classpath in the Load Balancer start script file (dsserver, cbrserver, ssserver) should be updated to include the location.
Sample custom advisor files specifically for the WebSphere Application Server (WAS) advisor are provided in the Load Balancer install directory.
The WebSphere Application Server 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 may use the Java 1.4 compiler that is installed with Load Balancer in the ...ibm/edge/java directory. These files are referenced during compilation:
Your classpath must point to both the custom advisor file and the base classes file during the compile.
For Windows, a sample compile command is:
javac -classpath install_dir\lb\servers\lib\ibmlb.jar ADV_fred.java
where:
The output for the compilation is a class file, for example
ADV_fred.class
Before starting the advisor, copy the class file to the ...ibm/edge/lb/servers/lib/CustomAdvisors install directory.
For AIX, HP-UX, Linux , and Solaris, the syntax is similar.
To run the custom advisor, you must first copy the class file to the proper install directory:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_fred.class
Configure the component, start its manager function, and issue the command to start your custom advisor:
dscontrol advisor start fred 123
where:
If the custom advisor references additional Java classes, the classpath in the Load Balancer start script file (dsserver, cbrserver, ssserver) should be updated to include the location.
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.
These are base class methods:
Load Balancer first looks at the list of native advisors that it provides. If it does not find a given advisor there, Load Balancer then looks at the customer's list of customized advisors.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Program Files\IBM\edge\lb\servers\lib\CustomAdvisors
The program listing for a sample advisor is included in Sample advisor. After installation, this sample advisor can be found in the ...ibm/edge/lb/servers/samples/CustomAdvisors directory.
This feature is available for all the Load Balancer components.
Metric Server provides server load information to the Load Balancer in the form of system-specific metrics, reporting on the health of the servers. The Load Balancer manager queries the Metric Server agent residing on each of the servers, assigning weights to the load balancing process using the metrics gathered from the agents. The results are also placed into the manager report.
For a configuration example see Figure 5.
Like the WLM advisor, the Metric Server reports on server systems as a whole, rather than on individual protocol-specific server daemons. Both WLM and Metric Server place their results into the system column of the manager report. As a consequence, running both the WLM advisor and Metric Server at the same time is not supported.
The Metric Server agent must be installed and running on all servers that are being load balanced.
Below are the steps to configure Metric Server for Dispatcher. Similar steps can be used for configuring Metric Server for the other components of Load Balancer.
port is the RMI port chosen for all the Metric Server agents to run on. The default RMI port that is set in the metricserver.cmd file is 10004.
systemMetric is the name of the script (residing on the backend server) which should run on each of the servers in the configuration under the specified cluster (or site name). Two scripts are provided for the customer - cpuload and memload. Or, you can create custom system metric scripts. The script contains a command which should return a numeric value in the range of 0-100 or a value of -1 if the server is down. This numeric value should represent a load measurement, not an availability value.
Limitation: For Windows platform, if the name of your System Metric script has an extension other than ".exe", you must specify the full name of the file (for example, "mysystemscript.bat"). This is due to a Java limitation.
Optionally, customers can write their own customized metric script files which define the command that the Metric Server will issue on the server machines. Ensure that any custom scripts are executable and located in the ...ibm/edge/lb/ms/script directory. Custom scripts must return a numeric load value in the range of 0-100.
To have Metric Server run on an address other than the local host, you need to edit the metricserver file on the load balanced server machine. After the occurence of "java" in the metricserver file, insert the following:
-Djava.rmi.server.hostname=OTHER_ADDRESS
In addition, before the "if" statements in the metricserver file, add the following line: hostname OTHER_ADDRESS.
When gathering metrics across different domains, you must explicitly set the java.rmi.server.hostname in the server script (dsserver, cbrserver, etc) to the fully-qualified domain name (FQDN) of the machine that is requesting the metrics. This is necessary because, depending on your setup and operating system, InetAddress.getLocalHost.getHostName() might not return the FQDN.
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 the Metric Server agent, the WLM agent reports on server systems as a whole, rather than on individual protocol-specific server daemons. Metric Server and WLM place their results into the system column of the manager report. As a consequence, running both the WLM advisor and Metric Server at the same time is not supported.
This chapter explains how to configure the load balancing parameters and how to set up Load Balancer for advanced functions.
IMPORTANT: If you are using the Load Balancer for IPv6
installation, see Deploying Dispatcher on Load Balancer for IPv6 for limitations and configuration differences before viewing
the contents of this chapter.
Table 13. Advanced configuration tasks for the Load Balancer
Task | Description | Related information |
---|---|---|
Collocate Load Balancer on a machine that it is load balancing | Set up a collocated Load Balancer machine. | Using collocated servers |
Configure high availability or mutual high availability | Set up a second Dispatcher machine to provide a backup. | High availability |
Configure rules-based load balancing | Define conditions under which a subset of your servers will be used. | Configure rules-based load balancing |
Use port 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. | port affinity override |
Use sticky (affinity) feature to configure a cluster's port to be sticky | Allows client requests to be directed to the same server. | How affinity feature for Load Balancer works |
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 (stickymask) |
Use active cookie affinity to load balance servers for CBR | A rule option that allows a session to maintain affinity for a particular server. | Active cookie affinity |
Use passive cookie affinity to load balance servers for Dispatcher's content-based routing and the CBR component | A rule option that allows a session to maintain affinity for a particular server based on the cookie name/cookie value. | Passive cookie affinity |
Use URI affinity to load-balance across Caching Proxy servers with unique content to be cached on each individual server | A rule option that allows a session to maintain affinity for a particular server based on the URI. | URI affinity |
Configure wide area Dispatcher support | Set up a remote Dispatcher to load balance across a wide area network. Or, load balance across a wide area network (without a remote Dispatcher) using a server platform that supports GRE. | Configure wide area Dispatcher support |
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 Caching Proxy for transparent proxy | Allows Dispatcher to be used to enable a transparent proxy. | Use wildcard cluster with Caching Proxy 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 "Denial of Service Attack" detection to notify administrators (via an alert) of potential attacks | Dispatcher analyzes incoming requests for a conspicuous amount of half-open TCP connections on servers. | Denial of service attack detection |
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 |
Load Balancer 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. Collocation applies to the Dispatcher and Site Selector components. Collocation is also supported for CBR, but only when using bind-specific Web servers and bind-specific Caching Proxy.
Linux: In order to configure both collocation and high availability at the same time, when running the Dispatcher component using the mac forwarding method, see Linux loopback aliasing alternatives when using Load Balancer's mac forwarding.
Solaris: There is a limitation that you cannot configure WAN advisors when the entry-point Dispatcher is collocated. See Using remote advisors with Dispatcher's wide area support.
In earlier 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 dscontrol 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. The collocated parameter should not be set for servers which are collocated using Dispatcher's nat or cbr forwarding method.
You can configure a collocated server in one of the following ways:
For Dispatcher's nat or cbr forwarding, you must configure (alias) an unused adapter address on the NFA. The server should be configured to listen on this address. Configure the server using the following command syntax:
dscontrol server add cluster:port:new_alias address new_alias router router_ip returnaddress return_address
Failure to configure for this can lead to system errors, no response from the server, or both.
Support for collocation when configuring Dispatcher's nat forwarding method can now be done on all operating systems if the following steps are performed on the Dispatcher machine:
arp -s hostname ether_addr pub
using the local MAC address for ether_addr. This enables the local application to send traffic to the return address in the kernel.
CBR supports collocation on all platforms with no additional configurations required. However, the Web servers and Caching Proxy that you use must be bind-specific.
Site Selector supports collocation on all platforms with no additional configurations required.
The high availability function (configurable using dscontrol highavailability command) is available for the Dispatcher component (but not for the CBR or Site Selector component).
To improve Dispatcher availability, the Dispatcher high availability function uses the following mechanisms:
If possible, it is recommended that at least one of the heartbeat pairs be across a separate subnet than the regular cluster traffic. Keeping the heartbeat traffic distinct will help prevent false takeovers during very heavy network loads and also improve complete recovery times after a failover.
Complete syntax for dscontrol highavailability is in dscontrol highavailability -- control high availability.
For a more complete discussion of many of the tasks below, see Setting up the Dispatcher machine.
dscontrol highavailability heartbeat add sourceaddress destinationaddress
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3At least one heartbeat pair must have the NFAs of the pair as the source and destination address.
If possible, it is recommended that at least one of the heartbeat pairs be across a separate subnet than the regular cluster traffic. Keeping the heartbeat traffic distinct will help prevent false takeovers during very heavy network loads and also improve complete recovery times after a failover.
Set the number of seconds that the executor uses to timeout high availability heartbeats. For example:
dscontrol executor hatimeout 3
The default is 2 seconds.
dscontrol 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.
dscontrol highavailability backup add primary [auto | manual] port
dscontrol highavailability backup add backup [auto | manual] port
dscontrol highavailability backup add both [auto | manual] port
dscontrol 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.
dscontrol cluster set clusterA primaryhost NFAdispatcher1 dscontrol cluster set clusterB primaryhost NFAdispatcher2
dscontrol cluster set clusterB primaryhost NFAdispatcher2 dscontrol cluster set clusterA primaryhost NFAdispatcher1
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 can provide a list of hosts that each of the Dispatchers should be able to reach in order to work correctly. The two high availability partners are continually in touch with each other through heartbeats, and they update one another on how many reach targets either one of them can ping. If the standby pings more reach targets than the active, a failover occurs.
Heartbeats are sent by the active Dispatcher and are expected to be received by the standby Dispatcher every half second. If the standby Dispatcher fails to receive a heartbeat within 2 seconds, a failover begins. All heartbeats must break for a takeover from the standby Dispatcher to occur. In other words, when two heartbeat pairs are configured, both heartbeats must break. To stabilize a high availability environment and to avoid failover, it is recommended that you add more than one heartbeat pair.
For reach targets, 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. Failover 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. Sample scripts can be found in the ...ibm/edge/lb/servers/samples directory and must be moved to the ...ibm/edge/lb/servers/bin directory in order to run. The scripts will run automatically only if dsserver is running.
The following sample scripts may be used:
On Windows systems: In your configuration setup, if you have Site Selector load balancing two Dispatcher machines that are operating in a high availability environment, you will need to add an alias on the Microsoft stack for the metric servers. This alias should be added to the goActive script. For example:
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
In the goStandby and goInOp, the alias will need to be removed. For example:
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
If there are multiple NIC's on the machine, then first check which interface you should use by issuing the following command on the command prompt: netsh interface ip show address. This command will return a list of currently configured interfaces and will number the "Local Area Connection" (for example, "Local Area Connection 2") so you can determine which one you should use.
IMPORTANT: When running Dispatcher on Linux for S/390 --
Dispatcher issues a gratuitous ARP to move IP addresses from one Dispatcher to another. This mechanism is therefore tied to the underlying network type. When running Linux for S/390, Dispatcher can natively do high availability takeovers (complete with IP address moves) only on those interfaces which can issue a gratuitous ARP and configure the address on the local interface. This mechanism will not work properly on point-to-point interfaces such as IUCV and CTC and will not work properly in certain configurations of QETH/QDIO.
For those interfaces and configurations where Dispatcher's native IP takeover function will not work properly, the customer may place appropriate commands in the go scripts to manually move the addresses. This will ensure that those network topologies can also benefit from high availability.
You can use rules-based load balancing to fine tune when and why packets are sent to which servers. Load Balancer reviews 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.
In most cases when configuring rules, you should configure a default always true rule in order to catch any request that falls through the other higher priority rules. This can be a "Sorry, the site is currently down, please try again later" response when all other servers fail for the client request.
You should use rules-based load balancing with Dispatcher and Site Selector when you want to use a subset of your servers for some reason. You must always use rules for the CBR component.
You can choose from 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, and may have a begin range and end range, along with a set of servers. In addition, the content type rule for the CBR component has a matching regular expression pattern associated with it. ( For examples and scenarios on how to use the content rule and valid pattern syntax for the content rule, see Appendix B, Content rule (pattern) syntax.)
Rules are evaluated in priority order. In other words, a rule with a priority of 1 (lower number) will be evaluated before a rule with a priority of 2 (higher number). 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, Site Selector will return the name server request with an error, and CBR will cause Caching Proxy 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, Site Selector will select a server from the full set of servers available on the site name, and CBR will cause Caching Proxy to return an error page.
This rule type is available in the Dispatcher, CBR, or Site Selector component.
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 dscontrol rule command, for example:
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
This "ni" 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.
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.
This rule type is available in the Dispatcher, CBR, or Site Selector component.
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.
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 dscontrol 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:
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
This rule type is available in the Dispatcher and CBR components.
You may want to use rules based on connections per second if you need to share some of your servers with other applications. For example, you can 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 increases above a certain level. This way, Dispatcher would balance the load across all five servers at peak times.
Setting rule evaluate option "upserversonrule" in conjunction with the "connection" type rule: When using the connections type rule and setting the upserversonrule option, if some of the servers in the server set are down, then you can ensure that the remaining servers will not be overloaded. See Server evaluation option for rules for more information.
This rule type is available in the Dispatcher or CBR component.
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 dscontrol rule command or the cbrcontrol rule command, for example:
dscontrol 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.
Reserved bandwidth and shared bandwidth rules are only available in the Dispatcher component.
For bandwidth rules, Dispatcher calculates bandwidth as the rate at which data is delivered to clients by a specific set of servers. Dispatcher tracks capacity at the server, rule, port, cluster, and executor levels. For each of these levels, there is a byte counter field: kilobytes transferred per second. Dispatcher calculates these rates over a 60 second interval. You can view these rate values from the GUI or from the output of a command line report.
The reserved bandwidth rule allows you to control the number of kilobytes per second being delivered by a set of servers. By setting a threshold (allocating a specified bandwidth range) for each set of servers throughout the configuration, you can control and guarantee the amount of bandwidth being used by each cluster-port combination.
The following is an example for adding a reservedbandwidth rule:
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
The begin range and end range are specified in kilobytes per second.
Prior to configuring the shared bandwidth rule, you must specify the maximum amount of bandwidth (kilobytes per second) that can be shared at the executor or cluster level using dscontrol executor or dscontrol cluster command with the sharedbandwidth option. The sharebandwidth value should not exceed the total bandwidth (total network capacity) available. Using the dscontrol command to set shared bandwidth only provides an upper limit for the rule.
The following are examples of the command syntax:
dscontrol executor set sharedbandwidth size dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth size
The size for sharedbandwidth is an integer value (kilobytes per second). The default is zero. If the value is zero, then bandwidth cannot be shared.
Sharing bandwidth at the cluster level allows a maximum specified bandwidth to be used by the cluster. As long as the bandwidth used by the cluster is below the specified amount, then this rule will evaluate as true. If the total bandwidth used is greater than the specified amount, then this rule will evaluate as false.
Sharing bandwidth at the executor level allows the entire Dispatcher configuration to share a maximum amount of bandwidth. As long as the bandwidth used at the executor level is below the specified amount, then this rule will evaluate as true. If the total bandwidth used is greater than that defined, then this rule will evaluate as false.
The following are examples of adding or setting a sharedbandwidth rule:
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel value dscontrol rule set 9.20.34.11:80:shrule sharelevel value
The value for sharelevel is either executor or cluster. Sharelevel is a required parameter on the sharebandwidth rule.
Dispatcher allows you to allocate a specified bandwidth to sets of servers within you configuration using the reserved bandwidth rule. By specifying a begin and end range, you can control the range of kilobytes delivered by a set of servers to the clients. Once the rule no longer evaluates as true (the end range is exeeded), the next lower priority rule will be evaluated. If the next lower priority rule is an "always true" rule, a server could be selected to respond to the client with a "site busy" response.
For example: Consider a group of three servers on port 2222. If the reserved bandwidth is set to 300, then the maximum kbytes per second will be 300, over a period of 60 seconds. When this rate is exceeded, then the rule no longer evaluates as true. If this were the only rule, then one of the three servers would be selected by Dispatcher to handle the request. If there were a lower priority "always true" rule, then the request could be redirected to another server and answered with "site busy".
The shared bandwidth rule can provide additional server access to clients. Specifically, when used as a lower priority rule following a reserved bandwidth rule, a client can still access a server even though the reserved bandwidth has been exceeded.
For example: By using a shared bandwidth rule following a reserved bandwidth rule you can allow clients to gain access to the three servers in a controlled manner. As long as there is shared bandwidth available to be used, the rule will evaluate as true and access is granted. If there is no shared bandwidth available, then the rule is not true and the next rule is evaluated. If an "always true" rule follows, the request can be redirected as needed.
By using both reserved and shared bandwidth as described in the preceding example, greater flexibility and control can be exercised in granting (or denying) access to the servers. Servers on a specific port can be limited in bandwidth usage, while others can use additional bandwidth as long as it is available.
This rule type is only available in the Site Selector component.
For the metric all rule, you choose a system metric (cpuload, memload, or your own customized system metric script), and Site Selector compares the system metric value (returned by the Metric Server agent residing in each load-balanced server) with the begin and end range that you specify in the rule. The current system metric value for all the servers in the server set must be within the range for the rule to fire.
The following is an example of adding a metric all rule to your configuration:
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
This rule type is only available in the Site Selector component.
For the metric average rule, you choose a system metric (cpuload, memload, or your own customized system metric script), and Site Selector compares the system metric value (returned by the Metric Server agent residing in each load-balanced server) with the begin and end range that you specify in the rule. The average of the current system metric values for all the servers in the server set must be within the range for the rule to fire.
The following is an example of adding a metric average rule to your configuration:
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
This rule type is available in the Dispatcher, CBR, or Site Selector component.
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 dscontrol rule command like:
dscontrol 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.
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 available in the CBR component or Dispatcher component (when using Dispatcher's cbr forwarding method).
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.
Important: For examples and scenarios on how to use the content rule and valid pattern syntax for the content rule, see Appendix B, Content rule (pattern) syntax.
With port 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 port 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 dscontrol server -- configure servers, for detailed information on command syntax for the port affinity override, using the server sticky option.
You can add rules using the dscontrol 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:
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol 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:
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
The server evaluation option is only available in the Dispatcher component.
On the dscontrol rule command there is a server evaluation option for rules. Use the evaluate option to choose to evaluate the rule's condition across all the servers on the port or to evaluate the rule's condition across just the servers within the rule. (In earlier versions of Load Balancer, you could only measure each rule's condition across all servers on the port.)
Notes:
The following are examples of adding or setting the evaluate option on a reserved bandwidth rule:
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate level dscontrol rule set 9.22.21.3:80:rbweval evaluate level
The evaluate level can be set to either port, rule, or upserversonrule. The default is port.
The option to measure the rule's condition across the servers within the rule allows you to configure two rules with the following characteristics:
The result is that when traffic exceeds the threshold of the servers within the first rule, traffic will be sent to the "site busy" server within the second rule. When traffic falls below the threshold of the servers within the first rule, new traffic continues once again to the servers in the first rule.
Using the two rules described in the previous example, if you set the evaluate option to port for the first rule (evaluate rule's condition across all the servers on the port), when traffic exceeds the threshold of that rule, traffic is sent to the "site busy" server associated to the second rule.
The first rule measures all server traffic (including the "site busy" server) on the port to determine whether the traffic exceeds the threshold. As congestion decreases for the servers associated to the first rule, an unintentional result may occur where traffic continues to the "site busy" server because traffic on the port still exceeds the threshold of the first rule.
For the Dispatcher and CBR components: 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 stickytime at the executor, cluster, or port level to some number of seconds. The feature is disabled by setting stickytime to zero.
For the Site Selector component: You enable the affinity feature when you configure a sitename to be sticky. Configuring a sitename to be sticky allows the client to use the same server for multiple name service requests. This is done by setting stickytime on the sitename to some number of seconds. The feature is disabled by setting stickytime to zero.
With the affinity feature disabled, whenever a new TCP connection is received from a client, Load Balancer 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, Load Balancer treats it as an unrelated new connection, and again picks the right server at that moment in time.
With the affinity 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.
Cross port affinity only applies to the Dispatcher component's MAC and NAT/NATP forwarding methods.
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:
dscontrol port set cluster:20 crossport 10 dscontrol port set cluster:30 crossport 10 dscontrol 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 dscontrol 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 dscontrol port command allows you to mask the common high-order bits of the 32-bit IP address. If this feature is configured, 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 Load Balancer. 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 dscontrol port command similar to the following:
dscontrol port set cluster:port stickytime 10 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 dscontrol port -- configure ports, for detailed information on command syntax for stickymask (affinity address mask feature).
Quiesce handling applies to the Dispatcher and CBR components.
To remove a server from the Load Balancer configuration for any reason (updates, upgrades, service, and so forth), you can use the dscontrol manager quiesce command. The quiesce subcommand allows existing connections to complete (without being severed) and forwards only subsequent new connections from the client to the quiesced server if the connection is designated as sticky and stickytime has not expired. The quiesce subcommand disallows any other new connections to the server.
Use the quiesce "now" option if you have stickytime set, and you want new connections sent to another server (instead of the quiesced server) before stickytime expires. The following is an example of using the now option to quiesce server 9.40.25.67:
dscontrol manager quiesce 9.40.25.67 now
The now option determines how sticky connections will be handled as follows:
This is the more graceful, less abrupt, way to quiesce servers. For instance, you can gracefully quiesce a server and then wait for the time where there is the least amount of traffic (perhaps early morning) to completely remove the server from the configuration.
You can specify the following types of affinity on the dscontrol rule command:
Passive cookie applies to the CBR component and to Dispatcher component's cbr forwarding method.
URI affinity applies to the CBR component and to Dispatcher component's cbr forwarding method.
The default for the affinity option is "none." The stickytime option on the port command must be zero (not enabled) in order to set the affinity option on the rule command to active cookie, passive cookie, or URI. When affinity is set on the rule, you cannot enable stickytime on the port.
The active cookie affinity feature applies only to the CBR component.
It provides a 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 "activecookie." This can be done when the rule is added, or using the rule set command. See dscontrol rule -- configure rules, for detailed information on command syntax.
Once a rule has been enabled for active 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.
Active 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. The cookie is in the following format: IBMCBR=cluster:port:rule+server-time! The cluster:port:rule and server information are encoded so the CBR configuration is not revealed.
Whenever a rule fires that has active cookie affinity turned on, the cookie sent by the client is examined.
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.
Each affinity instance in the cookie will be 65 bytes in length and end at the exclamation mark. As a result, a 4096 byte cookie can hold approximately 60 individual active cookie rules per domain. If the cookie fills up completely, then all expired affinity instances will be purged. If all instances are still valid, then the oldest one is dropped, and the new instances for the current rule is added.
The active cookie affinity option, for the rule command, can only be set to activecookie if port stickytime is zero (not enabled). Once active cookie affinity is active on a rule then you cannot enable stickytime on the port.
To enable active cookie affinity for a particular rule, use the rule set command:
rule set cluster:port:rule stickytime 60 rule set cluster:port:rule affinity activecookie
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.
Active cookie affinity has a default expiration of the current server time, plus the stickytime interval, plus twenty-four hours. If your clients (those sending requests to your CBR machine) have inaccurate times on their system (for example, they are more than one day ahead of the server time), then those clients' systems will ignore the cookies from CBR because the system will assume that the cookies have already expired. To set a longer expiration time, modify the cbrserver script. In the script file, edit the javaw line, adding the following parameter after LB_SERVER_KEYS: -DCOOKIEEXPIREINTERVAL=X where X is the number of days to add to the expiration time.
On AIX, Solaris and Linux, the cbrserver file is located in /usr/bin directory.
On Windows, the cbrserver file is located in \winnt\system32 directory.
Passive cookie affinity applies to the Dispatcher component's content-based routing (cbr) forwarding method and to the CBR component. See Dispatcher's content-based routing (cbr forwarding method) for information on how to configure Dispatcher's cbr forwarding method.
Passive cookie affinity provides a way to make clients sticky to a particular server. When you enable the affinity of a rule to "passivecookie", passive cookie affinity allows you to load-balance Web traffic with affinity to the same server, based on self-identifying cookies generated by the servers. You configure passive cookie affinity at the rule level.
When the rule fires, if passive cookie affinity is enabled, Load Balancer will choose the server based on the cookie name in the HTTP header of the client request. Load Balancer begins to compare the cookie name from the client's HTTP header to the configured cookie value for each server.
The first time Load Balancer finds a server whose cookie value contains the client's cookie name, Load Balancer chooses that server for the request.
If the cookie name in the client request is not found or does not match any of the content within the servers' cookie values, the server will be chosen using existing server selection or the weighted round-robin technique.
To configure passive cookie affinity:
The passive cookie affinity option, for the rule command, can only be set to passivecookie if port stickytime is zero (not enabled). Once passive cookie affinity is active on a rule then you cannot enable stickytime on the port.
URI affinity applies to Dispatcher's cbr forwarding method and the CBR component. See Dispatcher's content-based routing (cbr forwarding method) for information on how to configure the cbr forwarding method.
URI affinity allows you to load-balance Web traffic to Caching Proxy servers which allow unique content to be cached on each individual server. As a result, you will effectively increase the capacity of your site's cache by eliminating redundant caching of content on multiple machines. Configure URI affinity at the rule level. Once the rule fires, if URI affinity is enabled and the same set of servers are up and responding, then Load Balancer will forward new incoming client requests with the same URI to the same server.
Typically, Load Balancer can distribute requests to multiple servers that serve identical content. When using Load Balancer with a group of caching servers, frequently accessed content eventually becomes cached on all the servers. This supports a very high client load by replicating identical cached content on multiple machines. This is particularly useful for high volume Web sites.
However, if your Web site supports a moderate volume of client traffic to very diverse content, and you prefer to have a larger cache spread across multiple servers, your site would perform better if each caching server contained unique content and Load Balancer distributed the request only to the caching server with that content.
With URI affinity, Load Balancer allows you to distribute the cached content to individual servers, eliminating redundant caching of content on multiple machines. Performance for diverse-content server sites using Caching Proxy servers will be improved with this enhancement. It will send identical requests to the same server, thereby caching content on single servers only. And, the effective size of the cache will grow larger with each new server machine added to the pool.
To configure URI affinity:
The URI affinity option, for the rule command, can only be set to URI if port stickytime is zero (not enabled). Once URI affinity is active on a rule then you cannot enable stickytime on the port.
This feature is only available for the Dispatcher component.
If you are not using the Dispatcher's wide area support and not using Dispatcher's nat forwarding method, a Dispatcher configuration requires that the Dispatcher machine and its servers all be attached to the same LAN segment (see Figure 35). A client's request comes into the Dispatcher machine and is sent to the server. From the server, the response is sent directly back to the client.
Figure 35. Example of a configuration consisting of a single LAN segment
The wide area Dispatcher feature adds support for offsite servers, known as remote servers (see Figure 36). If GRE is not supported at the remote site and if Dispatcher's nat forwarding method is not being used, then the remote site must consist of a remote Dispatcher machine (Dispatcher 2) and its locally attached servers (ServerG, ServerH, and ServerI). A client's packet will go from the Internet to the initial Dispatcher machine. From the initial Dispatcher machine, the packet will then go to a geographically remote Dispatcher machine and one of its locally attached servers.
All the Dispatcher machines (local and remote) must be on the same type of operating system and platform in order to run wide area configurations.
Figure 36. 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.
To configure wide area support :
dscontrol server add cluster:port:server router address
For more information on the router keyword, see dscontrol server -- configure servers.
On entry-point Dispatchers:
Entry-point Dispatchers that are running on AIX, Linux (using GRE), or Solaris platforms will correctly display advisor loads. Other platforms will need to rely on either round-robin load balancing or use Dispatcher's nat/cbr forwarding methods instead of wide area networking.
AIX systems
HP-UX systems
Linux systems
Solaris systems
arp -s my_cluster_address my_mac_address pub
Windows systems
On remote Dispatchers: Perform the following configuration steps for each remote cluster address. For a high-availability configuration at the remote Dispatcher location, you must perform these steps on both machines.
AIX systems
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
HP-UX systems, Linux, Solaris, and Windows systems
Figure 37. Wide area example configuration with remote Load Balancers
This example applies to the configuration illustrated in Figure 37.
Here is how to configure the Dispatcher machines to support cluster address xebec on port 80. LB1 is defined as the "entry-point" Load Balancer. An ethernet connection is assumed. Note that LB1 has five servers defined: three local (ServerA, ServerB, ServerC) and two remote (LB2 and LB3). Remotes LB2 and LB3 each have three local servers defined.
At the console of the first Dispatcher (LB1), do the following:
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
At the console of the second Dispatcher (LB2):
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
At the console of the third Dispatcher (LB3):
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
Generic Routing Encapsulation (GRE) is an internet protocol specified in RFC 1701 and RFC 1702. Using GRE, the Load Balancer can encapsulate client IP packets inside IP/GRE packets and forward them to server platforms such as OS/390 that support GRE. GRE support allows the Dispatcher component to load balance packets to multiple server addresses associated with one MAC address.
Load Balancer implements GRE as part of its WAN feature. This allows Load Balancer to provide wide area load balancing directly to any server systems that can unwrap the GRE packets. Load Balancer does not need to be installed at the remote site if the remote servers support the encapsulated GRE packets. Load Balancer encapsulates WAN packets with the GRE key field set to decimal value 3735928559.
Figure 38. Wide area example configuration with server platform that supports GRE
For this example (Figure 38), to add remote ServerD, which supports GRE, define it within your Load Balancer configuration as if you are defining a WAN server in the cluster:port:server hierarchy:
dscontrol server add cluster:port:ServerD router Router1
Linux has the native ability to excapsulate GRE which allows Load Balancer to load balance to Linux/390 server images, where many server images share a MAC address. This permits the entry-point Load Balancer to load balance directly to Linux WAN servers, without passing through a Load Balancer at the remote site. This also allows the entry-point Load Balancer's advisors to operate directly with each remote server.
On the entry point Load Balancer, configure as described for WAN.
To configure each Linux back-end server, issue the following commands as root. (These commands may be added to the system's startup facility so that changes are preserved across reboots.)
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add cluster address dev gre-nd
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 bypassing 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(TM) 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: Configure the nonforwarding address using the executor configure command.
The servers added using the dscontrol server add command must be added using the private network addresses; for example, referring to the Apple server example in Figure 39, the command should be coded as:
dscontrol server add cluster_address:80:10.0.0.1
not
dscontrol server add cluster_address:80:9.67.131.18
If you are using Site Selector to provide load information to Dispatcher, you must configure Site Selector to report loads on the private addresses.
Figure 39. Example of a private network using Dispatcher
Using a private network configuration only applies to the Dispatcher component.
Using wildcard cluster to combine server configurations 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 wildcard cluster 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 dscontrol 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 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 Caching Proxy 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 Caching Proxy server residing on the same machine 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 Caching Proxy listening for client requests on port 80. You then configure a wildcard cluster (0.0.0.0). 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 Caching Proxy server running on the Dispatcher workstation. The client request will then be proxied as usual, and the response will be sent back from Caching Proxy 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:
dscontrol port add cluster:0
When configuring a cluster to handle passive FTP and the wildcard port, passive FTP by default utilizes the entire non-privileged TCP port range for data connections. This means a client, with an existing connection through a load-balancing cluster to an FTP control port, will have subsequent control connections and high port connections (port >1023) to the same cluster automatically routed by Load Balancer to the same server as the FTP control connection.
If the wildcard port and the FTP port on the same cluster do not have the same server set, then high port applications (port >1023) may fail when a client has an existing FTP control connection. Therefore, configuring different server sets for the FTP and wildcard ports on the same cluster is not recommended. If this scenario is desired, the FTP daemon passive port range must be configured in the Load Balancer configuration.
This feature is only available for the Dispatcher component.
Dispatcher provides the ability to detect potential "denial of service" attacks and notify administrators via an alert. Dispatcher does this by analyzing incoming requests for a conspicuous amount of half-open TCP connections on servers, a common trait of simple denial of service attacks. In a denial of service attack, a site receives a large quantity of fabricated SYN packets from a large number of source IP addresses and source port numbers, but the site receives no subsequent packets for those TCP connections. This results in a large number of half-opened TCP connections on the servers, and over time the servers can become very slow, accepting no new incoming connections.
Load Balancer provides user exits that trigger scripts which you can customize that alert the Administrator to a possible denial of service attack. Dispatcher provides the following sample script files in the ...ibm/edge/lb/servers/samples directory:
In order to run the files, you must move them to the ...ibm/edge/lb/servers/bin directory and remove the ".sample" file extension.
To implement the DoS attack detection, set the maxhalfopen parameter on the dscontrol port command as follows:
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
In the above example, Dispatcher will compare the current total number of half-open connections (for all servers residing on cluster 127.40.56.1 on port 80) with the threshold value of 1000 (specified by the maxhalfopen parameter). If the current half-open connections exceeds the threshold, then a call to an alert script (halfOpenAlert) is made. When the number of half-open connections drops below the threshold, a call to another alert script (halfOpenAlertDone) is made to indicate that the attack is over.
To determine how to set the maxhalfopen value: Periodically (perhaps every 10 minutes) run a half-open connection report (dscontrol port halfopenaddressreport cluster:port) when your site is experiencing normal to heavy traffic. The half-open connection report will return the current "total half-open connections received." You should set maxhalfopen to a value that is anywhere from 50 to 200% greater than the largest number of half-open connnections that your site experiences.
In addition to statistical data reported, the halfopenaddressreport will also generate entries in the log (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) for all the client addresses (up to approximately 8000 address pairs) that have accessed servers that resulted in half open connnections.
To provide additional protection from denial of service attacks for backend servers, you can configure wildcard clusters and ports. Specifically, under each configured cluster add a wildcard port with no servers. Also add a wildcard cluster with a wildcard port and no servers. This will have the effect of discarding all packets which are not addressed to a non-wildcard cluster and port. For information on wildcard clusters and wildcard ports, see Use wildcard cluster to combine server configurations and Use wildcard port to direct unconfigured port traffic.
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 dscontrol binlog 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 ...ibm/edge/lb/servers/samples/BinaryLog directory. 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:
dslogreport 2001/05/01 8:00 2001/05/01 17:00
to get a report of the Dispatcher component's server information from 8:00 AM to 5:00 PM on May 1, 2001. (For CBR, use cbrlogreport.)
This chapter includes the following sections:
Cisco CSS Controller or Nortel Alteon Controller can reside on the same machine as a server for which you are load balancing requests. This is commonly referred to as collocating a server. No additional configuration steps are required.
The high availability feature is now available for Cisco CSS Controller and Nortel Alteon Controller.
To improve controller fault tolerance, the high availability function contains these features:
See ccocontrol highavailability -- control high availability and nalcontrol highavailability -- control high availability for the complete syntax for xxxcontrol highavailability.
To configure controller high availability:
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondary
The address and partneraddress parameters are reversed on the primary and secondary machines.
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20
The same number of reach targets must be configured on the local and partner controllers.
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeover
This is necessary only for maintenance.
Notes:
In addition to the loss of connectivity between active and standby controllers, which is detected through the heartbeat messages, reachability is another failure detection mechanism.
When you configure controller high availability, you can provide a list of hosts that each of the controllers must reach to work correctly. There must be at least one host for each subnet that your controller machine uses. These hosts can be routers, IP servers, or other host types.
Host reachability is obtained by the reach advisor, which pings the host. Switchover takes place if the heartbeat messages cannot go through, or if the reachability criteria are better met by the standby controller than by the active controller. To make this decision based on all available information, the active controller regularly sends the standby controller its reachability capabilities and vice versa. The controllers then compare their reachability information with their partner's information and decide who should be active.
The roles of the two controller machines are configured as primary and secondary. At startup the controllers exchange information until each machine is synchronized. At this point, the primary controller moves to the active state and begins calculating weights and updating the switch, while the secondary machine moves to standby state and monitors the availability of the primary machine.
At any point if the standby machine detects that the active machine has failed, the standby machine performs a takeover of the active (failed) machine's load-balancing functions and becomes the active machine. When the primary machine is again operational, the two machines determine which controller will be active according to how recovery strategy is configured.
There are two kinds of recovery strategy:
The primary controller moves to the active state, calculating and updating weights, as soon as it becomes operational again. The secondary machine moves to standby after the primary is active.
The active secondary controller remains in active state, even after the primary controller is operational.
The primary controller moves to standby state and requires manual intervention to move to the active state.
The strategy parameter must be set the same for both machines.
For Cisco CSS Controller high availability configuration examples, see Examples.
For Nortel Alteon Controller high availability configuration examples, see Examples.
The controller function of Load Balancer performs load balancing based on the following settings:
You can change these settings to optimize load balancing for your network.
The controller can use some or all of the following metric collectors in its weighting decisions:
The default metrics are activeconn and connrate.
You can change the relative proportion of importance of the metric values. Think of the proportions as percentages; the sum of the relative proportions must equal 100%. By default, the active connections and new connections metrics are used and their proportions are set to 50/50. In your environment, you might need to try different metric proportion combinations to find the combination that gives the best performance.
To set the proportion values:
Weights are set based upon application response time and availability, feedback from the advisors, and feedback from a system-monitoring program, such as Metric Server. If you want to set weights manually, specify the fixedweight option for the server. For a description of the fixedweight option, see Controller fixed weights.
Weights are applied to all servers providing a service. For any particular service, 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.
If an advisor finds that a server has gone down, the weight for the server is set to -1. For Cisco CSS Controller and Nortel Alteon Controller the switch is informed that the server is not available and the switch stops assigning connections to the server.
Without the controller, advisors cannot run and cannot detect if a server is down. If you choose to run the advisors, but do not want the controller to update the weight you have set for a particular server, use the fixedweight option on the ccocontrol service command for Cisco CSS Controller or the nalcontrol server command for Nortel Alteon Controller.
Use the fixedweight command to set the weight to the value you desire. The server weight value remains fixed while the controller is running until you issue another command with fixedweight set to no.
To optimize overall performance, you can restrict how often metrics are collected.
The consultant sleeptime specifies how often the consultant updates the server weights. If the consultant sleeptime is too low, it can mean poor performance as a result of the consultant constantly interrupting the switch. If the consultant sleeptime is too high, it can mean that the switch's load balancing is not based on accurate, up-to-date information.
For example, to set the consultant sleeptime to 1 second:
xxxcontrol consultant set consultantID sleeptime interval
Other methods are available 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 providing a service is greater than the sensitivity threshold, the weights used by the load balancer to distribute connections are updated. Consider, for example, that the total weight changes from 100 to 105. The change is 5%. With the default sensitivity threshold of 5, the weights used by the load balancer are not updated, because the percentage change is not above the threshold. If, however, the total weight changes from 100 to 106, the weights are updated. To set the consultant's sensitivity threshold to a value other than the default, enter the following command:
xxxcontrol consultant set consultantID sensitivity percentageChange
In most cases, you will not need to change this value.
Advisors are agents within Load Balancer. Their purpose is to assess the health and load of server machines. They do this with a proactive client-like exchange with the servers. Consider advisors as lightweight clients of the application servers.
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 an HTTP "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, then use this value (in milliseconds) as the load.
Advisors then report the load value to the consultant function, where it appears in the consultant report. The consultant then calculates aggregate weight values from all its sources, per its proportions, and sends these weight values to the switch. The switch uses these weights for load balancing new incoming client connections.
If the advisor determines that a server is alive and well, it reports a positive, non-zero load number to the consultant. If the advisor determines that a server is not active, it returns a special load value of negative one (-1) to inform the switch that the server is down. Subsequently, the switch does not forward any further connections to that server until the server has come back up.
The advisor sleeptime sets how often an advisor asks for status from the servers on the port it is monitoring and then reports the results to the consultant. If the advisor sleeptime is too low, it can result in poor performance because the advisor constantly interrupts the servers. If the advisor sleeptime is too high, it can mean that the consultant's weighting decisions are not based on accurate, up-to-date information.
For example, to set the interval to 3 seconds for the HTTP advisor, type the following command:
xxxcontrol metriccollector set consultantID:HTTP sleeptime 3
You can set the amount of time an advisor takes to detect that a particular port on the server or service has failed. The failed-server timeout values, connecttimeout and receivetimeout, determine how long an advisor waits before reporting that either a connect or receive has failed.
To obtain the fastest failed-server detection, set the advisor connect and receive timeouts to the smallest value (one second), and set the advisor and consultant sleeptime to the smallest value (one second).
To set the timeoutconnect to 9 seconds for the HTTP advisor, type the following command:
xxxcontrol metriccollector set consultantID:HTTP timeoutconnect 9
The default for connect and receive timeout is 3 times the value specified for the advisor sleeptime.
Advisors have the ability to retry a connection before marking a server down. The advisor will not mark a server down until the server query has failed the number of retries plus 1. If not set the retry value defaults to zero.
For the Cisco CSS Controller, set the retry value using ccocontrol ownercontent set command. For more information, see ccocontrol ownercontent -- control the owner name and content rule.
For the Nortel Alteon Controller, set the retry value using nalcontrol service set command. For more information, see nalcontrol service -- configure a service.
The custom (customizable) advisor is a small piece of Java code that you provide as a class file, and is called by the base code. The base code provides all administrative services, such as:
It also reports results to the consultant. Periodically the base code performs 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 calls the getLoad method (function) in the custom advisor. The custom advisor then performs the necessary steps to evaluate the health of the server. Typically, it sends a user-defined message to the server and then waits 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 consultant.
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 consultant. 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 consultant. 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 to provide the precise information about servers that you need. A sample custom advisor, ADV_ctlrsample.java, is provided for the controllers. After installing Load Balancer, you can find the sample code in ...ibm/edge/lb/servers/samples/CustomAdvisors install directory.
The default install directories are:
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 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_ctrlsample inside the file to your new class name.
Custom advisors are written in Java language. You may use the Java 1.4 compiler that is installed with Load Balancer in the ...ibm/edge/java directory. The following files are referenced during compilation:
Your classpath must point to both the custom advisor file and the base classes file during the compile.
For Windows platform, a compile command might look like this:
javac -classpath install_dir\lb\servers\lib\ibmlb.jar ADV_pam.java
where:
The output for the compilation is a class file; for example:
ADV_pam.class
Before starting the advisor, copy the class file to the ...ibm/edge/lb/servers/lib/CustomAdvisors install directory.
For AIX, HP-UX, Linux , and Solaris, the syntax is similar.
To run the custom advisor, you must first copy the class file to the proper install directory:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_pam.class
Start the consultant, then issue this command to start your custom advisor:
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 consultant for use in the consultant'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.
These are base class methods:
The controllers first look at the provided list of native advisors; if they do not find a given advisor there, they look at the list of custom advisors.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Program Files\IBM\edge\lb\servers\lib\CustomAdvisors
The program listing for a controller sample advisor is included in Sample advisor. After installation, this sample advisor can be found in the ...ibm/edge/lb/servers/samples/CustomAdvisors directory.
Metric Server provides server load information to the Load Balancer in the form of system-specific metrics, reporting on the health of the servers. The Load Balancer consultant queries the Metric Server agent residing on each of the servers, assigning weights to the load balancing process using the metrics gathered from the agents. The results are also placed into the service report for Cisco CSS Controller or the server report for Nortel Alteon Controller.
The Metric Server agent must be installed and running on all servers that are being load balanced.
Below are the steps to configure Metric Server for the controllers.
For Nortel Alteon Controller, add a switch consultant, then add a service.
where metricName is the name of the metric server script.
The system metric script resides on the backend server and runs on each of the servers in the configuration under the specified ownercontent or service. Two scripts, cpuload and memload are provided, or you can create custom system metric scripts. The script contains a command that must return a numeric value. This numeric value represents a load measurement, not an availability value.
Limitation: For Windows, if the name of your system metric script has an extension other than .exe, you must specify the full name of the file; for example, mySystemScript.bat. This is a Java limitation.
Optionally, you can write your own customized metric script files that define the command that the Metric Server will issue on the server machines. Ensure that any custom scripts are executable and located in the ...ibm/edge/lb/ms/script directory. Custom scripts must return a numeric load value.
To have Metric Server run on an address other than the local host, edit the metricserver file on the load-balanced server machine. After java in the metricserver file, insert the following:
-Djava.rmi.server.hostname=OTHER_ADDRESS
In addition, before the "if" statements in the metricserver file, add this: hostname OTHER_ADDRESS.
For Windows: Alias the OTHER_ADDRESS on the Microsoft stack. To alias an address on the Microsoft stack, see page ***.
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, the controllers can accept capacity information from WLM and use it in the load balancing process. Using the WLM advisor, the controllers periodically open connections through the WLM port on each server in the consultant host table and accept the capacity integers returned. Since these integers represent the amount of capacity that is still available and the consultants expects values representing the loads on each machine, the capacity integers are inverted by the advisor and normalized into load values (for example, a large capacity integer but a small load value both represent a healthier server). There are several important differences between the WLM advisor and other controller advisors:
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.
The consultant must be running to log information in the binary logs.
Use the xxxcontrol consultant binarylog 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 consultant sends server information to the log server every consultant interval. The information is 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 consultant interval and the log interval. Since the log server is provided with information no faster than the consultant interval seconds, setting the log interval less than the consultant interval effectively sets it to the same as the consultant 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 consultant 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 are deleted by the log server. This occurs only if the log server is being called by the consultant, so if you stop the consultant, old log files are not deleted.
A sample Java program and command file are provided in the ...ibm/edge/lb/servers/samples/BinaryLog directory. 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.
Following is an example using the supplied script and program:
xxxlogreport 2002/05/01 8:00 2002/05/01 17:00
This produces a report of the controller's server information from 8:00 AM to 5:00 PM on May 1, 2002.
Load Balancer provides user exits that trigger scripts that you can customize. You can create the scripts to perform automated actions, such as alerting an Administrator when servers are marked down or simply record the event of the failure. Sample scripts, which you can customize, are in the ...ibm/edge/lb/servers/samples install directory. To run the files, copy them to the ...ibm/edge/lb/servers/bin directory, then rename each file according to the directions contained in the script.
The following sample scripts are provided, where xxx is cco for Cisco CSS Controller, and nal for Nortel Alteon Controller:
This part provides information on administering and troubleshooting Load Balancer. It contains the following chapters:
IMPORTANT: If you are using the Load Balancer for IPv6 installation, see Deploying Dispatcher on Load Balancer for IPv6 for limitations and configuration differences before viewing the contents of this chapter.
This chapter explains how to operate and manage Load Balancer and includes the following sections:
Load Balancer provides two different ways to run its configuration programs on a separate machine from the one on which the Load Balancer resides. Communication between the configuration programs (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) and the server (dsserver, cbrserver, etc.) can be performed by using either one of the following methods:
The advantage to remote administration using RMI is that performance is faster than Web-based administration.
The advantages to using Web-based administration is that it provides secure, authenticated, remote administration, and it can communicate to the Load Balancer machine even when a firewall is present. Also, this administration method does not require installation and use of authentication keys (lbkeys) on the remote client machine that is communicating with the Load Balancer machine.
For RMI, the command to connect to a Load Balancer machine for remote administration is dscontrol 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 the following command to generate public and private keys to be used for remote authentication:
This command runs only on the same machine as the Load Balancer.
Using the create option creates a private key in the servers key directory (...ibm/edge/lb/servers/key/) and creates public keys in the administration keys directory (...ibm/edge/lb/admin/keys/) for each of the Load Balancer components. The file name for the public key is: component-ServerAddress-RMIport. These public keys must then be transported to the remote clients and placed in the administration keys directory.
For a Load Balancer machine with hostname address 10.0.0.25 using the default RMI port for each component, the lbkeys create command generates the following files:
The administration fileset has been installed on another machine. The public key files must be placed in ...ibm/edge/lb/admin/keys directory on the remote client machine.
The remote client will now be authorized to configure Load Balancer on 10.0.0.25.
These same keys must be used on all remote clients that you want to authorize to configure Load Balancer on 10.0.0.25.
If you were to run the lbkeys 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 lbkeys delete command deletes the private and public keys on the server machine. If these keys are deleted, no remote clients will be authorized to connect to the servers.
For both lbkeys create and lbkeys delete there is a force option. The force option suppresses the command prompts that ask if you wish to overwrite or delete the existing keys.
Once you establish the RMI connection, you can communicate between the configuration programs using dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard, and sswizard commands from a command prompt. You can also configure Load Balancer via the GUI by typing lbadmin from a command prompt.
To use Web-based administration, the following is required on the client machine that performs remote administration:
The following is required on the host machine that you are accessing in order to perform remote Web-based administration:
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*where lang is your language subdirectory (for example, en_US)
For Linux and UNIX systems --
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/lang/*
ln -s /opt/perl/bin/perl /usr/bin/perl
In order to run Web-based administration, it must be started on the Load Balancer host machine: Issue lbwebaccess from the command prompt of the host machine.
The userID and password to the host machine that you are accessing remotely is also required. The userID and password are the same as the Caching Proxy administration userID and password.
To bring up Load Balancer's Web-based administration, access the following URL on the Web browser from the remote location:
http://host_name/lb-admin/lbadmin.html
Where host_name is the name of the machine you are accessing in order to communicate with Load Balancer.
Once the Web page is loaded, the Load Balancer GUI will appear in the browser window for you to perform remote Web-based administration.
From the Load Balancer GUI, you can also issue configuration control commands. In order to issue a command from the GUI:
Refreshing configuration remotely
With remote Web-based administration, if there are multiple administrators updating the Load Balancer configuration from other locations, you will need to refresh the configuration in order to view (for example) the cluster, port or server that has been added (or deleted) by another administrator. Remote Web-based administration GUI provides a Refresh Configuration and Refresh all Configurations function.
From the Web-based GUI, to refresh the configuration
Load Balancer posts entries to a server log, a manager log, a metric monitor log (logging communications with Metric Server agents), and a log for each advisor you use.
You can set the logging level to define the expansiveness of the messages written to the log. At level 0, errors are logged and Load Balancer 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 1 includes ongoing information, and so on, with level 5 including every message produced to aid in debugging a problem if necessary. The default for the manager, advisor, server, or subagent logs is 1.
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 1MB; 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 Load Balancer will be stored in the logs directory of the Load Balancer installation. To change this path, set the lb_logdir variable in the dsserver script.
AIX, HP-UX, Linux , and Solaris: The dsserver script is found in /usr/bin directory. In this script, the variable lb_logdir is set to the default directory. You can modify this variable to specify your log directory. Example:
LB_LOGDIR=/path/to/my/logs/
Windows: The dsserver file is found in the Windows system directory C:\WINNT\SYSTEM32, for Windows 2003. In the dsserver file, the variable lb_logdir is set to the default directory. You can modify this variable to specify your log directory. Example:
set LB_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 Load Balancer uses the same log directory as the other log files. See Using binary logging to analyze server statistics.
You can set the logging level to define the expansiveness of the messages written to the log. At level 0, errors are logged and Load Balancer also logs headers and records of events that happen only once (for example, a message about an advisor starting to be written to the consultant log). Level 1 includes ongoing information, and so on, with level 5 including every message produced to aid in debugging a problem if necessary. The default for the logs is 1.
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 1MB; however, when logging at level 3 and above, you should limit the size without making it too small to be useful.
Cisco CSS Controller and Nortel Alteon Controller have logs as follows:
The following is an example of configuring the logging level and maximum log size for the metric monitor log that logs communication with Metric Server agents:
xxxcontrol metriccollector set consultantID:serviceID:metricName loglevel x logsize y
By default, the logs generated by the controllers are stored in the logs directory of the controller installation. To change this path, set the xxx_logdir variable in the xxxserver script.
AIX, HP-UX, Linux , and Solaris: The xxxserver script is found in /usr/bin directory. In this script, the variable xxx_logdir is set to the default directory. You can modify this variable to specify your log directory. Example:
xxx_LOGDIR=/path/to/my/logs/
Windows: The xxxserver file is found in the Windows system directory, typically C:\WINNT\SYSTEM32. In the xxxserver file, the variable xxx_logdir is set to the default directory. You can modify this variable to specify your log directory. Example:
set xxx_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 Load Balancer uses the same log directory as the other log files. See Using binary logging to analyze server statistics.
This section explains how to operate and manage the Dispatcher component.
For Load Balancer, connections are considered stale when there has been no activity on that connection for the number of seconds specified in stale timeout. When the number of seconds has been exceeded with no activity, Load Balancer will remove that connection record from its tables, and subsequent traffic for that connection will be discarded.
At the port level, for example, you can specify the stale timeout value on the dscontrol port set staletimeout command.
Stale timeout can be set at the executor, cluster, and port levels. At the executor and cluster levels, the default is 300 seconds and it filters down to the port. At the port level, the default depends on the port. Some well defined ports have different default stale timeout values. For example, the telnet port 23 has a default of 259,200 seconds.
Some services may also have staletimeout values of their own. For example, LDAP (Lightweight Directory Access Protocol) has a configuration parameter called idletimeout. When idletimeout seconds have been exceeded, an idle client connection will be forcibly closed. Idletimeout may also be set to 0, which means that the connection will never be forcibly closed.
Connectivity problems can occur when Load Balancer's stale timeout value is smaller than the service's timeout value. In the case of LDAP, the Load Balancer staletimeout value defaults to 300 seconds. If there is no activity on the connection for 300 seconds, Load Balancer will remove the connection record from its tables. If the idletimeout value is larger than 300 seconds (or set to 0), the client may still believe that it has a connection to the server. When the client sends packets, the packets will be discarded by Load Balancer. This will cause LDAP to hang when a request is made to the server. To avoid this problem, set the LDAP idletimeout to a nonzero value that is the same or smaller than the Load Balancer staletimeout value.
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.
To improve the performance of connection record allocation and reuse, use the executor set fintimeout command to control the period during which Dispatcher should keep connections in the FIN state, active in the Dispatcher tables and accepting traffic. Once a connection in the FIN state exceeds fintimeout, it will be removed from the Dispatcher tables and ready for reuse. You can change the FIN timeout using the dscontrol executor set fincount command.
Use the dscontrol executor set staletimeout command to control the period during which Dispatcher should keep connections in the Established state when no traffic has been seen active in the Dispatcher tables and accepting traffic. See Using stale timeout value for more information.
Various charts can be displayed based on information from the executor and relayed to the manager. (The GUI Monitor menu option requires that the manager function is running):
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(R) NetView(R), 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 gets installed in the ..lb/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 Program Interface (DPI(R)) capability. DPI is an interface between an SNMP agent and its subagents. Windows operating system uses the Windows extension agent as an interface between an SNMP agent and its subagents.
Figure 40. SNMP commands for Linux and UNIX systems
AIX provides an SNMP agent that uses SNMP Multiplexer protocol (SMUX) and provides DPID2, which is an additional executable that works as a translator between DPI and SMUX.
For HP-UX, you must obtain an SNMP agent that is SMUX-enabled since HP-UX does not provide one. Load Balancer provides DPID2 for HP-UX.
Linux provides an SNMP agent that uses SMUX. Most of the Linux versions (for example, Red Hat) come with a UCD SNMP package. UCD SNMP version 4.1 or later has SMUX enabled agents. Load Balancer provides DPID2 for Linux.
For Solaris, you must obtain an SNMP agent that is SMUX-enabled since Solaris does not provide one. Load Balancer provides DPID2 for Solaris in the /opt/ibm/edge/lb/servers/samples/SNMP 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:
For AIX and Solaris:
"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
For Linux:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Also, you must comment all lines in the snmpd.conf file that begin with the following words: com2sec, group, view or access.
To install HP-UX SNMP support:
In order to use Load Balancer SNMP with SuSE Linux, you must do the following:
Refresh snmpd (if it is already running) so that it will reread the snmpd.conf file:
refresh -s snmpd
Start the DPID SMUX peer:
dpid2
The daemons must be started in the following order:
To install Solaris SNMP support:
/etc/rc3.d/S76snmpdx to /etc/rc3.d/K76snmpdx
/etc/rc3.d/S77dmi to /etc/rc3.d/K77dmi
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /usr/local/lib:/usr/local/ssl/lib:/usr/lib
export PATH=/usr/local/sbin:/usr/local/bin:$PATH
export SNMPCONFPATH =/etc/snmp
export MIBDIRS=/usr/local/share/snmp/mibs
cp /opt/ibm/edge/lb/servers/samples/SNMP/dpid2 /usr/local/sbin/dpid2
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Notes:
On the http://sunfreeware.com/ Web site, the names have an extension of .gz, so do not try to gunzip/untar them. Instead, use pkgadd packageName.
To install the Windows SNMP support:
With the executor running, use the dscontrol subagent start [communityname] command to define the community name used between the Windows OS Extension agent and the SNMP agent.
IMPORTANT: On Windows 2003, by default SNMP does not respond to any community names presented. In such case, the SNMP subagent will not respond to any SNMP requests. To ensure that the SNMP subagent will respond to the community name, you must set SNMP Service Properties with the appropriate community name and destination host(s). Configure SNMP security properties as follows:
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 the following 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 csID (cluster ID), psNum (port number), and ssID (server ID) 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.
The indDOSAttack trap indicates that numhalfopen, the number of half-open connections consisting only of SYN packets, has exceeded the maxhhalfopen threshold for the port specified by the csID (cluster ID) and psNum (port number) portion of the Object Identifier. The number of servers configured on the port is sent in the trap. This trap indicates that Load Balancer may be experiencing a Denial Of Service Attack.
The indDOSAttackDone trap indicates that numhalfopen, the number of half-open connections consisting only of SYN packets, has fallen below the maxhalfopen threshold for the port specified by the csID and psNum portion of the Object Identifier. The number of servers configured on the port is sent in the trap. When Load Balancer determines that the possible Denial of Service attack is over, this trap will be sent after an indDOSAttack trap is sent.
For Linux and UNIX systems, 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 dscontrol subagent start command turns the SNMP support on. The dscontrol subagent stop command turns the SNMP support off.
For more information about the dscontrol command, see dscontrol subagent -- configure SNMP subagent.
Built into the Linux kernel is a firewall facility called ipchains. When Load Balancer and ipchains run concurrently, Load Balancer sees packets first, followed by ipchains. This allows the use of ipchains to harden a Linux Load Balancer machine, which could be, for example, a Load Balancer machine that is used to load balance firewalls.
When ipchains or iptables are configured as completely restricted (no inbound or outbound traffic permitted), the packet-forwarding portion of Load Balancer continues to function normally.
Note that ipchains and iptables cannot be used to filter incoming traffic before it is load balanced.
Some additional traffic must be permitted for all of Load Balancer to function properly. Some examples of this communication are:
In general, an appropriate ipchains strategy for the Load Balancer machines is to disallow all traffic, except that which is to or from the back-end servers, the partner high availability Load Balancer, any reach targets, or any configuration hosts.
It is not recommended to activate iptables when running Load Balancer on Linux kernel version 2.4.10.x. Activation on this Linux kernel version can result in performance degradation over time.
To deactivate iptables, list the modules (lsmod) to see which modules are using ip_tables and ip_conntrack, then remove them by issuing rmmod ip_tables and rmmod ip_conntrack. When you reboot the machine these modules will be added again, so you will need to repeat these step each time you reboot.
This section explains how to operate and manage the CBR component of Load Balancer.
CBR and Caching Proxy collaborate via the Caching Proxy plug-in API to handle HTTP and HTTPS (SSL) request. Caching Proxy must be running on the same machine in order for CBR to begin load balancing servers. Set up CBR and Caching Proxy as described in CBR configuration example.
After starting CBR, you can control it using either of the following methods:
The logs used by CBR are similar to those used in Dispatcher. For more information, see Using Load Balancer logs.
After starting Site Selector, you can control it using either of the following methods:
The logs used by Site Selector are similar to those used in Dispatcher. For more description, see Using Load Balancer logs.
After starting Cisco CSS Controller, you can control it using either of the following methods:
The logs used by Cisco CSS Controller are similar to those used in Dispatcher. For more description, see Using Load Balancer logs.
After starting Nortel Alteon Controller, you can control it using either of the following methods:
The logs used by Nortel Alteon Controller are similar to those used in Dispatcher. For more description, see Using Load Balancer logs.
Metric Server provides server load information to the Load Balancer. Metric Server resides on each of the servers that are being load balanced.
Change the log level in the Metric Server startup script. You can specify a log level range of 0 through 5, similar to the log level range in Load Balancer logs. This will generate an agent log in the ...ms/logs directory.
This chapter helps you detect and resolve problems associated with Load Balancer.
Use the information in this section to gather the data that IBM service requires. The information is divided into the following subjects.
For the Dispatcher component only, there is a problem determination tool that automatically gathers operating system-specific data and component-specified configuration files. To run this tool, type lbpd from the appropriate directory:
For Linux and UNIX systems: /opt/ibm/edge/lb/servers/bin/
For Windows platform: C:\Program Files\IBM\edge\lb\servers\bin
This problem determination tool packages the data into files as follows:
For Linux and UNIX systems: /opt/ibm/edge/lb/lbpmr.tar.Z
For Windows platform: C:\Program Files\IBM\edge\lb\lbpmr.zip
Before you call IBM service, have the following information available.
dscontrol file save primary.cfg
This command places the configuration file in .../ibm/edge/lb/servers/configuration/component/ directory.
java -fullversion
On AIX, HP-UX, Linux , and Solaris: netstat -ni
On Windows: ipconfig /all
This is required from all servers and Load Balancer.
On AIX, HP-UX, Linux , and Solaris: netstat -nr
On Windows: route print
This is required from all servers and Load Balancer.
Gather the following required information for problems in an HA environment.
AIX, HP-UX, Linux, and Solaris platforms: /opt/ibm/edge/lb/servers/bin
Windows: C:\Program Files\ibm\edge\lb\servers\bin
The script names are:
goActive
goStandby
goIdle (if present)
goInOp (if present)
Also include the configuration files. See General information (always required).
Gather the following required information for advisor problems; for example, when advisors are mistakenly marking servers as down.
dscontrol advisor loglevel http 80 5
or
dscontrol advisor loglevel advisorName port loglevel
or
dscontrol advisor loglevel advisorName cluster:port loglevel
or
nalcontrol metriccollector set consultantID:serviceID:metricName loglevel value
This creates a log named ADV_advisorName log; for example, ADV_http.log. This log is located as follows:
AIX, HP-UX, Linux, and Solaris platforms: /opt/ibm/edge/lb/servers/logs/component
Windows platform: C:\Program Files\ibm\edge\lb\servers\logs\component
Where component is:
dispatcher = Dispatcher
cbr = Content Based Routing
cco = Cisco CSS Controller
nal = Nortel Alteon Controller
ss = Site Selector
The ADVLOG call prints statements to the advisors log file when the level is less than the logging level associated with the advisors. A logging level of 0 will cause the statement to always be written. You cannot use ADVLOG from the constructor. The log file is not created until immediately after the custom advisor's constructor has completed because the log file name depends on information that is set in the constructor.
There is another way to debug your custom advisor that will avoid this limitation. You can use System.out.println(message) statements to print messages to a window. Edit the dsserver script and change javaw to java for the print statements to appear in the window. The window used to start dsserver must be kept open for the prints to appear. If you are using Windows platform, you must stop the Dispatcher from running as a service and manually start it from a window to see the messages.
Refer to Programming Guide for Edge Components for more information on ADVLOG.
Gather the following required information for Content Based Routing problems.
Linux and UNIX systems: /etc/
Windows platform: C:\Program Files\IBM\edge\cp\etc\en_US\
Linux and UNIX systems: /opt/ibm/edge/lb/servers/configurations/cbr
Windows platform: C:\Program Files\IBM\edge\lb\servers\configurations\cbr
If you are not able to hit the cluster, it is possible that neither or both of the Load Balancer machines have the cluster aliased. To determine which machine owns the cluster:
ping cluster arp -aIf you are using Dispatcher's nat or cbr forwarding methods, ping the return address also.
On AIX and HP-UX: netstat -ni
On Linux and Solaris: ifconfig -a
On Windows: ipconfig /all
If you do not get a response from the ping, it is possible that neither machine has the cluster IP address aliased to its interface; for example, en0, tr0, and so forth.
If you are unable to solve routing problems and all else has failed, issue the following command to run a trace on the network traffic:
iptrace -a -s failingClientIPAddress -d clusterIPAddress -b iptrace.trc
Run the trace, recreate the problem, then kill the process.
tcpdump -i lan0 host cluster and host client
You may need to download tcpdump from one of the HP-UX GNU software archive sites.
tcpdump -i eth0 host cluster and host client
Run the trace, recreate the problem, then kill the process.
snoop -v clientIPAddress destinationIPAddress > snooptrace.out
You can also increase different log levels (for example, manager log, advisor log and so forth.) and investigate their output.
To identify a problem that is already fixed in a service release fix or patch, check for upgrades. To obtain a list of Edge Components defects fixed, refer to the WebSphere Application Server Web site Support page: http://www.ibm.com/software/webservers/appserv/was/support/. From the Support page, follow the link to the corrective service download site.
The correct version of Java code is installed as part the Load Balancer installation.
See Reference Information for links to support and library Web pages. The Web support page contains a link to Self-help information in the form of Technotes.
Refer to the following for:
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 |
Client machines are not being served or are timing out | High availability not working | Problem: Dispatcher high-availability function is not working |
Unable to add heartbeat (Windows platform) | Source address is not configured on an adapter | Problem: Unable to add heartbeat (Windows platform) |
Server not serving requests (Windows platform) | An extra route has been created in the routing table | Problem: Extra routes (Windows 2000) |
Advisors not working correctly with wide area | Advisors are not running on remote machines | Problem: Advisors not working correctly |
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 platform) |
Connection to remote machine refused | Older version of the keys is still being used | Problem: Dispatcher connection to a remote machine |
The dscontrol or lbadmin command fails with 'Server not responding' or 'unable to access RMI server' message |
| Problem: dscontrol or lbadmin command fails |
"Cannot Find the File..." error message, when running Netscape as default browser to view online help (Windows platform) | Incorrect setting for HTML file association | Problem: "Cannot find the file... error message when trying to view online Help (Windows platform) |
Graphical user interface does not start correctly | Insufficient paging space | Problem: Graphical user interface (GUI) does not start correctly |
Error running Dispatcher with Caching Proxy installed | Caching Proxy file dependency | Problem: Error running Dispatcher with Caching Proxy installed |
Graphical user interface does not display correctly. | Resolution is incorrect. | Problem: Graphical user interface (GUI) does not display correctly |
Help panels sometimes disappear behind other windows | Java limitation | Problem: On Windows platform, help windows sometimes disappear behind other open windows |
Load Balancer cannot process and forward a frame | Need a unique MAC address for each NIC | Problem: Load Balancer cannot process and forward a frame |
Blue screen appears | No installed and configured network card | Problem: A blue screen displays when you start the Load Balancer executor |
Path to Discovery prevents return traffic | The cluster is aliased on the loopback | Problem: Path to Discovery prevents return traffic with Load Balancer |
Advisors show that all servers are down when using task offload feature | TCP checksum is not computed correctly | Problem: Advisors show that all servers are down when task offload enabled (Windows platform) |
High availability in the Wide Area mode of Load Balancer does not work. | Remote Dispatcher must be defined as a server in a cluster on local Dispatcher | Problem: High availability in the Wide Area mode of Load Balancer does not work |
GUI hangs (or unexpected behavior) when trying to load a large configuration file. | Java does not have access to enough memory to handle such a large change to the GUI | Problem: GUI hangs (or unexpected behavior) when trying to load a large configuration file |
IP addresses not resolving correctly over the remote connection | When using a remote client over a secure socks implementation, fully-qualified domain names or host names might not resolve to the correct IP address | Problem: IP addresses not resolving correctly over the remote connection |
Korean Load Balancer interface displays overlapping or undesirable fonts on AIX and Linux | Default fonts must be changed | Problem: Korean Load Balancer interface displays overlapping or undesirable fonts on AIX and Linux |
On Windows, after aliasing the MS Loopback adapter, when issuing certain commands such as hostname, the OS will incorrectly respond with the alias address | In the network connections list, the newly added alias must not be listed above the local address | Problem: On Windows, alias address is returned instead of local address when issuing commands such as hostname |
Unexpected GUI behavior when using Windows platform paired with Matrox AGP video card | Problem occurs when using Matrox AGP video cards while running the Load Balancer GUI | Problem: On Windows platform, unexpected GUI behavior when using Matrox AGP video cards |
Unexpected behavior, such as system hang, when executing "rmmod ibmlb" on Linux | Problem occurs when manually removing the Load Balancer kernel module (ibmlb). | Problem: Unexpected behavior when executing rmmod ibmlb (Linux) |
Slow response time when running commands on the Dispatcher machine | Slow response time can be due to machine overloading from a high volume of client traffic | Problem: Slow response time running commands on Dispatcher machine |
For Dispatcher's mac forwarding method, SSL or HTTPS advisor not registering server loads | Problem occurs because the SSL server application not configured with the cluster IP address | Problem: SSL or HTTPS advisor not registering server loads (when using mac-forwarding) |
Disconnect from host when using remote Web administration via Netscape | Disconnect from host will occur when resize the browser window | Problem: Disconnect from host occurs when resize Netscape browser window while using Web administration |
Socket pooling is enabled and the Web server is binding to 0.0.0.0 | Configure the Microsoft IIS server to be bind specific | Problem: Socket pooling is enabled and the Web server is binding to 0.0.0.0 |
On Windows platform, corrupted Latin-1 national characters appear in command prompt | Change font properties of command prompt window | Problem: On Windows, corrupted Latin-1 national characters appear in command prompt window |
On HP-UX platform, the following message occurs: java.lang.OutOfMemoryError unable to create new native thread | Some HP-UX installations by default allow 64 threads per process. This is insufficient. | Problem: On HP-UX, Java out of memory/ thread error occurs |
On Windows platform, advisors and reach targets mark all servers down | Task offloading is not disabled or may need to enable ICMP. | Problem: On Windows, advisors and reach targets mark all servers down |
On Windows platform, problem resolving IP address to hostname when more than one address is configured to an adapter | The IP address you want as your hostname must appear first in the registry. | Problem: On Windows, resolving IP address to host name when more than one address is configured to an adapter |
On Windows platform, advisors not working in a high availability setup after a network outage | When the system detects a network outage, it clears its Address Resolution Protocol (ARP) cache | Problem: On Windows, after network outage, advisors not working in a high availability setup |
On Linux, "IP address add" command and multiple cluster loopback aliases are incompatible | When aliasing more than one address on the loopback device, should use ifconfig command, not ip address add | Problem: On Linux, do not use IP address add command when aliasing multiple clusters on the loopback device |
Error message: "Router address not specified or not valid for port method" when trying to add a server | Checklist of information to determine the problem that has occurred when adding a server | Problem: Router address not specified or not valid for port method error message |
On Solaris, Load Balancer processes end when you exit the terminal session window from which they started | Use the nohup command to prevent the processes that you started from receiving a hangup signal when you exit the terminal session. | Problem: On Solaris, Load Balancer processes end when you exit the terminal window from which they started |
Slow down occurs when loading large Load Balancer configurations | Setting the address parameter on the server add command slows down the loading of large configurations | Problem: Setting the address parameter on server add command slows down loading large configurations |
On Windows, the following error message appears: There is an IP address conflict with another system on the network | If high availability is configured, cluster addresses may be configured on both machines for a brief period which causes this error message to appear. | Problem: On Windows, an IP address conflict error message appears |
Both primary and backup machines are active in a high availability configuration | This problem may occur when the go scripts do not run on either primary or backup machine. | Problem: Both primary and backup machines are active in a high availability configuration |
Client requests fail when Dispatcher attempts to return large page responses | Client requests that result in large page responses timeout if the maximum transmit unit (MTU) is not set properly on the Dispatcher machine when using nat or cbr forwarding. | Problem: Client requests fail when attempting the return of large page responses |
On Windows systems, "Server not responding" error occurs when issuing a dscontrol or lbadmin command | When more than one IP address exists on a Windows system and the host file does not specify the address to associate with the hostname. | Problem: On Windows systems, Server not responding error occurs when issuing dscontrol or lbadmin |
High availability Dispatcher machines may fail to synchronize on Linux for S/390 on qeth devices | When using high availability on S/390 Linux with the qeth network driver, the active and standby Dispatchers may fail to synchronize. | Problem: High availability Dispatcher machines may fail to synchronize on Linux for S/390 systems on qeth drivers |
Table 15. CBR Troubleshooting table
Symptom | Possible Cause | Go to... |
CBR not running correctly | Conflicting port numbers | Checking CBR port numbers |
The cbrcontrol or lbadmin command fails with 'Server not responding' or 'unable to access RMI server' message | Commands fail due to socksified stack. Or commands fail due to not starting cbrserver | Problem: cbrcontrol or lbadmin command fails |
Requests are not being load balanced | Caching Proxy was started before the executor was started | Problem: Requests not being load balanced |
On Solaris, the cbrcontrol executor start command fails with 'Error: Executor was not started.' message | Command fails because the system IPC defaults may need to be modified, or link to library is incorrect. | Problem: On Solaris, cbrcontrol executor start command fails |
URL rule doesn't work | Syntactical or configuration error | Problem: Syntactical or configuration error |
Unexpected GUI behavior when using Windows system paired with Matrox AGP video card | Problem occurs when using Matrox AGP video cards while running the Load Balancer GUI | Problem: On Windows platform, unexpected GUI behavior when using Matrox AGP video cards |
GUI hangs (or unexpected behavior) when trying to load a large configuration file. | Java does not have access to enough memory to handle such a large change to the GUI | Problem: GUI hangs (or unexpected behavior) when trying to load a large configuration file |
Disconnect from host when using remote Web administration via Netscape | Disconnect from host will occur when resize the browser window | Problem: Disconnect from host occurs when resize Netscape browser window while using Web administration |
On Windows platform, corrupted Latin-1 national characters appear in command prompt | Change font properties of command prompt window | Problem: On Windows platform, corrupted Latin-1 national characters appear in command prompt window |
On HP-UX platform, the following message occurs: java.lang.OutOfMemoryError unable to create new native thread | Some HP-UX installations by default allow 64 threads per process. This is insufficient. | Problem: On HP-UX, Java out of memory/ thread error occurs |
On Windows platform, advisors and reach targets mark all servers down | Task offloading is not disabled or may need to enable icmp. | Problem: On Windows, advisors and reach targets mark all servers down |
On Windows platform, problem resolving IP address to host name when more than one address is configured to an adapter | The IP address you want as your hostname must appear first in the registry. | Problem: On Windows, resolving IP address to host name when more than one address is configured to an adapter |
On Solaris, Load Balancer processes end when you exit the terminal session window from which they started | Use the nohup command to prevent the processes that you started from receiving a hangup signal when you exit the terminal session. | Problem: On Solaris, Load Balancer processes end when you exit the terminal window from which they started |
Table 16. Site Selector troubleshooting table
Symptom | Possible Cause | Go to... |
---|---|---|
Site Selector not running correctly | Conflicting port number | Checking Site Selector port numbers |
Site Selector does not round-robin incoming requests from Solaris client | Solaris systems run a "name service cache daemon" | Problem: Site Selector doesn't round-robin traffic from Solaris clients |
The sscontrol or lbadmin command fails with 'Server not responding' or 'unable to access RMI server' message | Commands fail due to socksified stack. Or commands fail due to not starting ssserver. | Problem: sscontrol or lbadmin command fails |
ssserver fails to start on Windows platform | Windows does not require the host name to be in the DNS. | Problem: The ssserver is failing to start on Windows platform |
Machine with duplicate routes not load balancing correctly -- name resolution appears to fail | Site Selector machine with multiple adapters attached to the same subnet | Problem: Site Selector with duplicate routes not load balancing correctly |
Unexpected GUI behavior when using Windows platform paired with Matrox AGP video card | Problem occurs when using Matrox AGP video cards while running the Load Balancer GUI | Problem: On Windows platform, unexpected GUI behavior when using Matrox AGP video cards |
GUI hangs (or unexpected behavior) when trying to load a large configuration file. | Java does not have access to enough memory to handle such a large change to the GUI | Problem: GUI hangs (or unexpected behavior) when trying to load a large configuration file |
Disconnect from host when using remote Web administration via Netscape | Disconnect from host will occur when resize the browser window | Problem: Disconnect from host occurs when resize Netscape browser window while using Web administration |
On Windows platform, corrupted Latin-1 national characters appear in command prompt | Change font properties of command prompt window | Problem: On Windows platform, corrupted Latin-1 national characters appear in command prompt window |
On HP-UX platform, the following message occurs: java.lang.OutOfMemoryError unable to create new native thread | Some HP-UX installations by default allow 64 threads per process. This is insufficient. | Problem: On HP-UX, Java out of memory/ thread error occurs |
On Windows platform, advisors and reach targets mark all servers down | Task offloading is not disabled or may need to enable icmp. | Problem: On Windows, advisors and reach targets mark all servers down |
On Solaris, Load Balancer processes end when you exit the terminal session window from which they started | Use the nohup command to prevent the processes that you started from receiving a hangup signal when you exit the terminal session. | Problem: On Solaris, Load Balancer processes end when you exit the terminal window from which they started |
Table 17. Controller for Cisco CSS Switches troubleshooting table
Symptom | Possible Cause | Go to... |
---|---|---|
ccoserver will not start | Conflicting port numbers | Checking Cisco CSS Controller port numbers |
The ccocontrol or lbadmin command fails with 'Server not responding' or 'unable to access RMI server' message | Commands fail due to socksified stack. Or commands fail due to not starting ccoserver. | Problem: ccocontrol or lbadmin command fails |
receive error: Cannot create registry on port 13099 | Expired product license | Problem: Cannot create registry on port 13099 |
Unexpected GUI behavior when using Windows platform paired with Matrox AGP video card | Problem occurs when using Matrox AGP video cards while running the Load Balancer GUI | Problem: On Windows platform, unexpected GUI behavior when using Matrox AGP video cards |
Received a connection error when adding a consultant | Configuration settings are incorrect on the switch or the controller | Problem: Received a connection error when adding a consultant |
Weights are not being updated on the switch | Communication between the controller or the switch is unavailable or interrupted | Problem: Weights are not being updated on the switch |
Refresh command did not update the consultant configuration | Communication between the switch and the controller is unavailable or interrupted | Problem: Refresh command did not update the consultant configuration |
GUI hangs (or unexpected behavior) when trying to load a large configuration file. | Java does not have access to enough memory to handle such a large change to the GUI | Problem: GUI hangs (or unexpected behavior) when trying to load a large configuration file |
Disconnect from host when using remote Web administration via Netscape | Disconnect from host will occur when resize the browser window | Problem: Disconnect from host occurs when resize Netscape browser window while using Web administration |
On Windows platform, corrupted Latin-1 national characters appear in command prompt | Change font properties of command prompt window | Problem: On Windows platform, corrupted Latin-1 national characters appear in command prompt window |
On HP-UX platform, the following message occurs: java.lang.OutOfMemoryError unable to create new native thread | Some HP-UX installations by default allow 64 threads per process. This is insufficient. | Problem: On HP-UX, Java out of memory/ thread error occurs |
On Solaris, Load Balancer processes end when you exit the terminal session window from which they started | Use the nohup command to prevent the processes that you started from receiving a hangup signal when you exit the terminal session. | Problem: On Solaris, Load Balancer processes end when you exit the terminal window from which they started |
Table 18. Nortel Alteon Controller troubleshooting table
Symptom | Possible Cause | Go to... |
---|---|---|
nalserver will not start | Conflicting port numbers | Checking Nortel Alteon Controller port numbers |
The nalcontrol or lbadmin command fails with 'Server not responding' or 'unable to access RMI server' message | Commands fail due to socksified stack. Or commands fail due to not starting nalserver. | Problem: nalcontrol or lbadmin command fails |
receive error: Cannot create registry on port 14099 | Expired product license | Problem: Cannot create registry on port 14099 |
Unexpected GUI behavior when using Windows platform paired with Matrox AGP video card | Problem occurs when using Matrox AGP video cards while running the Load Balancer GUI | Problem: On Windows platform, unexpected GUI behavior when using Matrox AGP video cards |
GUI hangs (or unexpected behavior) when trying to load a large configuration file. | Java does not have access to enough memory to handle such a large change to the GUI | Problem: GUI hangs (or unexpected behavior) when trying to load a large configuration file |
Disconnect from host when using remote Web administration via Netscape | Disconnect from host will occur when resize the browser window | Problem: Disconnect from host occurs when resize Netscape browser window while using Web administration |
Received a connection error when adding a consultant | Configuration settings are incorrect on the switch or the controller | Problem: Received a connection error when adding a consultant |
Weights are not being updated on the switch | Communication between the controller or the switch is unavailable or interrupted | Problem: Weights are not being updated on the switch |
Refresh command did not update the consultant configuration | Communication between the switch and the controller is unavailable or interrupted | Problem: Refresh command did not update the consultant configuration |
On Windows platform, corrupted Latin-1 national characters appear in command prompt | Change font properties of command prompt window | Problem: On Windows, corrupted Latin-1 national characters appear in command prompt window |
On HP-UX platform, the following message occurs: java.lang.OutOfMemoryError unable to create new native thread | Some HP-UX installations by default allow 64 threads per process. This is insufficient. | Problem: On HP-UX, Java out of memory/ thread error occurs |
On Solaris, Load Balancer processes end when you exit the terminal session window from which they started | Use the nohup command to prevent the processes that you started from receiving a hangup signal when you exit the terminal session. | Problem: On Solaris, Load Balancer processes end when you exit the terminal window from which they started |
Table 19. Metric Server troubleshooting table
Symptom | Possible Cause | Go to... |
---|---|---|
Metric Server IOException on Windows platform running .bat or .cmd user metric files | Full metric name is required | Problem: Metric Server IOException on Windows platform running .bat or .cmd user metric files |
Metric Server not reporting the load information to the Load Balancer machine | Possible causes include:
| Problem: Metric Server not reporting loads to Load Balancer machine |
Metric Server log reports "Signature is necessary for access to agent" when key files transferred to server | Key file fails authorization due to corruption. | Problem: Metric Server log reports Signature is necessary for access to agent |
On AIX, when running Metric Server under heavy stress on a multi-processor system (4.3.3, 32-bit 5.1, or 64-bit 5.1), ps -vg command output may become corrupted | APAR IY33804 corrects this known AIX problem | Problem: On AIX, while running Metric Server under heavy stress, ps -vg command output may become corrupted |
Configuring Metric Server in a two-tier configuration with Site Selector load-balancing across high-availability Dispatchers | Metric Server (residing in the second-tier) is not configured to listen on a new IP address. | Problem: Configuring Metric Server in a two-tier configuration with Site Selector load-balancing across high-availability Dispatchers |
Scripts (metricserver, cpuload, memload) running on multi-CPU Solaris machines produce unwanted console messages | This behavior is due to the use of the VMSTAT system command to gather CPU and memory statistics from the kernel. | Problem: Scripts, running on multi-CPU Solaris machines, produce unwanted console messages |
On Solaris, Load Balancer processes end when you exit the terminal session window from which they started | Use the nohup command to prevent the processes that you started from receiving a hangup signal when you exit the terminal session. | Problem: On Solaris, Load Balancer processes end when you exit the terminal window from which they started |
If you are experiencing problems running 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's port numbers, you can either change the Dispatcher's port numbers or change the application's port number.
Change the Dispatcher's port numbers by doing the following:
Change the application's RMI port number by doing the following:
If you are experiencing problems running CBR, 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 number:
If another application is using one of the CBR's port numbers, you can either change the CBR's port numbers or change the application's port number.
Change the CBR's port numbers by doing the following:
Change the application's RMI port number by doing the following:
If you are experiencing problems running the Site Selector component, it may be that one of your applications is using a port number that Site Selector normally uses. Be aware that Site Selector uses the following port numbers:
If another application is using one of the Site Selector's port numbers, you can either change the Site Selector's port numbers or change the application's port number.
Change the Site Selector's port numbers by doing the following:
Change the application's RMI port number by doing the following:
If you are experiencing problems running the Cisco CSS Controller component, it may be that another application is using one of the port numbers used by Cisco CSS Controller's ccoserver. Be aware that Cisco CSS Controller uses the following port numbers:
13099 to receive commands from ccocontrol
10004 to send metric queries to Metric Server
13199 for the RMI server port
If another application is using one of the Cisco CSS Controller's port numbers, you can either change the port numbers for Cisco CSS Controller or change the application's port number.
Change the Cisco CSS Controller's port numbers by doing the following:
Change the application's RMI port number by doing the following:
If you are experiencing problems running the Nortel Alteon Controller component, it may be that another application is using one of the port numbers used by Nortel Alteon Controller's nalserver. Be aware that Nortel Alteon Controller uses the following port numbers:
14099 to receive commands from nalcontrol
10004 to send metric queries to Metric Server
14199 for the RMI server port
If another application is using one of the Nortel Alteon Controller's port numbers, you can either change the port numbers for Nortel Alteon Controller or change the port numbers for the applicaton.
Change the port numbers for Nortel Alteon Controller by doing the following:
Change the application's RMI 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. Also, check the host file for the correct address.
This problem has symptoms such as connections from client machines not being served or connections timing out. Check the following to diagnose this problem:
For Windows and other platforms, see also Setting up server machines for load balancing.
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:
The following steps are an effective way to test that high availability scripts are functioning properly:
The two reports are identical if the scripts are properly configured.
This Windows platform error occurs when the source address is not configured on an adapter. Check the following to correct or diagnose the problem.
dscontrol executor configure <ip address>
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 work correctly, make sure that they are started on both the local and the remote Dispatchers.
An ICMP ping is issued to the servers before the advisor request. If a firewall exists between Load Balancer and the servers, ensure that pings are supported across the firewall. If this setup poses a security risk to your network, modify the java statement in dsserver to turn off all pings to the servers by adding the java property:
LB_ADV_NO_PING="true" java -DLB_ADV_NO_PING="true"
See Using remote advisors with Dispatcher's wide area support.
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 documentation.
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.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
This can cause problems when one of the administration consoles runs on the same machine as a firewall or through a firewall. For example, when Load Balancer runs on the same machine as a firewall, and you issue dscontrol commands, you might see errors such as Error: Server not responding.
To avoid this problem, edit the dsserver script file to set the port used by RMI for the firewall (or other application). Change the line: LB_RMISERVERPORT=10199 to LB_RMISERVERPORT=yourPort. Where yourPort is a different port.
Once complete, restart dsserver and open traffic for ports 10099, 10004, 10199, and 10100, or for the chosen port for the host address from which the administration console will be run.
For example: java -Djava.rmi.server.hostname="10.1.1.1"
For Windows, when using Netscape as your default browser, the following error message may result: "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:
The graphical user interface (GUI), which is lbadmin, requires a sufficient amount of paging space to function correctly. If insufficient paging space is available, the GUI might not start up completely. If this occurs, check your paging space and increase it if necessary.
If you uninstall Load Balancer to reinstall another version and get an error when you attempt to start the Dispatcher component, check to see if Caching Proxy is installed. Caching Proxy has a dependency on one of the Dispatcher files; this file will uninstall only when Caching Proxy is uninstalled.
To avoid this problem:
If you experience a problem with the appearance of the Load Balancer GUI, check the setting for the operating system's desktop resolution. The GUI is best viewed at a resolution of 1024x768 pixels.
On Windows platform, when you first open help windows, they sometimes disappear into the background behind existing windows. If this occurs, click on the window to bring it forward again.
On Solaris each network adapter has the same MAC address by default. This works properly when each adapter is on a different IP subnet; however, in a switched environment, when multiple NICs with the same MAC and the same IP subnet address communicate with the same switch, the switch sends all traffic bound for the single MAC (and both IPs) down the same wire. Only the adapter that last put a frame on the wire sees the IP packets bound for both adapters. Solaris might discard packets for a valid IP address that arrived on the "wrong" interface.
If all network interfaces are not designated for Load Balancer as configured in ibmlb.conf, and if the NIC that is not defined in ibmlb.conf receives a frame, Load Balancer does not have the ability to process and forward the frame.
To avoid this problem, you must override the default and set a unique MAC address for each interface. Use this command:
ifconfig interface ether macAddr
For example:
ifconfig eri0 ether 01:02:03:04:05:06
On Windows platform, you must have a network card installed and configured before starting the executor.
The AIX operating system contains a networking parameter called path MTU discovery. During a transaction with a client, if the operating system determines that it must use a smaller maximum transmission unit (MTU) for the outgoing packets, path MTU discovery has AIX create a route to remember that data. The new route is for that specific client IP and records the necessary MTU to reach it.
When the route is being created, a problem might occur on the servers resulting from the cluster being aliased on the loopback. If the gateway address for the route falls in the subnet of the cluster/netmask, AIX creates the route on the loopback. This happens because that was the last interface aliased with that subnet.
For example, if the cluster is 9.37.54.69 and a 255.255.255.0 netmask is used, and the intended gateway is 9.37.54.1, AIX uses the loopback for the route. This causes the server's responses to never leave the machine, and the client times out waiting. The client typically sees one response from the cluster, then the route is created and the client receives nothing more.
There are two solutions to this problem.
Notes:
Windows platform has a feature called Task Offload that allows the TCP checksum to be calculated by the adapter card rather than the operating system. Task offload might improve performance on the system; however, the problem with task offload is that TCP checksum is not computed correctly for packets coming from the cluster address. This is the case with nat and cbr forwarding methods, where the back-end servers forward packets to the Load Balancer machine before reaching the client.
When task offload is enabled, Load Balancer advisors report that servers are down and reach targets are down. Advisors send traffic from the cluster address, collocated traffic comes from the return address, and reach target traffic comes from the cluster address. The only forwarding method that works when task offload is enabled is the mac-based forwarding method, where the back-end servers forward packets directly to the client.
To avoid this problem when using nat or cbr forwarding, go to the adapter card settings and disable Task Offload.
This problem was first observed with Adaptec's ANA62044 QuadPort Adapter. This adapter card refers to the feature as the Transmit Checksum offload. Disable Transmit Checksum offload to avoid the problem.
When you set up a Wide Area Load Balancer, you must define the remote Dispatcher as a server in a cluster on your local Dispatcher. Typically, you use the non-forwarding address (NFA) of the remote Dispatcher as the destination address of the remote server. If you do this, and then set up high availability on the remote Dispatcher, it will fail. This happens because the local Dispatcher always points to the primary on the remote side when you use its NFA to access it.
To get around this problem:
When the remote primary Dispatcher comes up, it will alias this address on its adapter, allowing it to accept traffic. If a failure occurs, the address moves to the backup machine and the backup continues to accept traffic for that address.
When using lbadmin or Web administration (lbwebaccess) to load a large configuration file (roughly 200 or more add commands), the GUI may hang or display unexpected behavior, such as responding to screen changes at an extremely slow rate of speed.
This occurs because Java does not have access to enough memory to handle such a large configuration.
There is an option on the runtime environment that can be specified to increase the memory allocation pool available to Java.
The option is -Xmxn where n is the maximum size, in bytes, for the memory allocation pool. n must be a multiple of 1024 and must be greater than 2MB. The value n may be followed by k or K to indicate kilobytes, or m or M to indicate megabytes. For example, -Xmx128M and -Xmx81920k are both valid. The default value is 64M. Solaris 8 has a maximum value of 4000M.
For example, to add this option, edit the lbadmin script file, modifying "javaw" to "javaw -Xmxn" as follows. (For AIX, modify "java" to "java -Xmxn"):
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
There is no recommended value for n , but it should be greater than the default option. A good place to start would be with twice the default value.
If Load Balancer administration (lbadmin) disconnects from the server after you update the configuration, check the version of dsserver on the server that you are attempting to configure, and ensure that it is the same as your version of lbadmin or dscontrol.
When using a remote client over a secure socks implementation, fully-qualified domain names or host names might not resolve to the correct IP address in IP address format notation The socks implementation might add specific, socks-related data to the DNS resolution.
If the IP addresses are not resolving correctly over the remote connection, we recommend that you specify the IP address in the IP address notation format.
To correct overlapping or undesirable fonts in the Korean Load Balancer interface:
On AIX
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
On Linux
-monotype- timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
On Windows, after aliasing the MS Loopback adapter, when issuing certain commands such as hostname, the OS will incorrectly respond with the alias address instead of the local address. To correct this problem, in the network connections list, the newly added alias must be listed below the local address. This will ensure that the local address is accessed prior to the loopback alias.
To check the network connections list:
On Windows platform when using a Matrox AGP card, unexpected behavior can occur in the Load Balancer GUI. When clicking the mouse, a block of space slightly larger than the mouse pointer can become corrupted causing possible highlighting reversal or images to shift out of place on the screen. Older Matrox cards have not shown this behavior. There is no known fix when using Matrox AGP cards.
On Linux, if dsserver is still running during the manual removal of the Load Balancer kernel module, unexpected behavior, such as system hang or javacores, can occur. When manually removing the Load Balancer kernel module, you must first stop dsserver.
If "dsserver stop" does not work, stop the java process with SRV_KNDConfigServer. Stop the process by finding its process identifier using ps -ef | grep SRV_KNDConfigServer command and then ending the process using kill process_id command.
You can safely run the "rmmod ibmlb" command to remove the Load Balancer module from the kernel.
If you are running the Dispatcher component for load balancing, it is possible to overload the computer with client traffic. The Load Balancer kernel module has the highest priority, and if it is constantly handling client packets, the rest of the system may become unresponsive. Running commands in user space may take a very long time to complete, or may never complete.
If this happens, you should begin to restructure your setup to avoid overloading the Load Balancer machine with traffic. Alternatives include spreading the load across several Load Balancer machines, or replacing the machine with a stronger and faster computer.
When trying to decide if the slow response time on the machine is due to high client traffic, consider whether this occurs during client peak traffic times. Misconfigured systems that cause routing loops can also cause the same symptoms. But before changing the Load Balancer setup, determine whether the symptoms may be due to high client load.
When using mac-based forwarding method, Load Balancer will send packets to the servers using the cluster address which is aliased on the loopback. Some server applications (such as SSL) require that configuration information (such as certificates) are based on the IP address. The IP address must be the cluster address which is configured on the loopback in order to match the contents of the incoming packets. If the IP address of the cluster is not used when configuring the server application, then the client request will not get properly forwarded to the server.
If you are using remote Web administration to configure Load Balancer, do not resize (Minimize, Maximize, Restore Down, etc.) the Netscape browser window in which the Load Balancer GUI appears. Because Netscape reloads a page every time browser windows are resized, this will cause a disconnect from host. You will need to reconnect to host each time you resize the window. If you are performing remote Web administration on a Windows platform, use Internet Explorer.
When running Microsoft IIS server, version 5.0 on Windows back-end servers, you must configure the Microsoft IIS server to be bind specific. Otherwise, socket pooling is enabled as the default, and the Web server binds to 0.0.0.0 and listens for all traffic, rather than binding to the virtual IP addresses configured as multiple identities for the site. If an application on the local host goes down while socket pooling is enabled, AIX or Windows ND server advisors detect this; however, if an application on a virtual host goes down while the local host stays up, the advisors do not detect the failure and Microsoft IIS continues to respond to all traffic, including that of the downed application.
To determine whether socket pooling is enabled and the Web server is binding to 0.0.0.0, issue the following command:
netstat -an
The instructions for how to configure the Microsoft IIS server to be bind-specific (disable socket pooling), are located on the Microsoft Product Support Services Web site. You can also go to one of these URLs for this information:
In a command prompt window on the Windows operating system, some national characters of the Latin-1 family might appear corrupted. For example, the letter "a" with a tilde may display as a pi symbol. To fix this, you must change the font properties of the command prompt window. To change the font, do the following:
Some HP-UX 11i installations are pre-configured to allow only 64 threads per process. However, some Load Balancer configurations require more than this amount. We recommend that the threads per process for HP-UX be set to at least 256. To increase this value, use the "sam" utility to set the max_thread_proc kernel parameter. If heavy use is expected, you might need to increase max_thread_proc beyond 256.
To increase max_thread_proc, do the following:
When configuring your adapter on a Network Dispatcher machine, you must ensure that the following two settings are correct for the advisor to work:
On Windows platform, when configuring an adapter with more than one IP address, configure the IP address that you want affiliated to the host name first in the registry.
Since Load Balancer is dependent on InetAddress.getLocalHost() in many instances (for example, lbkeys create), multiple IP addresses aliased to a single adapter might cause problems. To avoid this problem, list the IP address to which you want your host name to resolve first in the registry. For example:
By default, when the Windows operating system detects a network outage, it clears its address resolution protocol (ARP) cache, including all static entries. After the network is available, the ARP cache is repopulated by ARP requests sent on the network.
With a high availability configuration, both servers take over primary operations when a loss of network connectivity affects one or both. When the ARP request is sent to repopulate the ARP cache, both servers respond, which causes the ARP cache to mark the entry as not valid. Therefore, the advisors are not able to create a socket to the backup servers.
Preventing the Windows operating system from clearing the ARP cache when there is a loss of connectivity solves this problem. Microsoft has published an article that explains how to accomplish this task. This article is on the Microsoft Web site, located in the Microsoft Knowledge Base, article number 239924: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.
The following is a summary of the steps, described in the Microsoft article, to prevent the system from clearing the ARP cache:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Certain considerations must be taken when using Linux kernel 2.4.x servers and Dispatcher's MAC forwarding method. If the server has a cluster address configured on the loopback device using the ip address add command, only one cluster address can be aliased.
When aliasing multiple clusters to the loopback device use the ifconfig command, for example:
ifconfig lo:num clusterAddress netmask 255.255.255.255 up
Additionally, there are incompatibilities between the ifconfig method of configuring interfaces and the ip method of configuring interfaces. Best practice suggests that a site choose one method and use that method exclusively.
When adding servers to your Dispatcher configuration, the following error message can result: "Error: Router address not specified or not valid for port method".
Use this checklist to determine the problem:
The default for the router parameter is 0, which indicates the server is local. When you set the server's router address to something other than 0, this indicates that it is a remote server, on a different subnet. For more information on the router parameter on the server add command, see dscontrol server -- configure servers.
If the server that you are adding is located on a different subnet, the router parameter should be the address of the router to be used on the local subnet to communicate with the remote server.
On Solaris, after starting Load Balancer scripts (such as dsserver or lbadmin) from a terminal window, if you exit from that window, the Load Balancer process also exits.
To resolve this problem, start the Load Balancer scripts with the nohup command. For example: nohup dsserver. This command prevents the processes started from the terminal session from receiving a hangup signal from the terminal when it exits, allowing the processes to continue even after the terminal session has ended. Use the nohup command in front of any Load Balancer scripts that you want to continue to process beyond the end of a terminal session.
The following command might significantly slow down the loading of Load Balancer configurations containing a large number of servers:
dscontrol server add (cluster+c2+...):(port+p2+...):(server+s2+...) address address
This problem occurs because the address is verified using the Java InetAddress class. If the Load Balancer machine's DNS is configured incorrectly or DNS in general takes a long time, this adds to the delay, because Java is sending DNS requests on the network.
A workaround for this is to add your server addresses and hostnames to your local /etc/hosts file.
If high availability is configured, the cluster addresses may be configured on both machines for a brief period and cause the following error message to occur: There is an IP address conflict with another system on the network. In this case, you can safely ignore the message. It is possible for a cluster address to be briefly configured on both high availability machines at the same time, especially during startup of either machine, or when a takeover has been initiated.
Check the go* scripts to ensure they are correctly configuring and unconfiguring cluster addresses. If you have invoked a configuration file and have go* scripts installed, ensure you do not have any "executor configure" command statements for your cluster addresses in your configuration file, as this will conflict with the configure and unconfigure commands in the go* scripts.
For more information on go* scripts when configuring high availability, see Using scripts.
This problem may occur when the go scripts do not run on either primary or backup machine. The go scripts cannot run if dsserver is not started on both machines. Check both machines and make sure dsserver is running.
Client requests that result in large page responses time out if the maximum transmit unit (MTU) is not set properly on the Dispatcher machine. For Dispatcher component's cbr and nat forwarding methods, this can occur because Dispatcher defaults the MTU value, rather than negotiate the value.
The MTU is set on each operating system based on the type of communication media (for example, Ethernet or Token-Ring). Routers from the local segment might have a smaller MTU set if they connect to a different type of communication media. Under normal TCP traffic, an MTU negotiation occurs during the connection setup, and the smallest MTU is used to send data between the machines.
Dispatcher does not support MTU negotiation for Dispatcher's cbr or nat forwarding method because it is actively involved as an endpoint for TCP connections. For cbr and nat forwarding, Dispatcher defaults the MTU value to 1500. This value is the typical MTU size for standard Ethernet, so most customers do not need to adjust this setting.
When using Dispatcher's cbr or nat forwarding method, if you have a router to the local segment that has a lower MTU, you must set the MTU on the Dispatcher machine to match the lower MTU.
To resolve this problem, use the following command to set the maximum segment size (mss) value: dscontrol executor set mss new_value
For example:
dscontrol executor set mss 1400
The default for mss is 1460.
The mss setting does not apply for Dispatcher's mac forwarding method or any non-Dispatcher component of Load Balancer.
When more than one IP address is on a Windows system and the hosts file does not specify the address to associate with the host name, the operating system chooses the smallest address to associate with the host name.
To resolve this problem, update the c:\Windows\system32\drivers\etc\hosts file with your machine host name and the IP address that you want to associate with the host name.
IMPORTANT: The IP address cannot be a cluster address.
When using high availability on S/390 Linux machines with the qeth network driver, the active and standby Dispatchers may fail to synchronize. This problem might be limited to Linux Kernel 2.6.
If this problem occurs, use the following workaround:
Define a channel-to-channel (CTC) network device between the active and standby Dispatcher images and add a heartbeat between the two CTC endpoint IP addresses.
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.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
This can cause problems when one of the administration consoles runs on the same machine as a firewall or through a firewall. For example, when Load Balancer runs on the same machine as a firewall, and you issue cbrcontrol commands, you might see errors such as Error: Server not responding.
To avoid this problem, edit the cbrserver script file to set the port used by RMI for the firewall (or other application). Change the line: LB_RMISERVERPORT=11199 to LB_RMISERVERPORT=yourPort. Where yourPort is a different port.
Once complete, restart cbrserver and open traffic for ports 11099, 10004, 11199, and 11100, or for the chosen port for the host address from which the administration console will be run.
Caching Proxy and CBR have been started, but requests are not being load balanced. This error can occur if you start Caching Proxy before starting the executor. If this happens, the stderr log for Caching Proxy will contain the following error message: "ndServerInit: Could not attach to executor." To avoid this problem, start the executor before starting Caching Proxy.
On Solaris, the cbrcontrol executor start command returns: "Error: Executor was not started." This error occurs if you do not configure the IPC (Inter-process Communication) for the system so that the maximum size of a shared memory segment and semaphore IDs are bigger than the operating system's default. In order to increase the size of the shared memory segment and semaphore IDs, you must edit the /etc/system file. For more information on how to configure this file, see page ***.
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 Windows platform when using a Matrox AGP card, unexpected behavior can occur in the Load Balancer GUI. When clicking the mouse, a block of space slightly larger than the mouse pointer can become corrupted causing possible highlighting reversal or images to shift out of place on the screen. Older Matrox cards have not shown this behavior. There is no known fix when using Matrox AGP cards.
If you are using remote Web administration to configure Load Balancer, do not resize (Minimize, Maximize, Restore Down, etc.) the Netscape browser window in which the Load Balancer GUI appears. Because Netscape reloads a page every time browser windows are resized, this will cause a disconnect from host. You will need to reconnect to host each time you resize the window. If you are performing remote Web administration on a Windows platform, use Internet Explorer.
In a command prompt window on the Windows operating system, some national charactes of the Latin-1 family might appear corrupted. For example, the letter "a" with a tilde may display as a pi symbol. To fix this, you must change the font properties of the command prompt window. To change the font, do the following:
Some HP-UX 11i installations are pre-configured to allow only 64 threads per process. However, some Load Balancer configurations require more than this amount. We recommend that the threads per process for HP-UX be set to at least 256. To increase this value, use the "sam" utility to set the max_thread_proc kernel parameter. If heavy use is expected, you might need to increase max_thread_proc beyond 256.
To increase max_thread_proc, refer to the steps on page ***.
When configuring your adapter on a Network Dispatcher machine, you must ensure that the following two settings are correct for the advisor to work:
Refer to page *** for instructions on configuring these setting.
On Windows platform, when configuring an adapter with more than one IP address, configure the IP address that you want affiliated to the host name first in the registry.
Since Load Balancer is dependent on InetAddress.getLocalHost() in many instances (for example, lbkeys create), multiple IP addresses aliased to a single adapter might cause problems. To avoid this problem, list the IP address to which you want your host name to resolve first in the registry.
Refer to page *** for steps to configure the host name first in the registry.
This problem can occur when another application is using one of the ports used by Site Selector. For more information, go to Checking Site Selector port numbers.
Symptom: Site Selector component does not round-robin incoming requests from Solaris clients.
Possible cause: Solaris systems run a name service cache daemon. If this daemon is running, the subsequent resolver request will be answered from this cache instead of querying Site Selector.
Solution: Turn off the name service cache daemon on the Solaris machine.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
This can cause problems when one of the administration consoles runs on the same machine as a firewall or through a firewall. For example, when Load Balancer runs on the same machine as a firewall, and you issue sscontrol commands, you might see errors such as Error: Server not responding.
To avoid this problem, edit the ssserver script file to set the port used by RMI for the firewall (or other application). Change the line: LB_RMISERVERPORT=10199 to LB_RMISERVERPORT=yourPort. Where yourPort is a different port.
Once complete, restart ssserver and open traffic for ports 12099, 10004, 12199, and 12100, or for the chosen port for the host address from which the administration console will be run.
Site Selector must be able to participate in a DNS. All the machines involved in the configuration should also be participants of this system. Windows does not always require the configured host name to be in the DNS. Site Selector requires that its host name be define in the DNS to start properly.
Verify this host is defined in the DNS. Edit the ssserver.cmd file and remove the "w" from "javaw". This should provide more information about errors.
Site Selector's name server does not bind to any one address on the machine. It will respond to requests destined for any valid IP on the machine. Site Selector relies on the operating system to route the response back to the client. If the Site Selector machine has multiple adapters and any number of them are attached to the same subnet, it is possible the O/S will send the response to the client from a different address than it was received. Some client applications will not accept a response received from an address other than where it was sent. As a result, the name resolution will appear to fail.
On Windows platform when using a Matrox AGP card, unexpected behavior can occur in the Load Balancer GUI. When clicking the mouse, a block of space slightly larger than the mouse pointer can become corrupted causing possible highlighting reversal or images to shift out of place on the screen. Older Matrox cards have not shown this behavior. There is no known fix when using Matrox AGP cards.
If you are using remote Web administration to configure Load Balancer, do not resize (Minimize, Maximize, Restore Down, etc.) the Netscape browser window in which the Load Balancer GUI appears. Because Netscape reloads a page every time browser windows are resized, this will cause a disconnect from host. You will need to reconnect to host each time you resize the window. If you are performing remote Web administration on a Windows platform, use Internet Explorer.
In a command prompt window on the Windows operating system, some national charactes of the Latin-1 family might appear corrupted. For example, the letter "a" with a tilde may display as a pi symbol. To fix this, you must change the font properties of the command prompt window. To change the font, do the following:
Some HP-UX 11i installations are pre-configured to allow only 64 threads per process. However, some Load Balancer configurations require more than this amount. We recommend that the threads per process for HP-UX be set to at least 256. To increase this value, use the "sam" utility to set the max_thread_proc kernel parameter. If heavy use is expected, you might need to increase max_thread_proc beyond 256.
To increase max_thread_proc, refer to the steps on page ***.
When configuring your adapter on a Network Dispatcher machine, you must ensure that the following two settings are correct for the advisor to work:
Refer to page *** for instructions on configuring these setting.
This problem can occur when another application is using one of the ports used by the Cisco CSS Controller's ccoserver. For more information, see Checking Cisco CSS Controller port numbers.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
This can cause problems when one of the administration consoles runs on the same machine as a firewall or through a firewall. For example, when Load Balancer runs on the same machine as a firewall, and you issue ccocontrol commands, you might see errors such as Error: Server not responding.
To avoid this problem, edit the ccoserver script file to set the port used by RMI for the firewall (or other application). Change the line: CCO_RMISERVERPORT=14199 to CCO_RMISERVERPORT=yourPort. Where yourPort is a different port.
Once complete, restart ccoserver and open traffic for ports 13099, 10004, 13199, and 13100, or for the chosen port for the host address from which the administration console will be run.
This problem can occur when a valid product license is missing. When you attempt to start ccoserver, you receive the following message:
Your license has expired. Contact your local IBM representative or authorized IBM reseller.
To correct this problem:
On Windows platform when using a Matrox AGP card, unexpected behavior can occur in the Load Balancer GUI. When clicking the mouse, a block of space slightly larger than the mouse pointer can become corrupted causing possible highlighting reversal or images to shift out of place on the screen. Older Matrox cards have not shown this behavior. There is no known fix when using Matrox AGP cards.
You might experience a connection error, due to incorrect configuration settings, when adding a consultant. To fix this problem:
To fix this problem
Increase the consultant loglevel and retry the command. If it fails again, search the log for SNMP timeout or other SNMP communication errors.
If you are using remote Web administration to configure Load Balancer, do not resize (Minimize, Maximize, Restore Down, etc.) the Netscape browser window in which the Load Balancer GUI appears. Because Netscape reloads a page every time browser windows are resized, this will cause a disconnect from host. You will need to reconnect to host each time you resize the window. If you are performing remote Web administration on a Windows platform, use Internet Explorer.
In a command prompt window on the Windows operating system, some national charactes of the Latin-1 family might appear corrupted. For example, the letter "a" with a tilde may display as a pi symbol. To fix this, you must change the font properties of the command prompt window. To change the font, do the following:
Some HP-UX 11i installations are pre-configured to allow only 64 threads per process. However, some Load Balancer configurations require more than this amount. We recommend that the threads per process for HP-UX be set to at least 256. To increase this value, use the "sam" utility to set the max_thread_proc kernel parameter. If heavy use is expected, you might need to increase max_thread_proc beyond 256.
To increase max_thread_proc, refer to the steps on page ***.
This problem can occur when another application is using one of the ports used by the Nortel Alteon Controller's nalserver. For more information, see Checking Nortel Alteon Controller port numbers.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
This can cause problems when one of the administration consoles runs on the same machine as a firewall or through a firewall. For example, when Load Balancer runs on the same machine as a firewall, and you issue nalcontrol commands, you might see errors such as Error: Server not responding.
To avoid this problem, edit the nalserver script file to set the port used by RMI for the firewall (or other application). Change the line: NAL_RMISERVERPORT=14199 to NAL_RMISERVERPORT=yourPort. Where yourPort is a different port.
Once complete, restart nalserver and open traffic for ports 14099, 10004, 14199, and 14100, or for the chosen port for the host address from which the administration console will be run.
This problem can occur when a valid product license is missing. When you attempt to start nalserver, you receive the following message:
Your license has expired. Contact your local IBM representative or authorized IBM reseller.
To correct this problem:
On Windows platform when using a Matrox AGP card, unexpected behavior can occur in the Load Balancer GUI. When clicking the mouse, a block of space slightly larger than the mouse pointer can become corrupted causing possible highlighting reversal or images to shift out of place on the screen. Older Matrox cards have not shown this behavior. There is no known fix when using Matrox AGP cards.
If you are using remote Web administration to configure Load Balancer, do not resize (Minimize, Maximize, Restore Down, etc.) the Netscape browser window in which the Load Balancer GUI appears. Because Netscape reloads a page every time browser windows are resized, this will cause a disconnect from host. You will need to reconnect to host each time you resize the window. If you are performing remote Web administration on a Windows platform, use Internet Explorer.
You might experience a connection error, due to incorrect configuration settings, when adding a consultant. To fix this problem:
To fix this problem
Increase the consultant loglevel and retry the command. If it fails again, search the log for SNMP timeout or other SNMP communication errors.
In a command prompt window on the Windows platform operating system, some national charactes of the Latin-1 family might appear corrupted. For example, the letter "a" with a tilde may display as a pi symbol. To fix this, you must change the font properties of the command prompt window. To change the font, do the following:
Some HP-UX 11i installations are pre-configured to allow only 64 threads per process. However, some Load Balancer configurations require more than this amount. We recommend that the threads per process for HP-UX be set to at least 256. To increase this value, use the "sam" utility to set the max_thread_proc kernel parameter. If heavy use is expected, you might need to increase max_thread_proc beyond 256.
To increase max_thread_proc, refer to the steps on page ***.
You must use the full metric name for user-written metrics on Metric Servers running on Windows platform. For example, you must specify usermetric.bat instead of usermetric. The name usermetric is valid on the command line, but will not work when executed from within the runtime environment. If you do not use the full metric name, you will receive a Metric Server IOException. Set the LOG_LEVEL variable to a value of 3 in the metricserver command file, then check the log output. In this example, the exception appears as:
... java.io.IOException: CreateProcess: usermetric error=2
There can be several reasons why Metric Server is not reporting load information to Load Balancer. To determine the cause, perform the following checks:
The Metric Server log reports this error message after key files have been transferred to the server.
This error is logged when the key file fails authorization with the paired key due to corruption in the pair. To correct this problem try the following:
While running Metric Server under heavy stress on a multi-processor AIX platform (4.3.3, 32-bit 5.1, or 64-bit 5.1), output from ps -vg command may be corrupt. For example:
55742 - A 88:19 42 18014398509449680 6396 32768 22 36 2.8 1.0 java -Xms
The SIZE and/or RSS field of the ps command may show an excessive amount of memory being used.
This is a known AIX kernel problem. Apar IY33804 will correct this problem. Obtain the fix from AIX support at http://techsupport.services.ibm.com/server/fixes, or contact your local AIX support representative.
In a two-tier Load Balancer configuration, if Site Selector (first-tier) is load balancing across a pair of Dispatcher high-availability partners (second-tier), there are steps you must complete to configure the metric server component. You must configure metric server to listen on a new IP address that is specifically for metric server's use. On the two high-availability Dispatcher machines, metric server is active only on the active Dispatcher.
To correctly configure this setup, complete the following steps:
For example:
ifconfig en0 delete 9.27.23.61 ifconfig lo0 alias 9.27.23.61 netmask 255.255.255.0 route add 9.27.23.61 127.0.0.1 metricserver stop # Sleep either max 60 seconds or until the metricserver stops let loopcount=0 while [[ "$loopcount" -lt "60" && 'ps -ef | grep AgentStop| grep -c -v gr ep' -eq "1"]] do sleep 1 let loopcount=$loopcount+1 done route delete 9.27.23.61
For example:
call netsh interface ip delete address "Local Area Connection" addr=9.27.23.61 call netsh interface ip add address "Local Area Connection 2" addr=9.27.2.3.61 mask = 255.255.255.0 sleep 3 metricserver stop
When running on multi-CPU Solaris machines, metricserver, cpuload, and memload scripts can produce unwanted console messages. This behavior is due to the use of the VMSTAT system command to gather CPU and memory statistics from the kernel. Some messages that VMSTAT returns indicate that the state of the kernel has changed. The scripts are unable to handle these messages, resulting in unnecessary console messages from the shell.
Examples of these console messages are:
/opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=: syntax error /opt/ibm/edge/lb/ms/script/memload[31]: LOAD=4*100/0: divide by zero /opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=659664+: more tokens expected
These messages can be ignored.
This part provides command reference information for all the Load Balancer components. It contains the following chapters:
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------------------------------------------------><
This chapter describes how to use the Dispatcher dscontrol commands. It is also a command reference for CBR.
For previous versions, when the product was known as Network Dispatcher, the Dispatcher control command name was ndcontrol. The Dispatcher control command name is now dscontrol. Ensure you update all previous script files to use dscontrol (not ndcontrol) for configuring Dispatcher.
CBR uses a subset of the Dispatcher commands listed in this command reference. When using these syntax diagrams for CBR, substitute cbrcontrol for dscontrol. For information, see Configuration differences between CBR and Dispatcher.
IMPORTANT: If you are using the Load Balancer for IPv6 installation of this product, only the Dispatcher component is available. The Dispatcher for this type of installation uses a subset of the dscontrol commands listed in this command reference. When using these syntax diagrams, substitute at (@) for colon (:) as the delimiter within the dscontrol command. For more information, see Command syntax differences and Supported dscontrol commands.
The following list contains the commands noted in this chapter:
You can enter a minimized version of the dscontrol 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 type dscontrol he f instead of dscontrol help file.
To start up the command-line interface: issue dscontrol to receive a dscontrol command prompt.
To end the command line interface: issue exit or quit.
The CBR command line interface is a subset of the command line interface of Dispatcher. For CBR, substitute the cbrcontrol command instead of dscontrol to configure the component.
Some of the commands that are omitted in CBR are listed below.
>>-dscontrol--advisor--+-connecttimeout--name--+-port---------+--timeoutseconds-+->< | '-cluster:port-' | +-interval--name--+-port---------+--seconds--------------+ | '-cluster:port-' | +-list---------------------------------------------------+ +-loglevel--name--+-port---------+--level----------------+ | '-cluster:port-' | +-logsize--name--+-port---------+--+-unlimited---------+-+ | '-cluster:port-' '-number of records-' | +-receivetimeout--name--+-port---------+--timeoutseconds-+ | '-cluster:port-' | +-report--name--+-port---------+-------------------------+ | '-cluster:port-' | +-retries--name--+-port---------+--numretries------------+ | '-cluster:port-' | +-start--name--+-port---------+--+----------+------------+ | '-cluster:port-' '-log file-' | +-status--name--+-port---------+-------------------------+ | '-cluster:port-' | +-stop--name--+-port---------+---------------------------+ | '-cluster:port-' | +-timeout--name--+-port---------+--+-unlimited-+---------+ | '-cluster:port-' '-seconds---' | '-version--name--+-port---------+------------------------' '-cluster:port-'
See List of advisors for more information on the advisors that Load Balancer provides.
Names of customized advisors are of the format xxxx, where ADV_xxxx is the name of the class that implements the custom advisor. See Create custom (customizable) advisors for more information.
The cluster is the address in IP address format or symbolic name. The port is the number of the port that the advisor is monitoring.
Advisor Name | Protocol | Port |
---|---|---|
cachingproxy | HTTP (via Caching Proxy) | 80 |
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | private | 12345 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10,007 |
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. The default log files for cluster (or site) specific advisors are created with the cluster address, for example, http_127.40.50.1_80.log.
Examples
dscontrol advisor start http 127.40.50.1:80
dscontrol advisor start http 88
dscontrol advisor stop http 127.40.50.1:80
dscontrol advisor connecttimeout http 80 30
dscontrol advisor connecttimeout http 127.40.50.1:80 20
dscontrol advisor interval ftp 21 6
dscontrol advisor listThis command produces output similar to:
--------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
dscontrol advisor loglevel http 80 0
dscontrol advisor logsize ftp 21 5000
dscontrol advisor receivetimeout http 80 60
dscontrol advisor report ftp 21This command produces output similar to:
Advisor Report: --------------- Advisor name ............. Ftp Port number .............. 21 Cluster address .......... 9.67.131.18 Server address ........... 9.67.129.230 Load ..................... 8 Cluster address .......... 9.67.131.18 Server address ........... 9.67.131.215 Load ..................... -1
dscontrol advisor status http 80This command produces output similar to the following:
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
dscontrol advisor timeout ftp 21 5
dscontrol advisor version ssl 443This command produces output similar to the following:
Version: 04.00.00.00 - 07/12/2001-10:09:56-EDT
>>-dscontrol--binlog--+-start----------------------+----------->< +-stop-----------------------+ +-set--+-retention--hours--+-+ | '-interval--seconds-' | '-status---------------------'
>>-dscontrol--cluster--+-add--cluster+c2+...--+----------------------------------------+-+->< | +-address--address-----------------------+ | | +-proportions--active--new--port--system-+ | | +-maxports--size-------------------------+ | | +-maxservers--size-----------------------+ | | +-stickytime--time-----------------------+ | | +-weightbound--weight--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--address-------------------+ | | +-staletimeout--staletimeout-------------+ | | '-sharedbandwidth--size------------------' | +-set--cluster+c2+...--+-proportions--active--new--port--system-+-+ | +-maxports--size-------------------------+ | | +-maxservers--size-----------------------+ | | +-stickytime--time-----------------------+ | | +-weightbound--weight--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--address-------------------+ | | +-staletimeout--staletimeout-------------+ | | '-sharedbandwidth--size------------------' | +-remove--cluster-------------------------------------------------+ +-report--cluster-------------------------------------------------+ '-status--cluster-------------------------------------------------'
With the exception of the dscontrol cluster add command, you can use a colon (:) to act as a wild card. For example, the following command, dscontrol cluster set : weightbound 80, will result in setting a weightbound of 80 to all clusters.
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.
Examples
dscontrol cluster add 130.40.52.153
dscontrol cluster remove 130.40.52.153
dscontrol cluster set 9.6.54.12 proportions 60 35 5 0
dscontrol cluster add 0.0.0.0
dscontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
dscontrol cluster status 9.67.131.167This command produces output similar to:
Cluster Status: ---------------- Cluster ................................. 9.67.131.167 Address ................................. 9.67.131.167 Number of target ports .................. 3 Default sticky time ..................... 0 Default stale timeout ................... 30 Default port weight bound ............... 20 Maximum number of ports ................. 8 Default port protocol ................... tcp/udp Default maximum number of servers ....... 32 Proportion given to active connections... 0.5 Proportion given to new connections...... 0.5 Proportion given specific to the port.... 0 Proportion given to system metrics....... 0 Shared bandwidth (KBytes) ............... 0 Primary Host Address .................... 9.67.131.167
>>-dscontrol--executor--+-report-----------------------------------------------------------+->< +-set--+-nfa--IP address------------+------------------------------+ | +-maxclusters--size----------+ | | +-maxports--size-------------+ | | +-fintimeout--fintimeout-----+ | | +-hatimeout--time------------+ | | +-maxservers--size-----------+ | | +-mss--size------------------+ | | +-staletimeout--staletimeout-+ | | +-stickytime--time-----------+ | | +-clientgateway--address-----+ | | +-weightbound--weight--------+ | | +-porttype--type-------------+ | | +-wideportnumber--port-------+ | | '-sharedbandwidth--size------' | +-configure--interface_address+i2+...--+-------------------------+-+ | '-interface_name--netmask-' | +-unconfigure--interface_address-----------------------------------+ +-start------------------------------------------------------------+ +-status-----------------------------------------------------------+ '-stop-------------------------------------------------------------'
Examples
dscontrol executor status Executor Status: ---------------- Nonforwarding address ............... 9.67.131.151 Client gateway address .............. 0.0.0.0 Fin timeout ......................... 60 Wide area network port number ....... 0 Shared bandwidth (Kbytes) ........... 0 Default maximum ports per cluster ... 8 Maximum number of clusters .......... 100 Default maximum servers per port .... 32 Default stale timeout ............... 300 Default sticky time ................. 0 Default weight bound ................ 20 Default port type ................... tcp/udp
dscontrol executor set nfa 130.40.52.167
dscontrol executor set maxclusters 4096
dscontrol executor start
dscontrol executor stop
>>-dscontrol--file--+-delete--file[.ext]----------+------------>< +-appendload--file[.ext]------+ +-report----------------------+ +-save--file[.ext]--+-------+-+ | '-force-' | '-newload--file[.ext]---------'
The file extension (.ext) can be anything you like and can be omitted.
Examples
dscontrol file delete file3 File (file3) was deleted.
dscontrol file newload file1.sv File (file1.sv) was loaded into the Dispatcher.
dscontrol file appendload file2.sv File (file2.sv) was appended to the current configuration and loaded.
dscontrol file report FILE REPORT: file1.save file2.sv file3
dscontrol file save file3 The configuration was saved into file (file3).
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-cluster----------+ +-executor---------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-host-------------+ +-logstatus--------+ +-manager----------+ +-metric-----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-set--------------+ +-status-----------+ '-subagent---------'
Examples
dscontrol helpThis command produces output similar to:
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help cluster help - print complete help text advisor - help on advisor command cluster - help on cluster command executor - help on executor command file - help on file command host - help on host command binlog - help on binary log command manager - help on manager command metric - help on metric command port - help on port command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on server log status subagent - help on subagent command highavailability - help on high availability commandNotice that parameters within <> are variables.
fintimeout <cluster address>|all <time> -Change FIN timeout (Use 'all' to change all clusters)
>>-dscontrol--highavailability--+-status--------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--p-+-+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--address--mask------------+ | '-delete-' | +-heartbeat--+-add--srcaddress--dstaddress-+--+ | '-delete--address-------------' | '-takeover--+---------+-----------------------' '-address-'
In addition, the status keyword returns information about various substates:
Mutual high availability configuration (role of each Dispatcher machine is both):
Notes:
Examples
dscontrol highavailability status
Output:
High Availability Status: ------------------------- Role ........................primary Recovery Strategy ........... manual State ....................... Active Sub-state.............. Synchronized Primary host........... 9.67.131.151 Port .........................12345 Preferred Target....... 9.67.134.223 Heartbeat Status: ----------------- Count ......................... 1 Source/destination ............ 9.67.131.151/9.67.134.223 Reachability Status: -------------------- Count ................ 1 Address .............. 9.67.131.1 reachable
dscontrol highavailability backup add primary auto 80
dscontrol 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
dscontrol highavailability takeover
>>-dscontrol--host:--remote_host-------------------------------><
dscontrol host:remote_host
After this command has been issued on the command prompt, enter any valid dscontrol command you want issued to the remote Load Balancer machine.
>>-dscontrol--logstatus----------------------------------------><
Examples
To display the logstatus:
dscontrol logstatus
This command produces output similar to:
Dispatcher Log Status: ------------------------------ Log filename ............... C:\PROGRA~1\IBM\edge\lb\servers\logs\dispatcher \server.log Log level .................. 1 Maximum log size (bytes) ... 1048576
>>-dscontrol--manager--+-interval--seconds----------------------+->< +-loglevel--level------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-quiesce--server--+-----+---------------+ | '-now-' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-refresh--refresh cycle-----------------+ +-report--+----------------+-------------+ | '-cluster+c2+...-' | +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-start--+-----------------------+-------+ | '-log file--metric_port-' | +-status---------------------------------+ +-stop-----------------------------------+ +-unquiesce--server----------------------+ '-version--------------------------------'
Or, if you used server partitioning, use the logical server's unique name. See Server Partitioning: logical servers configured to one physical server (IP address) for more information.
The default file will be installed in the logs directory. See Appendix C, Sample configuration files. To change the directory where the log files will be kept, see Changing the log file paths.
Examples
dscontrol manager interval 5
dscontrol manager loglevel 0
dscontrol manager logsize 1000000
dscontrol manager quiesce 130.40.52.153
dscontrol manager refresh 3
dscontrol manager reportThis command produces output similar to:
-------------------------------------------------------------------- | SERVER | IP ADDRESS | STATUS | -------------------------------------------------------------------- | mach14.dmz.com | 10.6.21.14 | ACTIVE | | mach15.dmz.com | 10.6.21.15 | ACTIVE | -------------------------------------------------------------------- ----------------------------- | MANAGER REPORT LEGEND | ----------------------------- | ACTV | Active Connections | | NEWC | New Connections | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | | CONN | Connections | ----------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 21 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | -1 | 0 | | mach15.dmz.com | 10 10 | 0 | 0 | -1 | 0 | ------------------------------------------------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 80 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | 23 | 0 | | mach15.dmz.com | 9 9 | 0 | 0 | 30 | 0 | ------------------------------------------------------------------- --------------------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------------------
dscontrol manager restart Restarting the manager to update codeThis command produces output similar to:
320-14:04:54 Restarting the manager to update code
dscontrol manager sensitivity 10
dscontrol manager smoothing 2.0
dscontrol manager start ndmgr.log
dscontrol manager statusThis command produces output similar to the following example.
Manager status: =============== Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 0.05 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7 Metric monitor log file name.................. MetricMonitor.log Metric monitor log level...................... 1 Maximum metric monitor log size............... 1048576
dscontrol manager stop
dscontrol manager quiesce 130.40.52.153 now
dscontrol manager quiesce 130.40.52.153
dscontrol manager unquiesce 130.40.52.153
dscontrol manager version
>>-dscontrol--metric--+-add--cluster+c2+...+cN:metric+metric1+...+metricN--------------+->< +-remove--cluster+c2+...+cN:metric+metric1+...+metricN-----------+ +-proportions--cluster+c2+...+cN proportion1 prop2 prop3...propN-+ '-status--cluster+c2+...+cN:metric+metric1+...+metricN-----------'
Examples
dscontrol metric add site1:metric1
dscontrol metric proportions site1 0 100
dscontrol metric status site1:metric1This command produces output similar to the following:
Metric Status: ------------ Cluster ....................... 10.10.10.20 Metric name ................... metric1 Metric proportion ............. 50 Server .................... plm3 Metric data ............... -1
>>-dscontrol--port--+-add--cluster:port--+----------------------+-+->< | +-crossport--otherport-+ | | +-maxservers--size-----+ | | +-stickymask--value----+ | | +-stickytime--time-----+ | | +-method--type---------+ | | +-staletimeout--value--+ | | +-weightbound--weight--+ | | +-porttype--type-------+ | | +-protocol--type-------+ | | '-reset--value---------' | +-set--cluster:port--+-crossport--otherport-+-+ | +-maxservers--size-----+ | | +-stickymask--value----+ | | +-stickytime--time-----+ | | +-staletimeout--value--+ | | +-weightbound--weight--+ | | +-porttype--type-------+ | | +-maxhalfopen--value---+ | | '-reset--value---------' | +-remove--cluster:port------------------------+ +-report--cluster:port------------------------+ +-status--cluster:port------------------------+ '-halfopenaddressreport--cluster:port---------'
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.
For the Dispatcher component:
For the CBR component: If you set the port stickytime to a nonzero value, then the affinity type on the rule must be none (default). Rule-based affinity (passive cookie, URI, active cookie) cannot co-exist when stickytime is set on the port.
Notes:
A positive value indicates that a check will be made to determine if the current half-open connections exceeds the threshold. If the current value is above the threshold, a call to an alert script is made. See Denial of service attack detection for more information.
Examples
dscontrol port add 130.40.52.153:80+23
dscontrol port set 130.40.52.153:0
dscontrol port set 130.40.52.153:80 weightbound 10
dscontrol port set 130.40.52.153:80+23 stickytime 60
dscontrol port set 130.40.52.153:80 crossport 23
dscontrol port remove 130.40.52.153:23
dscontrol port status 9.67.131.153:80This command produces output similar to:
Port Status: ------------ Port number .................... 80 Cluster ........................ 9.67.131.153 Stale timeout .................. 300 Weight bound ................... 20 Maximum number of servers ...... 32 Sticky time .................... 0 Port type ...................... tcp/udp Cross Port Affinity ............ 80 Sticky mask bits ............... 32 Max Half Open Connections ...... 0 Send TCP Resets ................ no
dscontrol port report 9.62.130.157:80This command produces output similar to:
Port Report: ------------ Cluster address ................ 9.62.130.157 Port number .................... 80 Number of servers .............. 5 Maximum server weight .......... 10 Total active connections ....... 55 Connections per second ......... 12 KBytes per second .............. 298 Number half open ............... 0 TCP Resets sent ................ 0 Forwarding method .............. MAC Based Forwarding
dscontrol port halfopenaddressreport 9.67.127.121:80This command produces output similar to:
Half open connection report successfully created: ------------ Half Open Address Report for cluster:port = 9.67.127.121:80 Total addresses with half open connections reported ... 0 Total number of half open connections reported ........ 0 Largest number of half open connections reported ...... 0 Average number of half open connections reported ...... 0 Average half open connection time (seconds) reported .. 0 Total half open connections received .................. 0
>>-dscontrol--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---------+ +-cookiename--value---------------+ +-evaluate--level-----------------+ '-sharelevel--level---------------'
See Active cookie affinity for more information.
An affinity type of "activecookie" enables load-balancing Web traffic with affinity to the same server based upon cookies generated by Load Balancer.
An affinity type of "passivecookie" enables load-balancing Web traffic with affinity to the same server based upon self-identifying cookies generated by the servers. You must use the cookiename parameter in conjunction with passive cookie affinity.
An affinity type of "URI" enables load-balancing Web traffic to caching-proxy servers in a manner which effectively increases the size of the cache.
See Active cookie affinity, Passive cookie affinity, and URI affinity for more information.
See Passive cookie affinity for more information.
For the connection type rule, you can also specify an evaluate option -- upserversonrule. By specifying upserversonrule, you can ensure that the remaining servers within the rule will not be overloaded if some of the servers in the server-set are down.
Or, if you used server partitioning, use the logical server's unique name. See Server Partitioning: logical servers configured to one physical server (IP address) for more information.
Examples
dscontrol rule add 9.37.67.100:80:trule type true priority 100
dscontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
dscontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 dscontrol rule useserver cluster1:80:timerule server05
dscontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
dscontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
dscontrol cluster set 9.67.131.153 sharedbandwidth 200 dscontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-dscontrol--server--+-add--cluster:port:server--+-------------------------+-+->< | +-address--address--------+ | | +-collocated--value-------+ | | +-sticky--value-----------+ | | +-weight--value-----------+ | | +-fixedweight--value------+ | | +-cookievalue--value------+ | | +-mapport--portvalue------+ | | +-protocol--value---------+ | | +-router--addr------------+ | | +-returnaddress--addr-----+ | | +-advisorrequest--string--+ | | '-advisorresponse--string-' | +-set--cluster:port:server--+-collocated--value-------+-+ | +-sticky--value-----------+ | | +-weight--value-----------+ | | +-fixedweight--value------+ | | +-cookievalue--value------+ | | +-protocol--value---------+ | | +-router--addr------------+ | | +-advisorrequest--string--+ | | '-advisorresponse--string-' | +-down--cluster:port:server-----------------------------+ +-remove--cluster:port:server---------------------------+ +-report--cluster:port:server---------------------------+ +-up--cluster:port:server-------------------------------+ '-status--cluster:port:server---------------------------'
Or, if you use a unique name that does not resolve to an IP address, you must provide the server address parameter on the dscontrol server add command. See Server Partitioning: logical servers configured to one physical server (IP address) for more information.
Examples
dscontrol server add 130.40.52.153:80:27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 sticky no
dscontrol server down 130.40.52.153:80:27.65.89.42
dscontrol server remove ::27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
dscontrol server set 130.40.52.153:80:27.65.89.42 weight 10
dscontrol server up 130.40.52.153:80:27.65.89.42
dscontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
dscontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/1.0\""
dscontrol server status 9.67.131.167:80:9.67.143.154This command produces output similar to:
Server Status: -------------- Server ......................... 9.67.143.154 Port number .................... 80 Cluster ........................ 9.67.131.167 Cluster address ................ 9.67.131.167 Quiesced ....................... N Server up ...................... Y Weight ......................... 10 Fixed weight ................... N Sticky for rule ................ Y Remote server .................. N Network Router address ......... 0.0.0.0 Collocated ..................... N Advisor request................. HEAD / HTTP/1.0 Advisor response................ Cookie value ................... n/a Clone ID ....................... n/a
>>-dscontrol--set--+-loglevel--level--------+------------------>< '-logsize--+-unlimited-+-' '-size------'
>>-dscontrol--status-------------------------------------------><
Examples
dscontrol statusThis command produces output similar to:
Executor has been started. Manager has been started. ---------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | ---------------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | ----------------------------------------
>>-dscontrol--subagent--+-loglevel--level--------------------+->< +-logsize--+-bytes-----+-------------+ | '-unlimited-' | +-report-----------------------------+ +-start--+-------------------------+-+ | '-community_name--logfile-' | +-status-----------------------------+ +-stop-------------------------------+ '-version----------------------------'
For Windows platform: The community name for the operating system is used.
Examples
dscontrol subagent start bigguy bigguy.log
This chapter describes how to use the following Site Selector sscontrol commands:
You can enter a minimized version of the sscontrol 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 sscontrol he f instead of sscontrol help file.
>>-sscontrol--advisor--+-connecttimeout--name--+-port----------+--seconds-------+->< | '-sitename:port-' | +-interval--name--+-port----------+--seconds-------------+ | '-sitename:port-' | +-list---------------------------------------------------+ +-loglevel--name--+-port----------+--level---------------+ | '-sitename:port-' | +-logsize--name--+-port----------+--+-size | unlimited-+-+ | '-sitename:port-' '-bytes------------' | +-receivetimeout--name--+-port----------+--seconds-------+ | '-sitename:port-' | +-report--name--+-port----------+------------------------+ | '-sitename:port-' | +-retries--name--+-port----------+--numretries-----------+ | '-sitename:port-' | +-start--name--+-port----------+--+----------+-----------+ | '-sitename:port-' '-log file-' | +-status--name--+-port----------+------------------------+ | '-sitename:port-' | +-stop--name--+-port----------+--------------------------+ | '-sitename:port-' | +-timeout--name--+-port----------+-----------------------+ | '-sitename:port-' | '-version--name--+-port----------+--seconds--------------' '-sitename:port-'
.
Advisor Name | Protocol | Port |
---|---|---|
Connect | n/a | user-defined |
db2 | private | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
PING | PING | N/A |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
The default file is advisorname_port.log, for example, http_80.log. To change the directory where the log files are stored, see Changing the log file paths.
You can start only one advisor for each sitename.
Examples
sscontrol advisor connecttimeout http 80 30
sscontrol advisor interval ftp 21 6
sscontrol advisor listThis command produces output similar to:
--------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | --------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
sscontrol advisor loglevel http mysite:80 0
sscontrol advisor logsize ftp mysite:21 5000
sscontrol advisor receivetimeout http 80 60
sscontrol advisor report ftp 21This command produces output similar to:
Advisor Report: --------------- Advisor name ............. http Port number .............. 80 sitename ................. mySite Server address ........... 9.67.129.230 Load ..................... 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80This command produces output similar to the following:
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
sscontrol advisor stop http 80
sscontrol advisor timeout ftp 21 5
sscontrol advisor version ssl 443
>>-sscontrol--file--+-delete--filename.ext----------+---------->< +-appendload--filename.ext------+ +-report------------------------+ +-save--filename.ext--+-------+-+ | '-force-' | '-newload--filename.ext---------'
The file extension (.ext) can be anything you like and is optional.
Examples
sscontrol file delete file3 File (file3) was deleted.
sscontrol file newload file1.sv File (file1.sv) was loaded into the Dispatcher.
sscontrol file appendload file2.sv File (file2.sv) was appended to the current configuration and loaded.
sscontrol file report FILE REPORT: file1.save file2.sv file3
sscontrol file save file3 The configuration was saved into file (file3).
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-logstatus--+ +-manager----+ +-metric-----+ +-nameserver-+ +-rule-------+ +-server-----+ +-set--------+ +-sitename---+ '-status-----'
Examples
sscontrol helpThis command produces output similar to:
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help name help - print complete help text advisor - help on advisor command file - help on file command host - help on host command manager - help on manager command metric - help on metric command sitename - help on sitename command nameserver - help on nameserver command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on logstatus commandParameters within < > are variables.
logsize <number of bytes | unlimited> -Set the maximum number of bytes to be logged in the log file
>>-sscontrol--logstatus----------------------------------------><
>>-sscontrol--manager--+-interval--seconds----------------------+->< +-loglevel--level------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-report--sitename+sn2+...+snN-----------+ +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-start--+----------------------+--------+ | '-logfile--metric_port-' | +-status---------------------------------+ +-stop-----------------------------------+ '-version--------------------------------'
The default file is installed in the logs directory. See Appendix C, Sample configuration files. To change the directory where the log files will be kept, see Changing the log file paths.
Examples
sscontrol manager interval 5
sscontrol manager loglevel 0
sscontrol manager logsize 1000000
sscontrol manager reportThis command produces output similar to:
---------------------------------- | SERVER | STATUS | ---------------------------------- | 9.67.129.221| ACTIVE| | 9.67.129.213| ACTIVE| | 9.67.134.223| ACTIVE| ---------------------------------- -------------------------- | MANAGER REPORT LEGEND | -------------------------- | CPU | CPU Load | | MEM | Memory Load | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | -------------------------- ------------------------------------------------------------------------ | mySite | WEIGHT | CPU 49% | MEM 50% | PORT 1% | SYS 0% | ------------------------------------------------------------------------ | |NOW NEW | WT LOAD | WT LOAD | WT LOAD | WT LOAD | ------------------------------------------------------------------------ | 9.37.56.180 | 10 10 |-99 -1|-99 -1|-99 -1| 0 0| ------------------------------------------------------------------------ | TOTALS:| 10 10 | -1| -1| -1| 0| ------------------------------------------------------------------------ ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ----------------------------------------- | http | 80 | unlimited | -----------------------------------------
sscontrol manager restart Restarting the manager to update codeThis command produces output similar to:
320-14:04:54 Restarting the manager to update code
sscontrol manager sensitivity 10
sscontrol manager smoothing 2.0
sscontrol manager start ndmgr.log
sscontrol manager statusThis command produces output similar to the following example.
Manager status: ============= Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 5 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--sitename+sn2+...+snN:metric+metric1+...+metricN--------------+->< +-remove--sitename+sn2+...+snN:metric+metric1+...+metricN-----------+ +-proportions--sitename+sn2+...+snN:proportion1 prop2 prop3...propN-+ '-status--sitename+sn2+...+snN metric+metric1+...+metricN-----------'
Examples
sscontrol metric add site1:metric1
sscontrol metric proportions site1 0 100
sscontrol metric status site1:metric1This command produces output similar to the following:
Metric Status: ------------ sitename ..................... site1 Metric name ................... metric1 Metric proportion ............. 50 Server ......... 9.37.56.100 Metric data .... -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--address-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--sitename+sn2+...+snN:rule+r2+...+rN--type--value--| value |--| opts |-+->< +-dropserver--sitename+sn2+...+snN:rule+r2+...+rN--server+s2+...+snN---------+ +-remove--sitename+sn2+...+snN:rule+r2+...+rN--------------------------------+ +-set--sitename+sn2+...+snN:rule+r2+...+rN--| value |--| opts |--------------+ +-status--sitename+sn2+...+snN:rule+r2+...+rN--------------------------------+ '-useserver--sitename+sn2+...+snN:rule+r2+...+rN--server+s2+...+snN----------' opts: |--+---------------------------------+--------------------------| +-beginrange--low--endrange--high-+ +-priority--value-----------------+ '-metricname--value---------------'
Examples
sscontrol rule add sitename:rulename type true priority 100
sscontrol rule add sitename:rulename type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add sitename:rulename type time beginrange 11 endrange 14 sscontrol rule useserver sitename:rulename server05
>>-sscontrol--server--+-add--sitename+sn2+...+snN:server+s2+...+sN--+------------------------+-+->< | +-metricaddress--address-+ | | '-weight--value----------' | +-down--sitename+sn2+...+snN:server+s2+...+sN----------------------------+ +-remove--sitename+sn2+...+snN:server+s2+...+sN--------------------------+ +-set--sitename+sn2+...+snN:server+s2+...+sN--+------------------------+-+ | +-metricaddress--address-+ | | '-weight--value----------' | +-status--sitename+sn2+...+snN:server+s2+...+sN--------------------------+ '-up--sitename+sn2+...+snN:server+s2+...+sN------------------------------'
Examples
sscontrol server add site1:27.65.89.42
sscontrol server down site1:27.65.89.42
sscontrol server remove :27.65.89.42
sscontrol server up site1:27.65.89.42
>>-sscontrol--set--+-loglevel--level--------+------------------>< '-logsize--+-unlimited-+-' '-size------'
>>-sscontrol--sitename--+-add--sitename+sn2+...+snN--+----------------------------------------+-+->< | +-cachelife--value-----------------------+ | | +-networkproximity--yes | no-------------+ | | +-proportions--cpu--memory--port--metric-+ | | +-proximitypercentage--value-------------+ | | +-stickytime--time-----------------------+ | | +-ttl--time------------------------------+ | | +-waitforallresponses--yes | no----------+ | | '-weightbound--weight--------------------' | +-remove--sitename+sn2+...+snN------------------------------------------+ +-set--sitename+sn2+...+snN--+----------------------------------------+-+ | +-cachelife--value-----------------------+ | | +-networkproximity--yes | no-------------+ | | +-proportions--cpu--memory--port--metric-+ | | +-proximitypercentage--value-------------+ | | +-stickytime--time-----------------------+ | | +-ttl--time------------------------------+ | | +-waitforallresponses--yes | no----------+ | | '-weightbound--weight--------------------' | '-status--sitename+sn2+...+snN------------------------------------------'
Examples
sscontrol sitename add 130.40.52.153
sscontrol sitename set mySite networkproximity yes
sscontrol sitename set mySite cachelife 1900000
sscontrol sitename set mySite proximitypercentage 45
sscontrol sitename set mySite waitforallresponses no
sscontrol sitename set mySite ttl 7
sscontrol sitename set mySite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status mySiteThis command produces output similar to:
SiteName Status: --------------- SiteName ........................... mySite WeightBound ........................ 20 TTL ................................ 5 StickyTime ......................... 0 Number of Servers .................. 1 Proportion given to CpuLoad ........ 49 Proportion given to MemLoad ........ 50 Proportion given to Port ........... 1 Proportion given to System metric .. 0 Advisor running on port ............ 80 Using Proximity .................... N
>>-sscontrol--status-------------------------------------------><
Examples
sscontrol statusThis command produces output similar to:
NameServer has been started. Manager has been started. ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
This chapter describes how to use the following ccocontrol commands for Cisco CSS Controller:
You can use an abbreviated version of the ccocontrol command parameters by typing the unique letters of the parameters. For example, to get help on the file save command, you can type ccocontrol he f instead of ccocontrol help file.
To get the ccocontrol command prompt: type ccocontrol.
To end the command line interface: type exit or quit.
>>-ccocontrol--consultant--+-add--scID--address--swIPAddr--community--commName-+->< +-binarylog--scID+scID2...--+-report-------------+--+ | +-set--+-interval--+-+ | | | '-retention-' | | | +-start--------------+ | | '-stop---------------' | +-remove--scID+scID2...-----------------------------+ +-report--scID+scID2...-----------------------------+ +-set--+-loglevel--level----------------+-----------+ | +-logsize--+-size------+---------+ | | | '-unlimited-' | | | +-sensitivity--weight percentage-+ | | '-sleeptime--sec-----------------' | +-start--scID+scID2...------------------------------+ '-stop--scID+scID2...-------------------------------'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
Examples
ccocontrol consultant add sc1 address 9.37.50.17 community comm2
ccocontrol consultant binarylog sc1 start
ccocontrol consultant report sc1
This command produces output similar to:
Consultant sc1 connected to switch at 9.37.50.1:cn1 Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 Log size = 1,048,576 ownerContent(s): ownerContent oc1
ccocontrol consultant set sc1 sleeptime 10
ccocontrol consultant start sc1
>>-ccocontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--level--------+ '-logsize--+-size------+-' '-unlimited-'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
Examples
ccocontrol controller report
This command produces output similar to:
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
ccocontrol set loglevel 0
ccocontrol controller set logsize 1000000
>>-ccocontrol--file--+-delete--filename----------+------------->< +-load--filename------------+ +-report--------------------+ '-save--filename--+-------+-' '-force-'
Install (default) directory: C:\Program Files\ibm\edge\lb\servers\configurations\cco
Examples
ccocontrol file delete file1
ccocontrol file load config2
ccocontrol file report
This command produces output similar to:
FILE REPORT: ------------ file1.xml file2.xml file3.xml
ccocontrol file save config2
>>-ccocontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metriccollector--+ +-ownercontent-----+ '-service----------'
Examples
ccocontrol help
This command produces output similar to:
The following commands are available: controller - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors ownerContent - operate on ownerContents service - operate on services
>>-ccocontrol--highavailability--+-add--+-address--address---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--address----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--time-----+---------+ | +-takeoverinterval--time-+ | | +-loglevel--level--------+ | | '-logsize--+-size------+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--address-----------------------'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
ccocontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
ccocontrol highavailability usereach 9.37.50.9
ccocontrol highavailability dropreach 9.37.50.9
ccocontrol highavailability start manual
ccocontrol highavailability report
This command produces output similar to:
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner --------------------------------------- No reach targets configured
>>-ccocontrol--metriccollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-timeoutconnect--sec----+-' +-loglevel--level--------+ +-logsize--+-size------+-+ | '-unlimited-' | +-timeoutreceive--sec----+ '-sleeptime--sec---------'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
Examples
ccocontrol metriccollector report sc1:http
This command produces output similar to:
MetricCollector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
ccocontrol metriccollector set sc1:http timeoutconnect 15 logsize unlimited
>>-ccocontrol--ownerContent--+-add--scID:ocN--ownername--oN--contentrule--cN------------------------------+->< +-metrics--scID+scID2...:ocN+ocN2...--mN--importance--mN2--i2----------------+ +-refresh--scID+scID2...:ocN+ocN2...-----------------------------------------+ +-remove--scID+scID2...:ocN+ocN2...------------------------------------------+ +-report--scID+scID2...:ocN+ocN2...------------------------------------------+ '-set--scID+scID2...:ocN+ocN2...----metric--mN--+------------------------+---' +-requeststring--string--+ +-responsestring--string-+ '-retry--numretries------'
Following is a list of valid metric names and their associated
ports.
Advisor Name | Protocol | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10,007 |
activeconn | n/a | n/a |
connrate | n/a | n/a |
cpuload | n/a | n/a |
memload | n/a | n/a |
Examples
ccocontrol ownerContent add sc1:oc1 ownername owner1 contentrule content1
ccocontrol ownerContent metrics sc1:oc1 activeconn 50 http 50
ccocontrol ownerContent report sc1:oc1
This command produces output similar to:
ownerContent sc1:oc1 Weightbound = 10 Metric activeconn has proportion 25 ResponseString... n/a RequestString.... n/a Metric http has proportion 50 ResponseString... n/a RequestString.... n/a Metric connrate has proportion 25 ResponseString... n/a RequestString.... n/a Contains Service t3 Contains Service t2 Contains Service t1
ccocontrol ownerContent set sc1:oc1 metric http requeststring getCookie
>>-ccocontrol--service--+-report--scID+scID2...:ocN+ocN2...:svc+svc2...---------------------------------+->< '---set--scID+scID2...:ocN+ocN2...:svc+svc2...--+---------------------------+---' +-fixedweight--+-integer-+--+ | '-off-----' | +-requestsourceip--IPAd-----+ +-metricserveraddress--IPAd-+ '-metricserverport--portN---'
Examples
ccocontrol service report sc1:oc1:t1
This command produces output similar to:
Service sc1:oc1:ta has weight 10 Fixed weight is off Request Source Ip..... 9.27.24.156 Application port...... 80 MetricServer address.. 1.0.0.1 MetricServer port..... 10004 Metric activeconn has value -99 Metric http has value -99 Metric connrate has value -99
ccocontrol service set sc1:oc1:t2 metricserveraddress 9.37.50.17
This chapter describes how to use the following nalcontrol commands for Nortel Alteon Controller:
You can use an abbreviated version of the nalcontrol command parameters by typing the unique letters of the parameters. For example, to get help on the file save command, you can type nalcontrol he f instead of nalcontrol help file.
To get the nalcontrol command prompt: type nalcontrol.
To end the command line interface: type exit or quit.
>>-nalcontrol--consultant--+-add--scID--address--swIPAddr--+---------------------------+-+->< | +-rcommunity--readCommName--+ | | '-wcommunity--writeCommName-' | +-binarylog--scID+scID2...--+-report------------------------+-+ | +-set--+-interval--interval---+-+ | | | '-retention--retention-' | | | +-start-------------------------+ | | '-stop--------------------------' | +-remove--scID+scID2...---------------------------------------+ +-report--scID+scID2...---------------------------------------+ +-set--+--------------------------------+---------------------+ | +-loglevel--level----------------+ | | +-logsize--+-size------+---------+ | | | '-unlimited-' | | | +-sensitivity--weight percentage-+ | | '-sleeptime--sec-----------------' | +-start--scID+scID2...----------------------------------------+ '-stop--scID+scID2...-----------------------------------------'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
Examples
nalcontrol consultant add sc1 address 9.37.50.17
nalcontrol consultant binarylog sc1 start
nalcontrol consultant report sc1
This command produces output similar to:
Consultant ID: sc1 Switch IP addr: 9.37.50.1 Read Community: public Write Community: private Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 log size = 1,048,576 Service(s): Service svc1
nalcontrol consultant set sc1 sleeptime 10
nalcontrol consultant start sc1
>>-nalcontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--level--------+ '-logsize--+-size------+-' '-unlimited-'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
Examples
nalcontrol controller report
This command produces output similar to:
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
nalcontrol set loglevel 0
nalcontrol controller set logsize 1000000
>>-nalcontrol--file--+-delete--filename-+---------------------->< +-load--filename---+ +-report-----------+ '-save--filename---'
Common install directory path -- C:\Program Files\ibm\edge\lb\servers\configurations\nal
Native install directory path -- C:\Program Files\ibm\lb\servers\configurations\nal
Examples
nalcontrol file delete file1
nalcontrol file load config2
nalcontrol file report
This command produces output similar to:
FILE R EPORT: ------------ file1.xml file2.xml file3.xml
nalcontrol file save config2
>>-nalcontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metrinalllector--+ +-ownercontent-----+ '-service----------'
Examples
nalcontrol help
This command produces output similar to:
The following commands are available: controller - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors server - operate on servers service - operate on services
>>-nalcontrol--highavailability--+-add--+-address--address---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--address----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--time-----+---------+ | +-takeoverinterval--time-+ | | +-loglevel--level--------+ | | '-logsize--+-size------+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--address-----------------------'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
nalcontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
nalcontrol highavailability usereach 9.37.50.9
nalcontrol highavailability dropreach 9.37.50.9
nalcontrol highavailability start manual
nalcontrol highavailability report
This command produces output similar to:
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 Started. . . . . . . . . . N State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner ---------------------------------------
>>-nalcontrol--metricollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-connecttimeout--sec----+-' +-loglevel--level--------+ +-logsize--+-size------+-+ | '-unlimited-' | +-receivetimeout--sec----+ '-sleeptime--sec---------'
0 = None
1 = Minimal
2 = Basic
3 = Moderate
4 = Advanced
5 = Verbose
Examples
nalcontrol metrinalllector report sc1:http
This command produces output similar to:
Metrinalllector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
nalcontrol metrinalllector set sc1:http connecttimeout 15 logsize unlimited
>>-nalcontrol--serer--+-report--scID+scID2...:svcID+svcID2...:serverID+svrID2...-----------------------------------+->< '---set--scID+scID2...:svcID+svcID2...:serverID+svrID2--+--------------------------------+---' +-fixedweight--+-integer-+-------+ | '-off-----' | +-requestsourceip--IPAddress-----+ +-metricserveraddress--IPAddress-+ '-metricserverport--portNumber---'
Examples
nalcontrol server report sc1:svc1:1
This command produces output similar to:
Server sc1:svc1:1 has weight -99 Fixed weight is off Request Source Ip...... 9.27.24.156 Application port....... 99 MetricServer address... 9.99.99.98 MetricServer port...... 10004 Metric activeconn has value -99 Metric connrate has value -99
nalcontrol server set sc1:svc1:2 metricserveraddress 9.37.50.17
>>-nalcontrol--service--+-add--scID+scID2...:serviceID+svcID2...--vsid--virSvrID--vport--virPortNum------+->< +-metrics--scID+scID2...:svcID+svcID2...--mN--importance--mCN2--i2---------------+ +-refresh--scID+scID2...:svcID+svcID2...-----------------------------------------+ +-remove--scID+scID2...:svcID+svcID2...------------------------------------------+ +-report--scID+scID2...:svcID+svcID2...------------------------------------------+ '-set--scID+scID2...:svcID+svcID2...----metric--mN----+-requeststring--string--+-' +-responsestring--string-+ '-retry--numretries------'
Following is a list of valid metric names and their associated
ports.
Advisor Name | Protocol | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10,007 |
activeconn | n/a | n/a |
connrate | n/a | n/a |
cpuload | n/a | n/a |
memload | n/a | n/a |
Examples
nalcontrol service add sc1:svc1 vsid 1 vport 80
nalcontrol service metrics sc1:svc1 activeconn 50 http 50
nalcontrol service report sc1:svc1
This command produces output similar to:x
Service sc1:svc1 Weightbound = 48 Metric activeconn has proportion 50 Metric connrate has rpoportion 50 Contains Server 4 Contains Server 3 Contains Server 2 Contains Server 1
nalcontrol service set sc1:svc1 metric http requeststring getLastErrorCode
In the Load Balancer graphical user interface (GUI), the left side of the panel displays a tree structure with Load Balancer at the top level, and Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller, and Nortel Alteon Controller as components.
If you are using the Load Balancer for IPv6 installation, only the Dispatcher component is available. For more information, see Deploying Dispatcher on Load Balancer for IPv6.
For graphical examples of the Load Balancer GUI that highlight each of the different components, refer to the following:
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 then 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.
Click the plus or minus signs to expand or compact the items in the tree structure.
In order to execute a command from the GUI: highlight the Host node from the GUI tree and select Send command.... from the Host pop-up menu. In the command entry field, type the command that you want to execute, for example: executor report. The results and history of the commands run in the current session appear in the window provided.
The right side of the panel displays status indicator tabs for the element currently selected.
To access Help, click the question mark (?) in the upper right hand corner of the Load Balancer window.
This appendix describes how to use the content rule (pattern) syntax for the CBR component and the Dispatcher component's cbr forwarding method, along with scenarios and examples of their usage.
Only applicable if you selected "content" for the rule type.
Enter the pattern syntax you want to use, with the following restrictions
Reserved keywords are always followed by an equal sign "=".
A browser targeting http://www.company.com/path/webpage.htm might result in values such as:
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.company.com Connection=Keep-Alive Referer=http://www.company.com/path/parentwebpage.htm
For example, the following command is valid only when using the cbrcontrol>> prompt.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern client=181.0.153.222&uri=/nipoek/*
When using special characters, for this same command to work at the operating system's prompt, double quotation marks (" ") must be placed around the pattern as follows:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "client=181.0.153.222&uri=/nipoek/*"
If the quotation marks are not used, some of the pattern might be truncated when the rule is saved in CBR. Note that quotation marks are not supported when using the cbrcontrol>> command prompt.
The following is a collection of possible scenarios and examples for using pattern syntaxes
Scenario 1:
The setup for one cluster name involves one set of Web servers for standard HTML content, another set of Web servers with WebSphere Application Server for servlet requests, another set of Lotus(R) Notes(R) servers for NSF files, and so forth. Access to the client data is required to distinguish between those requested pages. It is also required to send them to the appropriate servers. The content pattern matching rules provide the separation needed to accomplish these tasks. A series of rules are configured so that the necessary separation of requests occurs automatically. For example, the following commands accomplish the three splits mentioned:
>>rule add cluster1:80:servlets type content pattern uri=*/servlet/* priority 1 >>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern uri=*.nsf* priority 2 >>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3 >>rule uses cluster1:80:regular server5+server6
If a request for an NSF file arrives at Load Balancer, the servlets rule is checked first, but does not match. The request is then checked by the notes rule and returns a match. The client is load-balanced between server3 and server4.
Scenario 2
Another common scenario is when the main Web site controls several distinct internal groups. For example, www.company.com/software involves a different set of servers and content from www.company.com/hardware division. Because the requests are all based off the root www.company.com cluster, content rules are required to find the URI differences and complete load balancing. The scenario's rule looks similar to the following:
>>rule add cluster1:80:div1 type content pattern uri=/software/* priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern uri=/hardware/* priority 2 >>rule uses cluster1:80:div2 server3+server4
Scenario 3
Certain combinations are sensitive to the order in which rules are searched. For example, in Scenario 2, clients were split based on a directory in their request path; however, the target directory might appear at multiple levels of the path and mean different things on placement. For example, www.company.com/pcs/fixes/software is a different target from www.company.com/mainframe/fixes/software. The rules must be defined to account for this possibility and not catch too many scenarios at the same time. For example, the "uri=*/software/*" test is too broad a wildcard search in this case. Alternative rules could be structured in the following manner:
A combination search can narrow this down:
>>rule add cluster1:80:pcs type content pattern (uri=/pcs/*)&(uri=*/software/*) >>rule uses cluster 1:80:pcs server1
In cases where there are no combinations to use, the order becomes important:
>>rule add cluster1:80:pc1 type content pattern uri=/pcs/* >>rule uses cluster1:80:pc1 server2
The second rule catches when "pcs" appears in later directory spots instead of the first.
>>rule add cluster1:80:pc2 type content pattern uri=/*/pcs/* >>rule uses cluster1:80:pc2 server3
In almost every case, you want to complete the rules with a default always true rule to catch anything that falls through the other rules. This can also be a "Sorry, the site is currently down, please try again later" server for scenarios where all other servers fail for this client.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5
This appendix contains sample configuration files for the Dispatcher component of Load Balancer.
IMPORTANT: If you are using the Load Balancer for IPv6 installation, remember to substitute at (@) for colon (:) as the delimiter within dscontrol commands in these sample configuration files.
Sample files are located in the ...ibm/edge/lb/servers/samples/ directory.
#!/bin/bash
#
# 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
#
# dsserver start
# sleep 5
#
# Then start the executor
#
# dscontrol executor start
#
# The Dispatcher can be removed at any time using the
# "dscontrol executor stop" and "dsserver 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"
# dscontrol 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 "
# dscontrol 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"
# dscontrol 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"
# dscontrol 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.
# These proportions must add up to 100. As an example, setting
# the manager proportions to
# dscontrol 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..."
# dscontrol manager start
# echo "Starting the FTP advisor on port 21 ..."
# dscontrol advisor start ftp 21
# echo "Starting the HTTP advisor on port 80 ..."
# dscontrol advisor start http 80
# echo "Starting the Telnet advisor on port 23 ..."
# dscontrol advisor start telnet 23
# echo "Starting the SMTP advisor on port 25 ..."
# dscontrol advisor start smtp 25
# echo "Starting the POP3 advisor on port 110 ..."
# dscontrol advisor start pop3 110
# echo "Starting the NNTP advisor on port 119 ..."
# dscontrol advisor start nntp 119
# echo "Starting the SSL advisor on port 443 ..."
# dscontrol advisor start ssl 443
#
# echo "Setting the manager proportions..."
# dscontrol 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.
# dscontrol executor 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.
# dscontrol executor 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.
# dscontrol manager loglevel 1
# dscontrol manager logsize 1048576
# dscontrol manager sensitivity 5.000000
# dscontrol manager interval 2
# dscontrol manager refresh 2
#
# dscontrol advisor interval ftp 21 5
# dscontrol advisor loglevel ftp 21 1
# dscontrol advisor logsize ftp 21 1048576
# dscontrol advisor timeout ftp 21 unlimited
# dscontrol advisor interval telnet 23 5
# dscontrol advisor loglevel telnet 23 1
# dscontrol advisor logsize telnet 23 1048576
# dscontrol advisor timeout telnet 23 unlimited
# dscontrol advisor interval smtp 25 5
# dscontrol advisor loglevel smtp 25 1
# dscontrol advisor logsize smtp 25 1048576
# dscontrol advisor timeout smtp 25 unlimited
# dscontrol advisor interval http 80 5
# dscontrol advisor loglevel http 80 1
# dscontrol advisor logsize http 80 1048576
# dscontrol advisor timeout http 80 unlimited
# dscontrol advisor interval pop3 110 5
# dscontrol advisor loglevel pop3 110 1
# dscontrol advisor logsize pop3 110 1048576
# dscontrol advisor timeout pop3 110 unlimited
# dscontrol advisor interval nntp 119 5
# dscontrol advisor loglevel nntp 119 1
# dscontrol advisor logsize nntp 119 1048576
# dscontrol advisor timeout nntp 119 unlimited
# dscontrol advisor interval ssl 443 5
# dscontrol advisor loglevel ssl 443 1
# dscontrol advisor logsize ssl 443 1048576
# dscontrol advisor timeout ssl 443 unlimited
#
The following is a sample Load Balancer 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 dsserver must be started via Services rem rem rem Then start the executor rem rem call dscontrol 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 dscontrol 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 dscontrol executor set fintimeout 30 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 dscontrol 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 dscontrol 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 dscontrol 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. rem rem These proportions must add up to 100. As an example, rem setting the cluster proportions via rem dscontrol cluster set <cluster> proportions 48 48 4 0 rem will give active and new connections 48% input into the rem weighting decision, the advisor will contribute 4% and rem the system input will not be considered. rem rem NOTE: By default the manager proportions are set to rem 50 50 0 0 rem echo "Starting the manager..." rem call dscontrol manager start rem echo "Starting the FTP advisor on port 21 ..." rem call dscontrol advisor start ftp 21 rem echo "Starting the HTTP advisor on port 80 ..." rem call dscontrol advisor start http 80 rem echo "Starting the Telnet advisor on port 23 ..." rem call dscontrol advisor start telnet 23 rem echo "Starting the SMTP advisor on port 25 ..." rem call dscontrol advisor start smtp 25 rem echo "Starting the POP3 advisor on port 110 ..." rem call dscontrol advisor start pop3 110 rem echo "Starting the NNTP advisor on port 119 ..." rem call dscontrol advisor start nntp 119 rem echo "Starting the SSL advisor on port 443 ..." rem call dscontrol advisor start ssl 443 rem rem echo "Setting the cluster proportions..." rem call dscontrol cluster set %CLUSTER% 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 dscontrol executor configure %CLUSTER% rem If your cluster address is on a different NIC or subnet rem from the NFA use the following format for the cluster rem configure command. rem dscontrol executor 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 dscontrol manager loglevel 1 rem call dscontrol manager logsize 1048576 rem call dscontrol manager sensitivity 5.000000 rem call dscontrol manager interval 2 rem call dscontrol manager refresh 2 rem rem call dscontrol advisor interval ftp 21 5 rem call dscontrol advisor loglevel ftp 21 1 rem call dscontrol advisor logsize ftp 21 1048576 rem call dscontrol advisor timeout ftp 21 unlimited rem call dscontrol advisor interval telnet 23 5 rem call dscontrol advisor loglevel telnet 23 1 rem call dscontrol advisor logsize telnet 23 1048576 rem call dscontrol advisor timeout telnet 23 unlimited rem call dscontrol advisor interval smtp 25 5 rem call dscontrol advisor loglevel smtp 25 1 rem call dscontrol advisor logsize smtp 25 1048576 rem call dscontrol advisor timeout smtp 25 unlimited rem call dscontrol advisor interval http 80 5 rem call dscontrol advisor loglevel http 80 1 rem call dscontrol advisor logsize http 80 1048576 rem call dscontrol advisor timeout http 80 unlimited rem call dscontrol advisor interval pop3 110 5 rem call dscontrol advisor loglevel pop3 110 1 rem call dscontrol advisor logsize pop3 110 1048576 rem call dscontrol advisor timeout pop3 110 unlimited rem call dscontrol advisor interval nntp 119 5 rem call dscontrol advisor loglevel nntp 119 1 rem call dscontrol advisor logsize nntp 119 1048576 rem call dscontrol advisor timeout nntp 119 unlimited rem call dscontrol advisor interval ssl 443 5 rem call dscontrol advisor loglevel ssl 443 1 rem call dscontrol advisor logsize ssl 443 1048576 rem call dscontrol advisor timeout ssl 443 unlimited rem
The following is a sample advisor file called ADV_sample.
/**
* ADV_sample: The Load Balancer HTTP advisor
*
*
* This class defines a sample custom advisor for Load Balancer. 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 Load Balancer
* for use in the Load Balancer'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 Load Balancer directory:
*
* lb/servers/lib/CustomAdvisors/ (lb\servers\lib\CustomAdvisors on Windows)
*
* - 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>/lib/CustomAdvisors/ADV_sample.class
*
*
* Advisors, as with the rest of Load Balancer, must be compiled with the
* prereq version of Java. To ensure access to Load Balancer classes, make
* sure that the ibmlb.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 sDefaultName = 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 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 Load Balancer 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_Load_Balancer_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 Load
* Balancer-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 lower the weight will become within the Load Balancer.
*
* 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. Load Balancer will
* not attempt to load balance to a server that is down. Load Balancer will
* resume load balancing to the server when a positive value is received.
*
*/
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);
/**
* In the normal advisor mode ("replace" flag is false), the load
* returned is either 0 or 1 indicating the server is up or down.
* If the receive is successful, a load of zero is returned
* indicating that the load built within the base advisor is to be used.
*
* Otherwise ("replace" flag is true), return the desired load value.
*/
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // End - ADV_sample
This appendix describes how to set up a 2-tier, high availability configuration combining the capabilities of two Load Balancer components (the Dispatcher component and the CBR component) along with Caching Proxy.
The server machine set up for Figure 46 is the following:
Figure 46 shows a basic representation of multiple servers (EdgeServer1, EdgeServer2, EdgeServer3) load balancing across multiple backend Web servers. The CBR component uses Caching Proxy to forward requests based on the content of the URL to the backend Web servers. The Dispatcher component is used to load balance the CBR components across the EdgeServers. The high availability feature of the Dispatcher component is used to ensure that requests to the backend servers continue even if the primary high availability machine (EdgeServer1) fails at any time.
Basic Configuration Guidelines:
Caching ON CacheMemory 128000 K ReversePass /* http://websrvA.company.com/* http://www.company.com/*
Sample Configuration Files:
The following sample configuration files are similar to files that are created when setting up an Edge Components configuration as shown in Figure 46. The sample configuration files represent the files for the Dispatcher and CBR components of Load Balancer. In the sample configuration, a single ethernet adapter is used for each of the EdgeServer machines and all addresses are represented within a private subnet. The sample configuration files use the following IP addresses for the specified machines:
Sample Configuration file for Dispatcher component on Primary high availability EdgeServer:
dscontrol executor start dscontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 dscontrol port add 192.168.1.11:80 dscontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 dscontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 dscontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 dscontrol manager start manager.log 10004 dscontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 dscontrol highavailability backup add primary auto 4567
Sample Configuration file for CBR component on the EdgeServers:
cbrcontrol set loglevel 1 cbrcontrol executor start cbrcontrol cluster add 192.168.1.11 cbrcontrol port add 192.168.1.11:80 cbrcontrol server add 192.168.1.11:80:webserverA address 192.168.1.71 cbrcontrol server add 192.168.1.11:80:webserverB address 192.168.1.72 cbrcontrol server add 192.168.1.11:80:webserverC address 192.168.1.73 cbrcontrol rule add 192.168.1.11:80:webA_rule type content pattern (URI=*WSA*)|(URI=*wsA*) priority 21 cbrcontrol rule useserver 192.168.1.11:80:webA_rule webserverA cbrcontrol rule add 192.168.1.11:80:webB_rule type content pattern (URI=/WS_B*) priority 22 cbrcontrol rule useserver 192.168.1.11:80:webB_rule webserverB cbrcontrol rule add 192.168.1.11:80:webC_rule type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_rule webserverC
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any no-IBM product, program or service.
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:
IBM Director of Licensing
IBM Corporation
500 Columbus Avenue
Thornwood, NY 10594
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the
IBM Intellectual Property Department in your country or send inquiries, in
writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OR CONDITIONS OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions or the document. IBM may make improvements and / or changes in the product(s) and / or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
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:
IBM Corporation
Attn.: G7IA./503.
P.O. Box 12195
3039 Cornwallis Rd.
Research Triangle Park, N.C. 27709-2195
U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM International Program License Agreement or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is not guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples may include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.
If you are viewing this information softcopy, the photographs and color illustrations many not appear.
The following terms are registered trademarks or trademarks of IBM Corporation in the United States, other countries, or both.
AFS
AIX
DFS
IBM
iSeries
NetView
OS/2
Redbooks(TM)
RS/6000(R)
SecureWay
ViaVoice
WebSphere
zSeries
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Intel, Intel Inside (logos), MMX(TM) and Pentium(R) are trademarks of Intel Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.