balancing best practices - mod_proxy_balancer

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

 



All,

I am looking for some guidance on using HTTPD as a proxy and load balancer to a backend Tomcat application.  Specifically, I'm interested in how to best handle the balancing of requests.  The configuration would be very much like the 'typical implementation' shown in this Reverse Proxy Guide: https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html  (I'm using version 2.4.6):

+---------------------  +
|     Firewall Public |
+---------------------  +
+-------------------------------------------+
|      +------+   +-------+  +-------+      |
|      | httpd|   | httpd  |   | httpd |      |
|      |    1   |   |   2      |   |   3     |      |
|      +------+   +-------+  +-------+      |
+-------------------------------------------+
+----------------------  +
|     Firewall Private |
+----------------------  +
+---------------------------------------------+
|    +--------+  +---------+  +--------+      |
|    | tomcat|  |tomcat |   |tomcat |       |
|    |   1       |  |    2      |   |   3       |      |
|    +--------+  +---------+  +--------+      |
+---------------------------------------------+


We have this working fine with a vanity URL to a VIP on our public firewall --> to the 3 httpd proxy load balancer pool --> to one of the 3 backend Tomcat server pool.  We want everything to run over SSL and the currently working config on the httpd servers is basic:

<VirtualHost _default_:443>

        ServerName example.com

        SSLEngine on
        SSLProtocol all -SSLv2 -SSLv3
        SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA

        SSLCertificateFile /etc/pki/tls/certs/ssl.crt

# ------------------------------------------------
# Proxy Load Balancer
# ------------------------------------------------

<Proxy balancer://mycluster>

        BalancerMember https://app1.example.com:9009
        BalancerMember https://app2.example.com:9009

</Proxy>

SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/

</VirtualHost>


As mentioned, this works fine.  But now we need to dig into the request management.  I read here: https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html that the scheduler algorithm is provided by 'at least one of':

mod_lbmethod_byrequests
mod_lbmethod_bytraffic
mod_lbmethod_bybusyness
mod_lbmethod_heartbeat

Questions:

1. Am I correct in reading 'at least one of' that multiple of these algorithms can be used together?  If so, is there a hierarchy between them?

2. Does it make sense to use multiple algorithms?

- It sounds like each could be desirable:
mod_lbmethod_byrequests -> We do want to have an even distribution of request/sessions.

mod_lbmethod_bytraffic -> Some requests/sessions could be more intensive than others.

mod_lbmethod_bybusyness -> Sounds similar to byrequests?

mod_lbmethod_heartbeat -> Definately need to backend to be listening but would be nice to distribute or overlook a server based upon response time.  Is that part of how this works?

3. Is using HTTPD mod_proxy_balancer the best way to handle what we are looking to do?  Or are there better options?

4. On the backend we plan on using Tomcat session clustering for high availability.  That being the case, would that mean that we would NOT want to use sticky sessions at the HTTPD level in case a backend Tomcat node goes offline and the session is picked up on one of the other nodes?

Sorry if I've confused anything here, any guidance is greatly appreciated.  I'm happy to read any documentation directed to..

Thanks in advance,

HB


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux