IBM i Single Level Store …. In Lieu of a Crystal Ball

When the System/38 was being architected, it was recognized that underlying hardware technology was subject to unpredictable change. While it didn’t take a crystal ball to understand that change would be inevitable, having one to forecast the future of storage technology sure would have been nice. But as we all know, there is no crystal ball. This reality led to the development of Single Level Store. A key feature of Single Level Storage (SLS) architecture is that it insulates the upper-level code from the specifics of the storage technology it uses. Along with the Technology Independent Machine Interface, TIMI (see Steve Will’s “TIMI - Protecting Investments and Integrity in IBM i”), SLS is a fundamental element of the design that has allowed IBM i to continue to take advantage of new capabilities seamlessly.

Single level storage makes memory and disk space one entity; you do not need to know where your programs or files are stored. When you access something, you request it by name, and IBM i will automatically find it for you. Is it already in memory? Super! If it’s not, the storage management component will find it, wherever it may reside on disk and bring it into memory. You don’t need to worry about where the disk is or what type of disk is used. You can easily add additional storage, including solid state drives, to your existing disk configuration. The storage management support effortlessly introduces disks to the system regardless of their capabilities or technological frameworks.

Let’s review some of the technical advantages at your fingertips with IBM i and SLS along with the integrated storage management it incorporates: 

1. You can seamlessly optimize the use of solid state drives. This ability is an extension of automatic storage management. IBM i can automatically place your frequently accessed data on SSDs; IBM i with SLS manages your storage.
   
   But did you know that with the magic of SLS, you can also get immediate benefits of a very fast IPL by putting your load source on SSDs? Several IBM i clients have moved entirely from spinning disks to SSDs; substantially reduced IPL time was among the many benefits
   
   
2. You can transparently add more disk capacity and automatically balance your use of that additional storage.
   It’s critical to have your data and files distributed across disk units to allow for parallelism when accessing that data; you do not want a single disk unit to become a bottleneck. IBM i’s storage management will do this automatically for you. You do have controls, such as trace and balance for fine tuning, but once you have a configured environment, IBM i will take care of it all for you.
   
   
3. You are alleviated of the need to manage where your data is stored or the space allocated to file systems.
   On many non-i systems, you will find storage allocated to file systems. When the file system gets full, you will get errors until you either increase the size of the file system or delete files to free up space. There may be plenty of space available on the physical disk, it’s just not assigned to that particular file system.
   
   When I first started working with some software on a Unix environment and I discovered this requirement, I was dumbfounded. Why would anyone want to worry about how much storage is allocated to which file system? Why doesn’t the system take care of that for you? After all, there’s plenty of disk storage available!

IBM i Single Level Storage is well documented in the IBM i Information Center topic, IBM i Storage Management. Interestingly, this article is geared toward readers familiar with x86 storage architecture.

Other blogs on SLS include Steve Will’s “The “New” Value of Single Level Store” and Mike Cain’s “One of the Crown Jewels: Single Level Storage.”

Single Level Storage makes i easy.

 

 

 

 

Removable Mass Storage

With the October/November announcements, IBM i now supports a new type of removable media. Removable spinning disk (RDX) has become reliable and relatively fast, and can be used as a cost competitive save restore device. Prior to this support, removable media was either Tape or Optical. IBM calls this new type of device Removable Mass Storage (RMS).

RDX cartridges are very reliable, they are ruggedized to withstand a drop from up to 0.9 meters (36 in.) without damage, and they never need cleaning. A cartridge can be placed in either a USB or SATA dock to access the data.

Performance is better than typical for low cost tape drives (DAT), and the SATA device can achieve rates over 180GB/Hr. Chapter 9.31, RDX Device Performance, in the November 2012 Performance Capabilities Reference has the details.

Save/restore operations are done just as with a DVD, for example SAVLIB DEV(RMS01). Because it is an optical class device, you can also use IFS to manage data, e.g. WRKLNK OBJ(‘/QOPT/RDXVOL’). Commands are the normal optical storage commands (WRKOPTVOL, INZOPT, etc.). The IBM i 7.1 Information Center has a new section on Removable Mass Storage (RMS).

Rather than create all new commands, we recognize that the media is random-access and spins, with fixed size physical blocks. That is similar to optical devices, so RMS devices are “optical class” devices to IBM i. RDX Docks are available as CEC installed SATA devices on 6.1.1, or as SATA or USB devices on 7.1 with Technology Refresh 5. Cartridges may be from 320GB to 1TB. Hardware details are available.

IBM i 6.1.1 support reports the dock as a 632A (generic DVD) when directly attached, and as a 632C (virtualized DVD) when a client.

IBM i 7.1 Technology Refresh 5 will report the device as a 63B8 regardless of native attached or virtualized client. This release may host the device, but only to another i partition.

There is no VIOS support for RDX drives.

The external USB devices allow the cable to be unplugged without a configuration change (removing the IOA from the partition, or powering off), but the device should be varied off (VRYCFG) before the device is unplugged.

The announcement material for new I/O features and the developerWorks article on IBM i IO Support Details have additional information.

 

This week’s blog was written by Jim Tilbury who is the lead of the IBM i removable media team. Thanks, Jim!

Lesser-Known Features of Work With System Activity

Hopefully most of you now know that in the 6.1 release, IBM moved the Work with System Activity (WRKSYSACT) command from the Performance Tools licensed program product into the base operating system. WRKSYSACT has been around for a long time, but it has a few features that you may not be aware of.

