System i on Blade

Introducing the IBM BladeCenter

The IBM BladeCenter is a reflection of IBM technology sharing. But be careful, this architecture assumes that you as the customer will be the technology integrator. IBM technology sharing does not necessarily include the desire to make this product easy to setup and maintain. Our industry has adopted a certain level of complexity as we've moved towards a greater use of commodity (read that Intel) servers. IBM is a part of that overall trend.

Let me preface my subsequent remarks by disclosing that my views of the BladeCenter are heavily influenced by my long history of, and affiliation with, the IBM AS/400 and its successors.

First of all, the IBM BladeCenter is an architecture. Customers should not consider its purchase in the same manner they would if they were buying individual servers. With the IBM BladeCenter you are effectively investing in the chassis, and expending for the servers. In other words, the servers, like any other Intel based servers, will ultimately be a throwaway item over time, while the chassis will remain in place..

If you are considering a BladeCenter, please note that they only become cost effective when you have at least 5 physical blades to populate in the chassis. I won't bore you with the math, since that changes with pricing actions, but suffice it to say that if you need less than 5 servers, forget the BladeCenter.

Do you currently have a SAN? Do you understand how to manage a SAN? Why do I ask these questions? I ask them because the BladeCenter will drag the use of a SAN. With the exception of the BladeCenter S, the BladeCenter itself does not have storage. Of course, the individual Blades may contain one or two disk drives, but the the use of those drives varies by the operating system being deployed on that Blade. How this affects AS/400, iSeries, and System i customers I will explain momentarily.

I have spoken with System i customers who view the BladeCenter as an inexpensive alternative to the traditional System i that comes in either a rack or tower form factor. The reason at first appears simple, the cost of a Power6 blade is relatively inexpensive, at under $ 5,000. Unfortunately, there are numerous other considerations that should factor into your decision. One consideration is not so obvious, and that is from whom to purchase your Power6 Blade ( JS12 or JS22).

I know of a customer who had iSeries and pSeries and BladeCenters installed in their environment. The customer thought the new Power6 Blade would be an ideal way too host their iSeries applications going forward. To that end, they contacted their business partner and purchased a new JS22. This was hailed as a great decision since this customer had all the skills in-house to make this a deployment a success.

There was just one small problem. When they went to purchase the operating system from their business partner they found they could not. Their business partner was sanctioned by IBM to sell System p, AIX, Blades and IBM SANs, but they did not have the value add to sell IBM i (aka OS/400). They were never an iSeries business partner. That was not their heritage.

Eventually the problem was resolved, but it was messy. The bottom line is that IBM makes no distinction between business partners when it comes to the JS21 and JS22. So a business partner might inadvertently sell a Power6 Blade and not be able to sell the desired operating system.

In the above example the customer believed they had all of the skill sets to make the JS22 work with both the BladeCenter and IBM i. In my opinion, most iSeries customers do not possess those skills nor do most of IBM's business partners.

If one successfully downloads and installs all the various firmware and patches for the Advanced Management Module and the other I/O modules that were purchased, then they will be in a position to install the Power6 Blade (JS12, JS22, JS23 or JS43) and then install the operating system. I won't go into detail, but this initial process is tedious and must be done very, very carefully.

VIOS: Another operating system to worry about

At that point in time your are ready to focus on the install of the Power6 blade. However, there are some things you must first understand about the architecture of IBM i in a BladeCenter. For those that don't know, the System i on a Blade is a partitioned server, meaning that you will always have at least 2 LPARs on the Power6 Blade you install. One LPAR will house IBM i and the other will host VIOS.

VIOS is the Virtual IO Server, a subset of AIX. Stated another way, VIOS is essentially a limited use AIX LPAR dedicated to serve I/O devices to IBM i. It is VIOS that owns the I/O that IBM i needs to operate. In other words, IBM i cannot directly access the disk drives. VIOS see the disks via the I/O adapters, maps the drives for IBM i, and then presents them to IBM i as if they were native. VIOS also owns the tape drive(s) and the Ethernet adapter(s) and it presents those to IBM i too.

One implication of using VIOS is that you can forget IBM i based disk management. This is a shame since the gem of operating system, even from the days of OS/400, was it's disk management. That has now been compromised in the BladeCenter. Disk management is now the province of VIOS and the SAN that ultimately holds all objects. IBM i was very advanced in managing DASD, and in my opinion this new design is a step backwards. Whereas on a dedicated System i you can get direct access to your data, on the BladeCenter you must go through two constructs (VIOS and the SAN OS) to get to your objects. Is this more efficient? Are there more points of failure? I think so.

It should also be noted that even though the Power6 blades can have one or two disk drives, these on-board drives can only house the operating system (IBM I); they cannot be used to store your data. Data must always reside on external DASD.

Backup requires VIOS

Another major implication of VIOS is tape backup. Forget your current automated backup routine. When originally introduced in 2008, the way backup worked was that your objects were copied up to an optical image first and then to tape. They called it an optical image but actually the backing was to a disk image first. That means you needed at least as much free disk space as you had objects to back up.

Could you automate this process? Sure, if you understood the VIOS scripting language. There is an good publication about VIOS on IBM's web site. One could learn about the scripting language by reading that publication. Personally, I wondered why our colleagues in IBM Rochester did not provide such scripts so that customers could obtain some level of automation. Most of the customers I know still backup their data on a schedule.

In IBM Announcement letter 109-231 of April 28, 2009 support became available for direct backup to selected LTO-4 tape drives that are attached via VIOS. Native save/restore commands and BRMS can now be used with these drives. However, IBM calls this function virtual tape although IBM I already has a virtual tape function that was introduced in i5/OS V5R4.

What about Performance?

