Hi folks,
I hope your holiday plans are going well and are joyful.
So now that iCluster 9.2 is released, I am installing on our internal systems that I can share with you. Below are the steps I am taking to upgrade our systems from 9.1.1 to 9.2. (You can upgrade to 9.2 directly from iCluster 8.2 or higher) Please refer to the install guide for your specific install steps but I thought it might be helpful to see this example upgrade for my environment. I will not repeat all the install instructions that are provided here. This is simply a sample upgrade procedure and you get to look 'over my shoulder' to see what I am up to. Forgive me for switching back and forth between 'I', 'you', and 'we' in my writing. No time for perfect grammar today. Let's go!
Go to the Rocket web site and download the Rocket iCluster 9.2 install images. Then visit the documentation web site and download all the docs you will need for iCluster 9.2. (docs.rocketsoftware.com)
To download the needed components - https://support.rocketsoftware.com - Scroll down on the resulting page and select 'Rocket community'. Use your credentials to sign in or 'sign-up' to access your customer community portal. In the Notifications column, see the release Announcement for Rocket iCluster 9.2.0.
Side note but important:
Check your operating system version and PTF level to make sure the version 9.2 of iCluster is fully supported on the systems. Next are a couple commands/procedures to help. Check these on all systems to run iCluster 9.2.
WRKLICINF - will retrieve the version of the OS license version and the IBM processor group and serial number. Can be helpful when requesting your new 9.2 keys.
DSPPTF LICPGM(*ALL) SELECT(*ALL) RLS(*ALL) COVERONLY(*NO) OUTPUT(*PRINT)
Then 'find' the required PTFs from the Installation guide in the resulting spool output.
Now is a good time to open a support ticket to request your new iCluster 9.2 license keys.
Didn't receive an email from Rocket announcing the new update? See your User name in the upper right corner on the community page and click on the selection arrow. Then select Notifications (the link will open a new tab or window)and subscribe to the notifications you would like to receive.
Use the 'Downloads' link in the header to retrieve the list of available products for you. Select 'Rocket iCluster' and from the resulting list select RIC-6561 Rocket iCluster 9.2.0.
Download all the iCluster 9.2 images to your desired install platform (IBMi for the base iCluster install and 'IBMi or Linux' for the iCluster web binaries).
Here is a screen print of my download folder contents from my download session. (with the exception of one file... did you notice it?)
After I download the needed files, I combined all the ones I will be using in one zip file 'icv92i_full.zip'. I then distribute that file to all my IBM i host nodes using 'WinSCP'. I will not be installing to Linux this time so my zip file does not include the Linux support files.
I then go to my ssh session and extract the files from the zip. My example will use 'putty' for ssh. The command I'm using is 'jar -xvf file.zip' to extract the members from the zip file I created. (You can confirm in advance you have java installed or another command to unzip the zip files. Otherwise it may be necessary in your case to unzip the files on your desktop prior to transferring them to your IBMi host.) Then I'll extract the CSBASE savf from the 'iCluster 9.2.zip'.
Next I'll create the needed savf (in the library environment from my 5250 session) and then copy our CSBASE contents to the new savf.
crtsavf qgpl/icv92
File ICV92 created in library QGPL.
CPY OBJ('/home/ZZZZZ_X/icv92/CSBASE') TOOBJ('/QSYS.LIB/QGPL.LIB/ICV92.FILE') FROMCCSID(*JOBCCSID) TOCCSID(*JOBCCSID) REPLACE(*YES)
Object ICV92 in QGPL type *FILE deleted.
File ICV92 created in library QGPL.
Object auditing value changed for ICV92 in QGPL type *FILE.
Object copied.
I next verified my new savf resulted is a savf format with a DSPSAVF command. Now that the files are on the IBM i system, we can use iCluster to send the files to the other cluster node(s) using the DMSNDOBJ command. (We will have to repeat the previous upload steps to nodes in separate clusters and then distribute within each cluster.)
DMSNDOBJ TGTNODE(DRNODE) OBJ(QGPL/ICV92) OBJTYPE(*FILE)
Save-while-active checkpoint processing for library QGPL complete.
1 objects saved from library QGPL.
DMSNDOBJ TGTNODE(DRNODE) SNDTYPE(*PATH) PATH('/home/ZZZZZ_X/icv92/*')
I verify each savf and binary for the web agents as best I can before ending the active iCluster instances, comparing file sizes and savf access. After these checked out I'm ready to prepare to upgrade iCluster.
The first thing I do (before running my backup and upgrade) is take a quick look in the iCluster library to see the size of history files, reactivation logs and event logs. Here are some sample files I examine and their current size. Not too bad today and the value of the data in these files is questionable following the upgrade. All nodes in the cluster can be reviewed quickly and junk data purged.
DMAREACLOG *FILE PF 68202496
OMEVNTLOGP *FILE PF 11632640
OMFHLOG *FILE PF 352382976
I also check to see if there is any journal usage and a load of receivers in the ICLUSTER library. I recommend purging down to the minimum receiver storage in the ICLUSTER library prior starting the upgrade procedure. My preference is that no replication selections be journaled to a journal in the iCluster library. If there are some located, I make plans to eliminate them and move that activity to a journal consolidated library (outside ICLUSTER).
It's also a good ideal, if you haven't checked lately, to review the system requirements for iCluster v9.2 and insure you will be installing on a system that is a supported operating system and has the required IBM service packs installed.
OK, Lets get started with the upgrade!
Observe that replication is running and with low latency and we are upgrading at a time that system usage/activity is not at highest levels. We can upgrade iCluster even if there are broken replication groups and then resolve those issues with the new code level in place. So, if you have been struggling with a group's reliability, consider you may do well to clean up and upgrade then resolve the issue running the new code base. The system application and users do not need to be interrupted but we also don't want to induce a high amount of latency during the upgrade due to iCluster stoppage. End iCluster replication groups controlled with DMENDGRP *ALL command. End the groups controlled so you can anticipate groups will restart with little fuss.
Visit both the source and target XDMCLUSTER SBS and observe that all group jobs have ended before proceeding (not forcing them down will ensure they ended gracefully and will be important when time to restart). Go to the node that is the Metadata Owner and end all nodes with the Metadata Owner ended LAST. Now that all groups and nodes are ended, end the XDMCLUSTER Subsystem (*IMMED) on both/all nodes that will be upgraded.
Signoff all IBM i sessions that have been using the iCluster menus. (There will be object locks and commit groups open that will cause the backup and upgrade to fail if they are not ended.) Then signon a QSECOFR authority user back on and do not change your current library to ICLUSTER or access any iCluster function until the upgrade is complete. I typically try to perform the upgrade on all nodes at the same time. Each of the command sets must be performed on all nodes in this cluster.
Below are the functions to create a savf, submit a backup, verify it completes and was successful, and finally submit the upgrade (you must accept the agreement so must be run interactively)
> crtsavf qgpl/ic231213
File IC231213 created in library QGPL.
> SBMJOB CMD(SAVLIB LIB(ICLUSTER) DEV(*SAVF) SAVF(QGPL/IC231213) DTACPR(*MEDIUM)) JOB(@@SAVLIB)
Job 032873/MARKW_X/@@SAVLIB submitted to job queue QBATCH in library QGPL.
> dspmsg
> RSTLICPGM LICPGM(4RICLUS) DEV(*SAVF) OUTPUT(*PRINT) SAVF(QGPL/ICV92)
*PGM objects for product 4RICLUS option *BASE release *FIRST restored.
Objects for product 4RICLUS option *BASE release *FIRST restored.
After the upgrade completes on all nodes, sign off each system and back on. You can now begin your verification that the version of iCluster was upgraded on all nodes. DMSYSINF command displays the version of iCluster installed on this node. Run it on all nodes in this cluster.
Visit each node and use command WRKLICINF. Find '4RICLUS' iCluster in the list and 'add' the new 9.2 license key (with option 1). You can update the key/entitlement while iCluster is running if you have already started iCluster.
Now that I am ready to start, I go to the job scheduler and release immediately the job I have prepared to start iCluster. You have many options here as to how you want to restart replication. I manually start the SBS, which actually happens automatically if you visit the iCluster main menu on each system. My scheduled job runs command DMSTRCST with the options I have set for this cluster which starts all nodes and groups.
In my case, all elements, including all replication groups restarted normally with no additional actions required. Tomorrow, I plan to do some additional cleanup that I noticed during this upgrade activity. Keeping the system clean and doing it soon rather than later, is what assures me that my next upgrade will also be without too much additional effort or delay.
In my next post I plan to upgrade the iCluster Web components. See you there!
------------------------------
Mark Watts
Sr. Software Engineer
Rocket Software Inc
Waltham MA US
------------------------------