Clusterumgebung mit Problemen

J

Joe Smitz

New Member
Hallo liebe Community,

ich habe ein kleines Problem:

Ich benutze ein Clustersystem mit 4 verschiedenen Terminalservern. Je nachdem, welcher Server wie ausgelastet ist, verbindet mich die Farm auf den Terminalserver mit der niedrigsten Auslastung. Nun habe ich das Problem, dass die Daten, die ich speicher, immer nur auf dem jeweiligen Server abgelegt werden, und nicht von jedem Server erreichbar sind.

Solltet ihr mehr Infos brauchen, fragt einfach mal nach.

Danke für eure Hilfe

Joe
 
Wie wäre es mit einem gemeinsamen Storage für alle Clusternodes? Je nach Umgebung gibt es da diverse Möglichkeiten, z.B. SMB, iSCSI, NFS, etc.
 
Wäre eine Alternative. Meine Idee war es, unser Eternus SAN zu nutzen. Aber wenn es bessere Alternativen gibt, wäre ich auch dafür sicherlich offen.
 
Da wir logischerweise nicht wissen, was im Umfeld des Clusters ggfalls schon verfügbar ist, kannst Du das wohl nur selbst entscheiden. Z.B. hören wir hier zum ersten Mal von dem SAN. Wenn vorhanden würde das natürlich schon Sinn machen.
 
Ich bin mir eurer "Unwissenheit" meiner Serverumgebung schon bewusst. Allerdings würde es eure objektive Meinung beeinträchtigen, wenn schon bekannt ist, was entweder vorhanden bzw. schon verwendet wird. Würde hier SAN fallen, wäre ich mir selbst 100%ig sicher, dass dies eine ordentliche Lösung wäre. Aber bekanntlich ist nicht immer der ersichtliche Weg auch der richtige ;) Trotzdem danke, für das erste Feedback, über weiteres würde ich mich sehr freuen!

Joe
 
Joe Smitz said:
Allerdings würde es eure objektive Meinung beeinträchtigen,
Click to expand...
Das ist doch Schwachsinn. Entweder willst du einen Vorschlag für deine vorliegende Situation. Dann kannst du hier gerne fragen unter Schilderung deiner Situation. Oder du fragst nach generellen Meinungen, dann schreib das aber auch bitte dazu.

Aber bekanntlich ist nicht immer der ersichtliche Weg auch der richtige
Click to expand...
Die Leute, die Ahnung haben, sind sehr wohl in der Lage eine offensichtliche Lösung von einer besseren, nicht offensichtlichen zu unterscheiden.
Die Intelligenz der Forenteilnehmer zu beledigen nicht nicht gerade der beste Weg um Hilfe zu bekommen, wenn auch für manche vielleicht ein naheliegender...

über weiteres würde ich mich sehr freuen!
Click to expand...
Bitte.

Back to Topic: Wenn NAS vorhanden => NAS.
 
Joe Smitz said:
Ich bin mir eurer "Unwissenheit" meiner Serverumgebung schon bewusst. Allerdings würde es eure objektive Meinung beeinträchtigen, wenn schon bekannt ist, was entweder vorhanden bzw. schon verwendet wird.
Click to expand...

Quatsch mit Sauce! Ein "vernünftiger" Vorschlag bezieht ggfalls vorhandene Strukturen zur Kostenersparnis natürlich mit ein. Daher gibt es hier keine "objektive Meinung", sondern höchstens an das System angepasste Lösungen.

Würde hier SAN fallen, wäre ich mir selbst 100%ig sicher, dass dies eine ordentliche Lösung wäre.
Click to expand...

Neben einem SAN, das meist nicht gerade zu den günstigsten Lösungen zählt, gibt es noch mehrere andere Möglichkeiten. Wenn aber schon ein SAN vorhanden ist, dann verwendet man das natürlich, ist doch aus Gründen der einfacheren Verwaltbarkeit schon logisch. Du hättest jetzt aber auch einfach nur vier Server haben können und sonst nichts.
 
Da du was objektives hören möchtest:

je nach Firmengröße
SAN - NAS - Google Drive(ja das gibts als Firmenprodukt)
 
Öhm. Terminalserver Farm habe ich jetzt richtig herausgelesen. Wie wärs genau das zu machen was Microsoft empfiehlt und was in jedem Terminalserver Handbuch steht?

