Re: Zope and Ultramonkey: balancing more ZEO clients on the same machine

No, it doesn't seem to work   :(

I'll try to recap:

CLIENTS
   |  LAN1 (192.168.1.x)
   |---------------------|
(VIP 192.168.1.10)       | 
192.168.1.11          192.168.1.12
|----------------|    |----------------|
|REDIRECTOR      |    |STBY REDIRECTOR |  
|realserver 1    |    |realserver 2    |   
|(Apache on port |    |(Apache on port |  
|10080, 10081,   |    |10080, 10081,   |   
|10082)          |    |10082)          |   
|----------------|    |----------------|  
192.168.2.11          192.168.2.12
   |---------------------|
      LAN2 (192.168.2.x)

 
Every port is bound to an Apache Virtual Host that interacts with a 
separate instance of Zope.

The relevant part of my ldirectord.cf is

# Virtual Server for HTTP
virtual=192.168.1.10:80
        real=192.168.2.11:10080 masq
        real=192.168.2.12:10080 masq
        real=192.168.2.11:10081 masq
        real=192.168.2.12:10081 masq
        real=192.168.2.11:10082 masq
        real=192.168.2.12:10082 masq
        service=http
        request="index.html"
        receive="Intranet"
        scheduler=rr
        protocol=tcp
        checktype=negotiate


Now ipvsadm shows the right entries, but also local entries which I 
haven't configured

TCP  192.168.1.10:80 rr

  -> 192.168.2.12:10082        Masq    1      0          0

  -> 192.168.2.11:10082        Local   0      0          0

  -> 192.168.2.12:10081        Masq    1      0          0

  -> 192.168.2.11:10081        Local   0      0          0

  -> 192.168.2.12:10080        Masq    1      0          0

  -> 192.168.2.11:10080        Local   0      0          0


What I think happens is:

   1. realserver 2 receives packets from client on 192.168.2.12 port
      10080 (and also the others) but cannot send them back correctly,
      since the machine has also an interface on LAN1 and probably sends
      the reply on that interface directly
   2. realserver 1 is listed as Local and it seems that no NAT happens
      for a packet destined to a Local (and so it doesn't find the right
      virtual server for apache)

For 1. I think that if LVS NATed not only the destination address and 
port but also the source, masquerading behind the 192.168.2.11 address, 
then packets would be correctly routed.

For 2. I'd need to tell LVS to NAT even if it thinks that the realserver 
1 is Local.

I don't really know how to do this...    :(

Thank you.

Best regards,
    Paolo




Paolo Asioli ha scritto:

> Thank you for your feedback!
>
> Well, I don't expect more than 40 mbit, since that is the maximum 
> bandwidth we'll have available...
>
> My problem is: I'd like to start with a configuration similar to the 
> Streamline Highly Availability and Load Balancing with two servers, 
> but doing LVS/NAT on a secondary network interface (creating a private 
> subnet "behind" the two machines), to distinguish the IPs without the 
> need to put in use 4 machines.
>
> I'll try that very soon, but I'd appreciate if anyone has experience 
> and can point out in advance caveats and suggestions.
>
> Best regards,
>     Paolo
>
>
> Timan Rebel / Sugababes.nl ha scritto:
>
>>>to me this looks like a case of LVS/NAT.
>>>Is it possible to do it with just two servers, maybe redirecting to IPs
>>>on a dedicated subnet configured on a secondary ethernet port on each
>>>server ? Or is there any other solution (something that could let me
>>>keep the efficiency of LVS/DR) ?
>>>    
>>>
>>
>>Afaik know NAT is the only solution here... We are using NAT on our apache
>>cluster for both apache servers serving PHP files and apache servers serving
>>static content. ATM we have a metered (95%) bandwith use of over 230 mbit
>>and the director does not have any problems with it. I do not know what your
>>expectations are, but I guess that NAT would not have to be a problem for
>>you.
>>
>>With kind regards,
>>
>>Timan Rebel
>>Sugababes.nl
>>
>>
>>  
>>
>
>-- 
>
>--------
>Ing. Paolo S. Asioli
>Unieuro S.p.A.
>Tel. (+39) 0173 4664359
>Mob. (+39)  335 8430361
>  
>
>
>
> -----------------------------------------------------------------------
> Questa e-mail è stata inviata da un PC appartenente a Unieuro S.p.A. o
> a un'altra azienda del Gruppo Dixons. Il suo contenuto è confidenziale
> e riservato al mittente e al destinatario designato.
>
> Se l'avete ricevuta per errore, Vi preghiamo di segnalarcelo e di
> eliminarla dal vostro sistema; non potete fare alcuno uso dei
> contenuti né copiarla o inoltrarla a terze parti.
>
> Le opinioni, conclusioni e dichiarazioni d'intenti contenute in questa
> e-mail sono responsabilità del mittente e non saranno vincolanti per
> un'azienda del Gruppo Dixons a meno di essere state confermate da un
> rappresentante autorizzato in modo indipendente dal presente
> messaggio. Non accettiamo responsabilità per eventuali virus: deve
> essere Vostra cura provvedere alla verifica.
>
> Vi preghiamo di osservare che le e-mail inviate da ed al Gruppo Dixons
> sono verificate su base regolare a fini di archiviazione, controllo di
> qualità e addestramento, per assicurare aderenza ai regolamenti e per
> prevenire eventuali virus ed utilizzo non autorizzato dei nostri
> sistemi informativi.
> -----------------------------------------------------------------------


-- 

--------
Ing. Paolo S. Asioli
Unieuro S.p.A.
Tel. (+39) 0173 4664359
Mob. (+39)  335 8430361




-----------------------------------------------------------------------
Questa e-mail è stata inviata da un PC appartenente a Unieuro S.p.A. o
a un'altra azienda del Gruppo Dixons. Il suo contenuto è confidenziale
e riservato al mittente e al destinatario designato.

Se l'avete ricevuta per errore, Vi preghiamo di segnalarcelo e di
eliminarla dal vostro sistema; non potete fare alcuno uso dei
contenuti né copiarla o inoltrarla a terze parti.

Le opinioni, conclusioni e dichiarazioni d'intenti contenute in questa
e-mail sono responsabilità del mittente e non saranno vincolanti per
un'azienda del Gruppo Dixons a meno di essere state confermate da un
rappresentante autorizzato in modo indipendente dal presente
messaggio. Non accettiamo responsabilità per eventuali virus: deve
essere Vostra cura provvedere alla verifica.

Vi preghiamo di osservare che le e-mail inviate da ed al Gruppo Dixons
sono verificate su base regolare a fini di archiviazione, controllo di
qualità e addestramento, per assicurare aderenza ai regolamenti e per
prevenire eventuali virus ed utilizzo non autorizzato dei nostri
sistemi informativi.
-----------------------------------------------------------------------