ElasticXL (R82) vs ClusterXL Load Sharing — what changes in practice (architecture, traffic, sync, a

[WiliRGasparetto]

There has been a lot of discussion lately around ElasticXL in R82. The most common misunderstanding is treating ElasticXL as “just another ClusterXL mode.” It isn’t. ElasticXL changes the operational model (SMO + cloning) and the traffic distribution pattern (pivot-like), while ClusterXL Load Sharing remains the classic model where traffic is distributed directly (multicast/unicast) with Delta Sync for state.

Below is an objective, TAC/field-style comparison — no hype, no overpromising.

1) ElasticXL (R82) — how it works technically

1.1 Architecture and operations

• SMO (Single Management Object): a single SmartConsole object represents the entire cluster.

• Automatic cloning: you install/configure only the first appliance (SMO); additional members automatically clone configuration and software packages from the SMO.

• Scale out/in: the design supports adding/removing members in a simplified way using the same cloning mechanism.

  TAC note: treat this as a controlled change — any topology change can trigger traffic/session redistribution depending on the scenario.

1.2 Limits and Dual Site

• Maximum: 6 appliances per ElasticXL Cluster (3 per site in Dual Site).

• Dual Site: supported natively (geographic resiliency in the ElasticXL model).

1.3 Traffic distribution

• ElasticXL uses a per-site pivot model: the SMO receives traffic and distributes it to other members.

• Only General Distribution Mode is supported.

• This behavior is described as “pivot-like” (similar to the Pivot concept in ClusterXL LS Unicast).

1.4 Sync network (network requirements)

• Strong requirement: a dedicated Layer-2 broadcast domain for Sync.

• VLAN trunk is not supported on the Sync interface.

• Sync traffic is clear-text → a dedicated/isolated network is an operational requirement (L2 isolation, avoid exposure).

1.5 Virtualization

• VSNext only: ElasticXL supports VSNext only (Traditional VSX is not supported on ElasticXL).

1.6 Management

• ElasticXL includes Global Gaia Portal and Global Gaia Clish to manage the cluster as a single unit.

• Documentation mentions support for Gaia REST API in the ElasticXL context.

  Precision note: Gaia API is a Gaia capability; the differentiator here is the global cluster management model, not “API exists vs doesn’t exist.”

2) ClusterXL Load Sharing — the real baseline

2.1 Architecture and modes

• ClusterXL Load Sharing is Active/Active (multiple members process traffic in parallel).

• Load Sharing Multicast and Load Sharing Unicast are the classic modes.

2.2 Traffic distribution

• Load balancing is performed via an algorithm (hash/affinity), and each member receives part of the traffic directly depending on mode/configuration.

2.3 Limits and sync overhead

• Maximum supported: 5 members.

• In practice, it is common to recommend up to 4 for Load Sharing because Delta Sync overhead grows with:

  • member count

  • session/state volume

  • connection churn

• This does not mean 5 “doesn’t work,” but it often means efficiency drops after 4.

2.4 Member changes (operations)

• Adding/removing a member is a planned change and typically manual (configuration + validations).

• It can impact sessions and traffic distribution; a maintenance window is often required depending on the environment.

2.5 Geographic HA

• ClusterXL Load Sharing is not “Dual Site” in the same model ElasticXL provides. For geo HA, there are other technologies/approaches depending on design.

3) Comparison table (TAC-grade)

Capability	ElasticXL (R82)	ClusterXL Load Sharing
Max members	6 (3 per site in Dual Site)	5 (common practice: up to 4 in LS)
Management object	1 object (SMO)	Traditional ClusterXL object
Member onboarding	Automatic cloning from SMO	Manual per-member configuration (planned change)
Traffic distribution	Pivot-like: SMO distributes (General mode only)	Direct LS distribution (Multicast/Unicast)
Sync network	Dedicated L2, no trunk; clear-text sync	Traditional sync model; no ElasticXL-specific restrictions
Dual Site	Yes (native ElasticXL model)	Not in the same model
Virtualization	VSNext only	Traditional ecosystem (with virtualization-related variants/technologies)
Scaling beyond limit	For >6, architectures like Maestro become relevant	>4 often reduces efficiency (Delta Sync)

 

4) When I would choose each (field view)

