Operating and managing Load Balancer

Note:
When reading this chapter, in the general sections that are not specific to one component, if you are not using the Dispatcher component, then substitute "dscontrol" and "dsserver" with the following:

This chapter explains how to operate and manage Load Balancer and includes the following sections:

Remote administration of Load Balancer

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, and so on) 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.

Remote Method Invocation (RMI)

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 is 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:

lbkeys [create|delete]

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:

The script also creates public keys in the administration keys directory 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 the following 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.

After 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 using the GUI by typing lbadmin from a command prompt.

Note:
Due to changes to security packages in the Java version, Load Balancer keys generated for releases prior to v5.1.1 may not be compatible with the keys for the current release, so you must regenerate your keys when you install a new release.

Web-based administration

Requirements

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:

Configuring Caching Proxy

Running and accessing Web-based administration

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.

When 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:

  1. highlight the Host node from the GUI tree
  2. select Send command... from the Host pop-up menu
  3. in the command entry field, type the command that you want to run. For example: executor report. The results and history of the commands run in the current session appear in the window provided.

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

Using Load Balancer logs

For Dispatcher, CBR, and Site Selector

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.

Note:
Additionally, for the Dispatcher component only, entries can be made to a subagent (SNMP) log.
Note:
The Content Based Routing (CBR) component is not available on platforms that run a 64-bit JVM, except for HP-UX ia64. On HP-UX ia64, the CBR component runs as a 32-bit application. You can use the CBR forwarding method of Load Balancer's Dispatcher component to provide content-based routing without the use of Caching Proxy. See Dispatcher's content-based routing (cbr forwarding method) for more information.

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 customize the following logging features:

Configure logging with the following commands:

Changing the log file paths

By default, the logs generated by Load Balancer are 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 systems: 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 systems: The dsserver file is found in the <install_root>ibm\edge\lb\bin directory. 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).

Binary logging

Note:
Binary logging does not apply to the Site Selector component.

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.

For Cisco CSS Controller and Nortel Alteon Controller

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.

Controller logs

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

Changing the log file paths

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 systems: 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 systems: The xxxserver file is found in the <install_root>ibm\edge\lb\bin directory. 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).

Binary logging

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.

Using the Dispatcher component

This section explains how to operate and manage the Dispatcher component.

Starting and Stopping Dispatcher

Using stale timeout value

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 is 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 causes 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.

Using fintimeout and staletimeout to control cleanup of connection records

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. When a connection in the FIN state exceeds fintimeout, it is 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.

Reporting GUI -- the Monitor menu option

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):

Using Simple Network Management Protocol with the Dispatcher component

A network management system is a program that runs continuously and is used to monitor, reflect status of, and control a network. Simple Network Management Protocol (SNMP), a popular protocol for communicating with devices in a network, is the current network management standard. The network devices typically have an SNMP agent and one or more subagents. The SNMP agent talks to the network management station or responds to command line SNMP requests. The SNMP subagent retrieves and updates data and gives that data to the SNMP agent to communicate back to the requester.

Dispatcher provides an SNMP Management Information Base (ibmNetDispatcherMIB) and an SNMP subagent. This allows you to use any network management system, such as -- Tivoli® NetView®, Tivoli Distributed Monitoring, or HP OpenView -- to monitor the Dispatcher's health, throughput, and activity. The MIB data describes the Dispatcher being managed and reflects current Dispatcher status. The MIB gets installed in the ..lb/admin/MIB subdirectory.

Note:
The MIB, ibmNetDispatcherMIB.02, will not load using Tivoli NetView xnmloadmib2 program. To fix this problem, comment out the NOTIFICATION-GROUP section of the MIB. That is, insert "- -" in front of the line "indMibNotifications Group NOTIFICATION-GROUP", and the 6 lines which follow.

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.

SNMP commands and protocol

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) 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.

Enabling SNMP on AIX, HP-UX, Linux, and Solaris systems

Figure 37. SNMP commands for AIX, HP-UX, Linux, and Solaris operating systems
SNMP commands and server system for AIX, HP-UX, Linux, and Solaris

AIX systems 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 systems, you must obtain an SNMP agent that is SMUX-enabled because HP-UX does not provide one. Load Balancer provides DPID2 for HP-UX systems.

