none
Exchange 2010 DAG auflösen RRS feed

  • Allgemeine Diskussion

  • Ich teste gerade ein mögliches Ausfall-Szenario einer DAG Site.

    Site_A: ein DAG Server (EXA), ein Zeugenserver (FSW), ein CAS

    Site_B: ein DAG Server (EXB), ein CAS

    Wenn ich nur noch Site_B zur Verfügung habe bekomme ich ja meine Datenbank nicht mehr online, da weniger als 50% der Clusterknoten zur Verfügung stehen.

    Einen neuen Witness-Server kann ich in diesem Zustand nicht wählen. Die DAG kann ich scheinbar auch nicht auflösen.

    Folgendes habe ich probiert:

    Remove-DatabaseAvailabilityGroupServer -Identity DAG -MailboxServer EXA –ConfigurationOnly

    Worauf ich die Fehlermeldung bekomme das meine Datenbanken über mehrere Kopien verfügen.

    Remove-MailboxDatabaseCopy –Identity "Mailbox Database XY\EXA"

    Führt zu Fehlermeldung das die aktive Datenbank auf EXA liegt und ich diese erst mal verschieben soll.

    Move-ActiveMailboxDatabase –Identity  "Mailbox Datenbank XY" –ActivateOnServer EXB –SkipActiveCopyChecks

    Dann kommt der Fehler dass der Clusterdienst nicht läuft da das Quorum fehlt.

    Gibt es noch eine Möglichkeit die Datenbank ohne die Server von Site_A wieder online zu bringen?

    Mfg, Sven


    • Bearbeitet seh67 Montag, 3. Dezember 2012 15:41
    • Typ geändert Alex Pitulice Montag, 17. Dezember 2012 10:54 Warten auf Feedback
    Montag, 3. Dezember 2012 15:41

