|
|
|
In This Section: |
This chapter presents a conceptual overview of VSX cluster deployments, with emphasis on clustering features and their application. This discussion assumes that the reader is familiar with network cluster applications and environments, particularly ClusterXL.
The Cluster Management chapter provides detailed configuration procedures, including instructions for enabling and using all VSX clustering features.
VSX clusters provide redundancy and load sharing features for Virtual Systems and other virtual devices. A VSX cluster consists of two or more identical, interconnected VSX Gateways that ensure continuous data synchronization.
VSX High Availability ensures continuous operation by means of transparent gateway failover. Virtual System Load Sharing (VSLS) enhances system performance by distributing active Virtual Systems amongst cluster members.
The advantages of using clusters in a VSX environment include:
VSX clustering is based on Check Point ClusterXL concepts. This section reviews these concepts, and then demonstrates how these principles apply to VSX virtualization.
In typical Security Gateway deployment, a cluster consists of two or more identical, interconnected physical Security Gateways that provide redundancy and/or Load Sharing. This cluster behaves as a single Security Gateway and is assigned its own IP address, which is known as its cluster IP or virtual IP. This cluster IP address is distinct from the physical IP addresses of its cluster members, which are hidden from the networks connected to the cluster.
Traffic from external networks or the Internet directed to the internal networks arrives at the external cluster IP address. Depending on the clustering mode (High Availability or Load Sharing), a designated cluster member receives the traffic and performs the required inspection. After inspection, traffic is either sent to its destination on the internal network, or dropped.
Internal networks send traffic destined for the Internet or external networks, to the cluster IP address. This traffic is processed by the designated cluster member, inspected, and forwarded to its external destination.
Each member interface has a unique, physical IP addresses. These IP addresses which are invisible to physical networks, are used for internal communication between members and the management server for such tasks as downloading policies, sending logs and checking the status of individual cluster members.
VSX clusters, like their physical counterparts, connect two or more synchronized Gateways in such a way that if one fails, another immediately takes its place. VSX clusters are defined at two levels:
VSX ensures that Virtual Systems, Virtual Routers, Virtual Switches and their interfaces are provisioned and configured identically on each cluster member. The figure below shows that each cluster member contains identical instances of each virtual device. These identical instances are referred to as peers.
VSX provides the management functionality to support network and security virtualization, including:
As with physical network deployments, advance planning is the key to successfully creating a working network. IP address allocation for a VSX deployment requires particular attention. This section takes you through the basics of IP address allocation for a VSX environment. Your VSX configuration choices affect the number of IP addresses required, both public and private.
VSX IP address allocation is similar to physical networks. Both real and virtual IP addresses are required for network connectivity (internal and external), management, and state synchronization.
VSX simplifies the IP address management task by automatically assigning IP addresses to Warp Links between virtual devices. For example, Warp Links between a Virtual Router and its associated Virtual Systems are created automatically and assigned IP addresses without user intervention.
A VSX cluster network has these components:
The synchronization network is a physical network that carries state synchronization data between cluster members. You configure the synchronization network during the initial VSX cluster definition and can make changes as necessary when adding or removing members.
State Synchronization can be used ClusterXL deployments as well as other OPSEC-certified VSX solutions. The synchronization network must be configured using unique IP addresses that are not used anywhere else in the enterprise network.
The internal communication network is a virtual network that is required for Check Point ClusterXL environments, in addition to the synchronization network. The internal communication network is invisible to external networks and lets cluster members communicate and recognize the state of the environment.
VSX assigns an IP address to the internal communication network during the cluster creation process. This eliminates the need to manually assign an IP address to each cluster member. The default IP address range consists of four class C networks:
IP address: 192.168.2.0
Net mask: 255.255.252.0
You can modify the default IP address using the Gateway Cluster Properties > Cluster Members page of the VSX cluster object, but only before creating Virtual Systems. Once Virtual Systems have been created, the IP range of the internal communication network cannot be modified.
|
Note - To avoid overlapping IP addresses, before creating any virtual devices, make sure the default IP address range of the Internal Communication network is not used anywhere else in the external network. |
Cluster (virtual) IP addresses are the only IP addresses visible to the external network. The assigned cluster IP addresses must correspond to the directly-connected subnet and server as a valid next hop address. These IP addresses are similar to virtual addresses configured across traditional cluster setups.
This section describes VSX High Availability features. In a VSX environment, you can work with one of two High Availability scenarios:
VSX Gateway High Availability: Each cluster member functions as a VSX Gateway and is synchronized with the other members. If one member goes down, it immediately fails over to another member. Likewise, if an individual Virtual System, Virtual Router or Virtual Switch goes down, the entire member fails over to another member. All members and Virtual Systems function in an active/active mode and are continuously synchronized.
VSX Gateway High Availability is the default cluster configuration. All members of a cluster must be configured to use the same clustering mode.
In the above example, member M1 experiences a failure the affects VS1 and all Virtual Systems immediately fail over to member M2.
Virtual System Load Sharing is a cluster technology that assigns traffic for Virtual Systems to different active cluster members, which has these benefits:
|
Note - These virtual devices are not supported when the Per Virtual System state is enabled: - Virtual Routers - Virtual Switches without physical or VLAN interfaces |
This section presents a detailed conceptual overview of ClusterXL Virtual System Load Sharing.
Virtual System Load Sharing is a cluster technology that assigns traffic for Virtual Systems to different active cluster members. This methodology is different from physical cluster load sharing because it is not connection-based. Virtual System Load Sharing is useful for mission-critical deployments, where reserving bandwidth for a particular Virtual System is a priority.
VSLS lets administrators manually assign Virtual Systems to specified cluster members, or lets VSX automatically assign Virtual System traffic dynamically.
|
Note - You cannot configure a VSX ClusterXL in the Load Sharing mode if the cluster contains Virtual Routers. |
Virtual System priority refers to a preference regarding which 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 members designated to host a Virtual System backup state. The cluster member assigned priority 2 will be 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 cluster member assigned priority 3 would be the next in line to come online in the event of another failure. |
You can change the priority designation using the vsx_util vsls command.
Since all Virtual Systems are not 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 cluster members. Assigning a heavier weight to a Virtual System gives it a larger share of a particular member's resources, and accordingly, disperses the other Virtual Systems to other cluster members.
By default, all Virtual Systems are assigned an equal weight factor of 10. You can change the weight factor using the vsx_util vsls command.
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 relationship between Virtual System states is illustrated in the below figure.
Each Virtual System peer in a VSLS cluster is replicated on all 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 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.
For example, you can have three cluster members, each with three Virtual Systems. In this configuration, an equalized Load Sharing deployment could have one active Virtual System on each cluster member.
A different cluster member can host the Active state of each Virtual System. This distribution of Virtual Systems spreads the load among the clustered machines. When a Virtual System is created, the system automatically creates Standby and Backup states and distributes them among the other cluster members.
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 respective 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.
In this scenario, Member 1 fails and its active and standby Virtual Systems fail over to Members 2 and 3. The active Virtual System (VS1) moves to Member 2 and directs all VS 1 traffic itself. Its backup peer on Member 3 synchronizes with the new active Virtual System and becomes the standby.
VS2 on Member 2 becomes the standby and synchronizes with the active peer on Member 3. For VS3, the active and standby peers remain the same.
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.
All other Virtual Systems continue to function normally and no failover occurs.
When the failed cluster member or Virtual System comes back online, the system returns to its original Load Sharing configuration.
By implementing native layer-2 bridging instead of IP routing, you can add Virtual Systems without adversely affecting the existing IP structure.
When in the Bridge mode, Virtual System interfaces do not require IP addresses. You can optionally assign an IP address to the Virtual System itself (not the interfaces) to enable layer-3 monitoring, which provides network fault detection functionality.
VSX supports these Bridge mode models:
The Spanning Tree Protocol is an industry standard technology to prevent loops in high-speed switched networks. To use the STP Bridge mode, you must have STP deployed and properly configured on your network. These STP layer-2 protocols are supported:
See your vendor documentation to learn how to deploy and configure STP on your network hardware.
The Active/Standby Bridge Mode enhances both High Availability (for significant improvements) and Virtual System Load Sharing in VSX clustered environments (VSLS) (for throughput distributed among Virtual Systems).
Active/Standby Bridge Mode has these advantages:
The principal limitation of the Active/Standby Bridge Mode is that it breaks the STP tree structure.
|
Note - When configuring a Virtual System in the Active/Standby Bridge Mode, you should remove Virtual System VLANs from the STP database in the switches. This action prevents delays due to trunk interface failback. |
This section presents illustrative Active/Standby Bridge Mode deployments, which cannot function using a standard STP Bridge mode configuration.
In this deployment, each member connects to pair of redundant switches through a VLAN trunk. All Virtual Systems in a given member share the same VLAN trunk.
With Active/Standby Bridge Mode in High Availability mode, ClusterXL directs traffic to members according to administrator -defined priorities and status. In Virtual System Load Sharing deployments, the system distributes the traffic load amongst members according to your Virtual System Load Sharing configuration.
A three-layer hierarchical model is used in large, high-traffic network environments.
VSX in Active/Standby Bridge Mode is incorporated in the distribution layer, enforcing the security policy.
The routers direct external traffic to the appropriate Virtual System through a segregated VLAN. Inspected traffic exits the Virtual System through a separate segregated VLAN, to the routers and then to internal destinations.
In a VSX cluster, Virtual Switches are also clustered for redundancy. Virtual Switches in the cluster are defined as active/active.
By means of the ClusterXL Control Protocol (CCP), the physical interface connected to the Virtual Switch is monitored. In the event of a failover, all Virtual Systems on standby become active, and send gratuitous ARPs from the warp interface between the Virtual System and the Virtual Switch.
In the above figure, a simplified VSX cluster contains two members, one active, and the other standby. The Virtual Switches within each cluster are active/active. When the physical interface connected to either Virtual Switch fails to respond, a failover occurs.
