Re: iSCSI virtualization proposal

[julian_satran@il.ibm.com]

Yaron,

I like the idea but am not so sure about the solution.

BTW this is the way at least one Volume manager works and many
Raid controllers.

The reflection at each command is cumbersome.

Getting to know the volumes you are talking to is a one-time operation
unless you want every operation to have a new mapping and the later
makes very little sense to me.

And if for some reason you are interested in "continuous virtualization"
a 3 party scheme would make more sense.

Julo



Yaron Klein <klein@eng.tau.ac.il> on 12/10/2000 12:54:12

Please respond to Yaron Klein <klein@eng.tau.ac.il>

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