Virtualisierung des Arbeitsplatzes

Moin!

Bei uns in der Firma wird momentan überlegt, sämtliche PCs zu virtualisieren (vDesktop steht zur Debatte). Ich habe da so meine Bedenken was die Performance bei der täglichen Entwicklerarbeit betrifft (habe momentan einen 4Kerner und bin trotzdem am Nörgeln bzgl. der Performance) 😉

Wie sieht das bei Euch im beruflichen Umfeld so aus? Werden/Sind Eure PCs virtualisiert und wie sine da Eure Erfahrungen? Auch würde mich interessieren, welche Technik (vmWare, vDersktopm XenDesktop, Citrix, ...) verwendet wird und was für ein Blech als Server für wieviele Arbeitsplätze eingesetzt wird....

Vielen Dank!

Bye,
Michael

mein eigentlicher Rechner ist nicht virtualisiert, weil ich zusätzlich noch virtuelle Maschinen in VMWare Workstation-Umgebungen neben meiner eigentlichen Installation nutze. Rechenleistung ist gar nicht so das Problem bei Virtualisierung, ich finde eher die Bedienung etwas träge. Und ich weiss nicht, wie weit die Citrix-Technik mittlerweile ist, aber vor einigen Jahren konnte man Videos (z. B. Ausschnitte der Entwicklerkonferenzen von MS) noch nicht über RDP oder Citrix schauen, ohne dass das heftig geruckelt hat.

vDesktops haben natürlich nette Vorteile. Regelmäßige Backups in der Nacht, Nebenbei-Betrieb mehrerer Maschinen für verschiedene Zwecke usw.

Kam bei uns schon mehr als ein Mal als Idee auf; aber als produktiver Entwicklerarbeitsplatz alles andre als umsetzbar.

Genauso halte ich von mobilen Arbeitsplätzen nichts, die quasi einer Arbeitsplatzvirtualisierung sehr nahe stehen.
Solche Ideen sind schön und gut, aber nicht zu Ende gedacht. Die Produktivität wird - anders als irgendwelche BWL Berechnungen es sagen - niemals durch solch eine Umsetzung erreicht; im Gegenteil: sie wird sinken.

Wie in Arbeitet ihr mit/in virtuellen Maschinen? geschrieben, halte ich die Idee prinzipiell für gar nicht so schlecht, wenn es technisch gut umgesetzt ist (automatische Updates, stabile Netzwerkverbindung usw.)
Letztlich kann es sich ja sogar positiv auf die Performance auswirken, wenn der Hostrechner "üppig" mit Hardware ausgestattet ist (ich denke da an SSD-Raids usw.).

Vorteil sehe ich vor allem darin, dass man auch während eines Reboots weiterarbeiten (Mails, Chat, usw.) kann, wenn man mehrere VMs zur Verfügung hat bzw. der Clientrechner noch einigermaßen Resourcen zur Verfügung stellt.
Videos kann man dann zur Not ja auch auf dem Host anschauen; das schaffen ja inzwischen sogar Atom-CPUs.

Kam bei uns schon mehr als ein Mal als Idee auf; aber als produktiver Entwicklerarbeitsplatz alles andre als umsetzbar.

Warum? Belege?

Genauso halte ich von mobilen Arbeitsplätzen nichts, die quasi einer Arbeitsplatzvirtualisierung sehr nahe stehen.

Das ist einer der Gründe, warum unsere GF diese Virtualisierung umsetzen will. Hier gibt es diverse "3er Brüros", die u. U. eine ganze Woche leer stehen, weil die Consultants/Vertriebler/Sonstwas "on the road" sind...

Solche Ideen sind schön und gut, aber nicht zu Ende gedacht. Die Produktivität wird - anders als irgendwelche BWL Berechnungen es sagen - niemals durch solch eine Umsetzung erreicht; im Gegenteil: sie wird sinken.

Kannst Du das belegen? Einfach die Behauptung aufstellen ist ja einfach 😉

Ich sehe durchaus Vorteile, wenn ich mal eben für 1-2 Tage (oder meinetwegen auch Stunden) mein Büro wechseln kann (um mich bei "hirnintensiven" Anforderungen mal in ein leeres Büro zurückzuziehen) und dort meine gewohnte Umgebung vorfinde.... Oder man sich mit einem Kollegen zwecks (gesprächintensiven) Pair-Programming in ein anderes (leeres) Büro verdrücken kann um eben andere Kollegen nicht zu stören....

