Kan ik hier veilig replicatie verwijderen?

[michaelbar]

Beste,

Ik heb een vraagje mbt. een foutieve replicatie opstelling in Hyper-V die ik helaas trof bij komst op mijn nieuwe werk.

Ik wil min of meer weten of ik veilig replicatie kan stopzetten (en vervolgens opschonen) aan de hand van de volgende informatie.

Even ter background, normaliter kun je replicatie opzetten tussen 2 machines voor Hyper-V Failover, echter zie ik op de Slave server een replica in de 'warning' status, en er zijn al langere tijd geen replicaties uitgevoerd. Niet alleen dat, ook was de 'friendly name' (aka. wat je ziet in de UI) veranderd zodoende staat er nu 'DO NOT USE' achter (intussen renamed naar passende: '(failover-slave)')... Zie screenshot.

Als ik kijk naar de Master server, zie ik dat er een replica naar zichzelf wordt gemaakt?? Dat is hetgeen wat mij een beetje doet zorgen maken, vooral daar dit gaat om de FMSO domain controller van het bedrijf. Zie screenshot.

Mocht dit een risicovolle situate lijken (en laten we hopen dat we samen vinden dat dat niet zo is) dan kan ik nog altijd de FSMO rollen verplaatsen naar een recent gekreerde nieuwe DC, maar mocht dat lastig zijn, of de omgeving betasten, dan wil ik dat het liefst ook vermeiden (ervaring mee, iemand?).

Mocht iemand hier ervaring mee hebben, wil iemand mij dan adviseren?

Alvorens hartelijk dank allen, en nog een fijne dag toegewenst

Warning Slave (on server 1):


Warning Master (on server 2). Zie de 'Primary' en 'Replica' servers (waar het dus allemaal om gaat):

[ Voor 3% gewijzigd door michaelbar op 14-02-2018 11:52 ]

[MAX3400]

2 seconden Googlen op een non-clustered Hyper-V omgeving (dus losse nodes zonder directe shared storage maar wel een domain trust)

- replicatie "wegmikken" op de master VM
- slave VM "wegmikken" en even handmatig de storage opruimen
- replicatie van master VM opnieuw aanmaken

Maar ja, dan heb je zomaaaar kans dat je over een maand dezelfde errors gaat krijgen. Het lijkt me sowieso wel een mooi leermomentje om uberhaupt te troubleshooten waarom de replicatie niet meer functioneert maar ook hoe je FSMO / DC's in een organisatie verplaatst. Point being; zonder DC/FSMO heeft Hyper-V geen bestaansrecht...

[michaelbar]

MAX3400 schreef op woensdag 14 februari 2018 @ 12:27:
2 seconden Googlen op een non-clustered Hyper-V omgeving (dus losse nodes zonder directe shared storage maar wel een domain trust)

- replicatie "wegmikken" op de master VM
- slave VM "wegmikken" en even handmatig de storage opruimen
- replicatie van master VM opnieuw aanmaken

Maar ja, dan heb je zomaaaar kans dat je over een maand dezelfde errors gaat krijgen. Het lijkt me sowieso wel een mooi leermomentje om uberhaupt te troubleshooten waarom de replicatie niet meer functioneert maar ook hoe je FSMO / DC's in een organisatie verplaatst. Point being; zonder DC/FSMO heeft Hyper-V geen bestaansrecht...

Beste MAX3400,

Ik moet zeggen dat het een goede oefening is, maar ook een gevaarlijke? Overigens is het dat ik eerder twijfel aan het feit dat de server zijn eigen 'replicatie target' is geworden, maar hoe is mij onduidelijk.

Als er iets is waar ik altijd voorzichtig mee ben, is het schijbare 'misconfiguraties' vooral in productie omgevingen, laat staat op de FSMO DC...

Door in deze situatie te zitten, hoopte ik inzicht te krijgen in hoe deze situatie ontstond, en advies te krijgen mbt. wat ik evt. aan pro-actieve diagnoses kan uitvoeren.

