Changing ClusterXL Configuration Mode from High-Availability to Load-Sharing

[gkamdem]

Dear

We intend to change our cluster configuration mode from  HA  to Load-sharing . I would like to ask based on your experience some guidelines that should be taken into consideration before changing the cluster mode.

We want to change it in order to fix performance issues and high cpu occurences.

This is a cluster of 2 physical appliances (4000) running on R80.10

Thanks in advance

[_Val_]

Two points.

1. There is no LS mode for R80.10 cluster. You would have to go R80.20 and up, with certain HFA levels. Look into sk162637
2. Why to you want to do that in the first place? LS mode may bring some drawbacks, especially if you are looking to improve your overall cluster performance. 

[Wolfgang]

Your main problem, you have to upgrade. Cluster XL Load Sharing is not supported with R80.10. ClusterXL Load Sharing mode in R80.20 and above 

Before you change have look at ClusterXL Load Sharing mode limitations 

I think MOB-blade and VPN are the main limitations of LS.

Wolfgang

[gkamdem]

Hi Wolfgang. Thanks,
The documentation mislead me ! I touht it was supported for Loadsharing unicats, but working with restriction (secureXL) in Loadsharing multicast mode

[_Val_]

What specific part in the documentation is misleading? Can you specify please?

[gkamdem]

it was not specify that LS is not fully supported on R80.10. I am trying to optimize my cluster and need to reduce the high cpu usage that i have. As you said,I am also not sure if LS mode will help on this, but i need to find the root cause of the high cpu first and evaluate the mitigation strategies. The first which came in mind was switching to LS (Active/Active Multicast).
Thanks

[HristoGrigorov]

I am sorry but this is really the last thing you should try. May be try something like this:

- Check underlying network for problems - drops, overruns, errors

- Optimize rule base as much as possible to get more of your traffic accelerated

- Try to re-arrange CPU cores distribution

- If you have TP blades enabled try to disable them one by one to identify which one is causing most CPU usage and try to optimize it

- Try to upgrade to R80.30+

I do not know how much your firewall is overloaded but if these steps do not help then switching to LS cluster won't help either.

There are plenty of performance optimization topics here to start from and most of them are safe to try and really easy to revert if needed.

[_Val_]

@gkamdem We appreciate your feedback. I am forwarding this to the relevant team.

[gkamdem]

thank you for the all the relevant information and the follow up !

[Timothy_Hall]

If you go down the load sharing path, beware of Load Sharing Multicast.  While it is the most efficient load-sharing mode of ClusterXL and can most certainly be made to work, the use of multicast MAC addresses by the cluster will generally cause various traffic-handling problems with the adjacent routers and switches, which usually leads to hardcoding the multicast MAC address into the CAM/forwarding and IP-ARP caches of adjacent switches and routers, respectively.  Load Sharing Unicast avoids this, but the "Pivot" of the cluster must keep traffic balanced between the members which leads to additional CPU overhead on the Pivot system, and extra network utilization on its attached network switchports.

In R80.40 a new ClusterXL mode called "Active-Active" was introduced, which allows an external entity such as OSPF or a load balancing appliance to balance load between the cluster members instead of ClusterXL trying to do it.

[gkamdem]

Thank you all ,

@Timothy_Hall : If i follow you, it means that Loadsharing in Active/Active (multicast) is supported on R80.10. But i still have to consider some points like following. Please correct me if i am wrong.

- multicast mac adresse (static Arp)

- Enabling the Sticky function while disabling the Accelerated path (PXL)

- on the cluster with 2 members, the traffic will be handled by half on each members, thus reducing the cpu usage of each member.  

I found out following regarding the traffic handling in my environment:

         - 26 % traffic is handled by the Accelerated path

         - 3 % traffic is handled by the F2Fed

          - 69 % traffic is handled by the PXL path

Regarding the CPU usage :

 4.3 % US, 7,8 % Sy , 0.0%ni, 24,8 % id, 0.0 % wa, 2.6 % hi, 60,4 5 si , 0.0 % st

Does this means that most traffic is handled by the PXL path, but traffic trough the Accelerate path and  interrupts keep the cpu busy ?

- Considering i wan to try to switch from HA to LS in a maintenance window to test the performance and rollback, Do this resume of switching the mode as on the picture?  Do you have any experience with this switching/rollback ?

thanks in advance !

[Wolfgang]

no ClusterXL LoadSharing with R80.10.

IPSEC VPN not supported with ClusterXL LoadSharing in later revisions.

Wolfgang

[Timothy_Hall]

ClusterXL Load Sharing is supported in R80.10; it was not supported in the initial versions of R80.20 and R80.30 but was added back in via Jumbo HFA subject to the IPSec VPN limitation mentioned in this thread.  Still not a desirable path to go down in my opinion if you can avoid it; load sharing should not be employed to compensate for underpowered individual firewalls.

Also R80.40 introduced a new ClusterXL mode called "Active-Active" which is distinct and separate from "Load Sharing", so using these two terms interchangeably going forward can cause confusion.  Caught myself doing exactly that multiple times while teaching a class last week.  🙂

Enabling SDF in R80.10 and earlier kills all SecureXL acceleration and everything foes F2F/slowpath.  Note that the Sticky Decision Function (SDF) is gone in R80.20+ due to the major overhaul of SecureXL in that revision, and has been replaced with the Cluster Correction Layer mechanism described here: sk169154: Asymmetric connections in ClusterXL R80.20 and higher.  

Your blend of traffic in SXL/PXL/F2F is pretty typical, you might be able to some further optimization but it doesn't look horrible at this point.