RE: Portal group discovery
I guess my confusion with portal group is fully
understanding the way it is
supposed to be used.
When a portal group is used for multiple connections in
session,
the cmnSN must be monotonic and shared among all the ports-
so this indeed is a shared state, and it cannot work with
multiple routers.
However, if all I want to achieve is multipath fail-over, I
can have multiple sessions,
or MCS - but with only one session active. In both cases,
the initiator can use an
alternative session or connection, and the cmdSN will
advance just fine.
From all the answers, I understand now that
portals are indeed for MCS, and failover
using multiple devices such as routers, needs to use
multiple sessions (active+standby),
and that distinct devices, even providing the
same service - access to same "real target",
should not, and must not be part of the
same portal group.
Dan
Dan,
The portal groups have to share more than a target name
- they'll have to have some common state (the CmdSN etc.).
If behind the routers there is only the "real" FC
target I don't see how you can build a portal out of several routers. If the
target function is in the "real target" it might as well know who all its
front-ends are.
Julo
| "Dan Bar Dov"
<danb@xxxxxxxxxxxx>
03/10/06 12:00
|
|
To
| <ips@xxxxxxxx>
|
|
cc
| "John Hufferd"
<jhufferd@xxxxxxxxxxx>, Julian Satran/Haifa/IBM@IBMIL,
"William Studenmund" <wrstuden@xxxxxxxxxxxxxxxxx>
|
|
Subject
| RE: Portal group
discovery |
|
Let me try to explain how it can and does happen.
Our
iSCSI target device is a "gateway" (or router). It provides FC SAN
targets to iSCSI SAN. The iSCSI
target name is generated from the FC WWNN.
When there are
more then one such routers in the iSCSI SAN, it is possible and normal
for two (or more) iSCSI routers to
expose the same FC target. This is not by mistake,
rather, it allows fail-over between such routers, where the
initiator uses the multiple portals
for failover.
Given such a configuration, how does the
initiator discover it?
option 1:
the routers have "cluster awareness", one router can combine information from
the whole
router cluster for
sendTargets response.
option 2:
the initiator is configured with multiple discovery addresses - one per
router.
If option 2 is used, then the initiator needs to combine information
discovered in discrete sendTargets
responses and produce portal groups.
My question
relates specifically to that situation - it is not clear from the iSCSI spec,
if such failover
between portals
(with the same pgt) discovered in discrete sendTargets responses is
allowed.
Thanks,
Dan
From: Julian Satran
[mailto:Julian_Satran@xxxxxxxxxx]
Sent: Friday, September 29, 2006
8:05 AM
To: William Studenmund
Cc: Dan Bar Dov;
ips@xxxxxxxx
Subject: Re: Portal group discovery
This is not supposed to
happen (getting partial data in a session)
If it happens it can be the result of a
reconfiguration (between the two discovery sessions).
Julo
| William Studenmund
<wrstuden@xxxxxxxxxxxxxxxxx>
29/09/06 05:31
|
|
To
| Dan Bar Dov
<danb@xxxxxxxxxxxx>
|
|
cc
| ips@xxxxxxxx
|
|
Subject
| Re: Portal group
discovery |
|
-----BEGIN PGP SIGNED
MESSAGE-----
Hash: SHA1
On Sep 28, 2006, at 7:59 AM, Dan Bar Dov
wrote:
> Is it allowed for an initiator to create a single portal
group from
> information
> collected from two (or more)
sendTargets discovery sessions?
I don't think you need two or more
SendTargets discovery sessions.
You are supposed to hear about all
portals in one SendTargets
response, so it's supposed to all be
there.
If you had very separate off-load cards, I could see that not
being
followed. But then chances are you can't have a session span
said
cards anyway. :-)
Take care,
Bill
-----BEGIN
PGP SIGNATURE-----
Version: GnuPG v1.4.1
(Darwin)
iD8DBQFFHIV8DJT2Egh26K0RAtMRAJ0aABo+mr7HRWRf5ClX44sB15uSAACglrL7
oBLBpnH9PMvBjyu4RS+9dcc=
=3dI5
-----END
PGP
SIGNATURE-----
_______________________________________________
Ips
mailing
list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]
