Routing path between real servers in different LVS clusters.

pb <[email protected]>
Newsgroups gmane.linux.redhat.piranha
Message-ID <[email protected]>
Hello all,

I have a question on how LVS does routing,
specifically in a situation that I describe below.

We have two clusters (A) and (B) below:

(A)
        EMAIL-LVS
         /     \
 EMAIL-REAL1  EMAIL-REAL2

(B)
            LDAP-LVS
          /     |    \
LDAP-REAL1 LDAP-REAL2 LDAP-REAL3


All SMTP (sendmail) requests to EMAIL-LVS do an LDAP
AUTHENTICATION to LDAP-LVS.   There are two
possible routing paths, and I need to know
which one LVS actually does....

INITIAL ROUTING GOES LIKE THIS:

PC==>EMAIL-LVS==>EMAIL-REAL1==>LDAP-LVS==>LDAP-REAL1


BUT ONCE THE ABOVE ROUTING OCCURS, ONE OF TWO THINGS
COULD HAPPEN:

(1)
       LDAP-REAL1 establishes a direct connection
       with EMAIL-REAL1 the ldap authentication 
       traffic passed direct between them
       like this  LDAP1-REAL1<==>EMAIL-REAL1

(2) 
       LDAP-REAL1 needs to talk to EMAIL-REAL1 
       but traffic flow must go back out 
       LDAP-LVS, and then back into EMAIL-LVS,
       and back to EMAIL-REAL1. And vice-versa
       for reverse communication.

I think that the initial routing is (2) but then once
EMAIL-REAL1 and LDAP-REAL1 establish a session, they
talk directly like routing shown in (1).  

MY QUESTIONS:

(Q1) Please tell me if I am correct in my routing
     assumptions (1) and (2). If not please explain.

(Q2) Is there a way to make LVS do routing method (2) 
     only (by addition of iptables/ipvsadm statements 
     please give some examples of how-to).

(Q3) Explain the benefits or pitfalls of (1) and 
     (2), ie. which is better? why? and why do
      the major l.b. companies apparently do (2)
     by default?  


Many thanks in advance for your very specific replies.

Peter

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.