April 28, 2021 | IBM i

An Introduction to IBM i iASPs

Inside IBM i servers, disk storage units are grouped together into Auxiliary Storage Pools (ASPs) Each ASP is a collection of internal, storage area network (SAN), or other types of IBM i accessible disk units. There is a special type of ASP called Independent Auxiliary Storage Pools (iASPs). iASPs allow you to move and access the same ASP data on different IBM i servers. Today’s post focuses on iASPs and how they can benefit your IBM i server strategy.

A brief look at IBM ASPs and iASPs

To understand iASPs, you have to understand IBM’s ASP storage types. IBM i ASPs are numbered from 1 to 255. The following ASP types are available on IBM i systems.

System ASP (ASP 1)—The system ASP is automatically created for an IBM i system. It is the default ASP for your system. It contains disk storage unit 1, along with any other disk units not assigned to another ASP. It also contains your operating system objects, licensed programs, and any user objects that are not assigned to a basic or independent ASP.
Basic ASP (ASP 2 through ASP 32)—Basic ASPs are server-defined. You can create a basic ASP by grouping a set of storage units together, and assign that group to an unused ASP number. Basic ASPs are numbered from 2 through 32 (ASP 2 through ASP 32). They are used to isolate certain objects and infrequently used system data. If you run out of storage on a basic ASP, the data will overflow into the system ASP. Basic ASPs are assigned to only one IBM i server. They are not switchable to other local or remote IBM i systems.
Independent ASPs (ASP 33 through ASP 255)—As opposed to system and basic ASPs, Independent ASP (iASPs) can be made available on a local or remote IBM i server, without restarting the server. Independent ASPs are numbered from 33 to 255 (ASP 33 through ASP 255). They have many uses, particularly for business continuity, server consolidation, and database isolation. iASPs can be switched between IBM i servers.

Why use iASPs?

Even though it’s not a perfect comparison, think of iASPs as IBM i USB flash drives. As a USB flash drive can be physically moved between various PCs, iASPs can be virtually switched (brought online and offline) between different IBM i servers. This means the same data, programs, and Integrated File System (IFS) objects can be used on different systems.

Some of the more common uses for iASPs include:

High availability and disaster recovery, where an entire environment can be moved from one IBM i system to another. IBM has several products (including PowerHA SystemMirror, MetroMirror, GeoMirror and HyperSwap), where iASPs are used in business continuity situations.
Backups, including using iASPs for FlashCopy. iASPs can be taken offline and transferred to another server for backup processing. IBM’s Backup Recovery and Media Services product (BRMS) also provides support for iASPs to consolidate backup compliance reporting.
Server consolidation, where you can run multiple applications and databases on different IBM i servers.
Isolating critical application data on its own switchable disk array, such as running your database on a primary iASP and database journaling on a secondary iASP.

Types of iASPs

There are three different types of iASPs you can define for your IBM i systems.

User-defined file system iASPs (UDFS iASPs) that only contain IFS objects.
Primary iASPs that contain native IBM i objects and IFS objects. Primary iASPs can also have secondary iASPs linked to them.
Secondary iASPs that are linked to a primary iASP. Like primary iASPs, they can contain native IBM i objects and IFS objects. Secondary iASPs are added to or removed from an IBM i system along with their primary iASP. One or more secondary iASPs linked to a primary iASP are referred to as an ASP Group.

The mechanics of iASPs

To create an iASP, you need at least one unconfigured disk unit available on your system. iASPs are created by using the Configure Device ASP command (CFGDEVASP) on the green screen or by using System Director Navigator for i.

Independent ASPs are brought online or taken offline through the Vary Configuration command (VRYCFG). When you want to transfer an iASP or ASP group to a particular i server, you vary that iASP on inside the target server (VRYCFG *ON). When you want to make an iASP group unavailable on an i server, you vary that iASP off (VRYCFG *OFF). To reference an iASP in an i server, you have to add an ASP group component to your IBM i name space, and job threads must be configured to reference the iASP data.

In non-clustered environments, iASPs are assigned to a single IBM i system (Private iASP). In clustered environments where iASPs are associated with a switchable hardware group, they can be switched between IBM i systems on a local IBM POWER system or on another IBM POWER system (switchable iASP), enabling many of the iASP uses listed above.

iASPs are entirely flexible and provide a number of functions for IBM i shops, especially for high availability, disaster recovery, business continuity, server consolidation, and backup reporting. Please feel free to contact us at SEA software if you want to learn more about how iASPs can enhance your IBM i strategy.