Lektionen aus dem Rechenzentrum: Verwaltete Verfügbarkeit

Veröffentlichung des Originalartikels: 22.09.2012

Überwachung ist eine der Hauptkomponenten für eine erfolgreiche Bereitstellung von Exchange. In vorherigen Versionen haben wir umfassend in die Entwicklung eines Korrelationsmoduls investiert und eng mit der SCOM-Produktgruppe (System Center Operations Manager) zusammengearbeitet, um eine umfassende Warnlösung für Exchange-Umgebungen zu ermöglichen.

Üblicherweise umfasste die Überwachung das Erfassen von Daten und bei Bedarf das Anwenden einer Aktion basierend auf den erfassten Daten. Im SCOM-Kontext wurden verschiedene Mechanismen verwendet, um Daten mithilfe des Exchange Management Pack zu erfassen:

Überwachungsziele für Exchange Server 2013

Als wir mit der Entwicklung von Exchange 2013 begannen, war ein Hauptschwerpunkt die Verbesserung der Überwachung von A-Z aller Exchange-Bereitstellungen: von der kleinsten lokalen Bereitstellung mit zur weltweit größten Bereitstellung – Office 365. Dabei hatten wir drei Ziele vor Augen:

1. Unsere Kompetenz und Erfahrung mit Office 365 Benutzern lokaler Lösungen zur Verfügung stellen Seit knapp 6 Jahren betreibt die Exchange-Programmgruppe Exchange Online. Das Betriebsmodell, das wir nutzen, wird als DevOps-Modell bezeichnet. In diesem Modell werden Probleme direkt an den Entwickler eines Features eskaliert, wenn sein Feature im Dienst eine schlechte Leistung bietet oder wenn ein Kunde ein unbekanntes Problem meldet, das eskaliert wird. Ungeachtet der Problemursache bringt eine direkte Eskalation an den Entwickler ein Verantwortungsgefühl für die Entwicklung der Software, das durch Beheben der Softwarefehler zum Ausdruck kommt.

   Dank dieses Modells haben wir viel gelernt. Im Exchange 2010 Management Pack gab es beispielsweise nahezu 1100 Warnungen. Mit der Zeit haben wir herausgefunden, dass nur ca. 150 dieser Warnungen für Office 365 sinnvoll sind (weshalb wir den Rest deaktiviert haben). Darüber hinaus fanden wir heraus, dass wenn Entwickler eine Eskalation empfangen, sie sich zuständiger fühlen und sich um die Behebung des Problems kümmern (entweder durch eine Codekorrektur, neue Wiederherstellungsworkflows, durch Optimierung der Warnung usw.), da sie nicht fortlaufend unterbrochen oder geweckt werden möchten, um dasselbe Problem immer wieder aufs Neue zu beheben. Im DevOps-Modell gibt es im Bereitschaftsdienst eine Übergabebesprechung, in der die Vorfälle der letzten Woche behandelt werden. Das Ergebnis ist, dass interne Wiederherstellungsworkflows entwickelt werden, z. B. Zurücksetzen der IIS-Anwendungspools usw. Vor Exchange 2013 hatten wir ein internes Modul, mit dem diese Wiederherstellungsworkflows abgewickelt wurden. Das Wissen darüber ist nie in die lokalen Produktversionen gelangt. Bei Exchange 2013 haben wir das Wiederherstellungsworkflow-Modul in Komponenten unterteilt, damit auch unsere Kunden der lokalen Version von diesen Erfahrungen profitieren können.