In the same announcement IBM introduced the new JS23 and JS43 Power blades. These new blades are 4-core and 8-core implementations supporting up to 64Gbs and 128Gbs of memory, respectively. Omitted from this notice was any mention of their CPW ratings.

It is the CPW rating for the Power6 blades that is the most troubling aspect of this product. IBM has presented a very misleading statement of performance for this product. Let me explain. The JS12 has a 2-core 3.8GHz POWER6 processor. IBM quotes a CPW rating for this blade of 7,100.( http://www-03.ibm.com/systems/bladecenter/hardware/servers/js12/perfdata.html ). This ratingwas achieved under test with 90-drives assigned to IBM i, and with .2 processors assigned VIOS. How many System i customers would have 90-drives attached to IBM i on a Power blade? That equates to at minimum some 6.5 Terabytes if disk.

The IBM Power Systems Performance Capabilities Reference IBM i Operating System 6.1 is the published authority on performance matters. A careful reading of that text yields a very different expectation. ( http://www-03.ibm.com/systems/resources/systems_i_advantages_perfmgmt_pdf_pcrm.pdf ) If you look in Appendix C1 on page 333 you will note that IBM says that a 12 disk configuration associated JS12 would be equivalent to a 1,200 CPW server (or only 100 CPW per disk drive). I Think that it is safe to say that if you have less than 2 Terabytes of disk being used under IBM i, that your performance is more likely to be in the 1,200 CPW range (or 83% less than IBM is quoting on their web page).

In summary, given the issues with backup and overall performance I cannot see how the Power6 blade implementation can be viewed as a practical platform for most System i customers.

The Worlds Best Computer

Introduction to the System i

The System i is the most advanced computer available to the general public. That is a bold statement, but who can point to another system that can run: i5/OS, AIX, POWER Linux, Windows, Intel Linux, Solaris and Netware operating systems and their applications, concurrently? I know of no other computer that can do this.

This machine is a true 64-bit computer. The operating system, objects and hardware are all 64-bit. The System i has been 64-bit since December 1995 and is in its 12^th generation of 64-bit processors.

Today the System i uses the IBM POWER6 processor running at 4.7 GHz. It should be noted that the POWER6 is architected to run at as high as 5.6 GHz and a single processor can support up to 1,000 LPARs (logical partitions). Intel cannot match this performance. In fact, the fastest Intel processor cannot go beyond 3.8 GHz in clock speed. At 4 GHz the Intel chip runs so hot that the gates may not close in the transistors. This in part accounts for the Intel strategy of using multiple cores all at slower clock speeds.

Even though the AS/400 and its successors, including the System i are used in 85% of the Fortune 500 businesses, this machine remains the least known of IBM’s hardware brands.

But what if you speak with IBM's customers? Then you will be very pleasantly surprised. Our customers are the most loyal and most satisfied of all IBM’s customers. Why? Because the System i is perhaps the most reliable machine in existence, it just runs and runs and runs. It is also the easiest to operate.

If you ask any System i trained person what makes the machine special, you’ll likely get an answer like “Single Level Store”. That’s a great answer but very few folks can explain single level store adequately.

Single level store relates to how the System I views where objects are located. Essentially everything stored on the System i: files, programs, and profiles, etc. are objects. All objects on the System I are referenced by name not by name at location as you do in Windows, UNIX and Linux. One way to look at this is that the ‘system’ acts as if all objects are currently in memory. The system views memory and disk as one big storage space.

Another perspective says that objects are not referenced by location since their location is likely to change if the system acts to optimize itself. In essence the most critical area of the System i architecture is its storage management.

System i Storage Management

The System I supports both internal (also known as integrated) storage as well as external (i.e. SAN) storage. The most prevalent in use is internal storage, and the way this is managed is elegant.

An object put onto the System i is scatter loaded across the available drives. This happens regardless of the protection scheme in effect (none, RAID5, RAID51, RAID6, or RAID10). This spreading of the data is not in and of itself anything special. It’s what happens next that makes it special.

The operating system, i5/OS will then manage each drive such that the occupancy across the drives is equal. Therefore, if there are 10 disk drives on the system, all 10 will show approximately the same level of space consumed.

Aside from occupancy, the system will also balance the arm busyness (also called spindle or actuator activity). As a general guideline, no given arm on the System i should ever be above 40% busy.

Disks may be added to the System i hot (while the system is running). The new drives will be flagged and then given higher priority for saving objects. When the system has spare CPU cycles it will perform its balancing act over time. Or the customer can issue a command and force balancing immediately across all drives (including the new one).

Since any given object is scatter loaded, when an object is called for execution and it is not already in memory, the system will queue up the arms to access the object in tandem, or in a coordinated fashion. The result is that I/O-bound applications are particularly faster on this machine than others. Database applications doing large table scans as well as random-I/O applications like those found in typical online transaction processing will be executed faster.

These two factors alone cause us to think of disk acquisitions differently on this machine. For example, the more arms the better. It will be better for instance to have 4 – 72 Gb. disk drives installed than 1 – 288 Gbs drive; the lesson is that four arms working is better than one. The smaller drives have less real estate for the arms to traverse to access the called upon object.

The most exciting aspect of System i storage management is that all the operating systems can exploit it to their benefit. For instance, a Windows server on the System i will never have to be defragged and windows disk drives can be dynamically expanded while Windows applications are active. You cannot do that with a Windows server from Dell, HP, Gateway or IBM, but you can do this with the System i.

A customer once asked me what I could do with Windows on a System i that I could not do on a free standing system. I told him that I could sit in Philadelphia and add disk to a system sitting in Chicago. Could he do that? The answer was of course not. And as an added bonus, the disk protection in effect for i5/OS would automatically, and transparently be extended to Windows, AIX, Linux, Solaris and/or Netware.