Mailing List Archive

You can use mod_backhand, but it would be to balance the traffic across
your second tier. As you said in your email, much of the cost involved
is the SSL traffic itself. This cost can't be balanced by mod_backhand
as it happens at the application level and the cost is paid at the
application protocol level. To balance the cost of SSL resource
consumption you need to do it beneath the application protocol layer
(HTTPS), for example on the TCP/IP level. So you'd use a TCP/IP load
balancer in front of everything (like LVS, BIG/ip, ServerIron,
Arrowpoint, etc. etc. etc.)

However, I doubt you really need fine grained balancing across your
first tier SSL proxy machines. We ran a pretty high traffic site over
SSL that just used DNS round robin for naively distributing the
incoming connections. Then mod_backhand intelligently distributed them
across a second tier cluster of Jakarta Tomcat servers.

I would duplicate your current front end machine and give it a second
publicly accessible IP address. Add another A record to DNS for the
web site. Then, use wackamole to ensure high availability of the two
"exposed" IP addresses. We did this with great success. I'd throw in
hardware SSL accelerators if you are noticing that as the bottleneck.

Note, if you are going to be VERY high traffic, your setup may justify
installing an SSL-aware hardware load-balancer and hardware SSL
accelerators on your 1st tier machines. The SSL "crypto acceleration"
cards compared to doing the openssl work on your system processor is
like night and day. A financial application where the majority of web
transactions happen over SSL justifies the purchase of one of these
hardware accelerators.

On Saturday, Sep 27, 2003, at 10:35 US/Eastern, Kok Wei, Koh wrote:

> Hello everyone,
>
> I am currently looking for a solution to a project I am working on, in
> a local financial institution where high performance is needed due to
> a reasonably high number of users accessing the web services everyday.
>
> I'll write a paragraph of the current situation:
>
> The nature of the banking services website consists of a front
> Internet facing Apache 1.3.28 (EAPI, mod_ssl, mod_proxy) being a
> reverse proxy proxying to 3 different machines based on different
> URLs. Behind the reverse proxy, there lies 2 IIS servers, and 1 Apache
> (mod_jrun) which ties to JRun housing Java servlets. The database
> server is of another machine of a deeper DMZ.
>
> I suppose the following diagram shall illustrate better ...
>
>
> +--------+
> | RP | (SSL, HTTP)
> +--------+
> |
> /|\
> / | \
> / | \
> / | \
> IIS HTTPD IIS
>
>
> I realize that the bottleneck is on the RP when in the near future the
> number of users are expected to grow tremendously. When users access
> the banking services, they are forced to enter HTTPS mode, which also
> consumes more processing power than just pure HTTP. Besides, this
> setup is clearly a single-point-of-failure if the RP goes down after a
> system patch, or whatever reason it needs to reboot.
>
> My direction is really to see if backhand/wackamole could be used to
> load-balance/fail-over the RP if one or two more boxes are parked next
> to it, and similarly setup/configured. The goal is performance being
> the first priority, and availability the second ;-) Or both > preferably!
>
> Hoping to get various feedbacks. Thank you in advance.
>
>
> --
> Kok Wei, Koh <kokwei@imocha.com.my>
>
>
> _______________________________________________
> backhand-users mailing list
> backhand-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/backhand-users
>
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth

Thank you so much for the reply!

BTW, I still have a couple of questions in which I hope you could enlighten.

After reading your suggestions, I'd go for duplicating the RP and adopt
RR DNS. Say the new infrastructure now looks like the following:


(www.banking.com)

10.100.13.1 10.100.13.2
+---------+ +---------+
| RP1 | | RP2 |
+---------+ +---------+

The thing is the system requires client authentication, after which a
successful SSL handshake is followed by a custom apache module that
extracts the client certificate subject DN and re-packages it into a
HTTP auth header, passing it into the backend Apache (JRun) servers.
This is why the first thought in my mind was SSL Accelarators are out of
the question, or will I still be able to extract the DN if SSL is to be
handled by a dedicated hardware?

Another doubtful question is ...

Imagine a user already presented his/her client certificate to RP1, and
then somewhere down the road of subsequent HTTPS requests, the DNS
resolves to RP2. Does the client needs to re-present the client
certificate again?

Hope to get help on this. Thank you!

Theo Schlossnagle wrote:
> You can use mod_backhand, but it would be to balance the traffic across
> your second tier. As you said in your email, much of the cost involved
> is the SSL traffic itself. This cost can't be balanced by mod_backhand
> as it happens at the application level and the cost is paid at the
> application protocol level. To balance the cost of SSL resource
> consumption you need to do it beneath the application protocol layer
> (HTTPS), for example on the TCP/IP level. So you'd use a TCP/IP load
> balancer in front of everything (like LVS, BIG/ip, ServerIron,
> Arrowpoint, etc. etc. etc.)
>
> However, I doubt you really need fine grained balancing across your
> first tier SSL proxy machines. We ran a pretty high traffic site over
> SSL that just used DNS round robin for naively distributing the incoming
> connections. Then mod_backhand intelligently distributed them across a
> second tier cluster of Jakarta Tomcat servers.
>
> I would duplicate your current front end machine and give it a second
> publicly accessible IP address. Add another A record to DNS for the web
> site. Then, use wackamole to ensure high availability of the two
> "exposed" IP addresses. We did this with great success. I'd throw in
> hardware SSL accelerators if you are noticing that as the bottleneck.
>
> Note, if you are going to be VERY high traffic, your setup may justify
> installing an SSL-aware hardware load-balancer and hardware SSL
> accelerators on your 1st tier machines. The SSL "crypto acceleration"
> cards compared to doing the openssl work on your system processor is
> like night and day. A financial application where the majority of web
> transactions happen over SSL justifies the purchase of one of these
> hardware accelerators.
>
> On Saturday, Sep 27, 2003, at 10:35 US/Eastern, Kok Wei, Koh wrote:
>
>> Hello everyone,
>>
>> I am currently looking for a solution to a project I am working on, in
>> a local financial institution where high performance is needed due to
>> a reasonably high number of users accessing the web services everyday.
>>
>> I'll write a paragraph of the current situation:
>>
>> The nature of the banking services website consists of a front
>> Internet facing Apache 1.3.28 (EAPI, mod_ssl, mod_proxy) being a
>> reverse proxy proxying to 3 different machines based on different
>> URLs. Behind the reverse proxy, there lies 2 IIS servers, and 1 Apache
>> (mod_jrun) which ties to JRun housing Java servlets. The database
>> server is of another machine of a deeper DMZ.
>>
>> I suppose the following diagram shall illustrate better ...
>>
>>
>> +--------+
>> | RP | (SSL, HTTP)
>> +--------+
>> |
>> /|\
>> / | \
>> / | \
>> / | \
>> IIS HTTPD IIS
>>
>>
>> I realize that the bottleneck is on the RP when in the near future the
>> number of users are expected to grow tremendously. When users access
>> the banking services, they are forced to enter HTTPS mode, which also
>> consumes more processing power than just pure HTTP. Besides, this
>> setup is clearly a single-point-of-failure if the RP goes down after a
>> system patch, or whatever reason it needs to reboot.
>>
>> My direction is really to see if backhand/wackamole could be used to
>> load-balance/fail-over the RP if one or two more boxes are parked next
>> to it, and similarly setup/configured. The goal is performance being
>> the first priority, and availability the second ;-) Or both > preferably!
>>
>> Hoping to get various feedbacks. Thank you in advance.
>>
>>
>> --
>> Kok Wei, Koh <kokwei@imocha.com.my>
>>
>>
>> _______________________________________________
>> backhand-users mailing list
>> backhand-users@lists.backhand.org
>> http://lists.backhand.org/mailman/listinfo/backhand-users
>>
> // Theo Schlossnagle
> // Principal Engineer -- http://www.omniti.com/~jesus/
> // Postal Engine -- http://www.postalengine.com/
> // Ecelerity: fastest MTA on earth
>
>
> _______________________________________________
> backhand-users mailing list
> backhand-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/backhand-users
>
>