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