Hyper-V: Confronto tra Switch Embedded Teaming (SET) e Load Balancing and Failover (LBFO)

In Windows Server 2022 la creazione di un Hyper-V vSwitch tramite LBFO non è più possibile tramite l’Hyper-V Console, ma se si desidera creare un Hper-V virtual switch che fa uso di un team è necessario utilizzare la funzionalità Switch Embedded Teaming (SET).

A riguardo si veda Features removed or no longer developed starting with Windows Server 2022:

“In a future release, the Hyper-V vSwitch will no longer have the capability to be bound to an LBFO team. Instead, it must be bound via Switch Embedded Teaming (SET).”

Per quanto riguarda l’uso di Switch Embedded Teaming (SET) occorre tenere presente che supporta fino a 8 NIC (al contrario di LBFO che supporta fino a 32 NIC) e solo la configurazione switch-independent utilizzando gli algoritmi di load-balancing Dynamic o Hyper-V Port, inoltre per ottenere performance migliori l’algoritmo di load-balancing Hyper-V Port è raccomandato su tutte le schede di rete che operano a 10 Gbps o superiori, a rigardo si veda quanto riportato in Switch Embedded Teaming (SET):

“SET supports only switch-independent configuration by using either Dynamic or Hyper-V Port load-balancing algorithms. For best performance, Hyper-V Port is recommended for use on all NICs that operate at or above 10 Gbps. Network ATC makes all the required configurations for SET.”

Inoltre si veda anche https://aka.ms/LBFODeprecation che punta all’articolo Teaming in Azure Stack HCI – Microsoft Community Hub in cui vengono date una serie di informazioni e indicazioni sul perché LBFO è stato deprecato.

Innanzitutto va precisato che LBFO è stato introdotto in Windows Server 2012 mentre SET è disponibile in Windows Server 2016 successivi e in Windows 10 1809 e successivi, inoltre per poter utilizzare SET non è necessario eseguire macchine virtuali, ma è necessario installare il ruolo Hyper-V.

In sintesi Microsoft indica che LBFO è la vecchia tecnologia di teaming che non vedrà investimenti futuri in quanto non è compatibile con numerose funzionalità avanzate ed è stata superata in termini di prestazioni e stabilità dalla nuova tecnologia SET che è stata introdotta per supportare le tecnologie software-defined come SDNv2 e i containers. Tutte le nuove features rilasciate a partire da Windows Server 2016 sono state sviluppate tenendo conto di SET, compresa Azure Stack HCI che invece non è testata o certificata con LBFO.

La decisione di creare SET e non sviluppare più LBFO dipende dal fatto che LBFO si basa su NDIS un componente complesso nato ai tempi di Windows 95 e poi aggiornato, ma la complessità di NDIS aggravata dall’introduzione della virtualizzazione delle tecnologie software-defined ha reso sempre più difficoltoso lo sviluppo e il test delle funzionalità del sistema operativo e anche dei driver di rete con conseguenze sulla stabilità.

Di seguito le funzionalità supportate da SET, ma non da LBFO:

• Windows Admin Center (WAC) tramite cui è possibile gestire Windows Server e Azure Stack HCI, WAC permette la creazione e la gestione di team SET, mentre LBFO non è configurabile tramite WAC.
• RDMA Teaming, solo SET può mettere in team adattatori RDMA.
• Guest RDMA, solo SET supporta RDMA in una VM.
• Guest Teaming, solo SET permete di mappare una NIC virtuale ad una NIC fisica.
• Microsoft Software Defined Networking (SDN).
• Container Networking.
• Virtual Machine Multi-Queues (VMMQ).
• Dynamic VMMQ.
• RSC nello Switch virtuale.

Per quanto riguarda le performance occorre tenere presente che sebbene LBFO utilizzi il Link Aggregation Control Protocol (LACP) che è in grado di aggregare la banda delle schede di rete nel team, ma ciò non vale con la virtualizzazione in quanto quando il traffico arriva all’host le NIC necessitano di interrupt multipli che non possono essere gestiti da un singolo CPU core, per questo motivo è stato introdotto VMMQ che però non è compatibile con LBFO.

