Replicate save status and last save information across nodes in PowerHa Cluster.

In a PowerHA cluster, if I perform a save operation (to a tape drive) in a FlashCopy system that information is not spread among other systems in cluster specially production (main) system.

This cause some objects that must be saved before delete cannot be saved in another system different than its own system, for example, Journals Receivers.

It would be interesting if the "Save date/time" attribute and others related attributes of the object where replicated and/or distributed when the object is saved on a flashcopy node within the same cluster.

Use Case #1.

In a PowerHA cluster we use one of the Flashcopy systems to perform tape backups. Some elements that reside in iASP, such as journal receivers, must be properly saved before being removed from production.

When these objects are saved on our flashcopy system there is nothing in production to indicate that they have already been saved. This can be omitted with DLTJRNRCV DLTOPT(*IGNINQMSG), however it is not certain that they were saved completely. This forces having to save these elements directly in production to ensure that they have been properly backed up before they are eliminated.

Use Case #2.

We have store procedures that delete some "temporary" files in production every week, these files reside in libraries which are in iASP and are saved in FlashCopy. It would be very helpful if some system views like QSYS2.OBJECT_STATISTICS included some information that the item was saved on another node in the same cluster.

Idea priority

Medium

Post comment

Guest

Reply
| Nov 8, 2022

We appreciate the feedback on this idea. After consideration, the PowerHA team does not intend to provide a solution to this request at this time, so it is being closed. A FlashCopy represents a point-in-time copy of your data. As soon as that FlashCopy is taken, the data between the FlashCopy
and the original production copy diverges. In most cases, this is because the production copy continues making further changes. Depending on the type of FlashCopy, as the
FlashCopy comes online, any in-flight transactions may be rolled back as part of the vary on process; meaning the production copy shows the transaction happened, and the FlashCopy does not. In addition, additional user-initiated changes can occur on the FlashCopy from this point in time. In the example of use case #1, it is true that the journal receivers are likely not identical between the systems.

IBM i 7.5 did introduce new functionality in this area called ragged flash: https://www.ibm.com/support/pages/node/6579149
This functionality prevents the rollback behavior that occurs during vary on or IPL and enables you to take the receivers from the production copy and apply them to the FlashCopy version at a later point in time if desired. Using ragged FlashCopy would prevent the roll-back upon vary on, but there would still likely be differences between the objects on the system (assuming production continues changing data). Therefore, a save of an object on a Flashcopy, while it may save pretty close to the same object, is not identical to the object on the production copy. For this reason, the save information is not propagated, as we do not want to imply something is saved when in fact, there may be differences that were not saved.

For use case #2, the operating system's remote table functionality may achieve the functionality you are looking for by running table functions on remote IBM i systems. This might allow you to build a query that pulls the information from multiple systems in your environment, provided they are all up at the time. See https://www.ibm.com/support/pages/node/6828079 for additional information.

0 reply Hide replies

2 MERGED