W dniu 2013-08-23 14:25, Amos Jeffries pisze: > On 24/08/2013 12:10 a.m., Pawel Mojski wrote: >> W dniu 2013-08-23 14:08, Pawel Mojski pisze: >>> W dniu 2013-08-23 12:12, Amos Jeffries pisze: >>>> On 22/08/2013 8:47 p.m., Pawel Mojski wrote: >>>>> Hi Guys; >>>>> >>>>> I have some intresting deployment scenario. I have to install squid >>>>> box(es) as L2 bridge in 10Gbit network with 6Gbit amonunt of >>>>> traffic in >>>>> peak. >>>>> Squid is used to forward traffic to our ecap adapter. Ofcourse it's >>>>> impossible to handle that traffic amount on one box. >>>>> So, how to deploy it? I imagine such scenario. The first will be >>>>> "balancer", it will be a linux box with 2 10gigs cards. Then, the >>>>> "balancer" have to somehow redirect traffic to a squid boxes. >>>>> My first thought was to use wccpv2 protocol, but I have figured that >>>>> wccp router mode is very weakly supported on linux. I've found >>>>> only two >>>>> projects, one writen in C from 2002 and one in python from 2011. >>>>> So, do you have any suggestions how to forward traffic to squid >>>>> boxes? >>>>> The main thing is to provide source-ip spoofing functionality and >>>>> have >>>>> only one bridge in 10gig network. >>>>> Squid boxes will be connected to the balancer seperate interfaces >>>>> over >>>>> separate switch. >>>>> >>>>> Thanks in advance for further ideas. >>>> Yes WCCP may let you down here. There are quite a few limits to Squid >>>> support for it as well, not least of which is weak support for >>>> multiple caches per router. >>>> >>>> Doing this with only 1 bridge is probaly going to bite you as well, it >>>> will need one massive beast of a machine. Each Squid process will >>>> easily handle 100-150Mbps or so of traffic so you are looking at an >>>> estimate of around 45-60 Squid with 1 CPU core each. >>>> >>>> If you can find a box with enough CPU to split the traffic that way SM >>>> should serve you okay although it may have a lower bps capacity than >>>> standalone Squid due to the accept() races and UDS traffic the workers >>>> have to manage. Otherwise I suggest looking in the direction of policy >>>> routing the traffic using the iptables model for splitting traffic >>>> over ports >>>> (http://wiki.squid-cache.org/ConfigExamples/ExtremeCarpFrontend#Frontend_Balancer_Alternative_1:_iptables) >>>> >>>> but possibly splitting the traffic over routes to several cache boxes. >>>> Each of which doing regualar TPROXY on a smaller segment of the >>>> traffic before being aggregated back into the line upstream by another >>>> splitter/joiner. >>>> >>>> Amos >>> Thanks a lot Amos. >>> >>> I've already solved the problem yesterday. >>> I made a "balancer" machine which split the traffic over 8 squid boxes >>> (via ip rule) and then join it into one stream. >>> Disadvantage of the solution is require 16 (2 per each scanning box) on >>> the balancer, but I can deal with it. >>> Works like a charm. >>> >>> Regards; >>> Pawel Mojski >> require 16 additional vlan interfaces ofcourse, sorry for convinient. > > Any reason that is not 16 boxen on a single vlan? > > Amos To seperate in/out traffic on each box. Like I described in the aswer for Eliezer post. Regards; Pawel Mojski
