|
|
|
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 |
Included Topics |
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.
