This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
The real expert here is Jeff Mierzejewski. You should search for him and “WebSphere” to find some of the great things he’s written/presented on this subject.
I’m going to suggest that you look closely at the portable install option for WebSphere. Essentially you end up with a zip (well, really a .pax file) of whatever level you’re after. You unzip (unpax) that and end up with a copy of the runtime that you can move around as you need. It comes complete with the Installation Manager files required to install any interim fixes (iFixes) you might need on that level.
The servers themselves should access their runtime through a symbolic link. The servers ‘installation directory’ will be defined to this symlink. You might want to have a separate symlink for each ‘group’ of servers. The symlink will point to whatever level of the runtime you want those servers using. When you want to move them to a new level, you’ll get the portable install, unzip it in a new location, and (with the servers down please) change the symlink to point to the new level.
This will move all the servers using that symlink to the new level. That’s why you might want to have more than one symlink. You can switch the symlinks in whatever fashion you need to roll out use of a new level.
Since each level has its own IM information, you can put on fixes to that level if you have to. You might want to take a copy of the level being used by the servers and install the fix on the copy. Then you could switch the symlinks to the fixed version. That will be faster than taking the servers down while you apply the iFix. It also gives you a fast and easy way back if something goes wrong.
As we’d mentioned before, once created, the instances of the runtime should probably be in separate file systems that get mounted read-only.
To help keep things organized you’re probably going to want to have a single directory where all the various levels are anchored, and a naming convention you can easily understand to know which one is which. The symlinks will be in a separate directory and have a naming convention that allows you to tell which group of servers is using each one so you are sure you’re switching the right one when doing an update.
Having the symlinks located in one place will also make it easier to quickly look them over and see which levels are actually being used. At some point those older levels can be removed, but you want to be sure nobody is lagging behind. Say, there’s an idea…you could, if your runtime directory naming convention is done in a way that allows this to work, write a script that would list where all the symlinks are pointed and (with some careful use of ‘grep’ maybe?) report if any group of servers is lagging too far behind.