Storage is one of those subjects that we have never really had to worry about on iSeries and AS/400. We never worried about what our Windows and Linux brethren were doing with SANs and the like and IBM has always told us that keeping storage internal to i5/OS and OS/400 is the way to go. I have always been of this opinion too but recently I have had to give external storage far more consideration. I have been curious for a while now about what benefits external storage can provide and last October at the System i CUA meeting in Bristol, I caught up with Stu Preacher from IBM who works for the System Storage Division. Stu is an ex-iSeries person who has vast experience of i5/OS and all matters related to storage.

After listening to Stu's session on i5/OS and external storage, I found I was convinced that IBM really does have something we all should listen to. i5/OS attachment to external storage is something which will become far more prevalent over the coming years. I also recently attended the System i Technical Forum where IBMers and Business Partners are told what lies ahead for System i. Much of the information is confidential but what I can say is that my hunch was right, external storage will be as viable an option as internal storage with the next release of i5/OS.

Let's look at what we can do with our storage from an i5/OS perspective. It is important to make this distinction because System i can support just about any storage option available when attached to AIX or POWER Linux, hence the reason I am focusing on i5/OS.

SYSTEM ASP

Your disk and memory is managed by i5/OS and, by default, all disk units are located in the System Auxiliary Storage Pool (*SYSBAS). If you add more disks to your system you simply add them to the ASP and they are available to use. Certain i5/OS objects must be located in the system ASP such as the QSYS library.

ASP – DISK POOL

Sometimes we may want to segregate a number of disk units. We do this  by creating a user ASP (auxiliary storage pool) in which we can store user libraries and objects or just journal and journal receiver objects. This can be useful if you have archive libraries that are candidates to be stored on older, slower disk units.

A common use for user-ASPs is to store journal receiver objects for your database files. Many years ago, using user ASPs for this use virtually eliminated the disk performance overhead of journaling but these days, with faster disks and large write caches on the disk adapters, this is not so much the case.

INDEPENDENT ASPs

These are hot! IBM likes these and you will see a lot more on these over the next few years. Here's a question for all you techies. Can I store two or more libraries with the same name under i5/OS? The answer is yes, if you use IASPs. An IASP has an identifier called a name space. You can store libraries and their objects inside a name space. Libraries with the same names can be stored on the same system as long as they are in separate name spaces.
You could have a system with two, or more, IASPs and all of these could contain exactly the same library names but each with separate data -- name spaces allow this to happen.

Be aware, though, that not all object types are supported in an IASP as this could cause problems and conflicts with your applications. For example, you may have two companies accessing their own data from libraries in two separate iASPs. This would allow the libraries to have the same names but wouldn't overcome the problem of having two users with the same name because user profile objects have to be located in the System ASP, so must be unique across the entire system.

SWITCHABLE ASP

A switchable IASP (SWIASP) is the same as an IASP but it can be switched from one i5/OS system, or LPAR, to another. This provides a form of high availability because a set of disks can be moved from one system to another should the primary system fail or require routine maintenance. Let’s be clear here, this is not done without downtime. If the system which 'owns' the SWIASP fails, then we need to move the SWIASP to the secondary system and then vary on the SWIASP on the secondary system. This process need not necessarily take many minutes and for many organisations is an acceptable amount of time for an outage.

CROSS-SITE MIRRORING

This is sometimes referred to as XSM and provides the capability to mirror a set of disks from one system to another. In IBM System Storage this used to be called PPRC and is now called Metro or Global Mirroring. When a change is made to the data on the local disks in an IASP, the change is sent to a remote copy of the disks in an IASP on another System i.

XSM was introduced at V5R3 but has been vastly improved at V5R4. It is now possible to quickly recover from a comms failure between the two systems. In V5R3, a comms failure meant that the target copy of the data got out of sync with the source copy and had to be completely rebuilt when the comms link had been re-established. In V5R4, a comms failure initiates a source caching functions which tracks the changes to the source disk units and then replays these on the target IASP once the comms link has been re-established.

EXTERNAL STORAGE (SAN)

Good and bad news here. Yes, it is supported and it is entirely possible to have your i5/OS systems configured without any internal disks at all. A storage area network (SAN) is what is used to provide this. To date, only IBM ESS, DS6000 and DS8000 ranges of SAN can support i5/OS, as well as some EMC SANs too. These are high-level SAN products and can be quite expensive. Nevertheless, if you look at what a SAN can give you it may well be reasonably priced.

The disks in the SAN will most likely be RAID-5 or RAID-10-protected, meaning that we don't have to worry about it at the i5/OS level. IBM SANs also have Metro and Global Mirroring features. These ensure that data written to the local SAN is mirrored to another SAN, locally connected or across whatever distance necessary -- very similar to XSM.

IBM SANs also have FlashCopy too. This allows you to take a copy of your entire disk subsystem in a matter of seconds. Picture this. You are upgrading from V5R4 to VXRY so you do a full system backup to tape. This could take a long time if you have a lot of data; for this example we'll say two hours. You carry out your upgrade to VXRY and commence your testing only to find that there are problems and you need to go back to V5R4. This means loading the tape and doing a full system restore, let’s say around four hours. With external storage and FlashCopy, your initial save would not have been required. Should you wish to regress back to V5R4 after the upgrade, it would be merely a task of IPLing the LPAR and attaching the FlashCopy of the disks to the i5/OS system, let’s say around 20 minutes.

There is a significant amount of work on storage at present and IBM has said that it will be spending as much on developing internal storage solutions as on external storage. Ideally, i5/OS should be able to connect to any SAN from any vendor just like Windows and Linux/Unix does. We don't have this yet but with the enhancements planned for the near future you will start to see this happening.

The ability to attach to external storage and the enhancements to IASP/SWIASP adds complexity to your infrastructure. After all, today you have to do very little to manage your i5/OS storage. If you utilise SANs and IASPs then you are introducing a new layer of storage management but you are also introducing a more flexible storage infrastructure and, potentially, a different approach to backups, DR and HA too.

In the Intel world a virtual server whose disk is entirely based on SAN can be dynamically moved from one physical server to another providing a level of high availability never achieved before. It would be nice to think that this level of high availability would also be available to i5/OS in the near future with the introduction and use of these new storage features.

Glenn Robinson is the managing director of Quattro Consulting. You can ask him about this or any other of his Tech Tips at mailto:glenn.robinson@quattroconsulting.com

This article originally appeared in the March, 2007, edition of System i NEWS UK