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.
---------------
This question actually leads back to things we’ve talked about quite a while ago about grouping servers together. Technically, of course, you don’t need any Angels at all to use Liberty on z/OS. But it is very likely that you’re going to want to exploit some of the Liberty features that require an Angel to help the server get authorized. And, as we discussed last week, the original design was for each z/OS image to have a single Angel. But that didn’t work out very well. And that exact problem leads us to an answer to today’s question.
The problem was that to put maintenance on an Angel you needed to shut down all the servers that were using it. If you’ve just got one Angel per system then all the Liberty servers on that system that need an Angel have to be shut down. And the problem with that is not all the servers might be managed by the same people. If you have z/OS Connect servers and Liberty-in-CICS servers and a z/OSMF server and some other servers, all managed by different groups, which one is in charge of the one Angel and remembers to tell everybody before they shut it down? And, can you really keep all those servers on the same code level as that one Angel? Probably not.
So it comes down to two things. The first is server ownership. The people responsible for maintaining a group of servers should be responsible for the Angel they use. This makes z/OSMF easy. There’s just one of those per system (at most) and it will have its own Angel. If all the z/OS Connect servers are managed by the same group, you could group them together under a single Angel. But that might not be granular enough, depending on how they are used. Likewise Liberty-in-CICS servers or just regular Liberty servers used by your own applications. These could be grouped together under a single Angel, but you might want to break that up a bit.
The second factor is that the Angel and the servers using it have to be at the same code level (it didn’t use to be that way, but that’s the rule now). So that means that as you group servers together under an Angel you need to understand that you’ll be putting maintenance on all of those servers at the same time. If you have some strategy where you roll out maintenance updates across servers on the same system, you’ll want the groups to be under different Angels.
Ok, maybe there are three factors. The third one is availability. As you put on maintenance, all the servers sharing an Angel will be down at the same time. That’s could easily enter into your decision about how to group servers under the same or different Angels.
One thing you don’t have to worry about (finally!) is availability in the sense that if the Angel crashes it will take all the servers using it down with it. The Angel doesn’t actually do anything once it is initialized so there’s no code running to abend and take it down. That, of course, doesn’t protect you from somebody accidentally cancelling it. If that sort of thing is a concern, then maybe you do need to consider the scope of the impact if it happens.
All of this might lead you to think about having a whole lot of Angels to get lots of separation. That’s fine, but be aware that every Angel is using some common storage and if you get carried away it will add up. That storage does persist and gets reused by the Angel across restarts so taking down ‘unused’ Angels won’t free it up until an IPL. It isn’t a lot of common storage, but if you’re thinking about starting several hundred Angels…probably reconsider.