The "New" Value of Single Level Store

As Craig said in his introductory entry in this blog, one of the topics we’d like to cover is benefits of the IBM i architecture. Why do we want to do that? Well, it’s been our experience that many of our customers know they’re getting real value from their choice of IBM i, but they don’t know why, or they can’t concisely explain it to others in their businesses. I guess, being the IBM i Chief Architect, it makes sense to have my first “You and i” cover one such architectural advantage. And I haven’t made it easy on myself. I’ve chosen to discuss some benefits of one of the most complicated parts of our architecture: Single Level Store (SLS).

First of all, what is SLS? In general, I subscribe to Einstein’s advice that we should “Make everything as simple as possible, but not simpler.” In this case, I’m going to simplify a bit, so that we can concentrate on a specific attribute of SLS.

In simplified terms, SLS means that IBM i treats every piece of data stored on the system as if it were in memory, and it assigns an address to that data that remains connected to the data no matter where the data is stored.

Thus, when i creates a file, it assigns the address and whenever the system (or a program) accesses the file, the address is the same, whether the file is currently in memory or currently stored on a spinning disk somewhere.

What does that mean to you? Well, one of the most important things it means is that it saves you time and money. Why? Because, in the IBM i SLS environment, the operating system manages the placement of data on storage. This is second nature to an IBM i customer but is practically unbelievable to a user who’s only familiar with other types of operating systems. Managing which disk drives are connected to the system, how full they are and what data is stored on which disks is a complex task that must be done by technical professionals. This, of course, means that technical professionals must be hired to do the job. The vast majority of customers don’t need to worry about that sort of thing for their IBM i storage.

Saving money and time is certainly good enough on its own, but there’s another great advantage to IBM i SLS and integrated storage management: quick adoption and simplified use of new storage technology.

In April of 2009, IBM announced solid-state drives (SSD) for the POWER6 processor-based systems on which IBM i runs. Because IBM i has integrated storage management, the operating system automatically recognizes an SSD, knows that it has much faster access time than traditional disks and places highly used system objects on SSD, immediately improving performance on the system. We also have tools to allow a customer to simply trace which objects are being most frequently read from traditional spinning disk drives and then request IBM i to rebalance its storage to take advantage of the SSD performance. In future releases, it won’t even be necessary for the customer to do the trace/rebalance step – IBM i will simply do it automatically. By the way, for those customers who heavily use our integrated DB2, there are also interfaces to request that DB2 objects (such as tables, index objects and so on) be placed on SSDs. And all of this support is available on IBM i 6.1 as well as on 5.4.

One of our banking customers was recently in the Rochester Benchmark Center looking to reduce their month-end batch runtime from more than 4 hours to less than 3. They ran a base-line test with 72 disk drives and the batch runtime was 4 hours 22 minutes.  Their second run was with the same 72 disk drives plus eight SSDs and the runtime was reduced to 2 hours 43 minutes. The final run was with 60 disk drives and four SSDs and the runtime was 2 hours and 48 minutes. So they exceeded their performance objective by adding four SSDs and using just 60 spinning drives (they were able to reduce the number of spinning drives since the extra arms used to be required for performance, not space). After some I/O analysis, these performance gains were accomplished by using the recent enhancements to IBM i to place eight DB2 objects on the SSDs. Bottom line, they set up a storage hierarchy managed by IBM i Single Level Store. [[Editor’s note: you can read all about this in the upcoming September issue.]]

You can learn more about how SSDs might be able to help the performance of your applications by reading “Performance Value of Solid State Drives using IBM i.”

Saving time, saving money and immediate benefit from new technology – I think that’s a pretty strong set of answers when someone asks “Why i?”  And it comes to you as a direct result of the Single Level Store architecture of your favorite operating system – IBM i.

Comments

[Aaron Bartell]

This was a great topic to cover and you described it well in laymans terms. Don't know what you have plans to cover in the future, but here are a couple of topics that I would love to hear you expound on as you did with the above explanation of SLS:

