On Wed, Apr 29, 2015 at 03:00:58PM -0600, Shawn Heisey wrote:
> I have an existing load balancer installation that I have been slowly
> migrating from IPVS to haproxy. It's CentOS 6, so many components are
> out of date, such as TLS support.
>
> Once that migration is done, I would like to entirely replace the
> hardware and load an ideal software environment for haproxy.
>
> The new machines have Ubuntu 14, so the openssl version is fairly new,
> but not the newest available. The CPU is an Intel Xeon E5-2430, which
> has built-in TLS acceleration. It has 16GB of memory. The machine is
> dedicated for load balancing.
>
> How can I be sure that openssl is compiled with support for TLS
> acceleration in the CPU?
I don't understand what type of acceleration your talking about. There
are multiple features improving TLS performance such as AES-NI, MULX,
AVX2, etc. Anyway you can use "openssl speed" to compare between the
original lib and your newly built one. You can force some algorithms
to verify specific improvements, such as "openssl speed rsa2048" or
"openssl speed ecdhp256" etc.
> I am compiling haproxy from source. Would you
> recommend that I install a separate and newer openssl from source for
> explicit use with haproxy, and tweak its config for the specific
> hardware it's on?
As I mentionned in the other mail, I still prefer a dynamic build to
make it easier to update it, but I know it's not necessarily easy
because the soname doesn't change between versions...
> The CPU has 6 hyperthreaded CPU cores. I know that haproxy can be run
> in multiprocess mode to take advantage of multiple CPU cores, but is
> that a recommended and stable config?
Yes, but there are a few things that are not shared such as stick-tables
and stats. Also you won't be able to use "peers" to replicate stick-tables
between nodes. And health-checks will be done for each process.
> If it is, then I will do it just
> so I'm taking full advantage of the hardware.
If it's just for SSL performance, you can also have one TLS-only instance
running in multi-process to decipher the traffic and a single process one
for the rest. You just use abstract sockets between the processes, they're
cheaper than TCP and that's all. Example :
global
nbproc 6
listen ssl-offload
bind :443 process 1 crt ...
bind :443 process 2 crt ...
bind :443 process 3 crt ...
bind :443 process 4 crt ...
bind :443 process 5 crt ...
bind :443 process 6 crt ...
server clear abns@haproxy-clear-listener send-proxy-v2
And the other one :
global
nbproc 1
frontend clear-text
bind :80 ...
bind abns@haproxy-clear-listener accept-proxy
...
You can put the two in the same config if you want, but then don't
forget to specify "bind-process 1" in all instances except the first
one. Peers will fail as well (though I have an idea how to fix that).
> I know from the list
> history that stats don't aggregate across processes, but as long as I
> can figure out how to look at all the stats, that shouldn't be a problem.
To access all the stats, simply have different ports bound to different
processes and visit all of them. For the CLI, you can define as many as
you want and specify "process" on the stats line as well to limit the
scope of the socket.
> Is there anything else I should be aware of or think about as I work on
> the OS and software for this replacement hardware?
If you're working on preparing the OS, please *do* verify that conntrack
is properly tuned (large hash table with at least 1/4 of the total number
of sessions). Otherwise under load it will become extremely slow.
Regards,
Willy
