On 08.12.2015 14:07, Kernel freak wrote:
Hello friends,
I am working on a Debian server in which I would like to setup 2 instances
of Apache tomcat which will be load balanced by an Apache HTTP server(Do I
require a http server? ). In-case one copy of Apache tomcat goes down, the
other one will automatically comes online.
While I was creating a configuration for one of our server, I know how to
relay requests based upon URL to Apache Tomcat, these are the 2 things I
don't know.
1) Will this work with https? Reason I ask is, there are many pages which
are served under https and the configuration which I have and shown below
seems to be calling with http instead of https.
2) How to trigger the 2nd copy of tomcat.
[snip]
Hi. To answer this "top-down" :
1) to do "load-balance" 2 tomcats, there are many ways, and you do not necessarily have to
use Apache httpd as a front-end, there are other solutions.
But the Apache httpd solution is probably the easiest to set up, and it's free.
2) picture the following setup :
user browser <-- HTTP or HTTPS --> Apache httpd <-- HTTP/HTTPS/AJP --> tomcat1
+ Connector <-- HTTP/HTTPS/AJP --> tomcat2
tomcat1 and tomcat2 are always active, both. You do not start one when the
other fails.
They are normally both active, and they share the load (the httpd Connector does that for
you).
If one tomcat fails, the Connector under Apache httpd will notice that, and will start
forwarding the requests only to the still-working tomcat.
When the failed tomcat comes back on-line, the Connector notices again, and starts
balancing the requests again to both tomcats.
If both tomcats fail, you get an error at the httpd level.
3) for the httpd-level "Connector" between httpd and tomcat, you have 3 choices
:
a) mod_proxy + mod_proxy_http
b) mod_proxy + mod_proxy_ajp
c) mod_jk
Each one of those can do load-balancing, but their configuration is different.
4) If Apache httpd and the tomcats communicate through a network that is considered as
secure, then the most efficient configuration would be :
Connection A Connection B
user browser <-- HTTP or HTTPS --> Apache httpd <-- HTTP/AJP --> tomcat1
+ Connector <-- HTTP/AJP --> tomcat2
The usual way of describing this is "terminating HTTPS at the httpd level".
In other words, do not use HTTPS between httpd and tomcat (connection B), because it would
unnecessarily force an additional encryption/decryption.
All the additional HTTPS information that may be needed at the tomcat level, to know that
the original user connection with httpd (connection A) was under HTTPS, will be anyway
forwarded by the Connector, to Tomcat (as HTTP request headers).
(So tomcat can always know if the original browser to httpd connection A was
secure or not.)
5)
- The (mod_proxy + mod_proxy_http) Connector, forwards the original (HTTP/HTTPS) client
requests to Tomcat, using the HTTP protocol (and format).
So at the receiving end, in Tomcat, you need a matching HTTP Connector.
- the (mod_proxy + mod_proxy_ajp) Connector, and the mod_jk Connector, forward the
original (HTTP/HTTPS) client requests to Tomcat, using a protocol/format that is not HTTP,
but which essentially carries the same information (it is the AJP protocol/format).
So at the receiving end you need a matching AJP Connector.
- when the request is received by Tomcat using either one of the Tomcat Connectors, it is
the job of the Tomcat-side Connector to "translate" this request into an internal Tomcat
"request object", which is always the same. So from the point of view of your tomcat
webapps, it does not matter through which Connector the request was received, it always
looks the same.
- one difference between proxying through HTTP and proxying through AJP, is that the AJP
protocol does not have a corresponding "AJPS" encrypted version.
In other words, you should probably not use either (mod_proxy + mod_proxy_ajp) or mod_jk,
if your httpd and tomcats communicate over a non-secure channel (such as over an Internet
connection). (You could still do that over an SSH tunnel, but that complicates things).
- another difference is that the AJP protocol can carry to tomcat, a user-id that has been
authenticated at the httpd level. The HTTP protocol does not do that by itself.
(In short, if you authenticate users at the httpd level, and want Tomcat to use this and
avoid authenticating the user again, then use the AJP protocol).
Does this give you enough material to figure out the rest of your questions ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
