89371
26.10.2018
972
7
0
Schnellste Disaster Recovery Methode für AD und Exchange
Hallo zusammen,
wie sichert Ihr einen AD und Exchange Server, um ihn schnell wieder per Disaster Recovery zum laufen zu bringen? Das mühseelige zurückspielen eines kompletten Images auf die lokalen Platten dauert doch Stunden.
Ich habe eine Methode aufgegriffen, bei dem die Server übers Netzwerk von einem SAN/NAS/iSCSI booten und im Falle eines Disaster Recovery einfach nur auf ein kopiertes Boot Image zurück gegriffen wird. Somit bootet der Server wieder innerhalb von wenigen Minuten wieder hoch.
Ich sehe dabei jedoch einen gravierenden Nachteil: Der Server ist dann von weiteren Geräten abhängig. Wenn nur der Switch neu bootet, crasht der Server. Auch dürfte die Performance übers Netzwerk in die Knie gehen, im Vergleich zu physikalischen Maschinen mit SSD's.
Gibt es eine Methode dieses innerhalb einer Maschine ohne Netzwerk zu lösen?
Ich kenne nur die Möglichkeit den Server als ein VM Host zu betrieben und AD und Exchange als VM laufen zu lassen. Aber das beeinflusst doch die Performance deutlich schlimmer und einen DC sollte man nach meinem gefählichen Halbwissen nach auch nicht virtuell betreiben, da es zu unsyncronitäten mit evtl vorhandenen Backup DC's kommen kann.
Muss man für ein schnelles Disaster Recovery den Performance Verlust in Kauf nehmen oder kennt Ihr noch eine bessere Methode zum sichern/rücksichern?
wie sichert Ihr einen AD und Exchange Server, um ihn schnell wieder per Disaster Recovery zum laufen zu bringen? Das mühseelige zurückspielen eines kompletten Images auf die lokalen Platten dauert doch Stunden.
Ich habe eine Methode aufgegriffen, bei dem die Server übers Netzwerk von einem SAN/NAS/iSCSI booten und im Falle eines Disaster Recovery einfach nur auf ein kopiertes Boot Image zurück gegriffen wird. Somit bootet der Server wieder innerhalb von wenigen Minuten wieder hoch.
Ich sehe dabei jedoch einen gravierenden Nachteil: Der Server ist dann von weiteren Geräten abhängig. Wenn nur der Switch neu bootet, crasht der Server. Auch dürfte die Performance übers Netzwerk in die Knie gehen, im Vergleich zu physikalischen Maschinen mit SSD's.
Gibt es eine Methode dieses innerhalb einer Maschine ohne Netzwerk zu lösen?
Ich kenne nur die Möglichkeit den Server als ein VM Host zu betrieben und AD und Exchange als VM laufen zu lassen. Aber das beeinflusst doch die Performance deutlich schlimmer und einen DC sollte man nach meinem gefählichen Halbwissen nach auch nicht virtuell betreiben, da es zu unsyncronitäten mit evtl vorhandenen Backup DC's kommen kann.
Muss man für ein schnelles Disaster Recovery den Performance Verlust in Kauf nehmen oder kennt Ihr noch eine bessere Methode zum sichern/rücksichern?
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: 390759
Url: https://administrator.de/contentid/390759
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
kommt darauf an
Viele Datensicherungsprogramme, Shadowprotect und Acronis können ein Virtuel Recovery/Boot.
Dabei wird die VM direkt vom Backup-Storage gestartet. Das dauer nur wenige Minuten bis das System läuft.
Stefan
kommt darauf an
Viele Datensicherungsprogramme, Shadowprotect und Acronis können ein Virtuel Recovery/Boot.
Dabei wird die VM direkt vom Backup-Storage gestartet. Das dauer nur wenige Minuten bis das System läuft.
Stefan
Hi,
Recovery von großen Datenbeständen dauert im Desasterfall immer lang. Die Dauer ist dann davon abhängig, wie investitionsbereit der Kunde war und wieiviel ihm ein möglichst kurzer Ausfall Wert ist. Im Zweifel hat man halt mehrere Systeme die sich gegenseitig replizieren und steht dann nie wirklich unter Zeitdruck.
Gruß
bloody
Recovery von großen Datenbeständen dauert im Desasterfall immer lang. Die Dauer ist dann davon abhängig, wie investitionsbereit der Kunde war und wieiviel ihm ein möglichst kurzer Ausfall Wert ist. Im Zweifel hat man halt mehrere Systeme die sich gegenseitig replizieren und steht dann nie wirklich unter Zeitdruck.
Gruß
bloody
Wenn AD und Exchange unternehmenskritisch sind, dann wäre es doch wirklich nicht falsch es mind. doppelt auszulegen. Zwar hat das direkt mit dem Backup nichts zu tun, aber es hat zumindest Einfluss. Btw... Seit 2012R2 kannst du den DC als VM laufen lassen.
Alles doppelt auszulegen ist in der Tat eine gute Idee um den Desaster Recovery nicht verwenden zu müssen.
Was haltet Ihr von der Stabilität bei iSCSI? Mit jedem zusätzlichen Gerät steigt doch das Ausfallrisiko?!?
Was haltet Ihr von der Performance, wenn alles auf VM's läuft?
Ich habe mal testweise einen i7 mit 32GB RAM als VM host installiert, eine VM als DC und eine VM als Exchange Server installiert und der Exchange Server war grotten-langsam. Alleine das Anmelden beim OWA dauerte bis zu 30 Sekunden. Bei einem so schwachen Host auch erklärbar, aber nur um zu spielen wollte ich mir keinen goldenen Xeon kaufen.
Was haltet Ihr von der Stabilität bei iSCSI? Mit jedem zusätzlichen Gerät steigt doch das Ausfallrisiko?!?
Was haltet Ihr von der Performance, wenn alles auf VM's läuft?
Ich habe mal testweise einen i7 mit 32GB RAM als VM host installiert, eine VM als DC und eine VM als Exchange Server installiert und der Exchange Server war grotten-langsam. Alleine das Anmelden beim OWA dauerte bis zu 30 Sekunden. Bei einem so schwachen Host auch erklärbar, aber nur um zu spielen wollte ich mir keinen goldenen Xeon kaufen.
Wie du weißt braucht Exchange richtig viel Ram. Die 32 Gb hätte ich ihm schon alleine gegeben. Außerdem solltest du festplattentechnisch richtig was einbauen, denn die VMs teilen sich ja die HDDs. Nicht, dass sie mehr mit Zugriffen als mit lesen/schreiben beschäftigt ist. Das braucht kein Mensch. Oder du steckt Enterprise SSDs rein. Kostet zwar, aber es lohnt sich. Wir haben das für unsere Entwicklungsumgebung so gemacht. Da juckt es nicht, wenn jemand noch mal "Plattenlast" mit einer VM erzeugt, weil er war ausprobieren muss.
Doppelt sollte man das immer machen. DC kannst du z.B. einen physik und einen als VM.
DCs konnte man auch schon vor 2012R2 als VM laufen lassen. Man muss halt ein paar Sachen beachten
https://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-v ...
Ein Exchange mit 32GB Ram ist schon sehr unterdimensioniert. Exchange kannst du auch als VM laufen lassen, muss halt entsprechende Power drunter liegen. Viele haben auch dedizierte Hosts für ihre Exchange VM.
DCs konnte man auch schon vor 2012R2 als VM laufen lassen. Man muss halt ein paar Sachen beachten
https://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-v ...
Ein Exchange mit 32GB Ram ist schon sehr unterdimensioniert. Exchange kannst du auch als VM laufen lassen, muss halt entsprechende Power drunter liegen. Viele haben auch dedizierte Hosts für ihre Exchange VM.
@fireblade09
@89371
Gruß,
Dani
Gruß,
Dani
in Exchange mit 32GB Ram ist schon sehr unterdimensioniert. Exchange kannst du auch als VM laufen lassen, muss halt entsprechende Power drunter liegen. Viele haben auch dedizierte Hosts für ihre Exchange VM.
Die 32GB sind doch relativ zu sheen. Wenn nur 5 Postfächer und 100 Mails täglich empfangen/versendet werden, sind 32GB nicht sinnvoll und notwendig.@89371
Was haltet Ihr von der Stabilität bei iSCSI? Mit jedem zusätzlichen Gerät steigt doch das Ausfallrisiko?!?
Grundsätzlich ist gegen iSCSI nichts einzuwenden. Wenn man sich an Best Practise für Server, Storage, Netzwerk hält, sehe ich keinerlei Probleme.Ich sehe dabei jedoch einen gravierenden Nachteil: Der Server ist dann von weiteren Geräten abhängig. Wenn nur der Switch neu bootet, crasht der Server.
Die Problematik hast du doch im laufenden Betrieb auch. Ein Switch hat eine Firmware und diese wird in der Regel doch auch zeitnah aktualisiert um Bugs/Sicherheitslücken zu schließen.Auch dürfte die Performance übers Netzwerk in die Knie gehen, im Vergleich zu physikalischen Maschinen mit SSD's.
Wenn das Netzwerk und das Storage richtig dimensoniert ist für die Anwendungsfälle merkt man kaum einen Unterschied im Betrieb.Gruß,
Dani
Gruß,
Dani
