Hello Emilio.
I'm not disappeared... I had to wait for collegues to build up test machines in 
production configuration.
They'll run tests for several days. At the end I'll let you know the results.
 
Just a question. Is there a log file where I can see all the client connections 
and the real server addressed?
 
Thanks in advance.
 
Ciao.
Stefano.
 

________________________________

Da: Emilio Campos [mailto:[email protected]] 
Inviato: mercoledì 27 aprile 2011 12.50
A: [email protected]
Oggetto: Re: [Zenloadbalancer-support] R: R: Physical Server Config 
&Intra-cluster communications




2011/4/27 Chiesa Stefano <[email protected]>


        Hello Emilio, now everything works. I didn't understand the "Zen 
philosophy"....
        
        I'm used to work with another LB (Radware AppDirector). It uses a 
different approach. Each client connection is forwarded to the selected backend 
server as coming from the client public ip address. So the selected server 
knows the client source ip. In this scenario the balancer must be the backend 
server's default GW otherwise the client would never receive the answer from 
the farm VIP address.
        

 
Yes, This solution makes a Load Balancer working as gateway, and therefore, a 
firewall, the Load Balancer have to create a port forwarding and with this, the 
Load balancer has to works as transparent gw. We think that it is the future of 
Zen but there is a lot of work for do it.



        Zen works with a "reverse proxy" technology. The Zen balancer forwards 
the connection to the backend server changing the source client ip with the 
farm VIP address. The backend server never knows the original client ip. In 
this case setting the balances as backend server's default GW is useless 
because all the connections come from the Zen balancer.
        
        Am I right? Did I get it?


Ye you are right!
 


        I did another thought. If you add just another feature you could add a 
great value to Zen product.
        If you develop a layer 7 redirection (from a hostname to another 
hostname, from a url to another url) you'd have two products in one:
        * a pure reverse proxy but with a HA feature
        * a balancer with a http redirection (the source url identifies the 
farm)
        
        

 
Thanks about your suggestions, we are developing the integration of a reverse 
proxy with load balance, for do functionalities as:
 *reverse proxy (external url - internal url, like you commented)
 *persistence session, with tecnical as: cookie or id on url
 *ssl wrapper (ssl between client - load balancer, no ssl between load balancer 
- backend)





        Well, I didn't want to teach you.... It was just a night thought.
        I'll put your product in a deeper test in the next few days and I'll 
let you know the results.
        


We like read suggestions of our member list, we can evaluate the preferences 
for new developments.
Please can you tell us the results  when you end your test? 
Would you like add your result test on our "testimonial" section on web? It 
helps us much!

Regards!
 



        Thanks again and have a nice day.
        

        Ciao.
        Stefano.
        
        ________________________________
        
        Da: Emilio Campos [mailto:[email protected]]
        
        Inviato: martedì 26 aprile 2011 13.54
        
        A: [email protected]
        
        Oggetto: Re: [Zenloadbalancer-support] R: Physical Server Config 
&Intra-cluster communications
        


        So the first question was about each backend server default GW. Should 
it be the Zen eth0 ip address?
        NO, zen never works as gw, the default gw for all servers, zen included 
should be your fw (192.168.1.150)
        
        Otherwise how can a farm server can answer with the farm's VIP?
        The VIPs is configured on zen load balancer, when a client connect to 
the farm use the VIP (configured on zen), zen memorize this connection 
(client-zen) and create a new connection between zen and backend, backends 
NEVER know which client are connecting, for your backend only exist the zen 
server.
        This is the tcp/ip connection:
        
        from client to backend server:
        client -  zen(VIP) - backend(RIP)
        
        from backend server to client:
        backend(RIP) - zen(VIP) - client
        
        
        If A1 server calls the farm B VIP address (same network), how can I 
avoid farm B servers to answer directly to server A1 (they will not use the 
farm B VIP address)?
        the same that the last question. A1 server calls farm B VIP, your B 
server going to reply to B VIP, NOT A RIP Server
        This is the tcp/ip connection:
        
        from A server  to B server:
        A1 server - B VIP - B server
        
        >From Bserver to Aserver:
        B server - B VIP - A1 server
        
        
        Remember: VIP = Virtual IP, configured on zen service,
        RIP = Real IP configured on your server
        On Zen; you only have to indicate the RIP servers on "farm > edit" 
section.
        
        Reading your schema I have to tell you that 192.168.1.100 and 
192.168.1.200 (this going to be the VIPs) should be configured on the zen 
server, you can add two virtual interfaces as this eth0:1 and eth0:2 or eth0:v1 
and eth0:v2, you can add this virtual interfaces on "server > interfaces" 
section, and after select this on the first step on new farm configuration 
section.
        
        For cluster:
        for the cluster there is no problem, configure your eth1 on zen1 and 
the same interface eth1 on node2, follow the steps, if you have problem with 
this please write us.
        
        This solve your doubts? please tell me
        
        P.D. Your scheme helped me! ;)
        
        Regards!
        
        
        
        
        2011/4/26 Chiesa Stefano <[email protected]>
        
        
               Hello Emilio, thanks for your answer.
               I understood I didn't explain well my questions, too many things 
left unsaid....
               Attached you'll find a network schema that explains better my 