2. Auf der Endbenutzerumgebung basierende Überwachung Wir fanden auch heraus, dass viele unserer Methoden für die Überwachung uns beim Betrieb der Umgebung nicht wirklich halfen. Deshalb haben wir bei der Überwachung den Schwerpunkt auf die Kundensicht verlagert.

   In vorherigen Versionen entwickelte jedes für eine Komponente zuständige Team ein Integritätsmodell, das all die verschiedenen Komponenten im jeweiligen System berücksichtigte. Zum Transport gehören beispielsweise SMTP-IN, SMTP-OUT, Transport-Agents, Kategorisierungsmodul, Routingmodul, Speichertreiber usw. Das Komponententeam entwickelte anschließend Warnungen zu jeder dieser Komponenten. Im In-Place Management Pack gibt es Warnungen, die Sie informieren, dass der Speichertreiber fehlerhaft ist. Doch was fehlt, ist die Tatsache, dass die Warnung keine Informationen zur Endbenutzerumgebung liefert oder auf diese Umgebung zurückzuführen ist. Deshalb stellen wir in Exchange 2013 das Modell auf den Kopf. Die Überwachung auf Systemebene lassen wir nicht außer Acht, da sie wichtig ist. Doch was noch wichtiger ist, wenn Sie einen Dienst verwalten möchten, ist, was Ihre Benutzer sehen. Deshalb haben wir das Modell umgedreht und bemühen uns verstärkt, die Benutzerumgebung zu überwachen.

3. Schützen der Benutzerumgebung mithilfe von an der Wiederherstellung orientierten Verfahren Bei den bisherigen Versionen von Exchange konzentrierte sich die Überwachung auf das System und Komponenten und nicht darauf, wie die Endbenutzerumgebung automatisch wiederhergestellt werden kann.

Überwachen von Exchange Server 2013 – Verwaltete Verfügbarkeit

"Verwaltete Verfügbarkeit" ist eine Überwachungs- und Wiederherstellungsinfrastruktur, die in die Hochverfügbarkeitslösung von Exchange integriert ist. Diese Infrastruktur sorgt dafür, dass Probleme, sobald sie auftreten und erkannt werden, behoben werden.

Bei der verwalteten Verfügbarkeit liegt der Schwerpunkt auf dem Benutzer. Wir wollen drei Hauptaspekte messen: die Verfügbarkeit, die Umgebung (die bei den meisten Clientprotokollen als Latenz gemessen wird) und das Auftreten von Fehlern. Anhand eines Beispiels, ein mit Outlook Web App (OWA) arbeitender Benutzer, wollen wir diese drei Aspekte veranschaulichen.

Der Verfügbarkeitsaspekt ist lediglich, ob die Benutzer auf die Webseite für die formularbasierte Authentifizierung von OWA zugreifen können. Falls nicht, ist die Umgebung gestört, woraufhin eine Eskalation an das Helpdesk erfolgt. Wenn sie sich, was die Umgebung angeht, bei OWA anmelden können: Wie sieht die Umgebung aus? Wird die Oberfläche geladen? Kann der Benutzer auf seine E-Mail zugreifen? Der letzte Aspekt ist Latenz. Der Benutzer kann sich anmelden und auf die Oberfläche zugreifen, doch wie schnell wird die E-Mail im Browser gerendert? Dies sind die Bereiche, die die Endbenutzerumgebung ausmachen.

Ein Hauptunterschied zwischen Vorgängerversionen und Exchange 2013 ist, dass unsere Überwachungslösung in Exchange 2013 nicht versucht, die Problemursache zu liefern (was nicht bedeutet, dass die Daten nicht in Protokollen aufgezeichnet, keine Sicherungen generiert werden oder die Grundursache nicht ermittelt werden kann). Wichtig ist der Hinweis, dass wir bei bisherigen Versionen nie besonders effektiv beim Vermitteln der Ursache waren, denn wird lagen häufiger falsch als richtig.

Komponenten der verwalteten Verfügbarkeit

