bei der frage nach der idealen struktur für so ein netz kommt es grundsätzlich immer darauf an, wie und wofür die kisten verwendet werden sollen...
zentraler server (und vermutlich auch eine domäne) ist schonmal besser als jede kiste einzeln zu administrieren, führt aber auch einen single point of failure in das konzept ein ... fällt der zentrale server aus, gibts probleme ... abhilfe schafft da nur redundanz für die entsprechenden systeme (z.b. ein 2. server der bei ausfall des ersten übernehmen kann)
allgemeinverständlich zusammengefasst:
pro:
aufwand für die administration sinkt
contra:
fällt ein zentraler teil aus, hat das auswirkungen auf das gesammte netz
thema "thin clients"/"zero-clients":
zum konzept:
das was da am arbeitsplatz steht, ist kein rechner im eigentlichen sinne ... das gerät stellt lediglich die schnittstelle für bildschirm, tastatur, maus und sonstige peripherie zur verfügung, und bindet dies an ein system an, das woanders steht ... typischer weise ein terminal server oder ein VM-Host/Pool (in diesem fall hat jeder benutzer eine virtuelle maschine, also sein eigenes windows, linux oder sonstiges OS ... diese virtuelle maschine läuft auf einem rechenstraken server, der bei größeren netzen meist teil eines server-pools ist ... bei VMWare ist es beispielsweise möglich im laufenden betrieb eine VM von einem server des pools auf einen anderen zu transferieren, ohne das der benutzer dies merken würde ... muss der physikalische server zu wartungsarbeiten abgeschaltet werden, stellt das im idealfall keine beeinträchtigung für den benutzer dar ... das kommt dem "as a service" ansatz recht nahe)
vorteile:
-die hardware am arbeitsplatz selbst ist sehr standardisiert ... geht was kaputt, kann in der regel selbst ein nicht fachkundiger benutzer das gerät mühelos austauschen
-die kosten für die arbeitsplatz geräte sind sehr überschaubar
-keine lokalen daten am arbeitsplatz -> das typische problem nach einem crash "nein, das haben wir immer auf C gespeichert" entfällt ...
-variable ressourcen: je nach einsatzzweck kann man dem benutzer problemlos mehr oder weniger ressourcen zuweisen (bei terminal servern in dem man rechenintensive arbeiten auf server mit weniger benutzern verteilt, bei VM lösungen, in dem man die ressourcen für die VM entsprechend einteilt oder die vm auf einen anderen physikalischen server verlegt) ... somit entfällt das problem "lahmer möhrchen" in einzelnen büros
-energie kosten sinken ... thin-clients brauchen nur den bruchteil der energie eines normalen desktop rechners
-zentrale administration: am arbeitsplatz steht in der regel nichts mehr, das gewartet werden müsste
-im falle von Virtuellen Maschinen: ein "vor die wand gefahrenes" windows ist keine wirkliche problematik mehr ... bei einigen setups kann der benutzer seine VM per klick auf einen restore point zurück setzen ... vom kaputten system zum arbeitsferigen zustand in sekunden. (ohne eingreifen eines admins)
nachteile:
-ohne den terminal-server, den VM host/pool, oder den zugangsweg zu diesen, geht bei solchen konzepten gar nix mehr ... es ist also wichtig entsprechende redundante reserve systeme zu haben, idealer weise jedes kritische system mindestens doppelt
-die umstellung bestehender konzepte auf diese konzepte ist nicht so einfach, auch wenn an dieser problematik zur zeit gearbeitet wird und diese hürde dank automatisierter migrations-tools immer kleiner wird
-lohnt sich erst ab einer gewissen zahl an arbeitsplätzen
-die server systeme müssen für solche konzepte relativ leistungsstark sein, was in der regel dafür sorgt, dass die anschaffungskosten höher sind als bei "regulären" konzepten ... amortisation erreicht man meist nach 3-5 jahren
ein system mit dem ich gute erfahrungen gemacht habe stammt aus dem hause BKS Service ...
www.pano-logic.de![[HaBo]](/styles/default/logoklein.png){kind=small}
