Comments on: EC2 Elastic Load Balancing for Fun and Profit

By: james

james — Tue, 29 Jun 2010 11:34:04 +0000

If that’s the case then ELB over SSL is not the solution for your needs.

By: Damia Soler

Damia Soler — Tue, 29 Jun 2010 11:24:33 +0000

My concerns are not about statistics, my main concern is about to know from which ip have been done one transaction, web attack or things like this.

By: james

james — Tue, 29 Jun 2010 09:41:15 +0000

The lack of IP address passing through? It’s a trade off. We rely more on application logging for metrics rather than parsing Apache logs for pageviews and clickstreams. I’d suppose that alternatively one could implement a 3rd party package like Google Analytics to obtain the same functions of AWStats et al. That said, if getting IP addresses in the logs for HTTPS is important then ELB is not the right solution; prior to this we used a simple round-robin method from our DNS provider which worked successfully for a number of years.

By: Damia Soler

Damia Soler — Tue, 29 Jun 2010 07:55:43 +0000

What about lack of logging on SSL load balance??

For me is a problem. How dou deal with that?

By: james

james — Mon, 23 Nov 2009 21:57:00 +0000

Aw, fiddlesticks. Well, that puts another wrinkle in testing. I’ll have loop back and wrestle with that a little more as I *think* it is entirely possible for Passenger to crap the bed but Apache keeps on happily serving files. :-/

By: Shlomo

Shlomo — Mon, 23 Nov 2009 21:50:56 +0000

Aw, crud – the XML tags got munged. How about this:

shlomo$ elb-describe-lbs –show-long
LOAD-BALANCER,testLB,testLB-1819819914.us-east-1.elb.amazonaws.com,”{interval=10,target=TCP:8443,timeout=3,healthy-threshold=2,unhealthy-threshold=2}”,us-east-1a,(nil),”{protocol=HTTP,lb-port=80,instance-port=80, protocol=TCP,lb-port=443,instance-port=8443}”,2009-11-23T21:44:24.420Z

By: Shlomo

Shlomo — Mon, 23 Nov 2009 21:49:35 +0000

Very interesting - thanks for sharing this cool technique! One issue: An ELB only supports a single health check at a time. So your second health check for up.html overrides the TCP:8443 health check. Here's the results when I try these commands on my ELB testLB: shlomo$ elb-create-lb testLB --listener "lb-port=80,instance-port=80,protocol=http" --listener "lb-port=443,instance-port=8443,protocol=tcp" --availability-zones us-east-1a DNS-NAME testLB-1819819914.us-east-1.elb.amazonaws.com shlomo$ elb-configure-healthcheck testLB --headers --target "HTTP:80/status" --interval 5 --timeout 3 --unhealthy-threshold 2 --healthy-threshold 2 HEALTH-CHECK TARGET INTERVAL TIMEOUT HEALTHY-THRESHOLD UNHEALTHY-THRESHOLD HEALTH-CHECK HTTP:80/status 5 3 2 2 shlomo$ elb-configure-healthcheck testLB --headers --target "TCP:8443" --interval 10 --timeout 3 --unhealthy-threshold 2 --healthy-threshold 2 HEALTH-CHECK TARGET INTERVAL TIMEOUT HEALTHY-THRESHOLD UNHEALTHY-THRESHOLD HEALTH-CHECK TCP:8443 10 3 2 2 shlomo$ elb-describe-lbs --show-xml testLB testLB-1819819914.us-east-1.elb.amazonaws.com HTTP 80 80 TCP 443 8443 us-east-1a TCP:8443 10 3 2 2 2009-11-23T21:44:24.420Z 795ddb2e-d879-11de-b139-d72195628521 Only the second health check is retained.