Heb jij zodoende, of iemand anders daar dus aan de hand van nog meer info voor mij?

Alvorens ontzettend bedankt

Mvg,

Michael

[ Voor 5% gewijzigd door michaelbar op 15-02-2018 11:33 ]

[MAX3400]

Het is geen gevaarlijke; replication is niets meer/minder dan running delta's kopieren zodat je in geval van een "failover" alleen de data kwijt bent sinds de laatste delta. Als je van een VM elk uur een replicatie maakt, is je RTO 1 uur. Voor een Domain Controller houdt dat in dat de wijzigingen op Active Directory (etcetera) dus maximaal een uur oud zijn. Aangezien een Domain Controller zelf een ingebouwde tombstone heeft van 4320 uur, kan je redelijkerwijs aannemen dat een DC best enige uren offline mag zijn maar dat het natuurlijk wel logisch is dat de functies voor de omgeving op dat moment niet aanwezig zijn.

Om je minder met techniek lastig te vallen
- stop de replicatieschedules (dus niet weggooien) en je zal zien dat de DC gewoon blijft draaien
- indien je replicatie wil verwijderen, zet de VM uit, export de VM (tijdelijk) naar disk
- maak een ad-hoc backup van de VM
- gooi alle replicatieschedules weg
- zet de VM aan; er is een 99.999999% kans dat deze gewoon netjes opkomt en zaken gaat doen
- laat de VM draaien een dag of drie

- bij geen klachten: verwijder alle replicatie-files van disk
- bij geen verdere klachten: verwijder de exported VM

- maak na een week een nieuw replicatie-schedule aan naar de andere host

Aanvullend: indien je maar 1 DC hebt, zou ik je wel adviseren om mogelijk toch extra in te gaan lezen in hoe je een DC kan re-createn / authorative restores / FSMO takeover moet doen. Baat het niet, dan schaadt het niet.

[michaelbar]

Hi allen,

Eigenlijk weet ik nou nog steeds niet of het 'verwijderen' van de replicatie informatie, goed zal gaan, daar het een gekke configuratie lijkt te zijn. Is er iemand die mij dat nog kan vertellen?

Is het ook een gekke configuratie, in de zin van, kan het kloppen dat de master en slave de zelfde machine zijn?

Alvorens dank

[MAX3400]

michaelbar schreef op vrijdag 16 februari 2018 @ 12:00:
Is het ook een gekke configuratie, in de zin van, kan het kloppen dat de master en slave de zelfde machine zijn?

Ja dat kan. Als de VM eerst op node1 stond en repliceerde met node2, en er heeft een (handmatige) failover plaatsgevonden waardoor de VM nu op node2 staat, houdt het replicatie-verhaal hier absoluut geen rekening mee.

[michaelbar]

MAX3400 schreef op vrijdag 16 februari 2018 @ 12:21:
[...]

Ja dat kan. Als de VM eerst op node1 stond en repliceerde met node2, en er heeft een (handmatige) failover plaatsgevonden waardoor de VM nu op node2 staat, houdt het replicatie-verhaal hier absoluut geen rekening mee.

Beste MAX3400,

1. Ik heb de replicate op de slave verwijderd, ook de vhd.
2. Ik heb daarna de replicatie info weg gehaald op de master.
3. Ik ben nu een nieuwe replica aan het maken naar de slave

Dus alles ging goed, en daarvoor hartelijk dank

Dank je wel.

Met vriendelijke groeten,

Michael Barton

PS: Fijn weekend

[ Voor 3% gewijzigd door michaelbar op 16-02-2018 13:25 ]

[Question Mark]

michaelbar schreef op vrijdag 16 februari 2018 @ 13:25:
[...]
• Ik ben nu een nieuwe replica aan het maken naar de slave

Waarom deze keuze, en niet gewoon simpelweg een tweede Domain Controller deployen? Dat levert qua beschikbaarheid veel meer voordelen op.