I was wondering about SMP and requests loadbalance.

There is a difference between a forard proxy and a LB proxy..
For example haproxy can handle 100k requests per sec of proxying traffic.

IN a case that I want to load balance traffic to squid instances I have
considered using squid as Amos suggested but I am not sure yet how much
load one instance can take using one cpu??

Let say turning on instances that listens on a serial number of IPs
(local) 10.100.101.1-30 on port 3129 and a LB that sits at
10.100.101.200 that loads the balance between the proxies in IP level by
SRC+DST IP pairs in the kernel level seems to me a bit smarter and
efficient.

I am not sure about the above assumption and wanted to understand:
When I will use squid as a LB non cacheing instance what would be the
maximum load it can take?
In the above example squid will be sitting between the the client to the
cache proxies.
So each request will be using CPUx2 to only parse the request... am I
right about that?
let say we want to just use the main instance as LB not parsing at all..
so we will have eventually one instance that only gets the request from
the client and loadbalance it in the application level towards the other
instances with a very low consumption of resources.

I am not saying that there is a request for this feature but how complex
is it to add a "http_port 3124 loadbalancer" ??
I think that squid has a lot of power already in hands and adding this
specific feature will be a nice addition to the code.

In a case we dont want to mess it all up etc..
Haproxy uses something that called proxy-protocol which is described
probably here:
http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt

basically it's seems to me like the procol example is like this:
"PROXY TCP4 192.168.0.1 192.168.0.11 56324 443\r\n"
like line at the begining of the incomming connection.
the v2 is a binary form header which is describe in section 2.2

The above protocl gives the option of full transparent proxy
implementation to be real..
As an example for the option of using tproxy for that pourpose we can
divide the proxy network into 2 layers.
the ring between the client and the proxy which intercepts the connecion
and another layar between the proxies to the internet.
it's more of two rings proxy system.

in the above example the proxy gets a request from 10.100.100.200 with
the proxy tcp4 srcip dstip srcport dstport\r\n (can be another way of
implememnting it)
the proxy can then bind the traffic to the src-ip:src-port
dst-ip:dst-port and allow a full tproxy binding allowing the clients use
their full 65535 ports..
In the meanwhile the proxy GW will not be .200 but 201 or another IP in
another network..
This way we can have a full transparent proxy setup..
While the above mentioned .200 host must be an application level proxy
rather then kernel level proxy it gives also the option of a SERVER
first\CLIENT first interception then we can probe the client and LB into
a SMTP interception proxy or to HTTP proxy..

The idea will not force usage of any kernel level patches and instead of
investing a lot of thr efforts into the kernel-land more efforts will be
invested in the application and hardware level.

So relate to the questions regarding using the PROXY protocol or any
other protocol and the related questions regarding LB http_port.
If you have any opinion on any of the above subjects I am willing to
hear you out.

Thanks,
Eliezer
Received on Sun Oct 06 2013 - 23:31:39 MDT