---
canonical: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/safekituserguidehtml/documentation/safekituserguideen.htm
---

## 13.6          Virtual IP address - <vip>

The Virtual IP address (VIP) ensures highly
available access to critical applications and, depending on the architecture,
load balancing of this access. The VIP provides a single access point for
clients.

The configuration of a VIP is supported
only:

- In an on-premises cluster
- In a cluster where the servers belong to
  the same subnet, as failover and load-balancing mechanisms rely on Layer 2
  (data link layer) operations

Cloud environments or certain network
configurations therefore do not allow the direct use of a VIP. Refer to section 13.6.3 for
alternative solutions

|  |  |
| --- | --- |
| Commentaire important contour | If you install and run several application modules on the same server, the virtual IP addresses must be different for each application module. |

### 13.6.1      <vip> example in a mirror module

```
In a mirror module:
```

```
 
```

·        
The VIP is active only on the primary node in
the ![](safekituserguideen_fichiers/image358.jpg)PRIM/ALONE(Ready)states

·        
The VIP is automatically transferred to the
secondary node after failover in the event of a primary node failure

The
example below illustrates the configuration of a VIP for a mirror module in an
on-premises cluster.

<vip>

   
<interface\_list>

       
<interface check="on">

          
<real\_interface>

              
<virtual\_addr addr="192.168.1.222"
where="one\_side\_alias" check="on"/>

         
</real\_interface>

       
</interface>

   
</interface\_list>

</vip>

|  |  |
| --- | --- |
| Sous-titres contour | See also the full example in section 15.1. It presents the configuration via the web console along with the corresponding userconfig.xml. |

### 13.6.2      <vip> example in a farm module

In a farm module:

·        
The VIP is active simultaneously on all active
nodes in the ![](safekituserguideen_fichiers/image359.jpg)UP(Ready) state

·        
Traffic is distributed across the nodes. The
distribution is handled by SafeKit at the kernel level, according to the
configured load-balancing rules.

The example below illustrates the
configuration of a VIP with load balancing for a farm module in an on-premises
cluster. TCP connections to the VIP on port 80 are distributed among the nodes,
while all other traffic is denied.

<vip>

   
<interface\_list>

     
<interface check="on">

       
<virtual\_interface type="vmac\_directed">

         
<virtual\_addr addr="192.168.1.222" where="alias"
check="on"/>

       
</virtual\_interface>

     
</interface>

   
</interface\_list>

   
<loadbalancing\_list>

      
<group name="FarmProto">

        
<rule port="80" proto="tcp"
filter="on\_port"/>

      
</group>

   
</loadbalancing\_list>

  </vip>

|  |  |
| --- | --- |
| Sous-titres contour | See also the full example in section 15.2. It presents the configuration via the web console along with the corresponding userconfig.xml. |

### 13.6.3      Alternative to <vip>

Configuring a virtual IP address using a <vip> section in userconfig.xml is supported only:

·        
In an on-premises cluster

·        
In a cluster where the servers belong to the
same subnet

If your cluster does not meet these
requirements, an alternative is to configure the virtual IP address on a load
balancer. The load balancer routes packets to the physical IP addresses of
servers by testing an URL status named health check and managed by SafeKit.

So, SafeKit provides a health check for
SafeKit modules. For this, configure the health check in the load balancer
with:

·        
HTTP protocol

·        
port 9010, the SafeKit web service port

·        
URL /var/modules/*AM*/ready.txt, where *AM* is
the module name

In a mirror module, the health check:

·        
returns OK, that means that the instance is
healthy, when the module state is ![](safekituserguideen_fichiers/image360.png)PRIM(Ready) or  ![](safekituserguideen_fichiers/image361.png)ALONE(Ready)

·        
returns NOT FOUND, that means that the instance
is unhealthy, in all other states

In a farm module, the health check:

·        
returns OK, that means that the instance is
healthy, when the farm module state is  ![](safekituserguideen_fichiers/image362.png)UP (Ready)

·        
returns NOT FOUND, that means that the instance
is out of service, in all other states

See section 16 for a description of how to implement
this solution in the Cloud.

Another alternative is that you implement a
special DNS configuration, and a DNS rerouting command inserted in the SafeKit
restart scripts.

### 13.6.4      <vip> syntax

#### 13.6.4.1  Virtual IP load balancing in farm architecture

<vip
[tcpreset="off"|"on"]
[scriptcontrol="off"|"on"]>

 <interface\_list>

  <interface

   
[check="off"|"on"]

   
[arpreroute="off"|"on"]

   
[arpinterval="60s"]

   
[arpelapse="1200s"]

  >

 

  