Verwaltete Verfügbarkeit ist in beide Serverrollen von Exchange 2013 integriert und schließt drei primäre asynchrone Komponenten ein. Die erste Komponente ist das Testmodul, das für Messungen auf dem Server zuständig ist. Dessen Ergebnisse fließen in die zweite Komponente, den Monitor. Der Monitor enthält die Geschäftslogik zum Codieren, was wir als fehlerfrei halten. Sie können sich den Monitor als Mustererkennungsmodul vorstellen. Es erfolgt eine Suche nach unterschiedlichen Mustern in den verschiedenen erfassten Messungen. Anschließend wird eine Entscheidung getroffen, was als fehlerfrei eingestuft wird und was nicht. Die dritte Komponente ist das Respondermodul, das ich im folgenden Diagramm mit "Recover" beschriftet habe. Wenn etwas nicht fehlerfrei arbeitet, ist die erste Aktion der Versuch, diese Komponente wiederherzustellen. Zur verwalteten Verfügbarkeit zählen mehrstufige Wiederherstellungsaktionen. Der erste Versuch ist ggf. der Neustart des Anwendungspools, der zweite Versuch der Neustart des Diensts und der dritte Versuch der Neustart des Servers. Auf der letzten Stufe wird der Server ggf. offline geschaltet, damit er keinen Datenverkehr mehr annimmt. Wenn diese Versuche keinen Erfolg haben, sieht die verwaltete Verfügbarkeit die Eskalation des Problems über eine Ereignisprotokollbenachrichtigung an einen Mitarbeiter vor.

Ihnen wird vielleicht auch auffallen, dass wir einige Dinge dezentralisiert haben. Bislang befand sich der SCOM-Agent auf allen Servern, von wo aus alle Messungen an einen zentralen SCOM-Server übertragen wurden. Der SCOM-Server wertete dann alle Messungen aus, um zu bestimmen, ob eine Komponente fehlerfrei arbeitet oder nicht. In großen Umgebungen kommt es dadurch zu komplexen Korrelationsvorgängen. Wir stellten fest, dass das Auslösen von Warnungen usw. länger dauerte. Für das Übertragen sämtlicher Messungen an eine Zentrale war keine Skalierung möglich. Stattdessen fungierte jeder einzelne Server als Insel – mit eigenem Test-, Überwachungs- und Respondermodul und bei Bedarf auch mit Eskalation im eigenen isolierten Umfeld.

Abbildung 1: Komponenten für die verwaltete Verfügbarkeit

Tests

Die Testinfrastruktur besteht aus drei getrennten Strukturen:

1. Tests sind synthetische Transaktionen, die von den Teams der einzelnen Komponenten entwickelt werden, und ähneln Test-Cmdlets in vorherigen Versionen. Bei Tests wird die Wahrnehmung des Diensts durch Ausführung synthetischer Benutzertransaktionen von A bis Z gemessen.
2. Überprüfungen sind ein passiver Überwachungsmechanismus und dienen zum Messen des tatsächlichen Kundendatenverkehrs.
3. Die Benachrichtigungsstruktur ermöglicht es uns, Maßnahmen sofort zu ergreifen, ohne die Ausführung eines Tests abwarten zu müssen. Wenn wir einen Fehler erkennen, können wir also unmittelbar in Aktion treten. Benachrichtigungen sind das zentrale Element dieser Struktur. Wenn beispielsweise ein Zertifikat abläuft, wird ein Benachrichtigungsereignis ausgelöst, über das das Betriebsteam informiert wird, dass das Zertifikat verlängert werden muss.

Monitore

Die bei Tests erfassten Daten werden in Monitore eingespeist. Es gibt nicht unbedingt eine 1:1-Beziehung zwischen Tests und Monitoren. Viele Tests können Daten in einen einzelnen Monitor einspeisen. Monitore untersuchen die Ergebnisse von Tests und kommen zu einem binären Ergebnis: fehlerfrei oder nicht fehlerfrei.

Wie bereits erwähnt, liegt der Schwerpunkt der Exchange 2013-Überwachung auf der Endbenutzerumgebung. Zu diesem Zweck muss auf verschiedenen Ebenen der Umgebung eine Überwachung erfolgen.

Abbildung 2: Überwachung auf mehreren Ebenen zur Überprüfung der Benutzerumgebung

Wie Sie anhand des Diagramms erkennen können, gibt es vier verschiedene Überprüfungen. Die erste Überprüfung ist der Postfachselbsttest, bei dem geprüft wird, ob das lokale Protokoll bzw. die lokale Schnittstelle auf die Datenbank zugreifen kann. Bei der zweiten Überprüfung, dem Protokollselbsttest, wird geprüft, ob das lokale Protokoll auf dem Postfachserver funktioniert. Die dritte Überprüfung, der Proxyselbsttest, wird auf dem Clientzugriffsserver ausgeführt und untersucht, ob die Proxyfunktionalität für das Protokoll einwandfrei ist. Bei der allumfassenden vierten und letzten Überprüfung wird die Umgebung von A bis Z analysiert (von den Protokollproxy- bis zu den Speicherfunktionen). Bei jeder Überprüfung erfolgt eine Erkennung in verschiedenen Intervallen.

