Hochverfügbarkeit und Notfallwiederherstellung

Server und Funktionen von System Center – Operations Manager können potenziell ausfallen und die Funktionsweise von Operations Manager beeinträchtigen. Die Menge an Daten und Funktionen, die bei einem Ausfall verloren gehen, ist in jedem Fehlerszenario unterschiedlich. Das hängt von der Rolle der ausgefallenen Funktion und der Zeit ab, die benötigt wird, um die ausgefallene Funktion wiederherzustellen.

Hochverfügbarkeit

Der Bedarf an hoher Verfügbarkeit wird durch den Einbau von Redundanz in die Verwaltungsgruppe für die Operations Manager‑ und Data Warehouse-Datenbanken, die Gateway‑ und Verwaltungsserver sowie spezifische Arbeitslasten gedeckt. Zu diesen Arbeitslasten gehören die Überwachung von Netzwerkgeräten, die plattformübergreifende Überwachung und arbeitsgruppenspezifische Arbeitslasten, die zuvor vom Stammverwaltungsserver verwaltet wurden.

Die Konfiguration mehrerer Server in einer einzigen Verwaltungsgruppe kann SQL Server Always On nutzen, um eine Hochverfügbarkeit und Servicekontinuität der Operations Manager-Datenbank bereitzustellen. Die Fehlertoleranz des Verwaltungsservers wird durch mindestens zwei Verwaltungsserver und die Verwendung der Ressourcenpools zur Überwachung von UNIX-Servern, Linux-Servern und Netzwerkgeräten sichergestellt. Agentbasierte Windows-Server können mit einem primären und einem sekundären Verwaltungsserver konfiguriert werden, um die Agentkommunikation umzuleiten, falls ein Verwaltungsserver ausfällt.

Der RMS-Emulator kann auch zu einem anderen Verwaltungsserver verschoben werden, falls der Verwaltungsserver, auf dem der RMS-Emulator gehostet wird, nicht mehr verfügbar sein sollte.

Die Verbindungen der Bedienkonsole können durch die Konfiguration einer Hochverfügbarkeit für die Datenzugriffsdienste hochverfügbar gemacht werden. Dies kann durch die Installation von Microsoft-Netzwerklastenausgleich (NLB) oder durch die Verwendung eines hardwarebasierten Load Balancers oder DNS-Alias erfolgen. Ein oder mehrere Verwaltungsserver werden als Mitglieder des NLB-Pools hinzugefügt. Wenn Sie die Konsole öffnen, verweisen Sie auf den in DNS registrierten virtuellen Namen der Verwaltungsserver mit Lastenausgleich.

Hinweis

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

Mehrere Gatewayserver können über eine Vertrauensgrenze hinweg eingesetzt werden, um redundante Pfade für Agents in dieser Vertrauensgrenze bereitzustellen. Genauso wie Agents zwischen einem primären Verwaltungsserver und einem oder mehreren sekundären Verwaltungsservern ausfallen können, können sie auch zwischen Gatewayservern ausfallen. Darüber hinaus können mehrere Gatewayserver verwendet werden, um die Arbeitslast der Verwaltung von ohne Agents verwalteten Computern und verwalteten Netzwerkgeräten zu verteilen.

Zusätzlich zur Bereitstellung von Redundanz durch Agent-Gateway-Failover können Gatewayserver so konfiguriert werden, dass sie zwischen Verwaltungsservern in einer Verwaltungsgruppe ein Failover ausführen, wenn mehrere Verwaltungsserver verfügbar sind.

SQL Server Reporting Services unterstützt zwar ein Bereitstellungsmodell zur horizontalen Skalierung, mit dem Sie mehrere Berichtsserverinstanzen ausführen können, die eine einzige Berichtsserverdatenbank gemeinsam nutzen, dies wird jedoch nicht von Operations Manager unterstützt. Operations Manager Reporting installiert eine angepasste 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ädigungen verlassen werden. In diesen Fällen müssen möglicherweise Sicherungskopien oder verzögerte Replikationskopien für Wiederherstellungsvorgänge verwendet werden. In vielen Fällen ist ein Wiederherstellungsvorgang die am besten geeignete Art von DR. Ein Beispiel hierfür könnte eine Berichtsdatenbank mit niedriger Priorität oder Analysedaten sein. In vielen Fällen übersteigen die Kosten für die Aktivierung der standortübergreifenden DR auf System‑ oder Anwendungsebene bei Weitem den Wert der Daten. In Fällen, in denen der kurzfristige Wert der Daten gering ist und der Zugriff auf die Daten ohne schwerwiegende geschäftliche Auswirkungen verzögert werden kann, wenn ein Ausfall oder eine übermäßige Wiederherstellung vor Ort eintritt, sollten Sie die Verwendung einfacher Sicherungs‑ und Wiederherstellungsprozesse für die DR nach einem Ausfall in Betracht ziehen, wenn die Kosteneinsparungen dies rechtfertigen.

Das Verständnis der Auswirkungen und der Toleranz für Ausfallzeiten hilft dabei, die Entscheidungen zu treffen, die verstanden werden müssen, um die Architektur für den Operations Manager und den Grad an Komplexität und Kosten, die für die Unterstützung der Notfallwiederherstellung erforderlich sind, richtig zu gestalten. Berücksichtigen Sie zudem, in welchem Umfang die IT-Organisation Datenverluste tolerieren kann, ohne dass dies geschäftliche Konsequenzen hat. 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.