<virtual\_interface

   [type=""vmac\_directed"|"vmac\_invisible"]

  
[addr="xx:xx:xx:xx:xx"]

   >

    
<virtual\_addr

     
addr="virtual\_IP\_name or virtual\_IP\_address"

     
[where="alias"]

     
[check="off"|"on"]

     
[connections="off"|"on"]

     />

     …

  
</virtual\_interface>

 
</interface>

 </interface\_list>

 <loadbalancing\_list>

   <group
name="*group\_name*"

    
<cluster>

       
<host name="*node\_name*" power="*value*" />

        …

    
</cluster>

     <rule

      
[virtual\_addr="\*"|"virtual\_IP\_name"|"virtual\_IP\_address"]

      
[port="\*"|"value"]

       
proto="udp"|"tcp"

       
filter="on\_addr"|"on\_port"|"on\_ipid"

     />

     …

  
</group>

   …

 </loadbalancing\_list>

</vip>

|  |  |
| --- | --- |
| Commentaire, ajouter contour | The <vip> tag and subtree **cannot** be changed with a dynamic configuration. |

#### 13.6.4.2  Virtual IP failover in mirror architecture

For on-premises SafeKit cluster:

<vip
[tcpreset="off"|"on"]>

 <interface\_list>

  <interface

   
[check="off"|"on"]

   
[arpreroute="off"|"on"]

   
[arpinterval="60s"]

   
[arpelapse="1200s"]

  >

 

  
<real\_interface>

   
<virtual\_addr

     
addr="virtual\_IP\_name or virtual\_IP\_address"

     
where="one\_side\_alias"  
      [check="off"|"on"]

     
[connections="off"|"on"]

    />

    …

  
</real\_interface>

 
</interface>

  …

 </interface\_list>

</vip>

### 13.6.5      <vip><interface\_list>, <interface>, <virtual\_interface>, <real\_interface>, <virtual\_addr> attributes

|  |  |
| --- | --- |
| <vip |  |
| [tcpreset="off"|"on"] | Before unconfiguring the virtual IP address, all connections with the virtual IP address as IP source are reset. The reset is disabled when set to off.  Default value: on |
| [scriptcontrol=  "off"|"on"] | **Farm only**  With scriptcontrol="on, opening and closing traffic to the VIP is manually controlled within the module scripts (see section 15.2.3.2). For a detailed description, refer to section 15.2.2.5.  Default value: off |
| <interface\_list> |  |
| <interface | Definition of an interface with virtual IP addresses. Define as many <interface> sections as there are network interfaces to configure. |
| [check="off"|"on"] | Set an interface checker on the interface to stop the service and put it in the WAIT state when the interface is down. The name of the interface checker is intf.<network\_IP\_mask> (intf.192.168.0.0).  Default value: on  For more information, see section 13.14. |
| [arpreroute="off"|"on"] | **IPv4 VIP only**  Automatically broadcast gratuitous ARP on virtual IP addresses defined in <real\_interface> section.  Default value: off. |
| [arpinterval="60s"] | **IPv4 VIP only**  Time in seconds between two gratuitous ARP.  Default value: 60s (60 seconds)   |  |  | | --- | --- | | Commentaire, ajouter contour | Time unit supported since SafeKit 8.2.5 (see section 13.1). | |
| [arpelapse="1200s"] | **IPv4 VIP only**  Time in seconds during which gratuitous ARP are sent.  Default value: 1200s (1200 seconds)   |  |  | | --- | --- | | Commentaire, ajouter contour | Time unit supported since SafeKit 8.2.5 (see section 13.1). | |
| [name="*interface name*"] | **Linux only**  You can specify the name of the network interface on which the virtual IP addresses will be set.   Ex.: name="bond0"  Default: no value, SafeKit detects the network interface with virtual IP addresses set on it. |

#### 13.6.5.1  <virtual\_interface>, <virtual\_addr> attributes in farm architecture

Use with farm modules for virtual IP load
balancing:

|  |  |
| --- | --- |
| <virtual\_interface | Definition of virtual IP addresses configured on an Ethernet interface. |
| type=  "vmac\_directed"|  "vmac\_invisible" | ·         type="vmac\_directed"  Advertise the MAC address of one of the servers as the associated mac address, as with normal traffic. No promiscuous mode needed. For details, see section 13.6.7.3.  ·         type="vmac\_invisible"  The virtual MAC address never visible in Ethernet headers to allow broadcasting of switch. Needs promiscuous mode.  For details, see section 13.6.7.2.   |  |  | | --- | --- | | Commentaire important contour | When running SafeKit into a virtual machine, you must turn on the promiscuous mode on the virtual network adapter. See SK-0099 for the procedure to follow for Hyper-V and VMware ESXi. |   Note: can be used for a mirror module with a need of transparent rerouting. |
| [addr="xx:xx:xx:xx:xx"] | Unicast virtual MAC address value.  If not set, default is the concatenation of "5A:FE" (Safe) and the first configured virtual IP address in hexadecimal. Ignored in vmac\_directed mode. |
| <virtual\_addr | Definition of one Virtual IP address. Set as many <virtual\_addr> sections as there are virtual IP addresses on the interface. |
| addr="*virtual\_IP\_name*"|  "*virtual\_IP\_address*" | Name or address of the virtual IP (prefer an IP address to be independent from the name server).  IPv4 or IPv6 address. |
| where="alias" | Configuration for farm module: the virtual IP address is defined on all servers as an alias IP address.  Load balancing rules apply only for this type of virtual IP addresses.  Note: when VMAC is used with a mirror module, set here where="one\_side\_alias" |
| [check="off"|"on"] | Defines an ip checker on the virtual IP address to stopstart the module when the virtual IP is deleted or in conflict. The name of the ip checker is ip.<addr value> (ip.192.168.1.99).  Default value: on  For more information, see section 13.15 |
| [connections="off"|"on"] | Enables counting of the number of active connections on the virtual address. This count is stored in the resource named connections.<virtual addr value> (for example: connections.192.168.1.99) which is assigned every 10 seconds. This value is provided as a guideline only.  Default value: off |
| netmask="*defaultnetmask*" | Linux and IPV4 only. By default, the netmask of the network interface on which the virtual IP address is set.  Set the netmask if there are several netmasks on the interface. |
| </virtual\_interface> |  |

#### 13.6.5.2  <real\_interface>, <virtual\_addr> attributes in mirror architecture

Use with mirror modules for virtual IP
failover:

|  |  |
| --- | --- |
| <real\_interface> | Definition of virtual IP addresses associated with the real MAC address of the interface. |
| <virtual\_addr | Definition of one virtual IP address. Set as many virtual\_addr sections as there are virtual IP addresses on the interface. |
| addr=  "*virtual\_IP\_name*"|  "*virtual\_IP\_address*" | Name or address of the virtual IP (prefer an IP address to be independent from the name server).  IPv4 or IPv6 address. |
| where="one\_side\_alias" | The Virtual IP address will be aliased on the server on which the module becomes PRIM or ALONE. |
| [check="off"|"on"] | Defines an ip checker on the virtual IP address to stopstart the module when the virtual IP is deleted or in conflict. The name of the ip checker is ip.<addr value> (ip.192.168.1.99).  Default value: on  For more information, see section 13.15. |
| [connections="off"|"on"] | Enables counting of the number of active connections on the virtual address. This count is stored in the resource named connections.<virtual addr value> (for example: connections.192.168.1.99) which is assigned every 10 seconds. This value is provided as a guideline only.  Default value: off |
| netmask="*defaultnetmask*" | Linux and IPV4 only. By default, the netmask of the network interface on which the virtual IP address is set.  Set the netmask if there are several netmasks on the interface. |
| </real\_interface> |  |

### 13.6.6      <loadbalancing\_list>, <group>, <cluster>, <host> attributes

Use with farm module.

|  |  |
| --- | --- |
| Sous-titres contour | For many load-balancing examples, see section 15.2. It presents the configuration via the web console along with the corresponding userconfig.xml. |

 

|  |  |
| --- | --- |
| <loadbalancing\_list> |  |
| <group | Definition of a load balancing group. Define as many sections as there are groups.   |  |  | | --- | --- | | Sous-titres contour | See multi group example in section 15.2.2.4. | |
| name="*group\_name*" | Name of the load balancing group. |
| <cluster | Optional definition of the server set on which the load current group balancing will be applied. If no <cluster> section is defined, the rules apply to all servers of the farm. |
| <host | Definition of one node in the cluster. Define as many hosts sections as there are nodes configured for the module. |
| name="*node\_name*" | Define the name of the host. *node\_name* must be the name of a node name set into the SafeKit cluster configuration (see section 12). |
| power="*value*" | Relative weight to apply to the current node in this load balancing group’s cluster. Can be equal to 0, which means no traffic will be dispatched to this node. See section 13.6.7.4 for more information. |
| </cluster> |  |
| <rule | Definition of a load balancing rule for the group. Define as many sections as there are load balancing rules for this group. |
| [virtual\_addr=  "\*" |  "*virtual\_IP\_address*"|  "*virtual\_IP\_name*"] | Virtual IP name or address scope of the rule.  By default, all virtual IP addresses: \* |
| [port="\*"|"*value*"] | TCP or UDP port to which the load balancing rule applies.  By default, all ports: \* |
| proto="udp" | "tcp" | "arp" | ·         proto="udp"  Load balancing rule applies to the UDP protocol.  ·         proto="tcp"  Load balancing rule applies to the TCP protocol.  ·         proto="arp" **only with** filter="on\_addr" **and** vmac\_directed  Load balancing rule for responses to IP ↔ MAC resolution requests (ARP for IPv4, Neighbor Discovery for IPv6). See section 13.6.7.3 for details. |
| filter=  "on\_addr" |   "on\_port" |   "on\_ipid" | ·         filter="on\_addr"  Load balancing criteria is the source IP address (client, far end of the connection)  ·         filter="on\_port"  Load balancing criteria is the source port (client, far end of the connection).  ·         filter="on\_ipid"  Load balancing is made on the client ip\_id at input.  Useful for UDP. No sense for TCP and for IPv6 addresses. |

### 13.6.7      <vip> Load balancing description

#### 13.6.7.1  <vip> prerequisites

See network prerequisites described in section 2.3.2.

#### 13.6.7.2  What is the vmac\_invisible type?

When type="vmac\_invisible", a virtual MAC address is mapped on the virtual IP address with a
unicast MAC Ethernet address on several network nodes. When a network device
tries to resolve the virtual IP address into its corresponding MAC address, the
SafeKit servers respond with the virtual MAC address. However, SafeKit servers use
its physical MAC address to communicate. To “see” the packets sent to the
virtual MAC address the interface is set to promiscuous mode. So, the virtual
MAC address is invisible to layer 2 network devices.  Ethernet switches therefore
forward virtual MAC address directed packets to all the ports in the same vlan
as the source, reaching all the servers of the farm. A kernel module running on
each farm server is responsible for filtering out the packets that should not
be processed by a given farm node, according to the load balancing rules
defined.

With the virtual MAC address technology,
the failover time is null. There is no network rerouting after a failure: all
network equipment keeps their mapping virtual IP address, virtual MAC address.

|  |  |
| --- | --- |
| Commentaire important contour | When running SafeKit into a virtual machine, you may have to turned on the promiscuous mode on the virtual network adapter. See SK-0099 for the procedure to follow for Hyper-V and VMware ESXi. |

To test a virtual MAC address in your
network, see section 4.3.7.

#### 13.6.7.3  What is the vmac\_directed type?

The configuration type="vmac\_directed" modifies the behavior of the filter. In this mode, there is no
virtual MAC; from the outside, the virtual IP (VIP) behaves like a normal IP
address:

·        
Clients send IP ↔ MAC resolution
requests for the VIP (ARP for IPv4 and Neighbor Discovery for IPv6).

·        
Each server responds to the request with its own
MAC address. To avoid multiple responses, add the following load balancing
rule:

<loadbalancing\_list>

  <group
name="FarmProto">

     <rule
proto="arp" filter="on\_addr"/>

…

The responses
are distributed among the nodes based on the source address of the request.

·        
The client stores the physical MAC received in
its cache. Any subsequent traffic to the VIP is sent to this address.

·        
The kernel module filters incoming packets
destined for the VIP and forwards them to the server selected by the load
balancing algorithm, whether it is the local node or another node in the
cluster.

The
vmac\_directed mode can introduce a failover delay for clients that have cached
the VIP with the MAC of a server that has become unavailable. This behavior is
like what occurs during VIP failover in a mirror module (with <real\_interface>). The VIP becomes accessible again once the client updates its IP ↔ MAC
resolution for the VIP. Other clients in the cluster are not affected.

When
the VIP is of type IPv4, the clients’ ARP cache is normally updated only when
the ARP entry expires. To speed up this update and minimize the failover delay,
set arpreroute="on" as shown below:

<vip>

 <interface\_list>

  <interface
arpreroute="on" [arpinterval="60s"]
[arpelapse="1200s"]>

  
<virtual\_interface type="vmac\_directed">

…

This option enables the arpreroute
daemon, which sends Gratuitous ARP messages to encourage clients to update
their ARP entries without waiting for them to expire.

By default, the daemon sends Gratuitous ARP
messages every 60 s (arpinterval) for 1200 s (arpelapse).

When the VIP is of type IPv6, no additional
configuration is required. The Neighbor Discovery protocol automatically
handles neighbor detection and updates clients’ caches when a neighbor becomes
unavailable or changes its MAC address.

#### 13.6.7.4  How does load balancing work?

On all the servers of the farm, the load
balancing algorithm filters received packets according to the identity of the
sender. The criteria to check is defined by configuration in userconfig.xml: client IP address, client port… (i.e.: level 3 load balancing), or
requestor address (arp rules, i.e., level 2 load balancing). The criteria are hashed
into a value representing the server on which the packet is to be accepted.

When a server fails, the membership
protocol reconfigures the filters to re-balance the traffic of the failed
server on the available servers.

Each server can have a power (=1, 2…) and
then takes more or less traffic. The power is implemented by the number of bits
set to 1 in the hash table (a bitmap of 256 bits).

|  |  |
| --- | --- |
| Sous-titres contour | A bitmap example is given in section 4.3.5. |