On This Page:

Upgrading the server without stopping ServiceOptimizer
Replacing a failed host
Other maintenance

With limited exceptions noted below, ServiceOptimizer does not support the ability to make changes to the system configuration whilst the system is running, and there is no checking done by the system to verify that the configuration tables are not being changed.

Upgrading the server without stopping ServiceOptimizer

For Bugfix releases only, it is possible to do a staged upgrade of the software on the slave installations of a ServiceOptimizer instance, provided that some or all of the slaves run on different SPHOMEs. This means that during the upgrade some SPHOME locations within a ServiceOptimizer instance will have been upgraded while others have not.

However, once you come to upgrade the SPHOME on which the master installation for the instance is running, the whole ServiceOptimizer instance (the master and all slave installations) must be stopped and all system monitors closed down. This is so reagardless of whether the SPHOME for the master installation also runs some slaves or whether the master SPHOME is dedicated to the master installation.

Instructions for Upgrading server slave installations without stopping ServiceOptimizer

To do this:

Identify those host(s) that are running components from the SPHOME location to be upgraded and verify that none of these are running the master installation (see above)
Stop ServiceOptimizer on these host(s) (by stopping the service or running the stop script). This will stop slave system monitor and the components that are running on the host(s).
Upgrade the software at the SPHOME location.
Start ServiceOptimizer on these host(s) (by starting the service or running the startup script).

Replacing a failed host

If a host machine fails then a preconfigured replacement can be installed:

Instructions for replacing a failed Host

The replacement host must have been set up with ServiceOptimizer installed and configured in the same way as the failed host.
The replacement host is configured to have the same IP address (and optionally host name) as the failed host. (Note that if the replacement host is only configured to have the same host name, then because of the way DNS changes are propagated throughout a network there may be a substantial delay before the rest of the network recognises it.)
The slave system monitor is started on the replacement host (by starting the service or running the start script).
The ServiceOptimizer instance will detect that the host is available “again” and use it as required.

Other maintenance

All other maintenance of the ServiceOptimizer system requires the instance to be stopped:

Maintenance activities include:

All database upgrades require the ServiceOptimizer instance to be stopped. The database can then be upgraded.
The introduction of a new travel matrix always requires a ServiceScheduling database upgrade (because of the introduction of new geography for example) and so a staged upgrade of travel matrices is never possible. While the ServiceOptimizer instance is stopped, the new travel matrix files must be installed in all the SPHOME locations.
A new host may be added to ServiceOptimizer instance while the instance is stopped in order to support the introduction of new FRUs or new hardware. This requires an update to the database following similar steps to the example in Example Configurations.

Instructions for General Maintenance

The ServiceOptimizer instance must be stopped by stopping the master system monitor (by stopping the service or running the stop script on the master system monitor’s host).
The Slave System Monitors on all the hosts must be similarly stopped.
The required upgrade or maintenance activity is then carried out
The Slave System Monitors on all the hosts can then be restarted.
The ServiceOptimizer instance can then be restarted by starting the master system monitor (by starting the service or running the start script on the master system monitor’s host).

Browser not supported