Hochverfügbarkeit und Notfallwiederherstellung

System Center – Operations Manager-Server und -Features können potenziell fehlschlagen, was sich auf die Operations Manager-Funktionalität auswirkt. Die Menge der während eines Fehlers verloren gegangenen Daten und Funktionen unterscheidet sich in jedem Fehlerszenario. Dies hängt von der Rolle des fehlerhaften Features und der Zeit ab, die zum Wiederherstellen des fehlerhaften Features benötigt wird.

Hochverfügbarkeit

Hohe Verfügbarkeitsanforderungen werden durch die Erstellung von Redundanz in die Verwaltungsgruppe für die Operations Manager-Datenbanken für betriebs- und Data Warehouse-Datenbanken, das Gateway und die Verwaltungsserver sowie bestimmte Workloads behoben. Zu diesen Workloads gehören Netzwerkgeräteüberwachung, plattformübergreifende Überwachung und gruppenspezifische Verwaltungsarbeitslasten, die zuvor vom Stammverwaltungsserver verwaltet wurden.

Die Konfiguration mehrerer Server mit einer einzelnen Verwaltungsgruppe kann SQL Server AlwaysOn verwenden, um hohe Verfügbarkeit und Dienstkontinuität der Operations Manager-Datenbanken bereitzustellen. Die Fehlertoleranz des Verwaltungsservers wird durch die Verwendung von mindestens zwei Verwaltungsservern und die Verwendung der Ressourcenpools für die Überwachung von UNIX-Servern, Linux-Servern und Netzwerkgeräten bereitgestellt. Agentbasierte Windows-Server können mit einem primären und sekundären Verwaltungsserver konfiguriert werden, um die Agentkommunikation umzuleiten, wenn ein Verwaltungsserver fehlschlägt.

Der RMS-Emulator kann auch auf einen anderen Verwaltungsserver verschoben werden, wenn der Verwaltungsserver, auf dem der RMS-Emulator gehostet wird, nicht mehr verfügbar ist.

Operations console connections can be made highly available by configuring high availability for the Data Access Services. Dazu können Sie Microsoft Network Load Balancing (NLB) oder einen hardwarebasierten Lastenausgleich oder DNS-Alias verwenden. Mindestens ein Verwaltungsserver wird als Mitglieder des NLB-Pools hinzugefügt, und beim Öffnen der Konsole verweisen Sie auf den virtuellen Namen, der in DNS registriert ist, von den Verwaltungsservern mit Lastenausgleich.

Hinweis

Ein Netzwerklastenausgleich wird für den Operations Manager-Webkonsolenserver nicht unterstützt.

Mehrere Gatewayserver können über eine Vertrauensgrenze hinweg bereitgestellt werden, um redundante Pfade für Agents bereitzustellen, die sich über diese Vertrauensgrenze erstrecken. Ebenso wie Agents zwischen einem primären Verwaltungsserver und einem oder mehreren sekundären Verwaltungsservern fehlschlagen können, können sie auch zwischen Gatewayservern fehlschlagen. Darüber hinaus können mehrere Gatewayserver verwendet werden, um die Arbeitsauslastung der Verwaltung von agentlosen verwalteten Computern und verwalteten Netzwerkgeräten zu verteilen.

Zusätzlich zur Bereitstellung von Redundanz über das Agent-Gateway-Failover können Gatewayserver so konfiguriert werden, dass zwischen Verwaltungsservern in einer Verwaltungsgruppe ein Failover ausgeführt wird, wenn mehrere Verwaltungsserver verfügbar sind.

Sql Server Reporting Services unterstützt zwar ein Skalierungsmodell, mit dem Sie mehrere Berichtsserverinstanzen ausführen können, die eine einzelne Berichtsserverdatenbank gemeinsam nutzen, aber mit Operations Manager wird sie nicht unterstützt. Operations Manager Reporting installiert eine benutzerdefinierte Sicherheitserweiterung als Teil des Setups der Front-End-Komponenten, die nicht in der Webfarm repliziert werden können.

Notfallwiederherstellung