Bei uns geht es also auch darum, bei Bedarf die unkomplizierte Möglichkeit zu haben, mal das Büro auf Zeit zu wechseln (und nicht seinen festen Arbeitsplatz aufzugeben)...

Bye,
Michael

Belegen kann man sowas nicht anhand zahlen, sondern anhand logischen denkens.
Sowas kann man nicht "einfach so" messen.

Damit ein Entwickler wirklich produktiv ist, muss er sich wohl fühlen und ungestört sein (Allgemeine Aussage, manche können bestimmt auch prima neben ner Tunnelbohrmaschine arbeiten).
Wenn nen Entwickler jeden Tag an nem anderen Arbeitsplatz ist, dann muss er sich auch erst einleben. Das kann man nicht messen - das ist allein das Unterbewusstsein.

Mobile Arbeitsplätze sind bestimmt eine SUPER Idee in der BWL Welt; besonders bei der Projektplanung etc. Da macht das vielleicht auch ein wenig sinn.
Aber für Regelarbeitsplätze mit Tagesgeschäft sicherlich nicht: da muss man morgens erst mal nen Arbeitsplatz suchen, der frei ist. Man will kurz zu nem Kollegen, was besprechen oder fragen, weil man "sowieso" vorbei geht, und er sitzt natürlich nicht da wie gewohnt.

Der Mensch ist ein Gewohnheitstier; und jeden Tag ein "neues" Umfeld zu haben, ist sicherlich nicht förderlich.
"Mal" für 1-2 Tage wo anders zu sitzen, ist kein mobiler Arbeitsplatz.
Mobile Arbeitsplätze sind: du hast nen Rollcontainer (o.ä.) den Du Dir morgens schnappst und irgendeinen Platz im Unternehmen suchst. Da setzt Dich hin und arbeitest an Deinem Projekt.
Dafür sind Projekträume viel besser geeignet als mobile Arbeitsplätze. Google macht sowas mit ihren Kreativräumen.

Es wird aber immer Störfaktoren geben wie "ey, ich will ans Fenster, also komm ich früher" - was automatisch Gruppen zerreist.
Dann kommt nen Kollege und fragt "hey, ich muss heut mit Herbert arbeiten, könntest Du eventuell wo anders hin?" und zack biste ne viertel Stunde am Suchen nach nem neuen Arbeitsplatz. Der erste freie gefällt Dir nicht, der zweite wird besetzt für nen Kollegen etc etc....
Da gabs auch irgendein Faktor, damit das wirklich funktioniert, der besagt, dass es irgendwie 1,4 mal mehr Arbeitsplätze geben muss als Mitarbeiter, damit das annähernd klappen kann. Manche Faktoren lassen sich aber auch damit nicht beheben (Platz-Gier zum Beispiel).

Großraubüros sind bei manchen Unternehmen auch noch absolut im Trend, da sie ja die kommunikativen Wege kürzen sollen etc.
Studien belegen aber mittlerweile, dass Großraumbüros für die Produktivität und Effizienz kontraproduktiv sind. Des weiteren werden Mitarbeiter öfter krank und andere Dinge, die das ganze in ein ganz anderes Licht rücken, als die Theorie es sagt.

Der Standort, an dem ich arbeite, ist (fast) komplett mit Großraumbüros ausgestattet. Ich kenne fast niemnden, der damit zufrieden ist.
In der Hardware-Entwicklung sitzen sie teilweise mit Gehörschutz am Arbeitsplatz, weil der Support gegenüber den ganzen Tag telefoniert.
Ich persönlich sitz den ganzen Tag mit Musik auf dem Ohr, weil die Lautstärke einfach zu hoch ist, als dass man ohne in seinem eigenen Tunnel entwickeln könnte. Ständig lacht mal einer, telefoniert mal lauter, Tür zur Kammer knallt zu...
Das sind Dinge, die beachtest Du als BWLer einfach nicht. Der Alltag sieht leider ganz anders aus, als die Theorie es besagt.

