Re: Portal group discovery

Dan,

I see your failover problem similar to failover to a simple FC drive. It has two SCSI ports and, using dual loops, the initiator can fail over from one port to the other. If you expose two different TPGs then you similate exactly this method because a TPG is simply a SCSI Port.

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: Dan Bar Dov 
  Cc: [email protected] ; William Studenmund ; John Hufferd 
  Sent: Wednesday, October 04, 2006 3:03 PM
  Subject: RE: [Ips] Portal group discovery



  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" <[email protected]> 
        03/10/06 12:00 
       To <[email protected]>  
              cc "John Hufferd" <[email protected]>, Julian Satran/Haifa/IBM@IBMIL, "William Studenmund" <[email protected]>  
              Subject RE: [Ips] 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:[email protected]] 
  Sent: Friday, September 29, 2006 8:05 AM
  To: William Studenmund
  Cc: Dan Bar Dov; [email protected]
  Subject: Re: [Ips] 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 <[email protected]> 
        29/09/06 05:31 
       
              To Dan Bar Dov <[email protected]>  
              cc [email protected]  
              Subject Re: [Ips] 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
  [email protected]
  https://www1.ietf.org/mailman/listinfo/ips




------------------------------------------------------------------------------


  _______________________________________________
  Ips mailing list
  [email protected]
  https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips