RE: iSCSI virtualization

[Robert Snively <rsnively@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@eng.tau.ac.il]
>  Sent: Friday, October 13, 2000 4:10 AM
>  To: ips@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@sanrad.com
>  
>  
>  


-----
Message-ID: <39E58A44.17926940@eng.tau.ac.il>
From: Yaron Klein <klein@eng.tau.ac.il>
To: ips@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@sanrad.com