Mobile Arbeitsplätze sind: du hast nen Rollcontainer (o.ä.) den Du Dir morgens schnappst und irgendeinen Platz im Unternehmen suchst. Da setzt Dich hin und arbeitest an Deinem Projekt.

Das ist die "klassische" Bezeichnung eines mobilen Arbeitsplatzes. Das sehe ich (oder allgemeiner "wir" hier in der Firma) etwas anders oder besser gesagt, nicht auf das Firmengebäude begrenzt:

• Home Office: Wir Entwickler arbeiten i. d. R. einmal die Woche von zu Hause.

• Abends im Hotel (für Vor- und Nachbereitungen des Tages). Ist doch chic, wenn man die gesamte Firmeninfrastruktur zur Verfügung hat und nicht nur den sehr begrenzten Subset auf dem Notebook. Gute Sache für die Vertriebler + Consultants.

• Produktvorführungen beim Kunden, die für die Präsentation eine umfangreiche Infrastruktur erfordern - eine zSeries mitzuschleppen ist immer etwas unhandlich 😉

• Urlaub: Ja, kommt auch vor, dass Spezial-Wissen nicht weit verbreitet und ein Kollege mal im Urlaub "ran" muss...

• Team-Entwicklung "auswärts"... Es ist in der Tat schon einmal vorgekommen, dass bei einem immens wichtigen Auftrag und engem Zeitpan ein Team komplett auswärts entwickelt hat um effektiv und ungestört zu entwickeln....

Bei uns steht der "klassische" mobile Arbeitsplatz nicht zur Debatte... ganz im Gegenteil (zumindest für die Mitarbeiter, die ständig im Büro sind: Sekretariat, Hotline, Entwickler, ...) .

Aber ich finde wir schweifen ab.... ich wollte/will ja nicht die Vor- und Nachteile diskutieren sondern hatte gehofft jemand hier kann Hinweise/Tips aus eigener Erfahrung geben....

Bye,
Michael

Also ich würde mich selbst als ziemlichen Virtualisierungs-Skeptiker bezeichnen. Das umfasst nicht nur Desktops sondern auch Server. Darauf will ich aber gar nicht hinaus. Das würde jetzt auch den Umfang sprengen.

Ich habe aber bisher einfach noch keine VM-Umgebung gesehen, die der nativen Umgebung das Wasser reichen kann. Dabei beziehe ich mich allerdings schon auf den Power-User-Bereich. Ich glaube gewöhnliche Office- und Standard-Anwendungen können gut virtualisiert werden. Aber wenn ich daran denke, dass meine gesamte Entwicklungsumgebing inkl. allem Anhang virtualisieren soll, gruselt es mich. VMs fühlen sich für mich immer etwas zäh in der Bedienung und schleppend in der Rückmeldung an. Im wesentlichen rede ich hier von VMWare und VirtualBox. Ich betreibe die Dinger auf nem 4-Kerner mit 8 GB RAM (keine Rumpelkiste würde ich sagen).

Natürlich gibt es eine ganze Reihe Vorteile, die da angeführt werden. Wenn man aber ehrlich ist, sind das die gleichen Thesen mit denen in den 70ern Maineframes, später Remotedesktop und jetzt "die Cloud" verkauft wird.

Home Office: Wir Entwickler arbeiten i. d. R. einmal die Woche von zu Hause.

Wenn du zu Hause arbeiten willst, dann müsste die VM doch auf deinem Heimrechner liegen. Dort müsste immer Synchron zur Firmenversion sein. Kann man das sicherstellen?

Wenn du die VM aus dem Firmenrechner starten willst brauchst du ne wirklich dicke DSL-Leitung. Wenn das eine Hand voll Entwickler hast, die das machen wollen, brauchst du nen mächtigen Upstream.

Abends im Hotel (für Vor- und Nachbereitungen des Tages). Ist doch chic, wenn man die gesamte Firmeninfrastruktur zur Verfügung hat und nicht nur den sehr begrenzten Subset auf dem Notebook. Gute Sache für die Vertriebler + Consultants.

Kann man doch auch per VPN verfügbar machen oder RDP. Wenn du die VM auf dem NB haben willst, dann stellt sich die Frage der Konsistenz wieder.

