Robot in Modern IBM i Environments

Virtualization refers to the act of creating a virtual version of a computer, its processor, memory, disk, and network. A virtual computer behaves like an actual computer except that it’s easier to modify if business requirements change. You can increase or decrease a virtual computer’s resources without buying hardware or involving hardware engineers. If one virtual computer has spare capacity and another computer needs it, you can reallocate it.

The move towards virtualization has not happened over night. Virtualization features have been continually added to IBM i since its launch, and they have now come to a point where many large enterprises and SMEs are finding these capabilities functional, complete, and robust enough for widespread adoption.

So, let’s look at the features currently available that enable virtual IBM i computers.

Operating System (IBM i)

When the AS/400 was launched in 1988, the operating system was called OS/400 Release 1. It became i5/OS V4R5 in 2000, then IBM i version 6.1 in 2008. Major releases to the operating system continue today with a roadmap for the technology extending well into the future. And while new virtualization features have been added over the years, the base architecture has remained the same.

Unlike most other operating systems, IBM i has always had hardware virtualization capabilities. For example, single-level storage gives us the ability to view all storage— memory, solid state, and spinning disk—as a single name space so that operators and programmers don’t need to worry where data is physically stored.

Virtualization capabilities link IBM i closely to the hardware on which it runs with self-diagnosis and self-healing capabilities. As a result, it’s not advised to transplant IBM i from one hardware environment to another. If you save IBM i (SAVSYS) and restore it to another server, for example, it will typically go into shock and spend hours diagnosing and self-healing until it makes sense of its new environment. Note the following about IBM i:

• It’s a best practice not to try to move your instance of IBM i to different hardware.*
• It’s a best practice not to mirror IBM i (library QSYS) to a backup server.*
• IBM i must run from an internal disk pool closest to the processor known as ASP1. More often, it’s called SYSBAS (short for system base ASP).

*There is an exception. See live partition mobility.

Auxiliary Storage Pools (ASPs)

OS/400 Release 1 has had auxiliary storage pools (ASPs) since AS/400 debuted. ASPs are virtual collections of physical disk units that are combined together to create a pool. Users do not have to think about which disk their data is being stored on within each ASP—IBM i decides.

Each server can support up to 16 ASPs. ASP1 (SYSBAS) is always reserved for IBM i. Business application and data libraries can also be located in ASP1 or in one of up to 15 user-created ASPs, assuming there are sufficient disk units available. The user ASPs are numbered 2 through 16.

The primary purpose of ASPs is to improve business application performance by allowing users to contain I/O heavy activity, such as journaling, within their own ASP. This helps to ensure that I/O performance bottlenecks are less likely to affect mission-critical business applications running in other ASPs.

Since 1988, each server had only one name space, which means that library names could not be duplicated on a server. Larger organizations would have to use multiple servers, each one running a single application environment.

Logical Partitions (LPARs)

Zipping forward about a decade, AS/400 (OS/400 V5R4) introduced logical partitions (LPARs) in 1999. An LPAR is a virtual computer that sits within a server and behaves like an independent computer with its own unique instance of IBM i. You can power an LPAR up and down as if it were its own actual computer. Since each LPAR has its own name space, library names can be duplicated within the same server so long as names are used in different LPARs.

Many SMEs and large enterprises could now consolidate multiple stand-alone servers into single, larger servers running multiple LPARs. This made things easier to manage and more cost effective.

Storage Area Networks (SANs)

In 2001, eServer iSeries (i5/OS V5R1) gained the ability to attach to storage area networks (SANs). A SAN is an external disk subsystem where disk capacity can be carved up and shared by many servers simultaneously. It’s also possible to move the disk capacity around within a SAN as business needs change. This is a big advantage over previous internal disks that offered much less flexibility. SANs are sometimes referred to simply as external disk storage. IBM’s most used enterprise SANs are called DS8000s, and IBM’s midrange SANs are called Storwize V7000s. EMC’s enterprise SANs are called EMC Symmetrix.

Independent Auxiliary Storage Pools (IASPs)

At the same time as SAN attachments became available, independent auxiliary storage pools (IASPs) were introduced. An IASP is similar to an ASP except it has its own name space and is located within a SAN.

Many SMEs and large enterprises replaced internal disks with SANs because it gave them more flexible storage management and, ultimately, cost savings down the road.

Initially, IASPs were slow to be adopted by IBM i users because they require business applications to include an IASP number alongside a library name whenever they point to an object. This requires a lot of testing and application code changes in many cases. Over time, however, many business applications have been gradually modified so that they are IASP enabled. Not all business applications are IASP enabled today, particularly in-house developed applications or heavily modified ERPs.

Disk Storage with Robot