- The advantages of subsystem and job control (i.e. WRKACTJOB and all of it's options)

- The advantages of library lists and call stacks.

- The advantages of having the DB embedded into the OS.

Thanks for taking the time to help us prove that IBM i is the best darn OS in existence.

[Craig]

SSDs are a hot topic for sure. If you would like to learn more there is a webcast on October 6 through System i Network where we will discuss the value of SSDs and take your questions.

To register for the webcast see: https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=159213&sessionid=1&key=EE2FA729056EEFB2A2F0A6BBD4844C84&partnerref=wbcsthmpg&sourcepage=register

[Gianni Costanzi]

I've been working on IBM i systems for two years and I've been asking myself if the SLS architecture was something good or bad since the first time I've heard about it (I don't like very much the idea of not being able to exactly understand where my data are, but it's just a personal opinion).. there are always PROs and CONs, but I liked very much your post Steve..

Just one question about the SSDs... we are using external DS8100 storage systems for our IBM i v5.4 partitions: will we be able to introduce some SSDs on our DS8100s, along with the already installed HDDs, or DS8100 won't support mixed SSDs and standard HDDs in the same machine? If it is possible to install, for example, only and array of SSDs in a DS8100, will the IBM i be able to recognize which logical LUNs of the DS8100 are spread on SSDs or will it simply see DS8100 LUNs without being able to understand on which disks they effectively are?

[Craig]

Hi Gianni.... yes SSDs are supported with the DS8100. Best practice would be to have a LUN full of SSDs. Regarding IBM i support, the explotation of SSDs that Steve discussed works with internal SSDs today. We plan to extend this support to SANs and VIOS attached SSDs later on in 2009. This extension will be with an update to IBM i 6.1. So bottom line, yes we will be able to support the environment you described with IBM i 6.1.

[Steve Will]

Gianni - Craig answered your question, so that's taken care of.

Aaron - thanks for the ideas for future topics. Have you been reading my mind? (Or placing thoughts there?) That's the sort of thing I was imagining - a series of articles that helps answer the "Why i?" question.

Mark (sent me an e-mail, but I thought the reply would help others too) -
The tools mentioned above are Start ASP Trace (strasptrc) and Start ASP Balance (straspbal). They have been available for many releases, but the use of them to work with SSDs just started when the support for SSDs came out.

The documentation for using these commands is in the Information Center at http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/rzarm/rzarmtrace-ballance.htm

One thing you need to be aware of to make use of them with SSDs is that we've had to overload the existing "*HSM" value to work on SSDs. This will be changed when the next major release comes out.

[Maran]

Hi Steve,

Very Good Post!

Can you give some light on "the operating system manages the placement of data on storage"
I don't I am correct but all the OS does the same. Then how can say this is an unique feature of IBM i?

Warm Regards,
Maran

[Aaron Bartell]

Another possible topic to expound on is whether the IBM i operating system uses memory more effectively/efficiently than other operating systems and thus doesn't need as much as a Windows/Linux machine to facilitate the same number of users/processes.

[Steve Will]

Maran asked this:

"Can you give some light on 'the operating system manages the placement of data on storage' I don't I am correct but all the OS does the same. Then how can say this is an unique feature of IBM i?"

The key to IBM i, and its predecessors, is that it transparently manages all data across all the storage it owns, without requiring customers to know (or typically care) about which data is stored on which physical drive.

True, each OS puts data on the storage device. However, in most other OSes, the customer or application must choose which storage device gets which data. Customers have to get involved in balancing data across their multiple drives (or volumes.)

If you search the web for "data balance across disk" and you put the name of an operating system in front of that, you'll find that there are many complex documents and tools that teach the users of other OSes how to manage data across storage devices.

For IBM i (i5/OS) you find articles that tell you that IBM i does it for you. The trace/rebalance step is very simple, and does not require the customer to know the placement of the data on the devices.

I hope this helps.

[Maran]

Thanks a lot Steve!

Now I have gotten how IBM i differs from other OSes in terms of Storage Management

Thanks Again!

Maran