Was sind Redundanz, Replikation und Sicherung?

Wir denken oft an die Cloud als global verteiltes, allgegenwärtiges System. In Wirklichkeit besteht die Cloud jedoch aus Hardware, die in Rechenzentren ausgeführt wird. Resilienz erfordert, dass Sie einige der Risiken berücksichtigen, die mit den physischen Standorten verbunden sind, an denen Ihre in der Cloud gehosteten Komponenten ausgeführt werden.

Dieser Artikel enthält eine allgemeine Einführung in Redundanz, Replikation und Sicherung, bei denen es sich um Methoden handelt, die zum Erstellen von Workloads verwendet werden, die für physische Risiken widerstandsfähig sind, was zu Dienstunterbrechungen, Ausfall oder Datenverlust führt.

Redundanz ist die Möglichkeit, mehrere identische Kopien einer Dienstkomponente beizubehalten und diese Kopien auf eine Weise zu verwenden, die verhindert, dass eine Komponente zu einem einzigen Fehlerpunkt wird.

Replikation oder Datenredundanz ist die Möglichkeit, mehrere Kopien von Daten zu verwalten, die als Replikate bezeichnet werden.

Sicherung ist die Möglichkeit, eine zeitstempelte Kopie von Daten beizubehalten, die zum Wiederherstellen verloren gegangener Daten verwendet werden können.

Aus Zuverlässigkeitsperspektive besteht eine wichtige Möglichkeit, um viele Risiken zu minimieren, besteht darin, eine Art von Redundanz, Replikation oder Sicherung in Ihre Geschäftskontinuitätsplanung einzubeziehen.

Redundanz

Redundanz besteht aus der Bereitstellung mehrerer Instanzen einer Komponente. Während Redundanz einfach zu verstehen ist, kann es in einigen Situationen komplex werden, um sie zu implementieren.

Wenn Sie mit der Redundanz beginnen, ist es am einfachsten, Redundanz in Bezug auf zustandslose Komponenten zu berücksichtigen, bei denen es sich um Komponenten handelt, die keine Daten speichern. Obwohl die meisten realen Lösungen die Verwaltung des Zustands erfordern, besprechen wir in diesem Abschnitt Redundanz in Bezug auf eine beispiellose Anwendungsprogrammierschnittstelle (API). Die Beispiel-API akzeptiert Eingaben, arbeitet an dieser Eingabe und gibt dann eine Ausgabe zurück, ohne Daten zu speichern. Im nachfolgenden Abschnitt "Replikation: Redundanz für Daten" fügen wir Überlegungen zur zustandsbehafteten Redundanz hinzu.

Szenario: Zustandslose Redundanz

In diesem Beispiel wird eine zustandslose API-Komponente auf einem virtuellen Computer bereitgestellt. Um Ausfallzeiten für die API-Komponente zu vermeiden, wenn ein Hardwarefehler auf dem physischen Host auftritt, implementiert das Beispiel eine redundante Lösung, die:

• Stellt mehrere Kopien der API-Instanz bereit.
• Implementiert ein Lastenausgleichsmodul zum Verteilen von Anforderungen zwischen API-Instanzen.

Der Load Balancer überwacht die Gesundheit jeder Instanz, um Anforderungen nur an funktionierende Instanzen zu senden.

Überlegungen zur Redundanz

Bei der Implementierung redundanter Lösungen, z. B. im obigen Szenario, ist es wichtig, Folgendes zu berücksichtigen:

• Ressourcenkosten. Standardmäßig umfasst Redundanz mehrere Kopien von Etwas, wodurch die Gesamtkosten zum Hosten der Lösung erhöht werden.

