[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: target portal discovery using iSNS versus SendTargets



One question I have is that if the iSNS server is likely to lose access to a portal on an iSCSI target, isn't it also likely that an iSCSI initiator will also lose access to that same portal?  In that case, the iSNS server would be behaving correctly to deregister the unreachable portal.

Use of ESI by iSNS clients is optional.  If you don't wish the iSNS server to depend on your target portal's accessibility via ESI, you could instead proactively transact with the iSNS server before your Registration Period has expired.  A transaction received by the iSNS server from a registered iSNS client will serve to refresh that client's registration.  You would of course need to repeatedly transact with the iSNS server at a time interval less than the client's Registration Period in order to maintain the client's registration in the database, unless you are using ESI instead (an ESI response received by an iSNS server from a registered iSNS client will also server to refresh that client's registration).

Finally, it would be considered prudent for iSNS clients to register for SCNs to be notified whenever there are changes made to registered iSNS clients that the iSNS client is interested in.  For example, an iSCSI client may wish to be notified whenever changes are made to iSCSI targets (which are registered with the iSNS server), and likewise, iSCSI targets may wish to be notified whenever changes are made to iSCSI clients (which are registered with the iSNS server).

----- Original Message ----
From: Paul Hughes <phughes@xxxxxxxxxxxxxx>
To: ips@xxxxxxxx
Sent: Tuesday, June 5, 2007 10:26:02 AM
Subject: target portal discovery using iSNS versus SendTargets

I am concerned that an iSCSI initiator that uses iSNS might not discover all portals of an iSCSI target in some situations.  For example, if the target has registered for ESI monitoring of its portals and the iSNS server loses access to one portal the iSNS server will de-register the inaccessible portal.  During this time if an SCSI initiator queries the iSNS database for the target's portal addresses it will see only those portals that are accessible to the iSNS server even though the initiator may have access to all portals.
 
On the other hand, if the iSCSI initiator used iSNS to obtain one target portal address and then issues SendTargets it would discover all of the portals.  This of course assumes that an iSCSI target should report all of its portals in the SendTargets response regardless of whether the target has knowledge that one of its portals is inaccessible due to a portal hardware failure.
 
I guess what I'm trying to determine is whether iSCSI initiators are expected to query the iSNS database to detect the addition of target portals or whether they only query the iSNS database once during boot or driver initialization.  Does anyone have any experience with some of the more popular iSCSI initiators to comment on this?
 
Thanks,
Paul
 
_______________________________________________
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]

Add to Google Powered by Linux