SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI virtualization proposal


    • To: ips@ece.cmu.edu
    • Subject: Re: iSCSI virtualization proposal
    • From: "John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>
    • Date: Thu, 12 Oct 2000 11:16:08 -0700
    • Content-Transfer-Encoding: quoted-printable
    • Content-type: text/plain; charset=iso-8859-1
    • Importance: Normal
    • Sender: owner-ips@ece.cmu.edu

    Yaron,
    Jim has a valid point that this is not iSCSI focused.  I see this as a
    Third Party Virtualization, of which a number of companies have such
    products out today.  They also have special host code to support this, as
    you will need here.   But more to the point, it is not iSCSI specific and
    therefore should be pursued with T10.  If that Standard is established,
    then and then only, we should consider it as part of iSCSI.  Lets keep this
    out of our discussion on Gateways, Proxies, etc. it does not fit there.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    (408) 256-0403, Tie: 276-0403
    Internet address: hufferd@us.ibm.com
    
    
    Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/12/2000 10:35:47 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Yaron Klein <klein@eng.tau.ac.il>
    cc:   ips@ece.cmu.edu
    Subject:  Re: iSCSI virtualization proposal
    
    
    
    
    Yaron,
    
    Is this something specific to iSCSI or more general (e.g., applicable to
    SVP or FCP or even parallel)?  If so, I would suggest that this is an issue
    for T10.
    
    Additionally, this can be interpreted in some sense as the initiator being
    a copy manager and receives (as a target) from the manager (now an
    initiator) an  EXTENDED COPY command in which the destination of the data
    is the initiator. This point of view  changes the sematics a bit (and
    doesn't quite fit the suggestion from Charles to pass status back through
    the manager).  Do we get the same net function this way? Is there anything
    that iSCSI needs to do?  Can it all be accomplished with implementations
    within the existing spec?
    
    I honestly don't know the answer to these questions (as I haven't really
    thought about this that hard).
    
    Jim Hafner
    
    
    Yaron Klein <klein@eng.tau.ac.il>@ece.cmu.edu on 10-12-2000 02:54:12 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  iSCSI virtualization proposal
    
    
    
    Proposal for iSCSI virtualization:
    
    The problem:
    
    In order to implement iSCSI virtualization in a local network, we need the
    following topology:
    
      -----------
      |
      | host    |
      |
      -----------
    
    
    
    ---------------------------------------------------------
         |              |                |
         |              |                |
         |              |                |
    ----------      ----------      ----------      ----------
    |        |      |        |      |        |      |
    | Manager|      | Disk A |      | Disk B |      | Disk C |
    |        |      |        |      |        |      |
    ----------      ----------      ----------      ----------
    
    When the host is an iSCSI initiator, the disks are iSCSI targets and the
    manager is with iSCSI target port to the host and iSCSI initiator port to
    the disks.
    
    The host considers the manager as a "flat" disk space with iSCSI port and
    is unaware of the disks. The manager manages the disks in some algorithm to
    construct a combined virtual volume.
    
    Consider the following example:
    
    Each disk contains 1000 blocks. The virtual volume is thus 3000 blocks. The
    hosts sends an iSCSI command to the manager to read 40 blocks from address
    500. The physical addresses are: A ? 400:409, B ? 300:319 and C ? 600:609.
    
    In the current iSCSI protocol, the traffic scenario is:
    
    Host -> manager: iSCSI command, read from 500 size 40.
    Manager -> A: iSCSI command, read from 400 size 10.
    A -> manager: iSCSI data.
    A -> manager: iSCSI status.
    Manager -> host: iSCSI data.
    Manager -> B: iSCSI command, read from 300 size 20.
    B -> manager: iSCSI data.
    B -> manager: iSCSI status.
    Manager -> host: iSCSI data.
    Manager -> C: iSCSI command, read from 600 size 10.
    C -> manager: iSCSI data.
    C -> manager: iSCSI status.
    Manager -> host: iSCSI data.
    Manager -> host: iSCSI status.
    
    Problem 1: Traffic on the line is double! Each data packet is transferred
    twice (from disk to manager and from manager to host).
    
    Problem 2: The manager is a bottleneck. Both data and commands of all the
    system (assuming many hosts and disks) is transferred via it.
    
    Solution:
    
    Lets add in the iSCSI status message, in the "iSCSI status" field, the
    following option:
    
    2 - iSCSI reflection
    
    Which means that the status contains add-ons of iSCSI command that the host
    should implement. These commands will implement the original request. In
    our example it will look as:
    
    Host -> manager: iSCSI command, read from 500 size 40.
    Manager -> host: iSCSI status (with reflection), iSCSI commands (for A, B
    and C)
    host -> A: iSCSI command, read from 400 size 10.
    A -> host: iSCSI data.
    A -> host: iSCSI status.
    host -> B: iSCSI command, read from 300 size 20.
    B -> host: iSCSI data.
    B -> host: iSCSI status.
    host -> C: iSCSI command, read from 600 size 10.
    C -> host: iSCSI data.
    C -> host: iSCSI status.
    
    Benefits:
    
    * Data traffic on the line is single.
    * No bottleneck on the manager.
    
    
    Note: The manager is a software pack. It can be an independent unit, in the
    host or in one of the disk. It is just schematically stated as independent
    unit.
    
    In conclusion, the addition of the reflection feature in the protocol is
    minor change, can be optional and will enable the enormous potential of
    virtualization.
    
    Comments are more than welcome,
    
    Yaron Klein
    SANRAD
    
    klein@sanrad.com
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:41 2001
6315 messages in chronological order