• Leistung Je weiter Sie die Kopien der Objekte in einem geografischen Gebiet verteilen, desto mehr tragen Sie zur Risikominderung bei. Anfragen von Clients benötigen jedoch mehr Zeit, um längere Entfernungen zurückzulegen, da sie mehr Netzwerkinfrastruktur durchqueren müssen, was die Netzwerklatenz erhöht.

  In den meisten realen Situationen ist die Netzwerklatenz für kurze Entfernungen inkonsequent, z. B. innerhalb eines Rechenzentrums oder sogar zwischen Rechenzentren in einer Stadt. Wenn Sie Jedoch Kopien über eine lange Entfernung verteilen, kann die Netzwerklatenz erheblicher werden.

• Konsistenz von Instanzen. Es ist wichtig, Instanzen miteinander konsistent zu halten und das Konfigurieren von Instanzen einzeln zu vermeiden, da Sie möglicherweise versehentlich Unterschiede zwischen den Instanzen einführen. Wenn es Unterschiede zwischen Instanzen gibt, werden Anforderungen je nachdem, welche Instanz sie bedient, möglicherweise unterschiedlich verarbeitet. Dies kann zu schwer zu diagnostizierenden Fehlern und Verhaltensweisen führen.

• Verteilung der Arbeit. Wenn Sie über mehrere Instanzen einer Komponente verfügen, müssen Sie Arbeit unter ihnen verteilen. Sie können die Arbeit auf alle Instanzen gleichmäßig verteilen, oder Sie senden Anforderungen an eine einzelne primäre Instanz und verwenden nur eine sekundäre Instanz, wenn die primäre Instanz nicht verfügbar ist.

  Für Komponenten, die eingehende Anforderungen empfangen, werden Lastenausgleichsgeräte häufig verwendet, um diese Anforderungen an Instanzen zu senden. Manchmal funktionieren Komponenten jedoch unabhängig und empfangen keine Anforderungen von Clients. In diesen Situationen müssen Instanzen ihre Arbeit möglicherweise miteinander koordinieren.

• Systemüberwachung. Die Integrität jeder Instanz bestimmt, ob diese Instanz ihre Arbeit erledigen kann, und die Integritätsüberwachung ist wichtig, um eine schnelle Wiederherstellung zu ermöglichen, wenn ein Problem vorliegt.

  Lastenausgleichsgeräte führen in der Regel eine Integritätsüberwachung durch. Für Komponenten, die keinen Lastverteiler enthalten, haben Sie möglicherweise eine externe Komponente, die den Gesundheitszustand aller Instanzen überwacht, oder jede Instanz kann den Gesundheitszustand anderer Instanzen überprüfen.

Physische Standorte in der Cloud

Die Notwendigkeit von Redundanz ist klar, wenn Sie verstehen, dass selbst in einer Cloudumgebung eine Instanz oder ein Datenteil an einem bestimmten physischen Ort gespeichert wird.

Beispiel:

• Ein virtueller Computer wird jederzeit an einem einzigen physischen Ort ausgeführt.
• Daten werden an einem bestimmten physischen Speicherort gespeichert, z. B. auf einem Solid-State-Laufwerk (SSD) oder einer Festplatte, die mit Servern verbunden ist.

Selbst wenn mehrere Kopien eines Datenteils oder instanzen einer Komponente vorhanden sind, ist jede Kopie an die physische Hardware gebunden, auf der sie gespeichert ist.

Der physische Standort einer Cloudumgebung als Ganzes kann in physische Bereiche unterteilt werden. Auf jedem physischen Bereich gibt es potenzielle Risiken, die die Komponenten oder Daten innerhalb dieses Bereichs kompromittieren könnten. Nachfolgend finden Sie eine nicht erschöpfende Liste von Risiken, die im Hinblick auf den physischen Umfang definiert werden können:

Aus Zuverlässigkeitsperspektive besteht eine wichtige Möglichkeit, die mit einem physischen Bereich verbundenen Risiken zu minimieren, darin, Instanzen einer Komponente auf verschiedene physische Bereiche zu verteilen. Azure-Dienste mit integrierter Redundanz bieten Ihnen möglicherweise eine oder mehrere der folgenden drei Möglichkeiten zum Bereitstellen redundanter Instanzen:

• Lokale Redundanz platziert Instanzen in mehreren Teilen eines einzelnen Azure-Rechenzentrums und schützt vor Hardwarefehlern, die sich auf eine einzelne Instanz auswirken können. Lokale Redundanz bietet in der Regel die niedrigsten Kosten und Latenz. Ein Rechenzentrumsfehler könnte jedoch bedeuten, dass alle Instanzen nicht verfügbar sind.

• Zonenredundanz verteilt Instanzen über mehrere Verfügbarkeitszonen in einer einzelnen Azure-Region. Zonenredundanz schützt vor Rechenzentrumsfehlern zusätzlich zu Hardwarefehlern.

• Georedundanz platziert Instanzen in mehreren Azure-Regionen und bietet Schutz vor großen regionalen Ausfällen. Georedundanz kommt zu höheren Kosten und erfordert eine Berücksichtigung des umfassenderen Lösungsdesigns und der Umstellung zwischen Instanzen Ihrer Komponenten in den einzelnen Regionen. Sie müssen auch die Latenz berücksichtigen, die in synchroner und asynchroner Replikation beschrieben wird.

Funktionsweise von Redundanz in Azure: Computedienste

Redundanz wird in fast jedem Teil von Azure eingesetzt. Als Beispiel für die Implementierung von Redundanz in Azure sollten Sie die Dienste berücksichtigen, die Computeworkloads ausführen.

In Azure wird ein einzelner virtueller Computer (VM) auf einem einzelnen physischen Host in einem Azure-Rechenzentrum ausgeführt. Sie können Azure Anweisungen bereitstellen, um sicherzustellen, dass der virtuelle Computer an dem gewünschten Ort ausgeführt wird, z. B. die Region und Verfügbarkeitszone, und in einigen Situationen möchten Sie ihn möglicherweise sogar auf einem Host platzieren, der Ihnen gewidmet ist.

Es ist üblich, mehrere Instanzen eines virtuellen Computers auszuführen. In diesem Szenario können Sie sie entweder einzeln oder mithilfe eines Skalierungssatzes für virtuelle Computer verwalten. Wenn Sie einen Skalierungssatz verwenden, können Sie immer noch die einzelnen virtuellen Computer sehen, die sie unterstützen, aber der Skalierungssatz bietet eine Reihe von Funktionen, um redundante VMs zu verwalten. Zu diesen Funktionen gehören die automatische Platzierung der virtuellen Computer basierend auf von Ihnen angegebenen Regeln, z. B. indem sie über Fehlerdomänen innerhalb der Region oder Verfügbarkeitszone verteilt werden.

Es gibt viele andere Azure-Computedienste, die auf virtuellen Computern angewiesen sind, um Computeaufgaben auszuführen. Computedienste bieten in der Regel verschiedene Redundanzeinstellungen, die bestimmen, wie die virtuellen Computer verteilt werden. Beispielsweise kann ein Dienst eine Zonenredundanzeinstellung bereitstellen, mit der Sie virtuelle Computer automatisch über Verfügbarkeitszonen verteilen und den Lastenausgleich konfigurieren können.

Replikation: Redundanz für Daten

Redundanz wird bei Anwendung auf Zustand (Daten) als Replikation bezeichnet. Mit der Replikation können Sie mehrere Echtzeit- oder Nahezu-Echtzeit-Kopien von Livedaten verwalten, die als Replikate bezeichnet werden. Um die Resilienz gegenüber Risiken zu verbessern, können Sie Replikate an verschiedenen Standorten verteilen. Wenn ein Replikat nicht verfügbar ist, schlägt das System möglicherweise fehl, sodass ein anderes Replikat seine Funktion übernimmt.

Es gibt unterschiedliche Replikationstypen, und jede legt unterschiedliche Prioritäten auf Datenkonsistenz, Leistung und Kosten. Jeder Replikationstyp wirkt sich auf zwei wichtige Metriken aus, die in Diskussionen über geschäftskontinuität verwendet werden: Wiederherstellungszeitziel (RTO), bei dem es sich um die maximale Anzahl von Ausfallzeiten handelt, die Sie in einem Notfallszenario tolerieren können, und das Ziel des Wiederherstellungspunkts (Recovery Point Objective , RPO), was die maximale Menge an Datenverlusten ist, die Sie in einem Notfallszenario tolerieren können. Weitere Informationen zu diesen Metriken und ihrer Beziehung zu Geschäftskontinuität finden Sie unter "Was sind Geschäftskontinuität, hohe Verfügbarkeit und Notfallwiederherstellung?"

Aufgrund der Bedeutung der Replikation bei der Erfüllung der Funktionalen und Leistungsanforderungen umfassen die meisten Datenbanksysteme und andere Datenspeicherprodukte und -dienste eine Art Replikation als eng integrierte Funktion. Die Arten der Replikation, die sie anbieten, basieren in der Regel auf ihrer Architektur und den Möglichkeiten, wie sie verwendet werden sollen. Informationen zu den Replikationstypen, die von Azure-Diensten unterstützt werden, finden Sie in den Anleitungen zur Zuverlässigkeit des Azure-Diensts.

Synchrone und asynchrone Replikation

Wenn Sie Daten replizieren, müssen alle Änderungen an diesen Daten zwischen Replikaten synchronisiert werden. Beim Versuch, die Konsistenz bei Datenänderungen aufrechtzuerhalten, gibt es einige wichtige Herausforderungen:

• Latenz. Das Aktualisieren eines Replikats dauert Zeit, und je weiter auseinander die Replikate sind, desto länger dauert es, Daten über den Abstand zwischen den Replikaten zu übertragen und eine Bestätigung zu erhalten.

• Änderungsverwaltung. Daten können sich ändern, während Replikas synchronisiert werden, und daher kann die Verwaltung der Datenkonsistenz komplex werden.

Um diese Herausforderungen zu bewältigen, gibt es zwei Hauptmethoden, wie Sie Datenänderungen replizieren und die Datenkonsistenz verwalten können:

• Die synchrone Replikation erfordert Aktualisierungen für mehrere Replikate, bevor das Update als abgeschlossen betrachtet wird. Das folgende Diagramm veranschaulicht, wie die synchrone Replikation funktioniert:

  

  In diesem Beispiel erfolgt die folgende Abfolge der Schritte:

  1. Ein Client ändert die Daten, und die Anforderung wird an Replikat 1 gesendet, wodurch die Anforderung verarbeitet und die geänderten Daten gespeichert werden.
  2. Replikat 1 sendet die Änderungen an Replikat 2, die die Anforderung verarbeitet und die geänderten Daten speichert.
  3. Replikat 2 bestätigt die Zurückänderung zu Replikat 1.
  4. Replikat 1 bestätigt die Zurückänderung zu dem Client.

  Die synchrone Replikation kann Konsistenz garantieren, was bedeutet, dass sie ein RPO mit Null unterstützen kann. Dies kommt jedoch zu leistungseinbußen. Je weiter auseinander Ihre Replikate geografisch sind und je mehr Netzwerkhüpfungen durchlaufen werden müssen, desto mehr Latenz wird durch den Replikationsprozess eingeführt.

