MThomas 10 Geschrieben 3. Juli 2012 Melden Teilen Geschrieben 3. Juli 2012 Hallo zusammen, noch einmal kurz zu mir: Ich bin seit langem stiller User im MCSEBoard und habe mir hier schon den einen oder anderen Tipp erlesen können. Ein gutes Forum hier - Danke dafür. Zu meiner Umgebung: Ich baue zur Zeit eine virtuelle Umgebung mittels VMWare auf. Hierbei benutze ich VCenter Server 5 mit zwei physikalischen ESXI-Hosts und einem seperaten Backupserver. Nach VMWareempfehlung läuft der Managementhost auch als virtuelle Maschine. DC-Systeme sind Windows2008R2 Standard auf dem Backuphost und virtuell Windows 2008R2 Datacenter. Zu meiner Frage: Auf dem Backuphost habe ich zur Zeit den ersten DC mit den FSMO-Rollen installiert. Die restliche Umgebung inkl. DC2 läuft virtuell. Aus Gründen der Ausfallsicherheit neige ich nun dazu, die FSMO-Rollen doch lieber auf den virtualisierten DC2 zu ziehen. So bräuchte ich bei einem Ausfall des Backhosts (DC1) z.B. keine Rollen "seizen". Sollte ich die FSMO-Rollen auf den virtualisierten DC "transfer"ieren? Sind hierbei Probleme zu erwarten? Macht meine Überlegung Sinn? Worin seht ihr Vor- und Nachteile? Eure Meinung interessiert mich sehr. Grüße Thomas Zitieren Link zu diesem Kommentar
Robi-Wan 10 Geschrieben 3. Juli 2012 Melden Teilen Geschrieben 3. Juli 2012 Hallo, die Frage, ob eine Migration der FSMO-Rollen wegen der Ausfallsicherheit zu verschieben notwendig ist, kannst nur Du beantworten. Schau Dir an, wofür die Rollen gut sind und was bei einem Ausfall passiert. Dann musst Du für jede Rolle einzeln entscheiden, ob für Dich ein Ausfall verkraftbar ist oder nicht. Ohne die Anforderungen und geplanten Änderungen in Deiner Infrastruktur zu kennen, ist keine Aussage zielführend. Grüße, Robert Zitieren Link zu diesem Kommentar
MThomas 10 Geschrieben 3. Juli 2012 Autor Melden Teilen Geschrieben 3. Juli 2012 Hallo, Danke für die Antwort. Gibt es denn irgendeinen Einwand, alle FSMO-Rollen auf den virtuellen DC zu ziehen? DC1: AD, DNS Backupsoftware DC2: AD, DNS, KMS Mehrere Memberserver: File, Print, WSUS, Proxy, Applikationen usw. - eine Domäne Grüße Thomas Zitieren Link zu diesem Kommentar
Necron 71 Geschrieben 3. Juli 2012 Melden Teilen Geschrieben 3. Juli 2012 Hallo, Danke für die Antwort. Gibt es denn irgendeinen Einwand, alle FSMO-Rollen auf den virtuellen DC zu ziehen? DC1: AD, DNS Backupsoftware DC2: AD, DNS, KMS Mehrere Memberserver: File, Print, WSUS, Proxy, Applikationen usw. - eine Domäne Hi, dagegen spricht nichts. Aber wenn ihr schon am virtualisieren seid, dann würde ich noch einen dritten DC als virtuellen in Betrieb nehmen. So viel Ressourcen verbraucht der wiederum nicht. ;) Zitieren Link zu diesem Kommentar
bla!zilla 10 Geschrieben 3. Juli 2012 Melden Teilen Geschrieben 3. Juli 2012 Ich würde nur zwei DCs in der virtuellen Umgebung laufen lassen. Ein Managementhost/ Backuphost sollte nie so kritisch sein, wie es ein DC ist. Du kannst auf jedem der beiden ESXi einen DC laufen lassen und über Autostartup die DCs beim Start bzw. Shutdown eines oder beider ESXi Server rauf- oder runtefahren lassen. Wichtig: Keine Snapshosts von den DCs machen bzw. zurückspielen. Sichere den Systemstate der beiden Kisten. Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 3. Juli 2012 Melden Teilen Geschrieben 3. Juli 2012 Welche Maschinen willst du mit der Backupsoftware sichern? Wenn du die Virtuelle Umgebung sichern willst würde ich diesen nicht virtualisieren. Zitieren Link zu diesem Kommentar
MThomas 10 Geschrieben 4. Juli 2012 Autor Melden Teilen Geschrieben 4. Juli 2012 Hallo zusammen, vielen Dank für die zahleichen Hilfestellungen. Ich habe mich entschieden: - physikalischer Backuphost ist DC2 ohne FSMO-Rollen - virtueller DC1 hat die FSMO-Rollen problemlos übernommen Falls DC2 nun ausfallen sollte, brauche ich nur noch im schlimmsten Fall ein Metadata-Clenaup durchführen und brauche vorher keine Rollen seizen. Sollte der virtuelle DC1 ausfallen, kann ich die Snapshotsicherung zurückspielen und auf beiden DCs Systemstate zurücksichern. Bis dahin sorgt DC2 für den Betrieb. In jedem Fall läuft der DC mit den FSMO nun virtuell und somit doch sicherer, denke ich. Grüße Thomas Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 4. Juli 2012 Melden Teilen Geschrieben 4. Juli 2012 Sollte der virtuelle DC1 ausfallen, kann ich die Snapshotsicherung zurückspielen und auf beiden DCs Systemstate zurücksichern. Bis dahin sorgt DC2 für den Betrieb. Grüße Thomas Hast du einen DC mit Windows Server 2012? Wenn nein, dann darfst du keine Snapshots von DC's zurückspielen! Zitieren Link zu diesem Kommentar
MThomas 10 Geschrieben 4. Juli 2012 Autor Melden Teilen Geschrieben 4. Juli 2012 Ich sehe bei Snapshotsicherungen keine Probleme, wenn ich ich die VM zurücksichere und ausgeschaltet lasse. Dann trenne ich die VM vom Netzwerk, fahre sie hoch und spiele das gesicherte Systemstate zurück. Anschließend spiele ich auf dem anderen DC ein zeitgleiches Systemstate zurück und fahre die DCs wieder im Netzwerk hoch. Das müsste doch klappen, oder? Grüße Thomas Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 4. Juli 2012 Melden Teilen Geschrieben 4. Juli 2012 Mir wäre ein "müsste" zu viel Risiko und würde das nicht so machen. Bei Server 2012 kannst du Snapshots machen. Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 5. Juli 2012 Melden Teilen Geschrieben 5. Juli 2012 Warum willst du überhaupt den DC aus einem Backup wiederherstellen? Neue VM bereitstellen, dcpromo, fertig! Ohne Risiken und Nebenwirkungen. Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 5. Juli 2012 Melden Teilen Geschrieben 5. Juli 2012 Vor allem verlierst du bei bei deinem Plan ggf. Objekte, die zwischen dem Disasterfall und dem Restore angelegt worden sind, wenn du beide DC's zurückspielst. Zitieren Link zu diesem Kommentar
MThomas 10 Geschrieben 5. Juli 2012 Autor Melden Teilen Geschrieben 5. Juli 2012 Hallo zusammen, sicherlich habt ihr Recht: Neu aufsetzen ist die beste und sicherste Lösung. Snapshot und State zurücksichern ist aber die schnellste Lösung ;-)) zumal bei uns im AD nicht zu viel passiert. Dazu bin ich nebst Urlaubsvertretung der einzige Admin, der Änderungen an den Servern vornimmt und die USN sich so nicht unerwartet erhöhen kann. Vielen Dank aber für die Kritik. Ich werde daher eine VM vorbereiten, die im Notfall zum DC gemacht wird und die Rollen übernehmen kann. Das schließt dann wohl jedes Risiko aus und geht auch recht schnell. Eventuell weiss jemand, ob ich dann einfach einen neuen KMS aufsetzen kann, ohne den alten KMS irgendwo entfernen zu müssen. Das gleiche gilt für eventuelle Lizenzserver, die auf dem DC in Zukunft laufen könnten, denn der virtuelle DC wird Rollenmaster, zweiter Katalogserver, DNS, KMS und Lizenzserver sein. Gerade die letzten genannten Gründe haben mich zur Überlegung bewegt, eventuell doch eher auf die Sicherungen und Systemstate zurückzugreifen - damit würde ich zu 99% keine Objekte im AD verlieren und hätte innerhalb von 10 Minuten die DCs wieder aktiv. Voraussetzung wäre natürlich eine regelmäßige Systemstatesicherung, um ein USN-Rollback zu vermeiden. Danke für die vielen Stellungnahmen und die gute Diskussion Viele Grüße Thomas Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 5. Juli 2012 Melden Teilen Geschrieben 5. Juli 2012 Ein KMS ist schnell aufgesetzt. Der SRV Record wird registriert - eventuell noch den alten SRV Record löschen - fertig! Beim Umzug vom RD Lizenzserver wirst du um einen Anruf beim Clearing House wohl nicht herum kommen. How to move Terminal Services CALs from one license server to another in Windows 2000, Windows Server 2003 and Windows Server 2008 Wenn du ohnehin an einen Umzug der Rollen denkst, packe doch gleich beide in kleine separate VM und spare dir die Backup/Restore Thematik, die auftritt, wenn die Rollen mit auf einem DC laufen. Zitieren Link zu diesem Kommentar
MThomas 10 Geschrieben 6. Juli 2012 Autor Melden Teilen Geschrieben 6. Juli 2012 Vielen Dank. Die Idee mit der separaten VM finde ich sehr gut. Somit habe ich nun die für mich perfekte Lösung. Grüße Thomas 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.