Produktvorführungen beim Kunden, die für die Präsentation eine umfangreiche Infrastruktur erfordern - eine zSeries mitzuschleppen ist immer etwas unhandlich 😉

Ich versuche es möglichst zu vermeiden in Präsentationen externe Resourcen zu verwenden. Die Admins beim Kunden sind paranoid 😃

Urlaub: Ja, kommt auch vor, dass Spezial-Wissen nicht weit verbreitet und ein Kollege mal im Urlaub "ran" muss... Man sollten den Kollegen klar machen, was ein Fileserver ist. Das horten lokalen Wissens ist weder mit noch ohne VM eine gute Idee. Das Ergebnis wird sonst sein, dass du erstmal 7 VMs abgrasen kannst um ein wichtiges Besprechhungsprotokoll zu finden.

Team-Entwicklung "auswärts"... Es ist in der Tat schon einmal vorgekommen, dass bei einem immens wichtigen Auftrag und engem Zeitpan ein Team komplett auswärts entwickelt hat um effektiv und ungestört zu entwickeln.... Wenn die VM in einem VM-Server hängt, hätte ich keine Lust nur mit stabiler Internetverbindung zu arbeiten. Wenn die VM lokal ist, dann stellt sich das Problem der Konsistenz. Ich würde hier lieber auf ein gutes Source-Control-System setzen.

Wie gesagt: Ich bin da eher skeptisch 😃 No hard feelings.

Gruß

Levi

Hallo zusammen,

seid ihr euch sicher, dass ihr alle über das gleiche redet? So wie ich m.knigge verstanden habe, geht es darum, die Ausführung weg von den Clients hinzu einem (großen/leistungsfähigen) Server zu verschieben. Die Clients könnten dann schwachbrüstig sein. Andere scheinen eher darüber zu sprechen, dass auf einem leistungsfähigen Client eine oder mehrere VMs ausgeführt werden. Das finde ich einen großen Unterschied.

Vielleicht solltest du, m.knigge, noch mal genauer schreiben, was für eine Art von Virtualisierung bei euch geplant ist.

herbivore

Vielleicht solltest du, m.knigge, noch mal genauer schreiben, was für eine Art von Virtualisierung bei euch geplant ist.

Gerne!

Es geht wie gesagt um die Virtualisierung des Arbeitsplatzes - womit daber mehr oder weniger die Virtualisierung des PCs gemeint ist. Der "Client" (das Ding vor dem ich im Büro sitze) kann dann - wie Du schon angemerkt hast - durchaus etwas schwachbürstig sein (oder gar ein echter Thin Client). Da er "nur" ein Bild anzeigt, die die CPU-Power dann erst einmal schiet egal....

Der Server virtualisiert dann den gesamten PC samt Betriebssystem, Anwendungen und Hardware. Im Gespräch ist dabei zur Zeit (meines Wissens) "vmWare View", das den PC über ein hochoptimiertes "PCoIP" (PC over IP) Protokoll anspricht. Dabei ist selbst die Wiedergabe von Videos (in flüssig!) möglich.

Weiterhin kann dabei lokale Hardware im gewissen Rahmen benutzt werden - beispielsweise werden USB-Geräte (Speichersticks, Kamera, Drucker, ...) von meinem Arbeitsplatz PC an den virtuellen Arbeitsplatz im Server durchgereicht. Auch ein Dual-Monitor-Betrieb ist möglich....

Ansprechen kann (oder sollen wir später) den Server natürlich lokal im Büro als auch über eine VPN-Verbindung (auch mobil vom Notebook).

Das Ganze ist dann also im Grunde aus Benutzersicht wie eine RDP-Session zum eigenen Rechner im Büro - nur halt (angeblich!) in schnell und chic ;-> Egal von wo (im Büro, Hotel, Road...) - man verbindet sich mit einem Client zum Server und hat schwupps seinen "eigenen PC" auf dem Schirm (im LAN der Firma und damit mit der gesamten Infrastruktor der Firma).

Der Administrator hat bei "vmWare View" dahigegen eine Mischung aus Terminal Server und einzelnen Maschinen - N gleichartige Maschinen (gleiches Windows, gleiche Softwareausstattung) sind auf dem Server in der Tat nur 1x vorhanden. Nur aus Benutzersicht eben mehrmals, da jeder Benutzer einen "eigenen PC" sieht... Updates muss der Admin dann beispielsweise nur 1x einspielen - aber sie finden sich dann automatisch auf den N "Benutzer PCs".....

