Fail-safe operation
IT security is an increasingly important topic, also in the field of document management such as printing, copying or scanning. IQ4docs can contribute greatly to document security - but it is also important for IQ4docs to run securely. Consequently, not only the installation of IQ4docs must be designed to be fail-safe, but also areas that work together with the installation of IQ4docs.
In terms of fail-safe operation, there are areas that can be protected against failure with varying degrees of complexity. In the following, the advantages and disadvantages associated with different methods will be shown.
Since the mechanisms described in the following are by and large not part of IQ4docs or the underlying the infrastructure of the installation environment, support can only be provided to a limited extent, depending on the design employed for fail-safe operation.

To create a fail-safe IQ4docs cluster, you need at least three cluster nodes (i.e. servers), see Cluster Installation.

Workflow files are stored by the IQ4docs system in a directory that must be accessible from the servers and also from the devices via share, see also Storage locations.

- Locally stored data allows IQ4docs services to access the workflow files very quickly.
- IQ4docs services themselves do not require network access to the workflow directory.
- If the server with the local data fails, the other servers no longer have access to the files.
- Using replication, the workflow data can be kept the same on all servers (replication is not part of IQ4docs).

- A network drive is independent of the IQ4docs cluster servers.
- IQ4docs components and devices always access the workflow directory via the network.
- A normal network drive normally does not have high availability.

- Fail-safe shared storage must be available in the company (not part of IQ4docs).
- Typically, shared storage has comprehensive mechanisms for replication and the high availability of files.
- IQ4docs components and devices always access the workflow directory via the network.

The printer queue is an important part of the printing system outside of IQ4docs. The printer queue can be designed with a higher or lower fail-safe capability.

- Printer queues are completely independent of a print server, since drivers and spoolers are installed locally.
- There is no central print server that could fail; the failure of a local spooler only affects one PC/user.
- It makes sense to use automatic software distribution to install or update the printer queues locally.

- Spoolers and drivers do not need to be installed on all workstations.
- Each IQ4docs cluster node can be a print server - if one cluster node fails, another queue can be used manually.
- The print server can be made fail-safe using various methods:
- Windows Failover Cluster
- Fault Tolerance Installation (VMware)

Regardless of whether printer queues are installed locally or on a server, a printer pool can be created that sends the jobs to different addresses (for example, different cluster nodes).

The following schematic representation shows a IQ4docs cluster with 3 cluster servers. All services are available on each cluster server, RabbitMQ and MongoDB were connected to form a cluster. The IQ4docs services do not know each other and still only process messages from the RabbitMQ queue. This results in a distribution to all existing services.

In the figure, the printer queue was provided by a fail-safe print server. For each server (Server 1, Server 2, Server 3), a printer port was created and these were grouped to form a printer pool. In this way, the print jobs are distributed to the PrintServices. The transmission takes place with the protocol that you have selected for the print transmission (Raw, LPR or IPP), see Printer Driver Installation.
Each PrintService stores the print jobs in the share workflow files in a shared storage.