Rocket iCluster

ROCKETEER Linda Dan posted 08-05-2021 22:54

Hi Romeo,

If you are implementing for a new iCluster environment, you may consider to exclude application work file during your configuration plan:

1. Discuss with customer to identify those files which is created at begin of a process, deleted at end  of a process, and such process always re-start from beginning during any kind of outage. 
2. When iCluster find a new work file, it will need to register it, change the object auditing, turn on journaling,  refresh it to backup node, all those operation will affect application to allocate the work file. 
3. If application allocate the work file before iCluster, then the object will fail at iCluster new object register. End up iCluster even report *UNKNOWN journal cos application has deleted work file at end of processing.
4. Unnecessary to replication work file also will impact to your performance since you waste resource on work file replication.

------------------------------
Linda Dan
Senior Sales Engineer, APAC
Rocket Software
------------------------------

   

Zq L L posted 08-10-2021 09:29

Wanted to add on the following, Is this object updated frequently ?
Do you need real time  replication for this object?
Maybe you can consider changing the delay for object processing from 0 to a higher value.

Has this object reached sync point before?

ROCKETEER Mark Watts posted 08-10-2021 11:39

Hi Romeo,

The times anticipated where iCluster would need to refer to the object instead of the journal changes only are new object creation or significant object change.  This happens particularly for temporary objects but depending on the characteristic of the application other objects might also be involved.  Especially when the application desires an exclusive lock on an object recently created for access, renaming or even deletion.   

A feature in iCluster, available at the global level or can be adjusted at the group level, is  'Delay for object processing'.  The default value is '0' (zero) and is the number of seconds iCluster should wait before attempting to replicate an object change.  You can find this value under the iCluster System values on the first page near the middle of the list.  You can also find the value in the DMCHGGRP dialog on the 4th page.  Usually 3 seconds is long enough to allow the application to aquire it's allocation and not be interrupted by iCluster.  Even if the application still has its exclusive lock when iCluster attempts to replicate the object, iCluster will retry and eventually suspend the object if it doesn't come available during retries.  Following that, every 10 minutes iCluster would come back and check the availability of the object again to handle the situation without any intervention required. 

The delay value can be set quite high if necessary.  I think in most cases 10 seconds is ample amount and should allow the application free access to the object long enough even though iCluster access is anticipated to be brief.  The max value allowed is 1800 seconds.   There is more detail in the online HELP.

Another alternative to delay (if in fact you identify the problem as temporary objects) is to add a generic exclusion to prevent the temporary object from being selected for replication. 

Both approaches can be considered for your particular situation.  Remember that since the global value is also overridden at the group level, the group should be restarted to adopt the new characteristic for 'Delay for object processing'.