• Die asynchrone Replikation erfolgt im Hintergrund. Das folgende Diagramm veranschaulicht, wie die asynchrone Replikation funktioniert:

  

  In diesem Beispiel erfolgt die folgende Abfolge der Schritte:

  1. Ein Client ändert die Daten, und die Anforderung wird an Replikat 1 gesendet.
  2. Replikat 1 verarbeitet die Anforderung, speichert die geänderten Daten und erkennt die Änderung sofort wieder an den Client an.
  3. Zu einem späteren Zeitpunkt synchronisiert Replikat 1 die Änderung mit Replikat 2.

  Da die asynchrone Replikation außerhalb von Transaktionsflüssen erfolgt, wird die Replikation als Einschränkung für die Anwendungsleistung entfernt. Wenn Sie jedoch zu einem anderen Replikat wechseln müssen, verfügt es möglicherweise nicht über die neuesten Daten, und Ihr RPO muss größer als 0 sein. Das genaue RPO, das die asynchrone Replikation unterstützen kann, hängt von der Replikationshäufigkeit ab.

Replikatrollen

In vielen Replikationssystemen können Replikate unterschiedliche Rollen übernehmen, was dazu beiträgt, Änderungen an Daten zu koordinieren und die Wahrscheinlichkeit von Konflikten zu verringern. Es gibt zwei Haupttypen von Rollen, aktiv und passiv. Es gibt zwei gängige Methoden zum Verteilen von Replikaten mit diesen Rollen:

• Die aktive passive Replikation bedeutet, dass Sie über ein aktives Replikat verfügen, das für das Handeln als Wahrheitsquelle verantwortlich ist. Alle An den Daten vorgenommenen Änderungen müssen auf dieses Replikat angewendet werden. Alle anderen Replikate fungieren in einer passiven Rolle, was bedeutet, dass sie Aktualisierungen der Daten aus dem aktiven Replikat erhalten, aber keine Änderungen direkt von Clients verarbeiten. Passive Repliken werden nicht für Live-Traffic verwendet, es sei denn, es tritt ein Failover ein; in diesem Fall ändern sich die Rollen der Repliken. Das folgende Diagramm zeigt ein aktiv-passives System mit einem passiven Replikat:

  

  In einem aktiv-passiven System bestimmt die Dauer des Failovers die RTO. Häufig wird der RTO für ein aktiv-passives System in Minuten gemessen.

  Einige Replikationslösungen unterstützen auch schreibgeschützte Replikate, mit denen Sie Daten aus den passiven Replikaten lesen (aber nicht schreiben) können. Dieser Ansatz kann nützlich sein, um mehr Auslastung von Replikaten zu erzielen, z. B. wenn Sie Analysen oder Berichte zu Daten durchführen müssen, ohne dass sich dies auf das primäre Replikat auswirkt, das Sie für die Transaktionsarbeit Ihrer Anwendung verwenden. Mehrere Azure-Dienste unterstützen schreibgeschützte Replikate, einschließlich Azure Storage mit dem ReplikationstypRA-GRS (Read Access GRS) und der aktiven Georeplikationder Azure SQL-Datenbank.

• Die aktive-aktive Replikation ermöglicht die gleichzeitige Verwendung mehrerer aktiver Replikate für den Livedatenverkehr, und alle Replikate können Anforderungen verarbeiten:

  

  Die aktive Replikation ermöglicht eine hohe Leistung, da das System die Ressourcen für alle Replikate verwenden kann. Die aktive Replikation kann in manchen Situationen ein RTO von Null unterstützen. Diese Vorteile ergeben sich jedoch durch die Komplizierung der Datenkonsistenz, da gleichzeitig konkurrierende Änderungen an mehreren Replikaten asynchron abgeglichen werden müssen.

Komplexe Datendienste können sowohl die aktive als auch die passive Replikation kombinieren. Sie können z. B. eine Gruppe von Replikaten in einer Azure-Region und eine andere in einer anderen Region bereitstellen. Innerhalb jeder Region behandelt ein einzelnes aktives Replikat Anfragen, während ein oder mehrere passive Replikate für ein Failover bereitstehen. In der Zwischenzeit arbeiten beide Regionen in einem aktiven Modell, sodass datenverkehrsübergreifend verteilt werden kann.

Funktionsweise der Replikation in Azure-Datendiensten

