Probleme auf Terminal Server mit einer Anwendung
Hallo
Folgende Situation. Es gibt ein Problem auf einem Terminal Server.
Betriebssystem: Windows Server 2019
1x Connection Broker
3x Session Hosts
Auf den Session Host läuft eine Anwendung. Diese „verschwimmt“ wohl bei einigen Usern nach einiger Zeit und ist währenddessen nicht nutzbar. Kurz darauf geht diese wieder.
Laut Softwarehersteller könnte es am Load Balancing der Terminal Server liegen.
NLB ist an keinem Server installiert.
In den Eigenschaften des Connection Brokers ist der Lastenausgleich standardmäßig eingestellt. Es wurde nichts verändert.
Es gibt auch nur Probleme mit dieser einen Anwendung. Alle anderen haben dieses Problem nicht.
Woran kann dies liegen ?
Folgende Situation. Es gibt ein Problem auf einem Terminal Server.
Betriebssystem: Windows Server 2019
1x Connection Broker
3x Session Hosts
Auf den Session Host läuft eine Anwendung. Diese „verschwimmt“ wohl bei einigen Usern nach einiger Zeit und ist währenddessen nicht nutzbar. Kurz darauf geht diese wieder.
Laut Softwarehersteller könnte es am Load Balancing der Terminal Server liegen.
NLB ist an keinem Server installiert.
In den Eigenschaften des Connection Brokers ist der Lastenausgleich standardmäßig eingestellt. Es wurde nichts verändert.
Es gibt auch nur Probleme mit dieser einen Anwendung. Alle anderen haben dieses Problem nicht.
Woran kann dies liegen ?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5798697019
Url: https://administrator.de/contentid/5798697019
Ausgedruckt am: 23.11.2024 um 17:11 Uhr
19 Kommentare
Neuester Kommentar
Mahlzeit.
Was ist wenn du einen Remote Desktop Server aus dem Load Balancing nimmst und die Anwendung dann mal von ein paar Test Usern belastest?
Worum handelt es sich denn bei der mysteriösen Software? Läuft eine zentrale Datenbank irgendwo und die RDS Session Hosts greifen darauf zu?
Gruß
Marc
Was ist wenn du einen Remote Desktop Server aus dem Load Balancing nimmst und die Anwendung dann mal von ein paar Test Usern belastest?
Worum handelt es sich denn bei der mysteriösen Software? Läuft eine zentrale Datenbank irgendwo und die RDS Session Hosts greifen darauf zu?
Gruß
Marc
"Lastenausgleich" findet mit Windows Boardmitteln doch nur bei der Anmeldung der Sitzung statt und sorgt nicht dafür das aktive Sitzungen den Session Host wechseln. Ich halte die Aussage für groben Unfug, sofern hier nicht noch andere Software im Spiel ist (z.B. Citrix) die unter Umständen mehr kann.
- Um welche Anwendung geht es denn?
- Läuft nur die eine Anwendung auf den RD-SH?
- Reden wir von RemoteApp Bereitstellung oder wirklich eine komplette Session mit Desktop?
- Wie ist den die Auslastung und sonstige Performance an den RD-SH?
- Sind die RD-SH virtualisiert?
- Wenn ja, mit welchem Hypervisor? Wie ist die vCPU Zuteilung für die VM und für die anderen VMs auf dem selben Host? Welche CPU mit wie vielen Kernen ist verbaut?
- Um welche Anwendung geht es denn?
- Läuft nur die eine Anwendung auf den RD-SH?
- Reden wir von RemoteApp Bereitstellung oder wirklich eine komplette Session mit Desktop?
- Wie ist den die Auslastung und sonstige Performance an den RD-SH?
- Sind die RD-SH virtualisiert?
- Wenn ja, mit welchem Hypervisor? Wie ist die vCPU Zuteilung für die VM und für die anderen VMs auf dem selben Host? Welche CPU mit wie vielen Kernen ist verbaut?
Warum? Bist du / Seid ihr nicht der Betreuer?
Kannst du denn nicht einfach einen neuen RDS beim Kunden erstellen? Hast du denn überhaupt Zugriff auf die Infrastruktur des Kunden?
Die Anwendung ist Branchenspezifisch und hat eine Datenbank auf einem separaten Server
Welche Software ist das denn nun? Oder ist das ein Geheimnis und du musstest ein NDA unterschreiben?
Der ominöse Software-Hersteller kann dir vermutlich nicht genau sagen, warum Load-Balancing ein Problem sein soll, richtig?
Wie @ukulele-7 schon schrieb kann das technisch eigentlich kaum sein.
Gruß
Marc
Meine Glaskugel ist dunkel, mein Bauch sagt mir vielleicht ein Performance Problem der VM.
16 vCores für eine VM sind nicht wenig. Wie viele pCores hat der Host und wie viele nutzen die anderen VMs auf dem selben Host? CPU Overprovisioning lässt sich vermutlich leicht ausschließen: Wenn du die vCores mal auf 4 setzt und alleine auf dem RD-SH arbeitest, passiert das dann auch?
16 vCores für eine VM sind nicht wenig. Wie viele pCores hat der Host und wie viele nutzen die anderen VMs auf dem selben Host? CPU Overprovisioning lässt sich vermutlich leicht ausschließen: Wenn du die vCores mal auf 4 setzt und alleine auf dem RD-SH arbeitest, passiert das dann auch?
Hi,
hast du schon die üblichen Überprüfungen wie CPU, RAM, Netzwerk und Storage für Hosts + VMs und Anwendungsserver durchgeführt? Es kann auch hilfreich sein zu wissen, bei welchen Aktionen die Anwendung in Streik geht. Wartet sie auf Daten des Servers oder auf das Ergebnis einer Berechnung des Clients?
Gruß,
Thomas
hast du schon die üblichen Überprüfungen wie CPU, RAM, Netzwerk und Storage für Hosts + VMs und Anwendungsserver durchgeführt? Es kann auch hilfreich sein zu wissen, bei welchen Aktionen die Anwendung in Streik geht. Wartet sie auf Daten des Servers oder auf das Ergebnis einer Berechnung des Clients?
Gruß,
Thomas
Moin...
das sagt uns nix- schreibe doch Bitte, welche Software es ist!
Frank
das sagt uns nix- schreibe doch Bitte, welche Software es ist!
- Auf dem RDSH laufen auch noch weitere Anwendung
fein - komplette Session mit Desktop
- Ansonsten keinerlei Probleme
- Ja sind virtualisiert
- ESXi, CPU ist ein Intel Xeon und die RDSHs haben 16vCPU
16vCPU ? für welche anzahl an User? und was genau ist das für eine CPU, bitte schreibe nicht nur Intel Xeon, sondern die genaue bezeichnung! was wurde an Cores an andere VMs verteilt?- Ansonsten keinerlei Probleme
- Ja sind virtualisiert
- ESXi, CPU ist ein Intel Xeon und die RDSHs haben 16vCPU
Frank
Ich denke mal es könnte ggf. an der Overprovisioning der CPU´s liegen denn du schreibst das es 3 Session Hosts gibt.
Das wären dann 3*16=48 Kerne. Ja klar bis zu einen Punkt kann man überprovisionieren aber irgendwo ist halt auch Schluss. Wenn der CPU nur 12 Core hat wäre das schon eine ordentliche Überprovisionierung.
Nutzt ihr normale Desktop ( Fatclient ) oder setzt Ihr auf Thin Clients ?
Es ist nur die eine Software die verschwimmt ?
Habt Ihr auf den Sessionhosts irgendwelche zusätzlichen Treiber ( Teamviewer Grafiktreiber etc... ) installiert ?
Am Loadbalancing kann es eigentlich nicht liegen das hat @ukulele-7 oben ja schon geschreiben. Der Lastausgleich findet statt bevor die Verbindung aufgebaut wird und im Betrieb wird auch nichts gewechselt. Zumindet auf der TS Seite.
Ihr habt ESX im Einsatz.....
Habt Ihr da irgendwelche Tools wie DRS / HA / oder ähnliches an ?
Eventuell versucht der ESX ja im Hintergrund permanent die VM von einem Host auf den anderen zu schieben damit die Hosts gleich ausgelastet sind. Das kann u.u zu Problemen führen
Das wären dann 3*16=48 Kerne. Ja klar bis zu einen Punkt kann man überprovisionieren aber irgendwo ist halt auch Schluss. Wenn der CPU nur 12 Core hat wäre das schon eine ordentliche Überprovisionierung.
Nutzt ihr normale Desktop ( Fatclient ) oder setzt Ihr auf Thin Clients ?
Es ist nur die eine Software die verschwimmt ?
Habt Ihr auf den Sessionhosts irgendwelche zusätzlichen Treiber ( Teamviewer Grafiktreiber etc... ) installiert ?
Am Loadbalancing kann es eigentlich nicht liegen das hat @ukulele-7 oben ja schon geschreiben. Der Lastausgleich findet statt bevor die Verbindung aufgebaut wird und im Betrieb wird auch nichts gewechselt. Zumindet auf der TS Seite.
Ihr habt ESX im Einsatz.....
Habt Ihr da irgendwelche Tools wie DRS / HA / oder ähnliches an ?
Eventuell versucht der ESX ja im Hintergrund permanent die VM von einem Host auf den anderen zu schieben damit die Hosts gleich ausgelastet sind. Das kann u.u zu Problemen führen
3 RD-SH kann auch bedeuten ein RD-SH pro ESXi Host in einem Essentials Paket, finde ich naheliegend aber weiß ich natürlich nicht.
Wie schon gesagt Performance Probleme aufgrund schlechter vCPU Aufteilung kann man leicht durch Tests ausschließen: Den Workload auf dem ESXi reduzieren, die CPUs des RD-SH runter setzen auf 4 und das Problem ohne andere Benutzer noch mal provozieren. Verhält sich das Programm dann anders ist es ein Performance Problem und hat vermutlich mit der vCore Aufteilung aller VMs auf dem Host zu tun.
Ist das Problem unverändert ist vermutlich einfach die Software ###e was die RDP Darstellung angeht, das gibt's halt auch. Hierfür wären dann aber Informationen relevant wie z.B. seit wann läuft die Software schon auf RD-SH und war das Verhalten schon immer so?
Wie schon gesagt Performance Probleme aufgrund schlechter vCPU Aufteilung kann man leicht durch Tests ausschließen: Den Workload auf dem ESXi reduzieren, die CPUs des RD-SH runter setzen auf 4 und das Problem ohne andere Benutzer noch mal provozieren. Verhält sich das Programm dann anders ist es ein Performance Problem und hat vermutlich mit der vCore Aufteilung aller VMs auf dem Host zu tun.
Ist das Problem unverändert ist vermutlich einfach die Software ###e was die RDP Darstellung angeht, das gibt's halt auch. Hierfür wären dann aber Informationen relevant wie z.B. seit wann läuft die Software schon auf RD-SH und war das Verhalten schon immer so?
Der Softwarehersteller vermutet, dass es am Load Balancing des Terminalservers liegt.
Nochmal, das kann nicht sein, da der User niemals während der aktiven Session auf einen anderen Session Host geschoben wird.
Das Loadbalancing betrifft nur Neuanmeldungen.
Bei dem Prozessor handelt es sich um ein Intel Xeon Gold 6254 3,10GHz
Das heißt die 18 Kern / 36 Thread CPU hat schon drei VMs, welche jeweils 16 vCPU haben. Es sollte generell die Faustformel beachtet werden, dass nie mehr als das Zwei- oder im Äußersten das Dreifache der physischen Threads "bebucht" sind.
Wie ist denn der Host generell an RAM und HDD / SSD (lokaler Speicher oder SAN mittels iSCSi oder FibreChannel) ausgestattet und vor allem ausgelastet?
Welche Konfiguration haben denn die einzelnen Session Hosts (RAM / Speicher)?
Vielleicht ist es auch ein IOPS Problem. Denn 80 - 100 User auf drei Session Hosts ist jetzt kein Pappenstiel. Da wäre ein weiterer SH schon sinnvoll.
Da brauchen bloß 30 % auf die Idee kommen Teams laufen zu lassen und schon gibt es da massig an RAM, der vorhanden sein muss.
Gruß
Marc
Da die Software erst einen Monat auf RD-SH läuft und der Software Hersteller so abwegige Vermutungen anstellt tendiere ich dazu das eventuell beides problematisch ist. Zum einen die vCPU Konstellation aber zum anderen könnte die Software einfach ###e auf RD-SH laufen.
Zur vCPU (das was man hier gut bewerten kann auch ohne konkreten Testlauf):
1) Ein oder Zwei Xeon 6254?
2) Von der Faustformel halte ich nicht so viel. Das Problem sind eigentlich nur im Verhältnis vCore zu pCore große VMs die häufig CPU Zeit buchen. Mal ganz grob erklärt: Braucht irgend ein Vorgang auf der VM für kurze Zeit auch nur einen vCore (also auf einem RD-SH ständig), dann muss der Hypvervisor der VM CPU Zeit für ALLE ihre vCores gewähren, also quasi 1 Takt auf 16 pCores. Die übrigen 2 pCores können in der Zeit andere VMs bedienen aber natürlich nur eine bis maximal 2 vCore. Braucht eine andere VM für mehr als 2 vCores CPU Zeit muss sie warten bis wieder entsprechend pCores frei sind. Es können also in deinem Fall nie 2 RD-SH VMs gleichzeitig Rechenzeit bekommen und das ist immer schlecht, weniger vCore ist mehr. Meistens ist die Verteilung auf mehr und kleinere VMs damit besser aber natürlich muss auch das over all vCore / pCore-Verhältnis funktionieren.
3) Du kannst solche Probleme auch beobachten: https://www.yellow-bricks.com/esxtop/
4) Du kannst eventuell das Replika unterbrechen und auf der Replik Tests laufen lassen.
Zur vCPU (das was man hier gut bewerten kann auch ohne konkreten Testlauf):
1) Ein oder Zwei Xeon 6254?
2) Von der Faustformel halte ich nicht so viel. Das Problem sind eigentlich nur im Verhältnis vCore zu pCore große VMs die häufig CPU Zeit buchen. Mal ganz grob erklärt: Braucht irgend ein Vorgang auf der VM für kurze Zeit auch nur einen vCore (also auf einem RD-SH ständig), dann muss der Hypvervisor der VM CPU Zeit für ALLE ihre vCores gewähren, also quasi 1 Takt auf 16 pCores. Die übrigen 2 pCores können in der Zeit andere VMs bedienen aber natürlich nur eine bis maximal 2 vCore. Braucht eine andere VM für mehr als 2 vCores CPU Zeit muss sie warten bis wieder entsprechend pCores frei sind. Es können also in deinem Fall nie 2 RD-SH VMs gleichzeitig Rechenzeit bekommen und das ist immer schlecht, weniger vCore ist mehr. Meistens ist die Verteilung auf mehr und kleinere VMs damit besser aber natürlich muss auch das over all vCore / pCore-Verhältnis funktionieren.
3) Du kannst solche Probleme auch beobachten: https://www.yellow-bricks.com/esxtop/
4) Du kannst eventuell das Replika unterbrechen und auf der Replik Tests laufen lassen.
Gute Voraussetzung also.
Wie viel vCPU würdet ihr einem RDSH geben? Gibts da irgendeinen Richtwert, an dem man sich da halten sollte?
Am besten 4 oder maximal 8 vCPU pro RDSH. Damit sollten die VMs allemal zurechtkommen.
Wie sind die Maschinen und der Host denn nun generell ausgelastet? Haben alle immer das Problem oder nur sich ab einer gewissen Anzahl an Usern zusätzlich, anmeldenden User?
Gruß
Marc
Moin zusammen,
ich habe für RDSHs mal so grob beigebracht bekommen: 2-3 GB RAM pro User und wenn es geht nicht mehr als 10-16 User pro Host. Dann finde ich persönlich, dass Windows mit min. 4 Kernen einfach gut läuft und wenn die 4 dann mächtig ackern auf dem RDSH, dann hoch auf 6 oder bei Bedarf 8 Kerne.
Also in diesem Fall würde ich bei bis zu 100 Usern bereits 6 RDSH betreiben - sofern natürlich der Unterbau (ESXi) auch passend Ressourcen bereitstellt.
Grüße,
ich habe für RDSHs mal so grob beigebracht bekommen: 2-3 GB RAM pro User und wenn es geht nicht mehr als 10-16 User pro Host. Dann finde ich persönlich, dass Windows mit min. 4 Kernen einfach gut läuft und wenn die 4 dann mächtig ackern auf dem RDSH, dann hoch auf 6 oder bei Bedarf 8 Kerne.
Also in diesem Fall würde ich bei bis zu 100 Usern bereits 6 RDSH betreiben - sofern natürlich der Unterbau (ESXi) auch passend Ressourcen bereitstellt.
Grüße,
Moin...
hm OK.
Wie viel vCPU würdet ihr einem RDSH geben? Gibts da irgendeinen Richtwert, an dem man sich da halten sollte?
nein, natürlich kommt das auch auf deine Anwendungen an.
mit 3x 16 vCore pro RD Host, ist die Kiste völlig überbucht, aus meiner sicht.
bei 100 User würde ich 4 RD Host nutzen wollen, je nachden max 12vCore, mit 8 würde ich anfangen.
du kannst es drehen und wenden, aber dir fehlt ein ESXI für den 4 RD Host.
die nächste Frage, nach dem Storage... von was reden wir, Spindeln, SSD, NVMe? IO Last ist wie hoch?
der Xeon 6254 ist jetzt keine schlechte CPU, aber warscheinlich für das Setup falsch ausgewählt.
klar der hohe CPU takt, macht sich bei singel Core anwendungen bemerkbar, aber für die RDS Host wäre warscheinlich ein Intel Xeon Gold 6240R SRGZ8 24C die bessere wahl gewesen.
für den DB Server wäre warscheinlich der hohe Takt ok gewesen (SQL), aber dann als extra Server mit weniger Core!
da du den namen deiner anwendung nicht sagen möchtest, wird es schwer dazu etwas zu sagen, nur aus dem Bauch raus, ist das ganze setup falsch ausgewählt worden.
Frank
hm OK.
Wie viel vCPU würdet ihr einem RDSH geben? Gibts da irgendeinen Richtwert, an dem man sich da halten sollte?
mit 3x 16 vCore pro RD Host, ist die Kiste völlig überbucht, aus meiner sicht.
bei 100 User würde ich 4 RD Host nutzen wollen, je nachden max 12vCore, mit 8 würde ich anfangen.
du kannst es drehen und wenden, aber dir fehlt ein ESXI für den 4 RD Host.
die nächste Frage, nach dem Storage... von was reden wir, Spindeln, SSD, NVMe? IO Last ist wie hoch?
der Xeon 6254 ist jetzt keine schlechte CPU, aber warscheinlich für das Setup falsch ausgewählt.
klar der hohe CPU takt, macht sich bei singel Core anwendungen bemerkbar, aber für die RDS Host wäre warscheinlich ein Intel Xeon Gold 6240R SRGZ8 24C die bessere wahl gewesen.
für den DB Server wäre warscheinlich der hohe Takt ok gewesen (SQL), aber dann als extra Server mit weniger Core!
da du den namen deiner anwendung nicht sagen möchtest, wird es schwer dazu etwas zu sagen, nur aus dem Bauch raus, ist das ganze setup falsch ausgewählt worden.
Frank
Grundsätzlich würde ich versuchen weniger vCPU zu vergeben, idealerweise nicht mehr als 8 in deinem Fall. Reicht das nicht muss man einfach auch sehen das vielleicht ein Server (auch wenn der gut ausgestattet ist) zu wenig in dem Setup ist, es kommt aber einfach auf die Anwendungen an. Aber 3 GB RAM erscheinen mir auch wenig wenn die User z.B. mit vielen Tabs surfen...
Entscheidend ist das man klein anfängt und das beobachten muss.
CPUs mit hoher single thread performance finde ich grade für Terminal Server gut. Ich habe hier den 6154 aber 2x2 für 35 User. Da hat also ein User ein ganz anderes Gewicht.
3 RD-SH finde ich auch wenig, sowohl in der Performance als auch in der Administration. Wenn einer Probleme macht sind gleich > 30 User betroffen. Die DATEV hat mir mal gesagt das die im ASP (Hosting von RD-SH bei der DATEV) mit 4-5 Usern pro RD-SH kalkulieren. Warum genau wusste allerdings keiner mehr so richtig
Entscheidend ist das man klein anfängt und das beobachten muss.
CPUs mit hoher single thread performance finde ich grade für Terminal Server gut. Ich habe hier den 6154 aber 2x2 für 35 User. Da hat also ein User ein ganz anderes Gewicht.
3 RD-SH finde ich auch wenig, sowohl in der Performance als auch in der Administration. Wenn einer Probleme macht sind gleich > 30 User betroffen. Die DATEV hat mir mal gesagt das die im ASP (Hosting von RD-SH bei der DATEV) mit 4-5 Usern pro RD-SH kalkulieren. Warum genau wusste allerdings keiner mehr so richtig