Fail-safe operation

IT security is an increasingly important topic, also in the field of document management such as printing, copying or scanning. Kyocera Control can contribute greatly to document security - but it is also important for Kyocera Control to run securely. Consequently, not only the installation of Kyocera Control must be designed to be fail-safe, but also areas that work together with the installation of Kyocera Control.

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 Kyocera Control 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 Kyocera Control cluster, you need at least three cluster nodes (i.e. servers), see Cluster Installation.

Workflow files are stored by the Kyocera Control 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 Kyocera Control services to access the workflow files very quickly.
  • Kyocera Control 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 Kyocera Control).
  • A network drive is independent of the Kyocera Control cluster servers.
  • Kyocera Control 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 Kyocera Control).
  • Typically, shared storage has comprehensive mechanisms for replication and the high availability of files.
  • Kyocera Control components and devices always access the workflow directory via the network.

The printer queue is an important part of the printing system outside of Kyocera Control. 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 Kyocera Control 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 Kyocera Control cluster with 3 cluster servers. All services are available on each cluster server, RabbitMQ and MongoDB were connected to form a cluster. The Kyocera Control 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.

When scanning, the device first places the scan file in the Workflow Files folder (via SMB or FTP). The notification additionally set in RabbitMQ can be processed by any ImageService (and, depending on the scan process, by other services).