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?

    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).

                                +--->backend-ecc+                             |
frontend-tcp-ssl:443 |
                                +--->backend-rsa +                             |


Does this mean I can now mix RSA and ECC certificates on the same
frontend and skip the entire frontend-backend-frontend trick?



Reply via email to