This appendix describes sample NQE configurations for NQE administrators and discusses the following topics:
NQE servers and clients
NQE cluster configuration
NQS queue structure
NQE database and scheduler structure
NQE consists of a cluster of servers and clients. The following components can be configured to run on nodes in an NQE cluster:
The Network Load Balancer (NLB) server which receives and stores information from the NLB collectors in the NLB database which it manages.
The NQE database server which serves connections from clients, the scheduler, the monitor and lightweight server (LWS) components in the cluster to add, modify, or remove data from the NQE database.
The NQE scheduler which analyses data in the NQE database, making scheduling decisions.
The NQE database monitor which monitors the state of the database and which NQE database components are connected.
NQS which schedules and initiates batch requests on the local server.
FTA which adds reliability through transfer retry and recovery and through network peer-to-peer authorization (NPPA). FTA transfers may be initiated on any server and those transfers may retrieve files from or copy files to any NQE server or client.
NLB collectors which collect and communicate system load information to the NLB server so that the NLB can provide NQS with a list of servers, in order of preference, to run a request and provide status information upon request.
The LWS which obtains request information from the NQE database, verifies validation, submits the copy of a request to NQS, and obtains exit status of completed requests from NQS. The LWS may override NQS scheduling. For information about LWS attributes, see Chapter 9, “NQE Database”, and Chapter 10, “Writing an NQE Scheduler”.
NQE clients contain software so users may submit, monitor, and control requests by using either the NQE graphical user interface (GUI) or the command-line interface. From clients, users also may monitor request status, delete or signal requests, monitor machine load, and receive request output.
For more information on components which can be configured to run on nodes in an NQE cluster, see “NQE Environment” in Chapter 1.
NQE uses the FLEXlm license manager to license the product. Before you can run NQE, a license manager must be installed and running. The license manager can run on any server or on another (nonserver) host.
The NLB collector is run on all NQS server nodes to collect the following:
NQS request status data
Host load information for destination selection
By default, the collector is configured to report the system batch queue as [email protected] hostname and to send information to the NLB server.
The initial configuration of NQE starts the following components: NQS, NLB, and Collector
This section describes NQE clusters and gives you information about selecting servers. You can expand the examples to suit the needs of your network.
A simple cluster has one node to execute batch requests and has some clients, as shown in Figure B-1.
An NQE load-balanced cluster has one NLB server, multiple NQS servers, and multiple clients, as shown in Figure B-2. Clients submit work to an NQE load-balancing queue on any node. In this network, requests are sent to any node in an NQE cluster. To set up a quorum, the license manager is placed on each node.
An NQE scheduler cluster has one NQE database server, multiple NQS servers, one NLB server, and multiple clients, and is in this sense the same as the load-balanced cluster shown in Figure B-2. The difference between the two clusters lies in how work is scheduled, as described in section “NQE Database and Scheduler Structure”.
The following types of NQE servers can exist in the NQE cluster:
At least one node with high availability for the NQE cluster. The NLB load-balancing server and NQE database server run on this node.
Typically, the NQE cluster includes additional NQS servers that have sufficient CPU cycles to be used for executing batch requests. However, in a simple network, this might be the same node as the NLB server.
Typically, many workstations are designated as NQE clients, which do not provide batch execution cycles to the NQE cluster.
NQE comes configured with a default NQS load-balancing policy that assumes all of your NLB servers are of similar speed and that you want requests sent to the system that has the lowest CPU load. You can alter this policy or create others to suit your needs. For example, you could create policies that weigh and normalize differences in system CPU, or you could create policies that define sets of systems with important characteristics (some systems might run a given application, some systems might be for compiling, and so on). Chapter 8, “Implementing NLB Policies”, describes how to define and implement load-balancing policies.
In certain environments, it is not sufficient to choose a destination for a request by using NLB policies. For example, you may want to wait to send requests to a machine until its idle CPU is greater than 90%, or you may want to allow a user to run only one request at a time across the entire NQE cluster, regardless of which machine.
In such cases, you can use the NQE scheduler and NQE database. For a summary of how the NQE scheduler and NQE database are structured, see section “NQE Database and Scheduler Structure”. For more information, see Chapter 9, “NQE Database”, and Chapter 10, “Writing an NQE Scheduler”.
NQS supports two types of queues: batch queues, which initiate requests; and pipe queues, which route work to appropriate destinations for execution or further routing. A destination selection queue is a pipe queue that uses load-balancing to route requests. These pipe queues are associated with policies.
When requests enter a destination-selection queue, NQS queries the NLB for a list of destinations. The list is ordered based on the policy. When multiple destinations fit the policy, NQS tries the first destination. If for some reason the first destination cannot accept the request, NQS tries the second, and so on.
When you submit a request, NQS places it in the default queue unless you specify otherwise. NQE is shipped with the following queues configured:
The destination-selection queue nqenlb, which is the default for request submission.
The batch queue nqebatch, which handles local batch request submissions and accepts requests from other destination-selection queues in the NQE cluster.
This configuration uses the NLB to send requests to the most appropriate system, based on an NLB policy. The default NLB policy, called nqs, sends batch requests to the system that has the lowest CPU load.
If users submit requests to the nqebatch queue, the request runs on the local NQS server.
Part of the configuration process is to define these queues and to interconnect the different instances of NQS to form the NQE cluster.
The NQS_SERVER environment variable points to the NQS server that handles NQE request submission. If you want your request run on another NQS server explicitly, you can change the NQS_SERVER environment variable to point to another host running NQS. You must have access to an account on this host and must have set up NQS validation as described in Introducing NQE, publication IN-2153.
Figure B-3 shows how the default NQE configuration would look in a network that had one NLB server and two NQS servers. The nqebatch queue on each NQS system is configured by default to allow no more than six requests to run at one time and to allow no more than two requests from a user to run at one time on each NQS system. If the queue is full (running the predefined number of requests), requests wait in the nqebatch queue until an opening occurs, or until the queue limits are changed.
The NQE database and NQE scheduler let clients submit work to the NQE central storage database on the NQE database server. The scheduler analyzes the requests in the database, and selects when and on which NQS server the request will run.
The NQE scheduler and database components are shown in Figure B-4.
The database server system task serves connections from clients (either locally or in the network) to access data in the database.
The monitor system task monitors the state of the databases and which system tasks are connected.
The scheduler system task analyzes data in the database and makes scheduling decisions.
The lightweight server (LWS) system task obtains request information from the database, checks authorization files locally, submits request to NQS, and obtains their exit status.