Aufgrund von Abhängigkeiten erfolgt eine Überwachung auf verschiedenen Ebenen. Da es in Exchange 2013 kein Korrelationsmodul gibt, versuchen wir, unsere Abhängigkeiten mithilfe eindeutiger Fehlercodes zu differenzieren, die verschiedenen Tests sowie Tests entsprechen, die sich nicht auf geltende Abhängigkeiten beziehen. Was bedeutet es beispielsweise, wenn ein Postfachselbsttest und Protokollselbsttest gleichzeitig fehlschlagen? Heißt das, dass der Speicher ausgefallen ist? Nicht unbedingt, denn was Sie erfahren ist, dass die lokale Protokollinstanz auf dem Postfachserver nicht funktioniert. Was bedeutet es, wenn ein Protokollselbsttest Erfolg hat, aber ein Postfachselbsttest fehlschlägt? Dieses Szenario sagt Ihnen, dass es ein Problem mit der Speicherebene gibt, was tatsächlich bedeuten kann, dass der Speicher oder die Datenbank offline ist.

Aus Sicht der Überwachung bedeutet dies, dass wir nun präziser steuern können, welche Warnungen ausgelöst werden. Wenn wir beispielsweise die Integrität von OWA überprüfen, werden wir das Auslösen einer Warnung im Szenario mit einem fehlgeschlagenen Postfachselbsttest, aber funktionierenden Protokollselbsttest eher verzögern. Eine Warnung wird hingegen ausgelöst, wenn sowohl der Postfachselbsttest als auch der Protokollselbsttest Fehler zurückgeben.

Responder

Responder führen Reaktionen basierend auf Warnungen aus, die von einem Monitor generiert werden. Responder werden stets nur ausgeführt, wenn ein Monitor fehlerhaft ist.

Es stehen mehrere Typen von Respondern zur Verfügung:

• Responder für Neustart  Beendet den Dienst und startet ihn neu.
• Responder zum Zurücksetzen des Anwendungspools  Setzt den IIS-Anwendungspool zurück.
• Responder für Failover  Setzt einen Exchange 2013-Postfachserver außer Betrieb.
• Responder für Fehlerprüfung   Löst eine Prüfung des Servers auf Fehler aus.
• Offline-Responder  Setzt ein Protokoll auf einem Computer außer Betrieb.
• Responder für Eskalation  Eskaliert ein Problem.
• Responder für Spezialkomponenten 

Der Offline-Responder dient dazu, ein Protokoll auf dem Clientzugriffsserver außer Betrieb zu nehmen. Dieser Responder ist lastenausgleichsneutral konzipiert. Beim Aufruf dieses Responders bestätigt das Protokoll nicht die Lastenausgleichs-Integritätsprüfung. Dadurch kann das Lastenausgleichsmodul den Server oder das Protokoll aus dem Lastenausgleichspool entfernen. Gleichermaßen gibt es einen entsprechenden Online-Responder, der automatisch ausgelöst wird, sobald der entsprechende Monitor wieder fehlerfrei ist (vorausgesetzt, es gibt keine anderen dazugehörigen Monitore mit einem fehlerhaften Status). Der Online-Responder erlaubt dem Protokoll, auf die Lastenausgleichs-Integritätsprüfung zu reagieren, wodurch das Lastenausgleichsmodul den Server oder das Protokoll dem Lastenausgleichspool wieder hinzufügen kann. Der Offline-Responder kann auch manuell über das Cmdlet Set-ServerComponentState aufgerufen werden. Dadurch können Administratoren Clientzugriffsserver manuell in den Wartungsmodus versetzen.

