<   Previous Post  Wordle Blog Map
A step backwards for...  Next Post:   >

Comments (15)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 localhost commented Permalink

"Intelligent Performance Optimization function in Tivoli Storage Productivity Center 4.1 will help identify...."<div>&nbsp;</div> ...using stats that are available from the SVC I assume? Too much integration is just as bad as none at all!<div>&nbsp;</div> I would assume that the SSD's would not form an MDISKGROUP of their own, but would be used to hold 'hot' extents, or smaller elements? Would this be done on an automagic basis, or would you say, flag certain vdisks (or mdisks) to have the potential to use the SDD's?<div>&nbsp;</div>

2 localhost commented Trackback

The initial function in TSPC 4.1 will make use of the SVC stats and highlight hot vdisks.<div>&nbsp;</div> Further enhancements and details of the future functions in this area have not yet been made public.<div>&nbsp;</div> Barry

3 localhost commented Trackback

OK, so NOW we know why you backed down about putting SATA drives into existing storage...<div>&nbsp;</div> And the pre-announcement of putting PCIe-based flash into SVC controllers is interesting (you've been hinting at that for the last 9 months or so).<div>&nbsp;</div> But your assertions that IBM is the first major supplier to offer workload analyis tools to predict which data should be relocated to flash is incorrect - EMC has been supplying end-users and technical consultants with similar tools since we began shipping flash drives on Symmetrix at the beginning of last year.<div>&nbsp;</div> And as to optimizing performance by putting specific tables and indicies into flash, EMC has been doing the same thing all along - and not limited to just DB2 (we have numoerous white papers describing best practices for various applications to help). In fact, one customer took advantage of this approach to reduce the elapsed time of his nightly batch runs by 50%. And the cost of a few flash drives was more than off-set by the avoided costs of a proposed z10 MIPS upgrade. <div>&nbsp;</div> So be careful - your integration of flash may have a detrimental effect to IBM's bottom line :)

4 localhost commented Trackback

I figured you'd have some thoughts. <div>&nbsp;</div> A couple of assertions though. Nowhere does it mention what type of flash we will be using. <div>&nbsp;</div> Maybe my English is bad (no Maybe about it) but the "first major vendor" statements refer to "full disk encryption", "leveraging system-wide research teams" and "vendor putting flash everywhere it makes sense". No-where does it specifically say we are the first to provide "guidance" or "tooling".<div>&nbsp;</div> I think the key point is that IBM is vertically integrated in the stack, through applications, servers, SAN and storage and can therefore leverage flash where it makes sense for each specific customers needs. Thats where the advantage of Tony's "supermarket" vs "specialist" comes to bear again.

5 localhost commented Trackback

Barry,<div>&nbsp;</div> I think you might have mentioned what type of flash you will be using:<div>&nbsp;</div> "...and of course STEC Fibre SSD device support..."<div>&nbsp;</div> Unless you meant using elsewhere.<div>&nbsp;</div> Also, what's the difference (practically, not technically) between FATA and SATA behind a FS to SATA bridge?<div>&nbsp;</div> I'm eager to learn more about SVC's SSD capabilities. I'll be waiting for future announcements!<div>&nbsp;</div> Stephen

6 localhost commented Trackback

Stephen,<div>&nbsp;</div> The Fibre SSDs mentioned are in the DS8000, not SVC.<div>&nbsp;</div> Practically the difference is that any qualified SATA drive can be used behind the bridge, rather than having a native FATA onboard the drive, so you aren't stuck to the limited (and now almost non-existent) vendors producing FATA interfaced HDD.<div>&nbsp;</div> More info will follow in due course :)<div>&nbsp;</div> Barry<div>&nbsp;</div>

7 localhost commented Trackback

hi barry,<div>&nbsp;</div> congrats on the announcements, especially the SSD. im chomping at the bit to get my hands on some SSD in a USP-V..... im thinking that another vendor shipping them should increase demand and all the good stuff that generally drives proces down.<div>&nbsp;</div> and there was me believing barry burke that the ds8000 was on the verge of death. last time i believe anythinghe says ;-)<div>&nbsp;</div> actually are you sure your hiding something from us? you sure you're not rebadging the USP-V and calling it a DS8000. actually thats a good idea :-D<div>&nbsp;</div> oh and at least now you can strut around the locker room that is the storage blogsphere with a bit more pride :-S<div>&nbsp;</div> nigel

8 localhost commented Trackback

BarryB,<div>&nbsp;</div> &gt;But your assertions that IBM is the first major supplier to offer workload analyis tools to predict which data should be relocated to flash is incorrect<div>&nbsp;</div> Just realised the comment you are referring to - sorry, and corrected in the main body.<div>&nbsp;</div> Barry

9 localhost commented Permalink

It is lovely to read a post like this, great future is in front of us! When looking to the roadmaps and reading this post I can't wait to start working with the new features.<div>&nbsp;</div> I am already using TPC at the moment to monitor the storage behind SVC, companies that have a "slow" storage subsystem and a "fast" storage subsystem now already are live migrating vdisk to their needs, when there will also come an "Ultra Fast" storage capacities, there will be great advantages and time savings!<div>&nbsp;</div> The deduplication part is also very interesting, I hope this will be a "on the fly" dedeplication, because there are already vendors with "human interaction" deduplication but this is a moment of stress for the full storage environment.<div>&nbsp;</div> Kind regards<div>&nbsp;</div> Joeri

10 localhost commented Permalink

