4
Nur ein aktiver DFS ohne Replikation
Hallo zusammen,
habe in einer Infrastruktur mehrere Fileserver und darunter auch 2 DFS geerbt. Heute bin auch darauf gestoßen, dass beide DFS unterschiedliche Aufgaben übernehmen und Netzwerkfreigaben entweder auf dem einen oder den anderen aktiv sind. Außerdem gibt es untereinander keine Replikationsgruppe.
Die angelegten Namespaces sind jedoch Deckungsgleich.
Hat es einen bestimmten Sinn ihnen unterschiedliche Referenzlisten zu geben? Ich würde ansonsten beide DFS auf allen Freigabeordner aktiv schalten. Wir haben nur einen Standort, also keinen zweiten DFS an einem anderen Standort mit anderen Fileserverfreigaben und Berechtigungen. Außerdem würde doch eine Mehrzweckreplikationsgruppe Sinn machen oder?
Viele Grüße und einen schönen Wochenstart,
Crypt0r
habe in einer Infrastruktur mehrere Fileserver und darunter auch 2 DFS geerbt. Heute bin auch darauf gestoßen, dass beide DFS unterschiedliche Aufgaben übernehmen und Netzwerkfreigaben entweder auf dem einen oder den anderen aktiv sind. Außerdem gibt es untereinander keine Replikationsgruppe.
Die angelegten Namespaces sind jedoch Deckungsgleich.
Hat es einen bestimmten Sinn ihnen unterschiedliche Referenzlisten zu geben? Ich würde ansonsten beide DFS auf allen Freigabeordner aktiv schalten. Wir haben nur einen Standort, also keinen zweiten DFS an einem anderen Standort mit anderen Fileserverfreigaben und Berechtigungen. Außerdem würde doch eine Mehrzweckreplikationsgruppe Sinn machen oder?
Viele Grüße und einen schönen Wochenstart,
Crypt0r
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: 4863849871
Url: https://administrator.de/contentid/4863849871
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
4 Kommentare
Neuester Kommentar
Moin,
man muss hier ja unterscheiden zwischen DFS Namespaces und DFS Replication. Namespaces als Technologie verstecken ja den UNC Pfad, um sich bspw. beim Umzug oder Crash keine Sorgen um genutzte Pfade machen zu müssen: Server A weg, Server B hin, Daten aus dem Backup holen. Oder Migrationsszenarien,.... Oder wie auch immer. Die Liste kann lang sein.
Ob diese Daten per Replikation redundant sein müssen, ist ein anderes Thema, u.a. auch ob deine Hardware das von der Menge an Daten überhaupt packt.
Es kann also durchaus seine Berechtigung haben Namespaces ohne Replication zu betreiben.
VG
man muss hier ja unterscheiden zwischen DFS Namespaces und DFS Replication. Namespaces als Technologie verstecken ja den UNC Pfad, um sich bspw. beim Umzug oder Crash keine Sorgen um genutzte Pfade machen zu müssen: Server A weg, Server B hin, Daten aus dem Backup holen. Oder Migrationsszenarien,.... Oder wie auch immer. Die Liste kann lang sein.
Ob diese Daten per Replikation redundant sein müssen, ist ein anderes Thema, u.a. auch ob deine Hardware das von der Menge an Daten überhaupt packt.
Es kann also durchaus seine Berechtigung haben Namespaces ohne Replication zu betreiben.
VG
1
Hey Tezzla,
danke für dein Feedback! Aber macht es dennoch Sinn beide DFS alle Namespaces aktiv zu nehmen? Wir haben 4 Namespaces mit unterschiedlich vielen Verweisen, jeder DFS übernimmt 2 Namespaces.
danke für dein Feedback! Aber macht es dennoch Sinn beide DFS alle Namespaces aktiv zu nehmen? Wir haben 4 Namespaces mit unterschiedlich vielen Verweisen, jeder DFS übernimmt 2 Namespaces.
Zitat von @crypt0r:
danke für dein Feedback! Aber macht es dennoch Sinn beide DFS alle Namespaces aktiv zu nehmen? Wir haben 4 Namespaces mit unterschiedlich vielen Verweisen, jeder DFS übernimmt 2 Namespaces.
danke für dein Feedback! Aber macht es dennoch Sinn beide DFS alle Namespaces aktiv zu nehmen? Wir haben 4 Namespaces mit unterschiedlich vielen Verweisen, jeder DFS übernimmt 2 Namespaces.
Wenn man das als Lastverteilung sieht, ja.
Ich würds allerdings anders machen
VG
Moin.
Jo, das ergibt schon Sinn, vor allem ohne Replikation: Schaltest du die ein, greifen deine File-Locks evtl. ins Leere und die gleiche Datei wird auf beiden Servern bearbeitet. Bei replizierten DFS-Namespaces entscheidet der _Client!_, mit welchem DFS-Server er sich verbindet, d.h. Client A öffnet Datei XYZ von Server A und bearbeitet diese, während Client B Datei XYZ von Server B öffnet und bearbeitet.
Ein automatischer Merge findet dann nicht statt, es wird dann immer die neueste Version der Datei "überleben", die andere landet in einem speziellen Ordner und es gibt einen Eventlog-Eintrag über diesen Vorfall.
DFS-Replikation als "Full-Mesh" ist zwar hochredundant, aber mit eben solchen Unannehmlichkeiten behaftet. Ein Hub-and-Spoke-Modell bei der Replikation nutzt man z.B., um Daten mehrerer Server von verschiedenen Standorten zum Hauptstandort zu replizieren, um sie dann dort mit dem zentralen Backup einzusammeln o.ä.
Cheers,
jsysde
Jo, das ergibt schon Sinn, vor allem ohne Replikation: Schaltest du die ein, greifen deine File-Locks evtl. ins Leere und die gleiche Datei wird auf beiden Servern bearbeitet. Bei replizierten DFS-Namespaces entscheidet der _Client!_, mit welchem DFS-Server er sich verbindet, d.h. Client A öffnet Datei XYZ von Server A und bearbeitet diese, während Client B Datei XYZ von Server B öffnet und bearbeitet.
Ein automatischer Merge findet dann nicht statt, es wird dann immer die neueste Version der Datei "überleben", die andere landet in einem speziellen Ordner und es gibt einen Eventlog-Eintrag über diesen Vorfall.
DFS-Replikation als "Full-Mesh" ist zwar hochredundant, aber mit eben solchen Unannehmlichkeiten behaftet. Ein Hub-and-Spoke-Modell bei der Replikation nutzt man z.B., um Daten mehrerer Server von verschiedenen Standorten zum Hauptstandort zu replizieren, um sie dann dort mit dem zentralen Backup einzusammeln o.ä.
Cheers,
jsysde
