(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Notfallwiederherstellung und hohe Verfügbarkeit für Azure-Anwendungen

Letzte Aktualisierung: April 2014

Hauptautoren: Michael McKeown, Cloud Solutions Architect (Aditi); Hanu Kommalapati, Principal Technology Evangelist (Microsoft)

Beitragender Autor: Jason Roth

Prüfer: Patrick Wickline, Dennis Mulder, Steve Howard, Tim Wieman, James Podgorski, Ryan-Beere, Shweta Gupta, Harry Chen, Jim Blanchard, Andy Roberts, Christian Els

Einführung

Der Schwerpunkt dieses Dokuments liegt auf der hohen Verfügbarkeit von Anwendungen, die in Azure ausgeführt werden. Eine globale Strategie für hohe Verfügbarkeit umfasst auch den Bereich der Notfallwiederherstellung. Das Planen von Maßnahmen bei Ausfällen und Notfällen in der Cloud setzt voraus, dass Sie Fehler schnell erkennen. Anschließend implementieren Sie eine Strategie, die die berücksichtigt, welche Ausfallzeiten der Anwendung tolerabel sind. Darüber hinaus müssen Sie den Umfang eines Datenverlusts berücksichtigen, der von der Anwendung bei Wiederherstellung ohne nachteilige Geschäftsfolgen toleriert werden kann.

Wenn wir Kunden fragen, ob sie auf vorübergehende und umfassende Ausfälle vorbereitet sind, sind die meisten der Ansicht, dass dies zutreffend ist. Bevor Sie jedoch diese Frage für sich selbst beantworten, probt Ihr Unternehmen das Auftreten dieser Fehler? Testen Sie die Wiederherstellung von Datenbanken, um sicherzustellen, dass die richtigen Prozesse zur Verfügung stehen? Möglicherweise ist dies nicht der Fall. Dies liegt daran, dass das erfolgreiche Wiederherstellen im Notfall umfassender Planungs- und Entwurfsarbeiten bedarf, um diese Prozesse zu implementieren. Wie bei vielen anderen nicht funktionsbezogenen Anforderungen (z. B. der Sicherheit) wird der Notfallwiederherstellung nur selten der vorab erforderliche Aufwand an Analyse und Zeit gewidmet. Zudem verfügen die meisten Kunden nicht über die entsprechenden Mittel, um geografisch verteilte Datencenter mit redundanter Kapazität zu betreiben. Daher werden unternehmenswichtige Anwendungen häufig aus der angemessenen Planung für die Notfallwiederherstellung ausgeschlossen.

Cloud-Plattformen wie Azure bieten geografisch verteilte Datencenters weltweit. Diese Plattformen bieten zudem Funktionen, die die Verfügbarkeit und eine Vielzahl von Notfallwiederherstellungsszenarien unterstützen. Nun kann jede unternehmenswichtige Cloud-Anwendung bei den Notfallvorkehrungen für das System im notwendigen Umfang berücksichtigt werden. In Azure sind in vielen der Dienste Flexibilität und Notfallwiederherstellung integriert. Sie müssen diese Plattformfunktionen sorgfältig untersuchen und durch konkrete Anwendungsstrategien ergänzen.

Dieses Whitepaper beschreibt die erforderlichen Architekturschritte, die ausgeführt werden müssen, um eine Azure-Bereitstellung für Notfälle zu wappnen. Anschließend können Sie den größeren Geschäftskontinuitätsprozess implementieren. Ein Geschäftskontinuitätsplan ist ein Fahrplan, anhand dessen der Geschäftsbetrieb auch unter nachteiligen Bedingungen fortgeführt werden kann. Dabei kann es sich um Technologiefehler wie ausgefallene Dienste oder Naturkatastrophen wie Unwetter oder Stromausfälle handeln. Die Flexibilität von Anwendungen in Bezug auf Notfälle ist nur ein Teil des umfassenderen Notfallwiederherstellungsprozesses im vorliegenden NIST-Dokument: Notfall-Planungshandbuch für IT-Systeme.

In den folgenden Abschnitten werden unterschiedliche Ebenen von Fehlern, Verfahren zu deren Behebung sowie Architekturen zum Umsetzen dieser Verfahren erläutert. Diese Informationen liefern Eingabedaten für Ihre Notfallwiederherstellungsprozesse und -verfahren, um sicherzustellen, dass Ihre Notfallwiederherstellungsstrategie ordnungsgemäß und effizient funktioniert.

Merkmale flexibler Cloud-Anwendungen

Eine Anwendung mit durchdachter Architektur kann Funktionsausfällen auf taktischer Ebene widerstehen und zudem strategische, systemweite Ausfälle auf Datencenterebene tolerieren. In den folgenden Abschnitten werden die im vorliegenden Dokument verwendeten Begriffe beschrieben, mit denen die diversen Aspekte flexibler Cloud-Dienste erläutert werden.

Hohe Verfügbarkeit

In einer Cloud-Anwendung mit hoher Verfügbarkeit werden Strategien implementiert, um den Ausfall erforderlicher Komponenten abzufangen, z. B. der verwalteten Dienste, die von der Cloud-Plattform bereitgestellt werden. Trotz möglicher Ausfälle von Funktionen der Cloud-Plattform lässt dieser Ansatz zu, dass die Anwendung weiterhin mit den erwarteten funktionalen und nicht funktionalen systemischen Merkmalen ausgeführt wird. Dieser Aspekt wird ausführlich im Dokument FailSafe: Leitfaden zu robusten Cloud-Architekturen.

Wenn Sie die Anwendung implementieren, müssen Sie die Wahrscheinlichkeit eines Funktionsausfalls berücksichtigen. Außerdem müssen Sie die Auswirkungen untersuchen, die ein solcher Ausfall für die Anwendung aus geschäftlicher Sicht haben kann, bevor die Beschäftigung mit den Umsetzungsstrategien beginnt. Ohne angemessene Berücksichtigung der Auswirkungen auf das Unternehmen und der Wahrscheinlichkeit, dass die Gefahrensituation tatsächlich eintritt, kann die Implementierung zu aufwändig und ggf. sogar unnötig sein.

Zur Veranschaulichung wird hier ein Beispiel zur hohen Verfügbarkeit aus der Automobilindustrie angeführt. Selbst qualitativ hochwertige Teile und erstklassige Verarbeitung können gelegentliche Ausfälle nicht verhindern. Bei einer Reifenpanne kann ihr Auto zwar weiterhin fahren, seine Funktionstüchtigkeit ist jedoch erheblich eingeschränkt. Wenn Sie einen solchen möglichen Vorfall eingeplant haben, können Sie einen entsprechenden dünnwandigen Reservereifen nutzen, um die nächstgelegene Werkstatt zu erreichen. Sie können mit dem Reservereifen zwar nicht schnell fahren, das Fahrzeug ist jedoch bis zu einem Reifenwechsel weiterhin fahrtüchtig. Auf ähnliche Weise kann ein Cloud-Dienst, bei dem mögliche Ausfälle von Funktionen bereits eingeplant wurden, verhindern, dass ein relativ geringfügiges Problem zum Ausfall der gesamten Anwendung führt. Dies ist selbst dann der Fall, wenn der Cloud-Dienst mit eingeschränktem Funktionsumfang ausgeführt werden muss.

Es gibt mehrere zentrale Eigenschaften von Cloud-Diensten mit hoher Verfügbarkeit: Verfügbarkeit, Skalierbarkeit und Fehlertoleranz. Diese Eigenschaften sind zwar untereinander verbunden, es ist jedoch unerlässlich, jede einzelne und deren Beitrag zur Gesamtverfügbarkeit der Projektmappe zu verstehen.

Verfügbarkeit

Eine verfügbare Anwendung berücksichtigt die Verfügbarkeit ihrer zugrunde liegenden Infrastruktur und der erforderlichen Dienste. Verfügbare Anwendungen können einzelne Fehlerpunkte durch Redundanz und flexibles Design ausgleichen. Bei der Behandlung des Aspekts Verfügbarkeit in Azure muss unbedingt das Konzept der effektiven Verfügbarkeit der Plattform verinnerlicht werden. Bei der effektiven Verfügbarkeit werden die Vereinbarungen zum Servicelevel (SLAs) der einzelnen abhängigen Dienste und deren kumulierte Auswirkung auf die Systemgesamtverfügbarkeit berücksichtigt.

Mit der Systemverfügbarkeit wird der prozentuale Anteil des Zeitfensters angegeben, über den das System betrieben werden kann. So beläuft sich die Verfügbarkeits-SLA von mindestens zwei Instanzen einer Web- oder von Workerrolle in Azure auf 99,95 % (von 100 %). Mit diesem Maß werden weder Leistung noch Funktionalität der Dienste angegeben, die unter diesen Rollen ausgeführt werden. Allerdings wird die effektive Verfügbarkeit des Cloud-Diensts auch durch die verschiedenen SLAs der übrigen abhängigen Dienste beeinflusst. Je mehr dynamische Faktoren innerhalb des Systems vorhanden sind, desto sorgfältiger muss dafür gesorgt werden, dass die Anwendung auf flexible Weise den Verfügbarkeitsanforderungen der jeweiligen Endbenutzer gerecht wird.

Verwenden Sie ggf. die folgenden SLAs für einen Azure-Dienst, der Azure-Dienste verwendet: Server, Azure SQL-Datenbank und Azure-Speicher.

 

Azure-Dienst SLA Potenzielle Ausfallzeit in Minuten/Monat (30 Tage)

Server

99.95%

21.6

SQL-Datenbank

99.90%

43.2

Speicher

99.90%

43.2

Bei der Planung müssen Sie davon ausgehen, dass alle Dienste zu verschiedenen Zeitpunkten ausfallen können. In diesem Beispiel beläuft sich die Gesamtzahl der Minuten pro Monat, in der die Anwendung inaktiv sein könnte, auf 108 Minuten. Ein Monat mit 30 Tagen hat insgesamt 43.200 Minuten. 108 Minuten sind 0,25 % der Gesamtanzahl der Minuten in einem Monat mit 30 Tagen (43.200 Minuten). Dies liefert Ihnen eine effektive Verfügbarkeit von 99,75 % für den Cloud-Dienst.

Bei Verwendung der in diesem Whitepaper beschriebenen Verfügbarkeitsverfahren können Sie diesen Wert jedoch verbessern. Wenn Sie die Anwendung so konzipieren, dass sie bei Nichtverfügbarkeit der SQL-Datenbank weiterhin ausgeführt wird, können Sie diese Komponente aus der Gleichung entfernen. Dies könnte bedeuten, dass die Anwendung mit eingeschränktem Funktionsumfang ausgeführt wird. Daher sind auch Geschäftsanforderungen zu berücksichtigen. Eine vollständige Liste der Azure-SLAs finden Sie unter Vereinbarungen zum Servicelevel (SLAs).

Skalierbarkeit

Skalierbarkeit wirkt sich direkt auf die Verfügbarkeit aus: Eine Anwendung, die bei gesteigerter Last ausfällt, ist nicht mehr verfügbar. Skalierbare Anwendungen sind in der Lage, einen erhöhten Bedarf mit konsistenten Ergebnissen in akzeptablen Zeitfenstern zu erfüllen. Ein skalierbares System wird horizontal oder vertikal skaliert, um einen Anstieg der Last bei gleich bleibender Leistung zu bewältigen. Vereinfacht ausgedrückt heißt dies, dass beim horizontalen Skalieren weitere Computer der gleichen Größe (Prozessor, Arbeitsspeicher, Bandbreite) hinzugefügt werden, während beim vertikalen Skalieren die Größe der vorhandenen Computer erhöht wird. Für Azure verfügen Sie über vertikale Skalierungsoptionen zum Auswählen diverser Computergrößen für Server. Das Ändern der Computergröße erfordert jedoch eine erneute Bereitstellung. Daher sind die flexibelsten Lösungen auf die horizontale Skalierung ausgelegt. Dies gilt insbesondere für Server, da Sie die Anzahl der ausgeführten Instanzen einer beliebigen Web- oder Workerrolle auf einfache Weise heraufsetzen können. Diese zusätzlichen Instanzen verarbeiten erhöhten Datenverkehr durch das Azure-Webportal, PowerShell-Skripts oder Code. Diese Entscheidung sollte auf einem Anstieg spezieller überwachter Metriken basieren. In diesem Szenario werden die Benutzerleistung bzw. Metriken unter Last nicht wesentlich beeinträchtigt. Normalerweise speichern die Web- und Workerrollen Zustände extern. Auf diese Weise werden ein flexibler Lastenausgleich und eine ordnungsgemäße Verarbeitung von Änderungen an den Instanzanzahlen ermöglicht. Das horizontale Skalieren empfiehlt sich auch für Dienste wie Azure-Speicher, die keine mehrschichtigen Optionen für das vertikale Skalieren bieten.

Cloud-Bereitstellungen sollten als eine Sammlung von Skalierungseinheiten betrachtet werden. Auf diese Weise kann die Anwendung flexibel auf die Durchsatzanforderungen der Endbenutzer reagieren. Die Skalierungseinheiten sind auf der Web- und Anwendungsserverebene einfacher zu visualisieren. Dies liegt daran, dass Azure bereits statuslose Serverknoten durch Web- und Workerrollen bereitstellt. Das Hinzufügen weiterer Server-Skalierungseinheiten zur Bereitstellung hat keine Nebenwirkungen hinsichtlich der Verwaltung des Anwendungsstatus, da Serverskalierungseinheiten statuslos sind. Eine Speicherskalierungseinheit ist zuständig für das Verwalten einer Partition von Daten (strukturiert oder unstrukturiert). Beispiele für Speicher-Skalierungseinheiten sind Azure-Tabellenpartition, -BLOB-Container und -SQL-Datenbank. Selbst die Verwendung mehrerer Azure-Speicherkonten wirkt sich direkt auf die Anwendungsskalierbarkeit aus. Sie müssen einen hochgradig skalierbaren Cloud-Dienst so entwerfen, dass er mehrere Speicherskalierungseinheiten enthält. Wenn eine Anwendung z. B. relationale Daten verwendet, partitionieren Sie die Daten in mehreren SQL-Datenbanken. Auf diese Weise kann der Speicher dem flexiblen Serverskalierungseinheit-Modell genügen. Entsprechend lässt Azure-Speicher Datenpartitionierungsschemas zu, die sorgfältig entworfen werden müssen, damit die Durchsatzanforderungen der Serverebene erfüllt werden. Eine Liste bewährter Methoden zum Entwerfen skalierbarer Cloud-Dienste finden Sie unter Bewährte Vorgehensweisen für den Entwurf umfangreicher Dienste auf Azure Cloud Services.

Fehlertoleranz

Bei Anwendungen muss davon ausgegangen werden, dass jede abhängige Cloud-Funktion zu einem bestimmten Zeitpunkt ausfallen kann und wird. Eine fehlertolerante Anwendung erkennt und umschifft ausgefallene Elemente, sodass sie weiterhin ausgeführt wird und innerhalb eines festgelegten Zeitrahmens die richtigen Ergebnisse zurückgibt. Bei einem vorübergehenden Fehlerzustand wird in einem fehlertoleranten System eine Wiederholungsrichtlinie verfolgt. Bei schwerwiegenderen Fehlern ist die Anwendung in der Lage, Probleme zu ermitteln und ein Failover auf alternative Hardware oder eine Umstellung auf Notfallpläne auszuführen, bis der Fehler behoben wurde. Bei einer zuverlässigen Anwendung kann der Ausfall eines oder mehrerer Teile bewältigt und die Anwendung weiterhin ordnungsgemäß ausgeführt werden. Fehlertoleranten Anwendungen können eine oder mehrere Entwurfsstrategien zugrunde liegen, z. B. Redundanz, Replikation oder beeinträchtigte Funktionalität.

Wiederherstellung im Notfall

Eine Cloud-Bereitstellung funktioniert wegen eines systemischen Ausfalls der erforderlichen Dienste oder der zugrunde liegenden Infrastruktur möglicherweise nicht mehr. Unter solchen Bedingungen löst ein Geschäftskontinuitätsplan den Notfallwiederherstellungsprozess aus. Dieser Prozess schließt normalerweise sowohl Betriebspersonal Mitarbeiter als auch automatisierte Prozeduren ein, um die Anwendung in einem funktionsfähigen Datencenter erneut zu aktivieren. Dies erfordert die Übertragung von Benutzern, Daten und Diensten der Anwendung an das neue Datencenter. Hierbei kommen auch Sicherungsmedien oder die laufende Replikation zur Anwendung.

Erinnern Sie sich an das obige Beispiel, bei dem hohe Verfügbarkeit mit der Fähigkeit verglichen wurde, eine Reifenpanne vorübergehend mit einem Ersatzreifen zu überbrücken. Im Gegensatz dazu umfasst die Notfallwiederherstellung die Schritte, die nach einem Unfall ergriffen werden, wenn das Fahrzeug nicht mehr funktionstüchtig ist. In einem solchen Fall besteht die beste Lösung darin, eine effiziente Möglichkeit zum Wechsel des Fahrzeugs zu finden, beispielsweise durch Anrufen eines Automobilclubs oder eines Bekannten. In diesem Szenario dauert es wahrscheinlich etwas länger, bis Sie wieder unterwegs sind. Außerdem ist die Komplexität bei der Reparatur und Rückkehr zum ursprünglichen Fahrzeug größer. Ebenso ist die Notfallwiederherstellung in einem anderen Rechenzentrum eine komplexe Aufgabe, bei der i. d. R. eine gewisse Ausfallzeit und ein potenzieller Datenverlust auftreten. Für ein besseres Verständnis und eine Bewertung von Notfallwiederherstellungstrategien müssen zwei Begriffe definiert werden: Wiederherstellungszeitvorgabe (Recovery Time Objective, RTO) und Wiederherstellungspunktvorgabe (Recovery Point Objective, RPO).

RTO

Die Wiederherstellungszeitvorgabe (Recovery Time Objective, RTO) ist die maximale Zeitspanne, die bis zur Wiederherstellung der Anwendungsfunktionen eingeräumt wird. Ihre Grundlage sind die Geschäftsanforderungen, und sie ist daher mit der Wichtigkeit der Anwendung verknüpft. Wichtige Geschäftsanwendungen erfordern eine geringe RTO.

RPO

Die Wiederherstellungspunktvorgabe (Recovery Point Objective, RPO) ist das akzeptable Zeitfenster für Datenverlust aufgrund des Wiederherstellungsvorgangs. Wenn die RPO eine Stunde beträgt, müssen die Daten z. B. mindestens einmal pro Stunde vollständig gesichert oder repliziert werden. Wenn die Anwendung in ein alternatives Rechenzentrum übertragen wurde, können Sicherungsdaten aus einem Zeitraum von bis zu einer Stunde fehlen. Ebenso wie die RTO ist für Anwendungen eine möglichst geringe RPO erstrebenswert.

Teil 1: Hohe Verfügbarkeit

Eine Anwendung mit hoher Verfügbarkeit gleicht Schwankungen der Verfügbarkeit, der Last sowie vorübergehende Ausfälle der erforderlichen Dienste und Hardware aus. Die Anwendung wird weiterhin mit einem akzeptablen benutzer- und systembezogenen Reaktionsniveau ausgeführt, das durch Geschäftsanforderungen oder Vereinbarungen zum Servicelevel für die Anwendung definiert wird.

Azure-Funktionen für hohe Verfügbarkeit

Azure bietet viele integrierte Plattformfunktionen, die Anwendungen mit hoher Verfügbarkeit unterstützen. In diesem Abschnitt werden einige dieser Schlüsselfunktionen beschrieben. Eine umfassendere Analyse der Plattform finden Sie unter Technische Dokumentation zur Geschäftskontinuität mit Azure.

Der Azure Fabric Controller (FC) ist für die Bereitstellung und Überwachung des Zustands der Serverinstanzen von Azure verantwortlich. Der Fabric Controller überwacht den Status der Hardware und der Software der Host- und Gastcomputerinstanzen. Wenn ein Fehler festgestellt wird, werden SLAs durch automatisches Verschieben der virtuellen Computerinstanzen erzwungen. Die Server-SLA wird zudem durch das Konzept der Fehler- und Upgradedomänen weiter unterstützt.

Wenn mehrere Rolleninstanzen bereitgestellt werden, stellt Azure diese Instanzen in verschiedenen Fehlerdomänen bereit. Eine Fehlerdomänengrenze ist im Wesentlichen ein anderes Hardwarerack im gleichen Datencenter. Fehlerdomänen reduzieren die Wahrscheinlichkeit, dass ein festgestellter Hardwarefehler den Dienst einer Anwendung unterbricht. Sie können nicht die Anzahl der Fehlerdomänen verwalten, die Ihren Worker- oder Webrollen zugeordnet sind. Der Fabric Controller verwendet dedizierte Ressourcen, die von durch Azure gehosteten Anwendungen getrennt sind. Er ist zu 100 % verfügbar, weil er als Kernstück des Azure-Systems fungiert. Er überwacht und verwaltet Rolleninstanzen über Fehlerdomänen hinweg. In der folgenden Abbildung werden gemeinsam genutzte Azure-Ressourcen dargestellt, die vom Fabric Controller über verschiedene Fehlerdomänen hinweg bereitgestellt und verwaltet werden.

Fehlerdomänenisolation (vereinfachte Ansicht)

Abbildung 1: Fehlerdomänenisolation (vereinfachte Ansicht)

Upgradedomänen ähneln hinsichtlich ihrer Funktion den Fehlerdomänen, sie bieten jedoch Unterstützung für Upgrades und nicht für Fehler. Eine Upgradedomäne ist eine logische Einheit der Instanzentrennung, die festlegt, welche Instanzen in einem bestimmten Dienst zu einem bestimmten Zeitpunkt aktualisiert werden. Für Ihre gehostete Dienstbereitstellung sind standardmäßig fünf Upgradedomänen definiert. Sie können diesen Wert jedoch in der Dienstdefinitionsdatei ändern. Sie verfügen z. B. über acht Instanzen Ihrer Webrolle. Es sind zwei Instanzen in drei Upgradedomänen und zwei Instanzen in einer Upgradedomäne vorhanden. Azure definiert diese Updatesequenz. Sie beruht jedoch auf der Anzahl der Upgradedomänen. Weitere Informationen zu Upgradedomänen finden Sie unter Aktualisieren eines Azure-Diensts.

Zusätzlich zu diesen Plattformfunktionen, die hohe Serververfügbarkeit unterstützen, werden von Azure Funktionen für hohe Verfügbarkeit in seine anderen Dienste eingebettet. Beispielsweise behält Azure-Speicher drei Replikate für alle BLOB-, Tabellen- und Warteschlangendaten bei. Zudem wird die Option der geografischen Replikation geboten, um Sicherungskopien von BLOBs und Tabellen in einem sekundären Datencenter zu speichern. Die Netzwerk für die Inhaltsübermittlung (Content Delivery Network, CDN) ermöglicht das weltweite Zwischenspeichern von BLOBs, um Redundanz und Skalierbarkeit sicherzustellen. Azure SQL-Datenbank behält ebenfalls mehrerer Replikate bei. Sehen Sie zusätzlich zum Whitepaper Technische Dokumentation zur Geschäftskontinuität mit Azure das Whitepaper Bewährte Vorgehensweisen für den Entwurf umfangreicher Dienste auf Azure Cloud Services ein. Dort finden Sie eine umfassende Beschreibung der Plattform-Verfügbarkeitsfunktionen.

Azure stellt zwar eine Reihe von Funktionen bereit, die eine hohe Verfügbarkeit unterstützen. Sie müssen sich jedoch unbedingt mit deren Beschränkungen vertraut machen. Für Server garantiert Azure, dass Ihre Rollen verfügbar sind und ausgeführt werden. Dabei ist jedoch nicht bekannt, ob die jeweilige Anwendung ausgeführt wird oder überlastet ist. Für Azure SQL-Datenbank werden Daten innerhalb des Datencenters synchron repliziert. Bei diesen Datenbankreplikaten handelt es sich nicht um Zeitpunktsicherungen. Für Azure-Speicher werden Tabellen- und BLOB-Daten standardmäßig in ein anderes Datencenter repliziert. Sie können jedoch erst auf die Replikate zugreifen, wenn Microsoft einen Failovervorgang auf den anderen Standort ausführt. Ein Datencenter-Failover wird i. d. R. nur bei einem längeren, das gesamte Datencenter betreffenden Ausfall vorgenommen, und es gibt keine SLA für die Geo-Failoverdauer. Zudem ist zu beachten, dass sich Beschädigungen der Daten schnell auf die Replikate ausbreiten. Aus diesen Gründen müssen Sie die Funktionen für die Plattformverfügbarkeit durch anwendungsspezifische Verfügbarkeitsfunktionen ergänzen. Diese Anwendungsverfügbarkeitsfunktionen beinhalten die BLOB-Momentaufnahmefunktion zum Erstellen von Zeitpunktsicherungen der BLOB-Daten.

Der Schwerpunkt dieses Whitepapers liegt im Wesentlichen auf den Cloud-Diensten, denen ein Platform as a Service (PaaS)-Modell zugrunde liegt. Es gibt jedoch bestimmte Verfügbarkeitsfunktionen für virtuelle Azure-Computer, die auf einem Infrastructure as a Service IaaS-Modell (Infrastructure as a Service) basieren. Sie müssen Verfügbarkeitsgruppen nutzen, um eine hohe Verfügbarkeit für virtuelle Computer zu erreichen. Die Funktion einer Verfügbarkeitsgruppe ähnelt der von Fehler- und Upgradedomänen. Innerhalb einer Verfügbarkeitsgruppe werden die virtuellen Computer von Azure so platziert, dass festgestellte Hardwarefehler und Wartungsaktivitäten keinen Ausfall sämtlicher Computer in der betreffenden Gruppe bewirken. Verfügbarkeitsgruppen müssen die Anforderungen der Azure-SLA für die Verfügbarkeit von virtuellen Computern erfüllen. Weitere Informationen finden Sie unter Verwalten der Verfügbarkeit virtueller Computer. In der folgenden Abbildung werden zwei Verfügbarkeitsgruppen dargestellt, in denen virtuelle Web-Computer bzw. virtuelle SQL Server-Computer gruppiert sind.

Verfügbarkeitsgruppen für Virtuelle Computer in Windows Azure

Abbildung 2: Verfügbarkeitsgruppen für Azure-Virtuelle Computer

Beachten Sie, dass in der vorherigen Abbildung SQL Server auf virtuellen Computern installiert ist und ausgeführt wird. Dies unterscheidet sich von der beschriebenen Azure SQL-Datenbank, bei der die Datenbank als verwalteter Dienst bereitgestellt wird.

Anwendungsstrategien für hohe Verfügbarkeit

Die meisten Anwendungsstrategien für hohe Verfügbarkeit schließen entweder Redundanz oder das Entfernen fester Abhängigkeiten zwischen Anwendungskomponenten ein. Der Anwendungsentwurf sollte die Fehlertoleranz während gelegentlicher Ausfallzeiten von Azure oder Diensten von Drittanbietern unterstützen. In den folgenden Abschnitten werden einige Anwendungsmuster zur Steigerung der Verfügbarkeit der Cloud-Dienste erläutert.

Asynchrone Kommunikation und permanente Warteschlangen

Erwägen Sie die asynchrone Kommunikation zwischen lose gekoppelten Diensten, um die Verfügbarkeit in Azure-Anwendungen zu erhöhen. In einem solchen Muster werden Nachrichten zur späteren Verarbeitung in Speicherwarteschlangen oder in Service Bus-Warteschlangen geschrieben. Wenn die Nachricht in die Warteschlange geschrieben wurde, wird die Steuerung sofort an den Absender der Nachricht zurückgegeben. Die Nachrichtenverarbeitung erfolgt durch eine andere Ebene der Anwendung, die i. d. R. als Workerrolle implementiert ist. Bei einem Ausfall der Workerrolle werden die Nachrichten in der Warteschlange gesammelt, bis der Verarbeitungsdienst wiederhergestellt wurde. Solange die Warteschlange verfügbar ist, besteht keine direkte Abhängigkeit zwischen dem Front End-Absender und dem Nachrichtenprozessor. Auf diese Weise sind keine synchronen Dienstaufrufe erforderlich, die einen Durchsatzengpass in verteilten Anwendungen bewirken können.

Bei einer Variante hiervon werden Azure-Speicher- (BLOBs, Tabellen, Warteschlangen) oder Service Bus-Warteschlangen als Failoverspeicherort für fehlerhafte Datenbankaufrufe genutzt. Beispielsweise tritt wiederholt ein Fehler bei einem synchronen Aufruf eines anderen Diensts (z. B. einer Azure SQL-Datenbank) in der Anwendung auf. Möglicherweise können Sie die Daten in permanenten Speicher serialisieren. Zu einem späteren Zeitpunkt, wenn der Dienst oder die Datenbank wieder online ist, kann die Anwendung die Anforderung aus dem Speicher erneut senden. Der Unterschied in diesem Modell besteht darin, dass der temporäre Speicherort kein fester Bestandteil des Anwendungsworkflows ist. Es wird nur bei Fehlerszenarien verwendet.

In beiden Szenarien verhindern die asynchrone Kommunikation und das Zwischenspeichern, dass ein ausgefallener Back-End-Dienst den Ausfall der gesamten Anwendung bewirkt. Warteschlangen fungieren als logisches Bindeglied. Weitere Anleitungen zur Auswahl des richtigen Warteschlangendiensts finden Sie unter Azure-Warteschlangen und Azure-Servicebus-Warteschlangen – Vergleich und Gegenüberstellung.

Fehlererkennung und Wiederholungslogik

Ein Schlüsselaspekt eines Entwurfs für Anwendungen mit hoher Verfügbarkeit besteht in der Nutzung von Wiederholungslogik innerhalb von Code, sodass ein vorübergehend inaktiver Dienst ordnungsgemäß behandelt wird. Der vom Microsoft Patterns and Practices-Team entwickelte Anwendungsblock zur Behandlung vorübergehender Fehler unterstützt Anwendungsentwickler bei diesem Prozess. Der Begriff "vorübergehend" bezeichnet in diesem Zusammenhang eine temporär vorliegende Bedingung, die nur für einen relativ kurzen Zeitraum auftritt. Im Kontext dieses Whitepapers wird die Verarbeitung vorübergehender Fehler als Bestandteil der Entwicklung einer Anwendung mit hoher Verfügbarkeit gesehen. Beispiele für vorübergehende Fehlerbedingungen sind zeitweilig auftretende Netzwerkfehler und unterbrochene Datenbankverbindungen.

Der Anwendungsblock zur Behandlung vorübergehender Fehler bietet eine vereinfachte Möglichkeit, Fehler innerhalb des Codes auf ordnungsgemäße Weise zu behandeln. Er ermöglicht es Ihnen, die Verfügbarkeit von Anwendungen zu verbessern, indem eine robuste Logik zur Behandlung vorübergehender Fehler hinzugefügt wird. In den meisten Fällen verarbeitet die Wiederholungslogik kurze Unterbrechungen und stellt nach mindestens einem fehlgeschlagenen Versuch die Verbindung zwischen Absender und Empfänger wieder her. Ein erfolgreicher Wiederholungsversuch wird normalerweise von Benutzern der Anwendung nicht einmal bemerkt.

Es gibt drei Möglichkeiten für Entwickler, ihre Wiederholungslogik zu verwalten: inkrementell, in festen Intervallen und exponentiell. Beim inkrementellen Ansatz wird vor jedem Wiederholungsversuch linear zunehmend länger gewartet (z. B. zunächst 1, dann 2, 3 und 4 Sekunden). Bei einem festen Intervall wird vor jedem Wiederholungsversuch derselbe Zeitraum abgewartet (z. B. 2 Sekunden). Eine zufälligere Option bietet die exponentielle Backoff-Verzögerung, bei der länger zwischen den Wiederholungsversuchen gewartet wird. Sie verwendet jedoch ein exponentielles Muster (z. B. 2, 4, 8 und 16 Sekunden).

Die folgende globale Strategie wird im Code verfolgt:

  1. Definieren der Wiederholungsstrategie und -richtlinie

  2. Ausführen des Vorgangs, der zu einem vorübergehenden Fehler führen kann

  3. Aufrufen der Wiederholungsrichtlinie beim Auftreten eines vorübergehenden Fehlers

  4. Abfangen einer endgültige Ausnahme bei Fehlern aller Wiederholungsversuche

Testen Sie Ihre Wiederholungslogik mit simulierten Fehlern, um sicherzustellen, dass Wiederholungsversuche für aufeinanderfolgende Vorgänge keine unvorhergesehenen langen Verzögerungen bewirken. Dies sollte geschehen, bevor das Fehlschlagen des gesamten Tasks konstatiert wird.

Verweisdaten-Muster (hohe Verfügbarkeit)

Verweisdaten sind die schreibgeschützten Daten einer Anwendung. Diese Daten stellen einen Geschäftskontext bereit, in dem die Anwendung während eines Geschäftsvorgangs Transaktionsdaten generiert. Transaktionsdaten sind eine Zeitpunktfunktion der Verweisdaten. Daher hängt ihre Integrität von der Momentaufnahme der Verweisdaten zum Zeitpunkt der Aufzeichnung der jeweiligen Transaktion ab. Diese Definition ist zwar etwas allgemein gehalten, sollte für die Zwecke des vorliegenden Dokuments jedoch ausreichen.

Verweisdaten im Kontext einer Anwendung sind unverzichtbar für deren ordnungsgemäße Ausführung. Sie werden von den jeweiligen Anwendungen erstellt und verwaltet, häufig von Systemen der Masterdatenverwaltung. Diese Systeme sind für den Lebenszyklus der Verweisdaten verantwortlich. Beispiele für Verweisdaten sind Produktkataloge sowie Mitarbeiter-, Teile- und Anlagenstammdaten. Verweisdaten können auch aus externen Quellen stammen, beispielsweise Postleitzahlen oder Steuersätze. Strategien zum Verbessern der Verfügbarkeit von Verweisdaten sind normalerweise unkomplizierter als entsprechende Strategien für Transaktionsdaten. Verweisdaten sind durch den Vorzug gekennzeichnet, dass sie im Wesentlichen unveränderlich sind.

Azure-Webrollen und -Workerrollen, die Verweisdaten nutzen, können zur Laufzeit für autonom erklärt werden, indem die Verweisdaten zusammen mit der Anwendung bereitgestellt werden. Wenn die Größe des lokalen Arbeitsspeichers eine solche Bereitstellung zulässt, kann dies als idealer Status angesehen werden. Eingebettete Datenbankdateien (SQL oder NOSQL) und sogar XML-Dateien, die im lokalen Dateisystem bereitgestellt werden, tragen zur Autonomie von Azure-Serverskalierungseinheiten bei. Sie sollten jedoch über einen Mechanismus verfügen, über den die Daten in den einzelnen Rollen aktualisiert werden, ohne dass eine erneute Bereitstellung erforderlich ist. Platzieren Sie zu diesem Zweck alle Updates der Verweisdaten in einem Cloud-Speicherendpunkt (z. B. Azure-BLOB-Speicher oder Azure SQL-Datenbank). Fügen Sie den einzelnen Rollen Code hinzu. Die Rollen laden die Datenupdates bei ihrem Start auf die Serverknoten herunter. Sie können auch Code hinzufügen, der es einem Administrator ermöglicht, einen Download auf die Rolleninstanzen zu erzwingen. Zum Erhöhen der Verfügbarkeit sollten auch die Rollen einen Satz von Verweisdaten enthalten, für den Fall, dass der Speicher ausfällt. Dadurch können die Rollen mit einem Basissatz von Verweisdaten gestartet werden, bis die Speicherressource für Updates verfügbar wird.

Hohe Verfügbarkeit durch autonome Serverknoten

Abbildung 3: Hohe Verfügbarkeit von Anwendungen durch autonome Serverknoten

Eine wichtige Überlegung für dieses Muster ist die Bereitstellungs- und Startgeschwindigkeit für Ihre Rollen. Wenn Sie beim Starten große Mengen von Verweisdaten bereitstellen oder herunterladen, kann dies die Anlaufdauer für neue Bereitstellungen oder Rolleninstanzen erhöhen. Dies kann jedoch ein akzeptabler Nachteil der Autonomie der sofortigen Verfügbarkeit der Verweisdaten für die einzelnen Rollen sein, da hierbei keine Abhängigkeit von externen Speicherdiensten besteht.

Transaktionsdaten-Muster (hohe Verfügbarkeit)

Transaktionsdaten sind die Daten, die von der Anwendung in einem Geschäftskontext generiert werden. Transaktionsdaten sind eine Kombination aus der Sammlung der Geschäftsprozesse, die die Anwendung implementiert, und der Referenzdaten, die diese Prozesse unterstützen. Beispiele für Transaktionsdaten sind Bestellungen, erweiterte Versandmitteilungen, Rechnungen und CRM-Chancen. Derart generierte Transaktionsdaten werden zu Buchführungszwecken oder zur Weiterverarbeitung in externe Systeme gespeist.

Beachten Sie, dass sich Verweisdaten in den Systemen ändern können, bei denen die Zuständigkeit für diese Daten liegt. Deshalb muss für Transaktionsdaten der Zeitpunktkontext der Verweisdaten gespeichert werden, damit nur minimale externe Abhängigkeiten hinsichtlich ihrer semantischen Konsistenz bestehen. Ein Beispiel: Ein Produkt wird einige Monate nach dem Abschließen einer Bestellung aus dem Katalog entfernt. Die bewährte Methode besteht darin, einen möglichst umfassenden Verweisdatenkontext in die Transaktion einzubetten. Dadurch bleibt die zur Transaktion gehörende Semantik erhalten, selbst wenn sich die Verweisdaten nach dem Erfassen der Transaktion ändern sollten.

Wie bereits erwähnt, führen Architekturen mit losen Kopplungen und asynchroner Kommunikation an sich zu einem höheren Niveau der Verfügbarkeit. Dies gilt ebenso für Transaktionsdaten, die Implementierung ist jedoch komplexer. Herkömmliche Transaktionsaspekte hängen i. d. R. beim Sicherstellen der Transaktion von der Datenbank ab. Wenn Zwischenschichten eingeführt werden, muss der Anwendungscode die Daten auf den verschiedenen Ebenen ordnungsgemäß verarbeiten, um eine hinreichende Konsistenz und Dauerhaftigkeit sicherzustellen.

Die folgende Sequenz beschreibt einen Workflow, bei der die Erfassung von Transaktionsdaten von deren Verarbeitung getrennt ist:

  1. Webserverknoten: Bereitstellen von Verweisdaten.

  2. Externer Speicher: Speichern von Transaktionszwischendaten.

  3. Webserverknoten: Abschließen der Endbenutzertransaktion.

  4. Webserverknoten: Senden der abgeschlossenen Transaktionsdaten zusammen mit dem Verweisdatenkontext an einen temporären permanenten Speicher, der sicherstellt, dass eine vorhersagbare Antwort geliefert wird.

  5. Webserverknoten: Benachrichtigen der Endbenutzer über den Abschluss der Transaktion.

  6. Hintergrundserverknoten: Extrahieren und ggf. Nachverarbeiten und Senden der Transaktionsdaten an ihren endgültigen Speicherort im aktuellen System.

In der folgenden Abbildung wird eine mögliche Implementierung dieses Entwurfs in einem Azure-Cloud-Dienst veranschaulicht.

Hohe Verfügbarkeit durch lose Verbindung

Abbildung 4: Hohe Verfügbarkeit von Anwendungen über lose Kopplung

Die gestrichelten Pfeile in der Abbildung oben zeigen die asynchrone Verarbeitung an. Die Front-End-Webrolle ist über diese asynchrone Verarbeitung nicht informiert. Dies führt dazu, dass die Transaktion mit Verweis auf das aktuelle System an ihrem endgültigen Speicherort gespeichert wird. Aufgrund der Latenzzeit, die durch dieses asynchrone Modell eingeführt wird, können die Transaktionsdaten nicht sofort abgefragt werden. Daher muss jede Einheit der Transaktionsdaten in einem Cache oder einer Benutzersitzung gespeichert werden, um sofortige Anforderungen der Benutzeroberfläche erfüllen zu können.

Daher ist die Webrolle in Bezug auf die restliche Infrastruktur autonom. Ihr Verfügbarkeitsprofil umfasst eine Kombination aus Webrolle und Azure-Warteschlange und nicht die gesamte Infrastruktur. Neben der hohen Verfügbarkeit ermöglicht dieser Ansatz die horizontale Skalierung der Webrolle unabhängig vom Back-End-Speicher. Dieses Hochverfügbarkeitsmodell kann sich auf die Wirtschaftlichkeit der Vorgänge auswirken. Zusätzliche Komponenten wie Azure-Warteschlangen und -Workerrollen können die monatlichen Nutzungskosten beeinflussen.

Beachten Sie, dass in der obigen Abbildung eine Implementierung dieses kopplungsfreien Ansatzes für Transaktionsdaten veranschaulicht wird. Es gibt viele weitere mögliche Implementierungen. Die folgende Liste enthält einige alternative Varianten.

  • Eine Workerrolle kann zwischen der Webrolle und der Speicherwarteschlange platziert werden.

  • Eine Service Bus-Warteschlange kann anstelle einer Azure-Speicherwarteschlange verwendet werden.

  • Das endgültige Ziel kann Azure-Speicher oder ein anderer Datenbankanbieter sein.

  • Der Azure-Cachedienst kann auf der Webebene verwendet werden, um die unmittelbaren Zwischenspeicheranforderungen im Anschluss an die Transaktion zu erfüllen.

Skalierbarkeitsmuster

Neben den in diesem Abschnitt erläuterten Mustern muss unbedingt berücksichtigt werden, dass sich die Skalierbarkeit des Cloud-Diensts direkt auf die Verfügbarkeit auswirkt. Wenn ein Dienst aufgrund gestiegener Last nicht mehr reagiert, gewinnt der Benutzer den Eindruck, dass die Anwendung ausgefallen ist. Befolgen Sie die bewährten Methoden in Bezug auf die Skalierbarkeit, und orientieren Sie sich dabei an der erwarteten Anwendungslast und diesbezüglichen Prognosen für die Zukunft. Generell ist eine Vielzahl von Überlegungen relevant, z. B. ob ein oder mehrere Speicherkonten verwendet werden oder ob die gemeinsame Nutzung für mehrere Datenbanken eingerichtet wird. Auch Strategien für die Zwischenspeicherung spielen eine Rolle. Eine ausführliche Erläuterung dieser Muster finden Sie unter Bewährte Vorgehensweisen für den Entwurf umfangreicher Dienste auf Azure Cloud Services.

Teil 2: Wiederherstellung im Notfall

Hohe Verfügbarkeit bezieht sich auf die Verwaltung vorübergehender Fehler, Notfallwiederherstellung auf den schwerwiegenden Ausfall der Anwendungsfunktionalität. Betrachten Sie z. B. ein Szenario, in dem ein oder mehrere Datencenter ausfallen. In einem Fall solchen Fall muss ein Plan für die Ausführung der Anwendung bzw. den Zugriff auf die Daten außerhalb des Datencenters vorhanden sein. Die Ausführung dieses Plans beinhaltet Personen, Prozesse sowie unterstützende Anwendungen, die die Wiederherstellung der Funktionstüchtigkeit des Systems ermöglichen. Das Funktionalitätsniveau des Diensts während eines Notfalls wird durch die Unternehmensführung sowie die Technologieinhaber bestimmt, die seinen Betriebsmodus während eines Notfalls definieren. Die folgenden Betriebsmodi sind z. B. möglich: vollständige Nichtverfügbarkeit, teilweise Verfügbarkeit (beeinträchtigte Funktionalität oder verzögerte Verarbeitung) oder vollständige Verfügbarkeit.

Azure-Funktionen für die Notfallwiederherstellung

Wie auch bei den Aspekten der Verfügbarkeit gilt, dass Azure die Technische Dokumentation zur Geschäftskontinuität mit Azure bereitstellt, die die Notfallwiederherstellung unterstützen kann. Zudem besteht eine Beziehung zwischen einigen der Verfügbarkeitsfunktionen von Azure und der Notfallwiederherstellung. So erhöht z. B. die Verwaltung von Rollen über Fehlerdomänen hinweg die Verfügbarkeit einer Anwendung. Ohne eine derartige Verwaltung würde sich ein nicht behandelter Hardwarefehler schnell zu einem "Notfallszenario" entwickeln. Daher sollte die richtige Verwendung vieler Verfügbarkeitsfunktionen und -strategien als wichtiger Bestandteil der Absicherung von Anwendungen gegen Notfälle gesehen werden. Dieser Abschnitt geht jedoch über allgemeine Verfügbarkeitsaspekte hinaus und behandelt schwerwiegendere (und seltener auftretende) Notfälle.

Mehrere Datencenter-Regionen

Azure betreibt Datencenters weltweit in vielen verschiedenen Regionen. Dies unterstützt unterschiedliche Notfallwiederherstellungsszenarien, z. B. die vom System bereitgestellte Georeplikation von Azure-Speicher mit sekundären Datencentern. Dies bedeutet jedoch auch, dass Sie einen Cloud-Dienst einfach und kostengünstig an mehreren Standorten rund um den Globus bereitstellen können. Stellen Sie dieser Möglichkeit die Kosten und die Schwierigkeiten gegenüber, die mit dem Betrieb eigener Datencenter in mehreren Regionen verbunden sind. Durch die Bereitstellung von Daten und Diensten in mehreren Datencentern ist Ihre Anwendung vor schwerwiegenden Ausfällen in einem einzigen Datencenter geschützt.

Azure-Traffic Manager

Sobald ein Ausfall in einem bestimmten Datencenter auftritt, müssen Sie den Datenverkehr an Dienste oder Bereitstellungen in einem anderen Datencenter umleiten. Ein solches Routing kann manuell ausgeführt werden, es ist jedoch effizienter, einen automatisierten Prozess einzurichten. Azure Traffic Manager (WATM) wurde für diese Aufgabe entworfen. Die Anwendung ermöglicht Ihnen das automatische Verwalten des Failovers von Benutzerdatenverkehr in ein anderes Datencenter, wenn ein primäres Datencenter ausfällt. Da die Verwaltung des Datenverkehrs einen wichtigen Bestandteil der globalen Strategie darstellt, ist es unerlässlich, dass Sie die Grundlagen von WATM verstehen.

In der unten stehenden Abbildung stellen Benutzer eine Verbindung mit einer URL her, die für WATM angegeben ist (http://myATMURL.trafficmanager.net) und die tatsächlichen URLs der Website abstrahiert (http://app1URL.cloudapp.net und http://app2URL.cloudapp.net). Basierend auf den konfigurierten Kriterien für die Weiterleitung von Benutzern werden diese an die richtige tatsächliche Website weitergeleitet, wenn dies von der Richtlinie vorgegeben wird. Die Richtlinienoptionen sind Roundrobin, Leistung und Failover. Im vorliegenden Whitepaper wird nur die Failover-Option behandelt.

Routing mit Windows Azure Traffic Manager

Abbildung 5: Routing mit Azure-Traffic Manager

Beim Konfigurieren von WATM geben Sie ein neues Traffic Manager-DNS-Präfix an. Dies ist das URL-Präfix, das Sie Ihren Benutzern für den Zugriff auf den Dienst bereitstellen. WATM abstrahiert Lastenausgleich nun eine Ebene höher und nicht auf Datencenterebene. Der Traffic Manager-DNS wird einem CNAME für alle von ihm verwalteten Bereitstellungen zugeordnet.

In WATM geben Sie die Priorität der Bereitstellungen an, an die Benutzer bei Auftreten eines Fehlers weitergeleitet werden. WATM überwacht die Endpunkte der Bereitstellungen und erkennt den Ausfall der primären Bereitstellung. Bei einem Ausfall analysiert WATM die nach Priorität geordnete Liste der Bereitstellungen und leitet die Benutzer an die nächste Bereitstellung in der Liste weiter.

WATM entscheidet zwar, an welchen Standort bei einem Failover gewechselt wird, Sie können jedoch entscheiden, ob Ihre Failoverdomäne inaktiv oder aktiv ist, solange das System NICHT im Failovermodus ist. Diese Funktionalität hat keinerlei Bezug zum Azure-Traffic Manager. WATM erkennt einen Ausfall am primären Standort erkennt und leitet ein Rollover an den Failoverstandort ein. WATM leitet ein Rollover an den Failoverstandort unabhängig davon ein, ob von diesem Standort zurzeit Dienste für Benutzer erbracht werden. Weitere Informationen zu inaktiven oder aktiven Failoverdomänen finden Sie in späteren Abschnitten dieses Whitepapers.

Weitere Informationen zur Funktionsweise von Azure-Traffic Manager finden Sie in den Themen unter den folgenden Links.

Häufige Azure-Notfallszenarien

In den folgenden Abschnitten werden einige verschiedene Typen von Notfallszenarien behandelt. Ausfälle von Datencentern sind nicht die einzige Ursache von anwendungsweiten Fehlern. Auch ein mangelhafter Entwurf oder Verwaltungsfehler können zu Ausfällen führen. Es ist unverzichtbar, die möglichen Ausfallursachen sowohl während der Entwurfsphase als auch während der Testphase des Wiederherstellungsplans zu berücksichtigen. In einem durchdachten Plan werden die Vorteile von Azure-Funktionen genutzt und durch anwendungsspezifischen Strategien erweitert. Die ausgewählte Reaktion wird durch die Wichtigkeit der Anwendung, die RPO und die RTO vorgeschrieben.

Anwendungsfehler

Wie bereits erwähnt, werden Fehler, die auf die zugrunde liegende Hardware oder die Betriebssystemsoftware im virtuellen Hostcomputer zurückgehen, vom Azure Fabric Controller automatisch behandelt. Azure erstellt eine neue Instanz der Rolle auf einem funktionsfähigen Server und fügt sie der Lastenausgleichsrotation hinzu. Wenn die Anzahl der Rolleninstanzen größer als eins ist, verlagert Azure die Verarbeitung auf die anderen zurzeit ausgeführten Rolleninstanzen, während der fehlerhafte Knoten ersetzt wird.

Es liegen schwerwiegende Anwendungsfehler vor, die unabhängig von Hardware- oder Betriebssystemfehlern auftreten. Die Anwendung kann aufgrund schwerwiegender Ausnahmen ausfallen, die durch eine fehlerhafte Logik oder aufgrund von Problemen mit der Datenintegrität verursacht wurden. Sie müssen eine hinreichende Telemetrie in den Code einschließen, damit ein Überwachungssystem Fehlerbedingungen erkennen und einen Anwendungsadministrator benachrichtigen kann. Der mit den Prozessen für die Notfallwiederherstellung vertraute Administrator kann die Entscheidung treffen, einen Failovervorgang einzuleiten. Alternativ kann der Administrator einfach eine vorübergehende Nichtverfügbarkeit in Kauf nehmen, um die kritischen Fehler zu beheben.

Datenbeschädigung

Azure speichert die Daten von Azure SQL-Datenbank und Azure-Speicher automatisch dreifach redundant in den verschiedenen Fehlerdomänen im gleichen Datencenter. Wenn die Georeplikation verwendet wird, werden sie drei weitere Male in einem anderen Datencenter gespeichert. Wenn jedoch die betreffenden Daten in der primären Kopie durch Benutzer oder die Anwendung beschädigt wurden, werden diese schnell in die anderen Kopien repliziert. Dies führt leider zu drei Kopien mit beschädigten Daten.

Für die Verwaltung möglicher Beschädigungen von Daten müssen Sie eigene Sicherheitskopien verwalten, um die transaktionsbezogene Konsistenz sicherzustellen. Sie können die Sicherungskopien in Azure oder lokal speichern. Dies hängt von den Geschäftsanforderungen bzw. geltenden Gesetzen und Vorschriften ab. Weitere Informationen finden Sie im Abschnitt Datenstrategien für die Notfallwiederherstellung.

Netzwerkausfall

Wenn Teile des Azure-Netzwerks ausgefallen sind, können Sie Ihre Anwendung bzw. Ihre Daten möglicherweise nicht abrufen. Wenn eine Rolleninstanz oder mehrere Rolleninstanzen aufgrund von Netzwerkproblemen nicht verfügbar sind, nutzt Azure die verbleibenden verfügbaren Instanzen der Anwendung. Wenn die Anwendung wegen eines Azure-Netzwerkausfalls nicht auf ihre Daten zugreifen kann, ist u. U. eine Ausführung im heruntergestuften Modus möglich, bei der zwischengespeicherte Daten verwendet werden. Sie müssen die Ausführung im heruntergestuften Modus in der Strategie für die Notfallwiederherstellung in Ihre Anwendung einbinden. Dies ist für einige Anwendungen möglicherweise nicht praktikabel. Eine weitere Möglichkeit besteht darin, Daten bis zum Wiederherstellen der Verbindung an einem alternativen Speicherort zu speichern. Wenn sich der heruntergestufte Modus nicht empfiehlt, verbleiben als sonstige Optionen eine Downtime der Anwendung oder das Failover in ein alternatives Datencenter. Der Entwurf einer Anwendung, die im heruntergestuften Modus ausgeführt wird, ist sowohl eine geschäftliche als auch eine technische Entscheidung. Dies wird ausführlicher im Abschnitt zur Heruntergestufte Anwendungsfunktion erläutert.

Ausfall eines abhängigen Diensts

Azure stellt viele Dienste bereit, bei denen regelmäßige Ausfallzeiten auftreten können. Als Beispiel wird hier Azure Shared Caching angeführt. Dieser mehrinstanzenfähige Dienst bietet Cachingfunktionen für die Anwendung. Die in der Anwendung auftretende Ereignisse bei Nichtverfügbarkeit des abhängigen Diensts sind unbedingt zu berücksichtigen. Dieses Szenario ähnelt in vielen Aspekten dem Netzwerkausfallszenario. Die unabhängige Betrachtung der einzelnen Dienste führt jedoch zu potenziellen Verbesserungen des globalen Plans.

Beim Caching besteht z. B. eine relativ neue Alternative zum mehrinstanzenfähigen Shared Caching-Modell. Das rollenbasierte Azure Caching ermöglicht das Caching für die Anwendung aus der Cloud-Dienstbereitstellung heraus. (Dies ist auch die zurzeit empfohlene Vorgehensweise für die Verwendung von Caching). Es besteht zwar die Einschränkung, dass der Zugriff nur innerhalb einer einzigen Bereitstellung möglich ist; dafür gibt es potenzielle Vorteile in Bezug auf die Notfallwiederherstellung. Zum Ersten wird der Dienst nun für Rollen ausgeführt, die für die jeweilige Bereitstellung lokal sind. Somit sind Sie besser in der Lage, den Status des Caches im Rahmen der globalen Verwaltungsprozesse für den Cloud-Dienst zu überwachen und zu verwalten. Diese Form des Cachings bietet jedoch außerdem auch neue Funktionen. Eine der neuen Funktionen ist die hohe Verfügbarkeit zwischengespeicherter Daten. Dies trägt dazu bei, dass zwischengespeicherte Daten bei Ausfall eines Knotens erhalten bleiben, da Duplikate auf anderen Knoten gespeichert sind. Beachten Sie, dass eine hohe Verfügbarkeit den Durchsatz verringert und die Latenz steigert, da die sekundäre Kopie bei Schreibvorgängen aktualisiert wird. Zudem verdoppelt sie die Menge des für jedes Element genutzten Speichers, was ebenfalls zu berücksichtigen ist. Dieses konkrete Beispiel veranschaulicht, dass jeder abhängige Dienst über Funktionen verfügen kann, die die globale Verfügbarkeit sowie die Absicherung gegen schwerwiegende Ausfälle verbessern.

Bei jedem abhängigen Dienst sollten Sie sich der Auswirkungen eines Totalausfalls bewusst sein. Im Cachingbeispiel ist es u. U. möglich, direkt aus einer Datenbank auf die Daten zuzugreifen, bis die Cachingfunktionen wiederhergestellt werden. Dies wäre zwar ein heruntergestufter Modus in Bezug auf die Leistung, andererseits wird jedoch der volle Funktionsumfang hinsichtlich der Daten geboten.

Ausfall eines Datencenters

Bei den oben beschriebenen Fehlern handelt es sich hauptsächlich um Ausfälle, die innerhalb desselben Azure-Datencenters behandelt werden können. Darüber hinaus müssen Sie sich jedoch auf die Möglichkeit vorbereiten, dass das ganze Datencenter ausfällt. Bei Ausfall eines Datencenters sind die lokal redundanten Kopien Ihrer Daten nicht verfügbar. Wenn Sie die Georeplikation aktiviert haben, sind drei zusätzliche Kopien der BLOBs und Tabellen in einem Datencenter in einer anderen Region vorhanden. Wenn Microsoft das Datencenter für ausgefallen erklärt, ordnet Azure alle DNS-Einträge dem geografisch replizierten Datencenter neu zu. Beachten Sie, dass Sie keinen Einfluss auf diesen Prozess haben und dass dieser nur bei Ausfall eines ganzen Datencenters ausgeführt wird. Daher müssen Sie sich auch auf andere anwendungsspezifische Sicherungsstrategien verlassen, um die größtmögliche Verfügbarkeit sicherzustellen. Weitere Informationen finden Sie im Abschnitt Datenstrategien für die Notfallwiederherstellung.

Ausfall von Azure

Bei der Planung für Notfälle müssen Sie die ganze Bandbreite möglicher Notfälle abdecken. Einer der schwerwiegendsten Ausfälle würde sämtliche Azure-Datencenter gleichzeitig betreffen. Wie bei anderen Ausfällen können Sie entscheiden, dass Sie in einem solchen Fall das Risiko einer vorübergehenden Downtime eingehen. Umfassende Ausfälle, die eine Reihe ganzer Datencenter betreffen, sollten viel seltener als isolierte Ausfälle von abhängigen Diensten oder einzelnen Datencentern auftreten. Für einige unternehmenswichtige Anwendungen ist zu erwägen, einen Sicherungsplan auch für ein solches Szenario aufzustellen. Der Plan für derartige Ereignisse sollte das Failover zu Diensten eines Alternative Clouds oder in Hybridlösungen mit lokalen und cloudbasierten Anwendungen vorsehen.

Heruntergestufte Anwendungsfunktion

Eine sorgfältig konzipierte Anwendung nutzt in der Regel eine Auflistung von Modulen, die über die Implementierung lose gekoppelter Muster des Informationsaustauschs miteinander kommunizieren. Eine Anwendung, die die Notfallwiederherstellung unterstützt, erfordert die Abgrenzung von Problemen auf Modulebene. Dies soll verhindern, dass ein Ausfall eines abhängigen Diensts den Ausfall der gesamten Anwendung bewirkt. Angenommen, Unternehmen Y betreibt z. B. eine E-Commerce-Anwendung. Die Anwendung setzt sich aus folgenden Modulen zusammen:

  • Produktkatalog: Dieser ermöglicht es Benutzern, nach Produkten zu suchen.

  • Einkaufswagen: Dieses Modul ermöglicht es Benutzern, einem Einkaufswagen Produkte hinzuzufügen bzw. Produkte aus Ihrem Einkaufswagen zu entfernen.

  • Bestellstatus: Über dieses Modul wird der Versandstatus für Kundenbestellungen angezeigt.

  • Senden der Bestellung: Hiermit wird die Einkaufssitzung durch Senden der Bestellung und Bezahlen des Kaufbetrags abgeschlossen.

  • Bestellungsverarbeitung: Hiermit wird die Datenintegrität der Bestellung überprüft, und die Verfügbarkeit der bestellten Positionen wird festgestellt.

Wie funktioniert ein Modul in dieser Anwendung bei Ausfall einer seiner Abhängigkeiten, bis dieses Element wiederhergestellt wird? Ein System mit durchdachter Architektur implementiert Isolationsgrenzen durch die Abgrenzung von Tasks sowohl zur Entwurfszeit als auch zur Laufzeit. Jeder Fehler kann als behebbar oder als nicht behebbar eingestuft werden. Nicht behebbare Fehler ziehen einen Ausfall des Moduls nach sich, während ein behebbarer Fehler durch Alternativen gemindert werden kann. Wie bereits im Abschnitt zur hohen Verfügbarkeit erläutert, können einige Probleme im Hintergrund behoben werden, indem Fehler behandelt und alternative Aktionen ausgeführt werden. Bei einem schwerwiegenderen Ausfall kann die Anwendung u. U. komplett nicht verfügbar sein. Es ist jedoch eine dritte Option vorhanden, bei der Benutzer die Anwendung im heruntergestuften Modus weiterhin nutzen können.

Wenn z. B. die Datenbank ausfällt, die die Bestellungen hostet, kann das Modul für die Bestellungsverarbeitung keine Verkaufstransaktionen mehr verarbeiten. Je nach Architektur können die Module zum Senden und Verarbeiten von Bestellungen u. U. nur mit Problemen oder überhaupt nicht mehr ausgeführt werden. Wenn die Anwendung nicht auf die Bewältigung eines solchen Szenarios ausgelegt ist, kann sie komplett ausfallen.

Im gleichen Szenario ist es jedoch möglich, dass die Produktdaten an einem anderen Ort gespeichert sind. In diesem Fall können über das Produktkatalogmodul weiterhin Produkte angezeigt werden. Im heruntergestuften Modus stellt die Anwendung für Benutzer weiterhin die verfügbaren Funktionen bereit, z. B. das Durchsuchen des Produktkatalogs. Andere Teile der Anwendung sind hingegen nicht verfügbar, beispielsweise Senden von Bestellungen und Bestandsabfragen.

Bei einer anderen Variante des heruntergestuften Modus liegt der Schwerpunkt mehr auf der Leistung als auch dem Funktionsumfang. Betrachten Sie z. B. ein Szenario, in dem der Produktkatalog mit dem Azure-Cachedienst zwischengespeichert wurde. Wenn Caching nicht mehr verfügbar ist, kann die Anwendung u. U. direkt den Serverspeicher abfragen, um Produktkataloginformationen abzurufen. Ein solcher Zugriff ist jedoch möglicherweise langsamer als bei der Zwischenspeicherung von Daten. Daher ist die Anwendungsleistung beeinträchtigt, bis der Cachedienst vollständig wiederhergestellt wurde.

Die Entscheidung, in welchem Umfang eine Anwendung im heruntergestuften Modus noch funktioniert, ist sowohl eine geschäftliche als auch eine technische Entscheidung. Für die Anwendung muss zudem festgelegt werden, auf welche Weise Benutzer über vorübergehende Probleme informiert werden. In diesem Beispiel kann die Anwendung das Anzeigen von Produkten und sogar das Hinzufügen von Produkten zum Einkaufswagen unterstützen. Sobald der Benutzer jedoch versucht, einen Kauf abzuschließen, wird er von der Anwendung benachrichtigt, dass das Verkaufsmodul vorübergehend nicht zur Verfügung steht. Eine solche Regelung ist für den Kunden nicht ideal, ein Ausfall der gesamten Anwendung wird jedoch verhindert.

Datenstrategien für die Notfallwiederherstellung

Die richtige Behandlung der Daten ist der schwierigste Aspekt, der in einem Notfallwiederherstellungsplan berücksichtigt werden muss. Die Wiederherstellung der Daten ist zudem der Teil des Wiederherstellungsvorgangs, der i. d. R. die meiste Zeit in Anspruch nimmt. Die verschiedenen Auswahlmöglichkeiten für heruntergestufte Modi können Schwierigkeiten in Bezug auf die Datenwiederherstellung und die Datenkonsistenz nach einem Ausfall mit sich bringen. Einer der Faktoren ist die Anforderung, eine Kopie der Daten der Anwendung wiederherzustellen oder zu verwalten. Sie verwenden diese Daten für Verweis- und Transaktionszwecke an einem sekundären Standort. Bei einer lokalen Konfiguration erfordert dies einen arbeits- und zeitaufwendigen Planungsprozess, um eine Notfallwiederherstellungsstrategie mit mehreren Datencentern zu implementieren. Glücklicherweise ermöglichen die meisten Cloud-Anbieter (einschließlich Azure) die Bereitstellung von Anwendungen in mehreren Datencentern. Diese Datencenter sind geografisch so verteilt, dass Ausfälle mehrerer Datencenter extrem selten auftreten sollten. Die Strategie zum Verarbeiten von Daten über mehrere Datencenter hinweg ist einer der entscheidenden Erfolgsfaktoren für jeden Notfallwiederherstellungsplan.

In den folgenden Abschnitten werden Notfallwiederherstellungsverfahren in Bezug auf Datensicherungen, Verweisdaten und Transaktionsdaten erläutert.

Sicherung und Wiederherstellung

Einige Szenarien für die Notfallwiederherstellung können durch regelmäßige Sicherungen von Anwendungsdaten unterstützt werden. Für verschiedene Speicherressourcen sind unterschiedliche Verfahren erforderlich.

Für Azure SQL-Datenbank können Sie mit dem DATABASE COPY-Befehl eine Kopie der Datenbank erstellen. Sie müssen diesen Befehl verwenden, um eine Sicherungskopie mit Transaktionskonsistenz zu erhalten. Sie können auch den Import-/Exportdienst von Azure SQL-Datenbank nutzen. Dieser unterstützt das Exportieren von Datenbanken in BACPAC-Dateien, die im Azure-BLOB-Speicher gespeichert werden. Aufgrund der integrierten Redundanz von Azure-Speicher werden zwei Replikate der Sicherungsdatei im gleichen Datencenter erstellt. Die Ausführungshäufigkeit des Sicherungsprozesses wird jedoch durch Ihre Wiederherstellungspunktvorgabe bestimmt, mit der der potenzielle Datenverlust in Notfallszenarien angegeben wird. Sie führen z. B. einen Sicherungsvorgang zum Ende jeder vollen Stunde aus, und der Notfall tritt zwei Minuten vor Ablauf der vollen Stunde ein. Sie verlieren 58 Minuten der Daten, die seit der letzten Ausführung eines Sicherungsvorgangs aufgelaufen sind. Um sich gegen den Ausfall eines Datencenters zu schützen, sollten Sie außerdem die BACPAC-Dateien in ein alternatives Datencenter kopieren. Sie verfügen dann ggf. über die Möglichkeit, die betreffenden Sicherungen im alternativen Datencenter wiederherzustellen. Weitere Einzelheiten finden Sie unter Geschäftskontinuität in der Azure SQL-Datenbank.

Für Azure-Speicher können Sie einen eigenen benutzerdefinierten Prozess entwickeln oder eines der vielen Sicherungstools von Drittanbietern nutzen. Beachten Sie, dass Sie in den meisten Anwendungsentwürfen zusätzliche Komplexitäten vorliegen, wenn Speicherressourcen aufeinander verweisen. Betrachten Sie beispielsweise eine SQL-Datenbank, die eine Spalte enthält, die mit einem BLOB in Azure-Speicher verknüpft ist. Wenn die Sicherungen nicht gleichzeitig ausgeführt werden, enthält die Datenbank möglicherweise einen Zeiger auf ein BLOB-Objekt, das vor dem Ausfall nicht gesichert wurde. In der Anwendung oder im Notfallwiederherstellungsplan müssen Prozesse implementiert werden, um eine solche Inkonsistenz nach einer Wiederherstellung zu beheben.

Verweisdaten-Muster (Notfallwiederherstellung)

Wie bereits erwähnt sind Verweisdaten schreibgeschützte Daten, die die Anwendungsfunktionalität unterstützen. Normalerweise werden sie nur selten geändert. Obwohl Sicherung und Wiederherstellung eine Methode zur Behandlung von Datencenterausfällen darstellen, ist die Wiederherstellungszeitvorgabe (Recovery Time Objective, RTO) relativ lang. Wenn die Anwendung in einem sekundären Datencenter bereitgestellt wird, gibt es einige Strategien, die die RTO für Verweisdaten verbessern.

Da sich Verweisdaten nur selten ändern, können Sie die RTO verbessern, indem Sie eine permanente Kopie der Verweisdaten im sekundären Datencenter verwalten. Dadurch entfällt die erforderliche Zeit zum Wiederherstellen von Sicherungen bei einem Notfall. Damit die Anforderungen bei der Notfallwiederherstellung mit mehreren Datencentern erfüllt werden, müssen die Anwendung und die Verweisdaten zusammen in mehreren Datencentern bereitgestellt werden. Wie bereits oben im Abschnitt zu Thema Verweisdaten-Muster (hohe Verfügbarkeit) beschrieben, können Verweisdaten in der Rolle selbst und/oder in einem externen Speicher bereitgestellt werden. Das Modell der Verweisdatenbereitstellung innerhalb der Serverknoten erfüllt implizit auch die Anforderungen in Bezug auf die Notfallwiederherstellung. Für die Verweisdatenbereitstellung in der SQL-Datenbank muss eine Kopie der Verweisdaten in jedem Datencenter bereitgestellt werden. Die gleiche Strategie gilt auch für Azure-Speicher. Sie müssen eine Kopie aller im Azure-Speicher gespeicherten Verweisdaten in den primären und sekundären Datencentern bereitstellen.

Verweisdatenveröffentlichung in beiden Rechenzentren

Abbildung 6: Veröffentlichung von Verweisdaten im primären und im sekundären Datencenter

Wie bereits erwähnt, müssen Sie Ihre eigenen anwendungsspezifischen Sicherungsroutinen für alle Daten (einschließlich der Verweisdaten) implementieren. Geografisch replizierte Kopien in mehreren Datencentern werden bei Ausfällen eines ganzen Datencenters verwendet. Damit eine längere Ausfallzeit verhindert wird, stellen Sie die wichtigen Teile der Anwendungsdaten im sekundären Datencenter bereit. Ein Beispiel für diese Topologie finden Sie unter dem Aktiv/Passiv-Modell.

Transaktionsdaten-Muster (Notfallwiederherstellung)

Die Implementierung einer vollständig funktionsfähigen Notfallmodusstrategie erfordert die asynchrone Replikation der Transaktionsdaten in das sekundäre Datencenter. Die Zeitfenster, innerhalb derer die Replikation auftreten kann, bestimmen die RPO-Eigenschaften der Anwendung. Sie können die Daten, die aus dem primären Datencenter verloren gegangen sind, während des Replikationsfensters ggf. noch wiederherstellen. Sie sind ggf. auch in der Lage, zu einem späteren Zeitpunkt eine Zusammenführung mit dem sekundären Datencenter auszuführen.

Die folgenden Architekturbeispiele sollen einige Möglichkeiten veranschaulichen, wie Transaktionsdaten in einem Failoverszenario behandelt werden. Beachten Sie, dass diese Beispiele keine vollständige Liste der Möglichkeiten darstellen. Zwischenspeicherorte wie Warteschlangen können ggf. durch Azure SQL-Datenbank ersetzt werden. Bei den Warteschlangen selbst kann es sich entweder um Azure-Speicher- oder -Servicebus-Warteschlangen handeln (siehe Azure-Warteschlangen und Azure-Servicebus-Warteschlangen – Vergleich und Gegenüberstellung). Serverspeicherziele können ebenfalls variieren, z. B. können Azure-Tabellen anstelle von SQL-Datenbank genutzt werden. Darüber hinaus können Workerrollen vorhanden sein, die in den verschiedenen Schritten als Zwischenstufe eingefügt wurden. Wichtig ist vor allem, dass Sie diese Architekturen nicht genau emulieren, sondern die diversen Alternativen für das Wiederherstellen von Transaktionsdaten und der zugehörigen Module erwägen.

Betrachten Sie als Beispiel eine Anwendung, bei der Transaktionsdaten in Azure-Speicher-Warteschlangen gespeichert werden. Auf diese Weise können Workerrollen die Transaktionsdaten in der Serverdatenbank in einer entkoppelten Architektur verarbeiten. Wie bereits erläutert, muss für Transaktionen somit eine Form des temporären Cachings genutzt werden, wenn die Front-End-Rollen direkte Abfragen der betreffenden Daten erfordern. Je nach toleriertem Ausmaß von Datenverlusten steht die Replikation der Warteschlangen, der Datenbank oder sämtlicher Speicherressourcen zur Auswahl. Wenn nur Datenbankreplikation verwendet wird, können die Daten in den Warteschlangen beim Ausfall des primären Datencenters immer noch wiederhergestellt werden, wenn das primäre Datencenter wieder verfügbar wird. In der folgenden Abbildung wird eine Architektur veranschaulicht, in der die Serverdatenbank zwischen mehreren Datencentern synchronisiert wird.

Transaktionsdaten zur Vorbereitung von DR replizieren

Abbildung 7: Transaktionsdaten zur Vorbereitung der Notfallwiederherstellung replizieren

Die größte Herausforderung beim Implementieren der obigen Architektur ist die Strategie für die Replikation zwischen Datencentern. Azure stellt einen SQL-Datensynchronisierungsdienst für eine solche Art der Replikation zur Verfügung. Dieser Dienst befindet sich jedoch noch in der Vorschau, und er wird für Produktionsumgebungen nicht empfohlen. Weitere Informationen finden Sie unter Geschäftskontinuität in der Azure SQL-Datenbank. Für Produktionsanwendungen müssen Sie eine Lösung eines Drittanbieters erwerben oder eine eigene Replikationslogik in Code erstellen. Je nach Architektur kann die Replikation bidirektional und somit auch komplexer sein. In einer möglichen Implementierung kann auch die zwischengeschaltete Warteschlange aus dem vorherigen Beispiel genutzt werden. Die Workerrolle, die die Daten in das endgültige Speicherziel schreibt, kann die Änderung im primären und sekundären Datencenter vornehmen. Hierbei handelt es sich um keine unbedeutenden Aufgaben, und umfassende Anleitungen in Bezug auf den Replikationscode würden über den Rahmen dieses Whitepapers hinausgehen. Wichtig ist, dass Sie sich in einem Großteil Ihrer Zeit und Ihrer Tests damit befassen, wie die Daten in das sekundäre Datencenter repliziert werden. Es empfiehlt sich, weitere Verarbeitungs- und Testschritte auszuführen, um sicherzustellen, dass die Failover- und Wiederherstellungsprozesse mögliche Dateninkonsistenzen und doppelte Transaktionen ordnungsgemäß behandeln.

noteHinweis
Das Dokument behandelt vorrangig PaaS (Platform as a Service). Es gibt jedoch zusätzliche Replikations- und Verfügbarkeitsoptionen für Hybridanwendungen, die virtuelle Azure-Computer verwenden. Diese Hybridanwendungen nutzen Infrastructure as a Service (IaaS), um SQL Server auf virtuellen Computern in Azure zu hosten. Dies ermöglicht herkömmliche Verfügbarkeitsansätze in SQL Server, z. B. AlwaysOn-Verfügbarkeitsgruppen oder Protokollversand. Einige Techniken (wie AlwaysOn) funktionieren nur zwischen lokalen SQL-Servern und virtuellen Azure-Computern. Weitere Informationen finden Sie unter Hochverfügbarkeit und Notfallwiederherstellung für SQL Server auf Azure-Virtuellen Computern.

Betrachten Sie eine zweite Architektur, die im heruntergestuften Modus betrieben wird. In der Anwendung im sekundären Datencenter werden sämtliche Funktionen deaktiviert, z. B. Berichterstellung, BI oder das Leeren von Warteschlangen. Es werden lediglich die wichtigsten Typen von Transaktionsworkflows akzeptiert, die durch Geschäftsanforderungen definiert werden. Das System erfasst die Transaktionen und schreibt sie in Warteschlangen. Das System kann die Verarbeitung der Daten zu Beginn eines Ausfalls aufschieben. Sollte das System im primären Datencenter innerhalb des erwarteten Zeitfensters reaktiviert werden, können die Warteschlangen von den Workerrollen im primären Datencenter geleert werden. Durch diesen Vorgang ist keine Datenbankzusammenführung erforderlich. Wenn der Ausfall des primären Datencenters das tolerierbare Zeitfenster überschreitet, kann die Anwendung mit dem Verarbeiten der Warteschlangen beginnen. In diesem Szenario enthält die Datenbank im sekundären Datencenter inkrementelle Transaktionsdaten, die zusammengeführt werden müssen, sobald das primäre Datencenter erneut funktionsfähig ist. In der folgenden Abbildung wird diese Strategie für das vorübergehende Speichern von Transaktionsdaten bis zur Wiederherstellung des primären Datencenters veranschaulicht.

Heruntergestufter Anwendungsmodus für Transaktionsaufzeichnung

Abbildung 8: Ausschließlich für die Transaktionsaufzeichnung bestimmter heruntergestufter Anwendungsmodus

Weitere Erläuterungen zu Datenverwaltungstechniken für robuste Azure-Anwendungen finden Sie unter FailSafe: Leitfaden zu robusten Cloud-Architekturen.

Bereitstellungstopologien für die Notfallwiederherstellung

Unternehmenswichtige Anwendungen müssen auf die Möglichkeit vorbereitet sein, dass das gesamte Datencenter ausfällt. Zu diesem Zweck muss eine Bereitstellungsstrategie für mehrere Datencenter in die operative Planung eingeschlossen werden. Bei Bereitstellungen in mehreren Datencentern können IT-Pro-Prozesse relevant sein, mit denen die Anwendung und die Verweisdaten bei einem Notfall im sekundären Datencenter veröffentlicht werden. Wenn die Anwendung ein sofortiges Failover erfordert, kann der Bereitstellungsprozess die Umsetzung einer Aktiv/Passiv-Konfiguration oder einer Aktiv/Aktiv-Konfiguration umfassen. Dieser Bereitstellungstyp verwendet vorhandene Instanzen der Anwendung, die im alternativen Datencenter ausgeführt werden. Ein Routingtool wie Azure Traffic Manager stellt – wie bereits erwähnt – Lastenausgleichsdienste auf der DNS-Ebene bereit. Es kann Ausfälle erkennen und die Benutzer ggf. an andere Datencenter weiterleiten.

Teil einer erfolgreichen Azure-Notfallwiederherstellung ist deren Einbindung in die Lösung von Beginn an. Die Cloud stellt zusätzliche Optionen zur Wiederherstellung bei Fehlern während eines Notfalls bereit, die bei einem herkömmlichen Hostinganbieter nicht verfügbar sind. Insbesondere besteht die Möglichkeit, Ressourcen einem anderen Datencenter schnell und dynamisch zuzuordnen. Daher fallen keine hohen Kosten für Ressourcen im Leerlauf an, die nur aufgrund eines möglichen Ausfalls betrieben werden.

In den folgenden Abschnitten werden verschiedene Bereitstellungstopologien für die Notfallwiederherstellung erläutert. In der Regel kann ein Kompromiss zwischen gestiegenen Kosten und höherer Komplexität und zusätzlicher Verfügbarkeit gefunden werden.

Bereitstellung in einzelner Region

Eine Bereitstellung in einer einzelnen Region ist keine Notfallwiederherstellungstopologie im eigentlichen Sinn. Sie dient der Gegenüberstellung mit anderen Architekturen. Bereitstellungen in einer einzelnen Region sind für Anwendungen in Azure häufig anzutreffen. Es handelt sich jedoch nicht um eine ernsthafte Alternative für einen Notfallwiederherstellungsplan. In der folgenden Abbildung wird eine Anwendung dargestellt, die in einem einzigen Azure-Datencenter ausgeführt wird. Wie bereits erläutert, steigern der Azure Fabric Controller und die Nutzung von Fehler- und Upgradedomänen die Verfügbarkeit der Anwendung im Datencenter.

Bereitstellung in einzelner Region

Abbildung 9: Bereitstellung in einzelner Region

Hier wird ersichtlich, dass die Datenbank eine einzelne Fehlerquelle ist. Obwohl Azure die Daten über verschiedene Fehlerdomänen in interne Replikate repliziert, finden alle diese Vorgänge im selben Datencenter statt. Ein schwerwiegender Ausfall kann nicht bewältigt werden. Bei einem Ausfall des Datencenters fallen sämtliche Fehlerdomänen aus, und dies schließt alle Dienstinstanzen und Speicherressourcen ein.

Sie müssen für alle (mit Ausnahme der weniger wichtigen) Anwendungen einen Plan ausarbeiten, gemäß dem die jeweilige Anwendung in mehreren Datencentern in verschiedenen Regionen bereitgestellt wird. Bei der Überlegung, welche Bereitstellungstopologie genutzt werden sollte, müssen Sie RTO- und Kosteneinschränkungen berücksichtigen.

Im Folgenden wird näher auf bestimmte Muster zur Unterstützung des Failovers zwischen verschiedenen Datencentern eingegangen. In allen diesen Beispielen wird der Prozess anhand von zwei Datencentern beschrieben.

Erneut bereitstellen

In diesem Muster werden nur im primären Datencenter Anwendungen und Datenbanken ausgeführt. Das sekundäre Datencenter ist nicht für automatische Failovervorgänge eingerichtet. Wenn also ein Notfall eintritt, müssen Sie alle Teile des Diensts im neuen Datencenter einrichten. Dazu muss ein Cloud-Dienst in Azure hochgeladen werden, und die Cloud-Dienste müssen bereitgestellt, die Daten wiederhergestellt und der DNS zum Umleiten des Datenverkehrs geändert werden.

Dies ist zwar die kostengünstigste der Optionen für mehrere Regionen, die RTO-Eigenschaften sind jedoch am schlechtesten. In diesem Modell sind die Dienstpaket- und Datenbanksicherungen entweder lokal oder im BLOB-Speicher des sekundären Datencenters gespeichert. Es muss jedoch ein neuer Dienst bereitgestellt werden, und die Daten müssen wiederhergestellt werden, bevor der Betrieb fortgesetzt werden kann. Auch wenn Sie die Datenübertragung aus dem Sicherungsspeicher vollständig automatisieren, kann das Einrichten der neuen Datenbankumgebung viel Zeit in Anspruch nehmen. Das Verschieben von Daten aus dem Sicherungsspeicher in die leere Datenbank im sekundären Datencenter ist der aufwendigste Teil der Wiederherstellung. Dieser Vorgang ist jedoch erforderlich, damit die neue Datenbank funktionsfähig ist, da sie nicht repliziert wurde.

Die beste Vorgehensweise besteht darin, die Dienstpakete im Azure-BLOB-Speicher im sekundären Datencenter zu speichern. Daher ist es nicht notwendig, das Paket in Azure hochzuladen. Dies wäre der Fall, wenn Sie die Bereitstellung von einem lokalen Entwicklungscomputer ausführen. Die Dienstpakete können schnell mithilfe von PowerShell-Skripts aus dem BLOB-Speicher in einem neuen Cloud-Dienst bereitgestellt werden.

Diese Option empfiehlt sich ausschließlich für unwichtige Anwendungen, bei denen eine hohe RTO tolerabel ist. Dies kann z. B. für eine Anwendung ratsam sein, die mehrere Stunden inaktiv sein kann, die jedoch innerhalb von 24 Stunden wieder ausgeführt werden sollte.

Erneute Bereitstellung in einem sekundären Windows Azure-Rechenzentrum

Abbildung 10: Erneute Bereitstellung in einem sekundären Azure-Datencenter

Aktiv/Passiv

Das Aktiv/Passiv-Muster wird von vielen Unternehmen bevorzugt. Dieses Muster bietet eine verbesserte Zeitvorgabe für die Wiederherstellung (Recovery Time Objective, RTO) bei einem relativ geringen Anstieg der Kosten für dieses Modell der erneuten Bereitstellung. In diesem Szenario sind wiederum ein primäres und ein sekundäres Azure-Datencenter vorhanden. Der gesamte Datenverkehr fließt in die aktuelle Bereitstellung im primären Datencenter. Das sekundäre Datencenter ist besser auf die Notfallwiederherstellung vorbereitet, da die Datenbank in beiden Datencentern ausgeführt wird. Darüber hinaus ist zwischen beiden Datencentern ein Synchronisierungsmechanismus eingerichtet. Dieser "Standbyansatz" kann in zwei Varianten vorliegen: ein ausschließlich auf die Datenbank bezogener Ansatz oder eine vollständige Bereitstellung im sekundären Datencenter.

Bei der ersten Variante des Aktiv/Passiv-Musters verfügt nur das primäre Datencenter über eine bereitgestellte Cloud-Dienst-Anwendung. Im Gegensatz zum Muster mit erneuter Bereitstellung wird jedoch der Datenbankinhalt zwischen beiden Datencentern synchronisiert (weitere Informationen finden Sie im Abschnitt Transaktionsdaten-Muster (Notfallwiederherstellung)). Wenn ein Notfall eintritt, sind die Aktivierungsanforderungen geringer. Es muss lediglich die Anwendung im sekundären Datencenter gestartet werden, die Verbindungszeichenfolgen müssen auf die neue Datenbank festgelegt werden, und die DNS-Einträge müssen so bearbeitet werden, dass der Datenverkehr umgeleitet wird.

Wie bei der erneuten Bereitstellung sollten die Dienstpakete im Azure-BLOB-Speicher des sekundären Datencenters bereits gespeichert sein, damit die Bereitstellung schneller erfolgen kann. Im Gegensatz zum Muster mit erneuter Bereitstellung entfällt jedoch größtenteils der Aufwand, der für die Wiederherstellung der Datenbank erforderlich ist. Die Datenbank ist funktionsfähig und wird ausgeführt. Dies bringt eine wesentliche Zeitersparnis mit sich, sodass dieses Notfallwiederherstellungsmuster aufgrund seiner geringen Kosten meist bevorzugt wird.

Aktiv/passiv (nur Datenbank)

Abbildung: Aktiv/Passiv (nur Datenbank)

In der zweiten Variante des Aktiv/Passiv-Musters verfügen das primäre und das sekundäre Datencenter über eine vollständige Bereitstellung. Diese Bereitstellung enthält die Cloud-Dienste und eine synchronisierte Datenbank. Netzwerkanforderungen der Benutzer werden jedoch nur vom primären Datencenter aktiv behandelt. Das sekundäre Datencenter wird nur aktiv, wenn das primäre Datencenter ausfällt. In einem solchen Fall werden alle neuen Netzwerkanforderungen an die sekundäre Region weitergeleitet. Azure Traffic Manager kann dieses Failover automatisch verwalten.

Der Failovervorgang erfolgt schneller als bei der Variante, die nur die Datenbank betrifft, da die Dienste bereits bereitgestellt sind. Dieses Muster ist auf eine sehr niedrige RTO ausgelegt, wenn das sekundäre Failoverdatencenter bei einem Ausfall des primären Datencenters sofort aktiv werden muss.

Neben der schnelleren Reaktionszeit bietet dieses Muster den zusätzlichen Vorteil der Vorabzuordnung und Bereitstellung der Sicherungsdienste. Sie müssen sich keine Gedanken darüber machen, dass ein Datencenter in einem Notfall über keinen ausreichenden Platz zum Zuordnen neuer Instanzen verfügt. Dies ist wichtig, wenn die Kapazität Ihres sekundären Azure-Datencenters nahezu erschöpft ist. Es gibt keinerlei Garantie (SLA), dass Sie sofort in der Lage sein werden, eine Reihe neuer Cloud-Dienste in einem Datencenter bereitzustellen.

Damit die schnellste Reaktionszeit für dieses Modell erreicht wird, müssen das primäre Datencenter und das sekundäre Datencenter eine ähnliche Skalierung (Anzahl der Rolleninstanzen) aufweisen. Durch die für ungenutzte Serverinstanzen anfallenden Kosten stellt dies aber häufig trotz der Vorteile nicht die sinnvollste finanzielle Entscheidung dar. Daher ist es eher üblich, dass im sekundären Datencenter eine zentral runterskalierte Version der Cloud-Dienste verwendet wird. Anschließend können Sie schnell ein Failover und die horizontale Skalierung der sekundären Bereitstellung ausführen, falls dies erforderlich ist. Sie sollten den Failovervorgang automatisieren, damit Sie bei einem Ausfall des primären Datencenters in Abhängigkeit von der Last zusätzliche Instanzen aktivieren können. Dies kann einen automatischen Skalierungsmechanismus einschließen, z. B. AutoScale Preview oder den Anwendungsblock für automatische Skalierung. In der folgenden Abbildung wird das Modell veranschaulicht, in dem das primäre und das sekundäre Datencenter einen vollständig bereitgestellten Cloud-Dienst in einem Aktiv/Passiv-Muster enthalten.

Aktiv/passiv (vollständiges Replikat)

Abbildung 12 Aktiv/Passiv (vollständiges Replikat)

Aktiv/aktiv

Mittlerweile haben Sie wahrscheinlich eine Vorstellung von der Entwicklung der Muster – das Verringern der RTO steigert Kosten und Komplexität. Die Aktiv/Aktiv-Lösung durchbricht tatsächlich diese Tendenz hinsichtlich der Kosten. In einem Aktiv/Aktiv-Muster werden die Cloud-Dienste und die Datenbank in beiden Datencentern vollständig bereitgestellt. Im Gegensatz zum Aktiv/Passiv-Modell empfangen beide Datencenter Datenverkehr der Benutzer. Diese Option bietet die kürzeste Wiederherstellungszeit. Die Dienste sind bereits so skaliert, dass sie einen Teil der Last in jedem Datencenter verarbeiten können. Das DNS ist bereits für die Verwendung des sekundären Datencenters eingerichtet. Die Festlegung, auf welche Weise Benutzer an das entsprechende Datencenter weitergeleitet werden, ist ebenfalls sehr komplex. Roundrobinplanung ist ggf. möglich. Es ist jedoch wahrscheinlicher, dass einige Benutzer ein bestimmtes Datencenter bevorzugen, in dem sich die primäre Kopie ihrer Daten befindet.

Im Fall eines Failovers muss lediglich das DNS für das primäre Datencenter deaktiviert werden. Dabei wird der gesamte Datenverkehr an das sekundäre Datencenter weiterleitet. Selbst für dieses Modell gibt es einige Varianten. In der folgenden Abbildung wird z. B. ein Modell veranschaulicht, in dem das primäre Datencenter über die Masterkopie der Datenbank verfügt. Die Cloud-Dienste in beiden Datencentern schreiben in diese primäre Datenbank. Die sekundäre Bereitstellung kann Daten aus der primären oder aus der replizierten Datenbank lesen. Die Replikation in diesem Beispiel erfolgt unidirektional.

Aktiv/aktiv

Abbildung 13: Aktiv/Aktiv

Die in der vorherigen Abbildung dargestellte Aktiv/Aktiv-Architektur hat jedoch einen Nachteil. Das zweite Datencenter muss auf die Datenbank im ersten Datencenter zugreifen, da sich die Masterkopie dort befindet. Die Leistung wird erheblich beeinträchtigt, wenn der Zugriff auf Daten in einem Datencenter von außerhalb erfolgt. Bei Datencenter-übergreifenden Datenbankaufrufen sollten Sie erwägen, eine Art von Batchverarbeitung zu implementieren, um die Leistung dieser Aufrufe zu verbessern. Weitere Informationen finden Sie unter Stapelverarbeitungsverfahren für SQL-Datenbankanwendungen in Azure. Eine alternative Architektur kann vorsehen, dass aus jedem Datencenter direkt auf die eigene Datenbank zugegriffen wird. In einem solchen Modell ist eine Art der bidirektionalen Replikation erforderlich, um die Datenbanken in den einzelnen Datencentern zu synchronisieren.

Bei Verwendung des Aktiv/Aktiv-Musters benötigen Sie ggf. nicht so viele Instanzen im primären Datencenter wie bei Verwendung des Aktiv/Passiv-Musters. Wenn Sie über zehn Instanzen im primären Datencenter in einer Aktiv/Passiv-Architektur verfügen, benötigen Sie in einer Aktiv/Aktiv-Architektur möglicherweise nur fünf in jedem Datencenter. Die Last ist nun auf beide Regionen verteilt. Damit könnten Sie gegenüber dem Aktiv/Passiv-Muster Kosten einsparen, wenn Sie einen betriebsbereiten Standbymodus des passiven Datencenters mit zehn Instanzen bereitstellen, die auf einen Failovervorgang warten.

Beachten Sie, dass im sekundären Datencenter bis zur Wiederherstellung des primären Datencenters eine rapide Zunahme der Anzahl neuer Benutzer möglich ist. Wenn zum Zeitpunkt des Ausfalls des primären Datencenters 10.000 Benutzer auf jedem Server vorhanden waren, muss das sekundäre Datencenter plötzlich 20.000 Benutzer verarbeiten. Durch Überwachungsregeln im sekundären Datencenter muss diese Zunahme der Benutzeranzahl erkannt und die Anzahl der Instanzen im sekundären Datencenter verdoppelt werden. Weitere Informationen dazu finden Sie im Abschnitt Fehlererkennung.

Hybridlösungen mit lokalen und cloudbasierten Anwendungen

Eine zusätzliche Strategie für die Notfallwiederherstellung besteht darin, eine Hybridanwendung zu entwickeln, die lokal und in der Cloud ausgeführt wird. Je nach Anwendung kann das primäre Datencenter an jedem der beiden Orte eingerichtet sein. Betrachten Sie die zuvor beschriebenen Architekturen, und stellen Sie sich das primäre oder das sekundäre Datencenter als lokalen Standort vor.

Derartige Hybridarchitekturen bergen einige Herausforderungen. Zum Ersten wurden in diesem Whitepaper größtenteils PaaS-Architekturmuster (Platform as a Service) behandelt. Typische PaaS-Anwendungen in Azure basieren auf Azure-spezifischen Konstrukten wie Rollen, Cloud-Diensten und dem Fabric Controller. Zum Erstellen einer lokalen Lösung für eine solche Art von PaaS-Anwendung ist eine wesentlich andere Architektur erforderlich. Eine solche kann aus Verwaltungs- und Kostengründen möglicherweise nicht eingerichtet werden.

Allerdings birgt eine Hybridlösung zur Notfallwiederherstellung weniger Herausforderungen, wenn herkömmliche Architekturen einfach in die Cloud verschoben werden. Dies gilt für Architekturen, denen Infrastructure as a Service (IaaS) zugrunde liegt. IaaS-Anwendungen verwenden virtuelle Computer in der Cloud, die direkte Entsprechungen am lokalen Standort haben können. Die Verwendung virtueller Netzwerke ermöglicht es Ihnen außerdem, Verbindungen von Computern in der Cloud mit lokalen Netzwerkressourcen herzustellen. Dies eröffnet eine Reihe von Möglichkeiten, die bei ausschließlich auf PaaS beruhenden Anwendungen nicht gegeben sind. Beispielsweise kann SQL Server die Vorteile von Notfallwiederherstellungslösungen wie AlwaysOn-Verfügbarkeitsgruppen und Datenbankspiegelung nutzen. Einzelheiten hierzu finden Sie unter Hochverfügbarkeit und Notfallwiederherstellung für SQL Server auf virtuellen Azure-Computern.

IaaS-Lösungen bieten zudem für lokale Anwendungen einen einfacheren Pfad für die Nutzung von Azure als Failoveroption. Angenommen, Sie verfügen über eine voll funktionsfähige Anwendung in einem vorhandenen lokalen Datencenter. Wie sollten Sie jedoch vorgehen, wenn Ihre Ressourcen nicht ausreichen, um an einem anderen geografischen Standort ein separates Datencenter für Failoverzwecke zu betreiben? Sie können sich entscheiden, virtuelle Computer und virtuelle Netzwerke zu verwenden, um Ihre Anwendung in Azure auszuführen. Definieren Sie Prozesse, die Daten mit der Cloud synchronisieren. Die Azure-Bereitstellung wird dann zum sekundären Datencenter für Failoverzwecke. Als primäres Datencenter fungiert weiterhin die lokale Anwendung. Weitere Informationen zu IaaS-Architekturen und -Funktionen finden Sie unter Virtuelle Computer und Virtuelles Netzwerk.

Alternative Clouds

In einigen Fällen kann selbst die Stabilität der Cloud von Microsoft den Anforderungen in Bezug auf die Verfügbarkeit nicht gerecht werden. Im vergangenen Jahr waren einige schwerwiegende Ausfälle verschiedener Cloud-Plattformen zu verzeichnen. Beispiele sind Amazon Web Services (AWS) und die Azure-Plattformen. Selbst wenn die Implementierung von Sicherungssystemen in einem Notfall optimal vorbereitet und konzipiert wurde, greift dies zu kurz, und die gesamte Cloud fällt für einen ganzen Tag aus.

Es empfiehlt sich, die Verfügbarkeitsanforderungen den Kosten und der Komplexität gegenüberzustellen, die mit einer höheren Verfügbarkeit verbunden sind. Führen Sie eine Risikoanalyse aus, und definieren Sie die Zeitvorgabe für die Wiederherstellung (Recovery Time Objective, RTO) und die Wiederherstellungspunktvorgabe (Recovery Point Objective, RPO) für Ihre Lösung. Wenn für die Anwendung keinerlei Ausfallzeit toleriert werden kann, müssen Sie ggf. eine andere Cloud-Lösung in Betracht ziehen. Sollte nicht das gesamte Internet auf einmal ausfallen, sind andere Cloud-Lösungen wie Rackspace oder Amazon Web Services bei einem selten zu erwartenden Komplettausfall von Azure weiterhin funktionsfähig.

Wie im Hybridszenario können die Failoverbereitstellungen in den oben erwähnten Notfallwiederherstellungs-Architekturen auch in einer anderen Cloud-Lösung vorhanden sein. Alternative cloud-basierte Notfallwiederherstellungsorte sollten für diese Lösungen nur bei einer RTO genutzt werden, die nur eine geringe oder überhaupt keine Ausfallzeit zulässt. Beachten Sie, dass bei einer Lösung, die einen anderen cloud-basierten Notfallwiederherstellungsort als Azure nutzt, ein wesentlich höherer Aufwand in Bezug auf Konfiguration, Entwicklung, Bereitstellung und Verwaltung anfällt. Zudem ist es schwieriger, in einer Architektur mit mehreren Clouds bewährte Methoden zu implementieren. Cloud-Plattformen liegen zwar ähnliche allgemeine Konzepte zugrunde, die APIs und Architekturen unterscheiden sich jedoch. Sollten Sie sich entscheiden, Ihre Notfallwiederherstellung auf verschiedene Plattformen aufzuteilen, empfiehlt es sich, in den Entwurf der Lösung Abstraktionsebenen einzubinden. Auf diese Weise müssen für einen Notfall keine zwei verschiedenen Versionen ein und derselben Anwendung für unterschiedliche Cloud-Plattformen entwickelt und verwaltet werden. Wie beim Hybridszenario ist es in diesen Fällen einfacher, virtuelle Computer anstelle von cloud-spezifischen PaaS-Entwürfen zu verwenden.

Automatisierung

Einige der soeben erläuterten Muster erfordern die unverzügliche Aktivierung von Offlinebereitstellungen sowie die Wiederherstellung bestimmter Teile eines Systems. Automatisierung oder Skripts bieten die Möglichkeit, Ressourcen im Bedarfsfall zu aktivieren und Lösungen schnell bereitzustellen. Im vorliegenden Whitepaper wird die auf die Notfallwiederherstellung bezogene Automatisierung mit Azure PowerShell gleichgesetzt. Die REST-API der Azure-Dienstverwaltung stellt jedoch ebenfalls eine Option dar. Das Entwickeln von Skripts erleichtert es, die Teile der Notfallwiederherstellung zu verwalten, die von Azure nicht transparent behandelt werden. Dies bietet den Vorteil, dass stets konsistente Ergebnisse geliefert werden, wodurch die Möglichkeit menschlicher Fehler minimiert wird. Vorhandene vordefinierte Notfallwiederherstellungsskripts verringern auch die Zeit, die zum Neuerstellen eines Systems und seiner Bestandteile in einem Notfall benötigt wird. Denn natürlich möchten Sie sich nicht manuell mit der Wiederherstellung Ihres Standorts befassen, wenn dieser ausgefallen ist und Sie mit jeder Minute Geld verlieren.

Sobald die Skripts erstellt wurden, sollten Sie sie wiederholt und umfassend testen. Nachdem Sie die grundlegenden Funktionen überprüft haben, müssen Sie unbedingt Tests in Simulation von Notfällen ausführen. Solche Tests tragen dazu bei, Fehler in Skripts oder Prozessen aufzudecken.

Eine bewährte Methode in Bezug auf die Automatisierung besteht darin, ein Repository mit Azure-PowerShell-Skripts für die Notfallwiederherstellung zu erstellen. Kennzeichnen und kategorisieren Sie sie eindeutig, damit sie ohne Probleme auffindbar sind. Beauftragen Sie eine Person mit der Verwaltung des Repositorys und der Versionsverwaltung der Skripts. Stellen Sie eine ausführliche Dokumentation der Skripts mit Erklärungen der Parameter und Beispielen für die Skriptverwendung sicher. Darüber hinaus müssen Sie dafür sorgen, dass diese Dokumentation stets Ihren Azure-Bereitstellungen entspricht. Auch dies verdeutlicht die Notwendigkeit, dass eine konkrete Person für sämtliche Teile des Respositorys zuständig sein sollte.

Fehlererkennung

Um Probleme mit der Verfügbarkeit und der Notfallwiederherstellung richtig zu behandeln, müssen Sie in der Lage sein, Fehler zu erkennen und zu diagnostizieren. Hierzu bedarf es einer umfassenden Server- und Bereitstellungsüberwachung, damit Sie den vollständigen oder teilweisen Ausfall eines Systems schnell erkennen können. Ein Teil der damit verbundenen Aufgaben kann durch Überwachungstools ausgeführt werden, die die Gesamtintegrität des Cloud-Diensts und seiner Abhängigkeiten verfolgen. Microsoft stellt zwei Tools MetricsHub und System Center 2012 R2 (SCOM) zur Verfügung. Andere Tools von Drittanbietern (z. B. AzureWatch) bieten u. U. ebenfalls Überwachungsfunktionen. AzureWatch ermöglicht es Ihnen außerdem, die Skalierbarkeit zu automatisieren. Die meisten Überwachungslösungen verfolgen wichtige Leistungsindikatoren und die Dienstverfügbarkeit.

Diese Tools sind zwar unverzichtbar, sie machen das Planen von Fehlererkennung und -berichterstattung in einem Cloud-Dienst jedoch nicht überflüssig. Die ordnungsgemäße Verwendung der Azure-Diagnose muss geplant werden. Benutzerdefinierte Leistungsindikatoren oder Ereignisprotokolleinträge können auch Teil der Gesamtstrategie sein. Dadurch verfügen Sie bei Ausfällen über eine größere Menge von Daten, anhand derer das Problem diagnostiziert und der volle Funktionsumfang wiederhergestellt werden kann. Zudem werden damit zusätzliche Metriken für die Überwachungstools bereitgestellt, mit denen der Zustand der Anwendung bestimmt wird. Weitere Informationen finden Sie unter Sammeln von Protokollierungsdaten mit der Azure-Diagnose. Eine Beschreibung der Planung für ein globales "Integritätsmodell" finden Sie unter FailSafe: Leitfaden zu robusten Cloud-Architekturen.

Simulation von Notfällen

Bei Simulationstests werden kleinere reale Situationen in der tatsächlichen Arbeitsumgebung erzeugt, um die Reaktion der Teammitglieder zu untersuchen. Simulationen zeigen außerdem die Wirksamkeit der im Wiederherstellungsplan beschriebenen Lösungen. Führen Sie Simulationen so aus, dass die erstellten Szenarien zwar durchaus als "real" empfunden werden, der laufende Geschäftsbetrieb durch diese jedoch nicht unterbrochen wird.

Erwägen Sie, in der Anwendung eine Art von "Schalttafel" zu entwickeln, mit der Verfügbarkeitsprobleme manuell simuliert werden können. Lösen Sie beispielsweise über einen Softswitch Datenbankzugriffsausnahmen für ein Bestellmodul aus, indem Sie eine Fehlfunktion des Moduls bewirken. Ähnlich einfache Vorgehensweisen können auch für andere Module auf der Netzwerkschnittstellenebene verfolgt werden.

Alle nur mangelhaft behandelten Probleme werden im Verlauf der Simulation hervorgehoben. Die simulierten Szenarien müssen vollständig steuerbar sein. Dies bedeutet, dass der Normalzustand selbst bei einem voraussichtlichen Fehler des Wiederherstellungsplans wiederhergestellt werden kann, ohne dass wesentliche Schäden verursacht werden. Darüber hinaus ist stets die jeweils übergeordnete Leitungsebene vorab über Ausführungszeit und Art der Simulationsübungen zu informieren. Dieser Plan sollte Informationen zum potenziellen Ausfallzeitraum bzw. zu den Ressourcen enthalten, die der Produktionsumgebung während der Ausführung des Simulationstests entzogen werden. Wenn Sie Ihren Notfallwiederherstellungsplan einem Test unterziehen, müssen Sie unbedingt definieren, wie der Erfolg zu messen ist.

Es gibt eine Reihe anderer Techniken, mithilfe derer Sie Notfallwiederherstellungspläne testen können. Bei denen meisten davon handelt es sich jedoch schlicht um abgewandelte Versionen dieser grundlegenden Techniken. Das wichtigste Ziel dieser Tests besteht darin, die Durchführbarkeit und Verlässlichkeit des Wiederherstellungsplans zu beurteilen. Der Schwerpunkt von Tests der Notfallwiederherstellung liegt auf den Details, anhand derer Lücken im globalen Wiederherstellungsplan entdeckt werden können.

Prüfliste

Im Folgenden werden die wesentlichen der in diesem Whitepaper behandelten Punkte zusammengefasst. Damit verfügen Sie über eine Prüfliste von Aspekten, die bei Ihrer eigenen Planung für Verfügbarkeit und Notfallwiederherstellung zu beachten sind. Dies sind die bewährten Methoden, die Kunden, die sich ernsthaft mit dem Implementieren einer erfolgreichen Lösung befasst haben, als nützlich erachtet haben. Diese Art von Lösung funktioniert tatsächlich, und bei einem Systemausfall wird zeitnah und erfolgreich eine Wiederherstellung ausgeführt.

  1. Führen Sie eine Risikobewertung für jede Anwendung aus, da für jede einzelne spezifische Anforderungen gelten können. Einige Anwendungen sind wichtiger als andere, sodass bei ihrer Einrichtung in Bezug auf die Notfallwiederherstellung anfallende Zusatzkosten gerechtfertigt sein können.

  2. Verwenden Sie diese Informationen, um die RTO und die RPO für jede Anwendung festzustellen.

  3. Arbeiten Sie einen Entwurf für Ausfälle aus, und gehen Sie dabei von der Anwendungsarchitektur aus.

  4. Implementieren Sie bewährte Methoden für hohe Verfügbarkeit, und finden Sie dabei einen Kompromiss zwischen Kosten, Komplexität und Risiken.

  5. Implementieren Sie Pläne und Prozesse für die Notfallwiederherstellung.

    1. Ziehen Sie Ausfälle auf der Modulebene bis hin zu Ausfällen der gesamten Cloud in Betracht.

    2. Arbeiten Sie Sicherungsstrategien für alle Verweis- und Transaktionsdaten aus.

    3. Entscheiden Sie sich für eine Notfallwiederherstellungsstrategie mit mehreren Standorten.

  6. Beauftragen Sie eine konkrete Person mit der Zuständigkeit für Wiederherstellungsprozesse, Automatisierung und Tests. Die betreffende Person muss für den gesamten Prozess verantwortlich sein und diesen verwalten.

  7. Dokumentieren Sie die Prozesse, damit sie problemlos reproduziert werden können. Auch wenn nur eine Person verantwortlich ist, sollten mehrere Personen die bei einem Notfall auszuführenden Prozesse verstehen und diese ausführen können.

  8. Schulen Sie die Mitarbeiter in der Umsetzung des Prozesses.

  9. Nutzen Sie regelmäßige Notfallsimulationen sowohl für Schulungen als auch für die Überprüfung des Prozesses.

Zusammenfassung

Bei einem Ausfall von Hardware oder Software in Azure unterscheiden sich die Techniken und Strategien für deren Wiederherstellung von denen für lokale Systeme. Dies ist vor allem auf den Umstand zurückzuführen, dass Cloud-Lösungen normalerweise mehr infrastrukturbezogene Abhängigkeiten aufweisen, die auf das gesamte Datencenter verteilt sind und als separate Dienste verwaltet werden. Teilweise Ausfälle sind mithilfe von Techniken für hohe Verfügbarkeit zu behandeln. Schwerwiegendere Ausfälle, die möglicherweise auf einen Notfall zurückzuführen sind, werden mithilfe von Notfallwiederherstellungsstrategien behandelt.

Azure erkennt und behandelt viele Ausfälle, es gibt jedoch vielfältige Arten von Ausfällen, bei denen anwendungsspezifische Strategien verfolgt werden müssen. Sie müssen sich aktiv auf Ausfälle von Anwendungen, Diensten und Daten vorbereiten und diese verwalten.

Die Planung von Verfügbarkeit und Notfallwiederherstellung einer Anwendung sollte mit Blick auf die Geschäftsfolgen eines Ausfalls der Anwendung vorgenommen werden. Das Festlegen der Prozesse, Richtlinien und Verfahren zum Wiederherstellen wichtiger Systeme nach einem Notfall erfordert Zeit sowie einen erheblichen Planungs- und Arbeitsaufwand. Auch wenn die Pläne ausgearbeitet wurden, ist die Arbeit damit noch nicht beendet. Die Pläne sind entsprechend dem Anwendungsportfolio, den Unternehmensanforderungen und den verfügbaren Technologien regelmäßig zu analysieren, zu analysieren und kontinuierlich zu verbessern. Die neuen Azure-Funktionen zum Erstellen robuster Anwendungen, die gegen Ausfälle abgesichert sind, bringen gleichzeitig neue Herausforderungen mit sich.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.