Work with System Activity is a great tool for getting a basic understanding of what is happening on your partition in terms of performance. WRKSYSACT will show you jobs, threads, and tasks that are using system resources – CPU utilization, synchronous and asynchronous I/O, storage allocation information, etc. WRKSYSACT is the only green-screen command interface in the operating system where you will find information about tasks. Other command interfaces – such as WRKACTJOB – only show information about jobs and threads.

It would take far too much space to write about all of the things you can see through WRKSYSACT; rather, there are a few features that I want to discuss in more detail.

 

WRKSYSACT in Batch Mode

First of all, did you know that you can run WRKSYSACT in a batch monitoring mode and write the performance data to a file? You enable the batch mode with the OUTPUT parameter; by default this is * and the information is presented on your display. But there are two additional options, *FILE and *BOTH, which will write the performance data to a database file (QAITMON in QPFRDATA by default). You can specify the sample intervals with the INTERVAL parameter (which also controls the auto-refresh intervals as well) and how many intervals are collected (NBRITV parameter). When you take the option to write the data to a file, a job named WRKSYSACT is submitted to QBATCH to collect the performance data.

The Print Activity Report (PRTACTRPT) command can then be used to print out a report from the sample data collected by WRKSYSACT. The PRTACTRPT command can generate a summary report as well as a detailed report and has options to allow you to specify a timeframe of interest, specific jobs you may want in the report, as well as what criteria the report should use in ordering.

 

Wait Information

Wait information will tell you what a particular job, thread or task is waiting on when it is waiting to do more work. I wrote about wait accounting in “i Can Tell You Why You're Waiting” some time ago. You can also see wait information using WRKSYSACT; you simply need to determine which job/thread/task you want to look at, and use option 6, Wait detail, for that job or task. Option 6 will bring up a display that will list the wait categories for that job/thread/task. Be aware that this is a high-level summary of the kinds of wait for that job or task. However, it make give you some clues about what job or task you need more detailed information for; you can then use the Performance Data Investigator with Collection Services or Job Watcher data to view detailed wait information.

 

Storage Allocated/Deallocated

WRKSYSACT will also show the storage allocated or deallocated by a job/thread/task by pressing the F11 key to get to View 4. I wrote about “Understanding Disk Space Usage” and in that blog reviewed WRKSYSACT and the storage allocated/deallocated information.

 

Scaled CPU

Scaled CPU time is a metric that can be used to determine if energy management features, such as power capping or power savings, are in effect on your IBM i partition. These energy management capabilities can be turned on through Active Energy Manager, which is a plug-in to IBM Systems Director. When you use these energy management features, the system's processor may run at lower or higher frequencies, which can affect your partition's performance. I wrote about this topic at length in the blog “i Can Understand Scaled CPU Time.”

On the WRKSYSACT display, the value “Average CPU rate” will be displayed if you are using energy management capabilities. This rate is an easy way to determine if your processor has been slowed down due to power capping or power savings.

One final note – one thing that has not changed with WRKSYSACT is the limit of one user at any given time. WRKSYSACT collects a lot of information from critical interfaces in the operating system and the limit of one user ensures limited contention on those critical interfaces.

 

 

 

 

PowerHA and External Storage

This blog is written by Jenny Dervin, IBM PowerHA SystemMirror architect. See her in this new video from IBM.

 

The types of storage used by IBM i customers have become as varied as the types of business that run on IBM i. As virtualization becomes more common and clients move into an external storage environment, PowerHA has technologies that integrate the replication capabilities on those external storage servers with IBM i.

PowerHA SystemMirror for i is based on shared storage clustering technology featuring storage-level replication to support geographic dispersion. That means that replication takes place when data is written to disk. PowerHA determines which volumes on the storage to replicate by its location or address. Production data is placed in an independent auxiliary storage pool (IASP), similar to a volume group on AIX or a D drive on a PC. Whenever a sector is changed within that IASP, it is replicated to the target or backup disk. Object types outside of the IASP are be synchronized via PowerHA using Administrative Domain in order to provide a complete production-ready environment on the backup system.

Most external storage servers support some sort of replication technology. PowerHA supports the replication technology of DS8000, SAN Volume Controller (SVC) and Storwize V7000. When the IASP is located on one of those storage servers, the high availability environment is defined and controlled via IBM i interfaces, but the replication itself is offloaded to the storage server. The advantage of this type of replication is its simplicity and efficiency. No verification is needed, as the data is kept synchronized by the storage servers.

Each of these storage servers support synchronous replication, called Metro Mirror, as well as asynchronous replication, called Global Mirror. With Metro Mirror, the production and target copies of the IASP are guaranteed to be identical. There are distance limitations with Metro Mirror in order to achieve good production response time, depending on available bandwidth and disk write rates. Global Mirror has no distance limitation. With Global Mirror, there will be a slight lag between the production and target copies, but the target data is guaranteed to be consistent, and most customers are able to tune the delay down to only a few seconds. Many customers implement another PowerHA technology, called lun-level switching, to provide local high availability, and then use Global Mirror as a disaster recovery solution. Lun-level switching involves switching an IASP on external storage between multiple partitions or systems in order to provide protection from planned or unplanned outages of the IBM i system.

One more very useful external storage technology, also integrated in PowerHA, is FlashCopy. FlashCopy gives you the ability to create a very fast copy of an IASP which can then be varied on to another partition and used for backups, development, testing, etc. Most of our PowerHA customers with external storage take advantage of this technology to do their backups offline from their production system. I will discuss this technology in more detail in a future blog.

For more information on any of these technologies, please reference the PowerHA SystemMirror for IBM i Cookbook.