Latency op 10GbE netwerk

[JurienW]

Ik zit met een vraagstuk waar ik geen antwoord op kan vinden.
Waar het om gaat is of de ping tijden welke ik ervaar op een netwerk normaal zijn of dat er ergens iets niet klopt.
Het gaat om een 4 node Windows 2019 cluster bestaande uit DL380 Gen10
Deze zijn middels 2 x HPE 562SFP+ 10Gbit per server verbonden aan 2 HPE 5510 switches in IRF geconfigureerd.
Nu heb ik een behoorlijk stabiele ping tussen de nodes van 0.3 ms als deze server niet belast worden.
Echter als aantal VM's op de betreffende node zet en server belast wordt, blijft de ping in de basis zo'n 0.3 ms.
Wel zie ik dan pieken ontstaan, om de zoveel seconde van 3 a 4 ms.
Ook komen er meerdere keer per minuut pieken voorbij van richting de 10 ms.
Op zich geen hele schokkende tijden maar het is wel 30x zo hoog als de baseline.

Nu is er echter ook een software leverancier waarvan hun applicatie onverklaarbare fouten geeft naar de SQL database welke beweerd dat deze veroorzaakt worden door de onstabiele netwerkverbinding.
Mij persoonlijk lijkt dit onzin aangezien we het niet hebben over packet loss , maar over een reactiesnelheid welke wat hoger ligt, maar harde bewijzen kan ik hier niet voor vinden.
Is het dus gek dat je op een (10gbit) zulke pieken ervaart of is er daad werkelijk iets geks aan de hand.

[MagicTempest]

Ping, of latency binnen een netwerk wordt door een aantal zaken veroorzaakt:

- Processing delay
- Serialization delay
- Propagation delay

Van deze drie is er maar één die wordt bepaald door je 10Gb netwerk, dat is de serialization. Dat is de tijd die het kost om een frame van bit 1 tot de laatste bit op de lijn te zetten. Hoe sneller je netwerk hoe sneller een frame op de lijn staat en er aan de volgende frame kan worden begonnen. Ik schaar de wachttijd totdat er aan de serialization kan worden begonnen voor het gemak ook even onder de serialization delay. Dus als je netwerk congested is kan het dus even duren voordat een frame aan de beurt is om op de lijn te worden gezet.

De propagation delay is de tijd die het kost voor een bit om van de ene kant van de lijn tot de andere te komen. Die is afhankelijk van de lengte van de kabel, maar niet de bandbreedte van de verbinding (want het gaat om de snelheid van het licht in een fiber in het geval van een fiber, of de snelheid van electronen in een koperkabel).

De belangrijkste factor is echter de processing delay. De processing delay vindt plaats op alle tussenliggende systemen, want er moet iets gebeuren met het frame. Op een switch is dat de tijd die het kost om op te zoeken welke poort het frame uit moet. Op een server is het de tijd die het kost om het frame uit te pakken, te bepalen naar welk proces het moet, het proces het te laten afhandelen en dan een antwoord te krijgen. Deze tijd is vrijwel altijd het langste.

Als we kijken naar ping (ICMP echo request en echo reply) zien we dat het verwerken van deze frames altijd een lage prioriteit krijgt. Hierdoor kan het soms even duren voordat een systeem reageert op een ping, en die is dus zeer afhankelijk van wat het systeem op dat moment aan het doen is.

Een ping is dan ook nooit meer dan een indicatie. Als je echt wil weten wat de performance is, moet je de applicatie zelf gaan meten. Het kan best dat de applicatie / server zelf gewoon te weinig resources heeft.

Overigens is het wel weer zo dat een ping van 10ms binnen een bedrijfsnetwerk best wel hoog is, maar je eigen verhaal dat het alleen optreedt wanneer je belasting op de node plaatst staaft wel mijn verhaal.

[Ben(V)]

Een SQL database kan helemaal nooit enige last hebben van een ping van 10ms, dat is enkele magnitudes lager dan waar zo'n database last van kan krijgen.

Maar ik zou eens met wireshark op je netwerk gaan kijken, goede kans dat je last van overbodige broadcasts hebt.
Bijvoorbeeld veel systemen zoeken via een broadcast nog naar een wins server die er tegenwoordig meestal niet meer zijn.

[JurienW]