Soweit also mein Wissensstand zu dem Thema - ich bin da momentan nur nebenbei involviert.... Ob das alles so toll ist wie es klingt werden wir in wenigen Monaten wissen, wenn wir von unserem Lieferanten ein Testsystem (Server, SAN, ...) gestellt bekommen...

Ich selber bin auch skeptisch (wie man vielleicht in vorherigen Posts rausgelesen hat), bin mir aber der Vorteile durchaus bewusst (und könnte diese auch durchaus schätzen lernen).

Insbesondere bin ich halt skeptisch was die Performance betrifft. Nichts nervt einen Entwickler mehr als zu warten 😉 Zumindest ist das bei uns im Büro so 😉

Bye,
Michael

Da hat der HP Vertreter bei euch ganze Arbeit geleistet ( kenne ich von uns).

Das was dann "im Keller" pro Arbeitsplatz aufgestellt werden muss ist um ein vielfaches Teurer als was man i.a. für einen PC ausgibt.

Allerdings ist aus Sicht der IT Abteilung die Wartung einfacher ( wenn die nicht wissen wie man Windows per Richtlinien wartet ).

Hatte doch schon einen Grund warum man schon einmal von dieser Zentralen Idee weg gekommen ist.

Aber ihr müsst eure eigenen Erfahrungen sammeln.

Da hat der HP Vertreter bei euch ganze Arbeit geleistet ( kenne ich von uns).

Bei uns isses zur Zeit Dell 😉

Das was dann "im Keller" pro Arbeitsplatz aufgestellt werden muss ist um ein vielfaches Teurer als was man i.a. für einen PC ausgibt.

Was aber nicht zwingend bedeutet, dass die zentralisierte Lösung damit teurer ist... Alleine die Kosten für einen PC zu rechnen reicht ja nicht... Und ohne es gemessen probiert zu haben: ich denke, so 7-10 "Daddeluser" mit Word, Excel und Outlook (bei denen die CPU fast den ganzen Tag kurz vor dem Tod vor Langeweilse steht) steckt so ein kleiner 12Kerner ja wohl locker in die Tasche. Und ein 12Kerner ist heutzutage ja wirklich finanzierbar....

Ich befürchte ja eher, dass wir Entwickler die Anforderungen für den Server in die Höhe schnellen lassen.... Wir haben da an die Performance schon ziemlich spezielle Anforderungen 😉

Hatte doch schon einen Grund warum man schon einmal von dieser Zentralen Idee weg gekommen ist.

Ja ja, und der Host ist tot.... 😉

Spass beiseite... Ich denke, man ist JETZT erst technisch dort angelangt, wo dieser zentralisierte Ansatz in der Praxis auch ansatzweise für den Benutzer akzeptabel ist. Ich habe beispielsweise vor etwa 7 Jahren mal zu Hause mit einem RDP Thin Client experimentiert (von Igel). Mann war das sch##### 😉 Sowas von lahm....

Bye,
MK

Hallo,

was meinst du genau mit

dass wir Entwickler die Anforderungen für den Server in die Höhe schnellen lassen.... Wir haben da an die Performance schon ziemlich spezielle Anforderungen ?

Abgesehen von SSD ist doch nichts wirklich Performance relevant. Zumindest für 99% der Entwickler

Abgesehen von SSD ist doch nichts wirklich Performance relevant. Zumindest für 99% der Entwickler

Nunja, eine SSD ist ja ganz chic, aber trotzdem dauert ein Build so seine Zeit. Das Projekt an dem ich gerade arbeite dauert so ca. 15 Minuten komplett neu zu bauen (was ich leider öfters am Tag machen muss)....

Klar läuft der Compile durch 'ne SSD eine ganze Ecke schneller, aber wenn der Rechner (aufgrund einer schwachen CPU - vielleicht nur zwei Kerne) beim Build so lahm wird dass man nebenbei nix mehr machen kann, dann ist das nicht akzeptabel. Oder mal ein Beispiel aus der Praxis: Als unsere Infrastruktur letztes Jahr Kaspersky als Anti-Virus Lösung eingeführt hat haben sich die Build-Zeiten um ca. 40% verlängert... (will damit sagen: eine SSD ist halt nicht die Lösung für jedes Problem)

