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 is really just another aspect of the whole ‘where do I put everything’ discussion. You’re going to have an assortment of directory structures and you want to think about which are separate file systems that get independently mounted. You’ll also want to think about whether some are mounted read/write or read/only and perhaps if they are available across the sysplex or just locally within one system.
We’ll talk about maintenance strategies in a few weeks, but you’re probably going to end up with a few different levels of the runtime. Liberty delivers a new maintenance level roughly every four weeks, and, while you certainly won’t have every one, you’re likely to end up with a few different levels floating around. These will probably end up in separately mounted file systems. These might be read only, and could definitely be shared across the sysplex.
We’ve talked a lot about configuration and where the assorted configuration files live. A good starting point is probably to have a file system for ‘group’ of servers. These are servers sharing the same ‘servers’ directory where their configuration lives. You’ve already grouped these together, so keeping them in a separate file system probably makes sense. Since servers generally have a ‘home’ system, these are probably not shared across the sysplex. You’ll want to be able to make configuration changes, so obviously these aren’t mounted read-only. You’ll control access through file permissions (next week’s topic).
We’ve also talked about ‘output’ directories where logs and traces go for each server. You keep it separate from the configuration because a server only needs read access to its configuration, but needs write access to the log directory. You could put all the servers output directories into one file system (like you could, in theory, with the configuration directories), but it might make more sense to keep the same groups of servers whose configurations are in one file system with their output in the same separate file system. Space might be a consideration though, because sometimes logs (and especially traces when you’re working through a problem) can get big.
Output directories probably don’t need to be shared across the sysplex, but you might find it convenient to do so anyway to make it easier to look at logs when you’re having a problem (or for some sort of automated monitoring etc) if they are visible from everywhere. It used to be the case that having a file system mounted read-write to multiple systems in a sysplex was a very bad idea. Performance was horrible if you were writing to it from anywhere other than the ‘owning’ system. But that was corrected many years ago and testing showed no performance impact even when concurrent high volume writes were done to the same file system from multiple members of the sysplex.
What about applications? Should .war files be located in separate file systems or kept together? Should the same .war file (or .ear file) be used across the sysplex or separate for each system? That’s probably more of an organization than a technical issue. I’d be tempted to have separate copies for each system to make rolling updates possible (in case it goes badly) rather than replace everything at once. Separate file systems for applications for different lines of business (or whatever) might make sense. I don’t see a reason for each application to have its own, but your needs may provide a reason.