Servergespeicherte Profile. Leg die einfach auf einem Fileserver ab. 2 Einfache GPO Settings versorgen die RDP Server mit den nötigen Settings. Der Fileserver selber muss absolut nix dickes sein. Ein SAN wäre da absolut overdressed. Sowas setze ich nicht mal bei ~150 Leuten ein die auf einer 4er Farm arbeiten.

Wichtig ist: Profilgrößen beschränken. Es ist natürlich "blöd" in einer RDP Farm zuzulassen das die Leute 50GB Daten in ihren Ordnern wie Dokumente/Bilder/Downloads haben. Sowas regelt man über entsprechende Netzlaufwerke und leitet die Ordner per GPO um. Das Profil selber auf einem RDP Server sollte nicht größer als 200MB sein da bei servergespeicherten Profilen die Daten jedesmal beim Erstellen einer Session geholt und beim Beenden wieder zurückgeschaufelt werden.

Google Drive wollen wir im Unternehmensbereich mal bitte ganz weglassen. Wer dort ernsthaft die Daten eines Unternehmens speichert das bereits auf eine 4er Farm angewiesen ist, gehört links und rechts gewatscht bis ihm die Datenschutzbestimmungen zu den Ohren raus quillen.

Wenn ein SAN da ist das ausreichend Kapazität und Bandbreite hat, nimm es. Ein "Tisch NAS" würde ich für eine Farm jetzt nicht gerade einsetzen, dann doch eher sowas wie die RS2414+.

Wenn da iwo ein Hypervisor rennt würde es allerdings auch nen vServer vollkommen tun. Hauptsache du berechnest anhand der Anzahl der gleichzeitig möglichen Sessions auf der Farm +30% Puffer die nötige Bandbreite. Kapazität nicht vergessen (Anzahl Profile * Limit der Profilgröße + 25%) und fertig ;)
 
Wenn man von SAN spricht, ist üblicherweise Blockstorage gemeint, also meistens iSCSI oder FC Anbindung. Welches Produkt vorhanden ist, wurde ebenfalls schon genannt: Eternus. Das sind Blockstorages von Fujitsu.

Da würde es mich bei den SAN-Vertretern hier nun mal ernsthaft interessieren, wie sie sich die Verwendung des SANs für Profile auf mehreren Windows-Terminalservern vorstellen. :confused:
Cluster-Filesysteme für Windows sind Mangelware, also was bleibt da noch? Für jeden User eine iSCSI LUN und dynamische Einbindung wenn sich der User anmeldet? Also sorry, aber umständlicher geht es wirklich nicht.

Wie derWachert schon sagte ist ein NAS oder ein klassischer Windows-Fileserver, ganz nach Handbuch bzw. Best-Practive Guide von Microsoft die sinnvollste Lösung.
Wer unbedingt sein SAN dafür mitverwenden will, kann dies hinter dem NAS-Head ja gern tun. Aber das ist für die Lösung des "Problems" irrelevant, wie das Blockstorage hinter dem NAS angebunden ist.
 
@Fiwi naja, wenn dann hat man für sowas IMMER einen FileServer laufen. Der hat dann nen iSCSI Target laufen ;) Leider sehe ich das bei vielen so... kotzt mich immer aufs neue an. Meistens hängt der Server an einer 100Mbit oder 1Gbit Schnittstelle durch welche dann der gesamte "übliche" Netzwerkverkehr geht, das iSCSI Target UND die SMB Freigaben des Fileservers.

Sowas ist recht "dämlich". Wenn man sowas macht, dann braucht es wenigstens 2 wenn nicht wenigstens 3 getrennte Schnittstellen. Allgemeines Netzwerk (Domäne,Tokens und Co), iSCSI Connect, SMB-Freigaben.

Eine SAN als "direktes" Ziel wie FiWi schrieb,... kann man ihm nur zustimmen, bitte nicht... BITTE!!! :P

Was das BD hinter einem NAS als HeadDev angeht... würde ich aber durchaus auch eher meiden wollen. Gut, ausnahmen könnten ein StorVize sein oder auch ne Extension an einem bestehenden RM NAS wie die Synology oder ähnliche Vertreter es ja anbieten. Mit einem "Tisch-NAS" sollte man solche Späßchen aber dann auch tunlichst meiden ;)
 
Vielen Dank für die rege Diskussion!

Ich werde es so machen, wie unten aufgeführt. Den SAN nicht nutzen und alles über servergespeicherte Profile abwickeln. Ich denke, dass das die einfachste Lösung für unser Problem ist.

Danke noch einmal für eure Mithilfe!

Joe
 
You must log in or register to reply here.
Back
Top