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

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:

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: