Hochverfügbarkeit und Notfallwiederherstellung

Wichtig

Diese Version von Operations Manager hat das Ende des Supports erreicht. Es wird empfohlen, ein Upgrade auf Operations Manager 2022 durchzuführen.

System Center: Operations Manager-Server und -Features können möglicherweise fehlschlagen, was sich auf die Operations Manager-Funktionalität auswirkt. Wie stark der Daten- oder Funktionalitätsverlust während eines Ausfalls ist, hängt vom jeweiligen Ausfallszenario ab. Dies hängt von der Rolle des fehlerhaften Features und der Dauer der Wiederherstellung des fehlerhaften Features ab.

Hohe Verfügbarkeit

Um Anforderungen an die Hochverfügbarkeit zu erfüllen, muss für folgende Komponenten Redundanz in die Verwaltungsgruppe implementiert werden: Betriebs- und Data Warehouse-Datenbanken von Operations Manager, Gateway- und Verwaltungsserver sowie bestimmte Arbeitsauslastungen. Zu den Arbeitsauslastungen gehören die Überwachung von Netzwerkgeräten, die plattformübergreifende Überwachung sowie Arbeitsauslastungen speziell für die Verwaltungsgruppe, die zuvor vom Stammverwaltungsserver verwaltet wurden.

Bei einer Konfiguration mit mehreren Servern in einer einzelnen Verwaltungsgruppe können die Always On-Funktionen von SQL Server genutzt werden, um Hochverfügbarkeit und Dienstkontinuität für die Operations Manager-Datenbanken bereitzustellen. Die Fehlertoleranz der Verwaltungsserver lässt sich durch Bereitstellung von mindestens zwei Verwaltungsservern und durch Nutzung von Ressourcenpools für die Überwachung von UNIX- und Linux-Servern sowie Netzwerkgeräten erreichen. Agent-basierte Windows-Server können mit einem primären und einem sekundären Verwaltungsserver konfiguriert werden, um die Agent-Kommunikation umzuleiten, falls ein Verwaltungsserver ausfällt.

Der Emulator für Stammverwaltungsserver kann ebenfalls auf einen anderen Verwaltungsserver verschoben werden, falls der Verwaltungsserver, der den Emulator hostet, nicht verfügbar sein sollte.

Sie können Betriebskonsolenverbindungen hochverfügbar machen, indem Sie für die Datenzugriffsdienste Hochverfügbarkeit konfigurieren. Dies kann durch Installieren von Microsoft Network Load Balancing (NLB) oder mithilfe eines hardwarebasierten Lastenausgleichs oder eines DNS-Alias erfolgen. Dem NLB-Pool wird mindestens ein Verwaltungsserver hinzugefügt. Wenn Sie eine der Konsolen öffnen, verweisen Sie auf den in DNS registrierten virtuellen Namen der Verwaltungsserver mit Lastenausgleich.

Hinweis

Ein Netzwerk Load Balancer wird für den Operations Manager-Webkonsolenserver nicht unterstützt.

Es können mehrere Gatewayserver über eine Vertrauensgrenze hinweg bereitgestellt werden, um für Agents, die sich außerhalb dieser Vertrauensgrenze befinden, redundante Pfade zur Verfügung zu stellen. So wie für Agents ein Failover zwischen primärem Verwaltungsserver und einem oder mehreren sekundären Verwaltungsservern erfolgen kann, kann auch ein Failover zwischen verschiedenen Gatewayservern erfolgen. Darüber hinaus kann bei Verwendung mehrerer Gatewayserver die Arbeitslast verteilt werden, die beim Verwalten von Computern ohne Agent und beim Verwalten von Netzwerkgeräten entsteht.

Neben der Bereitstellung redundanter Pfade durch ein Agent-Gateway-Failover können Gatewayserver auch für ein Failover zwischen Verwaltungsservern in einer Verwaltungsgruppe konfiguriert werden, sofern mehrere Verwaltungsserver zur Verfügung stehen.

Während SQL Server Reporting Services ein Bereitstellungsmodell für horizontales Skalieren unterstützt, mit dem Sie mehrere Berichtsserverinstanzen ausführen können, die eine einzelne Berichtsserver-Datenbank gemeinsam nutzen, wird es mit Operations Manager nicht unterstützt. Operations Manager Reporting installiert eine benutzerdefinierte Sicherheitserweiterung als Teil des Setups der Front-End-Komponenten, die nicht über die Webfarm repliziert werden kann.

Notfallwiederherstellung

Bei der Notfallwiederherstellung geht es um Maßnahmen, mit denen sichergestellt wird, dass nach einem schwerwiegenden Ausfall (z. B. dem Verlust des gesamten Rechenzentrums, das die primäre Infrastruktur hostet) der Betrieb wieder aufgenommen werden kann. Es ist ein wichtiges Element, das bei jeder Bereitstellung berücksichtigt werden muss, und die Entscheidungen, die bei der Planung der Notfallwiederherstellung getroffen werden, beeinflussen, wie Operations Manager weiterhin die proaktive Überwachung und Berichterstellung der Leistung und Verfügbarkeit Ihrer kritischen IT-Dienste unterstützen kann. In diesem Abschnitt geht es um die empfohlene Strategie für die Ausfallsicherheit und die Notfallwiederherstellung und darum, welche Schritte erforderlich sind, um eine nahtlose Wiederherstellung zu gewährleisten.

