Not, There isn't log about client connections, but you can see the online
client connections on "manage farm" section.
Regards
2011/5/23 Chiesa Stefano <[email protected]>
> 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
>
--
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
