As explained in the knowledge base of VMware on network load balancing (NLB) multicast mode configuration, you need to manually configure static ARP resolution at the switch or router for each port that connects to the cluster. Deployment of the Microsoft NLB multicast mode in an unknown network environment can prove to be a complex and strenuous task.
With Microsoft NLB unicast mode, you must configure the ESXi/ESX host to not send RARP packets when any of its virtual machines is powered on. That’s why, Microsoft NLB is not working properly in Unicast Mode with VMware.
The SafeKit virtual IP address configuration does not require any special network configuration and the network load balancing can run in any environment. An important feature when the solution must be deployed in an unknown infrastructure: unknown switches or routers, physical servers or virtual servers.
On the previous figure, the Windows/Linux application is running on the 3 servers (3 is an example, it can be 2 or more). Users are connected to a virtual IP address.
The virtual IP address is configured locally on each server in the farm-mode cluster.
The input traffic to the virtual IP address is received by all the servers and split among them by a network filter inside each server’s kernel.
SafeKit detects hardware and software failures, reconfigures network filters in the event of a failure, and offers configurable application checkers and recovery scripts.
The network load balancing algorithm inside the network filter is based on the identity of the client packets (client IP address, client TCP port). Depending on the identity of the client packet input, only one filter in a server accepts the packet; the other filters in other servers reject it.
Once a packet is accepted by the filter on a server, only the CPU and memory of this server are used by the Windows/Linux application that responds to the request of the client. The output messages are sent directly from the application server to the client.
If a server fails, the farm heartbeat protocol reconfigures the filters in the network load balancing cluster to re-balance the traffic on the remaining available servers.
With a stateful Windows/Linux application, there is session affinity. The same client must be connected to the same server on multiple TCP sessions to retrieve its context on the server. In this case, the SafeKit load balancing rule is configured on the client IP address. Thus, the same client is always connected to the same server on multiple TCP sessions. And different clients are distributed across different servers in the farm.
With a stateless Windows/Linux application, there is no session affinity. The same client can be connected to different servers in the farm on multiple TCP sessions. There is no context stored locally on a server from one session to another. In this case, the SafeKit load balancing rule is configured on the TCP client session identity. This configuration is the one which is the best for distributing sessions between servers, but it requires a TCP service without session affinity.
The SafeKit cluster in farm mode is designed for high availability and scalability of services. The configuration focuses on distributing incoming traffic across both nodes simultaneously:
Monitoring a cluster in farm mode provides visibility into the Active-Active nature of the infrastructure, where all nodes contribute to the application’s performance (showing 2 nodes in this example):
Beyond simple status icons, the interface provides one-click node management, allowing you to manually stop or start a node for planned maintenance while the shared Virtual IP automatically redistributes traffic without interrupting user activity.
Explore SafeKit: Features, technical videos, documentation, and free trial
| Resource Type | Description | Direct Link |
|---|---|---|
| Key Features | Why Choose SafeKit for Simple and Cost-Effective High Availability? | See Why Choose SafeKit for High Availability |
| Use Cases | Explore How SafeKit Ensures the High Availability of Critical Infrastructure | See All Use Cases (OEM Software, Edge Servers, SCADA, and more) |
| Deployment Model | All-in-One SANless HA: Shared-Nothing Software Clustering | See SafeKit All-in-One SANless HA |
| HA Strategies | SafeKit: Infrastructure (VM) vs. Application-Level High Availability | See SafeKit HA & Redundancy: VM vs. Application Level |
| Technical Specifications | Technical Limitations for SafeKit Clustering | See SafeKit High Availability Limitations |
| Proof of Concept | SafeKit: High Availability Configuration & Failover Demos | See SafeKit Failover Tutorials |
| Architecture | How the SafeKit Mirror Cluster works (Real-Time Replication & Failover) | See SafeKit Mirror Cluster: Real-Time Replication & Failover |
| Architecture | How the SafeKit Farm Cluster works (Network Load Balancing & Failover) | See SafeKit Farm Cluster: Network Load Balancing & Failover |
| Competitive Advantages | Comparison: SafeKit vs. Traditional High Availability (HA) Clusters | See SafeKit vs. Traditional HA Cluster Comparison |
| Technical Resources | SafeKit High Availability: Documentation, Downloads & Trial | See SafeKit HA Free Trial & Technical Documentation |
| Pre-configured Solutions | SafeKit Application Module Library: Ready-to-Use HA Solutions | See SafeKit High Availability Application Modules |