Table of contents
TOC
Inhaltsverzeichnis reduzieren
Inhaltsverzeichnis erweitern

Hochverfügbarkeit und Notfallwiederherstellung

Matt Goedtel|Zuletzt aktualisiert: 02.03.2017
|
1 Mitwirkender

Gilt für: System Center 2016 – Operations Manager

Wenn Server und Features von System Center 2016 – Operations Manager ausfallen, wird die Funktionsweise von Operations beeinträchtigt. Wie stark der Daten- oder Funktionalitätsverlust während eines Ausfalls ist, hängt vom jeweiligen Ausfallszenario ab. Zu den Einflussfaktoren gehören die Rolle der fehlerhaften Funktion und der Zeitraum, der bis zur Wiederherstellung der fehlerhaften Funktion vergeht.

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.

In einer Konfiguration mit mehreren Servern in einer einzelnen Verwaltungsgruppe können die Always On-Funktionen von SQL Server 2014 oder SQL Server 2016 genutzt werden, um hohe Verfü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, sollte ein Verwaltungsserver ausfallen.

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.

Verbindungen der Betriebskonsole können hoch verfügbar gemacht werden. Dies lässt sich erreichen, indem Sie Hochverfügbarkeit für die Datenzugriffsdienste konfigurieren. Installieren Sie zu diesem Zweck den Microsoft-Netzwerklastenausgleich (Network Load Balancing, NLB), verwenden Sie hardwarebasierte Lastenausgleichsmodule oder verwenden Sie einen DNS-Alias. 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

Der Netzwerklastenausgleich 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.

Die SQL Server Reporting Services unterstützen ein horizontal hochskalierbares Bereitstellungsmodell, mit dem Sie mehrere Berichtsserverinstanzen ausführen können, die gemeinsam eine einzelne Berichtsserverdatenbank nutzen. Diese Konfiguration wird mit Operations Manager nicht unterstützt. Die Berichterstellung in Operations Manager wird im Rahmen der Einrichtung der Front-End-Komponenten als benutzerdefinierte Sicherheitserweiterung installiert. Diese Konstellation kann nicht über die Webfarm hinweg repliziert werden.

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. Dies ist ein wichtiges Element, das bei jeder Bereitstellung berücksichtigt werden muss. Die Entscheidungen, die bei der Planung der Notfallwiederherstellung getroffen werden, wirken sich nachhaltig auf die Art und Weise aus, in der Operations Manager die proaktive Überwachung und Berichterstellung für die Leistung und Verfügbarkeit Ihrer kritischen IT-Dienste gewährleisten 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 Schutz bei Systemfehlern oder Systemausfällen. Allerdings schützen sie nicht vor zufälligen, unbeabsichtigten oder böswilligen Datenverlusten oder Datenbeschädigungen. Für solche Fälle sollten Sicherungskopien oder Kopien durch verzögerte Replikation vorhanden sein, um Wiederherstellungsvorgänge durchzuführen. 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 der Datenzugriff nach einem schwerwiegenden Fehler oder Standortausfall ohne größere Auswirkungen auf das Geschäft nicht sofort wiederhergestellt werden muss, sollten Sie, sofern die Kosteneinsparungen in erheblichem Maß dafür sprechen, 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. Darüber hinaus müssen Sie berücksichtigen, 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 eines Duplikats der Verwaltungsgruppe, das im sekundären Rechenzentrum bereitgestellt wird. Hierbei werden Umfang und Konfiguration der primären Verwaltungsgruppe 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.

Die Bereitstellung einer duplizierten Verwaltungsgruppe ist eine Option, wenn Ausfallzeiten nicht toleriert werden können. Allerdings ist dies auch die komplexeste Option. Die Konfiguration der beiden Verwaltungsgruppen muss konsistent sein, damit es bei einer Übernahme keinerlei Unterschiede hinsichtlich der Überwachung, Warnungserstellung, Berichterstellung, Präsentation und Eskalation von Elementen gibt. Zudem muss eine Integration mit anderen Überwachungs- oder ITSM-Plattformen wie z.B. System Center 2016 – Service Manager, Remedy oder ServiceNow vorhanden sein. Eine solche Integration muss ggf. in einem Aktiv/Passiv-Zustand konfiguriert sein, um eine Duplizierung von Incidents, Konfigurationselementen usw. zu vermeiden. Agents sind in beiden Verwaltungsgruppen vorhanden, daher liegen Daten doppelt vor.