Beim Aufruf des Responders für Eskalation wird ein Windows-Ereignis generiert, das vom Exchange 2013 Management Pack erkannt wird. Dies ist kein normales Exchange-Ereignis. Es ist kein Ereignis, das besagt, dass OWA ausgefallen oder ein "harter" E/A-Fehler aufgetreten ist. Es handelt sich um ein Exchange-Ereignis, das besagt, dass der Integritätsstatus fehlerhaft oder fehlerfrei ist. Wir verwenden Einzelinstanzereignisse wie diese, um die Monitore in SCOM zu ändern. Und wir tun dies basierend auf einem Ereignis, das im Responder für die Eskalation generiert wurde, im Gegensatz zu Ereignissen, die auf das gesamte Produkt verteilt sind. Eine weitere Möglichkeit ist, sich dies als eine Ebene der Dereferenzierung vorzustellen. Das System der verwalteten Verfügbarkeit entscheidet, wann wir einen Monitor in SCOM umschalten und wann eine Eskalation erfolgen soll, d. h. wann ein Mitarbeiter eingeschaltet werden soll.

Responder können auch eingeschränkt werden, um sicherzustellen, dass der gesamte Dienst nicht gefährdet wird. Je nach Responder erfolgt die Einschränkung unterschiedlich:

• Einige Responder berücksichtigen die Mindestanzahl von Servern in der Datenbankverfügbarkeitsgruppe (DAG) oder im Clientzugriffsserver-Pool mit Lastenausgleich.
• Einige Responder berücksichtigen die Dauer zwischen Ausführungen.
• Einige Responder berücksichtigen, wie oft der Responder ausgelöst wurde.
• Einige verwenden eine beliebige Kombination dieser Einschränkungen.

Wenn eine Einschränkung erfolgt, kann je nach Responder dessen Aktion verzögert oder einfach ausgelassen werden.

Wiederherstellungssequenzen

Wichtig ist der Hinweis, dass die Monitore die Typen der Responder, die ausgeführt werden, und den Zeitrahmen bestimmen, in denen diese ausgeführt werden. Dies wird von uns als Wiederherstellungssequenz für einen Monitor bezeichnet. Angenommen, die Testdaten für das OWA-Protokoll (den Protokollselbsttest) lösen aus, dass der Monitor einen Fehler meldet. An dieser Stelle wird die aktuelle Uhrzeit gespeichert (die wir als Z bezeichnen). Der Monitor startet die Wiederherstellungssequenz, die auf der aktuellen Uhrzeit basiert. In der Wiederherstellungssequenz kann der Monitor Wiederherstellungsaktionen in festgelegten Zeitintervallen definieren. Beim Monitor für das OWA-Protokoll auf dem Postfachserver ist die Wiederherstellungssequenz wie folgt:

1. Bei Z=0 wird der Responder zum Zurücksetzen des IIS-Anwendungspools ausgeführt.
2. Wenn bei Z=5 Minuten der Monitor nicht wieder einen fehlerfreien Status hat, wird der Responder für Failover ausgelöst, und Datenbanken werden vom Server entfernt.
3. Wenn bei Z=8 Minuten der Monitor nicht wieder einen fehlerfreien Status hat, wird der Responder für Fehlerprüfung ausgelöst und ein Neustart des Servers erzwungen.
4. Wenn bei Z=15 Minuten der Monitor immer noch nicht wieder einen fehlerfreien Status hat, wird der Responder für Eskalation ausgelöst.

Die Wiederherstellungssequenz wird beendet, wenn der Monitor wieder einen fehlerfreien Status hat. Beachten Sie, dass die zuletzt genannte zeitbezogene Aktion nicht abgeschlossen sein muss, ehe die nächste startet. Darüber hinaus kann ein Monitor eine beliebige Anzahl benannter Zeitintervalle aufweisen.

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (SCOM) dient als Portal zum Anzeigen von Statusinformationen zur Exchange-Umgebung. Fehlerhafte Status im SCOM-Portal werden von Ereignissen ausgelöst, die über den Responder für Eskalation in das Protokoll Anwendung geschrieben werden. Das SCOM-Dashboard wurde optimiert und hat nun drei Hauptbereiche:

