Linux Terminal Server - Technische Möglichkeiten und Best Practices

gunnarh

Allwissende Müllhalde
Wir steuern voraussichtlich auf ein Projekt zu, welches mit einem Terminalserver zu realisieren wäre.

Die Projektdetails zu beschreiben würde den Rahmen sprengen - nur kurz umrissen damit ein kleiner Eindruck entsteht:

WinXP Clients (ich rechne mit 2000 concurrent Usern) sollen auf einen Terminalserver zugreifen. Auf diesem Terminalserver soll zumindest ein Webbrowser, wenn möglich auch ein Office angeboten werden. Diese Anforderung mag etwas eigenartig klingen - aber es geht um die Möglichkeit den Anwendern eine sichere Surf-Umgebung zu schaffen, also Surfen nicht direkt am Anwender-Arbeitsplatz, sondern über eine Terminalserver-Sitzung auf einem zentral gewarteten Terminalserver (bitte keine Diskussion zu dieser Anforderung selbst - ich kann nicht mehr Details preisgeben, die Anforderung hat jedenfalls konkrete Hintergründe und ihre Berechtigung).

Die Anforderung kann man voraussichtlich mit Linux oder Windows Servern erfüllen. Als Webbrowser wäre z.b. Firefox präferiert (wichtig: wir benötigen volle Shockwave, Flash, PDF-Reader, Java, ... Unterstützung und hohe Kompatibilität zu typischen Web-Inhalten). Als (optionales) Office könnte mit Openoffice das Auslangen gefunden werden. Details wie das Erzeugen von PDFs etc... sind wohl auch auf beiden Plattformen lösbar.


Nun zu den Fragen:

Lösungen von Citrix (vorwiegend auf Windows-Servern, jedoch auch für Solaris oder HP-UX verfügbar - leider nicht für Linux) kenne ich oberflächlich.

Lösungen für Linux wären meiner Recherche nach:

  • X11 Sitzung => ungeeignet da zwischen Server und Clients nur WAN Verbindung (z.b. 64kbit) mit hoher Latenz besteht
  • NoMaschine NX => erscheint mir ersten Tests zufolge geeignet
  • VNC - meinen ersten oberflächlichen Tests zufolge würde ich NoMachine bevorzugen.

Kann jemand noch andere Lösungen nennen oder von Erfahrungen aus der Praxis zu den von mir genannten Lösungen berichten?

folgende Anforderungen wären dabei zu bedenken:

  • geringer Server- und Bandbreiten-Resourcenbedarf
  • wir müssen mehrere tausend concurrent Sessions mit möglichst wenigen Servern realisieren
  • dies mit einer einzigen "dicken" Kiste zu realisieren erscheint mir unmöglich, ich hätte aus dem Bauch heraus auf maximal 200 concurrent User pro Server (4 XEON CPUs, ausreichend RAM, ...) geschätzt - hat jemand konkretere Erfahrungswerte? Die Lösung muss also für eine wachsende Serverzahl skalierbar sein, idealerweise auch Redundanz bieten.
  • Bandbreite zwischen Server und Anwendern ist firmeninternes WAN, es sollte nicht mehr als 64-128kbit pro Anwender nötig sein um vernünftig arbeiten zu können.
  • Auch Multimediainhalte müssen teilweise konsumiert werden können. Die Nutzung von Inhalten mit Shockwave, Flash bis hin zu Extemfällen wie Youtubevideos auch mit Ton sollten technisch realisiert werden können.
  • Wenn jemand gute Gründe hat, die gegen Linux sprechen (z.b. weil die Terminalserver Lösungen von Citrix unter Solaris, HP-UX oder Windows-Servern einfach die bessere wahl sind bitte ebenfalls um eine Wortmeldung)
 
Hallo gunnarh,

ich habe im Moment ein Projekt am laufen mit LTSP. http://www.ltsp.org

Es sind allerdings keine 2000 User sondern nur 25. Diese bestehen zu 90% aus Handelsüblichen PC's mit PXE Option.

