More Cooks, More Recipes
If you ask 200 experienced Linux system administrators how the storage of a Linux host should be allocated, you'll get at least 256 different responses. In the SLES for SAP environment I was tasked to create, my solution was based on both my experience, and the requirements of the environment. Other readers may have other solutions; I encourage a free exchange of ideas on the topic.
Doing The Math
SLES v15 had only been out for a few months when I started building test systems. After some experiments, I determined I could install a base OS configuration, including SWAP space, in about 33GB; as one might expect, SLES for SAP didn’t require significantly more than simple SLES.
Knowing the likelihood there would be a future need to adjust storage allocations and perhaps even add filesystems (for applications not in the original plan), I decided to round up to 50GB as the minimum storage allocation for a SLES host. That would leave 17GB for adjustments after deployment.
One of the storage engineers said "How about 100GB?"
I thought about it awhile - after all, in the new environment, everything is thin-provisioned, so in that sense, 50GB or 100GB made no difference. But at the same time, even a thin-provisioned allocation is an allocation; at some point, the SAN might be called upon to actually provide that storage.
Borrowing a term from the financial world, if I multiply that "unfunded liability" of 50GB by 200 (or more systems), that's potentially another 5TB of storage. When one has nearly a petabyte, a mere 5TB doesn't sound like much; however, there are also other potential expansion needs. More HANA databases might be added to the environment; the planned databases might grow larger or faster than expected; more SAP systems might be merged in. After some consideration, I decided that there was no real need to double my planned requirements.
Of course, the “elephant in the room” is the /boot filesystem; but there’s no easy way to expand that in the PowerPC LPAR world. No matter what number I selected, there would always be some scenario where it might be insufficient. There are only so many variables one can consider before reaching a point where a decision must be made.
Making Bacon
As I described in Background for Understanding the Environment, I'd already taken care of allocating /boot. For the rest, my goal was that following the initial install, no filesystem would have a utilization of 40% or more. I made my allocations like this:
Mount-point Size (GB) / 3 /home 4 /usr 8 /var 4 SWAP 4 /opt 1 /tmp 8
The SLES installer prefers that you make /usr part of the root filesystem, and there are some reasons to do so. I don't argue the basic validity of those reasons, but I note they pre-date LVM. In my view, since (for VMware) the storage for all the allocations above reside in an LVM Volume Group, if the VG is not accessible, then ALL of those filesystems will be unavailable, not just /usr. In such a situation, it's unlikely that recovery would be aided by making /usr part of the root filesystem.
There are a number of other considerations that impacted my design. For example, in the LPAR environment, the IBM Power Tools (equivalent of VMware Tools) install under /opt, and I want to ensure the storage utilization doesn't exceed a set amount.
The SAP Architect assured me that the application environment would benefit from the larger 8GB allocation to /tmp (I'd originally planned to give it 4GB). I learned SAP install processes often rely on unpacking large tarballs (SAR files). As a Linux admin, I keep hoping that SAP will learn about RPMs.
The relatively small SWAP may seem odd - in most database environments (DB2, Oracle, Sybase), typical guidance is for SWAP to be as much as twice the RAM. However, if the system hosts a 2TB HANA database, allocating 4TB to SWAP makes no sense.
The critical point is the in-memory nature of HANA - the system shouldn't be using SWAP; if it is, either HANA is incorrectly configured, or the host is underprovisioned.
So more isn’t always better.
What About SAP?
Yes, in this post, I'm not discussing the common SAP-related filesystems, such as /usr/sap and the children of /hana. I'll touch on those in XFS Uber Alles.