Storage Pools
This article introduces the idea of using IBM i storage pools to:
- Reduce initial program load time (system IPL).
- Reduce the time to save the system via SAVSYS.
- Host multiple versions of applications & databases.
- Host external developers and/or tenants. Give them their own storage & database environments.
- Create installation packages for your applications.
Background
IBM i is always installed in a base storage pool (a collection of one or more disks) known as SYSBAS. This pool contains the libraries, directories, and file systems that pertained to the operating system.
SYSBAS may also contain libraries, databases, directories, and file systems pertaining to end-user applications. In fact, that appears to be the configuration on most IBM i servers - a mixture of operating-system and end-user application components in the SYSBAS storage pool.
IBM i Navigator has a wizard that facilitates the creation of independent auxiliary storage pools from one or more disk drives. A good reference that covers this is Disk Management. Another is Implementing IASPs.
This piece considers some of the benefits of dividing operating-system components from end-user application components in separate storage pools.
Reduce IPL Time
An IBM i initial program load includes diagnostics and disk synchronization of the SYSBAS storage pool. For IASPs, such steps are not performed until an IASP is "varied on". This is normally performed by a system administrator, after an IPL. Thus the IPL may be streamlined. The time is especially shortened to recover from an abnormal system end.
Reduce System Save Time
The ASP Device parameter of the SAVSYS command provides several options for selecting which storage pool(s) to include in the backup. This provides the operator more control over the scope of each backup - what to include (and exclude). The time to perform a backup can be reduced by only including disk pools that need to be included.
There is something appealing about having a backup of operating system components, which is separate from end-user application components. Changes to some storage pools may happened less frequently, and not require backup as frequently as others.
Host Multiple Versions
Libraries, directories, database directory entries, and other file system components pertain to an ASP device. This enables the same names and object types to reside in more than one storage pool. Thus you can maintain multiple versions of your application and database components by saving them in one IASP, and restoring them to another.
The user's "currently assigned ASP group" is determined by the Job Description associated with the User Profile, and may be switch by running the SETASPGRP - Set ASP Group command. The user must have authority to the command, and authority to the device description associated with the ASP.
When a new storage pool is created, an additional database directly entry is also added for that pool. The WRKRDBDIRE - Work with RDB Directory Entry command can be used to review each.
Thus, users may be enabled to switch between one version of an application and another, one database or another by means of a single command.
Although application and database objects may reside in an IASP, your installation routine may need to store some object types such as *SBSD, *JOBD, *JOBQ, *CLS, *MSGQ in *SYSBAS in order to be used with IBM i commands (such as STRSBS) that require such objects to reside in *SYSBAS or a basic storage pool.
Host External Developers and Tenants
The use of IASPs can be a more efficient and economical means of hosting tenants, including external developers, than configuring and managing logical partitions "LPARS".
Tenants share the same instance of the operating system, while only having access to the storage pool pertaining to their user profile. Protecting one tenant storage pool from another may be as simple as excluding user-group profiles from having access to the ASP device description pertaining to other ASP groups. Users in one group can't even see the libraries, directories, and other file-system components pertaining to another.
Logical partitions have significant compute overhead and require separate management such as loading and applying PTFs to each partition, which is eliminated by using IASPs on a single IBM i instance. However one down-side is that an IASP configuration requires one or more disk drives, whereas logical partitions can be configured to use a portion of a disk drive.
If you are interested in having IBM provide support for IASPs that cover only a portion of a disk drive, in order to facilitate the creation of micro storage pools, please consider voting and commenting on this Request for Enhancement.
Create Installation Packages
This benefit may be of interest to independent software vendors "ISVs" who package their products for distribution, including automated setup. Development libraries, directories, and databases generally contain objects and data not meant for distribution.
Some ISVs take advantage of a free Partnerworld program that enables them to "rent" an IBM i LPAR for a week or so. They may restore their development libraries, etc. on the virtual-loaner server, delete objects and data not meant for distribution, then build a package from what remains.
A local IASP offers a similar environment for packaging software that may be permanent as opposed to temporary.
Summary
I hope this article, addressing some of the benefits and use-cases of disk pools might pique further investigation and trial on your part.
The time savings from SAVSYS and IPL are especially applicable to installing PTFs and performing IBM i release upgrades.
IASPs are fundamental to IBM's Power HA and Geographic Mirroring products, used for high availability.
There are a number of of similarities between storage pools under IBM i, containers such as Docker, and guest partitions found in Windows and *Nix environments.