Und seien wir mal ehrlich.... kann ein Rechner bzgl. der Build-Zeiten jemals "zu schnell" sein? 😉

Bye,
Knick

Hallo m.knigge,

es gibt ja zwei Gründe für schlechte Performance. Die Verzögerung über die Leitung und die (mangelnde) Rechenpower des Servers.

Ich habe mal vor einiger Zeit von Zuhause über DSL1000 per VPN/Remote Desktop auf einen entfernten Rechner zugegriffen, um darauf zu entwickeln. Ich fand es extrem cool, dass das überhaupt praktisch möglich war.

Ich denke, die Produktivität war nicht schlechter als direkt am Zielrechner. Möglicherweise sogar besser, weil man sich auf das Arbeiten konzentrieren konnte und nicht absichtlich oder unabsichtlich von den durchaus netten Kollegen abgelenkt wurde, bzw. man diese nicht abgelenkt hat.

Auf der anderen Seite waren in der beschriebenen Konfiguration bei der Darstellung schon leichte Verzögerungen - so gering diese auch waren - spürbar. So ist es mir z.B. regelmäßig passiert, dass wenn ich ein paar Zeichen per Backspace gelöscht habe, ich ein Zeichen zu spät aufgehört habe, was mir lokal nicht passiert. Außerdem habe ich in solchen und ähnlichen Situationen dann immer eine extra Sekunde gewartet, ob nun wirklich schon alle Tastendrücke verarbeitet wurden. Das hat zwar genervt, aber es war auch keine unüberwindliche Hürde. Allerdings habe ich nur in Ausnahmefällen so gearbeitet. Mag sein, dass wenn man das jeden Tag hat, man irgendwann völlig entnervt in die Tischkante beißt.

Im lokalen Netz oder bei sonstiger schneller(er) Verbindung und vermutlich mittlerweile auch verbesserter Übertragungstechnologie sind die Delays aber vielleicht auch gering genug, dass die nicht mehr auffallen. Immerhin soll es heute ja auch schon möglich sein, Action-Spiele über die Leitung zu spielen, auch wenn das natürlich nochmal ein anderes Thema ist.

Was die Rechnenpower des Servers im Verhältnis zu den im übertragenen Aufgaben ansieht, kommt es natürlich sehr auf das Szenario an. Ich hatte mich damals auf meinen Client im Büro verbunden. Daher war die Rechenleistung nicht besser oder schlechter als bei direkter Benutzung.

Bei dem was du schilderst, würde ich mir aber auch Sorgen machen. Zumindest wenn diesen Läufe öfter mal gleichzeitig durchgeführt werden. Ein, zwei auch lange Build sollte - nach meinem Gefühl - so ein 12Kerner noch locker wegstecken, zumindest solange VS pro Build nur einen oder wenige Kerne nutzt. Aber irgendwann ist natürlich Schluss mit lustig und im schlimmsten Fall sind dann alle, die an dem Server hängen, von unakzeptablen Verzögerungen betroffen auch wenn sie gerade nur editieren. Man darf auch nicht vergessen, dass nicht nur die CPU-Leistung begrenzt ist, sondern auch der Hauptspeicher, die I/O-Kapazität, die Grafik-Leistung usw. Jedes erreichen einer dieser Grenzen kann Auswirkungen auf alle Benutzer haben.

Trotzdem kann so ein Szenario natürlich auch funktionieren, wenn alles ausreichend dimensioniert ist. Und da sollte man den Berater in die Pflicht nehmen zu garantieren, dass die von ihm empfohlene Hardware auch für den geplanten Einsatzzweck ausreichend ist. Wie der dann berechnet, was für eine Hardware man für z.B. maximal sechs gleichzeitige Builds braucht, ist dessen Sache. Ich wüsste nicht, wie man das berechnet.

herbivore

Wie der dann berechnet, was für eine Hardware man für z.B. maximal sechs gleichzeitige Builds braucht, ist dessen Sache. Ich wüsste nicht, wie man das berechnet.