Als Server wird ein Intel Xeon 3360 verwendet mit 8 GB Ram und 2 x 1000 GB Disks als Hardware RAID 1.

Basis des Servers ist UbuntuLTSP https://help.ubuntu.com/community/UbuntuLTSP

Das Projekt läuft seit ca 4 Wochen sehr stabil. Die Clients haben Firefox, Thunderbird, OpenOffice zur Verfügung.

Das Netz ist ein geswitchtes 100 Mbit LAN.

Von NoMaschineNx haben wir auch Tests gemacht, allerdings sind wir, dadurch das es sich erstmal nur um 25 User handelt, erstmal von Abgewichen, alleine von dem Anschaffungspreis her.

Hoffe das ich dir ein wenig helfen konnte.

Gruß

Alex
 
Danke für den Hinweis auf http://www.ltsp.org. Wenn ich die Infos aber richtig interpretiere setzt LTSP auf klassisches X11 - somit bei WAN Strecken mit 64k und hoher Latenz leider nicht einsetzbar?
 
Hallo gunnarh,

während meines Praktikums in Australien wurde eine ähnliche Aufgabenstellung bewerkstelligt. Dort wurde auf Citrix und Bladeserver gesetzt. Realisiert wurde das ganze Vorhaben für 200ca. 150 concurrent User in Australien auf Servern in Deutschland mit einer 2 mbit Standleitung.

Das hat (für mich) erstaunlicherweise flüssig und ohne Probleme funktioniert.

Gruß,
--marneus
 
Hallo marneus!

Danke für Deinen Erfahrungsbericht.
Hättest Du noch ein paar Details?

Ich nehme an Du meinst mit "Citrix" den Presentation Server?

Citrix ist ja für Windows-Server, HP-UX, Solaris und AIX verfübar. Eventuell kannst Du mir ja zumindest das Serverbetriebsystem sowie das/die Clientbetriebsystem(e) und wieviele User pro Blade betrieben wurden sagen?
 
Zuerst zu den Dingen, die ich noch mit Sicherheit weiß.

Ja, Citrix war der Präsentationsserver und der lief so bin ich der festen Überzeugung auf einem Windows-Server.

Die Clients waren alle Win XP. Als Browser wurde jedoch der IE verwendet.

Mehr weiß ich leider nicht (mehr).

Viele Grüße,
--marneus
 
@gunnarh

Das ist richtig. Habe leider über WAN Strecken mit 64K oder 128K keine Erfahrungen machen können mit LTSP. Daher konnte ich dir auch keine Infos dazu bieten. Sollte sich das Projekt weiterhin stabil Entwickeln wird es diese Erfahrungen haben noch geben müssen. Allerdings läuft die Eigentliche Verbindung per SSH ab. Welche auch Komprimiert werden kann.
 
Allerdings läuft die eigentliche Verbindung per SSH ab. Welche auch Komprimiert werden kann.

X11 über WAN funktioniert meiner Erfahrung nach aus zweierlei Gründen nicht:

1. die roundtriptimes sind zu lang. Betreibbar ist das sinnvoll nur im LAN mit sehr kurzen Pingzeiten. Bei Pingzeiten von 50ms und mehr ist aber kein sinnvolles Arbeiten mehr möglich

2. die Datenmenge: selbst komprimiertes SSH bedeutet, dass das Starten eines Webbrowsers gleich mal ca. 1MB über die Leitung befördert.

Details kann man sich z.b. bei den Machern von NoMachine NX nachlesen, welches eine Lösung für dieses Problem bietet.
 
Vielen Dank für den Tipp bei NoMachine. Werde mir das mal durchlesen. Aber im Moment ist noch nichteinmal die Testphase angefangen. Hatte mir halt nur schonmal Gedanken gemacht. Auch in der Richtung z.B. LTSP Server am jeweiligen Standort unterzubringen und beide LTSP Server dann zu synchonisieren.
 
Back
Top