Re: Bench of haproxy

2011-05-07 Thread Jason J. W. Williams
Generally the Caviums are used for SSL offload. The CPUs in F5s generally do 
the bulk of the L7 + iRules application. 

-J

Sent via iPhone

Is your e-mail Premiere?

On May 7, 2011, at 0:06, Baptiste bed...@gmail.com wrote:

 On Sat, May 7, 2011 at 12:14 AM, Vincent Bernat ber...@luffy.cx wrote:
 OoO En  cette soirée bien amorcée  du vendredi 06 mai  2011, vers 22:46,
 Baptiste bed...@gmail.com disait :
 
 It seems  that the  CPU speed  of your F5  3900 is  2.4GHz with  8G of
 memory.
 
 The  F5  is  using some  Cavium  chip  to  forward requests.   The  main
 processor  is mainly  used for  the web  interface which  can  be pretty
 slow. ;-)
 --
 
 mmm...
 I thought the cavium would be used for L4 balancing only.
 But it seems they can do layer 7 as well within the chip:
  http://www.caviumnetworks.com/processor_NITROX-DPI.html
 Must be quite expensive :D
 
 To come back to haproxy, since it's event driven, the fastest the CPU,
 the most request it will handle :)
 and the more memory you'll have in your chassis, the more TCP
 connection you'll be able to maintain.
 
 Good luck with your testing.
 
 Baptiste
 
 
 I WILL NOT BARF UNLESS I'M SICK
 I WILL NOT BARF UNLESS I'M SICK
 I WILL NOT BARF UNLESS I'M SICK
 -+- Bart Simpson on chalkboard in episode 8F15
 
 



Re: Bench of haproxy

2011-05-07 Thread Hank A. Paulson
Not necessarily a solution to this performance issue, but I was thinking about 
how to get to that next level of performance for haproxy.


Here is an idea I had that is a bit far out. Supermicro and others now have 
GPU servers - TESLA from NIVDIA, etc. A project from Korea has used these 
GPGPUs to create a high speed Linux based router - they have achieved around 
40 Gbps. They have a related package for packet I/O:


Packet I/O Engine is a high-performance device driver for Intel 
82598/82599-based network interface cards. This program is based on  Intel 
IXGBE driver (version 2.0.38.2), but heavily modified for throughput-oriented 
user-level applications.


They take a different approach to memory for packet processing, rather than 
handing out memory like a Grandma slowing digging out her coin purse and 
handing out a few pennies each time the kids ask, they pre-allocate healthy 
amounts of memory. Details here:


http://shader.kaist.edu/packetshader/
http://shader.kaist.edu/packetshader/io_engine/index.html

Could this be a future for high speed dedicated haproxy machines - some 
interfaces are taken over by haproxy and dedicated to it using something 
similar to the above. Other interfaces are left to the normal kernel for 
management, logging, etc. Maybe not but there might be some usable ideas there.


12 Core CPU, 2 x16 PCIe, one for GPU, one for Intel 10GB X520-T2 Card:
http://www.supermicro.com/Aplus/system/1U/1122/AS-1122GG-TF.cfm


On 5/6/11 11:25 PM, Jason J. W. Williams wrote:

Generally the Caviums are used for SSL offload. The CPUs in F5s generally do 
the bulk of the L7 + iRules application.

-J

Sent via iPhone

Is your e-mail Premiere?

On May 7, 2011, at 0:06, Baptistebed...@gmail.com  wrote:


On Sat, May 7, 2011 at 12:14 AM, Vincent Bernatber...@luffy.cx  wrote:

OoO En  cette soirée bien amorcée  du vendredi 06 mai  2011, vers 22:46,
Baptistebed...@gmail.com  disait :


It seems  that the  CPU speed  of your F5  3900 is  2.4GHz with  8G of
memory.


The  F5  is  using some  Cavium  chip  to  forward requests.   The  main
processor  is mainly  used for  the web  interface which  can  be pretty
slow. ;-)
--


mmm...
I thought the cavium would be used for L4 balancing only.
But it seems they can do layer 7 as well within the chip:
  http://www.caviumnetworks.com/processor_NITROX-DPI.html
Must be quite expensive :D

To come back to haproxy, since it's event driven, the fastest the CPU,
the most request it will handle :)
and the more memory you'll have in your chassis, the more TCP
connection you'll be able to maintain.

Good luck with your testing.

Baptiste



I WILL NOT BARF UNLESS I'M SICK
I WILL NOT BARF UNLESS I'M SICK
I WILL NOT BARF UNLESS I'M SICK
-+- Bart Simpson on chalkboard in episode 8F15









Re: MySQL LB / Backup Config

2011-05-07 Thread Ben Timby
On Fri, May 6, 2011 at 5:41 PM, Brian Carpio bcar...@broadhop.com wrote:

 Hi,



 I have a very simple setup for doing load balancing for MySQL DBs.



 listen mysql_proxy vip01:3306

 mode tcp

 option tcpka

 balance roundrobin

 server mysql01 mysql01:3306 weight 1 check inter 10s rise 1 fall 1

 server mysql02 mysql02:3306 weight 1 check inter 10s rise 1 fall 1
 backup



 I am using the backup option so that mysql02 ONLY begins to receive traffic
 if mysql01 is down. The problem with this however is that once mysql01 is
 back online it begins to receive traffic gain. I would like mysql02 to stay
 as the “primary” until mysql02 fails, so basically if mysql01 goes down
 mysql01 becomes “backup.



 I didn’t see much in the docs on how to do this, however i could have
 missed it