ElasticXL (R82) makes more sense when:

• You want simplified operations (SMO + cloning, less drift risk).

• Your target scale is up to 6 appliances and you want the ElasticXL Dual Site model.

• You are aligned with VSNext and want the cluster represented as one object.

ClusterXL Load Sharing makes more sense when:

• You want to stay with the mature, traditional LS model (Multicast/Unicast).

• You run a smaller/medium environment where 2–4 members provide sufficient capacity and HA.

• You prefer the model where each member receives traffic directly and accept the traditional operational approach.

 

5) “Gotchas” checklist (where most issues come from)

• ElasticXL Sync: forgetting it requires a dedicated L2 and no trunk → stability problems.

• Dual Site: assuming it behaves like any geo-HA method → it’s a specific ElasticXL model.

• ClusterXL with 5 members: assuming linear scaling → Delta Sync grows, and marginal gains often drop after 4.

[the_rock]

Another great post.

[WiliRGasparetto]

Thank's andy

[Silvan_Nyambu]

This is a good post.

I have a question.

Can you achive dual site with local traffic optimisation when using ElasticXL?

The objective is to deploy site 1 with two gateways in PR and Site 2 with two gateways in DR. These gateways will be the default gateways of my DC servers, meaning same gateway IP addresses in site1&2.

I'd like my resources (servers) in PR to use site1 and resources (servers) in DR to use site2 gateways.

[WiliRGasparetto]

Excellent question!

Yes, it's possible to achieve dual-site local traffic optimization using ElasticXL, provided the network and cluster configuration is done correctly to support Local Traffic Optimization.

If you need a step-by-step guide or configuration details, I can look for more detailed information for your specific scenario.

If you'd like, please tell me the version of your environment so I can provide more precise examples and recommendations!

[WiliRGasparetto]

thinking about this point, I think I'll write another article presenting the possible architectures.

[Silvan_Nyambu]

This would be helpful. I'm planning to deploy R82.10

[WiliRGasparetto]

Thanls

[emmap]

That would require Active/Active support for EXL, which is not an option. A dual site EXL setup is always Active/Standby, and all the IP addresses are owned by the active site. 

[Silvan_Nyambu]

Based on the documentation, that was my initial understanding. However, I verified this in the DemoPoint lab and confirmed that Gateway members on both sites are Active, with the Site 1 SMO acting as the Pivot. At the time, Site 1 had two members and Site 2 had one.

After moving one member from Site 1 to Site 2, the Pivot shifted to Site 2, and the cluster transitioned to a full Active/Active state.

Does this mean the gateways which are active instandby site can't process any traffic?

One gateway per site

Adding gateway 2 to site 1

Two gateways in site 1 and one gateway in site 2

Two gateways in site 2 and 1 gateway site 1. Gateway member 1 in site 2 is the Pivot

[WiliRGasparetto]

Thank you very much, your contribution is very useful for the topic.

[emmap]

Hi

The 'cphaprob stat' output is a little misleading with EXL. What it's showing you is that all the SGMs are Active and ready to go, but it's not showing you the Site state. If you look in your 'insights' output, or if you run 'cinfo overview' from expert mode (or 'show cluster info overview' I think in gclish) you'll see a better output that shows the Site state as well as the per SGM state. You'll see there that Site 1 is Active but Site 2 is Standby. The Pivot member on the active site will only pivot incoming traffic down to other active SGMs in the Active site, not over to the Standby site. The standby site SGMs will not receive any inbound connections. 

Edit: For more about the cinfo command (it's an alias for cluster-cli show info) see:

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_ScalablePlatforms_AdminGuide/Conte... 

[Silvan_Nyambu]

When I hover over the site 2, I can see the "Standby" state and "active" state when I hover over a gateway in site 2.

[israelfds95]

can you run asg monitor?  and bring the output

[emmap]

Yes, so the Site is Standby, the SGM inside that site is Active and ready to go should the Site become Active. The Active SGMs in the Standby site do not receive or process traffic at all. 

[israelfds95]

very nice, good to see this view of your tests @Silvan_Nyambu 

[WiliRGasparetto]

Send the screenshot with the ASG monitor.

[PedroRFernandes]

Well Done, @WiliRGasparetto!

Best Regards,

Pedro Fernandes.