none
Ausfallzenario, Verständnisfrage RRS feed

  • Frage

  • moin,

    wir haben zwei EXCHANGE 2016 (DAG) DNS round robin und zwei AD Server. Client Office 2013

    wenn ich nun einen patche - vorher alle DB und aktiven User gemoved habe - können manche nur nach einem Neustart einsteigen. Outlook schließen reicht nicht. Ok, da wir ja keinen Loadbalancer haben. Mit dem könnte ich ja noch leben.

    Wenn nun ein CU Upgrade schief geht, ist der Server ja leider meist unbrauchbar. Was kann man am besten und schnellsten machen, damit dieser wieder geht.

    Darf man die gesamte Systemplatte samt Exchange restoren wenn man zwei Server hat? Die DBs und DB-Logs liegen auf eigenen Platten. Einige Systemlog und Queues liegen auf C:

    Montag, 13. April 2020 08:52

Antworten

  • Moin,

    ein DAG-Mitglied irgendwie wiederherstellen klappt in den allerwenigsten Fällen. Andererseits habe ich schon länger keine CU-Installationen mehr gesehen, die so richtig schief gegangen sind. Meistens hat man .NET vergessen, den Virenscanner angelassen, die AD-Replikation nicht abgewartet oder Ähnliches, Layer 8-Fehler also. Sollte es tatsächlich böse knallen, so ist der einzige supportete Weg DAG auflösen, Recovery-Installation, DAG wieder instantiieren. Wenn sich an den DBs in der Zeit nicht allzuviel geändert hat, gelingt es oft sogar ohne Re-Seeding.

    Ein richtiges Schwenken a la Load Balancer ist mit Round Robin nicht wirklich möglich, aber man kann dem näher kommen als bloss alle Datenbanken auf dem anderen Server zu aktivieren. Hier ein paar Ansätze, alles freilich kein Allheilmittel, aber in Kombination kann es durchaus helfen:

    1. Component States. Nachdem man die Datenbanken geschwenkt hat, sollte man, bevor man mit der Wartung beginnt, auf dem zu wartenden Server auch die Webservices tatsächlich auf "down" setzen (Set-ServerComponentState ist Dein Freund, die gesuchte Komponente heißt ServerWideOffline). Nicht vergessen, nach der Wartung wieder zurückzudrehen! 
    2. Round Robin für die Wartung tatsächlich auflösen. Es ist unglücklich, dass man einen DNS-Record nicht deaktivieren kann, aber Dein Maintenance-Skript kann ja den Record für den zu wartenden Server löschen und dann wieder anlegen. Wichtig ist, dass man bereits vor der Wartung die TTL für die RR-Records deutlich heruntersetzt, so dass die Clients gezwungen sind, zeitig nochmal zu fragen.

    Über einen Load Balancer kannst Du auch nachdenken. Es muss ja nicht gleich ein Netscaler sein, und Du brauchst ja auch kein SSL-Offload oder Ähnliches. Seit Exchange 2013 ist es sehr einfach, ein L4-HTTPS-Loadbalancing mit Exchange zu betreiben. Eine ZEVENET-Appliance ist kostenlos und in wenigen Minuten als VM aufgesetzt. Damit kannst Du sogar - ebenfalls kostenlos - ein Load Balancer-Cluster aufsetzen und auch Deinen Load Balancer ohne Downtime patchen und warten. Auch andere Projekte wie pfSense  können inzwischen einfaches Load Balancing.

    Oder, wenn Deine Infrastruktur nicht sehr groß ist, kannst Du von KEMP einen Free LoadMaster installieren. Die Limitierungen gegenüber der Vollversion sind:

    • kein Clustering
    • kein Support
    • Lizenz muss 1x pro Monat durch Nach-Hause-Telefonieren validiert werden
    • Bandbreitenbeschränkung auf 20 Mbps

    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert Dont - Worry Montag, 13. April 2020 11:20
    Montag, 13. April 2020 09:33

  • was macht man dann in so einem Fall?

    wie oben kurz beschrieben. Kopien entfernen, Server aus DAG raus, Platt machen (AD-Objekt NICHT löschen!!!!), Recovery-Setup, in DAG rein, Kopien hinzufügen.

    EDIT: Alternative: Neuen Server gleich auf dem Ziel-CU-Stand installieren, in die DAG, replizieren, usw., den alten sterben lassen. Wenn Deine Exchange-Installation zu 100% geskriptet ist, ist es praktikabel, sonst vergisst man meistens irgendwelche Dinge.


    Evgenij Smirnov

    http://evgenij.smirnov.de


    Montag, 13. April 2020 10:58

