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

    RE: iSCSI: No Framing

    >-----Original Message-----
    >From: Douglas Otis []
    >Sent: Monday, February 04, 2002 11:37 AM
    >Subject: 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 
    >At least with that scheme, there are direct placement 
    >interfaces available.
    Without bogging down the list in a debate about storage subsystems, I must
    say that there are examples to the contrary w.r.t. the usage of subsystem
    iSCSI is, of course, more than just storage-to-storage.  But we should not
    limit iSCSI to just host-to-storage.  Remember, storage subsystems can (and
    are, in some cases) both initiator and target at the same time.
    The original thread began with a question (paraphrased) about '...what
    applications could consume a 10G pipe for long periods of time'.  I answered
    that question - disk-disk backup and subsystem replication.
    FC is not sufficient.  Storage-to-storage needs all the advantages as well
    as that which iSCSI has to offer the host-storage model.
    >Direct placement is needed with low latency high bandwidth to reduce
    >overhead lost during a subsequent memory copy.
    This assumes 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.
    Having read this list since its creation, I choose to not participate in the
    SCTP/TCP religious war.  
    >In establishing a large remote mirror, the highest bandwidth means of
    >initialization would be physical transport of the image.  Once 
    >only differential information is exchanged largely limited by 
    >the bandwidth
    >and error rate of the interconnect.
    Well put.  Consider 3-10 TB of differential per day as a start.  Consider
    images of 100s to 1,000s of TB, spread across 100s to 1,000s of 15KRPM (or
    more, stay tuned) spindles.  Now, we're talking.
    Rob Peglar
    Corporate Architect
    XIOtech Corporation, a Seagate Company
    (314) 308-6983
    >> 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: Tue Feb 05 23:17:59 2002
8660 messages in chronological order