RE: iSCSI virtualization proposal

["Mark Bradley" <markb@indstorage.com>]

This virtualization would make this more generally applicable, however,
and is NOT on the this in the charter of this WG of things 'not to be
worked on'.
  --  markb

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> John Hufferd/San Jose/IBM
> Sent: Thursday, October 12, 2000 12:16 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI virtualization proposal
>
>
> 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
>
>
>
>
>
>