Migrating DirectAccess from NLB to External Load Balancer


Introduction

Migrating DirectAccess from NLB to External Load BalancerMultiple DirectAccess servers can be deployed in a load-balanced cluster to eliminate single crucial points of failure and to provide scalability for the remote access solution. Load balancing can be enabled using the integrated Windows Network Load Balancing (NLB) or an external physical or virtual load balancer.

NLB Drawbacks and Limitations

NLB is often deployed because it is simple and inexpensive. However, NLB suffers from some serious drawbacks that limit its effectiveness in all but the smallest deployments. For example, NLB uses network broadcasts to communicate cluster heartbeat information. Each node in the cluster sends out a heartbeat message every second, which generates a lot of additional network traffic on the link and reduces performance as more nodes are added. Scalability is limited with NLB too, as only 8 nodes are supported, although the practical limit is 4 nodes. Further, NLB supports only round-robin connection distribution.

External Load Balancer

A better alternative is to implement a dedicated physical or virtual load balancing appliance. A purpose-built load balancer provides additional security, greater scalability (up to 32 nodes per cluster), improved performance, and fine-grained traffic control.

Migrate from NLB to ELB

It is possible to migrate to an external load balancer (ELB) after NLB has already been configured. To do this, follow the guidance provided in my latest blog post on the KEMP Technologies blog entitled “Migrating DirectAccess from NLB to KEMP LoadMaster Load Balancers”.

Migrating DirectAccess from NLB to External Load Balancer

Additional Resources

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

Migrating DirectAccess from NLB to KEMP LoadMaster Load Balancers

Load Balancing DirectAccess with KEMP LoadMaster Load Balancers

DirectAccess Load Balancing Tips and Tricks Webinar with KEMP Technologies

DirectAccess Single NIC Load Balancing with KEMP LoadMaster Load Balancer

Configuring the KEMP LoadMaster Load Balancer for DirectAccess NLS

Enable DirectAccess Load Balancing Video

Implementing DirectAccess with Windows Server 2016 Book

Configuring Multicast NLB for DirectAccess

Introduction

DirectAccess in Windows Server 2012 R2 includes support for load balancing using either Windows Network Load Balancing (NLB) or an external physical or virtual load balancer. There are advantages and disadvantages to each, but NLB is commonly deployed due to its cost (free!) and relative ease of configuration. NLB has three operation modes – Unicast, Multicast, and IGMP Multicast. It may become necessary to change the NLB operation mode depending on the environment where DirectAccess is deployed. This article describes when and how to make those changes.

Default Configuration

When NLB is first configured, the default cluster operation mode is set to Unicast. In this configuration, all nodes in the NLB cluster share the same MAC address. The NLB kernel mode driver prevents the switch from learning the MAC address for any node in the cluster by masking it on the wire. When a frame is delivered to the switch where the NLB cluster resides, without a MAC address to switch port mapping the frame is delivered to all ports on the switch. This induces switch flooding and is by design. It is required for all nodes in the cluster to “see” all traffic. The NLB driver then determines which node will handle the request.

NLB on Hyper-V

Unicast NLB typically works without issue in most physical environments. However, enabling NLB when the DirectAccess server is running on a virtual machine requires some additional configuration. For Hyper-V, the only thing that is required is to enable MAC Address Spoofing on the virtual network adapter as I discussed here. No other changes are required.

NLB on VMWare

For VMware environments, it will be necessary to change the cluster operation mode from unicast to multicast. This is because the VMware hypervisor proactively informs the virtual switch of the virtual machine’s MAC address on startup and during other virtual networking events. When this occurs, all traffic for the NLB Virtual IP Address (VIP) will be delivered to a single node in the cluster. In multicast operation mode, all nodes in the NLB cluster retain their original MAC address and a unique MAC address is assigned to the cluster VIP. As such, there’s no need to prevent the switch from learning the virtual machine’s MAC address.

Configuring Multicast NLB

To enable Multicast NLB, first enable load balancing for DirectAccess using the Remote Access Management console as usual. DO NOT perform the initial configuration of NLB outside of the Remote Access Management console! Before adding another member to the array, open the Network Load Balancing Manager, right-click the cluster and choose Cluster Properties. Select the Cluster Parameters tab and change the Cluster operation mode to Multicast.

Configuring Multicast NLB for DirectAccess

When opening the Network Load Balancing Manager locally on the DirectAccess server, you may receive the following error message:

“Running NLB Manager on a system with all networks bound to NLB might
not work as expected. If all interfaces are set to run NLB in “unicast”
mode, NLB manager will fail to connect to hosts.”

Configuring Multicast NLB for DirectAccess

If you encounter this error message it will be necessary to run the NLB Manager on another host. You can install the NLB Manager on a Windows Server 2012 R2 system by using the following PowerShell command.

Install-WindowsFeature RSAT-NLB

Optionally you can download and install the Windows Remote Server Administration Tools (RSAT) on a Windows desktop client and manage NLB remotely.

Once this change has been made you can add additional DirectAccess servers to the array using the Remote Access Management console.

Additional Configuration

If you cannot communicate with the cluster VIP from a remote subnet, but can connect to it while on the same subnet, it might be necessary to configure static ARP entries on any routers for the subnet where the NLB cluster resides. Often this is required because routers will reject responses to ARP requests that are from a host with a unicast IP address but have a multicast MAC address.

%d bloggers like this: