5
DFS Zugriff soll nur auf eine Replikationspartner erfolgen
Hallo Gemeinde.
Folgendes Problem
Zustand:
2 Standorte über VPN verbunden
Jeweils ein 2008R2 DC
DFS auf beiden Servern
Replikation einwandfrei von DFS/ AD
Standorte sind gebaut im AD, Server zugeordnet, DNS sauber.
Besonderheit ist, das dass DFS nur dazu dient die Daten von Standort B nach Standort A zu bringen damit sie dort gesichert werden und für den Fall das Server B ausfällt ein langsammes arbeiten möglich ist.
Problem:
Die Clients am Standort B verbinden sich auch scheinbar willkürlich zum DFS an Standort A. Da mit Datengrößen von 20-50 MB gearbeitet wird zum Teil, gibt es konflikte mit den Dateiversionen etc.
Frage:
Wie ist indiesem Fall der saubere Weg dem DFS zu sagen, greife nur auf Server B zu und nur im Fehlerfall auf A. Mir würde es stichpunktartig reichen was eingestellt sein muss.
Alles was ich an Einstellung versucht habe, hat mit diversen Fehlern und Effekten nicht geklappt weil mir einfach die Erfahrung fehlt und ich aus meinen ergoogelten Sachen nicht schlau werde.
Danke an alle
Folgendes Problem
Zustand:
2 Standorte über VPN verbunden
Jeweils ein 2008R2 DC
DFS auf beiden Servern
Replikation einwandfrei von DFS/ AD
Standorte sind gebaut im AD, Server zugeordnet, DNS sauber.
Besonderheit ist, das dass DFS nur dazu dient die Daten von Standort B nach Standort A zu bringen damit sie dort gesichert werden und für den Fall das Server B ausfällt ein langsammes arbeiten möglich ist.
Problem:
Die Clients am Standort B verbinden sich auch scheinbar willkürlich zum DFS an Standort A. Da mit Datengrößen von 20-50 MB gearbeitet wird zum Teil, gibt es konflikte mit den Dateiversionen etc.
Frage:
Wie ist indiesem Fall der saubere Weg dem DFS zu sagen, greife nur auf Server B zu und nur im Fehlerfall auf A. Mir würde es stichpunktartig reichen was eingestellt sein muss.
Alles was ich an Einstellung versucht habe, hat mit diversen Fehlern und Effekten nicht geklappt weil mir einfach die Erfahrung fehlt und ich aus meinen ergoogelten Sachen nicht schlau werde.
Danke an alle
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: 228779
Url: https://administrator.de/contentid/228779
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
du musst die Sites ordentlich definieren.
LG
du musst die Sites ordentlich definieren.
LG
Er meint, Du musst im ADS für jeden physischen Standort einen Standort-Objekt erstellen und die zugehörigen Subnet-Objekte. Dann ordnest Du die Subnet-Objekte den jeweiligen Standorten zu. Der Client prüft regelmäßig, zu welchem Standort er gehört. Das tut er über die Auswertung der Subnet-Objekte und Vergleich mit seiner eigenen IP-Adresse. Dann bestimmt der DFS-Client aus der DFS-Konfiguration, die er ebenfalls aus dem ADS liest, ob es ein Ordner-Ziel am gleichen Standort gibt. Wenn ja nimmt er das, wenn nein, dann sucht er über die Standortverknüpfungen das nächstgelegenen Ziel.
Soweit die Theorie. Bei uns klappt nämlich auch das nicht 100% zuverlässig. Es gibt keine Garantie. Wenn das lokale Ziel mal nicht schnell genug reagiert, dann greift der Client auf das nächste zu.
E.
Soweit die Theorie. Bei uns klappt nämlich auch das nicht 100% zuverlässig. Es gibt keine Garantie. Wenn das lokale Ziel mal nicht schnell genug reagiert, dann greift der Client auf das nächste zu.
E.
Zitat von @emeriks:
Er meint, Du musst im ADS für jeden physischen Standort einen Standort-Objekt erstellen und die zugehörigen
Subnet-Objekte. Dann ordnest Du die Subnet-Objekte den jeweiligen Standorten zu. Der Client prüft regelmäßig, zu
welchem Standort er gehört. Das tut er über die Auswertung der Subnet-Objekte und Vergleich mit seiner eigenen
IP-Adresse. Dann bestimmt der DFS-Client aus der DFS-Konfiguration, die er ebenfalls aus dem ADS liest, ob es ein Ordner-Ziel am
gleichen Standort gibt. Wenn ja nimmt er das, wenn nein, dann sucht er über die Standortverknüpfungen das
nächstgelegenen Ziel.
Soweit die Theorie. Bei uns klappt nämlich auch das nicht 100% zuverlässig. Es gibt keine Garantie. Wenn das lokale Ziel
mal nicht schnell genug reagiert, dann greift der Client auf das nächste zu.
E.
Er meint, Du musst im ADS für jeden physischen Standort einen Standort-Objekt erstellen und die zugehörigen
Subnet-Objekte. Dann ordnest Du die Subnet-Objekte den jeweiligen Standorten zu. Der Client prüft regelmäßig, zu
welchem Standort er gehört. Das tut er über die Auswertung der Subnet-Objekte und Vergleich mit seiner eigenen
IP-Adresse. Dann bestimmt der DFS-Client aus der DFS-Konfiguration, die er ebenfalls aus dem ADS liest, ob es ein Ordner-Ziel am
gleichen Standort gibt. Wenn ja nimmt er das, wenn nein, dann sucht er über die Standortverknüpfungen das
nächstgelegenen Ziel.
Soweit die Theorie. Bei uns klappt nämlich auch das nicht 100% zuverlässig. Es gibt keine Garantie. Wenn das lokale Ziel
mal nicht schnell genug reagiert, dann greift der Client auf das nächste zu.
E.
Dann hast dir irgendwo einen Bock geschossen, bei mir funktioniert das an drei Standorten Problemlos. Eine evtl. Serverauslastung spricht für ein Fehldesign Hardware nah, nicht für eine Fehlfunktion des Dienstes, denn er soll ja im Fehlerfall eine "Alternative" auswählen.
Zitat von @certifiedit.net:
Eine evtl. Serverauslastung spricht für ein Fehldesign Hardware nah, nicht für eine Fehlfunktion des Dienstes, denn er soll ja im Fehlerfall eine "Alternative" auswählen.
Eine evtl. Serverauslastung spricht für ein Fehldesign Hardware nah, nicht für eine Fehlfunktion des Dienstes, denn er soll ja im Fehlerfall eine "Alternative" auswählen.
Schon klar, aber am Thema vorbei. Du kannst es NICHT garantieren. Du kannst nur alles dafür tun, dass es hoffentlich nicht passiert. Das wollte ich sagen.
Hast Du das jemals über einen längeren Zeitraum aufgezeichnet, um das so felsenfest zu behaupten?
Man kann aber für solche Fälle aber vordenken und am DFS-Ordner-Objekt die "Cachedauer" und das "Clientfallback" konfigurieren.
E.
Zitat von @emeriks:
> Zitat von @certifiedit.net:
>
> Eine evtl. Serverauslastung spricht für ein Fehldesign Hardware nah, nicht für eine Fehlfunktion des Dienstes, denn
er soll ja im Fehlerfall eine "Alternative" auswählen.
>
Schon klar, aber am Thema vorbei. Du kannst es NICHT garantieren. Du kannst nur alles dafür tun, dass es hoffentlich nicht
passiert. Das wollte ich sagen.
> Zitat von @certifiedit.net:
>
> bei mir funktioniert das an drei Standorten Problemlos
>
Hast Du das jemals über einen längeren Zeitraum aufgezeichnet, um das so felsenfest zu behaupten?
Man kann aber für solche Fälle aber vordenken und am DFS-Ordner-Objekt die "Cachedauer" und das
"Clientfallback" konfigurieren.
E.
> Zitat von @certifiedit.net:
>
> Eine evtl. Serverauslastung spricht für ein Fehldesign Hardware nah, nicht für eine Fehlfunktion des Dienstes, denn
er soll ja im Fehlerfall eine "Alternative" auswählen.
>
Schon klar, aber am Thema vorbei. Du kannst es NICHT garantieren. Du kannst nur alles dafür tun, dass es hoffentlich nicht
passiert. Das wollte ich sagen.
> Zitat von @certifiedit.net:
>
> bei mir funktioniert das an drei Standorten Problemlos
>
Hast Du das jemals über einen längeren Zeitraum aufgezeichnet, um das so felsenfest zu behaupten?
Man kann aber für solche Fälle aber vordenken und am DFS-Ordner-Objekt die "Cachedauer" und das
"Clientfallback" konfigurieren.
E.
Hi
je nachdem, wie man garantieren auslegt. Wenn das ganze öfter vorkommt, doch dagegen/dafür könnte man ordentlicher Planung eine Garantie für abgeben.
Muss ich nicht. Die Leitungen zu den anderen Standorten (hier mein Dank an die Telekom, einmal sarkastisch, einmal ehrlich gemeint) bisher noch bei 2MB - bald 50M, würde das Ding Ausfallen würde ich mich entweder selbst ärgern oder vom ärger anderer hören, dass alles so langsam ist.
LG,
Christian
