Best Practice: Intel i350, W2K12 R2 Nic Teams, HyperV & RSS

[Urk]

Vraagje, volgende situatie: een klant heeft een Dell PowerEdge R730 server, met daarin een Intel i350 NIC met 4 Gbit poorten + een Intel i350 PCIe kaart ook met 4 Gbit poorten.
De server draait Windows Server 2012 R2 als Hyper-V. We hebben 1 NIC poortje gebruikt voor het Management van het OS zelf. De andere 7 poorten hebben we gebundeld in 1 NIC Team (7Gbit dus).

In Hyper-V Virtual Switch management hebben we dit NIC Team gekoppeld aan een external Hyper-V switch.

Verder hebben 4 virtuele Windows 2012 R2 servers een netwerk interface die is gekoppeld aan deze externe Hyper-V switch.

Ik kom eigenlijk op deze vraag vanwege een BPA scan op een virtuele server, die geeft namelijk aan:

code:

Problem:
Some network adapters are capable of RSS, but the capability is disabled.

Impact:
Windows networking subsystem performance may be degraded since it is not configured to use multi-core and many-core processor architecture.

Resolution:
Enable RSS with PowerShell cmdlet: Enable-NetAdapterRss, or in the network adapter Advanced Properties.

BPA model version: 2.0

en

code:

Problem:
Some network adapters are capable of IPsec TOv2, but the capability is disabled.

Impact:
Networking performance may be degraded, and the CPU may be over-utilized since they are not optimized.

Resolution:
Enable IPsec TOv2 with PowerShell cmdlet: Enable-NetAdapterIPsecOffload, or in the network adapter Advanced Properties.

BPA model version: 2.0

Ik weet niet zo goed wat de best practice hier is. Ik heb hier eea over gelezen maar weet niet hoe dit het geval is in combinatie met native NIC Teaming en Hyper-V.

De instellingen zijn nu namelijk als volgt:
Op de 7 fysieke NIC poorten op de Hyper-V host::
- Virtual Machine Queues: ENABLED
- SR-IOV: ENABLED
- VMQ ports: 1
- SR-IOV ports: 6
- Receive Side Scaling: DISABLED, maar hier staat als omschrijving wel bij:
Notes: RSS is not supported on some adapters configured to use Virtual Machine Queues (VMQ). On these adapters VMQ will take precedence over RSS. RSS will appear disabled.
Teaming notes: If RSS is not enabled for all adapters in a team, RSS will be disabled for the team.

Op het NIC Team op de Hyper-V host:
- Virtual Machine Queues: ENABLED
- Receive Side Scaling: ENABLED

Op een virtuele Windows 2012 R2 server::
- Virtual Machine Queues: bestaat niet in een VM
- Receive Side Scaling: DISABLED, en over deze instelling klaag de BPA scan.

De eindvragen in dit verhaal zijn dus:
- Moet Receive Side Scaling op de VM niet op ENABLED staan? De VM heeft namelijk meerdere virtual processor cores.
- Is verder alles optimaal ingesteld of zijn er verbeteringen mogelijk (in performance)?

[Urk]

Kickje Anyone.....?

[ Voor 41% gewijzigd door Urk op 06-06-2016 15:34 ]

[lier]

Misschien is Professional Networking & Servers een betere plek om deze vraag te stellen?

[chaoscontrol]

Ik heb het nog niet gebruikt op VM niveau maar lees dit eens;
http://windowsitpro.com/h...n-configuring-rss-and-vmq
https://blogs.technet.mic...rkloads-with-virtual-rss/

Let er op dat RSS iets anders is dan vRSS (wat je dus wilt).

You’re probably thinking to yourself, “What’s the catch?” There is a catch and that’s the reason why vRSS is not enabled by default on any VMs. There are extra calculations that must be done to accomplish the spreading which leads to higher CPU utilization in the host. This means that small VMs with minimal or average network traffic will not want to enable this feature. This feature is meant for VMs that process high network traffic like file servers or gateways.

