Tony

Tony - I think you’ve posted this to the wrong place. What’s worse, I think you’ve violated several NDA’s!

Check it out: This is your HDS blog, and you’ve gone off and posted your summary of EMC’s 2010 roadmap!

- Your view of dynamic detection is smart and the “chunk” that will be moved will vary from vendor to vendor. I predict that HDS will use a 42 MB chunk because that fits well into their architecture. In this sense - a volume will be spread across different disk drive types with different RAID levels.

- You can still have pools and RAID groups - these things can co-exist. In fact, you want to do this. Your Tier 1 could be a RAID 10 with the active parts of the volume residing on it and and your lower tier can be RAID 5 with the in-active parts of the volume stored on it. The application will be none-the-wiser.

- LUN expansion and contraction is interesting. This is different than thin provisioning, which a number of storage systems do support today. It is really the host O/S or file system that will take care of this. However it is important for the storage system to integrate and be qualified with the host systems. I agree with the load balancing - the ability to create a pool of resources with a concept in the WAN world - committed information rates - set policies to provide a minimum performance ratio among all requesters but offer extra resources if needed and available.

- Smart reporting is a must. Some of the storage system vendors will tell you that they have some or most of what you describe. But we need to apply what we can do to the physical world to the virtual world. If we are creating private IT clouds with virtual storage systems - we need to be able to run reports on these virtual systems with depth and insight. We need visualization and reporting in order to predict, model and analyze.

Well if we get 20 engineers on it maybe it will only take one year
Thank you for the dialog.

Tony

- Dynamic detection of lun’s nature (write/read, random/sequential, etc) and block level optimization. That means that some (dormant) data of the lun will actually live in the lower-cost storage while if data actively being used it will be in the higher performance tier. Maybe blocksize of the lun will be also adaptable or even variable on the same lun.
- The notion of Raid Groups is very limiting and will be replaced by something like data pools, which will only be governed by redundancy requirements, for example raid 5, raid 6 or maybe raid 1+0. IT department should make the call on the level of date protection they need and could afford. No matter how smart the storage will become the human should make a call if two simultaneous disks failures is never going to happen in their environment, or maybe they are enjoying dealing with the stress and/or restoring the data, or maybe they just don’t like the employer.
- Next, the storage will be able to provide automatic lun expansion and maybe contraction initiated by individual hosts. Of course this will be pretty difficult to implement with the known variety of OS’s and even filesystem types within a given OS. However, to me the storage ain’t smart until it can do the most tedious and thankless tasks done by storage administrators, reducing possibility of human error and removing complexity of the front end interaction with the storage. It also should regulate automatically load balancing via intelligent and possibly dynamic port allocation for each host. So if there is a spike in data demand, the storage will use 4 ports instead of 2 for this given host for the period of two hours for example.
- Smart storage is smart reporting. The storage should provide capacity growth trends and down to the host/lun usage and performance data, especially with the cloud computing/storage direction of the industry, where the same lun might be accessed at the same time by different clustered hosts. Also, what’s required are smart tools and bottleneck alanalyzers, which sometimes could pinpoint a slower HBA or busy switch port, or even high cpu load on the host and not necessarily just the storage itself… yeah, right.

I guess I should stop here. This will be enough work for storage design engineers for the next 20 years.

Thanks for the comment.

Tony

As far as the issues you bring up as being important considerations for adoption of new technologies / capabilities - they weren’t brought up in this particular meeting. I agree that all of these things matter - and to some extent they do fit within fear, uncertainty and doubt - which is very real and should be discussed.

You are spot on - adoption is slow but awareness is being raised. And yes, there are many companies that have implemented - early adopters and in some cases early mainstream adopters. The goal of this blog entry was to share insights from this forum with some heavy duty storage customers.

Thanks