IT administrators can use Windows NIC teaming for more bandwidth and resilience on their Windows Server 2012 networks.
Connectivity has always been an important consideration for servers, but the continued evolution of data center technologies has placed a new emphasis on efficient networking.
For example, the broad adoption of virtualization allows a server to host numerous bandwidth-intensive workloads while supporting an increasing volume of time-sensitive data types, such as voice and video.
These increased workload demands put enormous pressure on the server's single traditional
The basics of Windows NIC teaming
A server can easily support numerous physical NIC ports, and workloads can be assigned to specific ports. However, NIC ports typically did not work cooperatively without complex third-party teaming products.
For example, a server with two gigabit Ethernet NIC ports could not easily aggregate both ports to deliver an equivalent 2 GbE path for the workload. In addition, there was no simple mechanism to failover a workload's network traffic from one NIC port to another. For example, if NIC port 1 failed, the affected workload would need to move to another server until port 1 was repaired, rather than just shifting the network traffic to a spare NIC port.
These limitations are not in the hardware -- network cards have supported teaming behaviors for years -- but in operating system (OS) support. Windows Server 2012 functionality allows servers with multiple NIC ports to aggregate bandwidth and failover to handle workload balancing and prevent connectivity issues that can disrupt workload operation.
NIC teaming is accomplished by essentially "virtualizing" the available physical network adapters in order to create virtual network adapters. The virtual network adapters are then accessible through the operating system, and workloads can connect to one or more virtual network adapters at the same time. Windows Server 2012 also supports NIC teaming in virtual machines (VMs), allowing VMs to use virtual network adapters connected to one or more Hyper-V switches. This maintains connectivity for the workload when the NIC port(s) associated with that adapter are disconnected.
Teaming could work with a single Ethernet NIC port. In this case, virtual LANs (VLANs) separate network traffic, but this offers little practical benefit for bandwidth aggregation and does not support failover. More practical and beneficial teaming will require a minimum of two Ethernet NIC ports, and Windows Server 2012 will team up to 32 NIC ports.
NIC teaming and network switches
Every NIC port on the server connects to a corresponding port on a network switch, so NIC teaming might require physical switches to participate in certain configurations. If the switch is not part of the NIC teaming configuration -- switch-independent teaming -- the NIC ports in a team can be connected to different switches; team connections do not all need the same switch. This may be desirable where resiliency and failover planning are critical goals of the NIC team. By putting each failover member on a different switch, the network architecture guards against a single switch failure disrupting multiple ports on the same switch, which might disable the entire team.
However, switches are often part of the NIC teaming configuration -- or switch-dependent teaming -- where NIC ports in the same team must be connected to the same switch. In static teaming, the elements must be expressly configured for the switch and server. This is a straightforward -- if error-prone – approach that can be tricky to implement, update and troubleshoot. By comparison, dynamic teaming uses the link aggregation control protocol (LACP) that automatically identifies team links between a server and switch. This makes deployment and changes far easier to manage, but the switch must support LACP.
Keeping NIC traffic organized
One of the biggest NIC teaming challenges is managing the traffic from the server to the greater network. When splitting and sending data across multiple NIC ports, it is easy for packets in the data stream to become disorganized, causing packets to arrive at the destination node out of order. Although the receiving node will reorganize the packets, the behavior can degrade performance, which defeats some of the NIC teaming benefits. Consequently, NIC teaming tries to keep all of the packets included with a particular data stream on the same network port, where the packet order is easier to maintain.
In a non-virtualized environment, NIC teaming typically relies on hashing techniques. When packets are constructed, a hash value is created that reflects source and destination media access control (MAC), IP and/or TCP port data --depending on the algorithm selected. The hash value is attached to the packets; packets with that hash tag are sent to a certain network port(s), knowing that the data stream is between two known locations in the network. This keeps the packets of each data stream on their own NIC ports to ensure that packets arrive roughly in the order sent. Advanced NIC teaming products can balance traffic by altering the hash on the fly, to distribute packets to other NIC ports that are more lightly used. This is referred to as adaptive load balancing.
In a virtualized environment, each VM can distribute packets based on MAC addresses of the sending and receiving servers. For example, the associated network switch can see the sending MAC address, determine that the traffic is originating from the same NIC adapter and then try to load balance the traffic across multiple links to the destination MAC address. Windows Server 2012 will use the Hyper-V switch port designation instead of the sending MAC address. Regardless, this approach is not the best means of load balancing.
The idea of NIC teaming is not new, but the introduction of Windows Server 2012 makes teaming a native feature that can boost throughput by aggregating bandwidth and improve workload resilience by handling failover between NIC ports within the established team. IT administrators deploying Windows Server 2012 on mission-critical, multi-NIC servers should take the time to evaluate and implement NIC teaming in the data center.
This was first published in March 2013