|
|
Title:
Caitlin Bestler wrote:
On Tuesday, July 15, 2003, gilligan@intransa.com wrote:
Hi - If you are using redirect to implement fault
tolerance/load balancing as we sketched out in
draft-gilligan-iscsi-fault-tolerance-00.txt, there may be
transients when an initiator gets redirected multiple times.
For example, say A redirects the initiator to B. But say B has
more recent information about the actual location of the
target, so it redirects the initiator to C. Eventually A
learns the same information as B and then redirects initiators
directly to C. So the initiator should be prepared to accept
some number of consecutive redirects.
Of course, if the redirection goes on indefinitely or loops - say A
redirects to B, which redirects to C, which redirects to A, etc. - that
probably does represent either a configuration error or a bug. So the
initiator may wish to detect a redirection loop or an excessive number
of redirections.
But, as you point out, what represents "excessive redirection"
is in the eye of the initiator. So, I don't think that the
main iSCSI spec needs to call out a specific hard limit.
In order to cover the type of fault-tolerance scenario you cited
wouldn't it make sense to set a minimum that the initiator SHOULD
be willing to accept?
That way cluster builders would have a base that they could assume
would not result in iniator failures (only delays).
Yes, it would be good to have some sort of minimal redirect/retry behavior
specified, but I'm not sure that it necessarily needs to be specificied in
terms of a minimun number of redirects to accept. It might be more natural
to define it in terms of time: how long an initiator should try to login
to a target (in the face of multiple redirects) before giving up and notifying
the upper layer. However it is implemented, it would also be desirable for
the initiator to make this count or interval configurable so that it can
be tuned for use in different environments.
Bob.
Home
Last updated: Tue Aug 05 12:46:12 2003
12771 messages in chronological order
|