1. Clustering

Clustering in Web Security Manager is based on CARP - the Common Address Redundancy Protocol.

CARP works by allowing a group of hosts on the same network segment to share an IP address. Within the group, one host is designated the "master" role and the rest are "backups". The master host is the one that currently "holds" the shared IP; it responds to any traffic or ARP requests directed towards it. If the master fails a backup transparently takes the master role and start responding to traffic.

CARP also allows for configuring a IP load balanced cluster. In such a cluster all the traffic load is shared between the nodes and in case a node fails it will be excluded from the cluster and the remaining nodes will handle traffic for the failed node.

IP load balancing works by utilizing the network itself to distribute incoming traffic to both nodes in the cluster. Each packet is filtered on the incoming carp interface so that only one node in the cluster accepts the packet. The other node will just silently drop it.

1.1. Cluster virtual IP configuration

The Cluster virtual IP configuration section allows for adding new virtual interfaces with virtual IP addresses.

It is important that the exact same number of interfaces are configured on the master and slave and that the interfaces are configured in the same order.

Virtual IP

Virtual IP address of the cluster.

This is the IP address the nodes in the cluster are sharing.

Netmask

The netmask defining the virtual IP's subnet.

The netmask should be the same as the netmask assigned to the IP address of the physical interface to which Inbound Traffic is bound.

Type

Drop down list

The type of the virtual IP.

Options

FAILOVER MASTER and FAILOVER BACKUP

LOADBALANCE MASTER and LOADBALANCE SLAVE

Default

FAILOVER MASTER

To configure a failover IP address, on the master select FAILOVER MASTER and on the slave select FAILOVER BACKUP.

See the examples below for more information.

Announce Proto

Drop down list

The protocol used for CARP announce messages.

In the cluster each node announces its presence every second by sending a message to the other node. If the Slave/backup node does not get an announce message from the Master it will promote itself to master and start responding to network requests targeting the virtual IP it shares with the Master.

This way, if the Master becomes unavailable traffic to the virtual IP will be failed over to the Slave within a maximum of one second.

If a lot of virtual IPs are configured in the cluster the CARP announce messages may generate some unwanted traffic as they are MULTICAST by default. To avoid that and to allow for CARP to work in complex networks CARP announce messages can be sent directly to the peer node using UNICAST.

Options

MULTICAST

UNICAST

Default

MULTICAST

The MULTICAST method is selected by default.

If UNICAST is selected it is necessary to configure the IP address of the corresponding node on each of the nodes in the cluster. See below.

Unicast Peer

Input field

The IP address of the other node in the cluster.

This input field is disabled if MULTICAST is selected. In this case it displays the multicast address which cannot be changed.

Valid input

The IP address directly bound to the physical network interface of the corresponding node in the cluster - i.e. on the TEACHER it should be the LEARNER and vice versa.

Do not enter a virtual IP in this field.

Default value

none

Example

In a cluster the following IP addresses are assigned to the Inbound Interface:

Master: 10.10.10.20, Slave: 10.10.10.21 both with netmask 255.255.255.0

On both nodes a virtual IP, 10.10.10.25, netmask 255.255.255.0 is configured.

The Unicast Peer should be on the Master: 10.10.10.21 and on the Slave: 10.10.10.20.

Type

Input field

Virtual host identifier number of the CARP group.

On each Web Security Manager node VHIDs are required to be unique.

VHIDs identify cluster groups accros Web Security Manager nodes. The same VHIDs are therefore required to be configured on both cluster nodes.

Valid input

An even integer in the range 2-254

Default value

Next available VHID number

1.2. IP load balancing

IP load balancing works by utilizing the network itself to distribute incoming traffic to all carp nodes in the cluster. Each packet is filtered on the incoming carp interface so that only one node in the cluster accepts the packet. The other nodes will just silently drop it.

The IP load balancing mode determines what method is used have incoming traffic distributed to both carp nodes. IP load balancing mode , IP, carp uses a multicast MAC address, so that a switch sends incoming traffic towards both nodes. However, there are a few OS and routers that do not accept a multicast MAC address being mapped to a unicast IP. This can be resolved by using one of the two other options, IP-Stealth or IP-Unicast.

IP

Carp uses a multicast MAC address, so that a switch sends incoming traffic towards both nodes.

Recommended default setting.

IP-Stealth

In this mode carp never sends packets with its virtual MAC address as source.

Stealth mode prevents a switch from learning the virtual MAC address, so that it has to flood the traffic to all its ports.

Please note that activating stealth mode on a carp interface that has already been running might not work instantly. Just wait until the MAC table entry in the switch times out.

Some layer 3 switches do port learning based on ARP packets. Therefore the stealth mode cannot hide the virtual MAC address from these kind of devices.
IP-Unicast

For scenarios where a hub is used it is not necessary to use a multicast MAC and it is safe to use the IP-Unicast mode.

Manageable switches can usually be tricked into forwarding unicast traffic to both cluster nodes ports by configuring them into some sort of monitoring mode.

1.3. Synchronization configuration

