none
Wartung von Exchange DAG und CAS-Array RRS feed

  • Frage

  • Hallo Community,

    bei uns steht ein Update der Exchangeserver an.

    Wir betreiben 4 Server im DAG / CAS-Array mit NLB

    Server 1 CAS / HUB

    Server 2 CAS / HUB

    Server 3 DAG Cluster

    Server 4 DAG Cluster

    In der Vergangeheit ist es immer wieder vorgekommen, dass Clients, die während des Updates verbunden waren, danach Probleme mit dem Zugriff auf das CAS-Array hatten.

    Dies ging sogar soweit, dass Outlook Pofile neu eingerichtet werden mussten.

    Clients = Outlook 2007

    Durch 24/7 Betrieb haben wir leider kein dediziertes Wartungsfenster.

    Kann man aktive Clients vor dem Update vom sauber CAS trennen z.B. durch beenden des RPC Client Access Service?

    Wie würdet Ihr bei dem Update vorgehen?

    Danke schon einmal für Eure Anregungen.

    Freitag, 14. September 2012 11:56

Antworten

  • Du kannst im NLB doch einen Knoten in "Wartung" setzen. Dann verbindet sich kein Client mehr mit dem CAS Server. Geht imho über das CMDlet Suspend-NLBClusterNode oder halt Stop-NLBClusterNode

    Gruß

    Jörg

    • Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
    • Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
    Freitag, 14. September 2012 14:37
  • Hallo T.Pustal,

    wie Joerg geschrieben hat - fuer die CAS im NLB, die Knoten anhalten. Fuer die DAG Knoten solltest Du wie unter http://technet.microsoft.com/en-us/library/dd298065.aspx beschrieben, die StartDagServerMaintenance.ps1 und StopDagServerMaintenance.ps1 Skripte verwenden:

    Installing Microsoft Exchange Server 2010 update rollups on a server that is a member of a database availability group (DAG) is a relatively straightforward process. When you install an update rollup on a server that's a member of a DAG, several services are stopped during the installation, including all Exchange services and the Cluster service. The general process for applying update rollups to a DAG member is as follows:

      • Use the StartDagServerMaintenance.ps1 script to put the DAG member in maintenance mode.
      • Install the update rollup.
      • Use the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance mode and put it back into production.
      • Use the RedistributeActiveDatabases.ps1 script to rebalance the active database copies across the DAG.

    Viele Gruesse

    Timo

    • Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
    • Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
    Sonntag, 16. September 2012 08:01

Alle Antworten

  • Du kannst im NLB doch einen Knoten in "Wartung" setzen. Dann verbindet sich kein Client mehr mit dem CAS Server. Geht imho über das CMDlet Suspend-NLBClusterNode oder halt Stop-NLBClusterNode

    Gruß

    Jörg

    • Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
    • Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
    Freitag, 14. September 2012 14:37
  • Hallo T.Pustal,

    wie Joerg geschrieben hat - fuer die CAS im NLB, die Knoten anhalten. Fuer die DAG Knoten solltest Du wie unter http://technet.microsoft.com/en-us/library/dd298065.aspx beschrieben, die StartDagServerMaintenance.ps1 und StopDagServerMaintenance.ps1 Skripte verwenden:

    Installing Microsoft Exchange Server 2010 update rollups on a server that is a member of a database availability group (DAG) is a relatively straightforward process. When you install an update rollup on a server that's a member of a DAG, several services are stopped during the installation, including all Exchange services and the Cluster service. The general process for applying update rollups to a DAG member is as follows:

      • Use the StartDagServerMaintenance.ps1 script to put the DAG member in maintenance mode.
      • Install the update rollup.
      • Use the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance mode and put it back into production.
      • Use the RedistributeActiveDatabases.ps1 script to rebalance the active database copies across the DAG.

    Viele Gruesse

    Timo

    • Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
    • Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
    Sonntag, 16. September 2012 08:01
  • Hi,

    ich kopier mal Roberts Anwort zu einem anderen Thread kurz rein:
     Die Frage ist falsch: Was ist bei WNLB schlecht:
     - Source-IP Affinität (also kein wirkliches LB)
     - schlechtes Zusammenspiel mit Routern (eventueli Multi-Cast-Stürme)
     - keine Erkennung von Diensten (z.B. musst Du bei RU-Installation manuell auf dem LB schwenken, weil der das Deaktivieren der Dienst nicht mitbekommt)


    Viele Grüße
    Christian

    • Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
    Montag, 17. September 2012 17:53
    Moderator
  • Danke für die Rückmeldungen!

    Damit können wir jetzt einen Wartung sauber planen.

    Gruß,

    Tobias

    Donnerstag, 20. September 2012 12:16