iSCSI virtualization
Charles Monia
cmonia at NishanSystems.com
Fri Oct 13 11:34:55 PDT 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* Charles Monia <cmonia at NishanSystems.com>
*
Hi:
Whether or not this is a T10 issue is a matter of opinion. In my opinion,
it's not.
In any event, I vote for taking this off the table.
Charles
> -----Original Message-----
> From: Robert Snively [mailto:rsnively at Brocade.COM]
> Sent: Friday, October 13, 2000 8:17 AM
> To: 'Yaron Klein'; ips at ece.cmu.edu; T10 Reflector (E-mail)
> Subject: RE: iSCSI virtualization
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Robert Snively <rsnively at Brocade.COM>
> *
> Actually, the matter is T10 and T10 only. It appears to
> be based on some IEEE work that provided a mass storage model,
> modified for implementation on SCSI. T10 has not yet spent much
> time on this and the mass storage model has been constrained
> by its performance characteristics to some specialized
> image filing markets, but the principles are sound enough.
> The IEEE standards that are somewhat relevant are:
>
> 1244.1 Architecture/Data Model
> Geoff Peck (principal), Curtis Anderson, Joel Williams,
> Murali Sathyanarayana
> 1244.2 Session Security, Authentication, and Initialization Protocol
> Bruce Haddon (principal 2000-), Jan Klier (principal
> 1997-2000),
> Curtis Anderson, Joel Williams
> 1244.3 Media Management Protocol
> Murali Sathyanarayana (principal), Curtis Anderson,
> Joel Williams
> 1244.4 Drive Management Protocol
> Joel Williams
> 1244.5 Library Management Protocol
> Joel Williams
>
> I would propose that T10 define a scripting block similar to
> the EXTENDED COPY scripts that could be returned to an initiator
> from a directory management device. The initiator could then
> execute the
> returned script to obtain the desired data directly from the
> actual location of the data. That SCSI tool would allow any
> SCSI transport layer to support this behavior.
>
> Note that this architecture trades an additional
> access and search operation against the efficiencies of direct
> data delivery. This performance tradeoff is not a clear cut
> win for either option and will depend on the configuration,
> SCSI transport technology characteristics, and
> types of transactions being performed. That is one of many
> reasons that
> host- and controller-based RAIDs have remained popular in spite of
> the availability of the alternative approach.
>
>
>
> > -----Original Message-----
> > From: Yaron Klein [mailto:klein at eng.tau.ac.il]
> > Sent: Friday, October 13, 2000 4:10 AM
> > To: ips at ece.cmu.edu
> > Subject: RE: iSCSI virtualization
> >
> >
> > Jim and John:
> >
> > The matter is iSCSI and iSCSI only. The title should be:
> >
> > Encapsulation of piggyback (SCSI) commands in the iSCSI protocol.
> >
> > And the virtualization is just one example of the benefits of this
> > encapsulation option. Many other examples can be found (as Julian
> > mentioned and more: smart proxies, virtual caches, smart
> > mirroring etc).
> > My main request from the WG is to add the option: "iSCSI
> > reflection" in
> > the iSCSI status (note again: iSCSI matter) in the status message.
> >
> > Charles:
> >
> > It looks as there are some applications that will require
> > the status to
> > be sent first to the manager (i.e., not to the initiator) or
> > to both the
> > initiator and the manager. I guess there are to ways to set it:
> >
> > 1. In the negotiation phase, set it permanently, or
> > 2. In the iSCSI command, add another bit to determine to who
> > the status
> > should be sent (initiator, manager or both).
> >
> > But first you should help me to convince the group to insert the
> > piggyback option to the protocol and than we will battle for
> > the status
> > issue.
> >
> > Regards,
> >
> > Yaron Klein
> > SANRAD
> > klein at sanrad.com
> >
> >
> >
>
>
> -----
> Message-ID: <39E58A44.17926940 at eng.tau.ac.il>
> From: Yaron Klein <klein at eng.tau.ac.il>
> To: ips at ece.cmu.edu
> Subject: iSCSI virtualization proposal
> Date: Thu, 12 Oct 2000 02:54:12 -0700
> X-Mailer: Internet Mail Service (5.5.2650.21)
>
> 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 at sanrad.com
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list