5
Fileserver für Terminalserverfarmen im Rechenzentrum
Guten Tag zusammen,
ich habe folgende Situation und benötige Hilfe für ein Konzept.
Wir haben aktuell ein Rechenzentrum diesem Aufbau:
- Fileserver
- Domaincontroller
- Broker
- Terminalserver Farmen (ca. 20 Farmen)
Die Kunden greifen per RDP auf ihre Farm zu.
Die Profile sind Remotedesktop Profile und werden auf dem Fileserver gespeichert
Die Kunden haben ein Netzlaufwerk per GPO, mit dem Sie auf ihre eigene Datenstruktur zugreifen können (auch auf dem Fileserver)
Zusätzlich haben die User noch ein eigenes Home Laufwerk, welches auch über GPO als Laufwerk gemappt wird (auch auf dem Fileserver)
Dieser oben genannte Aufbau ist leider historisch bedingt, ich möchte das ablösen. Wir sind im Aufbau eines neuen Rechenzentrums, somit ist es perfekt alles mit einem neuen Konzept zu starten und diese Kunden dann zu migrieren.
Warum möchte ich das?
- Fileserver wird im Cluster aufgebaut, sodass auch zu regulären Zeiten gewartet werden kann, ohne dass der Kunde betroffen ist
- Fileserver explodiert an der Datenmenge: Daten, Profile, Homelaufwerke
- Terminalserver explodieren, da manche Kunden bis zu 50 User haben und die Profile auch lokal angelegt werden, somit auf jedem Terminalserver des Kunden 50 Profile auf C:
- Das Rechenzentrum wird Redundant, in 2 verschiedenen Standorten, mit jeweils der gleichen Hardware miteinander verbunden sein, dies wird durch HP und einer externen Firma die speziell auf solche Umgebungen spezialisiert ist, aufgebaut.
- Alle wichtigen Server (SQL, File, Web, DC, etc.) werden im Cluster aufgebaut
Was möchte ich?
- Ein Konzept für den Fileserver, sodass dieser nicht unzählige TB gross sein wird (wie soll es aufgebaut werden für die Daten des Kunden, die Profile, die Homelaufwerke)
- Evtl. VHDX, damit die Terminalserver nicht volllaufen und C: irgendwann riesig wird
Hat jemand Erfahrung darin? Ich möchte es wirklich von Anfang an so aufbauen und testen, dass das Konzept viele Jahre hebt und nicht irgendwelche Speicherprobleme auf Terminalservern und Fileserver auftreten. Die Userlogins aber auch nicht gerade 10 Minuten dauern wie manchmal mit Redirected Folders, das hatte ich vor ca. 2 Jahren schon abgeschafft, da es immer wieder Probleme gemacht hat, dafür sind die Laufwerke der Terminalserver eben hochgegangen, da alles auf C: gespeichert wird beim Anmelden und beim Abmelden wieder synchronisiert wird auf den Fileserver, aber auf dem Terminalserver trotzdem bleibt.
Vielen Dank für jeden Gedanken an meine Frage
ich habe folgende Situation und benötige Hilfe für ein Konzept.
Wir haben aktuell ein Rechenzentrum diesem Aufbau:
- Fileserver
- Domaincontroller
- Broker
- Terminalserver Farmen (ca. 20 Farmen)
Die Kunden greifen per RDP auf ihre Farm zu.
Die Profile sind Remotedesktop Profile und werden auf dem Fileserver gespeichert
Die Kunden haben ein Netzlaufwerk per GPO, mit dem Sie auf ihre eigene Datenstruktur zugreifen können (auch auf dem Fileserver)
Zusätzlich haben die User noch ein eigenes Home Laufwerk, welches auch über GPO als Laufwerk gemappt wird (auch auf dem Fileserver)
Dieser oben genannte Aufbau ist leider historisch bedingt, ich möchte das ablösen. Wir sind im Aufbau eines neuen Rechenzentrums, somit ist es perfekt alles mit einem neuen Konzept zu starten und diese Kunden dann zu migrieren.
Warum möchte ich das?
- Fileserver wird im Cluster aufgebaut, sodass auch zu regulären Zeiten gewartet werden kann, ohne dass der Kunde betroffen ist
- Fileserver explodiert an der Datenmenge: Daten, Profile, Homelaufwerke
- Terminalserver explodieren, da manche Kunden bis zu 50 User haben und die Profile auch lokal angelegt werden, somit auf jedem Terminalserver des Kunden 50 Profile auf C:
- Das Rechenzentrum wird Redundant, in 2 verschiedenen Standorten, mit jeweils der gleichen Hardware miteinander verbunden sein, dies wird durch HP und einer externen Firma die speziell auf solche Umgebungen spezialisiert ist, aufgebaut.
- Alle wichtigen Server (SQL, File, Web, DC, etc.) werden im Cluster aufgebaut
Was möchte ich?
- Ein Konzept für den Fileserver, sodass dieser nicht unzählige TB gross sein wird (wie soll es aufgebaut werden für die Daten des Kunden, die Profile, die Homelaufwerke)
- Evtl. VHDX, damit die Terminalserver nicht volllaufen und C: irgendwann riesig wird
Hat jemand Erfahrung darin? Ich möchte es wirklich von Anfang an so aufbauen und testen, dass das Konzept viele Jahre hebt und nicht irgendwelche Speicherprobleme auf Terminalservern und Fileserver auftreten. Die Userlogins aber auch nicht gerade 10 Minuten dauern wie manchmal mit Redirected Folders, das hatte ich vor ca. 2 Jahren schon abgeschafft, da es immer wieder Probleme gemacht hat, dafür sind die Laufwerke der Terminalserver eben hochgegangen, da alles auf C: gespeichert wird beim Anmelden und beim Abmelden wieder synchronisiert wird auf den Fileserver, aber auf dem Terminalserver trotzdem bleibt.
Vielen Dank für jeden Gedanken an meine Frage
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: 2639083713
Url: https://administrator.de/contentid/2639083713
Ausgedruckt am: 22.11.2024 um 21:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
Als Profilmanagement: FSLogix, somit hast du nur eine VHDX die am Terminalserver bei Anmeldung gemountet wird.
Homelaufwerk: Hier würde ich Homefolder (Desktop, documents etc.) redirecten und das Laufwerk auf z.B. 1GB pro User begrenzen (somit werden die User gezwungen nicht denn ganzen "Müll" herumliegen zu lassen). Weiterer Gedanke zur redirection --> Falls ein neues Profil erstellt werden muss, sind die User daten unabhängig davon.
Daten des Kunden: Evtl. Archivierungslösung für alte Dateien um platz zu sparen. Muss mit Kunde angeschaut werden.
Das wären meine Vorschläge.
Gruss
Als Profilmanagement: FSLogix, somit hast du nur eine VHDX die am Terminalserver bei Anmeldung gemountet wird.
Homelaufwerk: Hier würde ich Homefolder (Desktop, documents etc.) redirecten und das Laufwerk auf z.B. 1GB pro User begrenzen (somit werden die User gezwungen nicht denn ganzen "Müll" herumliegen zu lassen). Weiterer Gedanke zur redirection --> Falls ein neues Profil erstellt werden muss, sind die User daten unabhängig davon.
Daten des Kunden: Evtl. Archivierungslösung für alte Dateien um platz zu sparen. Muss mit Kunde angeschaut werden.
Das wären meine Vorschläge.
Gruss
Erfahrung habe ich keine mit einer Lösung für mehrere Kundeninstanzen, aber ich gehe mal davon aus das ihr da entsprechend alles sauber trennt.
Für Profile definitiv FSLogix.
Redirected Folders kann man aber zusätzlich nutzen um die Profile Disks kleiner zu halten. Dateien aus den Redirected Folders lassen sich auch leichter administrativ da "raus holen" oder, wenn die redirected folders auf Freigaben laufen, mit anderen Nutzern teilen. Grundsätzlich sollten Daten natürlich nicht Benutzerspezifisch sondern in einer gemeinsamen Unternehmensstruktur abgelegt werden, man kann also die Nutzerdaten auch durch Quotas sehr klein halten. Hier wäre es ebenfalls klug zu trennen damit Dokumente (die in redirected folders liegen) nicht z.B. in das selbe Limit laufen wie der Browser Cache (VHDX können dann ein eigenes Limit haben).
Du solltest dir hier gut überlegen ob du alles in eine VHDX mit einem Limit packst oder nur AppData im VHDX ablegst und zusätzlich redirected folders nutzt.
Für den Fileserver solltest du dir DFS ansehen. Ich will es selbst auch erst noch umsetzen aber du kannst damit die Pfade einheitlich aufbauen und im Hintergrund mehrere Fileserver für verschiedenste Zwecke betreiben. Also z.B. Profildaten (VHDX) auf schnelleren Laufwerken als reine Dokumente. Der User sieht nur eine große Datenhalde. Außerdem kann DFS auch Replikation und besser über mehrere Hosts skalieren.
Für Profile definitiv FSLogix.
Redirected Folders kann man aber zusätzlich nutzen um die Profile Disks kleiner zu halten. Dateien aus den Redirected Folders lassen sich auch leichter administrativ da "raus holen" oder, wenn die redirected folders auf Freigaben laufen, mit anderen Nutzern teilen. Grundsätzlich sollten Daten natürlich nicht Benutzerspezifisch sondern in einer gemeinsamen Unternehmensstruktur abgelegt werden, man kann also die Nutzerdaten auch durch Quotas sehr klein halten. Hier wäre es ebenfalls klug zu trennen damit Dokumente (die in redirected folders liegen) nicht z.B. in das selbe Limit laufen wie der Browser Cache (VHDX können dann ein eigenes Limit haben).
Du solltest dir hier gut überlegen ob du alles in eine VHDX mit einem Limit packst oder nur AppData im VHDX ablegst und zusätzlich redirected folders nutzt.
Für den Fileserver solltest du dir DFS ansehen. Ich will es selbst auch erst noch umsetzen aber du kannst damit die Pfade einheitlich aufbauen und im Hintergrund mehrere Fileserver für verschiedenste Zwecke betreiben. Also z.B. Profildaten (VHDX) auf schnelleren Laufwerken als reine Dokumente. Der User sieht nur eine große Datenhalde. Außerdem kann DFS auch Replikation und besser über mehrere Hosts skalieren.
Vielen Dank
Tatsächlich hatte ich auch schon angefangen, mich mit FSLogix auseinander zu setzen.
Die Kundendaten sind natürlich alle sauber getrennt und haben eine Kontingente. Aber mein Problem war eben, dass wenn ich 20-30 Kunden habe, diese regelmässig auch neue Benutzer dazu bekommen usw. die Daten natürlich anwachsen und irgendwann ist der Fileserver dann 2 TB.
Aber ich werde mich auf jeden Fall weiter mit FSLogix auseinandersetzen und das testen.
DFS kenne ich, allerdings hatte ich das nie ohne Probleme gesehen, immer irgendwelche Daten die nicht synchronisiert werden etc. aber das ist jetzt fast 10 Jahre her, vielleicht gebe ich dem noch eine Chance und teste es doch noch einmal.
Tatsächlich hatte ich auch schon angefangen, mich mit FSLogix auseinander zu setzen.
Die Kundendaten sind natürlich alle sauber getrennt und haben eine Kontingente. Aber mein Problem war eben, dass wenn ich 20-30 Kunden habe, diese regelmässig auch neue Benutzer dazu bekommen usw. die Daten natürlich anwachsen und irgendwann ist der Fileserver dann 2 TB.
Aber ich werde mich auf jeden Fall weiter mit FSLogix auseinandersetzen und das testen.
DFS kenne ich, allerdings hatte ich das nie ohne Probleme gesehen, immer irgendwelche Daten die nicht synchronisiert werden etc. aber das ist jetzt fast 10 Jahre her, vielleicht gebe ich dem noch eine Chance und teste es doch noch einmal.
Ich will tatsächlich bei mir nur den DFS Namespace einführen um Daten auf mehreren Fileservern in eine Struktur zusammen zu führen. Replikation ist ein eigener Teil und muss nicht zum Einsatz kommen, die Fileserver können ihre Daten auch anderweitig replizieren oder eventuell auch zusätzlich als Cluster laufen, das muss man mal ausprobieren.
Ich hab einfach ein besseres Gefühl wenn ich nicht so viele TB auf einem Fileserver liegen habe, womöglich noch als VM. In der Wartung hat das Vor- und Nachteile.
Ich hab einfach ein besseres Gefühl wenn ich nicht so viele TB auf einem Fileserver liegen habe, womöglich noch als VM. In der Wartung hat das Vor- und Nachteile.
Ja genau, ich möchte eben auch nicht das so viele TB auf einem Fileserver liegen.
Dann werde ich mir das noch einmal genau ansehen. Vielen Dank
Dann werde ich mir das noch einmal genau ansehen. Vielen Dank
