Cluster with only one member

[Micha]

Hi,

We want in the future to have a two firewall cluster, but at the moment only have one firewall (and license).

In order to make it easier in the future to add a second firewall, we want to set it up initially as a cluster.

We configured one interface as "sync" (required by SmartConsole), but the cluster object always is red since ClusterXL is not working (obviously).

Is there a way to have the single firewall ignore the "cluster problems" so the object will be green?

Or is the only way to change it back to a single firewall (cpconfig -> Disable cluster membership for this gateway), add it to SmartConsole as a standalone firewall object,  and in the future perform cpconfig-> re-enable cluster membership?

Note: It is a GCP CloudGuard firewall.

[Vincent_Bacher]

I guess this is the classical "works as designed" behavior and i don't see any reason why a feature "ignore cluster problems" would make sense. So i would prefer using the simple gateway as it is and convert it to cluster later on when purchasing second cluster member device.

[the_rock]

Personally, but again, this is just my own opinion, I would not bother until you are ready to have a working custer. I mean, you can always enable/disable cluster membership option from the cpconfig menu (I know few customers who enabled that initially via default wizard, but then you can toggle it after from the menu, just needs a reboot).

Alternatively, you can then set up all the needed cluster interfaces. I could be mistaken, but if I recall, you only technically need sync interface for functioning cluster. No, I think thats not true, as you need VIP for the cluster IP object, so that would make it 1 + sync, so thats 2.

Best,

Andy

[PhoneBoy]

Forming a cluster requires two or more nodes to be active.
With a single member, there is no cluster, thus it will always appear "red" by design.
I wouldn't enable ClusterXL until you are ready to establish the cluster.

[Bob_Zimmerman]

The headache with moving from a single firewall to a cluster later is you then have to take a hard outage to change the IPs on the interfaces and use the old IPs as VIPs (or to change the routes on all adjacent things). If you start with a single-member cluster, you can add a second member at any time with zero traffic impact. This can be a big deal for locations which don't have qualified people nearby.

[Chris_Atkinson]

Yep but since this is a Cloud deployment and we don't have context of the scale of the deployment I would encourage some further discussion with the local account team, Vsec / Cloudguard cores can be relatively inexpensive.

Also does the topology mandate a traditional cluster vs auto-scale / MIG ?

[PhoneBoy]

That is 100% true.
Hopefully ElasticXL will take some of this pain away.

[the_rock]

Are you saying this would work with elasticXL? if so, that would be pretty cool : - )

Best,

Andy

[PhoneBoy]

In short, yes, it should.

ElasticXL will use much of the same technology that was developed for Maestro and Scalable Platforms.
Unlike with ClusterXL where you have to define the individual members before creating the cluster object, Maestro only requires a single management object, which is nothing more than a standard gateway object.
Members are added via the Orchestrator in Maestro and there will be gclish commands in R82 to add cluster members.

[the_rock]

Cool! But this will ONLY be possible on Maestro, nor regular Gaia gateways?

Andy

[PhoneBoy]

ElasticXL is ultimately replacing ClusterXL on regular gateways.