Cluster Configuration sets up OptimiDoc across several servers for high availability and load distribution. On this tab each node declares the shared address clients use to reach the cluster and the local name it advertises for itself; the heavier lifting — node roles, the master node, encryption key exchange and queue distribution — happens automatically once the nodes can see each other and the shared database.
Screenshot: Cluster Configuration settings
Overview
Where print volumes or availability requirements are high, OptimiDoc can run on multiple servers in a cluster. All nodes share one SQL Server database and the same job spooler, and each can process print, copy and scan jobs, giving redundancy and load balancing. A cluster contains two kinds of node:
-
Server nodes — full OptimiDoc servers that run the web interface, talk to devices and process jobs.
-
Printing nodes — lightweight OptimiDoc Printing Node (OPN) installs that receive and release print jobs at remote sites but do not run the full server.
Exactly one Server node is the master. The first active Server node claims the role at startup; there is never more than one, and a printing node can never be master. The master owns cluster-wide coordination such as issuing the encryption key to new nodes. You can move the role explicitly from the Cluster Nodes diagnostics page.
Accessing Cluster Configuration
-
Open the React administration interface as an Admin user.
-
Go to Settings in the left sidebar (route
/config). -
Select the Cluster tab. Saving writes the three values below (
api/v3/config/cluster).
Configuration Settings
|
Setting |
Description |
|---|---|
|
Shared IP/DNS |
The virtual IP or DNS name external clients use to reach the cluster (e.g. |
|
Local DNS |
The name this node advertises for itself. OptimiDoc substitutes it into the URLs it hands out — the print client download address, scan-delivery callbacks and email links — so clients contact the right node directly. Each node has its own distinct value. |
|
Strict security mode |
A Xerox-specific workaround, not a general cluster security switch. It changes how the Xerox terminal application binds (a single shared binding versus a per-device IP binding) to resolve SSL-certificate issues on some Xerox fleets. Leave it off unless Xerox support advises otherwise; it has no effect on non-Xerox devices or on inter-node traffic. |
Earlier documentation described "Strict Security" as hardened inter-node communication. That is incorrect — it is solely the Xerox terminal icon/binding workaround described above.
Setting Up a Cluster
Prerequisites
-
Shared database — every node connects to the same SQL Server database (set the connection string in each node's
web.config). -
Shared spooler — enable Use shared spooler in Print Settings and point all nodes at the same network share.
-
Connectivity — nodes must reach each other, the database and the shared storage.
-
Load balancer — distribute client traffic across nodes via the Shared IP/DNS address.
Configuration Steps
-
On each node, open Settings > Cluster.
-
Enter the Shared IP/DNS — identical on all nodes.
-
Enter the Local DNS — unique per node.
-
Leave Strict security mode off unless you run Xerox devices that need it.
-
Click Save and restart the OptimiDoc service on the node.
How a New Node Joins
OptimiDoc encrypts sensitive configuration with a master encryption key (MEK). A freshly installed node has no key, so the first time an administrator logs in on it and encryption is not yet initialised, the node asks the master to authenticate on its behalf and then requests the key over a secured bootstrap exchange. The master only answers requests coming from an IP that already appears as an active node in the cluster; unknown callers are rejected. Once the node has the key it can read shared configuration and participate fully.
What Is Shared and What Is Local
All nodes share the OptimiDoc database, the spooler directory and the configuration stored in the database. Node-specific items are the Local DNS identity, each node's own system logs and its temporary processing files.
IPP queue distribution. Named IPP (driverless print) queues are synchronised automatically. Server nodes pull each other's queue configuration at start-up and whenever a change is broadcast; printing nodes pull on their regular heartbeat (roughly every five minutes). A per-node timestamp gates the transfer so a node only applies changes newer than what it already has, and the marker only advances once every queue has been applied.
Monitoring Cluster Health
Use the Cluster Nodes diagnostics page to see every node's role, online/offline state and last activity, and to promote a different Server node to master. For the design behind failover, see Failover Architecture.
Tips
-
Prefer a DNS name over a raw IP for Shared IP/DNS so infrastructure changes don't force a reconfiguration.
-
Test failover by stopping the service on one node and confirming the others keep processing jobs.
-
Keep Local DNS resolvable from clients — it is the address they are told to use for direct callbacks.
Related articles