Hallo,
Hm, stellt sich dann die Frage, ob und wie man dann aus den
zwei physischen Rechnern einen virtuellen macht, inklusive
Plattenspiegelung usw.
Und da stellt sich die Frage, ob man das überhaupt will.
Die Redundanz vergrößert sich ja, wenn man File und
Druckdienste ausgliedert.
Naja, wie sonst bekommt man eine tatsächliche und vollständige
Hardware-Redundanz für den Terminalserver hin?
Was du mit der „Frage“ meinst, verstehe ich nicht.
Ich verstehe
das doch so, dass der Thin-Client sich mit einem Server
verbindet…
joa
… und eben nicht automatisch auf einen anderen
ausweichen kann.
Nach Möglichkeit sollte das Netz so gestaltet werden, dass
Server A und B gemeinsam arbeiten
wenn Server A ausfällt, Server B alleine weiterarbeitet
wenn Server B ausfällt, Server A alleine weiterarbeitet
Die Thin Clients sind in dem Sinne gar keine Rechner die sich verbinden, oder von sich aus irgendwas „intelligentes“ tun. Sie sind eher die Schnittstelle zwischen dem Anwender (in den allermeisten Fällen Menschen. 
) und dem Betriebssystem auf dem Server. Die Thin Clients selbst haben meist gar kein richtiges Betriebssystem. Sie verfügen über eine -sehr- schnelle Verbindung zu den Servern (Plural).
Über den Terminalserver, den sie ausgeben, greift man von den Clients aus (über die Terminalserver/deren Betriebssystem mit deren Standartanwendungen) auf die Daten (auf den Fileservern) zu, gibt Druckbefehle (Printserver (meist eine Einheit mit dem/den Fileservern)) und bearbeitt Datenbanken (auf den Datenbankservern)
=> Mein sehr knapper Überblick auf das „Thin Client - Terminalserver“ Funktionsprinzip.
Genauer wird es in der Wikipedia erklärt
http://de.wikipedia.org/wiki/Thin_client
http://de.wikipedia.org/wiki/Terminalserver
Also sollte das am besten so laufen, dass
zwei Server nebeneinander laufen und sich deren Kapazitäten
addieren. Fällt einer aus, bleiben zwar weniger
Systemressource übrig, aber man kann unterbrechungsfrei
weiterarbeiten.
Ganz genau so sollte es für die Terminalserver gemacht werden.
Alles Andere widerspricht doch deinem Ursprungsposting, dass
es besser wäre, zwei redundante Rechner mit Dual-Cores
auszustatten, als einen mit nem Quad-Core.
Genau, zwei Rechner als Terminalserver, aber ZUSÄTZLICH einen File/Druckserver. (in meinen Beispielen „C“ genannt)
Bei den Datenbanken muss man überlegen, ob man die in die Terminalserver reinkriegt (evtl. als Anwendung, oder auch in einer Virtual Maschine) oder ob sie gar einen extra Server brauchen. Letzteres hängt von der Datenbank an sich ab, und wie schnell sie Arbeiten muss (unter Anderem auch, wie viele Clients darauf zugreifen)
In meinem Beispiel hätte man jetzt 2 vollständige Terminalserver (A und B arbeiten normalerweise mit addierten Kapazitäten) und einem seperaten File/Druckserver C.
Die Datenbanken (damit kenne ich mich mal gar nicht aus) können manchmal als „Anwendung“ laufen (Beispiel: MySQL unter Windows), oder in einer Virtual Maschine (die hardwaremäßig auf den beiden Terminalservern liegt), oder die einen eigenen (richtigen) Server bekommen, der dann NUR für diese eine Datenbank arbeitet.
Je mehr Server man hat (Annähernd nach dem Motto „für jede Aufgabe ein Gerät“), desto weniger kann passieren, wenn ein Bauteil im großen Puzzle ausfällt, oder gar kaputt geht.
Immer noch Unklarheiten?
LG Yorick
