Jump to content

Zwei Standorte vernetzen...


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

folgende Situation: Ein Kunde hat an seinem Hauptstandort (Standort A) einen Server 2012 Std. (AD, DNS, Domäne "Firma.local", Fileserver, Mailserver mit Tobit David). Nun hat er zum Jahreswechsel einen weiteren Standort übernommen. Auch dort läuft ein Server (2012 R2 Foundation) mit AD, DNS, DHCP, Domäne "Firma2.local", Fileserver).

Am Standort A läuft ab Freitag ein VDSL 50-Anschluß (momentan noch DSL16 MBit), an Standort B ein DSL16-Anschluß. Beide Standorte sind nun schon per VPN (zwei neue LANCOM-Router) verbunden.

 

So, nun sollen die beiden Netze nach und nach noch stärker vernetzt werden. Dazu hab ich ein paar Fragen:

 

1. Kann ich die beiden verschiedenen Domänen miteinander verbinden? Oder ist es sinnvoll, die Domäne an Standort B zu entfernen und direkt an die Domäne an Standort A anzubinden? Oder ist es sinnvollWas ist eurer Meinung nach sinnvoll?

 

2. Um an beiden Standorten schnell Zugriff auf Dateien zu haben, würde sich wahrscheinlich am besten DFS-R anbieten, oder? Wenn ja, wie gehe ich da am besten vor? Wie bekomme ich erstmalig zur Replikation am einfachsten die Daten vom Server Standort A auf den Server an Standort B? Über die vorhandene VPN-Verbindung wäre dies wahrscheinlich nicht übertragbar, da es ja nicht nur ein paar MB sind...

 

3. Habt ihr generelle Tipps, wie ihr ein solches Vorhaben angehen würdet?

 

 

Grüße

ag1

Link zu diesem Kommentar

Hi,

 

zu 1) Foundation kann keine Vertrauensstellung

zu 2) DFS-R ist ungeeignet (http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx)

zu 3) Terminalserver an Standort A; alle PCs in Domäne Standort A; Server Standort B mit Standard Betriebssystem installieren und als DC für Standort B nutzen

 

Gruß

Jan

bearbeitet von testperson
Link zu diesem Kommentar

Hallo ag1,

 

das hängt von den Anforderungen ab welche die Firma hat und wie groß Sie ist. Du kannst am Anfang wenn es schnell gehen

soll einen Bidirektionellen -Trust zwischen den Gesamtstrukturen einrichten insofern den Foundation ablöst, solltest du mehr Zeit haben und genug Wissen über

die Systeme kannst du auch eine Migration machen indem du eine Domäne auflöst und die Devices, User und Co. in die andere Domäne aufnimmst, das hat den Vorteil du hast weniger Komplexität und Verwaltungsaufwand. Geht aber nicht ohne Planung und Wissen über alle Systeme.

 

Zu DFS kann ich dir aus Erfahrung sagen, auch das erfordert Planung und Wissen ansonsten machst du dir die DSL Leitung schneller dicht als du schaust da ich stark vermute das kein QoS implementiert ist

 

Grüße

 

Coolace

bearbeitet von CoolAce
Link zu diesem Kommentar

zu 1. Wenn das eine Firma ist, dann wäre das höchstwahrscheinlich sogar sehr sinnvoll. Aber ob du den Foundation sinnvoll in die andere Domäne integriert bekommst, würde ich erstmal bezweifeln.

zu 2. Naja, wenn man die Vor- und Nachteile von DFS-R kennt, _kann_ das eine Lösung sein.

zu 3. Ja, hol dir im Zweifel einen Dienstleister der dir mit Rat und Tat zur Seite steht und die Gegenbenheiten vor Ort schneller und besser erkennen dürfte, als man das hier im FOrum kann.

 

Bye

Norbert

Link zu diesem Kommentar

Moin

 

Sinnvoll ist es, nur eine Domäne zu betreiben.

 

Falls wirklich notwendig, falls stark gewünscht, dann an jedem Standort einen DC aufstellen, falls nicht notwendig, nicht stark gewünscht, dann an der Niederlassung keinn DC. Die Clients der Niederlassung sind Member der einen Domäne.

 

Die Daten sind an der Hauptstelle zu halten!

bearbeitet von lefg
Link zu diesem Kommentar

Hallo,

 

erst mal vielen Dank für eure Antworten.

 

