7 ms·

What are the conditions that using HAProxy is preferable over using ELB or in conjunction with ?

toomuchtodo 10y ago
When you want more control over your load balancing, or you have long lived connections that exceed the connection timeout you can configure with an ELB (RabbitMQ connections, for example; ask if you want deets, we've tried using ELBs multiple times with Rabbit, and always come back to HAproxy).
- bmurphy1976 10y ago
  Haproxy also supports mutual SSL and can do content-based health checks. Logs don't have to go through an S3 bucket so you can also get real-time metrics and logging if you want. Also, because you have control over it, you have more options for service discovery (i.e. write a Python script that periodically queries a Kubernetes cluster). And virtual hosts... And SNI... And about a thousand other features. Honestly, ELBs are pretty crappy.
  - toomuchtodo 10y ago
    ELBs are awesome if you need stupid, simple load balancing, and aren't too picky about how they behave. Anything else? Haproxy. I love that I can specify existing IAM SSL certs to an ELB; I don't have to provide access to the actual certs/keys to folks who want to provision their own ELBs in our environment, they simply need to pass through the IAM resource in the config. Its a small thing, but still important. EDIT: Something to note though, from my trails of broken glass I've walked; the process limits haproxy displays in the web interface don't always match the process limits the process actually has (as determined via /proc/<process_id>/limits). Don't get burned like I did (too few file descriptors despite haproxy indicating the contrary, epic connection failures).
- whalesalad 10y ago
  We had issues with internal ELB's for RabbitMQ (the 1 hour idle connection timeout) and the solution ended up being a heartbeat in the clients. Most client libraries have a parameter that will perform a heartbeat at some interval to keep the connection open. I can't imagine deploying our own HAProxy infrastructure. Sure, it's relatively simple, but the set-it-and-forget-it comfort provided by ELB (not to mention free SSL) is hard to beat.
  - toomuchtodo 10y ago
    We've seen some really weird ELB behavior in AWS (latency spiking excessively every few hours for seconds at a time, underlying ELB instances having scale down events occur at unexpected times, and so forth), so we use it sparingly for internal microservices. Running your own HAProxy infrastructure isn't terribly time consuming, but I do devops/infrastructure all day long; I'm biased. If you can and do avoid it, I can understand why.

When you want more control over your load balancing, or you have long lived connections that exceed the connection timeout you can configure with an ELB (RabbitMQ connections, for example; ask if you want deets, we've tried using ELBs multiple times with Rabbit, and always come back to HAproxy).

bmurphy1976 10y ago
Haproxy also supports mutual SSL and can do content-based health checks. Logs don't have to go through an S3 bucket so you can also get real-time metrics and logging if you want. Also, because you have control over it, you have more options for service discovery (i.e. write a Python script that periodically queries a Kubernetes cluster). And virtual hosts... And SNI... And about a thousand other features. Honestly, ELBs are pretty crappy.
- toomuchtodo 10y ago
  ELBs are awesome if you need stupid, simple load balancing, and aren't too picky about how they behave. Anything else? Haproxy. I love that I can specify existing IAM SSL certs to an ELB; I don't have to provide access to the actual certs/keys to folks who want to provision their own ELBs in our environment, they simply need to pass through the IAM resource in the config. Its a small thing, but still important. EDIT: Something to note though, from my trails of broken glass I've walked; the process limits haproxy displays in the web interface don't always match the process limits the process actually has (as determined via /proc/<process_id>/limits). Don't get burned like I did (too few file descriptors despite haproxy indicating the contrary, epic connection failures).
whalesalad 10y ago
We had issues with internal ELB's for RabbitMQ (the 1 hour idle connection timeout) and the solution ended up being a heartbeat in the clients. Most client libraries have a parameter that will perform a heartbeat at some interval to keep the connection open. I can't imagine deploying our own HAProxy infrastructure. Sure, it's relatively simple, but the set-it-and-forget-it comfort provided by ELB (not to mention free SSL) is hard to beat.
- toomuchtodo 10y ago
  We've seen some really weird ELB behavior in AWS (latency spiking excessively every few hours for seconds at a time, underlying ELB instances having scale down events occur at unexpected times, and so forth), so we use it sparingly for internal microservices. Running your own HAProxy infrastructure isn't terribly time consuming, but I do devops/infrastructure all day long; I'm biased. If you can and do avoid it, I can understand why.