Forum Discussion

AlexBCT's avatar
AlexBCT
Icon for Cumulonimbus rankCumulonimbus
Dec 05, 2022
Solved

How useful is SSL mirroring when clustering?

When clustering, persistence mirroring is a no-brainer, and connection mirroring can also be useful under the right circumstances, but how about SSL connection mirroring? (https://support.f5.com/csp/article/K7216) Is there a clear performance benefit for the F5 / Client or a security benefit? 

From what I've heard/read (hardly reliable sources... ;), it may be useful in very large scenarios where you are dealing with very large numbers of SSL sessions and a failover event would otherwise trigger all these SSL connections to re-establish, putting a lot of strain on the system.

At the same time, for many smaller systems, that initial strain might be manageable compared to the additional overhead of the synchronization that the SSL synchronization may not be worth it. Not to mention other issues such as the recently discovered bug that means you have to disable SSL caching. (https://cdn.f5.com/product/bugtracker/ID760406.html) Meaning you are now trading one benefit for another... 

Anybody got any ideas or able to shed any light on it??  Thanks in advance! 

  • Hi, Alex

    Bugs apart (let's assume we live in a perfect world for a minute), I always like to activate mirroring when I know traffic is SSL-based, whether the F5 terminates SSL sessions or not.

    The idea is precisely what you mentioned - making life easier for endpoints, who don't have to recreate all the SSL sessions in the event of a failover. If you don't have SSL termination, or if you do but re-encrypt traffic for the server-side, "endpoints" means client and server. You may not be worried with performance issues on the client machine, but tipically you want to take that load off your servers, even if it means putting a little extra load on the F5 machines.

    About performance on the F5 itself, the only way to know if you are having a big impact is by monitoring. If your system is very underloaded, even when doing mirroring, I would say keep it that way. If you are near any limits (CPU or RAM), disabling mirroring might help if there are a big number of sessions.

    /Mike

4 Replies

  • Hi, Alex

    Bugs apart (let's assume we live in a perfect world for a minute), I always like to activate mirroring when I know traffic is SSL-based, whether the F5 terminates SSL sessions or not.

    The idea is precisely what you mentioned - making life easier for endpoints, who don't have to recreate all the SSL sessions in the event of a failover. If you don't have SSL termination, or if you do but re-encrypt traffic for the server-side, "endpoints" means client and server. You may not be worried with performance issues on the client machine, but tipically you want to take that load off your servers, even if it means putting a little extra load on the F5 machines.

    About performance on the F5 itself, the only way to know if you are having a big impact is by monitoring. If your system is very underloaded, even when doing mirroring, I would say keep it that way. If you are near any limits (CPU or RAM), disabling mirroring might help if there are a big number of sessions.

    /Mike

    • Kai_Wilke's avatar
      Kai_Wilke
      Icon for MVP rankMVP

      I honestly like your idea to make life easier for endpoints. I may revisit my past decisions, because of this clear simple point of view... 😉

      Thanks and Cheers, Kai

  • Hi Alex,

    Your "hardly reliable source" might be right, that it could be a used to flatten performance spikes during failovers, but on the other hand introduces new challenges and performance implications. Its an individual tradeoff decission to make based on a specific setup and workload.... 

    Personally I never considered to enable "Connection" or "SSL connection" mirrorring for HTTPS sites. For other services which are more dependant on the underlying TCP channel and TLS connection (e.g. LDAPS) it makes much more sense to enable...

    Cheers, Kai

  • Kai_Wilke Mike757 

    Many thanks for both insights - it's good to have multiple points of view (and good to know that I wasn't missing something obvious 😉