Why do I have all of these OBS Out of Sync Objects?
Customers running continuous sync checks using the STRCNSC command may notice a large number of out of sync objects showing up on the monitor with a reason code of OBS. What does this mean and how do you get rid of them?
OBS out of sync objects are obsolete objects, objects that exist on the backup node but not on the primary node. This should normally not be of a concern as it means you have more objects on the backup than on the primary, so if you switch you at least know that everything you have on the primary is on the backup plus more! But of course it also means your two systems are not identical.
What sync checks catch these objects? Well obsolete objects are the results of the *CHKOBSLETE sync check parameter that was introduced in iCluster 7.1 TR1. This parameter is available on the DMSTRSC and STRHASC commands as an explicit sync check type BUT is also included in a *FULL sync check type when run from the DMSTRSC, STRHASC or STRCNSC (Continuous sync check) commands. *FILEATTR or *OBJATTR sync check types do NOT include *CHKOBSLETE nor does a *FULL sync check run as a user specified sync check using the STRHASCUSR command. Most customers who are running continuous sync check are running *FULL thus they are automatically checking for obsolete objects.
Why do they occur? It depends on the delay between objects specified on the cluster wide system values, at the group level, or on the STRCNSC command (the default is 200 ms.).
Let’s assume you have a very small system or group with 10 objects on the primary. The continuous sync check job creates a list of those 10 objects on the primary and sends the list to the backup, it then sends the first object name and its attributes to the backup node for a sync check, waits 200 ms, then does the same thing for object 2, waits again, does it for object 3 etc. If during these delays, new objects are created on the primary, they are immediately replicated to the backup, but since they weren’t in the original list of 10 objects, they exist on the backup but not on the primary which means they are marked as OBS. But the next time the continuous sync check runs, these new objects will be on the list and the OBS will be cleared.
[box type=”note” border=”full”]Stay current with iCluster with this weekly webinar![/box]
So you can see that if you have a large number of objects being sync checked and a large delay between objects, it may take many hours for the sync check to run and during this time you may see lots of OBS objects. The next time the sync check is run they will be cleared, but of course others may appear depending on how active your system is and how large a delay.
How do you get rid of them? Well you can reduce the delay between objects, which reduces the exposure and shortens the time it takes to run a complete continuous sync check, but it may increase CPU utilization. You may also want to think about do you really care about obsolete objects? The only time most customers see them and care about them is during initial synchronization when they have saved and restored an entire library but are only replicating a subset of the library, or just before a switchover. In the later case you can run a scheduled sync check instead. A final option is to use *FILEATTR or *OBJATTR as the type of sync check on the continuous sync check command.
In future releases the Obsolete objects will be cleared up automatically by iCluster. You can also contact the author of this blog by commenting on this entry and requesting the ICFIXOBS tool. More about this tool will be provided in the next post.