"I'll ignore the fact that no SANE enterprise shop would elect to store files that size on disk, unless they had frequent need for fast data access to it."
Sector, therein my lie the crux of this discussion: You appear to be refusing to accept, or you regard it highly unlikely that, such an online storage environment can exist. I hope that's not the case, because if it is you have just eliminated one of the most influential drivers behind the future sales of all memory and dwdm that exists today.
The fact is simply this, that I'm directly involved with several such beasts right now, and they are growing, as we type. They are real.
Another assumption which you incorrectly make, IMO, is that the ESCON attached memory unit needs necessarily to be a part of the mainframe. It can be, and most often is, attached to LPARs in the mainframe under the same director-ship as other mainframe channel resources, but it does not have to be the same ESCON director, nor does it necessarily even have to be attached to the same system.
More to the point, however, is that when storages of the types we are discussing here, with the same kinds of transfer requirments we have been discussing, such as an online realtime data repository or archive, can be free standing and operating under a seperate mid range -based "open systems platform," and almost entirely divorced from the mainframe except for I/Os which are needed to transfer processed data into them.
It can be free standing, allowing all of the ESCON-like director activity to be devoted to memory transfer, only, eliminating the worries associated with the sharing you cited. (Actually, the storage companies and the channel extension companies have their own directors in many cases.) The storage complex is separate and distinct from the main frame itself, in other words..
Note that I am not trying to prove that any single environment can scale to 300 GB/Sec speeds intrinsically within a single second of time. I never stated that. I am working under the assumption that enough transfer can take place to accommodate such a file size as 300 GB or greater over very high speed links in an acceptable time frame, as dictated by the economics of the situation and what the company could afford. If I can stream out ten FC or GbE feeds at 1 Gb/s each, then that is 10 Gb/s which would be suitable for an OC-196 line.
Such a line, if it were available and affordable for use with the proper interface, could deliver the payload in less than an hour. This could in fact be done using parallel lines, but the cost is still prohibitive in cross country venues, nonetheless, even for the most affluent enterprises at this time.
Since such a line interface is unlikely at this time, one would scale back to a single or a couple of FC or GbE ports, and derive a channel speed more conducive to an OC-12 which will take several hours, instead of a single hour or several seconds, to execute.
If I design my data storage complex correctly with these requirements in mind, then I am not concerned with all of the weak links within a server farm environment or within a data center. I am only concerned about transferring data from a stand alone active archive or other disc-based storage entity to a distant like entity. The weak links you've mentioned go away in this case, if I have taken the steps I've mentioned, and avoid taking circuitous routes all over the SAN or LAN, and avoid the effects of the mainframe channel's own contention.
Your statements about the impossibility or improbability at this time of sustaining these kinds of rates even with SR speeds are largely irrelevant. I am aware of at least several situations where clients will be doing this routinely, in another couple of months, using multiple dynamically varying [bandwidth on demand, in effect] T3s and OC-n's, several times per day. And in these cases the carrier will obviously not be using SR at this time.
The expected times to completion across the WAN for these multi-hundred GB flows are each rated at between six and ten hours apiece. We're scaling one of them to be capable of a TB load next year. Not quite real time, but they will do for disaster preparedness purposes, and for remote localization of file sharing, until something more affordable comes along than the OC-n pricing structures which are available today.
In your closing statement you make a point which appears to be in rebuttal to something I stated, but the fact is that these are your own assumptions that you are rebutting, not mine.
"I repeat. It will be years before we can ROUTINELY transfer that much data from a storage device, across bus/channels, at a SUSTAINED rate approaching Silkroad speeds."
Like I stated, for the transmission time frames which have been deemed acceptable (hours, not seconds) these capabilities are already on the books, and they will be routine very soon. With, or without, SR speeds.
Regards, Frank Coluccio |