Alle Antworten

  • Hallo,

    schau dir mal diesen Artikel von Scott an:

    http://blogs.technet.com/b/exchange/archive/2011/05/31/exchange-2010-high-availability-misconceptions-addressed.aspx

    Was du braucht ist ein Alternativer Whitness Server.

    ;)


    Gruß Norbert

    Montag, 3. Dezember 2012 16:37
    Moderator
  • Hi Sven,

    vielleicht noch ein allgemeiner Hinweis zu FSW und DAG: bei einer geraden Anzahl an DAG-Members ist ein FSW notwendig. Bei einer ungeraden Anzahl an DAG-Members ist kein FSW notwendig.

    Hättest du eine ungerade Anzahl an DAG-Member, könntest du dir den FSW und alternativen FSW sparen.

    Gruß

    Dominik


    Lync-Federation: dominik.hoefling@newcotec.com


    Dienstag, 4. Dezember 2012 09:09
  • Zusatz: bei der ungeraden Anzahl der DAG kann ein Server ausfallen, Beispiel Site_B. Fallen jedoch zwei Server aus, hat der Cluster kein "Majority" mehr, was durch einen manuellen Eingriff geändert werden muss.

    Wenn Site_A der Hauptstandort und Site_B der Backup-Standort ist und es fallen zwei Server aus, welche beide in Site_A stehen, dann geht der Knoten in Site_B nicht automatisch online. Allerdings kann durch manuellen Eingriff, Änderung der Majority, Site_B online genommen werden.

    Meines Erachtens eine bessere Lösung, wenn man 2 Standorte hat, statt eines FSW.

    Best Practices sind pro Standort 2 MBX-Server in einer DAG und der FSW im Hauptstandort.

    Gruß

    Dominik


    Lync-Federation: dominik.hoefling@newcotec.com

    Dienstag, 4. Dezember 2012 09:25
  • Vielen Dank erst mal für Eure Antworten.

    @Norbert

    Alternativer Witness Server hört sich gut an, nur habe ich im Moment nur ein AD Standort.
    Wenn ich das richtig verstanden habe brauche ich dafür aber zwei AD Standorte. Da ich keine
    Erfahrung mit mehreren AD Standorten habe muss ich mich erst mal schlau machen und das
    Für und Wieder abwägen.

    @Dominik
    Wie ändert man denn die "Majority" manuell?

    Dienstag, 4. Dezember 2012 10:47
  • Hi Sven,

    hast du getrennte HUB und/oder HUB/CAS-Server kannst du den FSW auch auf diesen Servern laufen lassen.

    Hier eine tolle Anleitung mit allen Szenarios anhand von den Infos, die du uns zur Verfügung gestellt hast: http://www.shudnow.net/2011/08/05/exchange-2010-site-resilient-dags-and-majority-node-set-clustering-part-1/

    Änderung Node Majority: bei 3 DAG-Mitgliedern läuft das sog. DAC - Database Activation Coordination um das Split-Brain-Syndrom zu verhindern (ab SP1 gibt es auch Support für 2 DAG-Member und DAC). Node Majority ist einfach nur die Änderung des Clusters.

    http://smtpport25.wordpress.com/2010/12/10/exchange-2010-dag-local-and-site-drfailover-and-fail-back/

    Sollten hier aber 2 Server ausfallen, brauchst du einen FSW, damit du die Datenbanken auf den noch einen verfügbaren Server aktiv schalten kannst.

    Wie gesagt - Best Practice sind je Site 2 DAG-Member ;-)

    Gruß

    Dominik


    Lync-Federation: dominik.hoefling@newcotec.com

    Dienstag, 4. Dezember 2012 11:20
  • Ich möchte hier noch mal meine Erfahrungen zum Thema DAG Switchover mit alternativen Zeugenserver kundtun.

    Nachdem ich meine Testumgebung wieder vollständig hatte, habe ich zunächst mal die Zeugenserver mittels der EMC umkonfiguriert. Der primäre Zeugenserver wurde der CAS-A, der alternative wurde der CAS-B.
    Einen neuen AD-Standort habe ich mir gespart, d.h. meine Domäne besteht aus nur einem einzigen Standort.

    Dann habe ich den Datacenter-Aktivierungsmodus in meiner DAG eingeschaltet, um das SplitBrain-Syndrom nicht zu haben und die DataCenterSwitchover-Befehle nutzen zu können.
    "Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly"

    Als Nächstes habe ich die beiden Server in Site_A ausgeschaltet. Damit wurde die Bereitstellung der Datenbank aufgehoben, da das Quorum von mehr als 50% nicht mehr erreicht
    wurde.

    Nun kennzeichnete ich den ausgefallenen Mailboxserver mit "Stop-DatabaseAvailabilityGroup -Identity DAG1 -MailboxServer EXA" und aktiviere den anderen Mailboxserver mit
    dem Befehl "Restore-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessServer CAS-B -AlternateWitnessDirectory c:\exdag".
    Diesen Befehl mußte ich noch mal wiederholen, da ich das erste Mal eine Fehlermeldung bekam:
    Fehler für Cluster-API '"Fehler bei  EvictClusterNodeEx('EXA') mit 0x46. Fehler: Der Remoteserver wurde angehalten oder wird gerade gestartet"'. [Server: EXB].


    Damit wurde der Zeugenserver CAS-B aktiviert und die Datenbanken auf dem EXB wurden wieder bereitgestellt. Die Exchange Organisation im Datencenter 2 (Backupdatencenter) lief damit erst mal wieder.


    Nachdem  nun im primären Datencenter die "Störungen" behoben waren, schaltete ich beide Server CAS-A und EXA wieder ein, und aktivierte den "ausgefallenen" DAG-Server wieder. "Start-DatabaseAvailabilityGroup -Identity DAG1 -MailboxServer EXA"


    Nun wartete ich noch bis die Länge der Kopierwarteschlange auf EXA wieder null zeigte und alles war wieder in Ordnung.


    So, dann werde ich das mal in unserer Produktiv-Umgebung einrichten ;-)
    Gruß, Sven.


    • Bearbeitet seh67 Montag, 10. Dezember 2012 15:54
    Montag, 10. Dezember 2012 14:21
  • Leider war es dass doch noch nicht ganz.

    Im vorigen Beitrag war der nicht ausgefallene Server (EXB) auch der aktive Datenbankserver. Nun habe ich das Testszenario so verändert, das ich nur die Server von Site_A am laufen habe.
    Der Status der Datenbank lautet nun "Verbindung wurde getrennt, erneute Synchronisierung wird ausgeführt"
    Die Befehle die ich dann eingegeben habe lauten wie folgt:
    Stop-DatabaseAvailabilityGroup -Identity DAG1 -MailboxServer EXB
    Stop-Service ClusSvc
    Restore-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessServer CAS-A -AlternateWitnessDirectory c:\msxdag
    Restore-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessServer CAS-A -AlternateWitnessDirectory c:\msxdag
    Move-ActivateMailboxDatabase -Identity "Mailbox Database XY" -ActivateOnServer EXA -SkipActivateCopyChecks

    Worauf ich folgenden Fehler bekomme:

    Fehler bei Active Manager-Vorgang: Bei einem Active Manager-Vorgang ist ein Fehler aufgetreten. Der Server muss Mitglie
    d einer Datenbankverfügbarkeitsgruppe sein, und die Datenbankverfügbarkeitsgruppe muss über ein Quorum verfügen, um die
    sen Vorgang auszuführen. Fehler: Übereinstimmung für automatische Bereitstellung nicht erreicht.. [Server: EXA]
        + CategoryInfo          : InvalidOperation: (Mailbox Database XY:ADObjectId) [Move-ActiveMailboxDatabase], AmOperationNotValidOnCurrentRole
        + FullyQualifiedErrorId : 3EE8AC53,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveActiveMailboxDatabase


    Wie bekomme ich die Datenbank Online?

    Gruß, Sven



    • Bearbeitet seh67 Montag, 10. Dezember 2012 15:57
    Montag, 10. Dezember 2012 15:54
  • Hi Sven,

    Move-ActivateMailboxDatabase das müsste "Move-ActiveMailboxDatabase" heißen.

    Tippfehler oder hast du das wirklich so eingegeben?

    Gruß

    Dominik


    Lync-Federation: dominik.hoefling@newcotec.com

    Dienstag, 11. Dezember 2012 11:50
  • Oh richtig, aber das ist nur ein Tippfehler hier

    Gruß, Sven

    Dienstag, 11. Dezember 2012 12:01
  • Hat die Wiedergabewarteschlange noch Elemente?

    Move-ActiveMailboxDatabase XY EXA -SkipClientExperienceChecks

    Kannst du den Befehl mal testen?


    Lync-Federation: dominik.hoefling@newcotec.com

    Dienstag, 11. Dezember 2012 12:10
  • Generell ist es wohl so, wenn der Mailboxserver, der die aktive Datenbank hatte nicht mehr online ist, aber die Datenbank immernoch auf diesen verweist, die Datenbank auf dem zweiten Mailboxserver nicht aktiviert werden kann.

    Der Failovercluster konnte dann nicht gebildet werden, da die Kopie der Clusterkonfiguration nicht aktuell war. Ich habe dann den Cluster mit /forcequorum gestartet.

    Nun bekomme ich weitere Fehlermeldungen beim Versuch diese Datenbank auf dem Server zu aktivieren.

    Move-ActiveMailboxDatabase -Identity 'Mailbox Database XY' -ActivateOnServer 'EXB' -MountDialOverride 'None' -SkipActiveCopyChecks -SkipHealthChecks

    Fehler bei Active Manager-Vorgang: Fehler bei der Datenbankaktion: Beim Versuch, die angegebene Datenbankkopie für eine mögliche Aktivierung zu überprüfen, ist ein Fehler aufgetreten: Database copy 'Mailbox Database XY' on server 'EXB' has a copy queue length of 9223372036854577339 logs, which is too high to enable automatic recovery. You c
    an use the Move-ActiveMailboxDatabase cmdlet with the -SkipLagChecks and -MountDialOverride parameters to move the data base with loss. If the database isn't mounted after successfully running Move-ActiveMailboxDatabase, use the Mount-Data base cmdlet to mount the database.. [Datenbank: Mailbox Database XY, Server: EXB]
        + CategoryInfo          : InvalidOperation: (Mailbox Database XY:ADObjectId) [Move-ActiveMailboxDatabase], AmDbActionWrapperException
        + FullyQualifiedErrorId : F6CD68F5,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveActiveMailboxDatabase


    dann mit dem Parameter -SkipLagChecks

    Fehler bei Active Manager-Vorgang: Fehler bei der Datenbankaktion: Beim Versuch, die angegebene Datenbankkopie für eine mögliche Aktivierung zu überprüfen, ist ein Fehler aufgetreten: Datenbankkopie 'Mailbox Database XY' auf Server 'EXB' weist Inhaltsindex-Katalogdateien mit folgendem Zustand auf: 'Failed'. Bei Bedarf können Sie das Cmdlet
    'Move-ActiveMailboxDatabase' mit dem Parameter 'SkipClientExperienceChecks' verwenden, um die Datenbank zu verschieben.. [Datenbank: Mailbox Database XY, Server: EXB]
        + CategoryInfo          : InvalidOperation: (Mailbox Database XY:ADObjectId) [Move-ActiveMailboxDatabase], AmDbActionWrapperException
        + FullyQualifiedErrorId : A932FC69,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveActiveMailboxDatabase


    und dann noch mit -SkipClientExperienceChecks

    Fehler bei Active Manager-Vorgang: Fehler bei der Datenbankaktion: Die Datenbank wurde nicht eingebunden, da aufgrund eines Switchovers oder Failovers ein Datenverlust aufgetreten ist und die letzten Protokolle nicht vom Quellserver kopiert werden konnten. Ausführliche Informationen finden Sie im Ereignisprotokoll. Spezifische Fehlermeldung: Fehler beim Kopieren der verbleibenden Protokolldateien für Datenbank 'Mailbox Database XY\EXB'. Fehler: Microsoft.Exchange.Cluster.Replay.AcllUnboundedDatalossDetectedException: Es wurden veraltete, vom Protokoll generierte Informationen für Datenbank 'Mailbox Database XY' festgestellt (Letzte Aktualisierung (UTC) = 2012-12-11T10:49:03, Zulässige Dauer = 00:12:00, Tatsächliche Dauer = 01:04:56.0767790).
       bei Microsoft.Exchange.Cluster.Replay.AttemptCopyLastLogs.ProtectUnboundedDataloss()
       bei Microsoft.Exchange.Cluster.Replay.AttemptCopyLastLogs.UpdateMountAllowedNow(AutoDatabaseMountDial& mountDial, Boolean& mountDialOverrideUsed)
       bei Microsoft.Exchange.Cluster.Replay.AttemptCopyLastLogs.ComputeLossAndMountAllowed(LocalizedString errorString)
       bei Microsoft.Exchange.Cluster.Replay.AttemptCopyLastLogs.AttemptCopyLastLogsInternal()
       bei Microsoft.Exchange.Cluster.Replay.AttemptCopyLastLogs.MakeAttempt(LogCopier logCopier, LogInspector logInspector, LogReplayer logReplayer)
    . [Datenbank: Mailbox Database XY, Server: EXB]
        + CategoryInfo          : InvalidOperation: (Mailbox Database XY:ADObjectId) [Move-ActiveMailboxDatabase], AmDbActionWrapperException
        + FullyQualifiedErrorId : 8D45F9B5,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveActiveMailboxDatabase

    Die Datenbank will ums verrecken nicht online gehen :-(

    Gruß, Sven


    • Bearbeitet seh67 Dienstag, 11. Dezember 2012 12:28
    Dienstag, 11. Dezember 2012 12:27
  • Hi Sven,

    bitte den Befehl folgendermaßen testen:

    Move-ActiveMailboxDatabase -SkipActiveCopyChecks -SkipLagChecks -MountDialOverride:BestEffort -SkipClientExperienceChecks -SkipHealthChecks -ActivateOnServer exch-dr -Identity DB1

    Gruß

    Dominik


    Lync-Federation: dominik.hoefling@newcotec.com

    Dienstag, 11. Dezember 2012 12:50