8
Terminalserver ein großer oder mehrere kleine?
Moin,
ich lese immer mal wieder, dass es besser sei, mehrere kleine Terminalserver zu bauen statt einen großen. Das sei perfomanter. Da ich demnächst für eine recht große Usergruppe "einen" Terminalserver einrichten werde, interessiert mich die Frage brennend. Bisher hatte ich es nur mit Terminalservern für kleine Usergruppen zu tun (max. ca. 30). Bei dem neuen sollen aber so ca. 150 User gleichzeitig via VPN zugreifen. Was ist besser?
Gesetzt ich habe einen Server mit hinreichend ausgestatteter Hardware. Auf diesem läuft Proxmox als Virtualisierer. Nein, kein anderer. Das ist Vorgabe. Ist es dann besser, wenn ich einen großen TS auf dem System einrichte mit allen verfügbaren Kernen (16 oder 32 insgesamt) und allem Arbeitsspeicher oder sagen wir vier, auf die ich dann Kerne und Speicher verteile? (Ja, ich weiß, dass Proxmox auch ein wenig davon braucht.
)
Oder gesetzt, ich habe 20.000 € für die Hardware zur Verfügung. Besser ein Monster anschaffen oder vier Mittelklasseserver?
Ich würde so aus dem Bauch heraus sagen, dass ein großer günstiger ist, weil ich dann nur einmal den Overhead des Betriebssystems habe und nicht viermal und auch der Virtualisierer nur eine Maschine und nicht vier verwalten muss. Aber vielleicht gibt es ja andere Gründe oder Erfahrungen, die das Gegenteil begründen.
Liebe Grüße
Erik
P.S.: Die Anzahl der Server ist ein Beispiel. Wir wissen noch nicht, wieviel Hardware wir da draufwerfen müssen. Wir stehen noch vor dem Anfang der Planung.
ich lese immer mal wieder, dass es besser sei, mehrere kleine Terminalserver zu bauen statt einen großen. Das sei perfomanter. Da ich demnächst für eine recht große Usergruppe "einen" Terminalserver einrichten werde, interessiert mich die Frage brennend. Bisher hatte ich es nur mit Terminalservern für kleine Usergruppen zu tun (max. ca. 30). Bei dem neuen sollen aber so ca. 150 User gleichzeitig via VPN zugreifen. Was ist besser?
Gesetzt ich habe einen Server mit hinreichend ausgestatteter Hardware. Auf diesem läuft Proxmox als Virtualisierer. Nein, kein anderer. Das ist Vorgabe. Ist es dann besser, wenn ich einen großen TS auf dem System einrichte mit allen verfügbaren Kernen (16 oder 32 insgesamt) und allem Arbeitsspeicher oder sagen wir vier, auf die ich dann Kerne und Speicher verteile? (Ja, ich weiß, dass Proxmox auch ein wenig davon braucht.
)Oder gesetzt, ich habe 20.000 € für die Hardware zur Verfügung. Besser ein Monster anschaffen oder vier Mittelklasseserver?
Ich würde so aus dem Bauch heraus sagen, dass ein großer günstiger ist, weil ich dann nur einmal den Overhead des Betriebssystems habe und nicht viermal und auch der Virtualisierer nur eine Maschine und nicht vier verwalten muss. Aber vielleicht gibt es ja andere Gründe oder Erfahrungen, die das Gegenteil begründen.
Liebe Grüße
Erik
P.S.: Die Anzahl der Server ist ein Beispiel. Wir wissen noch nicht, wieviel Hardware wir da draufwerfen müssen. Wir stehen noch vor dem Anfang der Planung.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 576349
Url: https://administrator.de/contentid/576349
Printed on: April 20, 2024 at 05:04 o'clock
8 Comments
Latest comment
Was machen die User auf dem Server?
N+1 würde ich vorziehen.
N+1 würde ich vorziehen.
Moin,
also bei 150Usern würde ich weg von nur einem TS gehen.
Man stelle sich vor, der TS zickt rum, dann sind direkt mal 150 User arbeitslos.
Mit ausreichend RAM und CPU und Netzwerkanbindung sollten sicherlich "sorgenfrei" 50 USer auf einem TS unterbringen können. Hängt aber auch davon ab, was die so vorhaben.
Wenn viele mit Browsern arbeiten, blähen die die CPU und den Ram brav auf. Oder viel mit PPT/ Excel.... am besten noch unkomprimierte 4k-Bitmaps^^
Ich denke, so ganz pauschal kann man das nicht beantworten, aber einer wäre mir persönlich zu wenig - schon alleine des Ausfallszenarios wegen...
Gruß
em-pie
also bei 150Usern würde ich weg von nur einem TS gehen.
Man stelle sich vor, der TS zickt rum, dann sind direkt mal 150 User arbeitslos.
Mit ausreichend RAM und CPU und Netzwerkanbindung sollten sicherlich "sorgenfrei" 50 USer auf einem TS unterbringen können. Hängt aber auch davon ab, was die so vorhaben.
Wenn viele mit Browsern arbeiten, blähen die die CPU und den Ram brav auf. Oder viel mit PPT/ Excel.... am besten noch unkomprimierte 4k-Bitmaps^^
Ich denke, so ganz pauschal kann man das nicht beantworten, aber einer wäre mir persönlich zu wenig - schon alleine des Ausfallszenarios wegen...
Gruß
em-pie
Hi
die Antwort ist hier wie quasi immer: Kommt ganz drauf an.
Bei TS Performance gibt es im Grunde 2 große Themen: CPU und Disk-IO. Letzteres lässt sich heute mit SSDs ja recht einfach in den Griff bekommen.
Interessanter ist da dann schon die CPU Leistung. Und da kommt es dann schwer drauf an was die User da auf dem TS treiben.
Läuft da einfach nur ein SAP Client pro User?
Ist das ein Desktopersatz mit Mail, Browser, Excel etc?
Sind sonstige CPU-Intensive Dinge am laufen?
usw usw
Mehr User bedeutet mehr Prozesse. Mehr Prozesse bedeutet, das die CPU-Zeit pro Prozess sinkt und irgendwann die Wartezeit, bis ein Prozess einen Kern zum Arbeiten bekommt, steigt. Wenn die User also viele Prozesse starten, die dann auch noch viel Leistung beanspruchen, dann will man lieber mehr CPUs haben, da diese dann die Request aufteilen.
Ich pers. nehme für normale TS lieber mehrere Bleche. Das hat einerseits den Performancegrund, andererseits aber natürlich auch den der Redundanz.
So richtige CPU Monster kommen IMHO eigentlich nur für so Dinge wie CAD, Simulationen etc in betracht. Und da verschiebt sich das eigentlich auch immer mehr in GPU-getriebene Anwendungen, wo die CPU nicht mehr so die Rolle spielt. Dazu kommt, das heutige CPUs schon wahnsinnig viel Power haben und man für sehr viel mehr Geld nur marginal mehr Leistung bekommt
die Antwort ist hier wie quasi immer: Kommt ganz drauf an.
Bei TS Performance gibt es im Grunde 2 große Themen: CPU und Disk-IO. Letzteres lässt sich heute mit SSDs ja recht einfach in den Griff bekommen.
Interessanter ist da dann schon die CPU Leistung. Und da kommt es dann schwer drauf an was die User da auf dem TS treiben.
Läuft da einfach nur ein SAP Client pro User?
Ist das ein Desktopersatz mit Mail, Browser, Excel etc?
Sind sonstige CPU-Intensive Dinge am laufen?
usw usw
Mehr User bedeutet mehr Prozesse. Mehr Prozesse bedeutet, das die CPU-Zeit pro Prozess sinkt und irgendwann die Wartezeit, bis ein Prozess einen Kern zum Arbeiten bekommt, steigt. Wenn die User also viele Prozesse starten, die dann auch noch viel Leistung beanspruchen, dann will man lieber mehr CPUs haben, da diese dann die Request aufteilen.
Ich pers. nehme für normale TS lieber mehrere Bleche. Das hat einerseits den Performancegrund, andererseits aber natürlich auch den der Redundanz.
So richtige CPU Monster kommen IMHO eigentlich nur für so Dinge wie CAD, Simulationen etc in betracht. Und da verschiebt sich das eigentlich auch immer mehr in GPU-getriebene Anwendungen, wo die CPU nicht mehr so die Rolle spielt. Dazu kommt, das heutige CPUs schon wahnsinnig viel Power haben und man für sehr viel mehr Geld nur marginal mehr Leistung bekommt
Moin,
Gruß,
Dani
Was ist besser?
eine Mischung zwischen wirtschaftlich und Redundanz. Unser RDSs sind immer so konzeptiert, dass eine VM ausfallen und trotzdem alle Benutzer weiterarbeiten können. Abgesehen von Wartungsarbeiten innerhalb der VM machen wir ungern abends/nachts. Schließlich ist Zeit nach wie vor Geld...Auf diesem läuft Proxmox als Virtualisierer.
Da kann ich dir nichts dazu sagen.Gruß,
Dani
Ich habe hier auf der einen Farm 80-90 User gleichzeitig und auf der anderen 150.
Ich betreibe jeweils 6 RDS Hosts pro Farm.
Die mit 150 Usern ist für die Produktion und dort läuft nur ein Programm. Theoretisch schaffen es auch 2 RDS Host allein, aber dann steigt die CPU Last nahe an 100% während des Schichtwechsels.
Die Farm mit 80-90 Usern teile ich auf 6 RDS Hosts auf, welche per DRS auf 5 VM Hosts aufgeteilt werden. Die Erfahrung hat uns gezeigt, dass wir damit besser fahren, da es hin und wieder User gibt, welche mit Excel Reports aus SAP die VM in die Knie zwingen oder blockieren. So betrifft es dann "nur" 10 statt 40 oder 80 User.
Bis vor 2 Jahren hatten wir noch 4 zusätzliche Bleche als RDS Hosts. Mittlerweile haben wir nur noch virtuelle RDS Host, welche alle auf einem FullFlash SSD Storage liegen.
In den nächsten Jahren wollen wir 1 RDS Farm mit NVIDIA Grid Karten ausstatten.
Bei 6 Hosts in meinem Fall kann ich bei bedarf auch immer 2 sperren für Software Wartung und kann dies während des Live Betriebs erledigen.
Ich betreibe jeweils 6 RDS Hosts pro Farm.
Die mit 150 Usern ist für die Produktion und dort läuft nur ein Programm. Theoretisch schaffen es auch 2 RDS Host allein, aber dann steigt die CPU Last nahe an 100% während des Schichtwechsels.
Die Farm mit 80-90 Usern teile ich auf 6 RDS Hosts auf, welche per DRS auf 5 VM Hosts aufgeteilt werden. Die Erfahrung hat uns gezeigt, dass wir damit besser fahren, da es hin und wieder User gibt, welche mit Excel Reports aus SAP die VM in die Knie zwingen oder blockieren. So betrifft es dann "nur" 10 statt 40 oder 80 User.
Bis vor 2 Jahren hatten wir noch 4 zusätzliche Bleche als RDS Hosts. Mittlerweile haben wir nur noch virtuelle RDS Host, welche alle auf einem FullFlash SSD Storage liegen.
In den nächsten Jahren wollen wir 1 RDS Farm mit NVIDIA Grid Karten ausstatten.
Bei 6 Hosts in meinem Fall kann ich bei bedarf auch immer 2 sperren für Software Wartung und kann dies während des Live Betriebs erledigen.
Definitiv mehrere RD-SH VMs auf dem Blech oder mehreren Blechen, für einen 2 HE Server mit 2 CPU a la Xeon Gold 62xx am oberen Ende kannst du aber bestimmt 15.000 rechnen, da ist dein Budget gar nicht so groß.
Dein erstes Problem ist CPU. Hast du eine VM mit vielen CPUs muss der Hypervisor, wenn er dieser VM Rechenzeit gewährt, alle CPUs dafür frei machen. Simples Beispiel: 1 CPU im Host mit 16 Kernen. Deine VM hat 16 Kerne. Will jetzt der Hypervsior oder irgendeine andere VM Rechenzeit muss deine wichtigste VM warten bis 16 Kerne gleichzeitig frei sind. Also niemals zuviele Kerne einer VM geben, weniger ist mehr (natürlich nicht für die User, daher mehr VMs mit weniger CPU).
Wenn du jetzt 2 CPUs im System hast ist jede an die hälfte des RAMs angebunden, ggf. trifft das auch auf andere Ressourcen zu. Belegt jetzt eine einzelne VM mehr Kerne oder mehr RAM als eine CPU/RAM-Kombination hat müssen Daten zwischen den CPUs fließen (NUMA, QPI, wie auch immer) und da entsteht dann ein weiterer Flaschenhals.
Und zu guter letzt die Probleme aus der Praxis. Gestern: Ein User macht eine Excel-Berechnung und schluckt 90%+ CPU für ~15 Minuten. Dann ist die Anzahl der User auf der VM - 1 in etwa die Anzahl der Anrufe die ich bekomme. Du kannst Ressourcen von Windows nicht limitieren, die Ressourcen einer VM schon. Heute: Profilliste am RD-SH aufgerufen. Die läd mit 30 Profilen schon echt lange...
Das schöne ist du kannst mit wenig RD-SH anfangen und dann erweitern. Aber ein RD-SH mit 150 Usern die mehr machen als Texteditor würde mir sofort Bauchschmerzen bereiten.
Dein erstes Problem ist CPU. Hast du eine VM mit vielen CPUs muss der Hypervisor, wenn er dieser VM Rechenzeit gewährt, alle CPUs dafür frei machen. Simples Beispiel: 1 CPU im Host mit 16 Kernen. Deine VM hat 16 Kerne. Will jetzt der Hypervsior oder irgendeine andere VM Rechenzeit muss deine wichtigste VM warten bis 16 Kerne gleichzeitig frei sind. Also niemals zuviele Kerne einer VM geben, weniger ist mehr (natürlich nicht für die User, daher mehr VMs mit weniger CPU).
Wenn du jetzt 2 CPUs im System hast ist jede an die hälfte des RAMs angebunden, ggf. trifft das auch auf andere Ressourcen zu. Belegt jetzt eine einzelne VM mehr Kerne oder mehr RAM als eine CPU/RAM-Kombination hat müssen Daten zwischen den CPUs fließen (NUMA, QPI, wie auch immer) und da entsteht dann ein weiterer Flaschenhals.
Und zu guter letzt die Probleme aus der Praxis. Gestern: Ein User macht eine Excel-Berechnung und schluckt 90%+ CPU für ~15 Minuten. Dann ist die Anzahl der User auf der VM - 1 in etwa die Anzahl der Anrufe die ich bekomme. Du kannst Ressourcen von Windows nicht limitieren, die Ressourcen einer VM schon. Heute: Profilliste am RD-SH aufgerufen. Die läd mit 30 Profilen schon echt lange...
Das schöne ist du kannst mit wenig RD-SH anfangen und dann erweitern. Aber ein RD-SH mit 150 Usern die mehr machen als Texteditor würde mir sofort Bauchschmerzen bereiten.
Moin,
erstmal allen Dank, die geantwortet haben. Ich packe nochmal ein wenig Butter bei die Fische:
Auf dem TS werden die Standardanwendungen Word, Excel (keine großen Tabellen, eher einfache Listen), Outlook, Firefox und die Clients einer auf einem MSSQL basierende Branchenlösung laufen. Word, Outlook, FF und die Branchensoftware laufen in der Regel gleichzeitig und werden auch gleichzeitig benutzt.
Bisher habe ich folgendes verstanden:
Mehrere kleine TS haben den Vorteil, dass man sie einzeln warten kann, dass einzelne User nur einen kleinen Teil der Ressourcen blockieren können, dass bei Ausfall nur ein Teil betroffen ist. Das hilft schonmal ungemein.
Liebe Grüße
Erik
erstmal allen Dank, die geantwortet haben. Ich packe nochmal ein wenig Butter bei die Fische:
Auf dem TS werden die Standardanwendungen Word, Excel (keine großen Tabellen, eher einfache Listen), Outlook, Firefox und die Clients einer auf einem MSSQL basierende Branchenlösung laufen. Word, Outlook, FF und die Branchensoftware laufen in der Regel gleichzeitig und werden auch gleichzeitig benutzt.
Bisher habe ich folgendes verstanden:
Mehrere kleine TS haben den Vorteil, dass man sie einzeln warten kann, dass einzelne User nur einen kleinen Teil der Ressourcen blockieren können, dass bei Ausfall nur ein Teil betroffen ist. Das hilft schonmal ungemein.
Liebe Grüße
Erik
N'Abend.
Und in dem Fall haben Sie Recht: Du hast plötzlich zwanzig, dreißig User mehr? Kein Problem, weiteren Server zur Farm hinzufügen, Drops gelutscht. Keine Anpassung von VM-Resourcen etc. Plötzlich Home Office für jeden (ist ja grad nicht mehr ganz so unwahrscheinlich....)? Auch kein Ding, einfach nen Server dazu gepackt und wenn der Spuk vorbei ist, wieder weg damit.
Gut, dieses Szenario ^^ setzt entsprechende Lizenzierung voraus. Oder eben das Einwerfen weiterer Coins für zusäztlich benötigte Lizenzen, aber ich halte das für verkraft- und vertretbar.
Da jede Seite zwei Medaillen hat: Mehrere Server erfordern natürlich auch ein entsprechendes Konzept für Updates, so musst du deine Fachanwendung eben auf n Server updaten statt nur auf einem. Gutes Skripting etc. hilft da ungemein.
Cheers,
jsysde
Zitat von @erikro:
[...]Mehrere kleine TS haben den Vorteil, dass man sie einzeln warten kann, dass einzelne User nur einen kleinen Teil der Ressourcen blockieren können, dass bei Ausfall nur ein Teil betroffen ist. Das hilft schonmal ungemein.
Wenn du einmal mit ner RDS-Farm angefangen hast, wirst du sehr schnell deren Vorteile erkennen. Emsige Consultants sagen immer: "Das skaliert besser". [...]Mehrere kleine TS haben den Vorteil, dass man sie einzeln warten kann, dass einzelne User nur einen kleinen Teil der Ressourcen blockieren können, dass bei Ausfall nur ein Teil betroffen ist. Das hilft schonmal ungemein.
Und in dem Fall haben Sie Recht: Du hast plötzlich zwanzig, dreißig User mehr? Kein Problem, weiteren Server zur Farm hinzufügen, Drops gelutscht. Keine Anpassung von VM-Resourcen etc. Plötzlich Home Office für jeden (ist ja grad nicht mehr ganz so unwahrscheinlich....)? Auch kein Ding, einfach nen Server dazu gepackt und wenn der Spuk vorbei ist, wieder weg damit.
Gut, dieses Szenario ^^ setzt entsprechende Lizenzierung voraus. Oder eben das Einwerfen weiterer Coins für zusäztlich benötigte Lizenzen, aber ich halte das für verkraft- und vertretbar.
Da jede Seite zwei Medaillen hat: Mehrere Server erfordern natürlich auch ein entsprechendes Konzept für Updates, so musst du deine Fachanwendung eben auf n Server updaten statt nur auf einem. Gutes Skripting etc. hilft da ungemein.
Cheers,
jsysde
1
