Configuring Virtual System Load Sharing

Introduction

VSXClosed Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. Clusters can efficiently balance network traffic load by distributing active Virtual Systems between VSX ClusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Members.

This capability is known as Virtual System Load Sharing (VSLS).

Virtual System Load SharingClosed VSX Cluster technology that assigns Virtual System traffic to different Active Cluster Members. Acronym: VSLS. is a cluster technology that assigns traffic for Virtual Systems to different Active VSX Cluster Members, which has these benefits:

  • Capacity: VSLS leverages the cluster machines to handle greater network volume by efficiently dividing the load.

  • Redundancy: VSLS gives full redundancy by maintaining connectivity for all Virtual Systems even when individual VSX Cluster Members fail.

  • Scalability: VSLS provides linear scalability for throughput and session rate.

  • Cost Effectiveness: A VSLS cluster uses standard network switches to get cost effective Load Sharing.

  • Ease of Configuration: Virtual Systems are automatically distributed between all the VSX Cluster Members - no special configuration is required.

  • Priority Designation: Mission-critical Virtual Systems can be separated from the other Virtual Systems to utilize better bandwidth and resources.

  • System Scalability: Every VSX Cluster MemberClosed Security Gateway that is part of a cluster. added to the cluster increases the overall system capacity and redundancy.

Note - These Virtual Devices are not supported when the Per Virtual SystemClosed Virtual Device on a VSX Gateway or VSX Cluster Member that implements the functionality of a Security Gateway. Acronym: VS. state is enabled:

  • Virtual Routers

  • Virtual Switches without physical or VLAN interfaces

In an example deployment scenario with three VSX Cluster Members, each with three Virtual Systems: an equalized Load Sharing deployment might have one Active Virtual System on each VSX Cluster Member.

Item

Description

 

Item

Description

1

VSX Cluster Member 1

 

8

Virtual System 2 is Backup

2

VSX Cluster Member 2

 

9

Virtual System 3 is Active

3

VSX Cluster Member 3

 

10

Virtual System 1 is Backup

4

Virtual System 1 is Active

 

11

Virtual System 2 is Active

5

Virtual System 2 is Standby

 

12

Virtual System 3 is Standby

6

Virtual System 3 is Backup

 

Sync Network

7

Virtual System 1 is Standby

 

 

 

A different member hosts the active peer for each Virtual System. This distribution spreads the load equally between the VSX Cluster Members.

When you create a Virtual System, VSX automatically assigns Standby and Backup states to the applicable peers and distributes them between the other VSX Cluster Members.

In the event that a VSX Cluster Member fails, VSLS directs traffic destined to affected Virtual Systems to their fully synchronized Standby peers, which then become Active. At the same time, a Backup Virtual System switches to Standby, and synchronizes with the newly Active Virtual System.

In the event that an individual active Virtual System fails, it immediately fails over to its Standby peer and one of its Backup peers becomes the Standby, synchronizing with the newly Active peer.

VSLS lets administrators manually assign Virtual Systems to specified VSX Cluster Members, or lets VSX automatically assign Virtual System traffic dynamically.

Requirements

All Virtual Systems in all VSX Cluster Members must have direct connectivity with each other.

Connectivity must be accomplished using switches or VLAN connections.

This is required for detecting and assigning Virtual System states.

Virtual System Priority

Virtual System priority refers to a preference regarding which VSX Cluster Member hosts a Virtual System's Active, Standby, and Backup states.

This preference is expressed as an integer value.

Priority

Definition

0

Highest priority, indicating the cluster designated to host the Virtual System Active state.

1

Second highest priority, indicating the member designated to host the Virtual System Standby state.

> 1

Lower priorities, indicating the VSX Cluster Members designated to host a Virtual System Backup state.

The VSX Cluster Member assigned priority 2 is the first to switch the Virtual System to the Standby state in the event of a failure of either the Active or Standby Virtual System.

A VSX Cluster Member assigned priority 3 is the next in line to come online in the event of another failure.

You can change the priority designation with the "vsx_util vsls" command on the Management ServerClosed Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server..

Virtual System Weight

Because not all Virtual Systems are equal in terms of traffic and load, VSLS allows you to assign "weights" to individual Virtual Systems.

The weight of a Virtual System affects the dispersal pattern of other Virtual Systems across VSX Cluster Members.

When you assign a heavier weight to a Virtual System gives it a larger share of resources on a specific VSX Cluster Member, and disperses the other Virtual Systems to other VSX Cluster Members.

By default, all Virtual Systems are assigned an equal weight factor of 10.

You can change the weight factor with the "vsx_util vsls" command on the Management Server.

Virtual System States

VSLS adds a Backup state to the existing Active and Standby states.

The Backup state contains the latest configuration settings for each Virtual System, but does not receive state table synchronization.

The figure below illustrates the relationship between Virtual System states.

Item

Description

1

VSX Cluster with 3 Cluster Members, each running 3 Virtual Systems (2, 3, and 4)

2

Virtual System 1 on VSX Cluster Member 1 is Active

3

Virtual System 1 on VSX Cluster Member 2 is Standby

4

Virtual System 1 on VSX Cluster Member 3 is Backup

5

Policy updates only

6

State tables are synchronized

Each Virtual System peer in a VSLS cluster is replicated on all VSX Cluster Members, and each copy exists in a different state.

The Active and Standby states are synchronized, so that the Standby peer can immediately become Active in the event of a failure of the Active Virtual System or VSX Cluster Member.

When this happens, the Backup peer becomes the Standby, and immediately synchronizes with the new Active Virtual System.

VSLS reduces the load on the synchronization network by not synchronizing the Backup Virtual System state tables with the Active Virtual System until a failover occurs.

Normalized VSLS Deployment Scenario

For example, you can have three VSX Cluster Members, each with three Virtual Systems.

In this configuration, an equalized Load Sharing deployment could have one Active Virtual System on each VSX Cluster Member.

Item

Description

 

Item

Description

1

VSX Cluster Member 1

 

8

Virtual System 2 is Backup

2

VSX Cluster Member 2

 

9

Virtual System 3 is Active

3

VSX Cluster Member 3

 

10

Virtual System 1 is Backup

4

Virtual System 1 is Active

 

11

Virtual System 2 is Active

5

Virtual System 2 is Standby

 

12

Virtual System 3 is Standby

6

Virtual System 3 is Backup

 

Sync Network

7

Virtual System 1 is Standby

 

 

 

A different VSX Cluster Member can host the Active state of each Virtual System.

This distribution of Virtual Systems spreads the load between the VSX Cluster Members.

When a Virtual System is created, the system automatically creates Standby and Backup states and distributes them between the other VSX Cluster Members.

VSX Cluster Member Failure Scenario

In the event that a member fails or experiences a connectivity problem, VSLS detects the problem and routes traffic for the affected Virtual Systems to their corresponding Standby Virtual Systems.

Standby Virtual Systems, which are fully synchronized with their active peers, change immediately to the Active state and preserve active connections.

At the same time, the backup Virtual Systems switch to Standby, and synchronize fully with the newly active Virtual Systems.

Item

Description

 

Item

Description

1

VSX Cluster Member 1

 

8

Virtual System 2 is Standby

2

VSX Cluster Member 2

 

9

Virtual System 3 is Active

3

VSX Cluster Member 3

 

10

Virtual System 1 is Standby

4

Virtual System 1 is Down

 

11

Virtual System 2 is Active

5

Virtual System 2 is Down

 

12

Virtual System 3 is Standby

6

Virtual System 3 is Down

 

Sync Network

7

Virtual System 1 is Active

 

Network Traffic

In this scenario, VSX Cluster Member 1 fails and its Active and Standby Virtual Systems fail over to VSX Cluster Member 2 and VSX Cluster Member 3.

The Active Virtual System (VS1) moves to VSX Cluster Member 2 and directs all VS1 traffic itself.

Its Backup peer on VSX Cluster Member 3 synchronizes with the new Active Virtual System and becomes the Standby.

VS2 on VSX Cluster Member 2 becomes the Standby and synchronizes with the Active peer on VSX Cluster Member 3.

For VS3, the Active and Standby peers remain the same.

Virtual System Failure Scenario

In a failure scenario where an active Virtual System fails on one member, but the Standby and Backup Virtual Systems remain up: the Active Virtual System fails over to its Standby peer, and its Backup becomes the Standby.

The new Standby synchronizes with the new Active member.

Item

Description

 

Item

Description

1

Member 1

 

8

VS 2 Backup

2

Member 2

 

9

VS 3 Active

3

Member 3

 

10

VS 1 Standby

4

VS 1 Down

 

11

VS 2 Active

5

VS 2 Standby

 

12

VS 3 Standby

6

VS 3 Backup

 

Sync Network

7

VS 1 Active

 

 

 

All other Virtual Systems continue to function as usual, and no failover occurs.

Failure Recovery

When the failed VSX Cluster Member or Virtual System comes back online, the system returns to its original Load Sharing configuration.