Jeder Azure-Dienst, der Daten speichert, bietet eine Art Replikation. Jeder Dienst kann jedoch einen anderen Ansatz verwenden, der für die Architektur des Diensts und die beabsichtigten Verwendungen spezifisch ist.

Azure Storage kann beispielsweise über eine Reihe von Funktionen sowohl synchrone als auch asynchrone Replikation bereitstellen:

• Mehrere Kopien Ihrer Daten werden synchron innerhalb Ihrer primären Region repliziert. Sie können auswählen, ob Replikate auf unterschiedlicher physischer Hardware in einem einzelnen Rechenzentrum in einem lokalen redundanten Speicher (LRS) platziert oder über mehrere Verfügbarkeitszonen für den zonenredundanten Speicher (ZRS) verteilt werden sollen.
• Wenn Ihre primäre Region gekoppelt ist und Sie georedundanten Speicher (GRS) aktivieren, werden die Daten auch in die gekoppelte Region repliziert. Da gekoppelte Regionen geografisch weit entfernt sind, geschieht diese Replikation asynchron, um die Auswirkungen auf den Anwendungsdurchsatz zu verringern.
• Sie können den zonenredundanten Speicher und den georedundanten Speicher gleichzeitig verwenden, indem Sie die geozone-redundante Speicherebene (GZRS) verwenden. Daten innerhalb der Region werden synchron repliziert, und Daten in allen Regionen werden asynchron repliziert.

Weitere Informationen finden Sie unter Azure Storage-Redundanz.

Ein weiteres Beispiel ist Azure Cosmos DB, das auch die Replikation bereitstellt. Alle Azure Cosmos DB-Datenbanken verfügen über mehrere Replikate. Wenn Sie Replikate global verteilen, unterstützt sie Schreibvorgänge mit mehreren Regionen, in denen Clients in ein Replikat in einer der von Ihnen verwendeten Regionen schreiben können. Diese Schreibvorgänge werden synchron innerhalb der Region repliziert und dann asynchron in anderen Regionen repliziert. Azure Cosmos DB bietet einen Konfliktlösungsmechanismus für den Fall, dass in den verschiedenen Replikaten Schreibkonflikte auftreten. Weitere Informationen finden Sie in der globalen Datenverteilung mit Azure Cosmos DB – unter der Haube.

Wenn Sie virtuelle Computer verwenden, können Sie Azure Site Recovery verwenden, um virtuelle Computer und deren Datenträger zwischen Verfügbarkeitszonen oder in eine andere Azure-Region zu replizieren.

Wenn Sie eine Azure-Lösung entwerfen, lesen Sie die Zuverlässigkeitsleitfäden für jeden Dienst , um zu verstehen, wie dieser Dienst Redundanz und Replikation bereitstellt, einschließlich an verschiedenen Standorten.

Datensicherung

Die Sicherung erstellt eine Kopie Ihrer Daten zu einem bestimmten Zeitpunkt. Wenn ein Problem vorliegt, können Sie die Sicherung später wiederherstellen . Alle Änderungen an Ihren Daten, die nach dem Erstellen der Sicherung aufgetreten sind, befinden sich jedoch nicht in der Sicherung und gehen möglicherweise verloren.

Mithilfe der Sicherung können Sie Lösungen bereitstellen, um Ihre Daten in oder in der Microsoft Azure-Cloud zu sichern und wiederherzustellen. Backup kann Sie vor einer Vielzahl von Risiken schützen, darunter:

• Katastrophale Verluste von Hardware oder anderer Infrastruktur.
• Datenbeschädigung und -löschung.
• Cyberangriffe wie Ransomware.

Wie die Sicherung Ihre Anforderungen beeinflusst

Bei Verwendung als Teil einer Notfallwiederherstellungsstrategie unterstützen Sicherungen in der Regel ein RTO und RPO, das in Stunden gemessen wird:

• RTO wird durch die Zeit beeinflusst, die es dauert, bis Sie Ihre Wiederherstellungsprozesse initiieren und abschließen können, einschließlich der Wiederherstellung einer Sicherung und der Überprüfung, dass die Wiederherstellung erfolgreich abgeschlossen wurde. Je nach Größe der Sicherung und wie viele Sicherungsdateien gelesen werden müssen, ist es üblich, dass es mehrere Stunden oder sogar länger dauert, bis eine Sicherung vollständig wiederhergestellt wird.

• RPO wird durch die Häufigkeit Ihres Sicherungsvorgangs beeinflusst. Wenn Sie Sicherungen häufiger ausführen, bedeutet dies, dass weniger Daten verloren gehen, wenn Sie aus einer Sicherung wiederherstellen müssen. Sicherungen erfordern jedoch Speicher, und in einigen Fällen können sie sich auf die Leistung des Diensts auswirken, während Sicherungen ausgeführt werden. Aus diesem Grund müssen Sie die Sicherungshäufigkeit berücksichtigen und das richtige Gleichgewicht für die Anforderungen Ihrer Organisation finden. Die Sicherungshäufigkeit sollte bei der Planung der Geschäftskontinuität berücksichtigt werden.

Einige Sicherungssysteme unterstützen komplexere Sicherungsanforderungen, einschließlich mehrerer Sicherungsebenen mit unterschiedlichen Aufbewahrungszeiträumen und differenzielle oder inkrementelle Sicherungen, die schneller zu sparen und weniger Speicherplatz verbrauchen.

Sicherung in Azure-Diensten

Viele Azure-Dienste bieten Sicherungsfunktionen für Ihre Daten.

Azure Backup ist eine dedizierte Sicherungslösung für mehrere wichtige Azure-Dienste, einschließlich virtueller Computer, Azure Storage und Azure Kubernetes Service (AKS).

Außerdem bieten viele verwaltete Datenbanken ihre eigenen Sicherungsfunktionen als Teil des Diensts, z. B.:

• Azure SQL-Datenbank stellt automatisierte Sicherungen bereit.
• Azure Cosmos DB bietet sowohl kontinuierliche als auch regelmäßige Sicherungsfunktionen.
• Mit Azure Key Vault können Sie eine Sicherung der Daten in Ihrem Tresor herunterladen.
• Azure App Service bietet sowohl automatische als auch benutzerdefinierte Sicherung für Webanwendungen und kann ihre Datenbanken sichern.

Sicherung im Vergleich zur Replikation

Sicherung und Replikation schützen Sie jeweils vor unterschiedlichen Risiken, und die beiden Ansätze ergänzen sich gegenseitig.

Die Replikation unterstützt die tägliche Resilienz und wird häufig in einer Hochverfügbarkeitsstrategie verwendet. Einige Replikationsansätze erfordern wenig bis zu keine Ausfallzeiten oder Datenverluste und unterstützen ein niedriges RTO und RPO. Die Replikation schützt Sie jedoch nicht vor Risiken, die zu Datenverlusten oder Beschädigungen führen.

Im Gegensatz dazu ist Backup oft eine letzte Verteidigungslinie gegen katastrophale Risiken. Sicherungen erfordern häufig ein relativ hohes RTO und RPO, wobei die Konfiguration der Sicherungen genau beeinflusst, wie hoch diese Werte sein werden. Eine vollständige Wiederherstellung aus einer Sicherung ist häufig Teil eines Notfallwiederherstellungsplans.

Vorbereiten von Komponenten für Redundanz

Wenn Sie ein System entwerfen, das Redundanz als Teil seiner Architektur verwendet, ist es wichtig, auch folgendes zu berücksichtigen:

• Doppelte Ressourcenkonfiguration zur Konsistenz.
• Verwalten Sie die Kapazität bei Instanzfehlern, indem Sie Überbereitstellung nutzen.

Doppelte Ressourcenkonfiguration