Linux systems 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 systems.

Note:
For SuSE Linux systems, you must obtain an SNMP agent that is SMUX-enabled because SuSE does not provide one.

For Solaris systems, you must obtain an SNMP agent that is SMUX-enabled because Solaris does not provide one. Load Balancer provides DPID2 for Solaris systems in the /opt/ibm/edge/lb/servers/samples/SNMP directory.

The DPI agent must run as a root user. Before you run the DPID2 daemon, update the /etc/snmpd.peers file and the /etc/snmpd.conf file as follows:

For AIX and Solaris systems:

For Linux systems:

Enable SNMP on HP-UX systems

To install HP-UX SNMP support:

  1. If you do not have a version of GNU SED installed, obtain it from the HP Web site, http://www.hp.com.
  2. Obtain ucd-snmp-4.2.4.tar.gz from the following Web page, http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Ensure that you have "gcc" and "gmake or make" installed on your machine. If not, you must install them.
  4. Unzip the ucd-snmp-4.2.4.tar.gz file and then untar all of the source files in the directory.
  5. Go to the directory where the source files are kept and then do the following:
    1. run ./configure --with-mib-modules=smux
    2. make
    3. Run the next two commands as root:
      1. umask 022
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd -s (This starts the SNMP agent)
    6. start dpid2 (This starts the DPI translator)
    7. dscontrol subagent start (This starts the Dispatcher subagent)

Enable SNMP on SuSE Linux systems

In order to use Load Balancer SNMP with SuSE Linux sysems, you must do the following:

  1. Remove the installed ucd-snmp rpm from the SuSE machine.
  2. Get ucd-snmp-4.2.4.tar.gz from http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Make sure you have "gcc" and "gmake or make" installed on your SuSE machine (you must install them if they are not there).
  4. Unzip the ucd-snmp-4.2.4.tar.gz file and then untar all of the source files in the directory.
  5. Go to the directory where the source files are kept and then do the following:
    1. run ./configure --with-mib-modules=smux
    2. make
    3. Run the next two commands as root:
      1. umask 022 #
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd -s
    6. start dpid2

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:

  1. SNMP agent
  2. DPI translator
  3. Dispatcher subagent

Enabling SNMP on Solaris systems

To install Solaris SNMP support:

  1. Kill the running Solaris SNMP daemon (snmpdx and snmpXdmid).
  2. Rename files as follows:
  3. Download the following packages from http://www.sunfreeware.com/:
  4. Install the downloaded packages using pkgadd.
  5. Download ucd-snmp-4.2.3-solaris8.tar.gz from http://sourceforge.net/project/showfiles.php?group_id=12694
  6. Gunzip and untar the ucd-snmp-4.2.3-solaris8.tar.gz at root directory (/)
  7. Issue the following commands:
  8. It it does not already exist, create /etc/snmpd.peers. Insert the following into snmpd.peers:
    "dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2     "dpid_password"
  9. If it does not already exist, create /etc/snmp/snmpd.conf. Insert the following into snmpd.conf:
    smuxpeer        1.3.6.1.4.1.2.3.1.2.2.1.1.2     dpid_password
  10. Start /usr/local/sbin/snmpd.
  11. Start /usr/local/sbin/dpid2.
Notes:
  1. The following packages are in package format.
    • libgcc-3.0.3-sol8-sparc-local (SMClibgcc)
    • openssl-0.9.6c-sol8-sparc-local (SMCosslc)
    • popt-1.6.3-sol8-sparc-local (SMCpopt)

    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.

  2. When you are adding the smuxpeer entry in /etc/snmp/snmpd.conf, make sure no space is added to the dpid_password string.
  3. The Load Balancer SNMP feature is tested with smux-enabled ucd-snmp version 4.2.3. Future releases of ucd-snmp with smux should work with similar setup.

Enabling SNMP on Windows operating system

To install the Windows SNMP support:

  1. Click Start > Control Panel > Add/Remove Programs.
  2. Click Add/Remove Windows Components.
  3. In the Windows Component Wizard, click Management and Monitoring Tools (but do not select or clear its check box), then click Details
  4. Select the Simple Network Management Protocol checkbox, click OK.
  5. Click Next.