Die Bereitstellung einer duplizierten Verwaltungsgruppe ist eine Option, wenn Ausfallzeiten nicht toleriert werden können. Allerdings ist dies die komplexeste Option. Die Konfiguration zwischen beiden muss konsistent sein, damit es bei der Umstellung keine Unterschiede bei der Überwachung, Warnung oder Berichterstattung, Präsentation und schließlich Eskalation gibt. 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 Aktiv/Passiv-Status konfiguriert werden, um die doppelte Erfassung von Vorfällen, Konfigurationselementen usw. zu vermeiden. Agents werden zwischen beiden Verwaltungsgruppen mehrfach vernetzt, sodass eine Duplizierung von Daten vorhanden ist.

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

Wenn für die Ihre Operations Manager-Bereitstellung keine sofortige Wiederherstellung 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 zumindest die Implementierung einer SQL Server 2014‑ oder 2016-Always-On-Verfügbarkeitsgruppe, um die Wiederherstellung der Betriebs‑ und Data Warehouse-Datenbanken zwischen zwei oder mehr Rechenzentren zu ermöglichen, wobei eine Failoverclusterinstanz (FCI) mit zwei Knoten im primären Rechenzentrum und ein eigenständiger SQL Server im sekundären Rechenzentrum als Teil eines einzelnen Windows Server-Failoverclusters (WSFC) bereitgestellt wird. Die sekundäre Replik für die Always-On-Verfügbarkeitsgruppe würde sich auf der nicht-FCI-Standalone-Instanz befinden, wie in der folgenden Abbildung zu sehen.

In diesem Beispiel müssten Sie einen oder mehrere Windows-Server 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 werden die Agents die gesammelten Daten (Warnmeldungen, Ereignisse, Leistung usw.) in eine Warteschlange stellen, bis sie die Kommunikation mit einem Verwaltungsserver in der Verwaltungsgruppe fortsetzen können. Dieser Ansatz vermeidet die Installation neuer Instanzen des 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 für das Fortsetzen der Mindestüberwachungsfunktionen erforderlich sind. Wenn dieser Ansatz nicht akzeptabel ist, können Sie Verwaltungsserver in Ihrem sekundären Rechenzentrum für die Wiederherstellung im Standby-Modus bereitstellen. Entfernen Sie sie als Mitglieder der drei primären Ressourcenpools – Ressourcenpool für alle Verwaltungsserver, Benachrichtigungen und AD-Zuweisung. Dies umfasst auch jeden angepassten Ressourcenpool, der möglicherweise Verwaltungsserver enthält, die im primären Rechenzentrum gehostet werden und als Teil des Wiederherstellungsplans weiterhin funktionieren müssen. Die Dienste „System Center Data Access“, „System Center Configuration Management“ und „Microsoft Monitoring Agent“ sollten gestoppt und auf manuell oder deaktiviert gesetzt werden und nur in einem Notfallwiederherstellungsszenario gestartet werden.

Wenn ein Verwaltungsserver die Integration unterstützt (über einen Konnektor, der direkt auf dem Verwaltungsserver gehostet wird, oder über ein anderes System Center-Produkt wie VMM, Orchestrator oder Service Manager), muss dies je nach Integrationskonfiguration und Reihenfolge der Wiederherstellungsschritte mit manuellen oder automatischen Wiederherstellungsschritten geplant werden. Dadurch wird sichergestellt, dass jede andere Abhängigkeit vom Verwaltungsserver erfasst und bei der Umsetzung des Notfallwiederherstellungsplans berücksichtigt wird.

Wenn ein Standort offline geht, wechselt der Agent zum Verwaltungsserver an einem anderen Standort, vorausgesetzt, die Failover-Konfiguration des Agents lässt dies zu. Konfigurieren Sie die Windows-Agenten neu, sodass nur Verwaltungsserver in Ihrem primären Rechenzentrum zwischengespeichert werden, die sie verwalten sollten, um zu verhindern, dass sie versuchen, ein Failover auf einen Verwaltungsserver im sekundären Rechenzentrum durchzuführen, was die Wiederherstellung und Berichterstellung nur verzögern würde. Dies kann erreicht werden, indem Sie den Agent manuell auf automatisierte Weise mit einem Skript (wie etwa VBScript oder besser noch PowerShell) bereitstellen, um ihn während der Installation oder nach der Bereitstellung zu konfigurieren, wenn Sie den Agent von der Konsole aus übertragen, wiederum unter Verwendung einer Skriptmethode, die mit Ihrer Unternehmenslösung für die Konfigurationsverwaltung verwaltet wird.

Operations Manager kann auf virtuellen Azure-Computern als alternative Notfallwiederherstellungsoption eingesetzt werden, um die Kontinuität der Verwaltungsgruppe aufrechtzuerhalten. Es wird notwendig sein, SQL Server auch auf einem virtuellen Computer in Azure und nicht in einer Hybridkonfiguration zu implementieren, da die Latenz zwischen einem Verwaltungsserver und dem SQL Server, der die Operations Manager-Datenbanken hostet, die Leistung der Verwaltungsgruppe negativ beeinflussen wird.

Berücksichtigen Sie den Überwachungsumfang, die Netzwerktopologie und die Netzwerkkonnektivität zu Microsoft Azure (d. h. Site-to-Site-VPN oder ExpressRoute), Integrationspunkte (d. h. ITSM-Lösungen, andere System Center-Produkte, Add-ons von Drittanbietern usw.), Konsolenzugriff, regulatorische oder relevante Gesetze oder Richtlinien usw., um dieses Szenario in Azure IaaS oder anderen Anbietern von öffentlichen Clouds ordnungsgemäß zu gestalten.