Octopus Administrator's Guide
Configuring Octopus for Multi-Server Operation

 

xPrevious Topic:
Running Remote OctoEng’s with Octopus Agent
Chapter Index
Next Topic:
Node Configuration

 

Octopus Configuration


When used with a multi-server system, the Octopus instance is configured in the same way as for single-server operation (as described in the previous chapter, Configuring a Single-Server Octopus System), with the addition of one required parameter to the OCTOPUS section of the nucleus.ini file:

Nodes=

A list of the node names representing the remote computers on which database server engines (OctoEng’s) will be running, separated by commas. Each remote Node must have its own section, as described below.

The node name can be the host name of the remote computer; when this is the case, the Host parameter does not have to be set in the NODE section.

The master Octopus host can be explicitly represented by the value localnode. For more details, see below.


Note:
When configuring Octopus for multi-server operation in a Windows environment, all DatabasePath values should be specified using the UNC style (\\server-name\folder-name).

When Octopus is running across multiple nodes, commands are first sent to the heaviest non-updatable Class defined on the last Node in the nucleus.ini file Nodes list. If all OctoEng's in this Subclass are busy, the command is sent to the heaviest class on the second-to-last node in the list, and if these OctoEng's are also busy, rescheduling proceeds up the list of Nodes until all the OctoEng's in the heaviest class have been attempted. At this point, the query is sent to the next heaviest class on the last Node in the list, and if these OctoEng's are busy it is rescheduled up the list of Nodes in a similar way.

For example, assume that there is an Octopus instance defined with two Classes of execution and two remote Nodes, as illustrated by the following nucleus.ini file entry:

[OCTOPUS Sample]
...
Classes=light,heavy
Nodes=host1,host2

The master Octopus host is implicitly the first Node definition. As of release 4.2, the master Octopus host can also be explicitly represented by including the value localnode in the list (see below).

When a query is sent to the Octopus instance, it will be rescheduled in the following way (assuming that all OctoEng's are busy):

  1. [SUBCLASS host2 heavy]
  2. [SUBCLASS host1 heavy]
  3. [SUBCLASS heavy] (on the local host)

    then:

  4. [SUBCLASS host2 light]
  5. [SUBCLASS host1 light]
  6. [SUBCLASS light] (on the local host)

As of release 4.2, when there are entries for the NODES parameter, the value localnode can be included anywhere to change the position of the main Octopus host in the "hierarchy"; for example, it can be placed last in the list in order to have commands sent first to the main Octopus server:

[OCTOPUS Sample]
...
Classes=light,heavy
Nodes=host1,host2,localnode

In this example, commands would be initially sent to the HEAVY class on the main Octopus host.

The following optional parameter may also be included in the OCTOPUS section:

BindToAdaptors=

Specifies the network ID name or IP address corresponding to the IP on the main Octopus server to which Octopus-Agent (and Octopus-client) communications will be bound. If the machine identified by the network name has multiple network interfaces (IP Addresses) the server/agent process will be bound to all IP addresses. Alternatively, if a single IP address is specified, the server/agent process will be bound only to that IP address. Multiple IP addresses can be specified, in which case they must be separated by commas.

Default: current host-name

 

 

Previous Topic:
Running Remote OctoEng’s with Octopus Agent
Chapter Index
Next Topic:
Node Configuration