Windows Server 2019: Massive Netzwerk(performance-)probleme mit RDS Farm auf ESXi-Hosts?

WindowsHat Microsoft etwas an Windows Server 2019 bezüglich der Netzwerkgeschichten geändert? Ein Blog-Leser hat mich kontaktiert und berichtet von massiven Problemen, wenn die Rolle des RDS Session Hosts installiert wird. Die Transferrate sinkt bei Übertragungen ins Bodenlose. Es tritt in einer Umgebung mit einer RDS Farm auf Basis Server 2019 auf, die auf ESXi-Servern virtualisiert wurde. Die Frage ist, ob auch andere Administratoren solche Probleme beobachtet haben.


Anzeige

Blog-Leser Joschka K. hat mich auf Facebook in einer direkten Nachricht angesprochen und berichtetet über Netzwerkprobleme. Diesbezüglich schrieb er:

Ich habe eine Frage und wende mich daher direkt an Sie. Vielleicht können Sie mir helfen. Wissen Sie, was am Netzwerk eines Servers (Server 2019) passiert oder geändert wird, auf dem die Rolle des RDS Session Hosts installiert wird? Wir haben massive Probleme mit dieser Konstellation, sobald diese Rolle installiert wird.

Vielen Dank und liebe Grüße

Microsoft hat zwar in den letzten Monaten immer mal wieder am Netzwerk und vor allem bei der Absicherung von Netzwerkverbindungen (Stichwort Kerberos-Härtung) geschraubt. Aber ad hoc fiel mir nichts konkretes ein und ich hatte auch keine weiteren Meldungen von anderen Nutzern vorliegen. Ich habe dann nach Details gefragt, um den Sachverhalt hier im Blog anzureißen. Joschka hat dann das Szenario und die Probleme folgendermaßen umschrieben:

Wir nutzen eine RDS Farm auf Basis Server 2019 und haben massive Netzwerkprobleme. Allerdings nur dort.

Latenz ist super, aber Throughput ist mies. Bei 10G Karten zwischen 15 und max 600Mbit.

Die Farm wird auf 5 ESXi Hosts betrieben. 3 Jahre alt mit Nimble als Storage.

Ich habe testweise Daten (4GB Testfile) von vielen verschiedenen Servern kopiert und auf allen habe ich eine Datenrate von 900Mb/s+

Auf der alten 2012er Farm, die parallel läuft tritt das Phänomen nicht auf. Nur auf 2019. Patchstand aktuell.

Ich habe dann einen zusätzlichen Server erstellt und die Testdatei kopiert. Alles gut.

Dann den Server zum Sessionhost gemacht und dann fangen die Probleme an.

Auf einem nackten System (nur Defender und FSLogix) schwanken die Datenraten zwischen 900 & 300.

Sobald die Rolle entfernt wird, ist alles wieder i.O.

Habe einen Server aus unserer Test Collection heute auf Server 2022 in Place upgegradet und das Phänomen tritt dort dann nicht mehr auf.

Daher meine Vermutung, dass irgendwas mit der Rolle bei 2019 nicht i.O. ist. Ich lasse morgen die User nochmal die Apps testen.

Die Frage an die Leserschaft wäre, ob etwas diesbezüglich beobachtet wurde? Es scheint sich wirklich auf Windows Server 2019 mit der RDS Session Hosts-Rolle zu beschränken. Ob die ESXi-Virtualisierung noch mit reinspielt, kann ich nicht sagen. Es gibt hier einen älteren Beitrag, in dem Treiberaktualisierungen bei langsamer Netzwerkverbindung empfohlen werden. Und es gibt einige allgemeine Hinweise zur Behebung von Verbindungs- und Performance-Problemen bei RDP-Verbindungen hier, wo ich aber nicht "allzu viel Heu" für den Betroffenen sehe.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Virtualisierung, Windows Server abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

13 Antworten zu Windows Server 2019: Massive Netzwerk(performance-)probleme mit RDS Farm auf ESXi-Hosts?

  1. MOM20xx sagt:

    hab grad auf einem windows server 2019 mit rds rolle (keine farm mit broker und was nicht allem) getestet. kopie von einem 12GB iso von einem anderen server 2019 rüber mit 500Mbyte/s laut Windows Explorer Dialog.

    Hier ist kein Defender im Einsatz und auch kein Fslogix. Patchlevel vom Server 2019 juli 2023.

    Vmware Esxi 7 aktueller Patchlevel.

  2. RalphAndreas sagt:

    Habe mit den 2019'er eigentl. keine Performance-Probleme eher mit 2022 im RDS-Umfeld (Single und/oder Collection)
    Basis aber MS-S2D-Cluster W2022, natürlich aktuell gepatcht.

  3. John Doe sagt:

    Cubic ausschalten, dann ist das weg…. Problem ist bekann und es gibt da ganz Abhandlungen drüber. Wurde auch hier im Blog schon thematisiert….

  4. Florian sagt:

    Keine Probleme mit FSLogix oder ohne unter Sever 2019 RDS auf vSphere 6,7,8 in unzähligen Umgebungen.

  5. squat0001 sagt:

    4gb ist finde ich zu klein um 10gbit Link zu testen..

  6. Charlie sagt:

    Problem tritt hier seit Kurzem auch auf. :(

  7. audiocrush sagt:

    Hallo zusammen,

    wir können das Verhalten auch beobachten.
    Getestet wurde mit iPerf, alle VMs auf der gleichen VMWare Cluster Node, alle mit VMXNET3, offloading Optionen im Treiber auf Standard, alle VMs mit Windows Server 2019 Datacenter, Tests jeweils mit CUBIC oder DCTCP durchgeführt (gleiches Ergebnis):

    iPerf von RDS-Host VM (ohne RDSH-Rolle installiert) auf den Application-DB Server: 19,8GBit/s
    iPerf von RDS-Host VM (Mit RDSH-Rolle installiert): 5,8GBit/s

    Das ist schon echt absurd irgendwie…
    Wenn man die RDSH-Rolle wieder desinstalliert kommt man auf die vorherigen Performance Werte.

  8. audiocrush sagt:

    Ah!
    Tappt nicht länger im Dunkeln:
    Des Rätsels Lösung scheint gefunden:
    https://wedelit.no/slow-application-on-citrix-rds-tsfairshare/
    https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/fair-share-enabled-by-default-rds

    Wenn man TSFairShare fürs Netzwerk deaktiviert ist alles wieder in Butter.
    Wäre schön wenn Microsoft diesen Mechanismus etwas offener kommuniziert hätte und ihn statt An oder Aus auch etwas granularer steuern ließe.
    Ich finde wenn ein User mal für 10 Sekunden nahezu Peak-Performance braucht damit seine Anwendung sich nicht furchtbar langsam anfühlt soll er sie doch auch gern mal haben dürfen und nicht sofort gedrosselt werden…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.