bill_mustermann 1 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 (bearbeitet) Hallo, ich überlege gerade wie ich es umsetzen könnte das wenn unser DC1 (Server 2012 std) ausfällt unsere Mitarbeiter trotzdem weiter arbeiten können. Derzeit haben wir nur einen DC welcher auf Laufwerk D: alle wichtigen Daten enthält (Fileserver). Unser DC1 hat nun also folgenden Funktionen: - DC1 - DNS - Fileserver Laufwerk D (Datei und Speicherdienste?) - Druckdienste - IIS (wahrscheinlich wegen WSUS) - WSUS Ich habe mir nun überlegt zu erst einmal einen DC2 einzurichten und diesen als Sekundären DC zu konfigurieren. Dann habe ich darüber nachgedacht zwischen den beiden Servern ein DFS einzurichten für Laufwerk D. Ziel soll sein das wenn DC1 ausfällt (offline) unsere Mitarbeiter trozdem noch auf Daten von Laufwerk D zugreifen können OHNE die URL oder den PFAD im Windows Explorer odwer sonstwo ändern zu müssen. Die USer sollen von dem Ausfall nichts merken. Ist mein Ansatz so OK oder gibts andere und bessere Lösungen? Falls das so klappen würde, was sind die Schlagwörter die ich googlen muss um mich da einzulesen? - DFS-N ? - DFS-R ? - Zweiten DC zufügen ? gruesse bearbeitet 12. Januar 2015 von bill_mustermann Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 (bearbeitet) Die USer sollen von dem Ausfall nichts merken. Ds ist ein wirklich hohes Ziel, das wirst Du aber mit den veranschlagten Mittel DFS-R für den Filer wohl nicht erreichen, Hochverfügbarkeit ist etwas anderes, Hochverfügbarkeit kostet einfach Geld. Ausfallsicherheit bietet das nicht, ersetze den Begriff gegen Verfügbarkeit. Unterscheide zwischen den Funktionen Filer und DC. Mit einem 2.DC ist bei Ausfall des 1.DC weiter verfügbar das AD und DNS, bei passenden OS oder Konfiguration auch DHCP. Von einem Ausfall des 1.DC merken die User dann nichts, der 2.DC stellt die Dienste zur Verfügung. bearbeitet 12. Januar 2015 von lefg Zitieren Link zu diesem Kommentar
gysinma1 13 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 (bearbeitet) Hallo Ein (oder mehrere) Domain Controller sind nie hochverfügbar. Er ist lediglich redundant. Das Vorhaben das die Leute nix merken lässt sich nicht erreichen, denn in jedem Falle dauert es 2-3 Minuten bis die Clients auf einen zweiten Domain Controller (DNS Cache) ausweichen. Zumindest das ist feststellbar. Sowieso würde ich in jedem Falle einen zweiten Domain Controller hinzufügen. Es lässt sich dann überlegen, ob man eine DFS Replication (nicht DFSR) machen soll. Auch das bringt nur etwas wenn die URL Pfade auf DNS Alias zeigen welche bei einem Ausfall manuell angepasst werden müssen. Gruss, Matthias bearbeitet 12. Januar 2015 von gysinma1 Zitieren Link zu diesem Kommentar
NilsK 2.969 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 Moin, abgesehen davon, ist DFS für die meisten Dateitypen auch nicht als Verfügbarkeitstechnik geeignet, weil es nach dem "Last Writer Wins"-Prinzip arbeitet: Zwei Replikate "wissen" nichts voneinander. Ändert jemand das Replikat 1 und jemand anders das Replikat 2, so überschreibt einfach die letzte Dateiversion die ältere. Gruß, Nils Zitieren Link zu diesem Kommentar
bill_mustermann 1 Geschrieben 12. Januar 2015 Autor Melden Teilen Geschrieben 12. Januar 2015 Hallo, erstmal danke für die Antworten :) Ich habe mir unser Konstrukt nun mal genauer angeschaut und muss feststellen das das alles noch komplizierter (oder auch einfacher) wird als gedacht. Wir haben ALLE unsere Server auf XEN virtualisiert. Also auch den DC1. Laufwerk D ist ein eigenes LVM welches in der DC1 VM einfach mit eingebunden wird. Platz für ein zweites LVM mit den Daten von Laufwerk D ist nicht vorhanden! Wenn ich nun eine zweite VM anlege als DC2 habe ich schonmal AD, DNS und DHCP ausfallsicher da im Problemfall der DC2 die Dienste zur Verfügung stellt. Was aber mache ich mit Laufwerk D? gruesse Zitieren Link zu diesem Kommentar
Doso 77 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 DHCP ausfallssicher stellst du dir einfacher vor als es ist. Meist ist es keine gute Idee zwei DHCP Server in einem Netz zu betreiben, wenn man nicht weis was man tut. Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 DHCP ausfallssicher stellst du dir einfacher vor als es ist. Meist ist es keine gute Idee zwei DHCP Server in einem Netz zu betreiben, wenn man nicht weis was man tut. Wo ist das Problem? DHCP1 stellt zur Verfügung 192.168.0.x und DHCP2 stellt 192.168.1.x, das Netz ist /23, das sollte doch funktionieren. Wie ist das mit DHCP auf Server 2012? Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 Seit 2012 gibt es auch die Möglichkeit den DHCP redundant aufzubauen. Zitieren Link zu diesem Kommentar
NilsK 2.969 Geschrieben 12. Januar 2015 Melden Teilen Geschrieben 12. Januar 2015 Moin, klar geht alles - der Hinweis war wohl auch eher, dass es nicht ausreicht, einfach zwei DHCP-Server im Netz zu betreiben. @bill_mustermann: Mir scheint, als solltest du dir mal einen kundigen Berater ins Haus holen. Verfügbarkeitskonzepte sind nicht trivial. Zuerst sollte man sich über seine Anforderungen im Klaren sein, und die sollten realistisch sein und sich an den Geschäftsprozessen orientieren. Hört man in der IT nicht so gern, ist aber so. Gruß, Nils Zitieren Link zu diesem Kommentar
bill_mustermann 1 Geschrieben 12. Januar 2015 Autor Melden Teilen Geschrieben 12. Januar 2015 >> Mir scheint, als solltest du dir mal einen kundigen Berater ins Haus holen. Wird wohl kein Weg dran vorbei gehen :) Danke für dei Antworten. gruesse Zitieren Link zu diesem Kommentar
Weingeist 159 Geschrieben 13. Januar 2015 Melden Teilen Geschrieben 13. Januar 2015 Das Problem bei den Beratern ist leider meist, dass man als Kleinfirma oft ned die tollste Beratung bekommt, sei es weil eben Zeit Geld ist oder schlicht Inkompetenz oder Schludrigkeit in der Abklärung. Unabhängig davon - ein externer Berater kann trotzdem sehr hilftreich sein - hat es noch nie geschadet sich über die Möglichkeiten, Gefahren, technisches Design etc. zu erkundigen um nicht quasi der Depp zu sein, der alles abnicken muss nur um am Ende zu merken, dass es nicht so toll war. ;) Bezüglich DHCP: In nem kleinen Netzwerk könntest auch fixe IP's vergeben (Oder Reservierungen im DHCP) und die Lease-Dauer deutlich erhöhen. Dann bleibt die Adresse erhalten auch wenn der DHCP kaputt geht. Alternativ mit Server 2012. Da klappt das mit der Redundanz ganz gut. Ein paar Tipps für DFS/Kleine Umgebungen: - Zwei Fileserver mit DFS-Stamm (evtl. zugleich DC) mit gleicher Datenstruktur. Beide Freigaben (zb. SV1_Daten, SV2_Daten) als Ordnerziele definieren. Ein Ordnerziel auf das andere Replizieren. Ein Ordnerziel deaktivieren und Zugriff sperren. Das macht das Replikationshandling viel einfacher und quasi sicher, da es keine Konflikte gibt. - Das einfachste Fehlerhandling und unproblematische Veröffentlichung erreichte ich, wenn der Freigabename jeweils den ServerNamen bzw. einen Kürzel davon enthielt und nicht identisch waren. Also wie oben SV1_Freigabename, SV2_Freigabename. - Im Fehlerfalle das andere Ziel als aktiv markieren - Änderungen am DFS-Stamm sind abhängig vom PDC. Wenn Du nun obiges Design umsetzen würdest, dann hast Du ein Problem wenn das Primäre Ziel auf dem PDC liegt und der PDC kaputt geht. Dann kannst nämlich das Ziel nicht ummappen und musst zwingend auf den Restore des PDC warten. Deshalb entweder auf dem PDC gar keine Ordnerziele oder nur das Replikat vorhalten - Es ist wichtig die Replikation NICHT mit dem gleichen Assistenten zu machen wie den DFS-Ordner --> Sehr mühsam im Handling, da nur beides zusammen verändert bzw. gelöscht werden kann. Replikation später separat einrichten So hat man quasi immer zwei aktuelle Datenstände und muss beim in der Regel grossen Fileserver nicht auf dessen vollständige Rücksicherung warten. Die anderen Server sind bei einem einigermassen potenten Backup und Disksystem relativ zügig wiederhergestellt. Anbei noch ein guter Link bezüglich DFS wie man es nicht machen sollte http://blogs.technet.com/b/deds/archive/2011/07/12/wie-ein-dfs-namespace-nicht-aussehen-sollte.aspx Zitieren Link zu diesem Kommentar
bill_mustermann 1 Geschrieben 13. Januar 2015 Autor Melden Teilen Geschrieben 13. Januar 2015 Danke Weingeist.... Ich denke jetzt habe ich erstmal genug Informationen. gruesse Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 13. Januar 2015 Melden Teilen Geschrieben 13. Januar 2015 Weil ich gerade DC und WSUS gelesen habe. Dieser Artikel ist für die Kombination WSUS/DC wichtig: http://www.wsus.de/wsus_auf_domain-controllern Zitieren Link zu diesem Kommentar
NorbertFe 2.100 Geschrieben 13. Januar 2015 Melden Teilen Geschrieben 13. Januar 2015 Das Problem bei den Beratern ist leider meist, dass man als Kleinfirma oft ned die tollste Beratung bekommt, sei es weil eben Zeit Geld ist oder schlicht Inkompetenz oder Schludrigkeit in der Abklärung. Du meinst "Kleinfirma" als Dienstleister oder als Auftragnehmer? ;) Unabhängig davon - ein externer Berater kann trotzdem sehr hilftreich sein - hat es noch nie geschadet sich über die Möglichkeiten, Gefahren, technisches Design etc. zu erkundigen um nicht quasi der Depp zu sein, der alles abnicken muss nur um am Ende zu merken, dass es nicht so toll war. ;) Das hilft aber auch nur, wenn man keien "Depp" als Dienstleister engagiert. ;) Bye Norbert Zitieren Link zu diesem Kommentar
Weingeist 159 Geschrieben 13. Januar 2015 Melden Teilen Geschrieben 13. Januar 2015 (bearbeitet) @Norbert: Och das geht in alle Richtungen. Bei den grossen Berater-Firmen bekommt man oft den Depp / die Deppen der Firma, oder eben auch Lehrlinge die können ja bei den kleinen lernen. Natürlich mit hohen Stundenansätzen. Bei den kleinen gibts genauso gute und weniger gute. Praktisch ist wenn man die Namen der kompotenten Leute kennt und auf die bestehen kann. =) Leider findet man das oft erst heraus wenn das Kind in den Brunnen gefallen ist. Daher schadet möglichst umfassende Selbstinformation über entsprechende Konzepte nie. Egal für welchen Zweig der Firma Ware, Maschinen, Geräte, Dienstleistung oder eben IT Dienstleistung eingekauft wird. Gutes Beispiel: Man spart heute bei einer Windows Server-Lizenz und hat morgen Spass bei der komplexen Migration weil falsche Dienste kombiniert werden die zwar unterstützt sind aber das Update-Handling unnötig kompliziert machen. Das kostet dann Manpower in Form von teuren Stunden. Das es besser ist, die Dienste möglichst zu separieren trifft in der Regel auch für Kleinumgebungen zu. bearbeitet 13. Januar 2015 von Weingeist Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.