Hi,
Similar to what Christian asked about a few days ago I would like help
to summarize the recommendations for running a haproxy as a SSL LB on
a multi cpu, multi core machine.
I have a machine with two sockets equipped with Intel Xeon E5-2680 v4.
56 cores in total with HT enabled, 28 with HT disabled.
Summary(correct me where I'm wrong):
Hyperthreading - should be disabled
As for network IRQ pinning, should I not pin the NIC to core 0 of each
CPU? Should I split it up between the cores when doing SSL termination
on most cores?
global
nbproc 28 # equal to the number of none HT cores (28 in my case)
# cpu-map's equal to the number of non HT cores.
# (didn't see any cpu-map in Christians configuration, is it not
needed anymore?)
cpu-map 1 0
cpu-map 2 1
...
cpu-map 28 27
frontend https
bind :443 ssl crt /etc/ssl/xx.pem process 1
....
bind :443 ssl crt /etc/ssl/xx.pem process 28
# should I omitt process 1/2 and 15/16 here?
# Should I use core 0 on each CPU for backends (proc 1+15) or should I
use core 1(proc 2+16)?
backend x
bind-process 1 15
backend y
bind-process 2 16
backend z
# or should i use a bind-process like the frontend's bind?
bind-process 2
bind-process 16
I just read the release notes for haproxy 1.7. There was mention of
mixing different certificate types under "support of multi-certs".
Previously I would have a tcp-ssl that would send traffic to a ecc
backend and a rsa backend depending on req.ssl_ec_ext, which in turn
would send traffic to a frontend with two sockets, one for each
certificate type.
To something like this (hope my ascii doesn't get messed up).
+-->backend01
+--->backend-ecc+ |
frontend-tcp-ssl:443 |
+--->frontend-https+-->backend02
+--->backend-rsa + |
+-->backend03
Does this mean I can now mix RSA and ECC certificates on the same
frontend and skip the entire frontend-backend-frontend trick?
+-->backend01
|
frontend-https:443+-->backend02
|
+-->backend03
Thanks,
Elias