When taking advantage of IASP technology on IBM i, Robot Space disk analysis software can assist by monitoring disk space usage and reporting on usage spikes. Robot Space allows for setting multiple thresholds, activating temporary storage monitors, and automating cleanup tasks. Built-in analysis tools gather snapshots of disk storage to help administrators find lost disk space by comparing changes.

Additionally, Robot Schedule job scheduling and batch management software controls which jobs can execute in attached IASPs and can be installed directly into an IASP, along with Robot Console message management and resource monitoring software.

Live Partition Mobility (LPM)

In 2012, IBM i V7R1 TR4 introduced live partition mobility (LPM). LPM lets users move an active LPAR from one server to another without disrupting active users or active jobs. LPM is intended for live migrations, workload balancing, planned maintenance, and power consumption reductions. LPM is not intended for HA/DR.

The primary and secondary servers must be identical and attached to the same SAN. When you execute a live migration, a snapshot of main memory is taken and copied to the target machine while changing disk pointers on the target LPAR to match disk pointers on the source LPAR at the same time. The target LPAR now has the same data in main memory as the source and is now in charge of the disk and memory. The migration typically takes a few seconds, and users are typically unaware it has happened.

Power Hypervisor

Power Hypervisor is firmware integrated into IBM Power Systems that gives us the ability to divide physical system resources into separate logical systems or logical partitions. The hypervisor handles time slicing and dispatching for the partition workloads between processors. The hypervisor can dynamically assign processors, I/O, and memory to each LPAR. The hypervisor can also assign shared processors to each LPAR using micro-partitioning.

Virtual I/O Server (VIOS)

The Virtual I/O Server (VIOS) is software that runs in a dedicated AIX LPAR within an IBM Power System. VIOS interacts with the hypervisor and facilitates the sharing of physical I/O resources and network resources among other LPARs within the IBM Power System. The VIOS LPAR acts as the host system and owns all physical resources. These resources are then virtualized out to the client LPARs. Typically, at least two VIOS are recommended per physical IBM Power System to provide redundancy and balance performance.

Micro-Partitioning

Micro-partitioning is the ability to add fractions of processors instead of whole processors to an LPAR to help make better use of available processors. The initial processor assignment for an LPAR is a tenth of a processor with increments of a hundredth of a processor. LPARs can either be dedicated processor LPARs (processors are assigned in increments of a full processor), or they’re shared processor LPARs (these use micro-partitioning); they can’t be a combination of the two.

PowerHA is a general term given by IBM to a group of mostly hardware-based technologies that can be combined in different ways to provide disaster recovery, high availability, or both. PowerHA technologies are building blocks. None of them provide HA/DR individually; they must be combined into a configuration that is designed to meet the customer’s need and budget. Here are the most common configurations.

LUN Level Switching (PowerHA)

The simplest PowerHA configuration is called LUN Level Switching. This allows two IBM i servers located in the same site to share the same IASPs within a SAN. In normal mode, the primary system can access the IASPs (it has the IASPs varied on). The secondary system cannot (it has IASPs varied off). The secondary system is active because it has ASP1 (SYSBAS) running the operating system, but it cannot access the business applications and data, which are located on the IASPs.

If the primary system fails, needs to be taken offline for maintenance, or is brought down as part of a switch operation, the secondary system can then access the IASPs (it varies them on). The primary system cannot (it has the IASPs varied off). LUN, or logical unit number, refers to an individual disk drive.

Geo Mirror (PowerHA)

A popular PowerHA configuration for SME environments is Geo Mirroring. This solution uses the host IBM i server to mirror memory pages from an IASP on a production server to an IASP on a remote secondary server. Geo Mirroring can be done in synchronous or asynchronous mode. Synchronous mode suffers from several limitations including limited distance and performance. Asynchronous mode is more popular because it has better performance and can mirror any distance.

While mirroring, the secondary system is offline. If the primary fails, then the secondary is brought back online with an IPL (initial program load) and now contains all the data that was on the primary at point of failure.

The contents of SYSBAS are partially mirrored using other techniques to make sure user profiles and passwords are current on the secondary, for example.

Metro Mirror with FlashCopy (PowerHA)

Metro Mirror is popular among larger enterprises. This technique avoids using the host IBM i server and instead executes SAN-disk to remote SAN-disk mirroring in synchronous mode. Disk sectors are captured, mirrored, and applied without using additional host resources.

Since disk sectors are mirrored synchronously, there is a limitation on the physical distance the secondary server can be from the primary. Typically, it’s no more than 31 miles (50 km). During mirroring, the secondary server is offline. If the primary server fails, the secondary is brought online with an IPL and now contains all the data contained on the primary at point of failure.

FlashCopy is used for periodic snapshot backups. This uses a bitmap copy technique that can duplicate the entire contents of one IASP to another on the same SAN in seconds. This action can be performed either at Site A or B and requires only a short interruption to service.

Here again, the contents of SYSBAS are partially mirrored using other techniques to make sure user profiles and passwords are current on the secondary, for example.