Yepp... DAS frage ich mich auch. Klar... es gibt da so Analyse-Tools - das von Dell beispielsweise nennt sich DPACK. Aber diese Tools sind halt auch kein allwissendes Orakel...

Deine Erfahrungen bzgl. remote Desktop.... Ja, ich war auch seinerzeit extrem entzückt wie "gut" das inzwischen funktioniert. Wobei es da natürlich auch auf die Anbindung und die Technologie ankommt. Zur Zeit arbeiten wir hier mit dem stinknormalen Remote Desktop. VNC hatten wir auch mal im Einsatz - aber das ist im Vergleich zu RDP (was die Performance betrifft) echt nix 😦

Wenn wir Entwickler unseren Kollegen mal etwas vorführen müssen, dann machen wir das für gewöhnlich in einem Besprechnungsraum und loggen uns via RDP auf dem entspr. Entwickler-PC ein. Das Arbeiten ist mit dem Arbeiten direkt am PC nahezu identisch. Da merkt man eigentlich keine Verzögerungen.

Von zu Hause erbeite ich ebenfalls per RDP über eine 16.000 DSL - das ist auch akzeptabel. Nur mein Router ist blöd - ab und zu hab ich Verzögerungen beim Tippen von teilweise ca. 2 Sekunden. Ein Reboot des Routers und schwupps ist es wieder performant...

Also alles in allem bin ich skeptisch, aber dennoch auch optimistisch und vor allem wahnsinnig gespannt, was aus diesem Projekt hier wird....

Bye,
MK

Servus zusammen,

ich würde meinen lokalen Rechner im Büro ja sofort gegen einen virtualisierte Desktop eintauschen wenn die Infrastruktur dahinter Leistungsfähig genug ist.

Die Plattenzugriffe sind mit einem anständigen SAN dahinter deutlich schneller als das mit einer lokalen Platte der Fall ist (nun gut, habe noch keine SSD in meiner Mühle) und selbst mit Laptop und einer UMTS-Verbindung bin ich immer wieder überrascht was das RDP-Protokoll seit Version 7 so alles leisten kann.

Größter Knackpunkt war für mich beim remote arbeiten immer der fehlende Multi-Monitor support aber auch das ist Geschichte.

Ich muss immer öfter mal auf dem Testsystem eines Kunden ein paar SQL Skripte schreiben und mache das eigentlich richtig gerne da dort eine dicke Kiste dahinter steht und die Leitungen auch ordentlich dimensioniert sind sowie die Latenz top ist.

Ansonsten arbeite ich zum testen sowie zum entwickeln unter Linux (z.B. eclipse auf debian für php) auch oft mit lokal installierten VMs (VMWare Workstation) und bin mit der Reaktionszeit mehr als zufrieden (sogar das OpenGL-Eyecandy läuft flüssig). Das ganze auf einem nun doch schon etwas in die Jahre gekommen Dell Precision M2400 mit Core2Duo 2.8Ghz und 8GB Ram.

Unseren Kunden haben wir nun auch schon öfter Terminal Server für ihre Anwendungen mit IGEL Thin Clients verkauft und bislang gab es noch keine Beschwerden (gut dort laufen i.d.R. nur ERP-Anwendungen mit, sagen wir mal genügsamer GUI).

Mit VmWare View habe ich jetzt selber leider noch keine Erfahrungen sammeln können. Ich könnte mir allerdings gut vorstellen das die Kosten-Nutzen Rechnung durchaus aufgeht wenn man alle Rechner in der Firma virtualisiert da die Rechner von Einkauf, Buchhaltung, Vertrieb etc. ja doch nur die meiste Zeit idlen und eine aktuelle Dual- oder gar Quadcore CPU dort oft hoffnungslos unterfordert ist. Diese Rechenleistung kann man ja dynamisch der Entwicklung und dem Test zur Verfügung stellen wenn sie nicht genutzt wird und ansonsten werden minimalanforderungen definiert für die man zugesicherte Resourcen bekommt.

So weit ich weiss hatte Sun dieses Konzept damals in weiten Teilen des Unternehmens obligatorisch gemacht (Sun Ray Thin Clients) eventuell findet man Erfahrungsberichte darüber im Netz.