Was ist die bessere Programmierunggebung? Thinclients + Server oder Einzelplatzworkstations?
-
volkard schrieb:
als programmierumgebung sind thin clients meiner erfahrung nach einfach nur müll.
das liegt daran, daß jeden tag einer der entwickler eine endlosschleife bastelt und den server totalauslastet. die anderen clients fangen an zu ruckeln und mit der zweiten endlosschleife bleibt das ganze system stehen.Dann gibt es auf diesem Server kein Quote zwischen Prozessen.
Das könnte man aber einrichten, so daß die Lastverteilung noch für jeden genug übrig läßt.
-
Thin Client schrieb:
Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.
Wenn dem so ist, dann ist der Server zu schwach ausgebaut.
Außerdem brauche ich als Entwickler die Freiheit, auch nachträglich noch Tools und Programme zu installieren, ohne erst Antrag 29392 auszufüllen, damit das irgendein Admin für mich irgendwann mal auf dem Server einrichtet.
Unter Linux kann man in der Regel seine eigenen Programme ins eigene Homeverzeichnis installieren, wenn es nicht vom Admin abgestellt ist.
Und was wenn Windows verwendet wird?
-
Naja da dieser Ansatz eher fremd für viele ist. ist hier das Feedback für ThinClients natürlich auch dementsprechend. Ich selbst hab damit auch noch nicht gearbeitet, habs aber mal von anderen gehört die das mal ne Zeitlang hatten.
In der Theorie hört sich das alle schon nicht so schlecht an, aber es kann eben doch immer mal wieder zu Ausfällen/Überlastungen des Servers kommen, wobei das tatsächlich eher die Ausnahme darstellen sollte. Ein anderes Problem ist hier ja dann auch noch das Netzwerk. Wenn das mal weg ist, dann geht halt echt gar nichts mehr wie schon jemand anmerkte. Sowas kommt defintiv vor und schlägt dann ziemlich drastisch zu Buche wenn du z.b. von 50 Entwicklern ausgehst.
Wieteres Problem ist tatsächlich die Performance der Clients. Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).
-
volkard schrieb:
als programmierumgebung sind thin clients meiner erfahrung nach einfach nur müll.
das liegt daran, daß jeden tag einer der entwickler eine endlosschleife bastelt und den server totalauslastet. die anderen clients fangen an zu ruckeln und mit der zweiten endlosschleife bleibt das ganze system stehen.also thinclients sind schonmal außerhalb jeder diskussion.
kann ich nur zustimmen. Grad heute hab ich mich mit 2 Jungs an die alten Zeiten im Uni-Pool (wo ich damals Studentadmin war) erinnert, wo wir um die 40 Sunrays an einem (schon damals 6 Jahren alten) Server hatten. Manchmap kamen 20 Leute gleichzeitg auf die Idee, Eclipse zu starten ... ich könnte nicht einmal per ssh 'kill' ausführen. Als Entwickler will ich meine eigene Maschine und noch dazu meine eigene Maschine selbst verwalten.
-
hustbaer schrieb:
Thin Client schrieb:
Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.
Wenn dem so ist, dann ist der Server zu schwach ausgebaut.
Unter Linux kann man in der Regel seine eigenen Programme ins eigene Homeverzeichnis installieren, wenn es nicht vom Admin abgestellt ist.
Und was wenn Windows verwendet wird?
Siehe Annahme im 1. Posting.
Windows wird nicht verwendet.
-
nep schrieb:
Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).
Nein ist es nicht, da der Client nur ein dummes Anzeigegerät ist.
-
Thin Client schrieb:
byto schrieb:
Ich kann mir beim besten Willen nicht vorstellen, produktiv über so einen Remote Desktop zu arbeiten.
Nun, Thin Clients sind in der Regel geräuschlos und der Server steht im Serverraum.
Ergonomischer kann man nicht arbeiten.Meine Workstation hier ist auch geräuschlos. Ergonomischer kann man nicht arbeiten.
Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.
Wenn dem so ist, dann ist der Server zu schwach ausgebaut.
Hat mit dem Server herzlich wenig zu tun, sondern viel mehr mit der Leitung. Aber vielleicht investiert besagter Autobauer auch einfach nur zu wenig Geld in die IT Infrastruktur.
Verrate doch mal, wie Du das realisieren willst. Sagen wir, es kommt eine IDE wie Eclipse zum Einsatz. Jeder Entwickler checkt den Quellcode aus dem Versionskontrollsystem aus.
Was und wie willst Du da nun gemeinsamen Speicher nutzen?Genau so wie du bei der Objektorientierten Programmierung Methoden für mehrere Objekte verwenden kannst, so kannst du das gleiche auch in einem Multiusersystem machen.
Wenn jeder Entwickler seinen eigenen Workspace auscheckt, dann kann man da auch nichts im Speicher sharen. Korrigiere mich, wenn ich mich irre.
-
nep schrieb:
Ein anderes Problem ist hier ja dann auch noch das Netzwerk. Wenn das mal weg ist, dann geht halt echt gar nichts mehr wie schon jemand anmerkte.
deshalb sollte man auch ein separates netz (z.b. mit eigenen leitungen) für das hausinterne thin-client system anlegen. und da sollte natürlich auch keiner seinen virenverseuchten wintel-pc anstöpseln, der permanent was ins netz senden will.
nep schrieb:
Wieteres Problem ist tatsächlich die Performance der Clients. Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).
warum? vielleicht wenn du von irgendwelchen basteleien wie 'windows terminal server' u.ä. remote-desktop 'lösungen' ausgehst, wobei auf den clients selbst oft schwergewichtige betriebssysteme laufen. bei den sun-rays ist es aber nicht so.
-
+fricky schrieb:
nep schrieb:
Ein anderes Problem ist hier ja dann auch noch das Netzwerk. Wenn das mal weg ist, dann geht halt echt gar nichts mehr wie schon jemand anmerkte.
deshalb sollte man auch ein separates netz (z.b. mit eigenen leitungen) für das hausinterne thin-client system anlegen. und da sollte natürlich auch keiner seinen virenverseuchten wintel-pc anstöpseln, der permanent was ins netz senden will.
Blabla, wie schon gesagt, man kann da echt viel machen, aber du wirst es definitiv nie vermeiden können, dass das Netz mal weg ist.
+fricky schrieb:
nep schrieb:
Wieteres Problem ist tatsächlich die Performance der Clients. Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).
warum? vielleicht wenn du von irgendwelchen basteleien wie 'windows terminal server' u.ä. remote-desktop 'lösungen' ausgehst, wobei auf den clients selbst oft schwergewichtige betriebssysteme laufen. bei den sun-rays ist es aber nicht so.
Mag schon sein, aber meistens kommst du eben um solche Dinge doch nicht wirklich rum. Gibt halt oft die verschiedensten Anforderungen die du nicht so einfach abdecken kannst, ohne dass der Client eine Rolle gibt. Für manche Fälle mag dies aber vielleicht anders sein.
-
nep schrieb:
Blabla, wie schon gesagt, man kann da echt viel machen, aber du wirst es definitiv nie vermeiden können, dass das Netz mal weg ist.
selber blah. das liegt leider in der natur der sache bei zentralisierten systemen: fällt was an der basis aus, dann ist alles tot. du kannst es dir aussuchen. übertriebene redundanz (= viele fette desktop-maschinen), dafür ausfallsicherheit (ok, nicht wirklich, wenn einer die hauptsicherung zieht), dafür hohe kosten, hoher energieverbrauch und hoher administrationsaufwand. oder stressfreiheit, geringe kosten, flexibilität (jeder kann sich einloggen wo er will und findet seinen desktop vor).
-
Ich sage: Workstations. Heutzuitage ist es ja kein Problem 50 Workstations auf einmal zu installieren.
Auch U2D zu halten nicht.
Auch wenn man 2 Server da hinstellt können die Ausfallen.
Siehe TMOBILE mit 3 Servern und 2 gehen nicht.
Kostenfrage kann es nicht sein da der Server unmengen kosten muss.
Ein ordentlicher Admin kommt mit 50 Workstations auch zurecht.
-
Ich habe zur Zeit das "Vergnügen" mit einer Sun Ray 1 zu arbeiten, wobei die Session selbst auf einem Solaris Server, Eclipse auf einem Linux Server läuft.
Ich weiß nicht, ob es am Netz oder dem alten Client liegt, aber es ist einfach nur zäh, obwohl die Server schon ziemlich dick und auf jedem vielleicht höchstens ein Dutzend Leute unterwegs sind.
-
+fricky schrieb:
nep schrieb:
Blabla, wie schon gesagt, man kann da echt viel machen, aber du wirst es definitiv nie vermeiden können, dass das Netz mal weg ist.
selber blah. das liegt leider in der natur der sache bei zentralisierten systemen: fällt was an der basis aus, dann ist alles tot. du kannst es dir aussuchen. übertriebene redundanz (= viele fette desktop-maschinen), dafür ausfallsicherheit (ok, nicht wirklich, wenn einer die hauptsicherung zieht), dafür hohe kosten, hoher energieverbrauch und hoher administrationsaufwand. oder stressfreiheit, geringe kosten, flexibilität (jeder kann sich einloggen wo er will und findet seinen desktop vor).
Desktop-Hardware ist mittlerweile eher billig und wenn man nicht gerade triple-sli Grafikkarten einsetzt ist der Stromverbrauch einer Workstation auch erträglich. Serverhardware dagegen ist nach wie vor teuer. Ich könnte mir shcon vorstellen das die Kosten von 50 Desktop-Systemen niedriger sind als die Kosten eines Server-Systems/Netzwerks das 50 Entwickler hosten soll.
Nebenbei. Die teuerste Einzelkomponente meines Arbeitsplatzes ist immer noch der Bildschirm...
+fricky schrieb:
(ok, nicht wirklich, wenn einer die hauptsicherung zieht)
Nicht wenn als Workstations Laptops eingesetzt werden. Da kann man zur Not auch mal einige Stunden ohne Strom arbeiten...
+fricky schrieb:
stressfreiheit
Ich bezweifele schwer das der Admin eines Servers auf dem 50 Entwickler arbeiten ein stressfreies Leben hat, ich denke eher das Gegenteil ist der Fall. Jeder noch so kleine Ausfall bedeutet gleich 50 Entwickler die nicht arbeiten können. Eine Stunde Ausfall entsprechen da 50 Mannstunden, sowas geht mächtig ins Geld.
-
loks schrieb:
+fricky schrieb:
(ok, nicht wirklich, wenn einer die hauptsicherung zieht)
Nicht wenn als Workstations Laptops eingesetzt werden. Da kann man zur Not auch mal einige Stunden ohne Strom arbeiten...
dann aber nur mit externer tastatur und extra mäuschen. ausserdem stell ich mir lieber 'nen flachbildschirm auf den tisch, als einen tief auslagerden schlepptop.
loks schrieb:
Ich bezweifele schwer das der Admin eines Servers auf dem 50 Entwickler arbeiten ein stressfreies Leben hat, ich denke eher das Gegenteil ist der Fall. Jeder noch so kleine Ausfall bedeutet gleich 50 Entwickler die nicht arbeiten können. Eine Stunde Ausfall entsprechen da 50 Mannstunden, sowas geht mächtig ins Geld.
der witz ist ja, dass solche serversysteme so gut wie nie ausfallen. die kannste nicht vergleichen mit irgendwelchen wackeligen windows-pcs, die wegen virenbefall, bugs und qualitativ minderwertiger hardware, öfter mal zuwendung brauchen.
-
+fricky schrieb:
der witz ist ja, dass solche serversysteme so gut wie nie ausfallen. die kannste nicht vergleichen mit irgendwelchen wackeligen windows-pcs, die wegen virenbefall, bugs und qualitativ minderwertiger hardware, öfter mal zuwendung brauchen.
Da kann ich nur zustimmen.
Wie wahrscheinlich ist ein Ausfall einer teuren Servermaschine und wie wahrscheinlich ist der Ausfall einer billigen Workstation? Die durchschnittliche Downtime eines Servers für 50 Personen ist sicher geringer, als die durchschnittliche Downtime einer Workstation.
Wenn ich auf das Jahr gerechnet eine Server mit sagen wir mal 5 Stunden Downtime habe, dann sind 50 Personen mal 5 Stunden ohne Rechner, macht 250 Stunden gesamte Ausfallzeit. Wenn ich einen einzelnen durchschnittlichen komplexen Clientrechner mit durchschnittlich sagen wir mal 10 Stunden Downtime im Jahr habe, habe ich bei 50 Rechnern eine gesamte Ausfallzeit von 500 Stunden. Der einzige Unterschied ist, dass der Server für alle zur gleichen Zeit ausfällt, aber die Workstations immer mal wieder einer. In der Summe ist der Server aber zuverlässiger.
Und wenn ich Administrator wäre, würde ich lieber ein mal im Jahr den Server streicheln, als 2 mal im Monat eine der 50 Workstations (und wenn ich der Chef wäre, würde ich auch lieber ersteren bezahlen
).Es hängt auch vom Projekt ab, welche Konfiguration sinnvoller ist. Wir entwickeln hier Serverprogramme unter Unix. Da ist das gar kein Problem, mit vielen Leuten auf einer grossen Kiste zu arbeiten. Andere entwickeln GUI-Lastige Programme. Da kommt man sich wahrscheinlich auf einer Maschine eher mal ins Gehege.
-
10h downtime im jahr pro client?
nie und nimmer.vorallem da du ersatzgeräte hast. also bei uns ist die downtime im schnitt pro client sicher unter 2h stunden und da sind downtime wegen updates dabei. und updates werden ja nicht eingespielt wenn die downtime weh tut.
insofern sehr fragwürdige rechnung...
-
Das Grundkonzept des INternet war es, anstelle eines zentralen Servers ein Netzwerk von vielen kleinen Rechnern zu haben. Warum? Weil in einem homogenen Netzwerk der Ausfall einzelner Komponenten nahezu keine Auswirkung auf das Gesamtsystem hat.
Und genau das ist der Punkt. Der Ausfall einer einzelnen Workstation hat auf den Arbeitsablauf einer Firma mit 50 entwicklern keine nennenswerte Auswirkung.
Dagegen ist der Ausfall eines Zentralrechners für den Gesamtbetrieb eine erhebliche Beeinträchtigung, weil der komplette Betrieb für die Dauer des Ausfalls lahmgelegt wird. Zugegeben, die Chance das der Server ausfällt ist gering, die Reparatur _wenn_ etwas kaputt geht kann aber umso aufwendiger werden.
Auch teure Hardware geht kaputt, auch Serverplatten fallen aus.
Lies mal die Geschichte: http://thedailywtf.com/Articles/Designed-For-Reliability.aspx
-
loks schrieb:
Auch teure Hardware geht kaputt, auch Serverplatten fallen aus.
Huuuiiii! Was passiert dann?
a) Die Serveradmins rennen wild zum Computerladen nebenan und warten darauf, dass die gewünschte Platte angeliefert wird und bauen sie dann ein während der Server die ganze Zeit steht.
b) Ein Admin sieht, dass eine Platte putt ist. Er holt sich einen Kaffee. Er holt sich noch einen Kaffe. Er geht zur Dönerbude nebenan und isst zu mittag. Irgendwann wird ihm heise.de doch zu blöd und er geht mit passender Ersatzplatte in den Serverraum und tauscht sie während der Server läuft.
-
@Tim:
Klar ist es billiger, einen dicken Server redundant und "ausfallssicher" auszulegen, als 50 redundante und "ausfallssichere" Workstations. Aber ist es billiger einen solchen Server hinzustellen, also 50 nicht-redundante "off the shelf" Workstations zu nehmen? Schliesslich ist es nicht so tragisch wenn man eine solche Workstation ausfällt.Mag sein ja, ich weiss es einfach nicht.
Wenn ich grob schätze und es im Kopf überschlage, würde ich meinen, dass zumindest die Anschaffungskosten von 50 Workstations geringer sind als die eines ausreichend dicken (redundanten) Servers. Bzw. eben min. 2 Server, denn einer alleine reicht IMO nicht, egal was man alles redundant macht (Netzteil, Controller, Disk-Stapel, Netzwerkkarten, Chip-Kill RAM etc.). Wenn z.B. das Board was hat is immer Schluss.
Sagen wir mal eine Workstation kostet ~500€, das sollte IMO hinkommen. Ein Thin-Client kostet ~200€ (zumindest kenne ich keine wesentlich billigeren). D.h. der Server dürfte die Differenz, also 300€*50 = 15000€ kosten. Bzw. die wenigstens 2 Server. Wie gesagt ich kenne die Preise von solcher Hardware nicht so gut, aber es würde mich wundern, wenn man um das Geld überhaupt redundante Plattenstapel bekommen würde (sagen wir mal 2 Stück RAID 5 oder RAID 6 Arrays, über Fiber/iSCSI gespiegelt).
Dass TCO != Anschaffungspreis ist mir auch klar. Bloss da hab ich dann überhaupt keine Ahnung mehr, was man bei den jeweiligen Optionen an Service-/Betriebs-Kosten veranschlagen müsste.
-
Ich habe schon zwei Terminalserverlösungen für je 30 und 45 Personen geplant und umgesetzt. Allerdings sind das Firmen welche wirklich nur Office und ihren ERP-Client auf den Terminalservern laufen lassen. Sonst habe sie keine Software.
In einem solchen Fall funktioniert das ganze hervorragend und mit extrem wenig administrativem Aufwand. In einer solchen Umgebung ist man sowieso vom DB-Server abhängig und mit dem TS führt man keinen vorher nichtvorhandenen Single-Point-of-Error ein.
Der Kunde mit der neueren Installation hat auch alle Daten und virtuellen Maschinen auf einem NAS welches vollständig redundant ist. Das heisst jede Festplatte hat zwei SAS-Anschlüsse welche an zwei unabhängige Systeme angebunden sind. Wenn jetzt ein Server ausfällt wird die VM einfach auf einem anderen Server wieder gestartet. Die Festplaten selbst sind natürlich per RAID redundant.
Ein Kunde hat eine relativ schlechte Stromversorgung. Nach einem Stromausfall können die Mitarbeiter sofort wieder genau dort weiterarbeiten wo sie aufgehört haben. Alle Clients mit USVs abzusichern wäre viel teurer.
Das ganze funktioniert aber nicht so gut wenn man Programmierer unter Windows beschäftigt. Einige Gründe wurden schon genannt. Zwei möchte ich noch hinzufügen:
-
Windows Terminalserver skalieren extrem schlecht mit der CPU Anzahl. Ich kann nicht einfach 8 CPUs einem Windows 2003 TS zuordnen. Das lagt wie die Sau. Vielleicht haben sie das unter Windows 2008 jetzt behoben. Wenn man also auf dem TS CPU intensive Aufgaben hat, braucht man mehr Instanzen also Loadbalancing, mehr Lizenzen und mehr RAM. Das alles Kostet und macht die Lösung unattraktiver.
-
Eine TS-Umgebung funktioniert nur dann wirklich gut, wenn alle Mitarbeiter dieselbe Umgebung haben. Bei Programmieren wird es wohl so sein, dass jeder viele eigene Tools und Programme hat die er gerne benutzt. Alle diese Tools dann auf dem TS zu installieren bekommt diesem unter Umständen nicht so gut.
Linux und UNIX habe wieder andere Vorzüge und Nachteile, aber dort habe ich keine praktische Erfahrung im TS-Einsatz.
Arbeiten die Programmierer hier eigentlich mit Admin-Rechten unter Windows?
-