Hochverfügbarkeits- und Notfallwiederherstellungslösungen bieten zwar Schutz vor Systemausfällen oder Systemverlusten, sollten aber nicht für den Schutz vor versehentlichem, unbeabsichtigtem oder böswilligem Datenverlust oder Beschädigung verwendet werden. In diesen Fällen müssen kopierte oder verzögerte Replikationskopien möglicherweise für Wiederherstellungsvorgänge verwendet werden. Wiederherstellungsvorgänge eignen sich häufig am besten für die Notfallwiederherstellung. Beispiele hierfür sind Berichtsdatenbanken oder Analysedaten mit geringer Priorität. In vielen Fällen übersteigen die Kosten für die Einrichtung einer Notfallwiederherstellung mehrerer Standorte auf System- oder Anwendungsebene bei Weitem den Wert der Daten. Wenn der kurzfristige Wert der Daten gering ist und die Wiederherstellung des Datenzugriffs nach einem schwerwiegenden Fehler oder Standortausfall ohne größere Auswirkungen auf das Geschäft verzögert werden kann, sollten Sie – sofern die Kosteneinsparungen dafürsprechen – einfache Sicherungs- und Wiederherstellungsprozesse für die Notfallwiederherstellung einrichten.

Eine genaue Kenntnis der Auswirkungen von Fehlern und der tolerierbaren Ausfallzeiten hilft dabei, die richtigen Entscheidungen zu treffen. Nur so können Sie die Architektur für Operations Manager optimal entwerfen und die Komplexität und Kosten für die Notfallwiederherstellung genau gegeneinander abwägen. Berücksichtigen Sie darüber hinaus, in welchem Umfang ein Datenverlust bei der Überwachung für die IT-Organisation tolerierbar ist, ohne dass dies geschäftliche Konsequenzen nach sich zieht. Diese Aspekte lassen sich am besten mit zwei Begriffen beschreiben: angestrebte Wiederherstellungszeit oder Recovery Time Objective (RTO) und angestrebter Wiederherstellungspunkt oder Recovery Point Objective (RPO).

Dies sind die beiden häufigsten Konfigurationen für die Notfallwiederherstellung für Operations Manager:

• Erstellen einer doppelten Verwaltungsgruppe, die in Ihrem sekundären Rechenzentrum bereitgestellt wird und die primäre Verwaltungsgruppe in Skalierung und Konfiguration dupliziert.
• Bereitstellen zusätzlicher Server in einem sekundären Rechenzentrum zur Unterstützung der Betriebs- und Data Warehouse-Datenbank. Hierbei werden die Verwaltungsserver in einer Konfiguration mit verzögerter Betriebsbereitschaft bereitgestellt und werden erst dann in die Verwaltungsgruppe eingefügt, wenn Wiederherstellungsaktionen ausgeführt werden müssen.

Das Bereitstellen einer doppelten Verwaltungsgruppe ist eine Option, wenn keine Toleranz für Ausfallzeiten besteht. Dies ist jedoch die komplexeste Option. Die Konfiguration zwischen beiden muss konsistent sein, sodass es bei der Übernahme keinen Unterschied gibt, was überwacht, benachrichtigt oder gemeldet, präsentiert und schließlich eskaliert wird. Die Integration mit anderen Überwachungsplattformen oder ITSM-Plattformen wie System Center – Service Manager, Remedy oder ServiceNow muss ebenfalls vorhanden sein und möglicherweise im Aktiv/Passiv-Zustand konfiguriert werden, um Duplizierungen von Vorfällen, Konfigurationselementen usw. zu vermeiden. Agents sind in beiden Verwaltungsgruppen vorhanden, daher liegen Daten doppelt vor.

Das folgende Diagramm zeigt ein Beispiel dieses Entwurfsszenarios.

Wenn eine sofortige Wiederherstellung für Ihre Operations Manager-Bereitstellung nicht erforderlich ist und Sie die Komplexität einer doppelten Verwaltungsgruppe vermeiden möchten, können Sie alternativ zusätzliche Verwaltungsgruppenkomponenten in Ihrem sekundären Rechenzentrum bereitstellen, um die Funktionalität Ihrer Verwaltungsgruppe beizubehalten. Sie sollten mindestens eine SQL Server 2014- oder 2016-Always On-Verfügbarkeitsgruppe implementieren, um für die Wiederherstellung der Betriebs- und Data Warehouse-Datenbanken zwischen mindestens zwei Rechenzentren zu sorgen. Hierzu gehört die Bereitstellung einer Failoverclusterinstanz mit zwei Knoten im primären Rechenzentrum und einer eigenständigen SQL Server-Instanz im sekundären Rechenzentrum im Rahmen eines einzelnen Windows Server-Failoverclusters. Hierbei ist das sekundäre Replikat für die Always On-Verfügbarkeitsgruppe die eigenständige Instanz, bei der es sich nicht um die Failoverclusterinstanz handelt, wie im folgenden Diagramm veranschaulicht.