In Cloudumgebungen ist die Konfiguration jeder Ihrer Ressourcen wichtig. Wenn Sie beispielsweise einen Netzwerklastenausgleich erstellen, konfigurieren Sie eine Vielzahl von Einstellungen, die sich auf die Funktionsweise auswirken. und wenn Sie eine Funktion mithilfe von Azure-Funktionen bereitstellen, konfigurieren Sie Einstellungen im Zusammenhang mit Sicherheit, Leistung und Anwendungskonfigurationseinstellungen. Jede Ressource in Azure verfügt über eine Art von Konfiguration, die das Verhalten steuert.

Wenn Sie redundante Kopien von Ressourcen an verschiedenen Stellen verwalten, ist es wichtig, dass Sie deren Konfiguration steuern. Viele Einstellungen müssen auf die gleiche Weise für jede Kopie eingerichtet werden, damit sich die Ressourcen auf die gleiche Weise verhalten. Einige Einstellungen können jedoch zwischen jeder Kopie unterschiedlich sein, z. B. Verweise auf das virtuelle Netzwerk einer bestimmten Region.

Ein gebräuchlicher Ansatz, Konsistenz innerhalb Ihrer Ressourcen beizubehalten, besteht darin, Infrastruktur als Code (IaC) zu verwenden, z. B. Bicep oder Terraform. Mit diesen Tools können Sie Dateien erstellen, die eine Ressource definieren, und Sie können diese Definitionen für jede Instanz der Ressource wiederverwenden. Mithilfe von IaC können Sie den Aufwand für die Erstellung und Verwaltung mehrerer Instanzen von Ressourcen für Resilienzzwecke verringern, und es gibt auch viele weitere Vorteile. Weitere Informationen finden Sie unter Was ist Infrastruktur als Code (IaC)? und Empfehlungen für die Verwendung der Infrastruktur als Code.

Verwalten der Kapazität mit Überbereitstellung

Wenn eine Instanz fehlschlägt, unterscheidet sich die Gesamtkapazität des Systems möglicherweise von der Kapazität, die bei fehlerfreien Vorgängen erforderlich ist. Angenommen, Sie verfügen in der Regel über sechs Instanzen eines Webservers, um ihren eingehenden Webdatenverkehr zu verarbeiten, und diese Instanzen sind in gleicher Weise auf drei Azure-Verfügbarkeitszonen in einer Region verteilt:

Wenn eine Verfügbarkeitszone einen Ausfall erlebt, verlieren Sie möglicherweise vorübergehend zwei Instanzen und bleiben mit nur vier Webserverinstanzen erhalten. Wenn Ihre Anwendung in der Regel ausgelastet ist und alle sechs Instanzen für den normalen Datenverkehr erforderlich sind, kann die Ausführung mit einer reduzierten Kapazität die Leistung Ihrer Lösung beeinträchtigen.

Um auf Fehler vorzubereiten, können Sie die Kapazität Ihres Diensts überlasten . Durch Überbereitstellung kann die Lösung einen gewissen Kapazitätsverlust tolerieren und ohne beeinträchtigte Leistung weiter funktionieren.

Führen Sie die folgenden Schritte aus, um zusätzliche Instanzen Ihres Webservers bereitzustellen, die den Ausfall einer Verfügbarkeitszone kompensieren:

1. Ermitteln Sie die Anzahl der Instanzen, die Ihre Spitzenarbeitsauslastung erfordert.
2. Ermitteln Sie die Anzahl der Überbereitstellungsinstanzen, indem Sie die Anzahl der Spitzenauslastungsinstanzen mit dem Faktor [(Zonen/(Zonen-1)] multiplizieren.
3. Runden Sie das Ergebnis auf die nächste ganze Zahl auf.

Im vorherigen Beispiel erfordert die Spitzenauslastung sechs Instanzen des Webservers. Daher erfordert die Überbereitstellung insgesamt neun Instanzen:

Nächste Schritte

Erfahren Sie mehr über Failover und Failback.