October 19, 2020
High availability and data resiliency are critical topics in the minds of business owners these days, especially in light of the summer’s disasters, both natural and manmade. To that end, in the latest batch of Technology Refreshes, IBM has bolstered the services that provide high availability and data resilience in IBM i, PowerHA, and BRMS.
Backup, Recovery, and Media Services (BRMS) is the licensed product that thousands of IBM i shops use to automate their backups and recoveries. Those backups usually involving tape, which was cited by 48 percent of IBM i shops in the 2020 IBM i Marketplace Survey done by HelpSystems. But IBM i shops increasingly are using other storage mediums, such as virtual tape libraries (27 percent, per the study) and the cloud (11 percent).
BRMS gained several enhancements with IBM i 7.4 TR3 and 7.3 TR9, mostly in the areas of making it easier for users to access information about BRMS processes, and improving the usability of the product.
For starters, the PRTRPTBRM (Print Report using BRM) command has been enhanced. IBM now includes an EXPDATE parameter that allows reporting of active control group data. Specifically, users can use it to show if encryption was used during the backup of any control group, according to IBM.
There should be fewer locks on network-related files when users are performing a reorganization of the BRMS database, thanks to a change IBM made with a sync job. And when backing up IFS data, users will be able to add a checkpoint without locking the file, thanks to additional values that IBM added to the *LNK Backup Control Group Entries on the Save While Active attribute.
IBM changed the BRMS Recovery Report to streamline recovery steps. IBM will also stop returning an error when trying to back up an output queue that’s empty.
We have told you about the proliferation of SQL services on the platform, which IBM has taken to calling IBM i services. In the latest batch, there are some services that are the equivalent of the WRKMEDBRM (Work with Media Using BRM) command.
Users can now customize how they see objects returned using the WRKOBJBRM (Work with Saved Objects using BRM) command. There’s a new START parameter that lets the user set which entries are shown first.
IBM also committed to enhancing PowerHA SystemMirror for i with the latest TRs. These new functions should become available December 18, the company says.
Setting up a PowerHA cluster should be easier, according to IBM, which says it has “greatly reduced the complexity and number of commands” that are required to deploy PowerHA environments. It achieved this simplicity the old-fashioned way: by providing default settings for common cluster configurations (although customers are free to tweak the settings as needed).
Speaking of tweaking things, IBM is now letting customers specify the port numbers used for Geographic Mirroring, which is the IP-based replication protocol used to replicate the contents of one independent auxiliary storage pool (iASP) to one or more other iASPs over long distances (as opposed to short distances, where Metro Mirror and it’s peer to peer remote copy [PPRC] protocol is used to replicate data located in storage area networks).
Previously, IBM would randomly select a port for geographic mirroring. But that could cause problems when customers were using WAN quality of service (QoS) and optimization solutions to boost their network throughput, as well as security tools. Now customers can specicy a port number in the WKRSRVTBLE (Work with Service Table Entries) command.
Once the cluster is up and running, it must be managed, and lo and behold, there are some goodies in the upcoming release of PowerHA for the management folks, too.
For starters, IBM says it’s providing contextual F4 prompt options for simplified commands. It’s also providing new dashboards that “provide an at-a-glance overview of the health of one or more PowerHA clusters.”
Finally, IBM is providing detailed recovery point objective (RPO) information for customers using Geographic Mirroring. This information will tell customers how much work they could potentially lose if the systems were to go down at that moment. The RPO information works for both synchronous and asynchronous configurations, IBM notes. (The RPO data loss figure should be less with synchronous replication, of course, but it won’t be zero; that’s why IBM rolled out Db2 Mirror.)
IBM made several iASP and clustering enhancements outside of the PowerHA product, too. For starters, any time the global status of a monitored resource entry (MRE) becomes inconsistent, the operating system will now automatically write an entry to a log file in the IFS of the server in the administrative domain. Previously, the administrator sometimes would not become aware of the inconsistency immediately, which could impact availability. This new log entry feature, which appears to be only available to IBM i 7.4, will help the administrator stay on top of those situations.
IBM also added a new “retry cluster node activation” feature after an IPL. Some admins are currently running into a problem when they try to start a cluster node in their startup program after an IPL, but before the IP addresses specified for the cluster node are fully activated. Instead of requiring the admin to try to restart the cluster node, the operating system will now automatically retry to start the cluster node after waiting a period of time. This feature will be available in both IBM i 7.3 and 7.4.
There has been a timing window when system administrators try to start a cluster node in their start-up program after an IPL, but the IP addresses specified for the cluster node are not yet fully activated. This situation will cause the cluster node to fail to start. The system administrator will be required to attempt the start of the cluster node again at a later time. An enhancement has been made to allow an automatic retry to start the cluster node after waiting for a period of time for the IP addresses to become fully active so that the start will be successful.
IBM has also added a feature to reconcile conflicts in IFS naming. IBM explains:
“Prior to this technology refresh, if there was an IFS directory in SYSBAS and there was a vary on of an IASP whose name was the same as that IFS directory, the result was that the vary on of the IASP would complete successfully, but the IFS directory in the IASP was not visible or accessible to anyone,” IBM says in its IPL. “The recommended work-around (vary off the IASP, delete, or rename the existing IFS directory in SYSBAS, and vary on the IASP again) could take a lot of time, and the user may not have been aware of the recommended action to take to correct the situation.”
The solution is to automatically detects the presence of an IFS directory in SYSBAS with the same name as the IASP during the IASP vary on process. IBM says the administrator is notified about the situation through an inquiry message so that appropriate action can be taken, such as renaming, moving, or deleting the existing IFS directory in SYSBAS, or forcing a mount of the IFS directory in the IASP over the IFS directory in SYSBAS.