[ Voor 42% gewijzigd door chaoscontrol op 06-06-2016 15:44 ]

[Equator]

Dit gebeurt niet veel, maar move naar Professional Networking & Servers

[Question Mark]

Ik wil eigenlijk eerst wel even één stapje terug gaan...

Waarom zitten er 8 nics in de host?

Is de VM density dermate hoog dat 7 Gbit nodig is data transfer?
Worden bepaalde nics gebruikt voor ISCSI?
Hoeveel vlans lopen over deze verbindingen (ik neem aan dat het trunks zijn)

Ik heb eigenlijk een dergelijke configuratie nog nooit gezien. Ik heb wel vaker hosts weggezet met veel Nic's, maar dan zat er altijd een logische scheiding in:

• 2x nic voor mgmt
• 2x nic voor vm netwerk
• 4x nic voor iscsi

Wat is de achterliggende gedachte van jullie configuratie?

Overigens zorgen technieken als RSS en VMQ ervoor dat niet tegen de limiet van ~3,5 Gbit/sec aangelopen wordt bij het gebruiken van vswitches. Lopen jullie in je huidige omgeving nu tegen deze limiet aan?

VMQ Deep Dive

Now the question remains, why would I want to use VMQ if I’m capped at a single core for network processing? VMQ is the mechanism we use to spread networking traffic to multiple cores. Without VMQ, all of the networking traffic is done on a single core so your overall throughput is capped at ~3.5Gbps.

If not, dan zou ik het lekker disabled laten. Als het werkt is het mooi, maar vaak werkt het net niet... En de oorzaak ligt dan vaak in de gebruikte NIC hardware en drivers, wat altijd erg lastig te troubleshooten is.

Als je niet boven de 3,5 Gbit/sec uitkomt momenteel zou ik wel even de config heroverwegen. Ik zou dan in elk geval mgmt redudant gaan maken.

[Urk]

Question Mark schreef op dinsdag 07 juni 2016 @ 10:20:
Ik wil eigenlijk eerst wel even één stapje terug gaan...

Waarom zitten er 8 nics in de host?

Is de VM density dermate hoog dat 7 Gbit nodig is data transfer?
Worden bepaalde nics gebruikt voor ISCSI?
Hoeveel vlans lopen over deze verbindingen (ik neem aan dat het trunks zijn)

Ik heb eigenlijk een dergelijke configuratie nog nooit gezien. Ik heb wel vaker hosts weggezet met veel Nic's, maar dan zat er altijd een logische scheiding in:

• 2x nic voor mgmt
• 2x nic voor vm netwerk
• 4x nic voor iscsi

Wat is de achterliggende gedachte van jullie configuratie?

Overigens zorgen technieken als RSS en VMQ ervoor dat niet tegen de limiet van ~3,5 Gbit/sec aangelopen wordt bij het gebruiken van vswitches. Lopen jullie in je huidige omgeving nu tegen deze limiet aan?

VMQ Deep Dive


[...]


If not, dan zou ik het lekker disabled laten. Als het werkt is het mooi, maar vaak werkt het net niet... En de oorzaak ligt dan vaak in de gebruikte NIC hardware en drivers, wat altijd erg lastig te troubleshooten is.

Als je niet boven de 3,5 Gbit/sec uitkomt momenteel zou ik wel even de config heroverwegen. Ik zou dan in elk geval mgmt redudant gaan maken.

Misschien ontwetendheid, maar....

Er zitten 8 NIC's in de host om alle VM servers van een goede bandbreedte te voorzien, 4 servers connected via 1 Gbit NIC poortje lijkt me wat summier, zeker voor een fileserver of zie ik dat verkeerd?

Om je andere vragen te beantwoorden:
- Nee, er wordt geen gebruik gemaakt van VLAN's op dit moment.
- En nee, er wordt ook geen gebruik gemaakt van iSCSI
- De fileserver draait op een VM binnen de Hyper-V host.