Brian, while HAProxy can load balance any protocol, my suggestion to you
would be to look into Heartbeat to perform this task for you. It does not
load balance like HAProxy, but allows a shared IP address to be migrated
between your two nodes. Once you are using Heartbeat, you can adjust the
stickyness of the MySQL resource to keep it from immediately failing back
to the original primary node. For me, Heartbeat has worked very well with
both MySQL and PostgreSQL. Not only can it migrate the IP address, but you
can also put other scripts or services under it's control so that failing
over can also toggle replication settings or anything else you need done.

I think in this case Heartbeat is the tool better suited for the job than
HAProxy.

I personally use Heartbeat with the Pacemaker cluster resource manager.
There are a ton of how-to articles for MySQL+Heartbeat out there.


RE: MySQL LB / Backup Config

2011-05-07 Thread Brian Carpio
Ben,

Thanks for the info. Yes I use heartbeat on my LBs but I guess I never 
considering using it on the MySQL servers, but it sounds like a good idea.

Brian

From: Ben Timby [mailto:bti...@gmail.com]
Sent: Saturday, May 07, 2011 11:22 AM
To: Brian Carpio
Cc: haproxy@formilux.org
Subject: Re: MySQL LB / Backup Config

On Fri, May 6, 2011 at 5:41 PM, Brian Carpio 
bcar...@broadhop.commailto:bcar...@broadhop.com wrote:
Hi,

I have a very simple setup for doing load balancing for MySQL DBs.

listen mysql_proxy vip01:3306
mode tcp
option tcpka
balance roundrobin
server mysql01 mysql01:3306 weight 1 check inter 10s rise 1 fall 1
server mysql02 mysql02:3306 weight 1 check inter 10s rise 1 fall 1 
backup

I am using the backup option so that mysql02 ONLY begins to receive traffic if 
mysql01 is down. The problem with this however is that once mysql01 is back 
online it begins to receive traffic gain. I would like mysql02 to stay as the 
primary until mysql02 fails, so basically if mysql01 goes down mysql01 
becomes backup.

I didn't see much in the docs on how to do this, however i could have missed it

Brian, while HAProxy can load balance any protocol, my suggestion to you would 
be to look into Heartbeat to perform this task for you. It does not load 
balance like HAProxy, but allows a shared IP address to be migrated between 
your two nodes. Once you are using Heartbeat, you can adjust the stickyness 
of the MySQL resource to keep it from immediately failing back to the original 
primary node. For me, Heartbeat has worked very well with both MySQL and 
PostgreSQL. Not only can it migrate the IP address, but you can also put other 
scripts or services under it's control so that failing over can also toggle 
replication settings or anything else you need done.

I think in this case Heartbeat is the tool better suited for the job than 
HAProxy.

I personally use Heartbeat with the Pacemaker cluster resource manager. There 
are a ton of how-to articles for MySQL+Heartbeat out there.


RE: MySQL LB / Backup Config

2011-05-07 Thread Mike Hoffs


Use it in combo with drbd and u dont have to make a complex mysql cluster to 
synchronise your data. Set good commit flush time and data loss of hardware 
failure is very minimum.
 
 
Met een vriendelijke groet,   
 

Mike Hoffs
 

Van: Ben Timby [mailto:bti...@gmail.com] 
Verzonden: zaterdag 7 mei 2011 19:22
Aan: Brian Carpio
CC: haproxy@formilux.org
Onderwerp: Re: MySQL LB / Backup Config
 

On Fri, May 6, 2011 at 5:41 PM, Brian Carpio bcar...@broadhop.com wrote:


Hi,
 
I have a very simple setup for doing load balancing for MySQL DBs. 
 
listen mysql_proxy vip01:3306 
mode tcp 
option tcpka
balance roundrobin
server mysql01 mysql01:3306 weight 1 check inter 10s rise 1 fall 1
server mysql02 mysql02:3306 weight 1 check inter 10s rise 1 fall 1 
backup
 
I am using the backup option so that mysql02 ONLY begins to receive traffic if 
mysql01 is down. The problem with this however is that once mysql01 is back 
online it begins to receive traffic gain. I would like mysql02 to stay as the 
“primary” until mysql02 fails, so basically if mysql01 goes down mysql01 
becomes “backup. 
 
I didn’t see much in the docs on how to do this, however i could have missed it 


Brian, while HAProxy can load balance any protocol, my suggestion to you would 
be to look into Heartbeat to perform this task for you. It does not load 
balance like HAProxy, but allows a shared IP address to be migrated between 
your two nodes. Once you are using Heartbeat, you can adjust the stickyness 
of the MySQL resource to keep it from immediately failing back to the original 
primary node. For me, Heartbeat has worked very well with both MySQL and 
PostgreSQL. Not only can it migrate the IP address, but you can also put other 
scripts or services under it's control so that failing over can also toggle 
replication settings or anything else you need done.

I think in this case Heartbeat is the tool better suited for the job than 
HAProxy.

I personally use Heartbeat with the Pacemaker cluster resource manager. There 
are a ton of how-to articles for MySQL+Heartbeat out there.