Deploy Connections iFixes in a cluster without downtime

Following the documentation of IBM regarding deploying iFixes on a Connections
environment they state that all of your Connections JVM’s should be stopped
during the upgrade process.

“But I have a cluster why can’t this be done online?”,
” Yeah but the IBM documentation says so.”

There you have your challenge. Not much downtime is caused by deploying a single iFix
but there is some chance on data loss. This because running the update installer with online JVM’s will cause an automatic restart of the EAR when they are being upgraded/modified. A restart of an EAR in a clustered environment is most likely to occur simultaneously and can result in HTTP 500 errors for the end user.

Below the steps that work for me to perform an iFix deployment online. It is not a scenario supported by IBM but it can help in improving the process speed of deploying that little iFix that is so desperately needed by a set of end-users. Maybe giving you some ammunition to cut some corners at the CAB meeting.

In this made up example I need to deploy an iFix for Files ( LO66666 ).

Steps:

  • In order to prevent the updateInstaller of Connections from modifying the second node we need to shutdown the nodeagent for this node. Navigate to the WAS console. In the WAS console go to System Administration -> Node agents.
  • Select the node agent of the second node and press stop.
    Tail the SystemOut.log of the nodeagent to check if the nodeagent indeed is stopped.
  • Now logon to the IHS webserver.
  • Open httpd.conf on the webserver. Locate the plugin-cfg.xml line.
  • Open the plugin-cfg.xml, and save a copy of it with another name
    ( i.e. plugin-cfg-primary2ndnode.xml )

 

  • Within this file locate all the ServerCluster sections. For a medium Connections deployment you should find four sections.This example works with a cluster setup consisting of two nodes. One is marked as primary and one is marked as backup. We want to temporarily redirect all traffic primarily to the second node.To do so replace the server line in the BackupServers section with the one of the PrimaryServers section and vice versa.Note the customized CloneID’s. This helps you to verify on which JVM’s you are working. These CloneID’s are mentioned in the JSESSIONID cookie value. Later more about this.
  • Save the changes.
  • Now navigate back to the httpd.conf. Replace the WebSpherePluginConfig with a line pointing to the modified one.

  • Restart the IHS webserver to make this change effective.
  • Now check with a browser that your new Connections session is really being redirect to the correct node. Press F12 and drill down to a cookie information screen
    for one of the requested URL’s. The last part of the JSESSIONID should mention the CloneID’s of the second server.( The screenshot below shows a session to JVM’s on the primary server: infra_srv1 and apps_srv1. )
  • Now go ahead and run the updateInstaller on the DMGR.
    updateSilent.bat -fix -installDir D:\IBM\Connections -fixDir D:\IBM\Connections\updateInstaller\Fixes -install -fixes LO66666 -wasUserId wasadmin -wasPassword ******* -featureCustomizationBackedUp yes
  • Wait for the installer to finish. To make sure the primary node is fully in sync perform
    a full sync from the WAS console interface.
  • Now stop the AppsCluster_server1 ( hosting the Files application ) on the primary node. Now clear all AppsCluster_server1 temp files under
    app_server_root/profiles/AppSrv01/temp/AppsCluster_server1
    and start the AppsCluster_server1 JVM again.
  • Now back to the IHS webserver and switch back to the httpd.conf. Make the original
    plugin-cfg.xml active again and restart the IHS webserver.
    Verify if the traffic routed to the primary server again.
  • Now to also make this change effective for the secondary node start the nodeagent.
    Make sure that all changes are synced if not entirely sure just perform a full sync to
    this server from within the WAS console.
  • Now perform the same procedure as for the primary node. Stop the AppsCluster_server2 JVM, clean all temp files and start the JVM again.
  • And you’re done.
This entry was posted in ibm connections and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please leave these two fields as-is:

Protected by Invisible Defender. Showed 403 to 801,095 bad guys.