situation.
        
               All elements (balancer, server) are in the same network (a DMZ) 
with a fw between this network and Internet.
        
               The Zen server will have two interfaces: eth0 - for farm/server 
communication (def GW: the fw)      eth1 - for the future cluster management
               There will be a couple of farms with 2 server each. Every server 
will have just 1 interface with a DMZ address space IP
        
               So the first question was about each backend server default GW. 
Should it be the Zen eth0 ip address? Otherwise how can a farm server can 
answer with the farm's VIP?
        
               Second question. If A1 server calls the farm B VIP address (same 
network), how can I avoid farm B servers to answer directly to server A1 (they 
will not use the farm B VIP address)?
        
               Hope this explanation helps.
        
               Ciao.
               Stefano.
        
        
               ________________________________
        
               Da: Emilio Campos [mailto:[email protected]]
               Inviato: lunedì 25 aprile 2011 0.01
        
               A: [email protected]
        
               Oggetto: Re: [Zenloadbalancer-support] Physical Server Config 
&Intra-cluster communications
        
        
        
        
        
               2011/4/22 Chiesa Stefano <[email protected]>
        
        
                      Hello all.
                      I'm pretty new to this list and I don't' know if someone 
else asked the
                      same questions.
        
                      I'm going to test you balancer in the next days but I 
need to know:
        
                      * Reading the available documentation I didn't understand 
what is the
                      right config of physical servers. I configure on the Zen 
server the
                      Virtual IP of the server farm and each physical sevrer 
ip. But what is
                      the correct interface configuration of PS? Do they have 
to address the
                      Zen server as default GW? Must they have to config 
another if to answer
                      to http request (i.e a loopback interface with the VIP 
address
                      configured)?
        
        
        
               There is no right configuration, depending your system 
infraestructure, but you need to know that
               default gw is not depending of farm, is a configuration that 
depends of network interfaces. YOu can configure one or a lot of network 
interface, and, after select wich interface use wich farm.
        
               You need configure your gw for tcp/ip level comunication, gw not 
depending of farm, depend of network, you have to think that zen is a entire 
solution for load balancing appliance, with network section, cluster section, 
backup section....
        
               First of all I recommend you configure your network in zen, 
comunication between zen server and your backend servers or physical servers 
that you said, the next step could be configure a farm.
        
        
        
        
                      * In the production environment I'll have several farm of 
balanced
                      server in the same subnet. A single server in farm A 
(i.e. A1) could
                      need to access infos in farm B and then make a request to 
the B farm vip
                      address. Will the selected server in farm B (i.e. B2) be 
able to answer
                      to server A1 using the farm B VIP or will answer directly 
to A1 with his
                      ip (as they reside in the same subnet)?
        
        
        
               It is possible, a backend or Physical server (PS) can connect to 
other PS over your Virtual IP with no problem
        
               One member of our distribution list are helping us with te 
documentation, maybe this new documentation could help you, but you can feel 
free for ask questions  all you need to the list.
        
               I hope my reply could help you to solve your doubts, or maybe my 
reply made more doubts? :P
        
               Regards!
        
        
        
        
                      Thanks in advance and have a nice week-end.
        
                      Stefano Chiesa.
        
                      ----------------------------------------
                      Stefano Chiesa
                      Wolters Kluwer Italia
                      Strada 1, Palazzo F6
                      20090 Milanofiori Assago (Mi) - Italia
                      Phone +39 0282476279 (20279 Voip)
                      Fax +39 0282476633
        
        
                      
------------------------------------------------------------------------------
                      Fulfilling the Lean Software Promise
                      Lean software platforms are now widely adopted and the 
benefits have been
                      demonstrated beyond question. Learn why your peers are 
replacing JEE
                      containers with lightweight application servers - and 
what you can gain
                      from the move. http://p.sf.net/sfu/vmware-sfemails
                      _______________________________________________
                      Zenloadbalancer-support mailing list
                      [email protected]
                      
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
        
        
        
        
        
               --
               Load balancer distribution - Open Source Project
               http://zenloadbalancer.sourceforge.net
               Distribution list (subscribe): 
[email protected]
        
        
        
        
               
------------------------------------------------------------------------------
               WhatsUp Gold - Download Free Network Management Software
               The most intuitive, comprehensive, and cost-effective network
               management toolset available today.  Delivers lowest initial
               acquisition cost and overall TCO of any competing solution.
               http://p.sf.net/sfu/whatsupgold-sd
               _______________________________________________
               Zenloadbalancer-support mailing list
               [email protected]
               
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
        
        
        
        
        
        
        --
        Load balancer distribution - Open Source Project
        http://zenloadbalancer.sourceforge.net
        Distribution list (subscribe): 
[email protected]
        
        
        
        
------------------------------------------------------------------------------
        WhatsUp Gold - Download Free Network Management Software
        The most intuitive, comprehensive, and cost-effective network
        management toolset available today.  Delivers lowest initial
        acquisition cost and overall TCO of any competing solution.
        http://p.sf.net/sfu/whatsupgold-sd
        _______________________________________________
        Zenloadbalancer-support mailing list
        [email protected]
        https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
        




-- 
Load balancer distribution - Open Source Project
http://zenloadbalancer.sourceforge.net
Distribution list (subscribe): [email protected]



------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

Reply via email to