LACP, allows for port-channels or switch-dependent teams to send traffic to the host over more than one physical port simultaneously.

For native hosts this means that every port in the port-channel can send traffic simultaneously

But things change with virtualization. When the traffic gets to the host, the NICs need to interrupt multiple, independent processors to exceed what a single CPU core can process – This is what VMMQ does, and as mentioned, VMMQ does not work with LBFO.

LBFO limits you to a single VMQ

In summary, LACP provides no throughput benefits for Azure Stack HCI scenarios, incurs higher CPU consumption, and cannot auto-tune the system to avoid competition between workloads for virtualized scenarios (Dynamic VMMQ).

Mentre tramite SET, ovvero tramite un team switch-independent, l’assistenza hardware di VMMQ e un numero sufficiente di CPU nel sistema è possibile aggregare la banda delle schede di rete nel team anche in ambienti virtuali.

SET è supportato da Microsoft se utilizzato con adattatori di rete simmetrici che abbiano superato il test Windows Hardware Qualification and Logo (WHQL), per cosa si intende per adattatori simmetrici si faccia riferimento alla seguente indicazione contenuta in Teaming in Azure Stack HCI – Microsoft Community Hub:

“Usually the easiest way to identify this symmetry is by the device Interface Description (with PowerShell, use Get-NetAdapter). If the interface description matches (with exception of the unique number given to each adapter e.g. Intel NIC #1, Intel NIC #2, etc.) then the adapters are symmetric.”

Ovvero due adattatori di rete simmetrici hanno lo stesso Produttore, Modello, velocità, configurazione, driver e firmware.

LBFO invece può operare con adattatori di rete asimmetrici e prima di Windows Server 2016 si riteneva che l’utilizzo di NIC differenti in un team fosse un vantaggio perché nel caso di un problema ad un driver su una NIC l’altra avendo un driver differente poteva continuare a funzionare. La realtà dei fatti però ha smentito questa convinzione perché avere più driver coinvolti in un team implica avere più punti di possibile failure come è stato riscontrato sul campo dal supporto Microsoft:

However, two drivers mean twice as many things can go wrong in fact increasing the likelihood of a problem. Instead, a properly designed infrastructure with symmetric adapters are far more stable in our review of customer support cases. As a result, support for asymmetric teams are no longer a differentiator for LBFO nor do we recommend it for Azure Stack HCI scenarios where reliability is the #1 requirement.

Per quanto riguarda quando la scelta tra team SET e LBFO Microsoft raccomanda di utilizzare SET ogni volta che sia possibile, mentre LBFO rimane la tecnologia di team negli scenari in cui il ruolo Hyper-V non è installato (o all’interno di una VM in cui si desidera configurare un team tra le vNIC) come indicato in Teaming in Azure Stack HCI – Microsoft Community Hub:

“Some customers I’ve worked with have asked if they should use LBFO for management adapters when the vSwitch is not attached – Our recommendation is to always use SET whenever available. A management adapter’s goal in life is to be stable and we see less support cases with SET.”

“To be clear, if the adapter is not attached to a virtual switch, LBFO is acceptable however, you should endeavor to use SET whenever possible due to the support reasons outlined in this article.”

“LBFO remains our teaming solution when Hyper-V is not installed. If however, you are running virtualized or cloud scenarios like Azure Stack HCI, you should give Switch Embedded Teaming serious consideration. As we’ve described in this article, SET has been the Microsoft recommended teaming solution and focus since Windows Server 2016 as it brings better performance, stability, and feature support compared to LBFO.”

Nel caso si intenda migrare la versione di Windows Server alla 2022 occorre convertire i team LBFO connessi a virtual switch Hyper-V ateam SET e per semplificare tale procedura è stato reso disponibile le script Convert-LBFO2SET, tale script sarà disponibile fino al 9 gennaio 2024 ovvero sino alla data della fine del supporto Mainstream di Windows Server 2019.

Bypassare la deprecazione de team LBFO in Hyper-V in ambiante Windows Server 2022

Fatte queste premesse per completezza va precisato che in Windows Server 2022 è ancora possibile utilizzare un team LBFO e connetterlo ad un virtual switch Hyper-V, ma questa operazione va fatta tramite PowerShell come indicato nell’articolo Bypass LBFO Teaming deprecation on Hyper-V and Windows Server 2022, questo può essere utile se nel sistema non sia hanno due adattatori simmetrici condizione necessaria per supportare SET.

Per connettere un team LBFO ad uno switch virtuale in Windows Server 2022 utilizzare la seguente procedura:

Passo 1: Creare il team LBFO tramite Server Manager 

Passo 2: Tramite PowerShell creare il virtual switch connesso al team LBFO creato al passo 1, di seguito il comando per creare un virtual switch denominato “Rete LAN” connesso al team LBFO denominato “Team Rete LAN” con l’impostazione per consetire al sistema operativo di utilizzare il virtual switch:

New-VMSwitch -Name “Rete LAN” -NetAdapterName “Team Rete LAN” -AllowNetLbfoTeams $true
                         -AllowManagementOS $true

Passo 3: Una volta creato il virtul switch tramite PowerShell questo sarà visibile e gestibile anche nellHyper-V Console.

Creazione di team SET

La creazione di team SET questo può essere fatto tramite PowerShell, di seguito il comando per creare un virtual switch e un team SET denominato “Rete LAN” utilizzando due schede di rete denominate “NIC1” e “NIC2”  con l’impostazione per consentire al sistema operativo di utilizzare il virtual switch:

New-VMSwitch -Name “Rete LAN” -NetAdapterName “NIC1”, “NIC2” -EnableEmbeddedTeaming $true

Per ottenere l’elenco delle schede di rete fisiche e ricavare il nome è possibile utilizzare il comando:

Get-NetAdapter -Physical

Per vedere le proprietà del virtual switch creato è possibile utilizzare il comando:

Get-VMSwitch “Rete LAN” | FL

Per vedere le proprietà del team SET creato è possibile utilizzare il comando:

Get-VMSwitchTeam “Rete LAN” | FL

Per modificare sul team SET l’algoritmo di bilancio di carico è possibile utilizzare i seguenti comandi:

Set-VMSwitchTeam “Rete LAN” -LoadBalancingAlgorithm Dynamic

Set-VMSwitchTeam “Rete LAN” -LoadBalancingAlgorithm HyperVPort

Per modificare sul team SET le schede di rete assegnate è possibile utilizzare il seguente comando:

Set-VMSwitchTeam -Name “Rete LAN” -NetAdapterName “NIC 1″,”NIC 3”

Per rimuovere il virtual switch e il team SET creati è possibile utilizzare il comando:

Remove-VMSwitch -Name “Rete LAN”

Per ottenere l’elenco delle schede di rete in un team SET è possibile utilizzare il seguente comando:

Get-NetAdapterBinding | Where-Object { $_.InstanceID -match (Get-VMSwitch -Name “Rete LAN”).NetAdapterInterfaceGuid } | Select Name -Unique

In alternativa per ottenere l’elenco delle schede di rete in un team SET con informazioni sullo stato è possibile utilizzare il seguente comando:

Get-NetAdapter | Where-Object InterfaceGuid -match (Get-VMSwitch -Name “Rete LAN”).NetAdapterInterfaceGuid | Select Name, Status, LinkSpeed

E’ possibile creare un virtual switch basato su un team SET anche tramite Virtual Machine Manager (VMM) o tramite Windows Admin Center (WAC).

Per ulteriori informazioni si vedano anche:

• Windows Server supported networking scenarios | Microsoft Learn
• Create and manage a Switch Embedded Teaming (veeam.com)
• Introduction to Hyper-V Switch Embedded Teaming, Part 1 — Redmondmag.com
• Introduction to Hyper-V Switch Embedded Teaming, Part 2 — Redmondmag.com