First of all thanks too all on this list for helping me to setup and
configure haproxy. Thanks to Willy for haproxy. I thought it is a good idea
to save somebody like me some time configuring Dell's servers for haproxy to
meet DDoS or other traffic-intensive task. Solution is - "get rid of bnx2
1Gbit NIC". There is an option in Del''s servers to install Intel's 10Gbit
NIC - it is working a way faster (x3, x5) then broadcom. But anyway it is
impossible to have one server to filter 10Gbit DDoS attack, at least it is
very far from default configuration, so I failed to find solution.

But as haproxy is really good software to handle DDoS you can use amazon's
cloud. And that was my final solution. Amazon's servers are taking 400Mbit
per node, so installing 60 EC2 nodes I've managed to filter DDoS traffic at
24Gbit/s (It was somewhere around 10*10^6 requests per second, or ~150-160k
session rate per node) without any problems. Yes, there was some balancing
issues, and some failures for couple of minutes, but it's nothing comparing
to typical DDoS expirience.

And question to Willy: What hardware in your opinion is the best to run
haproxy on to serve lot's of HTTP requests 99% percent of which are trash to
be blocked?

2011/7/20 Willy Tarreau <w...@1wt.eu>

> Hi Dmitriy,
> On Wed, Jul 20, 2011 at 06:33:27AM +0400, Dmitriy Samsonov wrote:
> > Very strange, but your experience is enourmous so I'd be better to listen
> to
> > you. As I wrote, before disabling HT I've tested all possible
> combinatrions
> > of bindings:
> > (haproxy, irq) = (cpu#n, cpu#m) in (0,1), (0,2), (0,3), ..(0,11), (1,0),
> > (1,2), (1,3)...,(1,11) - total of 138 combinations, testing each one for
> > three minutes with two httperf running, and recording information on
> > haproxy's stat socket. If problem was not in HT what then?
> Given that you tested that many combinations, I would say that there is
> no option left ! I'm just surprized that you have an hyperthreading which
> is as bad as the one we had on P4s. At this time, one of the factor for
> its low efficiency was that the caches were cut in half when it was
> enabled (half of the cache for each sibling). Maybe this is implemented
> that way on your CPU, I don't know.
> (...)
> > Yes, according to /proc/cpuinfo CPU#0 has physical_id = 0, CPU#1 has
> > physical_id = 1, and so on 0, 1, 0, 1... My first idea was to bind
> haproxy
> > is CPU#0 and process irqs and CPU #2, it should be one CPU in one socket.
> > And looks like these cores shoud share same L2.
> Yes that's the idea.
> > > At least now you know that in case of a DDoS, you can just put your
> > > desktop machine in front of your expensive servers to protect them :-)
> >
> > In case of DDoS I should read haproxy's mailing list:) I really
> appreciate
> > your help.
> Well, in a few years we managed to stop about a tens of them, maybe even
> a bit more, including at least three really big ones. Sometimes it can take
> up to a week to find how to block them. And each time we had to quickly add
> dirty emergency hacks in the code. Once you've figured how to scale and
> resist, they often give up because it's an endless game. At high rates, you
> generally need your internet provider to cooperate (eg: inflate pipes to
> drain the excess traffic). But that's something pleasant to work on :-)
> Cheers,
> Willy

Reply via email to