Die Notfallwiederherstellung bezieht sich auf Maßnahmen, die sicherstellen sollen, dass der Betrieb im Falle eines katastrophalen Ausfalls (z. B. Verlust des gesamten Rechenzentrums, in dem die primäre Infrastruktur untergebracht ist) wieder aufgenommen werden kann. Dies ist ein wichtiges Element, das bei jeder Bereitstellung berücksichtigt werden muss, und die Entscheidungen, die bei der Planung der Notfallwiederherstellung getroffen werden, wirken sich darauf aus, wie der Operations Manager weiterhin die proaktive Überwachung und Berichterstattung über die Leistung und Verfügbarkeit Ihrer kritischen IT-Services unterstützen kann. Dieser Abschnitt befasst sich mit der empfohlenen Strategie der Notfallwiederherstellung und Resilienz sowie mit den erforderlichen Schritten, um eine reibungslose Wiederherstellung sicherzustellen.

Während HA- und DR-Lösungen Schutz vor Systemausfall oder Systemverlust bieten, sollten sie sich nicht auf den Schutz vor versehentlichem, unbeabsichtigtem oder böswilligen Datenverlust oder Beschädigung verlassen werden. In diesen Fällen müssen kopierte oder markierte Replikationskopien möglicherweise für Wiederherstellungsvorgänge verwendet werden. In vielen Fällen ist ein Wiederherstellungsvorgang die am besten geeignete Form von DR. Ein Beispiel hierfür könnte eine Berichtsdatenbank mit niedriger Priorität oder Analysedaten sein. In vielen Fällen überwiegt die Kosten für die Aktivierung von dr für mehrere Standorte auf System- oder Anwendungsebene weit über den Wert der Daten. In Fällen, in denen der kurzfristige Wert der Daten niedrig ist und die Notwendigkeit des Zugriffs auf die Daten ohne schwerwiegende Geschäftliche Auswirkungen verzögert werden kann, wenn ein Ausfall oder ein Standort-DR übermäßig ist, erwägen Sie, einfache Sicherungs- und Wiederherstellungsprozesse für DR zu verwenden, wenn die Kosteneinsparungen dies garantieren.

Das Verständnis der Auswirkungen und toleranzen für Ausfallzeiten trägt dazu bei, die Entscheidungen zu fördern, die verstanden werden müssen, um die Architektur für Operations Manager ordnungsgemäß zu entwerfen und die Komplexität und Kosten zu unterstützen, die zur Unterstützung der Notfallwiederherstellung erforderlich sind. Berücksichtigen Sie darüber hinaus den Umfang der Überwachung des Datenverlusts, den die IT-Organisation tolerieren kann, ohne dass geschäftliche Konsequenzen entstehen. Dies wird am besten in zwei Punkten beschrieben: Recovery Time Objective (RTO) und Recovery Point Objective (RPO).

Die beiden am häufigsten verwendeten Entwurfskonfigurationen für die Notfallwiederherstellung für Operations Manager sind:

• Erstellen eines Duplikats der Verwaltungsgruppe, das im sekundären Rechenzentrum bereitgestellt wird. Hierbei werden Umfang und Konfiguration der primären Verwaltungsgruppe dupliziert.
• Bereitstellung zusätzlicher Server in einem sekundären Rechenzentrum zur Unterstützung der Betriebs- und Data-Warehouse-Datenbank, wobei die Management Server in einer Cold-Standby-Konfiguration bereitgestellt werden und erst dann an der Verwaltungsgruppe teilnehmen, wenn Wiederherstellungsmaßnahmen durchgefü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 beim Überschneiden keine Unterschiede in bezug auf überwachte, alarmierte oder gemeldete, präsentiert und schließlich eskaliert werden. Die Integration mit anderen Überwachungsplattformen oder ITSM-Plattformen wie System Center - Service Manager, Remedy oder ServiceNow muss ebenfalls vorhanden sein und möglicherweise in einem aktiven/passiven Zustand konfiguriert werden, um Duplizierungen von Vorfällen, Konfigurationselementen usw. zu vermeiden. Agents werden zwischen beiden Verwaltungsgruppen multihomediert, sodass eine Duplizierung von Daten vorhanden ist.

