Is the DS8K, the array which refuses to die? Despite every pronouncement from EMC that the DS8K range is going to die; it refuses to do so and it keeps just motoring on.
In many ways, I have the whole Shark range to 'thank' for my career in storage; I had the misfortune to be involved with the VSS and it is that reason alone that IBM continue to be nice to me, they owe me and everyone else involved with that. Then I was one of the first non-IBMers in the UK to be trained on the ESS range; then after a diversion into managing software development teams, I came back to infrastructure to be employed by a company who was kicking out EMC (cost reasons) and replacing with Shark and I was involved in all the pain that brought.
- Late delivery of PPRC over FC
- Strange hacks to enable multiple point in time copies to be taken
- Failed firmware upgrades which left each cluster node at a different level
- Arrays which turned themselves of after a period of time
- DS6000 – enough said
But despite that, it's still a product range that I have a lot of affection for; the ESS 800 is one of the few arrays which we as an end-user managed to tune beyond it's white-paper specs. I still remember the IBM SE's disbelief and his insisting of taking the logs away, getting them analysed and yet more disbelief when he returned with the acknowledgement that we had a Shark performing better than they had got one in their own labs.
And now IBM have launched the DS8800; I was expecting a fairly boring CPU jump and not a lot more but they've done rather more than that and this leads to me to believe that the DS8k has somewhat more life in it than anyone expected.
- 2.5" SAS Drives allowing a high-density foot-print; no SATA or FC at all and no 3.5" drives.
- A redesigned cabinet to allow it to fit in the hot-aisle-cold-aisle data centre.
You see IBM can't afford for the DS8K to die at present; I suspect it would have died if it wasn't for CKD and mainframe connectivity but this requirement keeps it alive and IBM seem to be making the best of a bad situation. I have asked in the past about CKD support in SVC and Barry Whyte does not seem especially positive about any real chance of this happening and so the DS8k lives on and IBM might as well continue to add features to it.
As with the DS8700 release; some features which exist on the DS8700 will only become available on the DS8800 later. I am really not sure about the logic of this and IBM do need to get to a common code-base for the DS8700 and DS8800 pretty soon; why launch an array which is missing features provided in the previous release? Seems madness to me but IBM are not the only ones who succumb to this madness.
I also wonder why IBM never really pushed the envelope on the ability to logically partition a DS8K? Surely this would give them secure multi-tenancy? And they've never delivered on the cogitated TSM integrated into the array itself or running DB2 in a partition on the array? Perhaps this will come as some kind of response to Oracle's database appliances? Hey, they could even run Oracle on it; that'd be amusing!
There's also no reason why the SONAS code base couldn't be ported to AIX; hell, GPFS started on AIX. At that point, IBM could have something which aspired to be unified storage appliance. I do at times wonder if the problem with the Shark range was that there was almost too much potential and IBM got distracted by the potential as opposed to delivery.
Now there are some interesting developments with the DS8K and SVC; the RAID code from the DS8K has made it into the SVC, does this mean that responsibility for it's ongoing development lies with the Hursley team?
I still think that the mid-to-long future of IBM's storage sits firmly with the SVC and related products but the DS8k still seems to have life. This is probably a good thing for the existing customer-base but not such a great thing for everyone else; IBM need to get behind a single product and push it hard! If IBM create a v5000 and v9000 to go with the v7000; they have potential to finally build a compelling, coherent storage story.
IBM need to look at what HP are doing by putting the future of their storage division in the hands of David Scott; with SVC, IBM have a product which like 3Par has technical pedigree but has underperformed in the market. IBM need to find their own David Scott to push them forward.
Hi Martin.
Thanks for creating so many well written blog posts.
You raise quite a few points in this entry, some of which I will try and address in a blog entry of my own. Two points that I want to clarify:
1) The DS8000 device adapter (RAID adapter) development has always been ‘owned’ by Hursley. Those guys did SSA and carried on their long tradition of creating RAID adapters for the ESS(Shark), the DS6000,the DS8000 (all model) and now the Storwize V7000. The only difference with the Storwize V7000 is that they are now merging that technology with the SVC technology they have also always developed, to create a new mid-range storage product.
2) The DS8700 an DS8800 do already share a common code base (known inside development as R5.0). The two products diverged when DS8700 brought out R5.1 while all the hardware changes needed for the DS8800 changed R5.0 into R6.0. IBM took the conservative and safe approach of not trying to force the R5.1 and R6.0 streams back together on day 1. We would rather bring out a boring and safe product on day 1 than an exciting but possibly unstable product. The goal is absolutely to merge them back together, and thats whats R6.1 will do. And thats still pretty exciting.
Cheers for the clarification on point 1, I think I really subconsciously knew that but thanks for the clarification.
And yes, I can see the logic and why the requirement for a temporary fork however it does let certain companies throw rocks. Still, the DS8K can probably stay relatively boring and safe; it’s not a product which is leading the charge for IBM into non-IBM accounts. It’s a better array than most give it credit for but I think even IBM acknowledge selling it into non-mainframe accounts is really hard work.