Alle Antworten

  • Moin,

    ein DAG-Mitglied irgendwie wiederherstellen klappt in den allerwenigsten Fällen. Andererseits habe ich schon länger keine CU-Installationen mehr gesehen, die so richtig schief gegangen sind. Meistens hat man .NET vergessen, den Virenscanner angelassen, die AD-Replikation nicht abgewartet oder Ähnliches, Layer 8-Fehler also. Sollte es tatsächlich böse knallen, so ist der einzige supportete Weg DAG auflösen, Recovery-Installation, DAG wieder instantiieren. Wenn sich an den DBs in der Zeit nicht allzuviel geändert hat, gelingt es oft sogar ohne Re-Seeding.

    Ein richtiges Schwenken a la Load Balancer ist mit Round Robin nicht wirklich möglich, aber man kann dem näher kommen als bloss alle Datenbanken auf dem anderen Server zu aktivieren. Hier ein paar Ansätze, alles freilich kein Allheilmittel, aber in Kombination kann es durchaus helfen:

    1. Component States. Nachdem man die Datenbanken geschwenkt hat, sollte man, bevor man mit der Wartung beginnt, auf dem zu wartenden Server auch die Webservices tatsächlich auf "down" setzen (Set-ServerComponentState ist Dein Freund, die gesuchte Komponente heißt ServerWideOffline). Nicht vergessen, nach der Wartung wieder zurückzudrehen! 
    2. Round Robin für die Wartung tatsächlich auflösen. Es ist unglücklich, dass man einen DNS-Record nicht deaktivieren kann, aber Dein Maintenance-Skript kann ja den Record für den zu wartenden Server löschen und dann wieder anlegen. Wichtig ist, dass man bereits vor der Wartung die TTL für die RR-Records deutlich heruntersetzt, so dass die Clients gezwungen sind, zeitig nochmal zu fragen.

    Über einen Load Balancer kannst Du auch nachdenken. Es muss ja nicht gleich ein Netscaler sein, und Du brauchst ja auch kein SSL-Offload oder Ähnliches. Seit Exchange 2013 ist es sehr einfach, ein L4-HTTPS-Loadbalancing mit Exchange zu betreiben. Eine ZEVENET-Appliance ist kostenlos und in wenigen Minuten als VM aufgesetzt. Damit kannst Du sogar - ebenfalls kostenlos - ein Load Balancer-Cluster aufsetzen und auch Deinen Load Balancer ohne Downtime patchen und warten. Auch andere Projekte wie pfSense  können inzwischen einfaches Load Balancing.

    Oder, wenn Deine Infrastruktur nicht sehr groß ist, kannst Du von KEMP einen Free LoadMaster installieren. Die Limitierungen gegenüber der Vollversion sind:

    • kein Clustering
    • kein Support
    • Lizenz muss 1x pro Monat durch Nach-Hause-Telefonieren validiert werden
    • Bandbreitenbeschränkung auf 20 Mbps

    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert Dont - Worry Montag, 13. April 2020 11:20
    Montag, 13. April 2020 09:33
  • Evgenij

    danke für die Information.

    ein DAG-Mitglied irgendwie wiederherstellen klappt in den allerwenigsten Fällen....

    was macht man dann in so einem Fall?

    AV war aus und Framework war 4.8.

    Set-ServerComponentState ntsex1 -Component ServerWideOffline -State Inactive -Requester Maintenance

    ist im Script vorhanden.

    DNS ist überlegenswert. Werde ich mir demnächst ansehen.

    Montag, 13. April 2020 10:53

  • was macht man dann in so einem Fall?

    wie oben kurz beschrieben. Kopien entfernen, Server aus DAG raus, Platt machen (AD-Objekt NICHT löschen!!!!), Recovery-Setup, in DAG rein, Kopien hinzufügen.

    EDIT: Alternative: Neuen Server gleich auf dem Ziel-CU-Stand installieren, in die DAG, replizieren, usw., den alten sterben lassen. Wenn Deine Exchange-Installation zu 100% geskriptet ist, ist es praktikabel, sonst vergisst man meistens irgendwelche Dinge.


    Evgenij Smirnov

    http://evgenij.smirnov.de


    Montag, 13. April 2020 10:58
  • danke für die Antwort.

    Installation ist leider nicht gescriptet. Beide Variante klingen sehr Zeitaufwendig. Da kann man nur hoffen das man mit dem einen noch weiterarbeiten kann bis man einen Neuen aufgesetzt und konfiguriert hat.

    Montag, 13. April 2020 11:20
  • Evgenij

    was hälst du von einem vollständigen VMWare Clone? max. 1 Tag Alt. Das müsste doch auch gehen?

    Montag, 13. April 2020 15:32
  • was hälst du von einem vollständigen VMWare Clone? 

    Nix. Die Config eines Exchange Servers steht nahezu vollständig im AD. Wenn die Daten im OS und im AD divergieren, hast Du eine noch blödere Situation als bei einem fehlgeschlagenen CU. Außerdem ist es ganz explizit unsupported.



    Evgenij Smirnov

    http://evgenij.smirnov.de


    Montag, 13. April 2020 16:32
  • Evgenij,

    entschuldige bitte wenn ich nochmals hier nachfrage, kann aber gerne einen neuen Thread eröffnen.

    Hast du zufällig eine Anleitung was zu tun ist wenn man einen neuen Exchange setup /m aufsetzt. Im Internet gibt es gute Anleitungen. Was mir jedoch unklar ist, wäre der alte Server.

    Mir ist bewußt: Es hängt natürlich davon ab was alles nicht mehr geht.

    Vorgangsweise:

    ich nehem an bevor der neue aufgesetzt wird muss man am zweiten funktionierenden die DB copies auflösen

    Remove-MailboxDatabaseCopy -Identity DB1\MBX1 -Confirm:$False
    Check!
    Get-MailboxDatabase <DatabaseName> | Format-List DatabaseCopies

    alten Server aus DAG nehmen

    Remove-DatabaseAvailabilityGroupServer -Identity DAG3 -MailboxServer MBX1

    Exchange am alten deinstallieren?

    AD - Reset a Computer Account (sollte ja eigentlich durch die Neuinstallation gleicher Name überschrieben werden)

    Neuen Server mit Setup /m aufsetzen

    Zertifikat einspielen

    eigene Receive Connetor neu erstellen

    Server in DAG aufnehmen

    wie kommen die zig TB DB-Daten wieder auf den neuen Server? Müssen die vom bestehen mittels DB Copy neu übertragen werden? das kann ja je nach Größe extrem lang dauern. TB sicher ein paar Tage? Bei uns wäre die DBs auf einer eigenen Platte und die könnte innerhalb die VMWare wieder leicht auf den neuen Server gemappt werden. Aber meines Wissen geht das nicht.

    Dienstag, 14. April 2020 13:23
  • Moin,

    nein, mit einer Anleitung, die alle möglichen Eigenarten abdeckt, kann ich nicht dienen. Aber hier zum Verständnis:

    Der Recovery Mode geht davon aus, dass der alte Server gestorben ist, und genau so ist er zu behandeln:

    1. Hart ausschalten, Systemplatte wegschmeißen, AD-Account zurücksetzen.
    2. Danach die DB-Kopien und den Server aus der DAG entfernen (-ConfigurationOnly ist Dein Freund).
    3. Server neu aufsetzen und ins AD aufnehmen.
    4. Zertifikat wieder einspielen, Datenplatten mit den alten Pfaden einbinden.
    5. Exchange im Recovery Mode installieren. An dieser Stelle sollte alles, was nicht DAG-spezifisch war, wiederhergestellt sein, denn wie oben geschrieben, die Konfig ist im AD gespeichert.
    6. Falls Anpassungen an web.config-Files vorgenommen wurden, diese nachziehen
    7. Server in die DAG aufnehmen
    8. Datenbankkopien hinzufügen. Es *könnte* sein, dass Du nicht re-seeden musst. Aber, wie unsere amerikanischen Freunde sagen, YMMV ;-)


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 14. April 2020 14:14