"Further enhancements and details of the future functions in this area have not yet been made public. "<div>&nbsp;</div> Bah humbug. I guess I will just have to wait, or pop round to Hursley and pester you guys.<div>&nbsp;</div> For the stats I was just making sure that TPC was simply making use of existing SVC statistics to perform it's problem determination, and not doing any special juju behind the scenes. I don't use TPC (and have no plans to), but I do make heavy use of the SVC statistics, so enhancements in this area are always of interest.<div>&nbsp;</div> Keep up the good work.<div>&nbsp;</div>

11 localhost commented Trackback

So, explain me this:<div>&nbsp;</div> The minimum # of SSDs on a DS8K is 16 (at a list price of $1.6M - more than a bare-bones DS8K itself, but that's not my question). Of the 16, only 14 are usable (mandatory 2 spares), and the entire unit of 16 must be installed as a whole on a single pair of back-end controllers.<div>&nbsp;</div> My calculations say that 3 SSDs can deliver more 4K read IOPS than a DS8K back-end controller pair can support, and ONE SSD can support more 4K write IOPS than that pair can deliver. And about 5 SSDs deliver more large-block bandwidth than the DS8K can deliver through a single back-end controller pair.<div>&nbsp;</div> You've pounded me for a year about this - so how do you explain it now that the shoe is on your own foot?<div>&nbsp;</div> And don't go telling me my math or my measurements are wrong ('cuz I'm sure you actually have the same numbers as we're getting on our DS8Ks)...

12 localhost commented Trackback

Have you ever given me an answer? Other than improved response time benefits... No. So the answer to you is the same.<div>&nbsp;</div> Max IOPs are only going to be available with a dedicated SSD platform / solution - like what we are doing with SVC.<div>&nbsp;</div>

13 localhost commented Trackback

Wah!<div>&nbsp;</div> So the truth is revealed - you've been Flinging FUD about Flash and SATA for a year, and here we finally find your DS8K developers have almost caught up with where DMX was a year ago.<div>&nbsp;</div> And now your only response is some unspecified implementation of Flash on SVC, and this is supposedly going to perform better than your vaunted DS8K "enterprise" storage platform.<div>&nbsp;</div> Yet you still try to convince the world that the DS9K isn't dead? <div>&nbsp;</div> It seems pretty obvious that the SVC and the XIV development teams are moving to the front of the IBM feeding trough...at least, you're both probably getting 3-5X the development resources (flash ain't cheep), leaving barely enough for the DS8K to keep breathing!<div>&nbsp;</div> Still, if you they can get away with charging $1,600,000US for 16 146GB SSDs, then maybe there'll be enough margin to keep the lights on (but given the poor back-end performance of the DS8K, I sincerely doubt it).

14 localhost commented Trackback

Hang on just a second.<div>&nbsp;</div> I have never claimed that these devices will be the be-all-and-end-all of IOPs throughput. I have always stood by the need for a new way of thinking about storage when it comes to SSD, and thats what we are doing. At the same time we are putting them into our Enterprise storage arrays as we can get an incremental benefit from them, just as your customers have, those that need the better response time, and increased throughput will get those gains. No solution today is able to saturate the iops of all these drives, the same is true for DMX - I've got your presentation, and can see your limits too. <div>&nbsp;</div> As for price, list prices are one thing - does anybody pay list? <div>&nbsp;</div> It may surprise you that SVC development is efficient, you need to have a briefing from me to understand how a modern storage solution (that doesn't have to put up with legacy META luns and a "unique" RAID solution, keep all the old Symm architecture for BVCs etc etc) can be modular, even in the code design. It will be interesting with DMX-5 if you can finally break away from META's and the like, but then thats a nice cash cow for you, charging a user to configure the box they have already paid for - how much longer can you get away with that?!<div>&nbsp;</div> Ultimately, coming back to your comments, I think we need to provide a distinction between FUD and TRUTH. Everything I have said is not FUD, its the TRUTH. Now you are trying to turn it back to FUD, and I'm answering back with the TRUTH.<div>&nbsp;</div> And hey, I'm just the SVC dude ... ;-p

15 localhost commented Trackback

As TonyP pointed out to me last year, the truth indeed can be FUD, and vice-versa. I'll refer you to his blog on exactly that topic; you now are guilty of the same thing he's charged me with - using the truth to create fear, uncertainty and doubt in the minds of our readers.<div>&nbsp;</div> I'm just pointing out that all the negatives you raised for the last year against DMX using SSDs and SATA are now also negatives against DS8K using SSDs and SATA - except that the upper IOPS and MB/s limits on the DS8K are even lower than on DMX.<div>&nbsp;</div> As to the myth you try to foster about charging for reconfigs - that's actually a customer choice. EMC offers all the tools necessary for the customer to perform virtually all of her own reconfigurations, should she so choose. But not all customers feel that their own change control is sufficient for their most mission-critical data, and so they elect to enlist EMC assistance (gives them someone to blame when things go wrong, I guess).<div>&nbsp;</div> Alas, it seems that the Anti-EMC crowd still loves to drag up historical limitations and past transgressions in their quest to dethrone EMC in the minds of blog readers. <div>&nbsp;</div> But the fact is, today's Symms bear little actual resemblance to the Symms of old. Sure, you can get all tangled in CLIs and Hypers and Metas if you'd like, but you can also deploy your DMX as a fully-thin provisioned array managed by a logical and easy-to-use GUI, and thus sidestep all of those messy physical/logical mapping concerns you so like to point out.<div>&nbsp;</div> Oh, and I suspect that a customer can buy Flash capacity from EMC for lower $/GB than that offered by IBM (or HDS, for that matter). And I'm almost positive we're selling the same drives :)