When Web Security Manager nodes are running a cluster one of the Web Security Manager nodes can be designated the TEACH role and the slave the LEARN role .

In order to keep load balancing and backup nodes up-to-date with the current configuration the TEACHER is keeping the LEARNER updated with changes to configured websites.

To keep the synchronization packages private in the cluster the messages are encrypted using a password as key. Synchronization messages can be sent using either MULTICAST or UNICAST.

Enable proxy settings synchronization

Check box

Enable or disable proxy settings synchronization.

If enabled, Web Security Manager will synchronize the current ACL database and other parameters with other Web Security Manager nodes.

Mode

Drop down list

Synchronization role.

If set to Teach, this Web Security Manager will multicast the ACL database to other Web Security Manager installations. If set to Learn, this Web Security Manager will update it's ACL database according to synchronization messages from other Web Security Manager installations.

Synchronization settings affects the operation of the Learner. When synchronization is enabled and the node synchronization mode is set to Learn, the node will not sample learn data but wait for the node master to dispatch a policy.

[Note] Note

You need to configure an interface that will be used for synchronization before the ACL database synchronization will be activated.

Password

Input field

Password used for synchronization message authentication.

Valid input

Any string.

A long password is recommended as it do not have to be memorable by humans.

Input example

98974953Q38512432324CU4859229842784

Default value

none

Protocol

Drop down list

Synchronization network protocol.

Options

MULTICAST

UNICAST

Default

MULTICAST

The MULTICAST method is selected by default. This method is the easiest to configure but as the name suggests the messages are sent to all nodes within the network and may not always work in complex networks. To keep network traffic at a minimum and to make things work in complex networks UNICAST should be preferred. This method requires the LEARN node to be specified on the TEACH node. When sending synchronization messages using UNICAST the TEACHER sends the messages directly to the LEARNERS ip address using UDP.

Sync type

Drop down list

How websites are synchronized are synchronized in a cluster.

Options

FULL SYNC

TEMPLATE

Default

FULL SYNC

This option applies to learning nodes and controls how websites are synchronized.

FULL SYNC

Everything, including "Listen IP", backend servers and health checking configuration is synchronized.

For HTTPS websites and HTTP websites configured to listen to a specific IP address it is required that the same IP addresses are configured on the learn node - typically in the form of a Cluster IP address configured for high availability or load balancing. Otherwise configuring the proxy core will fail.

TEMPLATE

When new website configuration is received by slave node: All information, including listen IP is included but website is created with disabled status meaning it will not served by the learning node until the website is enabled in ADC : Virtual Host (Section 1, “Virtual host”).

When synchronizing changes Listen IP, backend server configuration, load balancing settings and health checking configuration will not be synchronized. This allows for synchronizing across datacenters or for synchronizing a cluster that is used in combination with a network load balancer.

Peer(s)

Input field

The IP address(es) of the other node(s) in the cluster.

This input field is disabled if MULTICAST is selected. In this case it displays the multicast address which cannot be changed.

Valid input

The IP address(s) of the corresponding node(s) in the cluster - i.e. on the TEACHER it should be the LEARNER(s) and vice versa.

Note that the IP address should be the IP address assigned to the network interface to which synchronization is bound on the corresponding node.

To synchronize to more than one LEARNER node using UNICAST add a list of LEARNER IP addresses separated by comma or space.

Default value

none

1.4. Cluster configuration examples

Below are given examples of configuring a high availability cluster running in active/passive mode and a "self load balancing" cluster running in active/active mode.

1.4.1. Configuring a load balanced cluster

To configure a load balanced (active/active) cluster of two Web Security Manager nodes do the following:

Node 1 configuration

Create a LOADBALANCE MASTER interface by doing the following:

  1. In Cluster virtual IP configuration enter the virtual IP address of the cluster in the the Virtual IP field.

  2. In Netmask enter the netmask specifying the subnet for the virtual ip.

  3. In the Type drop-down menu select LOADBALANCE MASTER.

  4. In the Announce Proto drop-down select the default MULTICAST

  5. Click the Add virtual IP button.

This will create a Carp interfaces with type LOADBALANCE MASTER.

The interface is assigned an even numbered VHID and two priorities, Priority and Priority Slave. Due to the way IP Loadbalancing is implented with Carp another virtual interface is created in the background. Priority Slave is assigned to the background interface as is a VHID with an un-even number (VHID + 1).

Enable cluster synchronization and designate the role TEACH in the Synchronization configuration section:

  1. Select Enable proxy settings synchronization

  2. Select TEACH in the Mode drop-down.

  3. Enter a password for the cluster in the Password field.

  4. In the Protocol drop-down select the default MULTICAST

  5. Click the Save button.

Node 2 configuration

Create a LOADBALANCE SLAVE interface by doing the following:

  1. In Cluster virtual IP configuration enter the virtual IP address of the cluster (the same as on the master) in the the Virtual IP field.

  2. In Netmask enter the netmask specifying the subnet for the virtual ip.

  3. In the Type drop-down menu select LOADBALANCE SLAVE.

  4. In the Announce Proto drop-down select the default MULTICAST

  5. Click the Add virtual IP button.

