Inside System Storage -- by Tony Pearson

Tony Pearson Tony Pearson is a Master Inventor and Senior IT Specialist for the IBM System Storage product line at the IBM Executive Briefing Center in Tucson Arizona, and featured contributor to IBM's developerWorks. In 2011, Tony celebrated his 25th year anniversary with IBM Storage on the same day as the IBM's Centennial. He is author of the Inside System Storage series of books. This blog is for the open exchange of ideas relating to storage and storage networking hardware, software and services. You can also follow him on Twitter @az990tony.
(Short URL for this blog: )
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (7)

1 localhost commented Trackback

Tony, great post. I'd also include (although they didn't invent) the virtualisation in RVA, which enabled virtual LUNs to be created to do thin provisioning. This was an STK product if anyone is interested. One other point, you indicate that Hitachi uses 1:1 mapping versus more complicated mapping in SVC. In fact, I see Hu push the merits of 1:1 mapping in his posts but it isn't the only way to use virtualisation in the USP. For the implementations I have done, I didn't have enough addressable LUNs in the lower tier AMS to be able to present the LUNs as 1:1 through the USP, so I chose to present larger 400GB LUNs and use the USP to slice them. This meant I could address more storage however I lose the ability to just unhook the USP and go direct to the storage. The question is do I care? Probably not. My implementation gets better performance anyway.

2 localhost commented Permalink

Tony,<div>&nbsp;</div> One of the major tasks of a RAID controller is to present (on its host ports) an error free and ‘perfectly’ emulated disk drive… usually as a number of LUNs.<div>&nbsp;</div> In the proposed scheme, the SVC &amp; USP provide another level of "virtualization" in front of the existing &amp; already “virtualized” third-party backends, containing RAID controllers. This is sometimes called a “raid of raids”. <div>&nbsp;</div> Hence, the principle of "virtualization" in SVC is similar to that implemented in a typical RAID controller, driving a number of generic disks. However, this SVC ‘virtualization” task is much simplified by the fact that there is nosupport of RAID 5/6 algorithms. Why not..? <div>&nbsp;</div> RAID5/6 are very computationally &amp; backend IO intensive algorithms, difficult to implement at the required performance level. This particularly true on ‘commodity’ PC hardware, on which the SVC is based. Performance is one of the major reasons justifying purpose-built RAID controllers. <div>&nbsp;</div> If you remove the need for RAID 5/6, then all you have is RAID 0/1 … i.e. no extra level of protection…. and more computing power available to LVM, replication and data migration tasks. <div>&nbsp;</div> SVC seems to be similar to what is currently available under Linux, which is very efficient in striping over multiple host adapters, supports good LVM tools…. and also has a problem with performance under RAID 5/6.<div>&nbsp;</div> There are some other issues to explore ….<div>&nbsp;</div> How does one manage &amp; support multi-vendor RAID protected backend enclosures… with different controllers, disks &amp; management interfaces? How doe one justify the cost &amp; complexity of “split” support responsibility? How does SVC scale and how is it a better solution to a large centralized system..?<div>&nbsp;</div> All said and done… I suspect that it may be cheaper to migrate all of the backend data to a more ‘uniform’ hardware …. to multiple RAID-protected backends or perhaps on one large array. Both IBM &amp; HDS can provide this. <div>&nbsp;</div> The extra level of virtualization (be it SVC or USP) is an excellent tool for such “as you go”, uninterrupted data migration. <div>&nbsp;</div> In practical terms, this is a very thinly disguised marketing campaign to facilitate another case of vendor lock-in…...but is there any other alternative ?

3 localhost commented Trackback

Chris, Richard, you both bring up good points. Rather than a response here, will address them in future blog posts.

4 localhost commented Trackback

Hello Tony, hope you were able to clean up your computer screen. Good comments from Chris and Richard. I felt the need to clarify my statement due to your post. Please check it out on my blog. By the way I like your blog and appreciate that you keep it open for comments.<div>&nbsp;</div> RegardsHu

5 localhost commented Trackback

Hu, thanks for the clarification. The SVC now has 8GB per node (it was 4GB, but now is 8GB as of September 2006).

Add a Comment Add a Comment