Überlegungen zur Geschäftskontinuität und Notfallwiederherstellung für Red Hat Enterprise Linux in Azure
In diesem Artikel wird beschrieben, wie Sie die Geschäftskontinuität und Notfallwiederherstellung (BCDR) einer auf Red Hat Enterprise Linux (RHEL) basierenden Umgebung in Azure verbessern. Der Artikel enthält Empfehlungen, mit denen Sie RHEL-Workloads unterstützen und Komponenten für die RHEL-Plattformverwaltung bereitstellen können. Das Red Hat Management-Abonnement enthält Plattformkomponenten, die die Verwaltung von Workloads in mindestens einer RHEL-Zielzone unterstützen. Diese Komponenten bieten eigene BCDR-Konfigurationen.
Überlegungen zum Entwurf
Implementieren Sie folgende Aspekte, um die Resilienz Ihrer RHEL-Workloads zu verbessern.
Recovery Time Objectives
Ein Recovery Time Objective (RTO) ist die von Ihrem System benötigte Zeitspanne, um nach einem Notfall den ursprünglichen Zustand wiederherzustellen. Das RTO umfasst die benötigte Zeit für Folgendes:
- Widerherstellen der minimalen Funktionalität von virtuellen Maschinen (VMs) und Anwendungen
- Wiederherstellen von Daten, die von Anwendungen benötigt werden
Aus geschäftlicher Sicht stellt das RTO den Zeitraum dar, in dem die Geschäftsprozesse außer Betrieb sind. Ein niedriger RTO-Wert eignet sich ideal für unternehmenskritische Workloads, damit Geschäftsprozesse schnell wieder fortgesetzt werden können. Bei Workloads mit geringerer Priorität hat ein höherer RTO-Wert möglicherweise keine nennenswerten Auswirkungen auf die Gesamtleistung des Unternehmens.
Recovery Point Objectives
Um eine Cloudumgebung erfolgreich zu betreiben, müssen Sie Sicherungen, Replikationen oder beides implementieren, um Daten vor Ausfällen zu schützen. Das Recovery Point Objective (RPO) bezieht sich auf den Zeitpunkt, zu dem diese Daten zuletzt erfasst wurden. Wenn ein System ausfällt, ist nur eine Wiederherstellung des letzten Wiederherstellungspunkts möglich.
Sie messen das RPO vom letzten Wiederherstellungspunkt bis zum Zeitpunkt eines Ausfalls. Wenn Sie das RPO in Stunden messen, führt ein Systemausfall zum Verlust der Daten in den Stunden zwischen dem letzten Wiederherstellungspunkt und dem Ausfall. Wenn Sie das RPO in Tagen messen, führt ein Systemausfall zum Verlust der Daten in den Tagen zwischen dem letzten Wiederherstellungspunkt und dem Ausfall. Ein RPO von einem Tag führt theoretisch zum Verlust sämtlicher Transaktionen an diesem Tag bis zum Ausfall.
Messen Sie bei unternehmenskritischen Systemen das RPO in Minuten oder Sekunden, um Umsatz- oder Gewinnverluste zu vermeiden. Ein kurzes RPO führt in der Regel zu erhöhten Verwaltungskosten. Um diese Kosten zu senken, müssen Sie eine Verwaltungsbaseline erstellen, die sich auf das längste zulässige RPO konzentriert. Sie können dann das RPO der spezifischen Plattformen oder Workloads verringern, die weitere Investitionen rechtfertigen.
Überlegungen zur Workload-BCDR
Entwurfsüberlegungen zur Hochverfügbarkeit und Notfallwiederherstellung von RHEL-Workloads hängen von den Technologien ab, die diese Workloads unterstützen. Mit nativen Azure-Diensten können viele moderne Workloads verfügbarkeitszonen- und regionsübergreifende Redundanz bereitstellen. Verwenden Sie Azure-Dienste, um die Datenreplikation zu verwalten, Verfügbarkeitsgruppen automatisch zu skalieren sowie Update- und Fehlerdomänen zu steuern. Mit diesen Methoden wird die Verfügbarkeit von RHEL-Bereitstellungen einfacher gewährleistet.
Datenbanklösungen und andere zustandsbehaftete Anwendungen benötigen möglicherweise betriebssystemorientierte Lösungen, um Hochverfügbarkeit und Notfallwiederherstellung zu ermöglichen. Wenden Sie sich an den Anwendungsentwickler oder -anbieter, um die von den Anwendungen unterstützten Lösungen zu überprüfen. Weitere Informationen finden Sie unter Hochverfügbarkeit und Notfallwiederherstellung für IaaS-Apps.
| Azure-Feature oder -Dienst | Definition | Überlegungen |
|---|---|---|
| Regionen | Eine Gruppe von Rechenzentren, die sich nahe beieinander befinden, um geringe Netzwerkverzögerungen zu ermöglichen. Um eine schnelle Datenübertragung zu gewährleisten, verbindet ein bestimmtes regionales Netzwerk die Rechenzentren. | Berücksichtigen Sie beim Auswählen einer Azure-Region den Standort Ihrer Rechenzentren, Benutzer und Back-End-Daten. Überprüfen Sie die Verfügbarkeit der Dienste, die Sie in den ausgewählten Regionen benötigen. Bei RHEL-Bereitstellungen können Sie mit einer Region starten und dann später für BCDR-Zwecke weitere Regionen hinzufügen. |
| Azure ExpressRoute | Ein Azure-Dienst, mit dem Sie private Verbindungen von Microsoft-Rechenzentren mit Ihrer eigenen Infrastruktur oder einer Colocation-Umgebung herstellen. | ExpressRoute umgeht das öffentliche Internet und stellt eine dedizierte private Verbindung bereit. Diese Konfiguration ist eine gängige Anforderung für umfangreiche RHEL-Bereitstellungen. ExpressRoute ist ein freigegebener Dienst, daher müssen Sie Ihre Bandbreitenkapazität sorgfältig planen, um die allgemeinen Bandbreitenanforderungen Ihres Unternehmens zu erfüllen. Bei einer unzureichenden Bandbreite wird die Benutzerfreundlichkeit oder der Zugriff auf wichtige Dienste im Rechenzentrum möglicherweise beeinträchtigt. ExpressRoute muss auf resiliente Weise über Regionen und Peeringstandorte hinweg bereitgestellt werden. |
| Verfügbarkeitszonen | Trennen Sie Gruppen von Rechenzentren, die über eigene Energie-, Kühl- und Netzwerksysteme in einer Azure-Region verfügen. Verfügbarkeitszonen bieten Hochverfügbarkeit sowie Resilienz gegenüber Ausfällen von Rechenzentren. | Verwenden Sie nach Möglichkeit Verfügbarkeitszonen mit einer RHEL-Infrastruktur, um eine Vereinbarung zu einem hohen Servicelevel (Service-Level Agreement, SLA) zu gewährleisten. Verfügbarkeitszonen bieten Rechenzentrumsredundanz innerhalb einer Region. Nicht jede Region hat jedoch Verfügbarkeitszonen, daher müssen Sie sorgfältig planen. RHEL-Dienste, z. B. Azure Red Hat OpenShift und die Zielzonen-Verwaltungsdienste, unterstützen Verfügbarkeitszonen. |
| Verfügbarkeitsgruppen | Eine logische Gruppierung von VMs. Mindestens eine VM wird während geplanter oder ungeplanter Wartungsereignisse immer ausgeführt. Eine Fehlerdomäne ist eine Teilmenge einer Verfügbarkeitsgruppe, die allgemeine physische Infrastrukturelemente wie Stromversorgung oder Netzwerk gemeinsam verwendet. Wenn Sie VMs auf verschiedene Fehlerdomänen verteilen, reduziert eine Verfügbarkeitsgruppe die Auswirkungen von Hardwarefehlern auf die VM-Verfügbarkeit. | Verfügbarkeitsgruppen bieten eine hohe SLA. Verfügbarkeitsgruppen eignen sich für eine RHEL-Infrastruktur, wenn in einer Region keine Verfügbarkeitszonen vorhanden sind. Verfügbarkeitsgruppen bieten nur Hardwareredundanz, ähnlich den Antiaffinitätsregeln für Hypervisoren. Wenn für Ihre Regionen also keine Verfügbarkeitszonen vorhanden sind, benötigen Sie eine Strategie für Rechenzentrumsredundanz und geografische Redundanz für mehrere Regionen. |
| Azure-Lastenausgleich | Ein Dienst für den Netzwerklastenausgleich. Sie können Load Balancer so konfigurieren, dass Netzwerkdatenverkehr mit hohem Volumen effizient auf mehreren Red Hat Enterprise-Servern bereitgestellt wird. Durch die geringe Latenz und den hohen Durchsatz des Diensts werden die Leistung und Verfügbarkeit von Anwendungen verbessert. Load Balancer kann bei Bedarf automatisch skaliert werden. Um eine Hybridbereitstellung Ihrer Anwendungen zu fördern, kann Load Balancer den Netzwerkdatenverkehr über mehrere Regionen in Azure und auch zwischen lokalen Umgebungen und Azure verteilen. |
Load Balancer verteilt den Netzwerkdatenverkehr auf mehrere Server, um unterbrechungsfreie Anwendungsverfügbarkeit bereitzustellen und Single Points of Failure zu verhindern. Bei einem Notfall leitet Load Balancer den Datenverkehr an betriebsbereite Server um, um ein schnelles Failover und eine schnelle Wiederherstellung zu ermöglichen. Durch diesen Vorgang werden Ausfallzeiten minimiert und Geschäftsvorgänge aufrechterhalten. Load Balancer kann den Datenverkehr auf lokale Server in der Azure-Cloud oder auf Server in mehreren Azure-Regionen verteilen. Weitere Informationen finden Sie unter Optionen für den Lastenausgleich. |
| Verwaltete Datenträger | Virtualisierte Datenträger, die von Azure verwaltet werden. Sie wählen die Größe und den Typ des Datenträgers aus. Azure verteilt Datenträger auf verschiedene Speichereinheiten, um Ihre Daten vor Hardwarefehlern zu schützen. | Verwaltete Datenträger sind die beste Wahl für alle RHEL-Infrastrukturelemente. Verwenden Sie keine nicht verwalteten Datenträger. Weitere Informationen finden Sie unter SLAs für VMs. Verschiedene Arten von Datenträgern weisen unterschiedliche Leistung und Kosten auf. Für Computer mit RHEL-Infrastruktur empfehlen wir Azure SSD Premium. Berücksichtigen Sie bei der Auswahl des Datenträgertyps Kosten, Leistung und Verfügbarkeit. Wenn Sie die Zuordnung eines System aufheben, werden lokale SSDs und kurzlebige Datenträger entfernt. Sichern Sie die Daten auf diesen Datenträgern entsprechend. |
| Azure Backup | Ein Dienst, der kostengünstige Lösungen für die Sicherung Ihrer Daten und deren Wiederherstellung aus der Azure-Cloud bietet. | Die Sicherung stellt eine zuverlässige und kostengünstige Lösung dar, die Ihre RHEL-Infrastruktur vor VM-Fehlern oder Beschädigungen schützt. Verwenden Sie die Sicherung, um Ihre gesamte VM oder bestimmte Dateien und Ordner problemlos aus der Cloud wiederherzustellen, ohne die VM neu erstellen zu müssen oder Daten zu verlieren. Sie können auch andere unterstützte Partnerlösungen verwenden. |
| Azure Arc | Eine Plattform, die Azure-Dienste erweitert, sodass diese in verschiedenen Umgebungen, einschließlich Rechenzentren, Edgegeräten und Multicloudarchitekturen, ausgeführt werden. Verwenden Sie Azure Arc, um konsistente Entwicklung, Vorgänge und Sicherheitsverwaltung für Anwendungen und Dienste bereitzustellen. | Verwenden Sie Azure Arc, um zentralisierte automatisierte Sicherungen und Überwachung zu implementieren, wodurch die Resilienz aus BCDR-Sicht erhöht wird. |
| Azure Site Recovery | Ein Dienst, der Funktionen zur Notfallwiederherstellung bereitstellt, um die Geschäftskontinuität zu gewährleisten. Sie können Workloads, einschließlich Azure-VMs und lokaler VMs, regionsübergreifend replizieren und verwalten. Über Site Recovery können Sie Replikations-, Failover- und Wiederherstellungsprozesse einrichten, um Ihre Anwendungen während geplanter und ungeplanter Ausfälle zu schützen. | Mit Site Recovery können Sie Probleme beim Wiederherstellen minimieren, Infrastrukturkosten reduzieren und eine sichere und zuverlässige Wiederherstellung zwischen Azure-Regionen oder von lokalen Standorten in Azure gewährleisten. |
| Ressourcensperren | Ein Azure-Feature, mit dem Sie Benutzer und Rollen in Ihrer Organisation einschränken können. Schützen Sie Ihre kritischen Ressourcen vor versehentlichen oder böswilligen Änderungen. Sie können Ressourcen auf verschiedenen Bereichsebenen sperren, z. B. auf der Ebene des Abonnements, der Ressourcengruppe oder einzelner Ressourcen. Je nach Typ der Sperre können Sie Benutzer daran hindern, Ressourcen zu löschen oder zu ändern, doch die Benutzer können die Konfiguration der Ressourcen weiterhin sehen. | Mit Ressourcensperren schützen Sie alle RHEL-Infrastrukturelemente und Golden Image-VMs. Um zu verhindern, dass versehentlich wichtige Computer verloren gehen, sollten Sie zumindest die Löschsperre aktivieren. Wenden Sie die ReadOnly-Sperre auf Computer mit RHEL-Infrastruktur an, da diese sich nicht häufig ändern. Nehmen Sie Änderungen nur in den entsprechenden Zeitfenstern für die Änderungssteuerung vor. |
Überlegungen zur BCDR auf RHEL-Plattformen
Weitere Informationen zu BCDR-Funktionen für eine RHEL-Plattforminfrastruktur finden Sie hier:
- Hochverfügbarkeitsarchitektur – Satellite
- Hochverfügbarkeitsarchitektur – Ansible Automation Platform
- Hochverfügbarkeitsarchitektur – Identitätsverwaltung
Entwurfsempfehlungen
Verwenden Sie für cloudnative Anwendungen in Linux-Containern eine Kubernetes-basierte Plattform, um Skalierbarkeit, Hochverfügbarkeit und Redundanz zu gewährleisten. Verwenden Sie die Azure Red Hat OpenShift-Plattform oder eine selbstverwaltete OpenShift-Bereitstellung mit repliziertem oder georepliziertem Speicher.
Bei nativen Webanwendungs-Front-Ends und zustandslosen Anwendungen können Sie viele der Azure-nativen Dienste verwenden, die Anwendungsverfügbarkeit bieten. Architekturen, die solche Dienste verwenden, finden Sie hier:
- Baseline für hochverfügbare zonenredundante Webanwendung
- Hochverfügbare Webanwendung für mehrere Regionen
Die oben genannten Architekturen verwenden verschiedene Azure-Dienste für Verfügbarkeitszonen. Die Architektur mit mehreren Regionen verwendet Georeplikationsfunktionen für Inhalte und Azure Front Door als Lastenausgleichsdienst.
Für viele herkömmliche zustandsbehaftete Anwendungen, die Hochverfügbarkeit erfordern, bietet RHEL das Hochverfügbarkeits-Add-On mit Pacemaker an. Sie können Systeme mit dieser Funktion über Azure Marketplace abrufen oder ein benutzerdefiniertes Image bereitstellen, in das die erforderlichen Softwarekomponenten integriert sind. Weitere Informationen finden Sie unter Konfigurieren eines Red Hat-Hochverfügbarkeitsclusters in Microsoft Azure.
Verfügbarkeitsprobleme wirken sich auf Dienstausfälle und -antwortzeiten aus. Eventuelle Dienstbeeinträchtigungen können sich für Ihren Kunden auf die Benutzerfreundlichkeit des Diensts auswirken. Mit der Azure-Funktion für die Reservierung von Bedarfskapazitäten erhalten Sie das Leistungsniveau aufrecht und sorgen für ausreichende Kapazität in den erforderlichen Regionen.
Zuverlässigkeit
Viele der Konzepte, die für VM-Infrastrukturen mit Infrastructure-as-a-Service gelten, gelten auch für RHEL-Architekturen. Weitere Informationen finden Sie unter Entwurfsprinzipien für die Zuverlässigkeit.
Cluster
Azure unterstützt nicht die Kombination von Application Server Central Services und Hochverfügbarkeit von Datenbanken in einem einzigen RHEL-Pacemaker-Cluster. Um diese Einschränkung zu beseitigen, ordnen Sie die Komponenten separaten Clustern zu. Sie können jedoch bis zu fünf Central Services-Cluster in einem VM-Paar kombinieren.
Verwenden Sie für die BCDR in SAP folgende Dienste, um SAP Central Services-Cluster auszuführen:
- RHEL-Pacemaker-Cluster: STONITH-Blockgeräte werden nicht unterstützt, aber Sie können den Azure-Fence-Agent nutzen.
- SAP-zertifizierte, nicht von Microsoft stammende Clustersoftware: Erkunden Sie diese Option, wenn sie Ihren Anforderungen entspricht.
Wählen Sie den entsprechenden Dienst basierend auf Ihren spezifischen Anforderungen und Ihrem Betriebssystem aus.
Weitere Informationen finden Sie unter:
- Konfigurieren eines Red Hat-Hochverfügbarkeitsclusters in Microsoft Azure für RHEL 9
- Konfigurieren und Verwalten von Hochverfügbarkeitsclustern für RHEL 9
- RHEL 8-Dokumentation
Azure Compute Gallery-Replikate
Sie können Compute Gallery verwenden, um Golden Images für Bereitstellungen zu speichern. Verwenden Sie diese Images für die Notfallwiederherstellung von Anwendungen und Tools. Compute Gallery kann hochverfügbare Ressourcen mit ZRS-Konten (Zonenredundanter Speicher) in Regionen verwenden, die Verfügbarkeitszonen unterstützen. ZRS bietet Resilienz gegenüber Zonenausfällen. Sie können Katalogimages auch in anderen Regionen oder Geografien replizieren.
Hinweis
Es wird empfohlen, mindestens zwei Kataloge in verschiedenen Regionen zu verwenden.
Site Recovery
Mit Site Recovery kann die Resilienz einiger RHEL-Komponenten verbessert werden. Eine Liste der unterstützten RHEL-basierten Site Recovery-Server finden Sie unter Unterstützungsmatrix für die Azure-VM-Notfallwiederherstellung mit Site Recovery. Sie können Site Recovery auch als Failover von lokalen Umgebungen in der Cloud einrichten. Mithilfe des Site Recovery-Bereitstellungsplaners erhalten Sie eine Schätzung der Site Recovery-Kosten.
Wiederherstellungsclusterknoten
Um RTOs zu reduzieren und die Resilienz zu erhöhen, können Sie aktive Remoteknoten oder Standbyremoteknoten für Wiederherstellungscluster verwenden. Sie müssen Clusterelemente für die Notfallwiederherstellung manuell konfigurieren. Sie müssen z. B. Konfigurationen anwenden, um Ressourcen einzurichten und Daten zu kopieren.