Das folgende Diagramm ist ein Beispiel für dieses Entwurfsszenario.

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. Erwägen Sie mindestens die Implementierung einer SQL Server 2014- oder 2016-AlwaysOn-Verfügbarkeitsgruppe, um eine Wiederherstellung der Operational- und Data Warehouse-Datenbanken zwischen zwei oder mehr Rechenzentren bereitzustellen, wobei eine Zwei-Knoten-Failoverclusterinstanz (FCI) im primären Rechenzentrum bereitgestellt wird, und einen eigenständigen SQL Server im sekundären Rechenzentrum als Teil eines einzelnen Windows Server-Failoverclusters (WSFC). Das sekundäre Replikat für die Always On-Verfügbarkeitsgruppe befindet sich auf der eigenständigen Instanz ohne FCI, wie im folgenden Diagramm dargestellt.

In diesem Beispiel müssen Sie einen oder mehrere Windows-Server mit demselben Hardwarekonfigurations- und Computernamen bereitstellen und die Verwaltungsserverrolle mithilfe des Parameters "/Recover " erneut 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 werden die gesammelten Daten (Warnungen, Ereignisse, Leistung usw.) in die Warteschlange gestellt, bis sie die Kommunikation mit einem Verwaltungsserver in der Verwaltungsgruppe fortsetzen können. Dieser Ansatz vermeidet die Installation neuer Instanzen von SQL Server und das Wiederherstellen von Datenbanken aus der letzten bekannten guten Sicherung. 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 minimalen Überwachungsfunktionalität erforderlich sind. Wenn dieser Ansatz nicht akzeptabel ist, können Sie Verwaltungsserver in Ihrem sekundären Rechenzentrum für die On-Standby-Wiederherstellung bereitstellen. Entfernen Sie sie als Mitglieder der drei primären Ressourcenpools : Alle Verwaltungsserver-Ressourcenpool, Benachrichtigungen und AD-Zuordnung. Dazu gehören auch alle benutzerdefinierten Ressourcenpools, die Verwaltungsserver enthalten können, die im primären Rechenzentrum gehostet werden und weiterhin als Teil des Wiederherstellungsplans funktionieren müssen. Die System Center Data Access-, System Center Configuration Management- und Microsoft Monitoring Agent-Dienste sollten beendet und auf manuell oder deaktiviert festgelegt und 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 je nach Integrationskonfiguration und Abfolge der Wiederherstellungsschritte mit manuellen oder automatischen Wiederherstellungsschritten geplant werden. Dadurch wird sichergestellt, dass alle anderen Abhängigkeiten vom Verwaltungsserver erfasst und geplant werden, wann der Notfallwiederherstellungsplan implementiert werden muss.

Wenn ein Standort offline ist, schlägt der Agent an dem Verwaltungsserver an einem anderen Standort fehl, vorausgesetzt, dass die Failoverkonfiguration des Agents dies zulässt. Konfigurieren Sie die Windows-Agents so, dass nur Verwaltungsserver in Ihrem primären Rechenzentrum zwischengespeichert werden, die sie verwalten sollten, um zu verhindern, dass sie ein Failover auf einen Verwaltungsserver im sekundären Rechenzentrum durchführen, was nur die Wiederherstellung und Berichterstellung verzögern würde. Dies kann erreicht werden, wenn Sie den Agent manuell in automatisierter Weise mit einem Skript (z. B. VBScript oder noch besser, PowerShell) bereitstellen, um während der Installation vorkonfiguriert zu werden, oder nach der Bereitstellung, wenn Sie den Agent über die Konsole übertragen, erneut mithilfe einer skriptgesteuerten Methode, die mit Ihrer Unternehmenskonfigurationsverwaltungslösung verwaltet wird.

Operations Manager kann auf virtuellen Azure-Computern als alternative Notfallwiederherstellungsoption bereitgestellt werden, um die Kontinuität der Verwaltungsgruppe aufrechtzuerhalten. 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, auf dem die Operations Manager-Datenbanken gehostet werden, negativ auf die Leistung der Verwaltungsgruppe auswirken.

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