Hab nun nochmal mit dem Kunden telefoniert und zumindest mal mehr Details erfahren. Es soll nun erst mal doch nicht so eng vernetzt werden wie beim ersten Gespräch. Die meisten notwendigen Zugriffe (Mail, Zugriff auf das Projektprogramm und ein paar kleinere Programme) sind problemlos umsetzbar. Aber zu einem Thema würde ich mich noch über Tipps von freuen:

 

Bei dem Kunden handelt es sich um ein Architekturbüro. Nun sollen die ab nun neu angelegten Projekte (Ordnerstruktur "Projekte" -> "2016" -> "Projekt A", Projekt B" etc.) auf den Server zum Hauptstandort repliziert werden, am besten so, daß am jeweils anderen Standort eine geöffnete Datei gesperrt ist und erst nach einer erfolgten Replikation wieder freigegeben wird. Somit wäre auf beiden Seiten jeweils der aktuelle Stand. Wie könnte man dies realisieren? Hat dazu jemand Erfahrungen und Tipps?

 

 

Viele Grüße

ag1

Link zu diesem Kommentar

Das geht mit Bordmitteln nicht - DFS kennt kein Locking. Oben stand es schon - alles in eine Domäne und Terminal Server.

 

Alles andere ist mehr oder weniger Murks - und Dateien in der Architektur sind auch nicht gerade klein, da kommst mit dem DSL-Anschluß net weit, auch wenn Du für DFS-Locking Zusatzsoftware kaufen würdest (die es tatsächlich gibt).

Link zu diesem Kommentar

Bei dem Kunden handelt es sich um ein Architekturbüro. Nun sollen die ab nun neu angelegten Projekte (Ordnerstruktur "Projekte" -> "2016" -> "Projekt A", Projekt B" etc.) auf den Server zum Hauptstandort repliziert werden, am besten so, daß am jeweils anderen Standort eine geöffnete Datei gesperrt ist und erst nach einer erfolgten Replikation wieder freigegeben wird. Somit wäre auf beiden Seiten jeweils der aktuelle Stand. Wie könnte man dies realisieren? Hat dazu jemand Erfahrungen und Tipps?

Sofern Du nur eine unidirektionale Synchronisation benötigst kann man so etwas mit rsync umsetzten. Haben wir hier auch für die Anbindung eines Außenstandorts im Einsatz. Die Daten des Außenstandorts werden per rsync immer zum Hauptstandort übermittelt. Spart uns das Backup im Außenstandort. 

Bei bidirektionaler Synchronisation würde ich mal im DMS Bereich schauen. Da gibt es einige Produkte die so etwas können (z.B. ELO Prof./Enterprise).

 

Gruß

Dirk

Link zu diesem Kommentar
  • 4 Wochen später...

Hallo,

 

jetzt muss ich doch nochmal nachfragen.

 

1. Also der Server in dem neuen Büro muss ersetzt werden. Da von der 2012 R2 Foundation kein Inplace-Upgrade auf die Standard-Version möglich ist, bleibt wohl nur ein Komplett-Ersatz oder ein Neuaufsetzen mit der Standardversion. Oder hat jemand eine Lösung, wie man die vorhandene Domäne in die Domäne am Hauptstandort integrieren kann?

 

2. An Internetanschlüssen stehen jetzt VDSL 50/10 am Hauptstandort und VDSL 25/5 im Außenbüro zur Verfügung. Welche Lösung ist hier eurer Erfahrung nach überhaupt sinnvoll nutzbar?

 

3. Am Hauptstandort sind ca. 20 Rechner, im Außenbüro ca. 5 Rechner im Einsatz. Der Kunde hat bei einem Kollegen erfahren, daß bei diesem DFS-R zwischen zwei Standorten läuft, und möchte es wahrscheinlich auch so haben, außer jemand hier hat noch die Hammer-Lösung als Alternative oder ein vernünftiges Argument für eine andere Lösung. Was wären denn die Vor- und Nachteile von DFS-R und Terminalserverlösung? Funktioniert denn Terminalserver i.V. mit CAD-Software vernünftig? Ist DFS-R überhaupt ohne Erfahrung implementierbar oder würdet ihr hier gleich einen DFS-R-Spezialisten hinzuziehen? Man liest öfter mal, daß es Probleme bis hin zum Datenverlust geben kann... Dann liest man wieder, wie einfach das doch ist. Hab jetzt schon einige Artikel zu dem Thema gelesen, aber je mehr man liest desto unsicherer werde ich bei dem Thema.

 

 

So, das war's nun erst mal wieder mit meinen hoffentlich nicht zu dummen Fragen...

 

 

Grüße

ag1

Link zu diesem Kommentar

Moin,

 

Du kannst die Foundation Domäne zwar auf einen Server Standard migrieren, aber Du behältst immer noch zwei Forests.

Bei nur 5 Arbeitsplätzen dürfte das Plattmachen der Foundation Domäne und Aufnehmen der PCs in die Domäne der Zentrale relativ zügig gehen. Lieber einmal einen sauberen Schnitt, als jahrelang weiter basteln.

 

Mit den Bandbreiten lässt sich einiges anstellen. Für mehrere CAD Sitzungen über RDP dürfte es aber immer noch zu knapp sein.

 

Meine Erfahrungen mit DFS-r sind recht gemischt. Meistens läuft es glatt, wenn man die Spielregeln beachtet. Wenn es nicht glatt läuft ... Backup ist ohnehin Pflicht wink.gif

Zum reinen Datensammeln für ein zentrales Backup ist DFS-r durchaus brauchbar. Das zentrale DFS-r Ziel als "schreibgeschützt" anlegen; das senkt die Fehleranfälligkeit.

 

Die Frage ist, werden die Dateien gemeinsam bearbeitet oder hat jeder Standort seine eigenen Projekte?

Link zu diesem Kommentar

Hallo Dunkelmann,

 

danke für die Antwort.

 

Beim Server geb ich dir Recht. Da wird eine Neuinstallation schneller gehen als das rumbasteln...

 

Im Prinzip soll es wie folgt ablaufen:

- Es müssen nur neue Projekte ab Zeitpunkt X auf beiden Servern verfügbar sein, nicht aber der bisherige Stand.

- Es reicht, wenn nachts die beiden Datenbestände repliziert werden. Ein gleichzeitiger Zugriff ist nicht notwendig.

- Es soll also z.B. ein Ordner "Projekte 2016" angelegt werden und darunter die jeweiligen Projekte. Dabei soll es egal sein, an welchem Standort das Projekt angelegt wird.

 

 

Genau diese "gemischten Erfahrungen" lassen mich etwas unsicher werden. Was meinst du mit "Spielregeln beachten"? Backup am Hauptstandort ist natürlich aktiv und wird auch im Außenbüro eingerichtet. Was meinst du mit "zentrales DFS-r als schreibgeschützt" anlegen? Es sollte schon wie oben genannt auf beiden Servern gearbeitet werden können, aber eben nicht gleichzeitig bzw. am gleichen Tag. Es sollen nur beide Server nachts wieder auf den aktuellen Stand gebracht werden.

 

 

Grüße

ag1

Link zu diesem Kommentar

Moin,

 

du müsstest allerdings ausschließen, dass dieselben Dokumente zwischen zwei Replikationszyklen an beiden Standorten bearbeitet werden. Dass dies "nicht nötig" ist, reicht nicht aus.

 

Stell dir vor: Ute bearbeitet "Vertrag.docx" an Standort 1 und macht daraus 100 Seiten, sie speichert um 15:30. Gleichzeitig bearbeitet Uwe seine Kopie des Dokuments an Standort 2 - er weiß nichts von Utes Änderungen und macht daraus 20 Seiten. Er speichert um 15:31.

 

Am nächsten Morgen gibt es nur noch die 20 Seiten von 15:31 - "Last Writer Wins" nennt man das.

 

Gruß, Nils

Link zu diesem Kommentar

Müssen die Daten tatsächlich auf beiden Servern vorliegen? Bitte genau darüber nachdenken und ggf. beim Auftraggeber nachfragen. Das birgt das von Nils beschriebene Risiko des last write wins.

 

Wenn es primär um gemeinsame strukturierte Verzeichnisse geht, würde ich eher auf DFS Namespaces (ohne Replikation) setzen. In einem Namespace können verteilte Ordnerziele unter einem gemeinsamen Namen veröffentlicht werden.

 

Eine ganz andere Option wären banale Verknüpfungen unterhalb des Ordners "Projekte 2016", die einfach nur auf die Arbeitsordner am jeweiligen Standort verweisen.

 

Der Zugriff auf Daten des entfernten Standort würde dabei jeweils über die WAn Strecke erfolgen. Wenn es primär um lesende standortübergreifende Zugriffe geht, könnte zusätzlich Branch Cache genutzt werden.

Ob das passt müsste man am besten vor Ort mit den Beteiligten klären.

 

DFS Replikation könnte parallel zum zentralen Backup genutzt werden.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...