[strongSwan] Advice on Scaling up / out strongswan
Martin Willi
martin at strongswan.org
Thu Aug 8 09:53:06 CEST 2013
Hi Andy,
> Are there any good resources on scaling up / i.e. At what point does
> throwing tin and string at an instance stop being effective (we are
> thinking virtualized infrastructures here).
First have a look at IKE_SA lookup tuning [1]; this is something you
definitely have to consider for this many tunnels.
Logging is often a bottleneck as well, see [2]. By default charon logs
some important events to the syslogger authpriv facility. For security
reasons some sysloggers sync these messages directly to disk. This is
very I/O intensive, and you definitely don't want that.
If you use synchronous blocking operations (which are: RADIUS
authentication and CRL/OCSP fetching), you'll also have to consider
thread count and job management [3].
And please be aware: the ipsec.conf configuration backend does not scale
well. If you have more than a dozen connection definitions, this slows
things down significantly.
> What about scale out? I have read some about clustering - but have come
> to the conclusion that this is quite difficult within strong swan, so
> maybe DNS load balancing with sticky session is more appropriate?
Handling 70K tunnels should be doable on a single box if you have some
decent hardware (but requires appropriate configuration). But usually
you are limited to a few hundred Mbit/s ESP processing, so this might be
a limiting factor.
Our HA solution [4] works fine for load sharing. It isn't trivial,
though, and currently supports two nodes only. It supports live tunnel
migration should one node fail (or is under maintenance), which any
other (generic) load balancing mechanism can't.
DNS load balancing is certainly an option as well, but the options to
provide high availability are limited. Any other IP based load-balancing
mechanism might work as well.
The most CPU-expensive operations are always public key computations,
mostly the DH exchange. See [5] for some numbers about key strength and
the required cycles.
> What about load testing - I know about the strongswan load tester, but
> am interested in what realworld overhead is placed on the VPN headend
> by pushing traffic (and therefore encrypting it).
load-tester [6] is a powerful tool to test IKE performance, and I highly
recommend to use it for testing such a setup. It allows you to do
profiling on the tested host and find bottlenecks.
It currently can't simulate ESP traffic, though, we don't have any tools
for that. You'll have to script iperf or something, or switch to
commercial tools.
Kind Regards
Martin
[1]http://wiki.strongswan.org/projects/strongswan/wiki/IkeSaTable
[2]http://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration#Performance-consideration
[3]http://wiki.strongswan.org/projects/strongswan/wiki/JobPriority
[4]http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability
[5]http://wiki.strongswan.org/projects/strongswan/wiki/PublicKeySpeed
[6]http://wiki.strongswan.org/projects/strongswan/wiki/LoadTests
More information about the Users
mailing list