Zo een vreemde config lijkt mij dit toch niet, of wel? Je noemt namelijk dit nog nooit gezien te hebben maar heb 1 NIC voor Management van Hyper-V en de andere 7 NIC's zitten in 1 NIC Team met 7 Gbit aan bandbreedte.
De limiet van 3,5 Gbit/s hoor ik nu voor het eerst. Hoe kan ik meten of ik daar tegenaan loop?
En waarom management redundant maken? Dit wordt toch alleen gebruik voor het beheer van de Hyper-V server zelf?

Ik zal iig even het Microsoft artikel wat je doorstuurde doornemen, dank daarvoor!

[Question Mark]

Urk schreef op woensdag 08 juni 2016 @ 14:00:
[...]


Misschien ontwetendheid, maar....

Er zitten 8 NIC's in de host om alle VM servers van een goede bandbreedte te voorzien, 4 servers connected via 1 Gbit NIC poortje lijkt me wat summier, zeker voor een fileserver of zie ik dat verkeerd?

Dat ligt eraan hoeveel gebruikers gelijktijdig aan de netwerkverbinding van je fileserver trekken. Ik plaatste in het verleden ongeveer 35 VM's op één host en heb met 2x 1 Gbit nic geteamed op het KA netwerk nog nooit te weinig bandbreedte gehad op dit team. Nu zegt dat niks over jullie omgeving, maar het daadwerkelijk bandbreedte verbruik van je fileserver is natuurlijk snel te meten...

Het zou mij heel erg verbazen als je vier VM's een bandbreedte van 7 Gb/sec nodig hebben.

En waarom management redundant maken? Dit wordt toch alleen gebruik voor het beheer van de Hyper-V server zelf?

Het lijkt mij wel handig om beheer te kunnen blijven doen als één enkele NIC uitvalt. Verder wordt de verbinding ook gebruikt als je de VM's backupped via de Hyper-V host, maar ook dat ligt weer aan de inrichting.

Welke netwerkcounters handig zijn om te meten staat wel in onderstaand document weergegeven:

Monitoring Hyper-V Performance

[Psycho_Mantis]

Was het niet zo dat je teaming alleen moet gebruiken in de VM's zelf?
Dus per NIC een virtual switch maken en pas in de VM's zelf dus aan elkaar knopen.

Overigens wel een beetje vreemd om zo'n groot team te maken, als je echt zoveel traffic hebt dan zou ik over gaan naar 10Gbit NIC's.

[Urk]

Psycho_Mantis schreef op woensdag 08 juni 2016 @ 15:49:
Was het niet zo dat je teaming alleen moet gebruiken in de VM's zelf?
Dus per NIC een virtual switch maken en pas in de VM's zelf dus aan elkaar knopen.

Overigens wel een beetje vreemd om zo'n groot team te maken, als je echt zoveel traffic hebt dan zou ik over gaan naar 10Gbit NIC's.

Goed punt want dat vroeg ik mij zelf ook al een tijd af waarop ik tot op heden nog niet 1 heel duidelijk antwoord heb kunnen vinden. Je kunt inderdaad in de Hyper-V host een Team maken maar ook in de VM.

10Gbit NIC's zou kunnen maar we hebben geen 10Gbit switches en die gaan er ook niet komen op korte termijn. Vandaar deze setup.

[Equator]

Ligt dat er niet een beetje aan voor welk scenario je kiest voor een redundante setup?

Hoe zit bijvoorbeeld de host aangesloten? Op 1 switch of 2? Staan deze 2 switches in een VPC/IRF/Stack?
En hoe staat het e.e.a. op de host geconfigureerd. Die 7x1Gb is dat failover met load balancing of een andere modus. Als je daar alles redundant hebt aangesloten, inclusief failover dan heeft het afaik geen toegevoegde waarde om een VM 2 vNics toe te kennen en deze weer te teamen in het OS.

