Cluster multiple censhare servers

Prerequisites

• master server installed

• network connection between the servers for RMI (TCP 1090, 1099, 30543, 30546) and ssh (TCP 22)

• already logged in with the censhare Admin-Client on the master server

Definition

master server - the server near or with the database

remote server - the second, third, ..., server e.g. on another location

censhare Admin Client's "Master Data" is read-only for versions after 5.8.1. To edit master data switch to the Admin mode.

censhare Servers that are connected directly to the database, must have the same time and time zone setup. Ensure that a time synchronization daemon is running.

Master data

• Application servers

  • add new server

    ID=$CSS_ID on OS level

• File systems

  • The assets and assets-temp directories (on OS level) must not be on different physical volumes

  • For versions < 4.7, make sure to configure assets-temp as type=Asset-Temp and temp as type=Other.

Configuration

• Services|Filesystem

  • For each server with its own filesystem: ensure that a separate directory for assets-temp and temp is configured and exists on the OS level.

• Server|General

  • create a new configuration for the new server and adjust the Server name and Master server name

• Server|Launcher

  • duplicate the custom configuration or create a new configuration for the new server and adjust the Server name

Hint: You can configure two kinds of database connections for remote servers.

1. Direct database connection. Recommended if the remote server is in the same LAN as the database.

• Services|Database

  • duplicate the custom configuration or create a new configuration for the new server

2. Indirect database connection via the master server. Recommended if the remote server is not in the same LAN as the database.

• Services|Database

  • add 60 database connections (Connections|Maximal) for each remote server to the master's database configuration

• Services|Database

  • create a new configuration for the new server and deactivate it

• Services|Database Query

  • create a new configuration for the new server and deactivate it

• Services|DataObject

  • create a new configuration for the new server and deactivate it

For cluster/node servers with censhare server >=5.8

• Services|DataObject

  • Increase invocations for the master's data object configuration to 40. Add 10 invocations for each remote server to the master's data object configuration

• Services|Filesystem

  • create a new configuration for the new server

  • find here more details regarding file system configuration on multiple server environments

• Services|Remote-Server

  • create a new configuration for the master server and activate it

  • create a new configuration for the new server and customize the configuration as shown in the screenshot
    

    

• Services|Renderer

  • It's recommended to have 1 Render-Client connected to each server if required.

  • find here more details regarding renderer configuration on multiple server environments

• censhare Server to censhare Server communication
  • For the censhare Server to censhare Server communication, you must set up a public/private key authentication on each server. For more information, see censhare authentication with private/public key.

Configuration|Modules

Hint: Some modules must run only on one server, some must run on every server.

First, we have to check all commands which are running based on a cron-pattern or timer event if it makes sense to have them running on additional servers.

You can find those modules in censhare Admin/State/Events when you look for the target "scheduler:

censhareAdmin | State | Events

Double-click every scheduler event to find out which commands are using that particular scheduler:

Commands which use this scheduler

These modules must run only on one server (master):

Since 2018.1 and higher the following modules will have the "Run only on master server" flag set by default. A manual reconfiguration is no longer required then.

• Administration|Cleanup|Cleanup Database (automatic)

• Administration|Feature as Asset|Create feature asset for each feature (automatic)

• Administration|Feature as Asset|Create feature assets (config)

• Administration|Feature as Asset|Create feature assets by startup

• Administration|Feature as Asset|Update feature asset by feature changes (automatic)

• Administration|Maintenance|Check Database Locks (automatic)

• Administration|Migration|Feature Configuration Automatic Updates

• Administration|Module Assets|Synchronize client module assets

• Administration|Module Assets|Synchronize module assets (automatic)

• Administration|Module Assets|Synchronize module assets (runtime area)

• Asset Deletion|Delete Assets (automatic)

• Asset Deletion|Mark Asset Version for Deletion (automatic)

• Asset Deletion 2|Delete Asset Versions (automatic)

These modules must run on every server:

• Modules|Administration|Embedded database|Embedded database sync using CCNs (automatic)

• Modules|Statistics|collect_timing

Modules that can run on every server, but have to be checked, if you want to run the task on just one server

Hint: All persistent configured modules have to be active on the remote server but have event-count-limit (process limit) set to 0 if you want to avoid load balancing. And must have the identical command-id as the command on the master server. For example:

• Archive

• Asset Files|SwitchFilesystem for actual Versions (automatic)

• Image|Convert image (automatic)

• Image|Create additional Image (automatic)

• Schedule|Update Actual Date of Schedule Asset (automatic)

• Schedule|Update Asset Schedules (automatic)

• Workflow State|Update Worst Workflow State (automatic)

• Configuration|Modules|Asset Deletion|Delete Files (automatic) #Must run on every server with local filesystem at different times to avoid database locks.

Sync censhare from master to the remote server:

As everything is prepared now, sync censhare from the master server to the new remote server.