4

If you exhaust your public network connection (say 1 Gbps) to your haproxy server that proxies requests to your backend servers, what options do you have to scale it out?

Since all request traffic flows through haproxy, how can you scale this setup if you don't have any bandwidth left on your port?

codecompleting
  • 513
  • 1
  • 4
  • 14

2 Answers2

6

You add another port.

Say your existing network looks like one public IP address in front of one HAProxy box in front of N backend servers. You run through (or better yet approach running through 1 Gbps) of throughput but your backend servers are still healthy with spare resources.

The next step is to get a second public IP address and another HAProxy machine in front of you cluster. Add some Global Server Load Balancing out in front to send traffic in some configurable way to each of your two front end HAProxy boxes.

We've done this by managing our own Ketama Hash based Power DNS server. There are also DNS services that provide programmable DNS responses based on geographic location or other criteria.

Community
  • 1
dmourati
  • 25,540
  • 2
  • 42
  • 72
  • Exactly what I was going to say. By the time you are pushing 1 Gbps it's probably such an important part of your business that you really should have it spread across two geographically separate data centres. – Ladadadada Jan 30 '12 at 22:30
  • @Ladadadada well some things are high throughput but not necessarily something that brings in revenue :) – codecompleting Feb 02 '12 at 18:34
  • Not everything that is important brings in revenue. They can still cost a lot when they go down. – Ladadadada Feb 02 '12 at 18:46
1

Assuming that you don't have the means to get a faster uplink or otherwise scale the existing HAProxy device, then scale to multiple.

You can split the load between them in a few different ways:

  1. DNS round robin. This involves just adding extra A records to the existing DNS name, and should hopefully split the request load semi-evenly around the members of the A record.
  2. Selective DNS answering. Responds to different DNS requests with different answers depending on criteria - it could simply enforce round-robin distribution, or, if your application can be scaled to new locations effectively, it can answer queries with the closest available instance of the application for a given client (geographically-aware DNS).
  3. BGP Anycast. Generally considered "not such a good idea" for session-aware communications as topology changes can break TCP sessions, this would be another method of pushing traffic to a deployment of the application that's close to the user from an internet topology perspective.
Shane Madden
  • 114,520
  • 13
  • 181
  • 251