In diesem Beispiel müssen Sie mindestens eine Windows Server-Instanz mit der gleichen Hardwarekonfiguration und dem gleichen Computernamen bereitstellen und die Verwaltungsserverrolle mithilfe des Parameters /Recover neu installieren. Hier ein Beispiel:

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

Weitere Informationen finden Sie unter Installieren von Operations Manager über die Eingabeaufforderung.

Während dieser Zeit stellen Agents die gesammelten Daten (Warnungen, Ereignisse, Leistung usw.) in die Warteschlange, bis sie die Kommunikation mit einem Verwaltungsserver in der Verwaltungsgruppe fortsetzen können. Bei dieser Vorgehensweise müssen Sie keine neuen SQL Server-Instanzen installieren und Datenbanken nicht aus der letzten als funktionierend bekannten Sicherung wiederherstellen. In diesem Wiederherstellungsszenario wird es jedoch wahrscheinlich zu einer längeren Verzögerung bei der Rückkehr zu einem funktionsfähigen Zustand kommen, da Sie die anderen Rollen bereitstellen müssen, die zum Fortsetzen der Mindestüberwachungsfunktionalität erforderlich sind. Wenn diese Vorgehensweise nicht akzeptabel ist, können Sie Verwaltungsserver im sekundären Rechenzentrum bereitstellen, um eine bedarfsbasierte Wiederherstellung zu gewährleisten. Entfernen Sie die Verwaltungsserver aus den drei primären Ressourcenpools: alle Verwaltungsserver, Benachrichtigungen und AD-Zuweisung. Hierzu gehören auch benutzerdefinierte Ressourcenpools, die im primären Rechenzentrum gehostete Verwaltungsserver umfassen und im Rahmen des Wiederherstellungsplans weiterhin funktionieren müssen. Der System Center-Datenzugriffsdienst, der System Center Configuration Manager und der Microsoft Monitoring Agent müssen beendet werden. Dann müssen diese Dienste auf „Manuell“ oder „Deaktiviert“ festgelegt werden und dürfen nur in einem Notfallwiederherstellungsszenario gestartet werden.

Wenn ein Verwaltungsserver die Integration unterstützt (über einen Connector, der direkt auf dem Verwaltungsserver oder von einem anderen System Center-Produkt wie VMM, Orchestrator oder Service Manager gehostet wird), muss dies abhängig von der Integrationskonfiguration und der Reihenfolge der Wiederherstellungsschritte mit manuellen oder automatischen Wiederherstellungsschritten geplant werden. Dies sorgt dafür, dass alle weiteren Abhängigkeiten auf dem Verwaltungsserver erfasst und eingeplant werden, wenn der Plan für die Notfallwiederherstellung implementiert werden muss.

Wenn ein Standort offline geschaltet wird, führt der Agent ein Failover auf den Verwaltungsserver in einem anderen Standort durch – vorausgesetzt, der Agent wurde für ein solches Failover konfiguriert. Konfigurieren Sie die Windows-Agents neu, sodass nur Verwaltungsserver in dem primären Rechenzentrum zwischengespeichert werden, in dem sie verwaltet werden. So verhindern Sie, dass ein Failover auf einen Verwaltungsserver im sekundären Rechenzentrum versucht wird, was Wiederherstellung und Berichterstellung nur verzögern würde. Dies kann erreicht werden, wenn Sie den Agent manuell auf automatisierte Weise mit einem Skript (z. B. VBScript oder besser noch PowerShell) bereitstellen, der während der Installation vorkonfiguriert werden soll, oder nach der Bereitstellung, wenn Sie den Agent über die Konsole pushen, wieder mithilfe einer skriptgesteuerten Methode, die mit Ihrer Unternehmenskonfigurationsverwaltungslösung verwaltet wird.

Operations Manager kann als alternative Notfallwiederherstellungsoption auf Azure-VMs bereitgestellt werden, um die Kontinuität der Verwaltungsgruppe sicherzustellen. Es ist auch erforderlich, SQL Server auf einem virtuellen Computer in Azure und nicht in einer Hybridkonfiguration bereitzustellen, da sich die Latenz zwischen einem Verwaltungsserver und dem SQL Server, die die Operations Manager-Datenbanken hosten, negativ auf die Leistung der Verwaltungsgruppe auswirkt.

Berücksichtigen Sie den Überwachungsbereich, die Netzwerktopologie und Netzwerkkonnektivität mit Microsoft Azure (d. h. Site-to-Site-VPN oder ExpressRoute), Integrationspunkte (d. h. ITSM-Lösungen, andere System Center-Produkte, Drittanbieter-Add-Ons usw.), Konsolenzugriff, gesetzliche oder relevante Gesetze oder Richtlinien usw., um dieses Szenario innerhalb von Azure IaaS oder anderen öffentlichen Cloudanbietern ordnungsgemäß zu entwerfen.