VSX Technology

[CyberBreaker]

Hello,

I am a bit new dealing with VSX technology of Checkpoint, I did some labs as well using the DemoPoint but I am a bit confused for some use cases specially when it comes ClusterXL.

As we all know, for us to create a VS we need to register the 2x security gateway to Smart Console as VSX gateways then we bundle them using ClusterXL for HA. Is it possible to have 2x VS inside that VSX gateway and form an HA as well with ClusterXL?

Then once we form the 2x VS in ClusterXL mode, I want it to be in bridge (transparent) mode as well?

Thank you so much.

[G_W_Albrecht]

Did you study Check Point VSX Administration Guide R80.30 p.44 ff yet ?

[CyberBreaker]

Hi @G_W_Albrecht ,

Yes, I read that already but it gives me confusion because some materials such as in video in DemoPoint channel seems to be giving different information.

In the guide it shows you can create 2x VS then do a cluster of that 2x VS but in video, they just create VSX cluster gateway and then they just create 1x VS and seems to be that VS is already in cluster since it is on top of the VSX cluster gateways.

I just want some clarifications about it what is the correct way?

Thanks

[Maarten_Sjouw · Accepted solution]

To give you smoe clarification on your question:
A VS lives on either of the physical cluster members, when either fails it will automatically move to the other box.
VSLS is a different form of VSX clustering and allows you to define where which VS will be running.
You cannot put 2 VS's in a cluster. In other words: You cannot use a VS as a cluster member.

As soon as you put the 2 physical gateways in a VSX cluster you define the way you want to work for that specific cluster, either HA or VSLS. Whichever you choose, there will always be a shadow VS on the other cluster member. Transparent mode (bridge mode) does not change that.

[CyberBreaker]

Hi @Maarten_Sjouw ,

Thanks for the feedback.

Much more clear now, so that VS is understood to be in clusterXL because of the VSX gateway is deployed in cluster. I thought at first it still needs to configure 2x VS then put that VS into cluster.

Thank you so much again for the clarification.

[Muazzam · Accepted solution]

I'll give you an example of how I deployed VSX in past on R77.30. I used 4 physical 23000 series appliances in a cluster. After the base cluster is complete, patched etc. then I started creating new virtual systems. The first VS (call it VS1) becomes "Active" on appliance-1, Standby on appliance-2 and backup on appliance-3 and 4. The second virtual system becomes active on appliance-2, Standby on appliance-1 and backup on appliance-3 and 4. This all took place automatically. I have created 8 virtual systems and each VS is active on one, standby on one and backup on 2 physical appliances. You can change the order (it was not recommended at that time). The fail over is very quick if you need to do maintenance on any of the appliances.

[CyberBreaker]

Hi @Muazzam 

Thanks for the enlightenment. Can I manually set that all VS will be active on GW1 and standby on GW2?

Thanks

[_Val_]

yes you can

[Muazzam]

So I should mention here couple of things.

1. VSX is a great product, it works as designed. There were some performance related issues in R77.30 that are (by reading the R80.20 documents) fixed now. I have not used VSX in R80.20.

2. I had three 4-node clusters. On one of the clusters there were performance issues. Upon checking I found out that the 2 most resource intensive database clusters ended up on the same physical node (if you start adding new VS's, it is like a round-robin, Ex: for a 4-node cluster first VS will be on active on node-1 and fifth VS will also be active on node-1). I checked with diamond support, they were not recommending the manual adjustment but for our case they said we can do that if we like. It was a simple process and I moved around different VS's - change their physical node for the "Active", "Standby" and "Backup" roles. This was on R80.10.

[_Val_ · Accepted solution]

With VSX, there are two layers of representation.

1. Physical Gateways and clusters. With Multi-Domain Security Management, physical VSX clusters are usually managed from a dedicated "Main" domain server (CMA). Here you define your ClusterXL, management connectivity and NICs available for Virtual System.

2. Virtual Systems. Those are your virtual FWs. In MDSM case, they are spread through multiple "Target" domains. It is enough to define a single VS entity to have it created on all VSX physical gateways. It will be running a HA pair in if you have VSX cluster of two physical GWs. VSLS is a bit more complex case, but the bottom line is: on VS level you do not have to have two VS objects representing a clustered virtual firewall. One is enough.

For more info, refer to VSX admin guide