12
Terminalserver Cluster? Oder andere Vorschläge?
Brauche Vorschläge für eine hoch verfügbare Terminal Lösung
Hallo bin neu hier und habe gleich eine Frage ich steh irgendwie aufm Schlauch und komm nicht weiter und brauche daher einen kleinen Denkanstoß.
Ich brauch eine hoch verfügbare Terminal Lösung, gibt es da was in der Art Cluster? Das Problem ist das es zwei Server sein müssten um immer einen runterfahren und aktualisieren zu können, auch wenn User angemeldet sind.
Gibt es dazu eine Möglichkeit das zu realisieren?
Viel Dank schon mal im voraus
Hallo bin neu hier und habe gleich eine Frage ich steh irgendwie aufm Schlauch und komm nicht weiter und brauche daher einen kleinen Denkanstoß.
Ich brauch eine hoch verfügbare Terminal Lösung, gibt es da was in der Art Cluster? Das Problem ist das es zwei Server sein müssten um immer einen runterfahren und aktualisieren zu können, auch wenn User angemeldet sind.
Gibt es dazu eine Möglichkeit das zu realisieren?
Viel Dank schon mal im voraus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 162714
Url: https://administrator.de/contentid/162714
Ausgedruckt am: 22.11.2024 um 16:11 Uhr
12 Kommentare
Neuester Kommentar
Ja, dafür gibt es unter Windows entsprechende Clustering-Dienste.
Sauber konfiguriert, soll der Anwender davon nichts merken. Habe ich mir sagen lassen. (d.h. man soll Benutzersitzungen auf den anderen Server transferieren können, ohne dass der Anwender seine Daten verliert etc.)
Ich selber habe das aber noch nie live gesehen. Wir haben "nur" zwei separate TS im Einsatz. Servergespeicherte Benutzerprofile und identische Software-Installation sorgen dafür, dass es für den Benutzer grundsätzlich egal ist, auf welchem TS er arbeitet. Unsere Benutzer melden sich immer am Ende ihrer Arbeitszeit ab, so dass es also keine "Dauer-Sitzungen" gibt. Da ist es einfach, bei geplanten Wartungsarbeiten mal dafür zu sorgen, dass sich die Benutzer (beispielsweise) mittwochs nur auf TS1 und donnerstags nur auf TS2 anmelden sollen.
Dafür sind beide TS komplett autark, da eben kein Clustering-Dienst zum Einsatz kommt.
Howto's für die Einrichtung von TS mit Clustering Services findest du über Google ;)
Sauber konfiguriert, soll der Anwender davon nichts merken. Habe ich mir sagen lassen. (d.h. man soll Benutzersitzungen auf den anderen Server transferieren können, ohne dass der Anwender seine Daten verliert etc.)
Ich selber habe das aber noch nie live gesehen. Wir haben "nur" zwei separate TS im Einsatz. Servergespeicherte Benutzerprofile und identische Software-Installation sorgen dafür, dass es für den Benutzer grundsätzlich egal ist, auf welchem TS er arbeitet. Unsere Benutzer melden sich immer am Ende ihrer Arbeitszeit ab, so dass es also keine "Dauer-Sitzungen" gibt. Da ist es einfach, bei geplanten Wartungsarbeiten mal dafür zu sorgen, dass sich die Benutzer (beispielsweise) mittwochs nur auf TS1 und donnerstags nur auf TS2 anmelden sollen.
Dafür sind beide TS komplett autark, da eben kein Clustering-Dienst zum Einsatz kommt.
Howto's für die Einrichtung von TS mit Clustering Services findest du über Google ;)
Okay danke werde mich mal schlau machen ist ja schon mal ein Ansatz.
Das mit den 2 Servern geht leider nicht da immer User angemeldet sind.
Das mit den 2 Servern geht leider nicht da immer User angemeldet sind.
Habt ihr die beiden TS virtualisiert oder sind die beiden TS separat auf Blech?
Unsere sind virtualisiert und die können wir wärend des Betriebes via VMotion von einem Host zum anderen verschieben.
Wenn der Host leer ist können an diesem Wartungsarbeiten durchgeführt werden.
vg
Unsere sind virtualisiert und die können wir wärend des Betriebes via VMotion von einem Host zum anderen verschieben.
Wenn der Host leer ist können an diesem Wartungsarbeiten durchgeführt werden.
vg
Das klingt schon mal gut mit VMotion.
Denn momentan haben wir zwei Virtuelle mit Load Balancing. Wobei der eine einen Verweis auf den anderen hat also beide die selbe IP.
Denn momentan haben wir zwei Virtuelle mit Load Balancing. Wobei der eine einen Verweis auf den anderen hat also beide die selbe IP.
Bei uns laufen beide als VMs. Wurden von vornherein als VMs installiert.
Allerdings betrifft VMotion ja nur die Hardware, auf der die VMs laufen. Was damit eben nicht gelöst ist - und darum geht es meiner Meinung nach in der ursprünglichen Frage viel eher - sind die Downtimes aufgrund automatischer Updates und der damit verbundenen Reboots.
Selbst in internationalen Konzernen kommt es vor, dass ein frisch verfügbares ServicePack noch am gleichen Abend (von einem Admin) eingespielt wird und der TerminalServer deshalb dann 1-2x gebootet wird (zwangsweise). Ohne Vorankündigung und somit ohne Rücksicht auf angemeldete Benutzer und deren Sitzungen
Allerdings betrifft VMotion ja nur die Hardware, auf der die VMs laufen. Was damit eben nicht gelöst ist - und darum geht es meiner Meinung nach in der ursprünglichen Frage viel eher - sind die Downtimes aufgrund automatischer Updates und der damit verbundenen Reboots.
Selbst in internationalen Konzernen kommt es vor, dass ein frisch verfügbares ServicePack noch am gleichen Abend (von einem Admin) eingespielt wird und der TerminalServer deshalb dann 1-2x gebootet wird (zwangsweise). Ohne Vorankündigung und somit ohne Rücksicht auf angemeldete Benutzer und deren Sitzungen
Ja das ist ja unser Problem, die Sitzungen dürfen nicht beendet werden.
Ist das mit VMotion denn nicht möglich?
Was gibt es dann für Alternativen?
TS mit Clustering Service???
Ist das mit VMotion denn nicht möglich?
Was gibt es dann für Alternativen?
TS mit Clustering Service???
Zitat von @sebbo02:
Ja das ist ja unser Problem, die Sitzungen dürfen nicht beendet werden.
Ist das mit VMotion denn nicht möglich?
Ja das ist ja unser Problem, die Sitzungen dürfen nicht beendet werden.
Ist das mit VMotion denn nicht möglich?
Wie gesagt: VMotion ist dafür nicht *die* Lösung.
Mit VMotion kannst du bei VMware ESX(i) virtuelle Maschinen im laufenden Betrieb von einem Host auf einen anderen Host verlagern. Das "brauchst" du, wenn du Wartungsarbeiten am Host selber durchführen möchtest/musst und die VMs nicht herunterfahren möchtest.
Da dabei die virtuelle Maschine ja weiterhin läuft (halt nur woanders) hilft dir das überhaupt nicht im Bezug auf Software-Updates innerhalb der VM. Und natürlich auch nicht bei Rekonfigurationen der VM (zusätzliche CPUs, mehr RAM, zusätzliche Festplatten, eine zusätzliche Netzwerk-Karte, .....).
Wir hatten letztes Jahr uns mal ein Angebot eingeholt. Für einen hochverfügbaren TS Cluster. Da hat uns der "Ingenieur" (also der, der das nachher wirklich installiert hätte, nicht der Vertriebsmensch) versprochen, dass mit Clustering das alles gehen würde, was du möchtest.
Aber deren Angebot war uns nachher zu teuer und live gesehen habe ich es halt noch nie. Wir haben uns dann für die "Light"-Version zweier identischer TS mit servergespeicherten Profilen entschieden, weil es hinsichtlich Konfiguration und Administration überschaubarer ist und somit für uns Kosten (Zeit) bei der Installation gespart hat. In den letzten 3 Monaten habe ich die TS auch nicht neu booten müssen. Unter anderem natürlich deshalb, weil der ganze Auto-Update-Krams deaktiviert ist.
Wir haben die vorherigen TS jahrelang ohne automatische Updates betrieben. Und somit ohne lästige Reboots. Und wir leben noch
Google müsste jedenfalls bei der Suche nach howto's für die Clustering-Konfiguration behilflich sein.
Hmm da hab ich das wohl ausgangs falsch gelesen. Stimmt VMotion ist dazu da um den Host freizubekommen und diesen zu Warten.
Wir setzen einen virtuellen TS Cluster ein, haben unsere Wartungsintervalle aber immer ausserhalb des Produktivbetriebes und daher hatten wir den Fall noch nicht live Benutzersessions zu transferieren.
Die Updates werden automatisch gezogen, aber eingespielt werden diese erst wenn unser Test-TS sich nicht verschluckt =). Erst danach werden die Updates im Wartungsintervall eingespielt.
Wir setzen einen virtuellen TS Cluster ein, haben unsere Wartungsintervalle aber immer ausserhalb des Produktivbetriebes und daher hatten wir den Fall noch nicht live Benutzersessions zu transferieren.
Die Updates werden automatisch gezogen, aber eingespielt werden diese erst wenn unser Test-TS sich nicht verschluckt =). Erst danach werden die Updates im Wartungsintervall eingespielt.
Darf ich erfahren wie hoch die Kosten ungefähr gewesen wären?
Insgesamt wurden über 20k Euro (netto) veranschlagt. Inklusive neuer Hardware und den Lizenzen.
Darin enthalten waren zwei neue HP Server für je ~6k Euro [Dual Xeon, 48gb DDR3, 2x SAS-Platten...], Lizenzen für W2k8 R2 inkl. zusätzlicher CALs und in einer ersten groben Schätzung 6 Ingenieur-Tage je 750 Euro. Allerdings wäre es nicht bei den 6 Tagen geblieben, wie ich die Lage einschätze.
Die alten Windows 2000 TS hatten jeweils 1 CPU, 1gb RAM (hier war klar, dass das zu wenig ist, weil es damals schon zu wenig war). Die letztes Jahr dann "neu" installierten TS (W2k3, nicht W2k8 ^_^) begnügen sich mit 2 vCPUs und jeweils 3gb RAM. Die 3gb sind für 10 Benutzer ausgelegt: Pro Benutzer-Sitzung 250mb + Overhead für den Server selbst und 1-2 schlanke Admin-Sitzungen. (Diese Zahlen wurden dem Dienstleister auch im Termin offen gelegt, bevor er das Angebot ausarbeitete und darin 48gb RAM verbauen wollte). Aktuell arbeiten im Schnitt 2-3 Benutzer drauf und nicht mehr bis zu 6 gleichzeitig, weil in der Abteilung umsatzbedingt Personal abgebaut wurde.
H41 hat halt, genauso wie wir, den "Vorteil", den TS frei machen zu können. Bei uns wird zwar 24x7 darauf gearbeitet, aber eben nicht mit permanenten Sitzungen sondern mit sauberen An- und Abmeldungen. Deshalb haben wir beide halt nicht den Bedarf, Benutzersitzungen live zu transferieren.
Einen Test-TS haben wir auch. Also einen dritten TS zum herumspielen.
Gibt es auch eine Möglichkeit das mit dem RPD Connection Broker zu lösen? Hat das schon jemand versucht? Oder auch Terminal Services Session Broker
Hat keiner Erfahrungen damit?
