[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: No Framing

    Although it will be true large amounts of bandwidth will be exchanged
    between the typical SAN, such systems also use cache due to mechanical
    limitations with respect to rotation and linear access.  If it were just
    storage to storage, Fibre-Channel or FC encapsulation would be preferable.
    At least with that scheme, there are direct placement interfaces available.
    Direct placement is needed with low latency high bandwidth to reduce
    overhead lost during a subsequent memory copy.  SCTP offers a means of
    implementing direct placement without kludging a portion of the application
    beneath the transport.  In addition, this direct placement scheme can be
    done in an general fashion to support thousands of higher level protocols.
    As with most SAN, network related failures are not well tolerated, so the
    added robustness of SCTP becomes highly beneficial.
    In establishing a large remote mirror, the highest bandwidth means of
    initialization would be physical transport of the image.  Once initialized,
    only differential information is exchanged largely limited by the bandwidth
    and error rate of the interconnect.
    > De-lurking...
    > Right now, I'd say disk-disk backup/restore and mirroring.  The individual
    > disk devices of today can perform at ~70 MB/s.  One need only gang 14 of
    > these together, streaming, to reach nearly 1000 MB/s, or 1 GB/s,
    > or 8 Gb/s.
    > The disk devices of tomorrow are going to perform at rates approaching 100
    > MB/s per spindle.  Only ten devices are then necessary.
    > This would be a single TCP stream (one initiator, one target, many LUs).
    > If one has to mirror (/move) 10 TB in a reasonable amount of
    > time, say, then
    > a stream of 1 GB/s is not only necessary, but paramount.  Even at
    > that rate,
    > it would still take nearly three hours to move just 10 TB.  In a
    > business-critical recovery situation, three hours is an eon.
    > Don't think application (CPU/memory in a server) to storage.
    > Think storage
    > to storage.
    > Rob
    > Rob Peglar
    > Corporate Architect
    > XIOtech Corporation, a Seagate Company
    > (314) 308-6983


Last updated: Mon Feb 04 14:18:00 2002
8618 messages in chronological order