Configuring a VSX Cluster in VSLS Mode

Viewing VSLS Status

To view the current VSLS status and Virtual System distribution between VSX Cluster Members, select Display current VS Load Sharing configuration from the VSLS menu.

Distributing Virtual Systems Between VSX Cluster Members

The primary advantage of VSLS is that it distributes Active, Standby and Backup Virtual Systems between VSX Cluster Members to maximize throughput and user response time.

You can distribute Virtual Systems in one of these ways:

Exporting and Importing VSLS Configuration

When working with large scale VSLS deployments consisting of many Virtual Systems, multiple VSX Cluster Members, using the vsx_util command on the Management Server to do configuration tasks can be quite time consuming.

To let administrators to efficiently configure such deployments, VSX supports uploading VSLS configuration files containing configuration information for all Virtual Systems directly to Management Servers and VSX Cluster Members.

This capability offers the following advantages:

  • Fast VSLS configuration of large-scale deployments with many Virtual Systems and VSX Cluster Members.

  • Efficient migration and scalability for complex deployments.

  • External backup of VSLS configurations.

VSLS configuration files are CSV files that are editable using a text editor or other applications, such as Microsoft Excel. You can use the configuration file to change quickly the weight and VSX Cluster Member priority for each Virtual Systems in the list.

Note - You cannot use the VSLS configuration file to add or remove VSX Cluster Members. You must use the applicable vsx_util commands to do this.

You can use the VSLS configuration file to change member priorities for Virtual Systems after adding or removing a VSX Cluster Member.

Virtual Routers in VSLS Mode

From R81, you can configure Virtual Routers in VSLS mode.

Description of Virtual Router Groups

To ensure traffic flow during a VSX Cluster failover, a Virtual RouterClosed Virtual Device on a VSX Gateway or VSX Cluster Member that functions as a physical router. Acronym: VR. and all Virtual Systems that connect to it belong to the same Virtual Router Group.

The Virtual Router in a Virtual Router Group manages all Virtual Systems in that Virtual Router Group. It makes sure all Virtual Systems are Active on the same VSX Cluster Member as the Virtual Router.

If at least one Virtual System or the Virtual Router in the affected Virtual Router Group fail, all Virtual Systems and the Virtual Router in the same Virtual Router Group fail over from the affected VSX Cluster Member to another VSX Cluster Member.

Important:

  • A Management Server creates the corresponding Virtual Router Group automatically when you create a Virtual Router object.

  • You can connect a Virtual System to only one Virtual Router.

  • The cluster state of all members of the same Virtual Router Group is Active on the same VSX Cluster Member.

  • Changes in the cluster state of Virtual Systems in a Virtual Router Group take effect only after you install the Access Control Policy on the applicable Virtual Systems.

  • Connecting an existing Virtual System to an existing Virtual Router:

    If the cluster state of an existing Virtual System is Active on one VSX Cluster Member, and the cluster state of an existing Virtual Router is Active on another VSX Cluster Member, then after you connect the Virtual System to this Virtual Router and install the Access Control Policy on the Virtual System, it becomes Active on the same VSX Cluster Member as the Virtual Router.

Viewing the existing Virtual Router Groups on a Management Server

Viewing the existing Virtual Router Groups on VSX Cluster Members

VSLS Weights in Virtual Router Groups

When Virtual Systems are connected to a Virtual Router, the weight of the Virtual Router in the corresponding Virtual Router Group is the total sum of all weights of all Virtual Systems.

For Virtual Systems that belong to Virtual Router Groups, outputs of different commands show their weight of as 0 (zero).

For Virtual Systems that do not belong to Virtual Router Groups, outputs of different commands show their real weight (by default, all Virtual Systems are assigned an equal weight factor of 10.).

For example, if a Virtual System "vs1" with the wight 20 and a Virtual System "vs2" with the wight 30 are connected to a Virtual Router "vr", then outputs of different commands show the weight of the Virtual Router as 50.

Note - The total sum of all weights of all Virtual Systems in the same Virtual Router Group cannot be more greater than 100.

Distributing Virtual Systems that belong to a Virtual Router Group between VSX Cluster Members

If it is necessary to distribute manually Virtual Systems between VSX Cluster Members, and these Virtual Systems are connected to a Virtual Router, you must distribute the corresponding Virtual Router between VSX Cluster Members (assign the priority and weight only to this Virtual Router). The Management Server automatically distributes all Virtual Systems in the corresponding Virtual Router Group.

For more information, see Distributing Virtual Systems Between VSX Cluster Members.