Hi! 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 > >