This will create a Carp interfaces with type LOADBALANCE SLAVE.

The interface is assigned a VHID and priorities like on the LOADBALANCE MASTER node except that the priorities are mirrored.

Supposing there are no other or an equal amount of CARP interfaces configured on both nodes the VHID on the two nodes should be equal.

On node 1 the LOADBALANCE MASTER interface should have the same VHID as the LOADBALANCE SLAVE interface on node 2.

Otherwise configure the interfaces two achieve the above in CARP interfaces (Section 1.1, “Cluster virtual IP configuration”).

Enable cluster synchronization and designate the role LEARN in the Synchronization configuration section:

  1. Select Enable proxy settings synchronization

  2. Select LEARN in the Mode drop-down.

  3. Enter the same cluster password as for node 1for the cluster in the Password field.

  4. In the Protocol drop-down select the default MULTICAST

  5. Click the Save button.

The cluster can also be configured to synchronize and maintain availability state using UNICAST targeting a specific peer IP see (Section 1.1, “Cluster virtual IP configuration”) for more information.

1.4.2. Configuring a fail-over cluster

To configure a fail-over (active/passive) cluster of two Web Security Manager nodes do the following:

Node 1 configuration

Create a FAILOVER-MASTER interface by doing the following:

  1. In Cluster virtual IP configuration enter the virtual IP address of the cluster in the the Virtual IP field.

  2. In Netmask enter the netmask specifying the subnet for the virtual ip.

  3. In the Type drop-down menu select FAILOVER-MASTER.

  4. Click the Add virtual IP button.

Enable cluster synchronization and designate the role TEACH in the Synchronization configuration section:

  1. Select Enable proxy settings synchronization

  2. Select TEACH in the Mode drop-down.

  3. Enter a password for the cluster in the Password field.

  4. In the Protocol drop-down select the default MULTICAST

  5. Click the Save button.

Node 2 configuration

Create a FAILOVER-BACKUP interface for the same virtual IP by doing the following:

  1. In Cluster virtual IP configuration enter the virtual IP address of the cluster in the Virtual IP field.

  2. In Netmask enter the netmask specifying the subnet for the virtual ip.

  3. In the Type drop-down menu select FAILOVER-BACKUP.

  4. Click the Add virtual IP button.

Enable cluster synchronization and designate the role LEARN in the Synchronization configuration section:

  1. Select Enable proxy settings synchronization

  2. Select LEARN in the Mode drop-down.

  3. Enter the same cluster password as for node 1for the cluster in the Password field.

  4. In the Protocol drop-down select the default MULTICAST

  5. Click the Save button.

The cluster can also be configured to synchronize and maintain fail-over state using UNICAST targeting a specific peer IP see Section 1.3, “Synchronization configuration” and Section 1.1, “Cluster virtual IP configuration” for more information.

1.5. CARP Interfaces

The CARP Interfaces configuration section provides an overview of CARP interfaces and allows for post configuration.

ID

The CARP interface id on the node.

VIP

Virtual IP address of the cluster.

This is the IP address the nodes in the cluster is sharing.

Netmask The netmask defining the virtual IP's subnet.
Proto The CARP announce protocol selected. See above for details.
Peer The Unicast Peer , see above for details.
VHID

Input field

Virtual host identifier number of the CARP group.

On each Web Security Manager node VHIDs are required to be unique.

VHIDs identify cluster groups accros Web Security Manager nodes. The same VHIDs are therefore required to be configured on both cluster nodes.

Valid input

An even integer in the range 2-254

Default value

Next available VHID number

Interface The physical network interface the CARP interface is bound to.
State

State of the CARP interface can be either MASTER or BACKUP.

If a CARP interface with a low priority (automatically set when selecting the types FAILOVER-BACKUP or LOADBALANCE-FAILOVER) is assuming the role of MASTER then probably the original MASTER node is experiencing problems.

Priority

Input field

The priority of the interface in the CARP group.

Do not edit this property unless you are familiar with the CARP protocol.

The priority itself is an abstraction over the advskev CARP parameter. When setting priority advskev is calculated as 254 - priority.

Interfaces of type FAILOVER-MASTER and LOADBALANCE are configured with a high priority and interfaces of type FAILOVER-BACKUP or LOADBALANCE-FAILOVER are configured with a lower priority.

Valid input

An integer in the range 1-254

Default value

FAILOVER-MASTER and LOADBALANCE MASTER: 254

FAILOVER-BACKUP or LOADBALANCE-FAILOVER: 154

1.6. Fail-over status information

If the system is running in a fail-over configuration the following additional information will be displayed.

Virtual IP

Virtual IP address.

Role (config)

Shows the configured role (MASTER or BACKUP) for the specified virtual IP address.

Role (current)

Shows the current role (MASTER or BACKUP) for the specified virtual IP address.

If the current role differs from the configured an error situation has occurred and the role information fields will be blinking red.

Interface

Shows the physical interface the specified virtual IP address is attached to.

Priority

Shows the virtual IP address priority for the physical interface.

© 2005 - 2012 Alert Logic inc.