Overigens is 7x1Gb wel een vreemde setup. Welk bonding type gebruik je daar? Volgens mij is het de best practice om te bonden met 2/4 of 8 verbindingen. Niet 7. Afhankelijk van je switch setup kan je daar vreemde dingen mee krijgen.

Voor wat betreft noodzakelijkheid: Zonder inzicht in het type VM's dat je op deze host hebt draaien is het niet te zeggen of je zoveel bandbreedte nodig hebt. Ik heb omgevingen gezien die met gemak op 2x1Gb (failover) konden draaien, maar ook het tegenovergestelde.
Misschien kan je eens kijken naar de gebruikte bandbreedte over een periode van een week. Per VM en op de HV Host op je bond. Dan heb je meer inzicht op wat je daadwerkelijk nodig hebt

[Question Mark]

Equator schreef op donderdag 09 juni 2016 @ 07:17:
En hoe staat het e.e.a. op de host geconfigureerd. Die 7x1Gb is dat failover met load balancing of een andere modus. Als je daar alles redundant hebt aangesloten, inclusief failover dan heeft het afaik geen toegevoegde waarde om een VM 2 vNics toe te kennen en deze weer te teamen in het OS.

Nic teaming bij Hyper-V kan zowel op de host als in de VM. Beide methodes zijn ondersteund.

Bij nic teaming in de VM, worden er meerdere (external) vswitches aangemaakt, elk aangesloten op één fysieke NIC. Een VM krijgt dan twee Nic's, die aangesloten zitten op verschillende vswitches. Er vind op de host dan geen teaming meer plaats, dat zou inderdaad dubbelop zijn.

@TS: hoe staat je team eigenlijk gedefineerd? Als dat switch independ is, met loadbalancing type "Hyper-V Port", dan worden onder water de VM's één op één gemapped naar een fysieke NIC. Aangezien je maar 4 vm's gebruikt zouden 5 nic's in je team dan voldoende zijn. Dan krijgt elke VM nog steeds exclusief toegang tot één nic, en mag er nog steeds een nic uitvallen zonder performance verlies te krijgen.

Hyper-V Port
If your server is a Hyper-V host with multiple running VMs, this load balancing mode is normally preferred in most situations. When using “Hyper-V Port” load balancing, VM’s will be distributed across the network team and each VM’s outbound and inbound traffic will be handled by a specific active NIC. This mode works really well in scenarios where you are consolidating many VM's on a physical Hyper-V host, but where none of the VM’s are generating a network load that exceeds the bandwidth of one NIC in the team. In this use case, NIC teaming provides a very cost-effective way of load balancing the aggregate traffic from all VMs across the active team members, but remember: each VM is assigned to a specific NIC in the team, so none of the VM’s will be able to access more bandwidth than what one NIC provides.

Leuke discussie dit trouwens, er zijn meerdere wegen naar Rome. Ik ben wel erg benieuwd hoe anderen de best practices hanteren en implementeren.

[ Voor 41% gewijzigd door Question Mark op 09-06-2016 08:37 ]

[Equator]

Question Mark schreef op donderdag 09 juni 2016 @ 08:27:
[...]

Nic teaming bij Hyper-V kan zowel op de host als in de VM. Beide methodes zijn ondersteund.

Oh, het ging me niet zozeer om ondersteuning of niet. Ik weet dat beide kan..

Bij nic teaming in de VM, worden er meerdere (external) vswitches aangemaakt, elk aangesloten op één fysieke NIC. Een VM krijgt dan twee Nic's, die aangesloten zitten op verschillende vswitches. Er vind op de host dan geen teaming meer plaats, dat zou inderdaad dubbelop zijn.

Daar ging het echt om. Als je het al op de host regelt, dan is het niet noodzakelijk om dit op de VM nog eens te doen