Das folgende Diagramm zeigt ein Beispiel dieses Entwurfsszenarios.

Doppelte Verwaltungsgruppen

Wenn für Ihre Operations Manager-Bereitstellung eine sofortige Wiederherstellung nicht notwendig ist und Sie die Komplexität einer doppelten Verwaltungsgruppe vermeiden möchten, können Sie zusätzliche Verwaltungsgruppenkomponenten in Ihrem sekundären Rechenzentrum bereitstellen, um die Funktionalität Ihrer Verwaltungsgruppe sicherzustellen. 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.

Konfiguration einer einfachen Notfallwiederherstellung

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. Während dieses Zeitraums stellen die Agents die erfassten Daten (Warnungen, Ereignisse, Leistung usw.) in eine Warteschlange, bis die Kommunikation mit einem Verwaltungsserver in der Verwaltungsgruppe wieder aufgenommen werden kann. Bei dieser Vorgehensweise müssen Sie keine neuen SQL Server-Instanzen installieren und Datenbanken nicht aus der letzten als funktionierend bekannten Sicherung wiederherstellen. Da es in diesem Szenario jedoch wahrscheinlich länger dauern wird, einen betriebsfähigen Zustand wiederherzustellen, müssen Sie die anderen Rollen bereitstellen, die zur Wiederaufnahme einer minimalen Ü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. Diese Verwaltungsserver müssen aus den drei primären Ressourcenpools für alle Verwaltungsserver, Benachrichtigungen und AD-Zuweisung entfernt werden. 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 (über einen Connector, der direkt auf dem Verwaltungsserver oder in einem anderen System Center-Produkt wie z.B. VMM, Orchestrator oder Service Manager gehostet wird) unterstützt, muss dieses Szenario geplant werden. Hierbei müssen manuelle oder automatische Wiederherstellungsschritte eingerichtet werden, je nach Konfiguration der Integration und der Reihenfolge der Wiederherstellungsschritte. Dies sorgt außerdem dafür, dass alle weiteren Abhängigkeiten auf dem Verwaltungsserver erfasst und eingeplant werden, wenn der Plan für die Notfallwiederherstellung implementiert werden muss.

Konfiguration einer komplexen Notfallwiederherstellung

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. Sie sollten die Windows-Agents neu konfigurieren, sodass nur Verwaltungsserver im dem primären Rechenzentrum zwischengespeichert werden, in dem sie verwaltet werden. So verhindern Sie, dass ein Failover zu einem Verwaltungsserver im sekundären Rechenzentrum versucht wird, was Wiederherstellung und Berichterstellung nur verzögern würde. Zu diesem Zweck stellen Sie den Agent manuell mit Unterstützung durch ein automatisiertes Skript bereit (z.B. VBScript oder besser PowerShell), das den Agent vor der Installation konfiguriert. Alternativ dazu kann die Konfiguration auch nach der Bereitstellung erfolgen, wenn Sie den Agent per Push über die Konsole bereitstellen, ebenfalls mit einer skriptgesteuerten Methode, die über die Konfigurationsverwaltungslösung Ihres Unternehmens verwaltet wird.

Operations Manager kann als alternative Notfallwiederherstellungsoption auf Azure-VMs bereitgestellt werden, um die Kontinuität der Verwaltungsgruppe sicherzustellen. SQL Server muss ebenfalls auf einer VM in Azure bereitgestellt werden, nicht in einer Hybridkonfiguration, da die Latenz zwischen einem Verwaltungsserver und der SQL Server-Instanz, auf der die Operations Manager-Datenbanken gehostet werden, sich negativ auf die Leistung der Verwaltungsgruppe auswirkt.
Um dieses Szenario in Azure IaaS oder mit anderen Cloudanbietern richtig zu entwerfen, berücksichtigen Sie folgende Aspekte: Überwachungsumfang, Netzwerktopologie und Netzwerkkonnektivität mit Microsoft Azure (d.h. Standort-zu-Standort-VPN oder ExpressRoute), Integrationspunkte (ITSM-Lösungen, andere System Center-Produkte, Drittanbieter-Add-Ons usw.), Konsolenzugriff sowie anwendbare Gesetze und Richtlinien.

© 2017 Microsoft