SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: LU access through an iSCSI session



    
    Pierre,
    
    The answer to your questions (in my mind) are:
    
    > 1) Do commands directed to a particular LU through a session are
    > able to use any of the TCP connections within the  session?
    
    I think this should be "Yes" and is a very desirable design point (but I
    don't know if that's what we're going to get).
    
    
    > 2) Do commands directed to a particular LU through a session
    > need to be associated to different LUNs depending on the TCP
    > connection used or is it always the same LUN for all
    > the connections?
    
    This has a more complicated answer, namely: *it depends*.  Vendors can
    implement what they like, so in some of today's FC devices, the answer is
    that you might get different LUNs on different ports.  Though, in that
    case, it's not clear if different ports are conceptually connected in
    anything that resembles an initiator/target session.  The "same LUN for all
    connections" was a hoped-for side effect of the SCSI access controls model,
    since in that model, LUN Maps are defined per initiator, regardless of port
    connection.  If the initiator in an I_T nexus is coalesced across multiple
    connections, then you should see this.  On the other hand, the model
    doesn't preclude more complex implementations and other behaviour.  Such
    implementations would not necessarily be contrary to the SCSI standards
    (they are silent on this point) but would definitely be extra-standard.
    
    I agree with you that this behaviour is undesirable for many reasons, but
    there's nothing to inhibit it except market forces (I think).  I don't
    think IETF through iSCSI can mandate this behavior particularly since T10
    through SAM/SPC doesn't.
    
    Also, I agree with your assessment of the situation.
    
    Jim Hafner
    
    
    Pierre Labat <pierre_labat@hp.com>@ece.cmu.edu on 09-19-2000 10:44:06 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  LU access through an iSCSI session
    
    
    
    Julo,
    
    
    Thinking about what could be an implementation of an iSCSI
    session, several questions came to my mind for which
    i was unable to find an answer in the draft.
    
    1) Do commands directed to a particular LU through a session are
    able to use any of the TCP connections within the  session?
    
    As the TCP connections could connect to various "service delivery ports"
    it is
    not guarantee that a particular LU is visible through all the
    connections.
    
    
    2) Do commands directed to a particular LU through a session
    need to be associated to different LUNs depending on the TCP
    connection used or is it always the same LUN for all
    the connections?
    
    As the TCP connections could connect to various "service delivery ports"
    
    of the target, it seems that the LUN could differ depending on the
    connection used.
    In the iSCSI draft in 2.2.1 there is:
    "The group of TCP connections linking an initiator with a target forms
    a session (loosely equivalent to a SCSI nexus)." Does it means that
    the same LUN is used across the TCP connections?
    
    Depending on the answer to these questions the failover/load balancing
    can
    be handled in different ways:
    
    
    -> If the answer for 1)  is "All TCP connections can be used" and
    the answer for 2) is "Same LUN regardless of the connexion"
    
    For fail over and load balancing inside a session, there is no need to
    work
    at the (thin) LU granularity,  working at the granularity of the TCP
    connexion is sufficient. For example in case of failed TCP connexion
    all the traffic for this failed TCP connexion can be directed on the
    other
    connections regardless of the LU. It is very quick, straight forward
    and may add value compared to the legacy solutions that are doing
    the fail over on a LU basis (one LU command returns an error or
    timeout, the next commands for this LU will use an alternate path)
    In the case where a large number (N) of LUs access are multiplexed to
    a target port, N switch over are needed.
    The same result could be achieved in one operation (TCP connection
    switch over).
    
    -> If the answer for 1)  is "All TCP connections can be used" and
    the answer for 2) is "different  LUN depending on the connexion"
    We need to work at the LU granularity. For each command the
    right LUN as to be determined depending on the tcp connection
    selected.
    
    -> If the answer for 1) is "not all TCP connections can be used, it is
    LU dependent"
    On top of the previous case extra work, for each LU  it must be a list
    of
    TCP connections usable that needs to be looked into before routing
    the command to one TCP connection.
    It means that some LUs access using a session could survive
    to a TCP connection failure some other LUs no.
    
    
    Regards,
    
    Pierre
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:07:11 2001
6315 messages in chronological order