• Aktive Warnungen
• Organisationsintegrität
• Serverintegrität

Das Exchange Server 2013 SCOM Management Pack wird von SCOM 2007 R2 und SCOM 2012 unterstützt.

Korrekturen

Wie bei jeder Umgebung sind Standardeinstellungen nicht immer optimal, oder besondere Bedingungen können ein sofortiges Handeln erforderlich machen. Das System der verwalteten Verfügbarkeit ermöglicht Korrekturen für die gesamte Umgebung oder einen einzelnen Server. Korrekturen können für eine bestimmte Dauer festgelegt oder für eine bestimmte Version des Servers gelten. Die Cmdlets *-ServerMonitoringOverride und GlobalMonitoringOverride ermöglichen Administratoren das Festlegen, Entfernen und Anzeigen von Korrekturen.

Bestimmung der Integrität

Monitore, die ähnlich oder an die Architektur einer bestimmten Komponente gebunden sind, werden zu Integritätssätzen zusammengefasst. Die Integrität eines Integritätssatzes wird stets anhand der Integrität der Monitore im Satz bestimmt. Wenn beispielsweise von 9 Monitoren in einem Integritätssatz einer fehlerhaft ist, dann gilt der gesamte Integritätssatz als fehlerhaft. Mit dem Cmdlet Get-MonitoringItemIdentity können Sie die Zusammenstellung der Monitore (und dazugehörigen Tests und Responder) in einem bestimmten Integritätssatz bestimmen.

Die Cmdlets Get-ServerHealth und Get-HealthReport dienen zum Anzeigen der Integrität. Get-HealthReport wird auf die unformatierten Integritätsdaten angewendet und liefert eine aktuelle Momentaufnahme der Integrität. Diese Cmdlets können auf mehreren Ebenen ausgeführt werden:

• Sie können die Integrität eines bestimmten Servers mithilfe einer Gliederung nach Integritätssatz anzeigen.
• Sie ermöglichen eine Detailsuche in einem bestimmten Integritätssatz und das Anzeigen des Status der einzelnen Monitore.
• Sie können zum Zusammenfassen der Integrität eines bestimmten Satzes von Servern (DAG-Mitglieder oder Array von Clientzugriffsservern mit Lastenausgleich) genutzt werden.

Integritätssätze werden weiter in Funktionseinheiten unterteilt, die als Integritätsgruppen bezeichnet werden. Es gibt vier Integritätsgruppen, die zum Erstellen von Berichten im SCOM-Verwaltungsportal verwendet werden:

1. Kundenberührungspunkte – Komponenten mit direkter Interaktion mit Kunden in Echtzeit (z. B. OWA)
2. Dienstkomponenten – Komponenten ohne direkte Interaktion mit Kunden in Echtzeit (z. B. OAB-Erstellung)
3. Serverkomponenten – Physische Ressourcen eines Servers (z. B. Datenträger, Arbeitsspeicher).
4. Verfügbarkeit abhängiger Komponenten – Die Fähigkeit des Servers, abhängige Komponenten abzufragen (z. B. Active Directory).

Schlussfolgerung

Im Rahmen der verwalteten Verfügbarkeit erfolgen auf jedem Server verschiedene Integritätsprüfungen. Bei diesen regelmäßigen Tests wird die Einsatzbereitschaft verschiedener Komponenten auf dem Server getestet, wodurch die Integrität des Servers (oder der Servergruppe) vor und während der Verarbeitung von Benutzeranforderungen bestimmt wird. Sobald Probleme erkannt werden, erfolgen mehrstufige korrigierende Maßnahmen, um den Server wieder einen funktionsfähigen Zustand zu versetzen. Sollte dies nicht möglich sein, kann im Rahmen der verwalteten Verfügbarkeit ein zuständiger Mitarbeiter benachrichtigt werden.

Die Quintessenz ist, dass bei der verwalteten Verfügbarkeit der Schwerpunkt auf der Benutzerumgebung liegt und sichergestellt ist, dass bei Auftreten von Problemen die Umgebung nur minimal, falls überhaupt, beeinträchtigt wird.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Lessons from the Datacenter: Managed Availability