@MagicTempest Bedankt voor je uitgebreide reactie.
10 ms is voor een LAN idd aan de hoge kant maar gaat in dit geval echt om de spikes, 99% zit ruim onder de 1 ms.
Vraag gaat specifiek over de pieken, wat telkens eigenlijk maar een enkel ping betreft.
Ik denk zelf ook niet dat er problemen mogen ontstaan door af en toe een piek in je latency maar ik kan hier echter geen harde bewijzen voor vinden.
Als de load op de server hoog (nee CPU absoluut niet constant op 100%, maar wel tussen de 50% en 80%) zie je ook meer pieken.
Nu zie ik het zelfde beeld wanneer ik middels TCP de latency test omdat ICMP wat je al aangeeft meer een indicatie is, maar daar gebeurd het zelfde.
Uiteindelijk zal het de CPU een keer raken en als deze in gebruik is zal je even moeten wachten, maar is een max van 10 ms iets wat "normaal" is of zou dat eigenlijk nooit boven bijvoorbeeld 2 ms uit mogen komen. Zie dit namelijk op meerdere netwerken en het is volgens mij niet vreemd, maar de software leverancier geeft aan dat het probleem hierdoor veroorzaakt wordt.
Zo'n welles / nietes discussie wat ik niet feitelijk onderbouwd kan weerleggen.

@Ben(V) Broadcast verkeer zou absoluut serieus aanwezig zijn, maar de pieken zijn / lijken gerelateerd aan de load op de server. De kleine piekjes 0.3 -> 0.5 ms zouden hier een gevolg van kunnen zijn, maar deze vindt ik niet zo spannend.

Omdat plaatjes meer zeggen als 1000 woorden, een plaatje waar het effect zichtbaar is.
In dit voorbeeld niet heel veel aanwezig, maar is nu ook redelijk rustig op de omgeving.
Warning, schaal van grafiek is gedramatiseerd

[Ben(V)]

Zoals al gezegd kijk met wireshark wat er op je netwerk gebeurt, dan zie je snel genoeg of het de server is of iets op het netwerk

[Kabouterplop01]

en om beide zaken goed te kunnen scheiden; even de betreffende services disablen en dezelfde metingen doen, met grafieken dan kun je het 100% uitsluiten. Uiteraard daarna weer aanzetten.

[Brahiewahiewa]

JurienW schreef op vrijdag 15 juli 2022 @ 14:47:
...
Nu is er echter ook een software leverancier waarvan hun applicatie onverklaarbare fouten geeft naar de SQL database welke beweerd dat deze veroorzaakt worden door de onstabiele netwerkverbinding...

Je leverancier zou best wel eens gelijk kunnen hebben. Een windows cluster is ontworpen om met dedicated fail-over verbindingen te werken. Dus per node een aparte NIC enkel voor de keep-alive packets. Jij hebt besloten dat het fail-over netwerk ook wel over de bestaande NIC kan. En je ziet meteen problemen opduiken met de keep-alive packets.

Ik zeg: tijd om terug te gaan naar de tekentafel. Zet een nieuw cluster op waarin je wel dedicated NIC's gebruikt voor de fail-over en kijk of je de onverklaarbare fouten nog kunt reproduceren

[JurienW]

Brahiewahiewa schreef op zaterdag 16 juli 2022 @ 14:02:
[...]
Ik zeg: tijd om terug te gaan naar de tekentafel. Zet een nieuw cluster op waarin je wel dedicated NIC's gebruikt voor de fail-over en kijk of je de onverklaarbare fouten nog kunt reproduceren

Misschien niet helemaal duidelijk neergezet in mijn reactie.
Het gaat erom dat NA de live migration er VM's draaien op de server.
Heb het niet over het moment van de Live Migration zelf.
Er is verder ook geen probleem met het cluster op zichzelf, geen problemen met heartbeats of CSV wat niet werkt.

Waar het mij nu om gaat is de vraag of het vreemd is dat er op een server waar VM's op draaien en CPU load is en je pieken ziet richting de 10 ms.
Als nu blijkt dat dit niet normaal is en dus niemand anders met een vergelijkbaar netwerk dit ervaart dan moet ik op zoek naar een verklaring hiervoor.

Stukje cluster is misschien zelf wel helemaal niet relevant voor de vraag.
Stel je hebt 2 losse server welke belast worden, kan je dan verwachten dat je ping op deze manier fluctueert.

[Brahiewahiewa]

JurienW schreef op zaterdag 16 juli 2022 @ 15:15:
[...]Stel je hebt 2 losse server welke belast worden, kan je dan verwachten dat je ping op deze manier fluctueert.

Ja.
Daar gaat @MagicTempest's verhaal over. Een verhaal wat ik volledig onderschrijf.
Die RTT die ping uitpoept is de round-trip time en is een optelsom van alle vertragende factoren die hij onderweg tegenkomt. Het enige wat je met ping vast kunt stellen is dat er vertragende factoren zijn, maar je kunt niet pin-pointen waar die vertragende factor precies zit. En je kunt ook niet vaststellen of het een structurele vertragende factor is of een toevallige.

Daarnaast heb je het ook nog eens over VM's. Er is dus ook nog eens een virtualisatie laag in het spel waarin sommige mensen er in slagen om een heleboel te verkloten. Ik wil niet meteen suggereren dat jij daar iets verkloot hebt, maar ik zou ook niet durven garanderen dat dat niet het geval is ;o)

[JurienW]

@Ben(V) Gaat in dit geval om de ping van een losse Host naar een Host van het cluster, dus niet naar een VM.