HyperSwap

HyperSwap technology provides the ability to instantly switch an IBM i server from a primary SAN to a secondary SAN, providing continuous operations in the event of SAN failure. The switch can happen automatically, in case of SAN failure, or manually, in case of planned maintenance. It can also be automatically triggered by a live partition mobility (LPM) switch.

It is necessary to combine HyperSwap with Metro Mirror to ensure that the secondary SAN contains a current synchronous copy of mirrored data. HyperSwap is currently limited to DS8000 SANs.

Global Mirror with FlashCopy (PowerHA)

Global Mirror is used by larger enterprises wishing to avoid the distance limitations of Metro Mirror. Global Mirror can mirror over any distance. This solution uses SAN-disk to remote SAN-disk mirroring in asynchronous mode. The IASP that receives the data is a staging area from which FlashCopy is used to make a bitmap copy to another IASP, typically every 30 seconds. This is called a consistency flash because the resulting data is consistent and usable.

During mirroring, the secondary LPAR is offline. If the primary LPAR fails, the secondary is brought online with an IPL and now contains all the data contained on the primary, minus about 30 seconds of data loss.

FlashCopy is used for periodic snapshot backups. As previously stated, this uses a bitmap copy technique that can duplicate the entire contents of one IASP to another on the same SAN in seconds. This action can be performed either at Site A or B and requires only a short interruption to service.

Here again, the contents of SYSBAS are partially mirrored using other techniques to make sure user profiles and passwords are current on the secondary, for example.

Full System Copy

While all PowerHA solutions rely on IASPs as building blocks, it is possible to use FlashCopy, Metro Mirror, and Global Mirror without IASPs. Without IASPs, customer data and SYSBAS are combined when mirrored, resulting in a full system copy.

In the event of a primary server failure, the secondary server may need a lengthy, abnormal IPL procedure as part of a switch. This is because the IBM i operating system is a living, breathing thing that has been transplanted to a foreign server and now must rediscover where it is. Full system copy can be useful when RTO times do not need to be optimized.

Software-Based HA/DR

Software-based mirroring technology has been popular for high availability and disaster recovery for many years. There are several products available including Robot HA, MIMIX, OMS/ODS, iTERA, QUICK-EDD/HA, MAXAVA HA Suite, and others. All products use IBM i journaling to transport data changes to a remote backup server. Most often, IBM’s remote journaling in asynchronous mode is used as a transport mechanism.

Software-based HA/DR solutions are highly flexible and have few prerequisites. They mirror customer data and the essential parts of SYSBAS and can work with or without IASPs or SANs. Most recently, software-based HA/DR is being configured with multiple nodes, typically a local HA node and a remote DR node.

One key difference of software-based HA/DR compared to hardware-based HA/DR is that the backup/secondary is online while mirroring. This means it is possible to off-load some query and reporting workload to the backup, and it means there is no IPL needed during a switch.

Virtual Tape Library (VTL)

As disk storage has become cheaper, it has become increasingly advantageous to replace traditional tape media used for backups with disk storage. Tape storage technology is over 60 years old now and comes with a number of limitations when compared to disk. For starters, it’s slower, data can only be written and read sequentially, and it has to be physically transported to off-site locations. Disk is much faster, can be read in any order, and it can be replicated to a remote disk storage in real time. Special VTL software allows disk to emulate a tape drive so there is no need to modify existing save and restore routines when switching to VTL technology. VTL solutions are available from IBM, EMC, DSI, and Crossroads.

As hardware and software technologies evolve, so too does the complexity of the data center. IBM i often serves as the backbone for business-critical applications, including ERP packages, leaving other servers to run email, print serving, and the website—but users and other computing technologies still draw data from the transactional database on IBM i.

Robot Schedule interfaces with Oracle JD Edwards EnterpriseOne and SAP third-party ERP applications to retrieve true job completion information for EnterpriseOne UBE versions and SAP BAPI processes.

Robot knows many data centers have more than just IBM i to manage. Windows, UNIX (or AIX), and Linux operate alongside IBM i and have processes that must be coordinated and files that must be moved between these systems. The Robot Schedule Enterprise plug-in allows ERP processes to be integrated into other IBM i and enterprise job streams using the corresponding interface. It also allows true cross-platform dependencies and file transfer management so that data is ready and processes are triggered without delay, fully utilizing system resources and available processing time.

This is especially important as businesses—and their data—get bigger. As databases grow, backups take longer and systems are required to support huge amounts of historical data that must be monitored for overages. High availability products in complex environments can leave behind unsaved journal receivers that need cleanup; file transfers leave behind outdated files; files themselves need reorganizing; and document storage in the IFS must be monitored and cleaned up or the system might end up with unplanned downtime. Robot Space monitors IBM i disk usage and analyzes historical trends so teams can predict future growth and make smart decisions about additional storage investments.