Providing a community name for SNMP

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:

  1. Open Computer Management
  2. In the console tree, click Services
  3. In the details pane, click SNMP Service
  4. On the action menu, click Properties
  5. On the Security tab, under Accepted community names, click Add
  6. Under Community Rights, select a permission level for this host to process SNMP requests from the selected community (at least Read Only permission)
  7. In Community Name, type a case-sensitive community name, the same as you provided to the Load Balancer Subagent (default community name: public), and then click Add
  8. Specify whether or not to accept SNMP packets from a host. Choose one of the following options:
  9. Restart the SNMP Service in order for the change to take effect

Traps

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:

-idle
This machine is load balancing and is not trying to establish contact with its partner Dispatcher.
-listen
High availability has just started and the Dispatcher is listening for its partner.
-active
This machine is load balancing.
-standby
This machine is monitoring the active machine.
-preempt
This machine is in a transitory state during the switch from primary to backup.
-elect
The Dispatcher is negotiating with its partner regarding who will be the primary or backup.
-no_exec
The executor is not running

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 is sent after an indDOSAttack trap is sent.

For AIX, HP-UX, Linux, and Solaris operating 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 are able to determine the source of the trap because the data will contain an object identifier from within the ibmNetDispatcher MIB.

Turning the SNMP support on and off from the dscontrol command

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.

Using ipchains or iptables to reject all traffic to harden the Load Balancer machine (Linux systems)

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 backend 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 need to repeat these step each time you reboot.

For more information, see Problem: Linux iptables can interfere with the routing of packets.

Using the Content Based Routing component

This section explains how to operate and manage the CBR component of Load Balancer.

Note:
The Content Based Routing (CBR) component is not available on platforms that run a 64-bit JVM, except for HP-UX ia64. On HP-UX ia64, the CBR component runs as a 32-bit application. You can use the CBR forwarding method of Load Balancer's Dispatcher component to provide content-based routing without the use of Caching Proxy. See Dispatcher's content-based routing (cbr forwarding method) for more information.

Starting and Stopping CBR

CBR and Caching Proxy collaborate using 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.

Controlling CBR

After starting CBR, you can control it using either of the following methods:

Using CBR logs

The logs used by CBR are similar to those used in Dispatcher. For more information, see Using Load Balancer logs.

Note:

In previous releases, for CBR you could change the log directory path in the Caching Proxy configuration file. Now you can change the directory path where the log gets stored in the cbrserver file. See Changing the log file paths.

Using the Site Selector component

Starting and stopping Site Selector

Controlling Site Selector

After starting Site Selector, you can control it using either of the following methods:

Using Site Selector logs

The logs used by Site Selector are similar to those used in Dispatcher. For more description, see Using Load Balancer logs.

Using the Cisco CSS Controller component

Starting and stopping Cisco CSS Controller

  1. Type ccoserver on a command line to start Cisco CSS Controller.
  2. Type ccoserver stop on a command line to stop Cisco CSS Controller.

Controlling Cisco CSS Controller

After starting Cisco CSS Controller, you can control it using either of the following methods:

Using Cisco CSS Controller logs

The logs used by Cisco CSS Controller are similar to those used in Dispatcher. For more description, see Using Load Balancer logs.

Using the Nortel Alteon Controller component

Starting and stopping Nortel Alteon Controller

  1. Type nalserver on a command line to start Nortel Alteon Controller.
  2. Type nalserver stop on a command line to stop Nortel Alteon Controller.

Controlling Nortel Alteon Controller

After starting Nortel Alteon Controller, you can control it using either of the following methods:

Using Nortel Alteon Controller logs

The logs used by Nortel Alteon Controller are similar to those used in Dispatcher. For more description, see Using Load Balancer logs.

Using the Metric Server component

Starting and stopping Metric Server

Metric Server provides server load information to the Load Balancer. Metric Server resides on each of the servers that are being load balanced.

Linux and UNIX systems:

Windows systems:

Click Start > Control Panel > Administrative Tools > Services. Right-click IBM Metric Server and select Start. To stop the service, follow the same steps and select Stop.

Using Metric Server logs

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.