Updating YSoft SafeQ ORS with cache recovery
In this document
ORS update
About ORS update
To update a version of YSoft SafeQ ORS, use the installORSv2-exe.cmd installation script (the same script you use for the initial installation).
The installer automatically uninstalls YSoft SafeQ ORS and saves the file guid.conf (with the specific GUID of this particular ORS) to disk.
The installer then installs the latest version of YSoft SafeQ ORS to the specified folder, using the same GUID as the previous version.
WARNING
Updating hundreds of ORS servers with Cache Recovery feature enabled
In productions with hundreds of ORS servers, update should not be run "at once". Instead, updates for ORSs should be split into batches containing ~200 ORS.
In case of upgrading 600 ORSs, administrators should run updates for 200 ORS at first, and once update is done, proceed to next 200 ORSs and so on.
This process ensures, that CML will not get overloaded and it will be still able to handle other requests during recovery.
ORS update procedure
This section describes the way how to update ORS server.
1 | Enable Cache Recovery Before you start update, verify the ORS cache recovery settings. Go to System settings and set orsCacheRecovery property to enabled
|
2 | Configuring the safeq-ors.ini file Prepare safeq-ors.ini according to Installing YSoft SafeQ ORS description with following exceptions:
|
3 | Launching the YSoft SafeQ ORS installer
a) To start the installation, run the installORSv2-exe.cmd. or b) To install YSoft SafeQ ORS with a specific safeq.fwupdate.conf file: Copy the file safeq.fwupdate.conf to the folder that contains the YSoft SafeQ ORS installation files and run the installation script with this additional parameter: installORSv2-exe.cmd <safeq.fwupdate.conf> |
4 | Updating of hundreds ORS servers For productions with hundreds of ORSs, and Cache Recovery feature enabled, update should not be run "at once". Instead, updates for ORSs should be split into batches containing ~200 ORS. In case of upgrading 600 ORSs, administrators should run updates for 200 ORS at first, and once update is done, proceed to next 200 ORSs and so on. This process ensures, that CML won't get overloaded and it will be still able to handle other requests during cache recovery. |
5 | Make sure the YSoft SafeQ ORS service is running Once the update of YSoft SafeQ ORS is finished, make sure the YSoft SafeQ ORS service is running: Open Services on the YSoft SafeQ ORS server (Start > Run > services.msc) and check the following services:
|
6 | Post-installation step If scan to home/folder is used, you have to set up once again the account which is used to run the YSoft SafeQ ORS service.It is required to reinstall embedded terminals for Konica Minolta and Sharp after ORS update. |
In case of ORS cache data corruption, cache can be manually deleted and all job-related metadata will be recovered from CML. If this option is enabled, job consolidation will not be run during ORS startup.
NOTE: Verify that the YSoft SafeQ ORS is functional
1 | Open the YSoft SafeQ Web Interface and log in as an user with the right to administer printers (e.g. admin). |
2 | Select Devices > Printers. The group list (on the left) shows the connected YSoft SafeQ ORS server. (A new, additional ORS server should not have been created.) |
3 | Click the ORS icon or ORS server to and verify:
|
Cache Recovery
SafeQ 5 supports recovery of ORS cache after it's deletion. This greatly simplifies upgrade process to newer versions. In case of cache deletion, ORS will trigger cache recovery process during startup, and all job-related data lost due to deletion will be re-downloaded from CML again. This document describes procedure how to use cache recovery (further referenced as "CR") mechanism in production environments.
ORS cache recovery cannot be used to restore data which are unknown to the CML (e.g. statistics which were not yet synchronized to the CML) and job-related data for print jobs with status DELETED..
How to enable cache recovery during upgrade
By default, CR is enabled. CR will be automatically run when upgrading ORS to newer version. This behavior is ensured by property orsCacheRecovery=true in system settings of SafeQ CML interface (this requires deleting of ORS cache after update which is assured by deleteCacheAfterUpdate=1 from file safeq-ors.ini).
By default, both these properties are enabled.
PLEASE NOTE:
Before you choose to upgrade ORS using cache recovery, make sure that CML has property orsCacheRecovery set to true. If you run ORS upgrade without upgrading CML at first, this property might be disabled. This would cause that after the ORS upgrade the cache is deleted, but since CML has orsCacheRecovery=false, CR would not be run. If you encounter such situation, you can proceed with following steps:
stop ORS node services
set property orsCacheRecovery=true on CML web interface (or upgrading whole CML node)
restart CML services
restart ORS node (CR will be re-run)
Cache recovery mechanism overview
CR mechanism is based on message communication between CML and ORS. CR request messages are sent from ORS to CML, where they're processed, and data is returned back
to ORS. Keep in mind, that CR mechanism is based on transmitting ORS's job-related data from CML.
Each ORS running recovery will send multiple messages to CML as CR requests. CML will load data from database and sends them back to ORS as response. Please note, that loading data from database
might be expensive operation. If several ORS nodes are running recovery simultaneously, they might overload CML node. We introduced mechanism for loadbalancing CR
requests on CML, but in case the only one node in the CML cluster is active and hunderds of ORSes are connected, running a CR might still lead to poor performance of CML.
How to run recovery
When performance is concerned, many things must be taken into consideration. One of the most important one is number of jobs being recovered and number of ORSs connected to CML.
In productions with hundreds of ORS per single CML, CR should not be run "at once". Instead, CR for ORSs should be split into batches containing ~200 ORS.
In case of upgrading 600 ORSs, administrators should run CR for 200 ORS at first, and once CR is done, proceed to next 200 ORSs and so on.
This process should ensure, that CML won't get overloaded and it will be still able to handle other requests during recovery.
(You can see whether CR phase is done by monitoring CPU/hdd activity on CML)
Performance aspects to consider
Following aspect directly influence CR performance
Number of jobs per ORS
Number of jobs which are being recovered is important aspect of CR. All job-related metadata (lost during cache deletion, or possibly by upgrade) will be downloaded from CML to ORS.
According to number of jobs, amount of transferred metadata differs in size and might affect overall duration of CR. We also need to take in consideration time and resources needed
for loading metadata from database, which is slowest element in whole CR process.
HW configuration
HW setup is important mainly from DB(hdd/ssd) and CPU speed. Handling several hundreds of CR messages on CML side utilizes CPU, while loading CR metadata from DB utilizes HDD/SSD.
Performance of these elements must be taken into consideration.
Number of ORSs per CML
Number of ORSs connected to CML is related to overall performance of CML during CR. More ORSs requesting recovery will consume more resources on CML side. Sudden onslaught of hundreds
of ORSs on single CML node might overload that node, and it would become unresponsive. This scenario should be avoided as described in section 3) How to run recovery.
Please note, that even that we have load balancing on CML, it would not be able to serve such amount of sudden CR requests, and load would not be balanced out among other nodes.
CML cluster vs single node
In case of running CR in single CML node environment, extra precaution should be taken. CR (or upgrading of ORS nodes) should always be run sequentially, and not at once on all ORS nodes!
Spooler deletion
In case of ORS spooler deletion, all jobs belonging to this ORS will be marked on CML as DELETED. This adds additional overhead to CML node, since it'll need to update database records
for these jobs. This operation might be time consuming and must be taken into account when running CR.
(if spoolers are deleted, number of ORSs in single CR batch should be further decreased)
When to run cache recovery
Since CR consumes high amount of resources, it's not recommended to run CR during high-traffic period. Please note, that ORS needs some time to replicate metadata of received jobs to CML. Only after this step is done, job metadata becomes available for CR. If ORS node is shut down immediately after job is received, it's highly probable, that ORS-generated metadata will not be transmitted to CML, and CR mechanism will remove it from ORS spooler.
Possible problems and consequences
In case of CML getting "frozen" during CR process, it's recommended to wait until it becomes responsive again. If you get into such situation, CML is not able to handle such thrust from ORS
nodes. You need to decrease number of ORSs being recovered/upgraded. YOU ALSO NEED TO DELETE CACHES ON THESE ORS NODES. This will trigger CR process from scratch once you start these nodes.
CR process is safe in context of repetition. At any time during CR process, data are consistent between ORS and CML.