Tip of the Day: Why You Should Recommend SET over LBFO
Today’s Tip… Why You Should Recommend SET over LBFO
Ever need a quick reference when asked about the positives and negatives of various teaming technologies? Here is a set of factoids and recommendations that should help you out!
Background Reading
- Switch Embedded Teaming (SET)
- Load Balancing Failover (LBFO) - Server 2012, Server 2012R2
..and now to the good stuff…
Why We Recommend Switch Embedded Teaming (SET) over LBFO on Windows Server 2016 and 2019
- SET has exceeded the stability and performance capabilities of LBFO
- LBFO does not support a number of core Microsoft scenarios including:
- LBFO cannot team RDMA adapters and as such is not suitable for Storage Spaces Direct deployments
- LBFO does not support VMMQ or other stateless offloads that:
- Enable VMs to exceed ~5 Gbps throughput per virtual machine
- Improve system efficiency
- Improve VM density
- LBFO does not support SDNv2, the basis of Azure Networking on-premises in Windows Server 2016 or Windows Server 2019
‘However, SET does not support LACP and teaming mechanisms at the switch layer.’
The Microsoft perspective on this is:
- LACP is not agile and requires switch modification, which is not easily automated, deployed, troubleshot, or maintained
- Limits you to the minimum number of queues between the teamed adapters, limiting your overall VM density on the system
- Aggregate bandwidth is irrelevant unless you need a single VM to consume more than a single adapters capability
Here’s hoping this helps with your next customer conversation.