(0) exportieren Drucken
Alle erweitern

Failsafe: Leitfaden zu robusten Cloud-Architekturen

Letzte Aktualisierung: Juni 2014

Autoren: Marc Mercuri, Ulrich Homann, Mark Simms, Jason Wescott und Andrew Townhill

Bearbeiter: Michael Thomassy, Curt Peterson, Stuart Ozer, Fran Dougherty, Tim O’Brien, Hatay Tuna, Patrick Butler Monterde, Mark Kottke, Lewis Curtis, William Bellamy

Veröffentlichungsdatum: Juni 2014

Fail-Safety (Ausfallsicherheit) Nomen. Eine Komponente, die dafür konzipiert ist, den Ausfall eines Mechanismus, Systems o. ä. automatisch zu verhindern.

Ob es um Mitarbeiter, Bürger eines Lands oder Consumer geht, jeder erwartet sofortigen Zugriff auf Anwendungs-, Server- und Datendienste. Dabei steigt die Zahl sowohl der Personen als auch der Geräte ständig an, die eine Verbindung mit diesen Diensten herstellen. In einer Welt ständig verfügbarer Dienste müssen die unterstützenden Systeme auf hohe Verfügbarkeit und Resilienz ausgelegt sein.

Diese Dienste werden in Cloud-Umgebungen bereitgestellt, die von herkömmlichen Hardwaresystemen in vordefinierten Konfigurationen beherrscht werden. In der Vergangenheit haben Sie möglicherweise leistungsfähigere Hardware gekauft, um vertikal hochzuskalieren; in Cloud-Umgebungen müssen Sie stattdessen horizontal hochskalieren. Sie halten die Kosten für diese Cloud-Umgebungen niedrig, indem Sie herkömmliche Hardware verwenden. Bei herkömmlicher Hardware kommen Ausfälle vor, und die Cloud verlangt eine Architektur, die Ausfällen schon von Grund auf Rechnung trägt. Früher haben Sie sich vielleicht auf das Vermeiden von Ausfällen und das Optimieren der MTBF (Mean Time Between Failures, durchschnittliche störungsfreie Betriebszeit) konzentriert. In dieser neuen Umgebung verlagert sich der Schwerpunkt auf die "durchschnittliche Wiederherstellungszeit bei minimalen Auswirkungen".

Es ist sehr wahrscheinlich, dass die Dienste, die Sie entwickeln, aus Komponenten zusammengesetzt sind. Sie bestehen aus einer oder mehreren Plattformen von Erstanbietern oder Drittanbietern und Diensten von Drittanbietern. Diese Dienste bauen auf einer Cloud-Infrastruktur auf, bei der Ausfälle vorkommen. Die Architektur muss darüber hinaus davon ausgehen, dass die Dienste, die diese Struktur konsumieren, ebenfalls ausfallen. Wie schon die Architektur der Infrastruktur muss auch der Entwurf der Anwendungsarchitektur Ausfällen schon im Grundsatz Rechnung tragen.

Die FailSafe-Initiative von Microsoft unterstützt diese Entwicklung mit: allgemeinen Richtlinien zur Umsetzung resilienter Cloudarchitekturen, Orientierungshilfen zum Implementieren dieser Architekturen mit Microsoft-Technologien und Know-how für die Bereitstellung dieser Architekturen in zweckgebundenen Szenarien. Die Verfasser dieses Dokuments stammen aus den Abteilungen "Cloud + Enterprise", "Trustworthy Computing" und "Microsoft Consulting Services" bei Microsoft.

Der Artikel befasst sich mit den architektonischen Anforderungen, die bei der Umsetzung skalierbarer und resilienter Systeme bedeutsam sind.

Der Beitrag ist in folgende Abschnitte unterteilt:

  • Zerlegen der Anwendung in Funktionsbereiche: Definieren, wie ein an Funktionsbereichen orientierter Ansatz eine bessere Kostenkontrolle, mehr Flexibilität in der Auswahl der optimal für den Funktionsbereich geeigneten Technologien und ein präziser optimiertes Herangehen an Verfügbarkeit und Resilienz ermöglicht.

  • Erstellen eines Lebenszyklusmodells: Die Modellierung des Anwendungslebenszyklus hilft dabei, das erwartete Verhalten einer Anwendung in einer Produktionsumgebung zu definieren, und stellt Anforderungen und Einblicke für die gesamte Architektur bereit.

  • Erstellen eines Verfügbarkeitsmodells und -plans: Ein Verfügbarkeitsmodell gibt die Verfügbarkeitsstufe an, die für den Funktionsbereich einer Anwendung erwartet wird. Viele Entscheidungen bei der Umsetzung des Diensts werden auf der Grundlage dieses wichtigen Modells getroffen.

  • Identifizieren von Schwachstellen, Fehlerzuständen und Auswirkungen von Fehlern: Für den Aufbau einer robusten Architektur ist es wichtig, die Schwachstellen und Fehlerzustände im Vorfeld zu verstehen und zu identifizieren. Ein proaktiver Ansatz trägt dazu bei, mögliche Ursachen eines Ausfalls zu verstehen und zu dokumentieren, und liefert wichtige Anhaltspunkte für die Analyse und Planung.

  • Muster und Überlegungen zur Resilienz: Dieser Abschnitt – mit wichtigen Überlegungen zu Server-, Speicher- und Plattformdiensten – bildet den Hauptteil des Dokuments. Die Überlegungen basieren auf bewährten Verfahren und gewährleisten, dass die wichtigsten Prinzipien für Server-, Speicher- und Plattformdienste umgesetzt werden und eine stabile Anwendung hervorbringen.

  • Prozessorientierte Entwicklung: In einer Welt, in der Dienste immer verfügbar sein müssen, ist das Augenmerk auf dem Betrieb in der Entwicklung von Diensten unerlässlich. Dieser Abschnitt behandelt bewährte Verfahren zur prozessorientierten Entwicklung, die sich über den gesamten Lebenszyklus erstrecken. Dazu gehört die Erstellung eines Integritätsmodells, das visuelle Telemetriedaten für Prozesse und Entwickler verfügbar macht.

Anwendungen umfassen in der Regel mehrere Funktionsbereiche.

Verschiedene Funktionseinheiten bedeuten oft unterschiedliche Anforderungen, verschiedene Kritikalitätsebenen für das Unternehmen und – davon abgeleitet – spezielle budgetäre Überlegungen. Indem ein Unternehmen eine Anwendung in Funktionseinheiten zerlegt, schafft es Raum für Flexibilität. Ein an Funktionsbereichen orientierter Ansatz ermöglicht bessere Kostenkontrolle, höhere Flexibilität bei der Auswahl der am besten geeigneten funktionalen Technologie, spezifische Verfahren für hohe Verfügbarkeit und Sicherheit, Flexibilität und Agilität beim Hinzufügen und Bereitstellen neuer Funktionalität usw.

Beim Thema Resilienz ist es manchmal hilfreich, die Anforderungen im Kontext bestimmter Szenarien zu betrachten. Beispiele für typische Szenarien:

  • Sport-Datendienst

    Ein Kunde stellt einen Datendienst mit Informationen zu Sportereignissen bereit. Der Dienst verfügt über zwei primäre Funktionsbereiche. Der erste liefert Statistikdaten über Spieler und Teams, und der zweite stellt Ergebnisse und Kommentare zu den ausgetragenen Spielen bereit.

  • E-Commerce-Website

    Ein Onlinehändler verkauft seine Waren über eine Website in einem bewährten Modell. Die Anwendung verfügt über verschiedene Bereiche, darunter vor allem eine Such- und Browserfunktion und die "Kasse".

  • Soziales Netzwerk

    Eine beliebte soziale Website ermöglicht Mitgliedern einer Community Zugriff auf gemeinschaftliche Forumsaktivitäten, auf Inhalte, die von Nutzern eingestellt werden, und auf Onlinespiele. Die Anwendung verfügt über eine Reihe von Funktionsbereichen: Registrierung, Suche und Browser, soziale Interaktion, Spiele, E-Mail usw.

  • Web

    Ein Unternehmen plant, seine Kunden über seine Website einzubinden. Die Anwendung soll sowohl von computerbasierten Browsern als auch von gängigen mobilen Endgeräten (Mobiltelefon, Tablet-PC) unterstützt werden. Sie vereint eine Reihe von Modulen wie Registrierung, Suche und Browser, Veröffentlichung von Inhalten, Kommentare, Moderation, Spiele und vieles andere mehr.

Wir befassen uns im Folgenden mit einem konkreten Szenario, indem wir es in mehrere untergeordnete Funktionsbereiche zerlegen. Eine E-Commerce-Website kann eine Reihe von Funktionsbereichen enthalten: Suche & Browser, Kasse & Verwaltung, Benutzerregistrierung, von Nutzern eingestellte Inhalte (Bewertungen und Ranking), Personalisierung usw.

Beispieldefinitionen für zwei wichtige Funktionseineinheiten in diesem Szenario:

  • Suche & Browser ermöglicht Kunden die Navigation in einem Produktkatalog, die Suche nach bestimmten Artikeln und eventuell auch die Verwaltung von Warenkörben oder Wunschlisten. Diesem Funktionsbereich können Attribute wie anonymer Benutzerzugriff, Antwortzeiten unter einer Sekunde und Caching zugewiesen werden. Ein Leistungsabfall kann auftreten, wenn eine unerwartet hohe Benutzerlast oder anwendungstolerante Unterbrechungen bei der Aktualisierung des Produktbestands zu längeren Antwortzeiten führen. In diesem Fall kann die Anwendung den Dienst aufrechterhalten, indem sie Informationen aus dem Cache bereitstellt.

  • Kasse & Verwaltung unterstützt Kunden dabei, Bestellungen aufzugeben, zu verfolgen und zu stornieren, Versand- und Zahlungsmethoden auszuwählen und Nutzerprofile zu verwalten. Dieser Funktionsbereich kann über eine Reihe anderer Attribute verfügen – zum Beispiel sicherer Zugriff, warteschlangenbasierte Verarbeitung, Zugriff auf Zahlungsgateways von Drittanbietern und Verbindung mit lokalen Back-End-Systemen. Die Anwendung toleriert zwar höhere Antwortzeiten, aber keinen Verlust der eingegangenen Bestellungen. Folglich muss sichergestellt sein, dass Kundenbestellungen immer akzeptiert und erfasst werden, unabhängig davon, ob die Anwendung in der Lage ist, die Zahlung abzuwickeln oder den Versand zu organisieren.

Die Abbildung des Anwendungslebenszyklus definiert das Verhalten, das von einer Anwendung im laufenden Betrieb erwartet wird. Eine Anwendung stellt während verschiedener Phasen und Zeiten unterschiedliche Anforderungen an das System, die sowohl die Funktionalität als auch die Skalierbarkeit betreffen können. Diese Faktoren werden im Lebenszyklusmodell berücksichtigt.

Die für Funktionseinheiten definierten Lebenszyklusmodelle müssen alle einschlägigen und zutreffenden Szenarien mit passender Auflösung erfassen. Der Lebenszyklus eines Diensts berücksichtigt auch Abweichungen, die je nach Stunde, Tag, Woche oder Jahreszeit auftreten können. Deshalb sollten spezifische Kapazitäts-, Leistungs- und Skalierbarkeitsanforderungen bei der Modellerstellung im zeitlichen Verlauf betrachtet werden.

Abbildung 1. Beispiele für Lebenszyklen in verschiedenen Branchen und Szenarien

Es werden häufig Phasen auftreten, die einen eigenen, besonderen Lebenszyklus aufweisen, wie etwa:

  • Eine Spitze, die auf eine Nachfragespitze während eines Feiertagszeitraums zurückgeht.

  • Ein Anstieg bei Steuererstattungen direkt vor dem Fälligkeitsdatum.

  • Zeitfenster für Berufsverkehr (Pendler) am Morgen und am Nachmittag.

  • Leistungsbeurteilung von Mitarbeitern am Jahresende.

Viele Organisationen verstehen diese Szenarien und die mit ihnen zusammenhängenden szenariotypischen Lebenszyklen.

Mithilfe von Aufteilung können Sie auf der Funktionsbereichebene verschiedene interne Vereinbarungen zum Service Level (SLAs, Service Level Agreements) verwenden. Ein Beispiel dafür bietet die Sportereignisdaten-API, für die ein Ziel-SLA von 99,99 % festgelegt wurde. Diese API lässt sich jedoch in zwei Funktionsbereiche aufteilen: "Live-Punktestände & Kommentar" und "Team-, Spieler- und Ligastatistiken"

Für den Funktionsbereich "Live-Punktestände & Kommentar" folgt der Lebenszyklus einem "An/Aus"-Muster. Die Verfügbarkeit von "Team-, Spieler- und Ligastatistiken" ist jedoch konstant. Die Aufteilung nach Funktionsbereichen ermöglicht Ihnen, auf die Verfügbarkeitsanforderungen der zusammengesetzten Arbeitslast des Verbunddiensts maßgeschneiderte SLAs zu verwenden.

Abbildung 2

Nachdem ein Lebenszyklusmodell identifiziert wurde, besteht der nächste Schritt darin, ein Modell und einen Plan für die Verfügbarkeit zu erstellen. Ein Verfügbarkeitsmodell gibt die Verfügbarkeitsstufe an, die für den Funktionsbereich einer Anwendung erwartet wird. Viele Entscheidungen bei der Umsetzung des Diensts werden auf der Grundlage dieses wichtigen Modells getroffen.

Der Modellerstellung liegen eine Reihe von Überlegungen und Maßnahmen zugrunde.

Bei der Entwicklung des Verfügbarkeitsplans müssen eine Reihe von Faktoren ermittelt werden: die gewünschte Verfügbarkeit der Anwendung, die Funktionsbereiche innerhalb der Anwendung und die Dienste zur Bereitstellung der Funktionsbereiche.

Die Kenntnis des Lebenszyklus Ihres Funktionsbereichs hilft Ihnen bei der Auswahl der SLA, die Sie einsetzen möchten. Möglicherweise wird Ihnen auf dem Markt keine SLA für Ihren Dienst angeboten. Ihre Architektur sollte jedoch eine Basisverfügbarkeit anstreben, die Sie zu erreichen versuchen.

Abhängig von der Art der Lösung, die Sie erstellen, gerät eine Reihe von Überlegungen und Optionen für das Erzielen einer höheren Verfügbarkeit ins Blickfeld. Kommerzielle Dienstanbieter bieten keine SLAs mit 100 % Verfügbarkeit an, da Komplexität und Kosten zum Erreichen dieser SLA nicht umsetzbar oder wirtschaftlich nicht darstellbar sind. Das Aufteilen Ihrer Anwendung nach Funktionsbereichen ermöglicht Ihnen, Entscheidungen zu treffen und Ansätze zum Erreichen der gewünschten Verfügbarkeit zu implementieren. Das Erreichen von 99,99 % Verfügbarkeit für die gesamte Anwendung kann jenseits des Möglichen liegen, für einen Funktionsbereich in einer Anwendung ist es jedoch machbar.

Auch auf dieser Ebene müssen Sie nicht jede Option implementieren. Welche Option Sie implementieren, hängt von Ihren individuellen Anforderungen ab. Bevor Sie die tatsächlichen Optionen auswählen, sollten Sie alle Möglichkeiten in einem fundierten und überlegten Prozess abwägen.

Autonomie ist ein Synonym für Unabhängigkeit und beschreibt das Bemühen, Abhängigkeiten zwischen den Modulen eines Diensts abzubauen. Abhängigkeiten von Komponenten, Daten und externen Einheiten sind bei der Konzeptionierung eines Diensts zu untersuchen. Es ist darauf zu achten, dass die Funktionsbereiche in autonomen Diensteinheiten implementiert werden. Das erzeugt eine Agilität, auf die es ankommt, wenn getrennte autonome Einheiten unabhängig voneinander aktualisiert oder in optimal abgestimmter Weise skaliert werden sollen.

Arbeitslastorientierte Architekturen setzen sich häufig aus autonomen Komponenten zusammen, die keinen manuellen Eingriff erfordern und nicht beeinträchtigt werden, wenn Entitäten – von denen sie abhängen – nicht verfügbar sind. Anwendungen mit autonomen Funktionsbereichen sind:

  • hoch verfügbar und betriebsbereit

  • resilient und nach einem Ausfall schnell wieder betriebsbereit

  • weniger anfällig für kritische Fehlerbedingungen

  • einfach skalierbar im Wege der Replikation

  • weniger wartungsanfällig (z. B. keine manuelle Intervention)

Diese autonomen Einheiten basieren häufig auf asynchroner Kommunikation, PULL-basierter Datenverarbeitung und automatisierten Funktionen zur Aufrecherhaltung der Dienstkontinuität.

In Zukunft wird sich der Markt in eine Richtung entwickeln, bei der standardisierte Schnittstellen für bestimmte Funktionalitäten – vertikal oder horizontal – an der Tagesordnung sind. Wenn diese Zukunftsvision Wirklichkeit wird, kann ein Dienstanbieter mit unterschiedlichen Anbietern über verschiedene Implementierungen hinweg zusammenarbeiten, die die Arbeit der autonomen Einheit übernehmen. Um Kontinuität zu gewährleisten, werden Dienste autonom und richtlinienbasiert ausgeführt.

In dem Maße, wie sich autonome Modelle durchsetzen, steigt auch die Abhängigkeit vieler Dienste von Drittanbietern – und sei es nur ein Hostinganbieter. Es ist unverzichtbar, die SLAs dieser abhängigen Dienste zu verstehen und in den Verfügbarkeitsplan einzubeziehen.

In diesem Abschnitt werden die unterschiedlichen SLA-Typen behandelt, die für einen Dienst relevant sein könnten. Für jeden dieser Diensttypen gelten wichtige Überlegungen und Fragestellungen.

Öffentliche Cloudplattformdienste

Die auf einer kommerziellen Cloudplattform bereitgestellten Dienste, z. B. Server- oder Speicherkapazitäten, verfügen über SLAs, die auf Kundenzahlen in einer erheblichen Größenordnung ausgelegt sind. Die SLAs für diese Dienste sind also nicht verhandelbar. Ein Anbieter kann mehrschichtige Dienste mit unterschiedlichen SLAs bereitstellen, auch diese Ebenen sind nicht verhandelbar. Der Dienstanbieter verwendet abgestufte Service Level mit verschiedenen SLAs, um eine vorhersagbare Dienstqualität zur Verfügung stellen zu können.

Fragestellungen für diesen Diensttyp:

  • Lässt dieser Dienst nur eine bestimmte Anzahl von Dienst-API-Aufrufen zu?

  • Begrenzt dieser Dienst die Häufigkeit der Dienst-API-Aufrufe?

  • Begrenzt dieser Dienst die Anzahl der Server, die die Dienst-API aufrufen können?

  • Welche öffentlichen Ankündigungen wurden in Bezug auf die Verfügbarkeit des Diensts gemacht?

  • Wie kommuniziert der Dienst seinen Integritätsstatus?

  • Welche SLA wurde angegeben?

  • Welche äquivalenten Plattformdienste werden von anderen Drittanbietern bereitgestellt?

"Kostenlose" Dienste von Drittanbietern

Viele Drittanbieter stellen der Community "kostenlose" Dienste zur Verfügung. Bei Unternehmen des privaten Sektors erfüllt dies hauptsächlich den Zweck, ein Ökosystem von Anwendungen um die angebotenen Kernprodukte oder -dienste aufzubauen. Der öffentliche Sektor gewährt den Bürgern und Unternehmen eines Lands über diese Dienste Einsicht in Daten, die sie durch die Abgabe von Steuern sozusagen "mitfinanziert" haben.

Die meisten Dienste werden nicht unter einer SLA angeboten, sodass keine Verfügbarkeit garantiert wird. Wenn SLAs angeboten werden, gehen sie normalerweise mit Nutzungseinschränkungen für Anwendungen und Mechanismen einher und setzen sie durch. Beispielsweise kann der Zugriff gedrosselt oder der Kunde auf eine "Schwarze Liste" gesetzt werden, sobald eine Lösung eine maximale Anzahl von Serviceanforderungen, eine bestimmte Anzahl von Anforderungen in einem bestimmten Zeitraum (x pro Minute) oder die Anzahl der zulässigen Server überschreitet, die Anforderungen an den Dienst senden.

Fragestellungen für diesen Diensttyp:

  • Lässt dieser Dienst nur eine bestimmte Anzahl von Dienst-API-Aufrufen zu?

  • Begrenzt dieser Dienst die Häufigkeit der Dienst-API-Aufrufe?

  • Begrenzt dieser Dienst die Anzahl der Server, die die Dienst-API aufrufen können?

  • Welche öffentlichen Ankündigungen wurden in Bezug auf die Verfügbarkeit des Diensts gemacht?

  • Wie kommuniziert der Dienst seinen Integritätsstatus?

  • Welche SLA wurde angegeben?

  • Handelt es sich um einen Dienst, bei dem die erforderlichen Funktionalitäten und/oder Daten von mehreren Dienstanbietern angeboten werden?

  • Kann die Schnittstelle im letzteren Fall von anderen Dienstanbietern genutzt werden (direkt oder über eine verfügbare Abstraktionsschicht)?

  • Welche äquivalenten Plattformdienste werden von anderen Drittanbietern bereitgestellt?

Kommerzielle Dienste von Drittanbietern

Kommerzielle Dienste von Drittanbietern werden mit SLAs angeboten, die auf die Bedürfnisse zahlender Kunden ausgelegt sind. Ein Anbieter kann mehrschichtige SLAs mit unterschiedlichen Verfügbarkeitsebenen bereitstellen, diese SLAs sind jedoch nicht verhandelbar.

Fragestellungen für diesen Diensttyp:

  • Lässt dieser Dienst nur eine bestimmte Anzahl von Dienst-API-Aufrufen zu?

  • Begrenzt dieser Dienst die Häufigkeit der Dienst-API-Aufrufe?

  • Begrenzt dieser Dienst die Anzahl der Server, die die Dienst-API aufrufen können?

  • Welche öffentlichen Ankündigungen wurden in Bezug auf die Verfügbarkeit des Diensts gemacht?

  • Wie kommuniziert der Dienst seinen Integritätsstatus?

  • Welche SLA wurde angegeben?

  • Handelt es sich um einen Dienst, bei dem die erforderlichen Funktionalitäten und/oder Daten von mehreren Dienstanbietern angeboten werden?

  • Kann die Schnittstelle im letzteren Fall von anderen Dienstanbietern genutzt werden (direkt oder über eine verfügbare Abstraktionsschicht)?

  • Welche äquivalenten Plattformdienste werden von anderen Drittanbietern bereitgestellt?

Clouddienste für die Community

Eine aus mehreren Organisationen bestehende Community, z. B. eine Supply-Chain (Lieferkette), stellt Dienste für Mitgliedsorganisationen bereit.

Fragestellungen für diesen Diensttyp:

  • Lässt dieser Dienst nur eine bestimmte Anzahl von Dienst-API-Aufrufen zu?

  • Begrenzt dieser Dienst die Häufigkeit der Dienst-API-Aufrufe?

  • Begrenzt dieser Dienst die Anzahl der Server, die die Dienst-API aufrufen können?

  • Welche öffentlichen Ankündigungen wurden in Bezug auf die Verfügbarkeit des Diensts gemacht?

  • Wie kommuniziert der Dienst seinen Integritätsstatus?

  • Welche SLA wurde angegeben?

  • Haben Mitglieder der Community die Möglichkeit, eine andere SLA auszuhandeln?

  • Handelt es sich um einen Dienst, bei dem die erforderlichen Funktionalitäten und/oder Daten von mehreren Dienstanbietern angeboten werden?

  • Kann die Schnittstelle im letzteren Fall von anderen Dienstanbietern genutzt werden (direkt oder über eine verfügbare Abstraktionsschicht)?

  • Welche äquivalenten Plattformdienste werden von anderen Drittanbietern bereitgestellt?

Interne unternehmensweite Clouddienste von Erstanbietern

Ein Unternehmen kann seine Kerndienste, z. B. Börsenkursticker oder Produktmetadaten, für Geschäftsbereiche und Abteilungen verfügbar machen.

Fragestellungen für diesen Diensttyp:

  • Lässt dieser Dienst nur eine bestimmte Anzahl von Dienst-API-Aufrufen zu?

  • Begrenzt dieser Dienst die Häufigkeit der Dienst-API-Aufrufe?

  • Begrenzt dieser Dienst die Anzahl der Server, die die Dienst-API aufrufen können?

  • Welche öffentlichen Ankündigungen wurden in Bezug auf die Verfügbarkeit des Diensts gemacht?

  • Wie kommuniziert der Dienst seinen Integritätsstatus?

  • Welche SLA wurde angegeben?

  • Haben Mitglieder der Organisation die Möglichkeit, eine andere SLA auszuhandeln?

  • Handelt es sich um einen Dienst, bei dem die erforderlichen Funktionalitäten und/oder Daten von mehreren Dienstanbietern angeboten werden?

  • Kann die Schnittstelle im letzteren Fall von anderen Dienstanbietern genutzt werden (direkt oder über eine verfügbare Abstraktionsschicht)?

  • Welche äquivalenten Plattformdienste werden von anderen Drittanbietern bereitgestellt?

Interne bereichs- oder abteilungsweite Clouddienste von Erstanbietern

Ein Geschäftsbereich oder eine Abteilung innerhalb eines Unternehmens kann Dienste für andere Mitglieder der unmittelbaren Organisation verfügbar machen.

Fragestellungen für diesen Diensttyp:

  • Lässt dieser Dienst nur eine bestimmte Anzahl von Dienst-API-Aufrufen zu?

  • Begrenzt dieser Dienst die Häufigkeit der Dienst-API-Aufrufe?

  • Begrenzt dieser Dienst die Anzahl der Server, die die Dienst-API aufrufen können?

  • Welche öffentlichen Ankündigungen wurden in Bezug auf die Verfügbarkeit des Diensts gemacht?

  • Wie kommuniziert der Dienst seinen Integritätsstatus?

  • Welche SLA wurde angegeben?

  • Haben Mitglieder des Bereichs die Möglichkeit, eine andere SLA auszuhandeln?

  • Handelt es sich um einen Dienst, bei dem die erforderlichen Funktionalitäten und/oder Daten von mehreren Dienstanbietern angeboten werden?

  • Kann die Schnittstelle im letzteren Fall von anderen Dienstanbietern genutzt werden (direkt oder über eine verfügbare Abstraktionsschicht)?

  • Welche äquivalenten Plattformdienste werden von anderen Drittanbietern bereitgestellt?

Bedeutung der "9nen" in Bezug auf die Verfügbarkeit von Verbunddiensten

Vorhandene Dienste bieten ein enormes Potenzial, um die Agilität der Lösungsbereitstellung für die Organisation oder den kommerziellen Handel beträchtlich zu steigern. Obwohl das verlockend klingt, ist es absolut wichtig, sich die Auswirkungen zu vergegenwärtigen, die diese Abhängigkeiten auf die gesamte SLA für den Funktionsbereich haben.

Die Verfügbarkeit wird in der Regel als prozentuale Betriebszeit eines bestimmten Jahres ausgedrückt. Dieser Ausdruck für die prozentuale Verfügbarkeit, die Verfügbarkeitsklasse, wird durch die Anzahl der "Neunen" ausgedrückt. So stellt beispielsweise 99,9 die Verfügbarkeitsklasse 3 (3 Neunen) und 99,999 die Verfügbarkeitsklasse 5 (5 Neunen) dar.

 

Verfügbarkeit (%)

Downtime pro Jahr

Downtime pro Monat

Downtime pro Woche

90 % ("1 Neun")

36,5 Tage

72 Stunden

16,8 Stunden

95%

18,25 Tage

36 Stunden

8,4 Stunden

97%

10,96 Tage

21,6 Stunden

5,04 Stunden

98%

7,30 Tage

14,4 Stunden

3,36 Stunden

99 % ("2 Neunen")

3,65 Tage

7,20 Stunden

1,68 Stunden

99.5%

1,83 Tage

3,60 Stunden

50,4 Minuten

99.8%

17,52 Stunden

86,23 Minuten

20,16 Minuten

99,9 % ("3 Neunen")

8,76 Stunden

43,2 Minuten

10,1 Minuten

99.95%

4,38 Stunden

21,56 Minuten

5,04 Minuten

99,99% ("4 Neunen")

52,56 Minuten

4,32 Minuten

1,01 Minuten

99,999 % ("5 Neunen")

5,26 Minuten

25,9 Sekunden

6,05 Sekunden

99,9999 % ("6 Neunen")

31,5 Sekunden

2,59 Sekunden

0,605 Sekunden

99,99999 % ("7 Neunen")

3,15 Sekunden

0,259 Sekunden

0,0605 Sekunden

Ein allgemeines Missverständnis besteht hinsichtlich Anzahl der "9nen" bei Verbunddiensten. Wenn sich ein bestimmter Dienst aus fünf Diensten zusammensetzt, von denen jeder über eine angekündigte SLA-Betriebszeit von 99,99 % verfügt, wird häufig angenommen, dass der resultierende Verbunddienst eine Verfügbarkeit von 99,99 % hat. Das ist nicht der Fall.

Abbildung 3: Downtime der häufigen "9nen"

Der Verbund-SLA stellt faktisch eine Berechnung dar, die die Downtime pro Jahr angibt. Ein Dienst mit einer SLA von "vier 9nen" (99,99 %) kann bis zu 52,56 Minuten offline sein.

Werden fünf Dienste mit einer SLA von 99,99 % in einem Verbunddienst gebündelt, beträgt das resultierende SLA-Risiko 262,8 Minuten oder 4,38 Stunden. Dadurch verringert sich die Verfügbarkeit auf 99,95 % noch bevor nur eine einzige Zeile Code erstellt wurde!

Im Allgemeinen trifft es zu, dass sich die Verfügbarkeit von Drittanbieterdiensten nicht beeinflussen lässt. Beim Erstellen Ihres Codes können Sie jedoch die Gesamtverfügbarkeit Ihrer Anwendungen mithilfe von Techniken, wie sie in diesem Dokument beschrieben werden, steigern.

noteHinweis
Für einige Dienste stehen möglicherweise verschiedene Dienstebenen in verschiedenen Preislagen oder für Geschäftspartner zur Verfügung.

Betrachten wir noch einmal die schon erwähnte Sportereignisdaten-API. Benutzer können Spiele nur an bestimmten Tagen und dann auch nur über eine festgelegte Anzahl Stunden spielen. Während dieser Zeiträume, läge die SLA bei 100 %. Wenn keine Spiele angesetzt sind, hat dieser Funktionsbereich eine SLA von 0 %. Der Funktionsbereich "Team-, Spiele- und Ligastatistiken" hat ein einheitlicheres Lebenszyklusmuster. Es ist sogar erforderlich, dass dieser Funktionsbereich jederzeit einen 99 %-SLA aufweist.

Abbildung 4

Bei der Nutzung externer Dienste kann nicht oft genug auf die Bedeutung von SLAs – sowohl für Einzeldienste als auch für Verbunddienste – hingewiesen werden.

Das Verständnis einer Architektur ist wichtig, um eine resiliente Lösung umzusetzen. Ein proaktiver Ansatz hilft, mögliche Ursachen für Ausfallzeiten zu verstehen und zu dokumentieren.

Wenn Sie sich die Schwachstellen und Fehlerzustände für eine Anwendung und die beteiligten Arbeitslastdienste vergegenwärtigen, können Sie die Wahl Ihrer Resilienz- und Verfügbarkeitsstrategien auf fundierte Entscheidungen stützen.

Schwachstellen sind Punkte, an denen Fehler oder Ausfälle zu einer Dienstunterbrechung führen können. Besonderes Augenmerk gilt den Elementen, die externen Änderungen unterliegen.

Beispiele für Schwachstellen sind:

  • Datenbankverbindungen

  • Websiteverbindungen

  • Konfigurationsdateien

  • Registrierungsschlüssel

Kategorien allgemeiner Schwachstellen sind:

  • Zugriffssteuerungslisten

  • Datenbankzugriff

  • Externer Zugriff auf Websites/Dienste

  • Transaktionen

  • Konfiguration

  • Kapazität

  • Netzwerk

Während Schwachstellen die Bereiche definieren, die einen Ausfall herbeiführen können, bezeichnen Fehlerzustände die bestimmte Art und Weise eines Ausfalls.

Beispiele für Fehlerzustände sind:

  • Fehlende Konfigurationsdatei

  • Datenverkehr, der die Ressourcenkapazität deutlich überschreitet

  • Eine Datenbank an der maximalen Kapazitätsgrenze

Die Auswirkungen von Fehlern sind die Folgen der Fehler für die Funktionalität. Informieren Sie sich über die Auswirkungen von Fehlern und die Häufigkeit, mit der die einzelnen Fehlerarten wahrscheinlich auftreten. Dadurch können Sie Prioritäten für die Arbeit an den Schwachpunkten und Fehlerzuständen Ihrer Anwendung oder Ihres Diensts festlegen.

Dieses Dokument enthält wichtige Überlegungen zu Server-, Speicher- und Plattformdiensten. Bevor auf diese Themen eingegangen wird, ist es wichtig, einige grundlegende Punkte aufzugreifen, die sich auf die Resilienz auswirken und häufig missverstanden und/oder nicht implementiert werden.

Wie bereits erwähnt, sollte eine resiliente Architektur für autonomen Betrieb optimiert sein. Eine der Methoden, diese Autonomie zu erreichen, ist die asynchrone Auslegung der Kommunikation. Eine resiliente Architektur sollte immer auf asynchroner Interaktion basieren und nur in Ausnahmefällen die synchrone Interaktion zulassen.

Zustandslose Webebenen oder Webebenen mit verteiltem Cache können dies am Front-End einer Lösung gewährleisten. Warteschlangen können diese Kommunikationsfähigkeit bieten, um die Interaktion zwischen Arbeitslastdiensten bzw. zwischen Diensten innerhalb eines Arbeitslastdiensts zu ermöglichen.

Dabei können Nachrichten in Warteschlangen eingereiht und von sekundären Diensten abgerufen werden. Diese Kommunikation kann auf einer zeit- oder volumenabhängigen Logik basieren. Zusätzlich zur asynchronen Kommunikation ist auch eine Skalierung der Ebenen möglich, die nach Bedarf PUSH- oder PULL-Befehle an die Warteschlangen senden.

Häufig treten vorübergehende Fehler an Stellen auf, an denen die Architektur eine Verbindung mit einem Dienst oder einer Ressource, z. B. einer Datenbank, herstellt. Bei der Nutzung dieser Dienste empfiehlt es sich, eine Logik zu implementieren, die auf dem "Timeout"-Prinzip basiert. Diese Logik gibt einen zulässigen Zeitrahmen an, in dem eine Antwort erwartet wird. Wird dieser Zeitrahmen überschritten, gibt sie einen identifizierbaren Fehler aus. Sobald der Timeoutfehler angezeigt wird, werden entsprechende Maßnahmen ergriffen, die sich nach dem jeweiligen Fehlerkontext richten. Der Kontext kann angeben, wie häufig der Fehler aufgetreten ist, welche Auswirkungen die nicht verfügbare Ressource hat und welche SLA-Zusicherungen einem bestimmten Kunden für den aktuellen Zeitraum gegeben wurden.

Bei der Entwicklung von Diensten, die die Arbeitslast tragen, müssen Sie in Kauf nehmen, dass Ausfallzeiten auftreten, und geeignete Abhilfemaßnahmen treffen.

Eine der häufigsten Fehlerkategorien sind vorübergehende Fehler. Da kein Dienst zu 100 % verfügbar ist, muss immer einkalkuliert werden, dass mit einem Dienst, von dem ein Funktionsbereich abhängig ist, keine Verbindung hergestellt werden kann. Dieser Zustand oder die Fehler, die bei einem dieser Dienste auftreten, können flüchtig (< 1 Sekunde) oder permanent sein (Dienst wird vom Anbieter eingestellt).

Stufenweise Lösung

Der Arbeitslastdienst sollte so konzipiert sein, dass er vorübergehende Fehlerbedingungen stufenweise auflöst. Bei einem Ausfall seines Cloudanbieters ist die Onlinevideothek Netflix beispielsweise auf eine ältere Videowarteschlange ausgewichen, als der primäre Datenspeicher für seine Kunden nicht verfügbar war. Ein weiteres Beispiel ist eine E-Commerce-Website, die weiterhin Bestellungen entgegennimmt, während das Zahlungsgateway vorübergehend nicht erreichbar ist. Auf diese Weise können Bestellungen verarbeitet werden, sobald das Gateway wieder verfügbar ist oder nachdem ein Failover auf ein sekundäres Zahlungsgateway ausgeführt wurde.

Überlegungen für maßvolle Leistungseinbußen auf hoher Ebene

Bei Überlegungen über die Möglichkeiten, Leistungseinbußen im Rahmen zu halten, sind die folgenden Punkte wichtig:

  • Komponenten, die nicht im Besitz des gesamten Kontexts einer Anforderung sind, sollten einfach ausfallen und die Ausnahmemeldung weitergeben. Sie können dieses Problem beheben, indem Sie einen Trennschalter ("Circuit Breaker"), der weiter unten in diesem Dokument beschrieben wird, implementieren, der beim Erreichen der festgelegten Grenzwerte schnell ausfällt.

  • Ihrer Natur nach vorübergehende Ausfälle sind häufig. Verarbeiten Sie sie mithilfe des Wiederholungsmusters, das ebenfalls weiter unten in diesem Dokument beschrieben wird.

  • Der Aufrufer ist möglicherweise imstande, fehlgeschlagene Anforderungen zu korrigieren, indem er die Anforderung mit anderen Parametern oder über einen anderen Pfad erneut sendet.

  • Wenn der Erfolg der Anforderung für das Szenario nicht kritisch ist, verarbeiten Sie den Fehler einfach durch Fortlassen.

  • Sie können Fehler so verarbeiten, dass Sie eine Erfolgsnachricht zurückgeben und die fehlgeschlagenen Anforderungen zur späteren Verarbeitung, wenn die Ressource wieder in einen normalen Zustand zurückgekehrt ist, in eine Warteschlange einstellen.

  • Möglicherweise können Sie etwas zurückgeben, das in der Vergangenheit richtig war, etwa gespeicherte Anmeldeinformationen, abgelaufene Daten aus dem Cache usw.

  • Einige Fehler können dadurch verarbeitet werden, dass Sie ein "fast richtiges" Verhalten anbieten, z. B. temporären Zugriff, Näherungswerte, Werte mit der höchsten Wahrscheinlichkeit, keine Ausführung von Skripts usw.

  • Statt einen Fehler auszulösen, können Sie möglicherweise eine Alternative anbieten, z. B. Zufallswerte, anonyme Anmelderechte, Standardbilder usw.

Überlegungen zur Behandlung vorübergehender Fehler

Die effektive Behandlung vorübergehender Fehler basiert auf mehreren wichtigen Überlegungen, die in den folgenden Abschnitten beschrieben sind.

  • Wiederholungslogik

    Die einfachste Form ist die Wiederholung des Vorgangs, der den Fehler ausgelöst hat. Bei der Nutzung eines kommerziellen Drittanbieterdiensts kann die Implementierung einer "Wiederholungslogik" häufig Abhilfe schaffen.

    Es ist darauf hinzuweisen, dass Entwickler die Anzahl der Wiederholungen, die von der Logik ausgeführt werden, einschränken sollten. Die Logik versucht in der Regel, die Aktionen mit einer bestimmten Häufigkeit zu wiederholen. Wenn der Fehler weiterhin besteht, wird ein Fehler registriert und/oder ein sekundärer Dienst oder Workflow eingesetzt.

  • Exponential Backoff-Algorithmus

    Wenn der vorübergehende Fehler auf eine Drosselung des Diensts aufgrund zu hoher Arbeitslast zurückgeht, würden wiederholte Versuche, den Dienst aufzurufen, einen weiteren Drosselungsgrund liefern und sich negativ auf die Gesamtverfügbarkeit auswirken.

    Häufig ist es vorteilhaft, die Anzahl der Dienstaufrufe zu reduzieren, um eine Drosselung zu vermeiden oder einzuschränken. Dies geschieht in der Regel über einen Algorithmus nach folgendem Muster: sofortige Wiederholung nach dem ersten Fehler, 1 Sekunde warten nach dem zweiten Fehler, 5 Sekunden nach dem dritten Fehler usw., bis die Anforderung schließlich erfolgreich ist oder der Fehlerschwellenwert einer Anwendung erreicht wird.

    Diese Vorgehensweise wird als "Exponential Backoff" bezeichnet.

  • Idempotenz

    Eine Grundannahme bei Verbunddiensten besteht darin, dass diese Dienste nicht zu 100 % verfügbar sind und dass die Behandlung vorübergehender Fehler mithilfe einer Wiederholungslogik ein zentraler Implementierungsansatz ist. In Fällen, in denen eine Wiederholungslogik implementiert wird, besteht das Risiko, dass dieselbe Nachricht mehrere Male oder entgegengesetzt der normalen Reihenfolge gesendet wird.

    Designer sollten idempotente Prozesse entwickeln, um sicherzustellen, dass eine mehrfach gesendete Nachricht nicht zu einem unerwartet vollen oder belasteten Datenspeicher führt.

    Wenn beispielsweise Daten aller Anforderungen gesammelt werden, kann dies dazu führen, dass mehrere Datensätze hinzugefügt werden, wenn der Dienstvorgang mehrere Male aufgerufen wird. Eine alternative Methode besteht darin, den Code als intelligente UPSERT-Funktion zu implementieren. Ein Zeitstempel oder globaler Bezeichner könnte dazu dienen, neue von bereits verarbeiteten Nachrichten zu unterscheiden, wobei nur neuere in die Datenbank eingefügt und vorhandene Datensätze aktualisiert werden, wenn die Nachricht aktueller ist als die in der Vergangenheit empfangene Nachricht.

  • Kompensationsverhalten

    Zusätzlich zur Idempotenz liefert der Begriff "Kompensationsverhalten" einen weiteren wertvollen Ansatz. Vor dem Hintergrund immer größerer vernetzter Systeme und einer zunehmenden Zahl von Verbunddiensten ist das genaue Verständnis des Begriffs "Kompensationsverhalten" besonders wichtig.

    Der Begriff "Transaktion" ist vielen Entwicklern von Branchenanwendungen bereits seit langem bekannt, er bezieht sich jedoch häufig auf die Transaktionsfunktionalität, die von lokalen Datentechnologien und zugehörigen Codebibliotheken verfügbar gemacht wird. Bezieht man das Konzept auf die Cloud, muss dieser Ansatz neu überdacht und auf die Orchestrierung verteilter Dienste angewendet werden.

    Die Orchestrierung von Diensten kann sich über mehrere verteilte Systeme erstrecken und in einen langwierigen und zustandsorientierten Prozess münden. Die Orchestrierung selbst läuft selten synchron ab, sie kann mehrere Systeme umfassen und sich je nach Geschäftsumfeld über einen Zeitraum von Sekunden bis hin zu mehreren Jahren erstrecken.

    An einem Supply-Chain-Szenario, das 25 Organisationen in dieselbe Arbeitslastaktivität einbindet, können beispielsweise 25 oder mehr Systeme beteiligt sein, die in einer oder mehreren Orchestrierungen vernetzt werden.

    Falls eine Transaktion erfolgreich verläuft, müssen die 25 Systeme davon in Kenntnis gesetzt werden. Für jeden Verbindungspunkt in der Aktivität können Teilnehmersysteme eine Korrelations-ID für Nachrichten bereitstellen, die sie von anderen Systemen empfangen. Je nach Aktivitätstyp kann der Empfang der Korrelations-ID bereits ausreichen, um die Transaktion als abgeschlossen anzusehen. In anderen Fällen wird – sobald die Interaktionen aller 25 Teilnehmer abgeschlossen sind – eine Bestätigungsmeldung an alle Teilnehmer gesendet (entweder direkt von einem Einzelgerät oder über die spezifischen Interaktionspunkte der einzelnen Systeme).

    Um Fehler in Verbundaktivitäten und/oder verteilten Aktivitäten zu behandeln, würde jeder Dienst eine Dienstschnittstelle und Vorgänge verfügbar machen, um Abbruchanforderungen für eine bestimmte Transaktionen unter Angabe eines eindeutigen Bezeichners zu empfangen. Hinter den Kulissen würden Workflows installiert werden, die den Abbruch dieser Aktivität kompensieren. Im Idealfall sind dies automatisierte Prozeduren, allerdings kann auch ein Mitarbeiter aufgefordert werden, manuell Abhilfe zu schaffen.

Ein "Circuit-Breaker" (Trennschalter) ist eine Vorrichtung, die den elektrischen Stromfluss automatisch unterbricht, wenn die Spannung einen voreingestellten Grenzwert überschreitet. Trennschalter werden meist als Sicherheitsmaßnahme verwendet, wenn zu hohe Stromaufnahme in einem Schaltkreis gefährlich werden könnte. Im Gegensatz zu einer Sicherung kann ein Trennschalter zurückgesetzt und wiederverwendet werden.

Das gleiche Muster findet in der Softwareentwicklung Anwendung, insbesondere wenn Verfügbarkeit und Resilienz zu den wichtigsten Merkmalen eines Diensts zählen.

Wenn eine Ressource nicht verfügbar ist, kann die Implementierung eines softwarebasierten "Trennschalters" eine bestimmte Aktion auslösen.

Ein Trennschalter kann drei Status aufweisen: Geschlossen, geöffnet und halb geöffnet.

Der geschlossene Zustand ist der normale Zustand für die Anwendung oder den Dienst. In geschlossenem Zustand des Trennschalters werden Anforderungen über den Standardpfad geleitet. Ein Zähler erfasst die Ausfallraten und vergleicht sie mit einem Schwellenwert. Wenn diese Ausfallrate den Schwellenwert überschreitet, wechselt der Trennschalter in den geöffneten Zustand. Wenn eine Datenbankressource nach 100 aufeinander folgenden Verbindungsversuchen nicht aufgerufen werden kann, ergibt es wenig Sinn, weitere Anforderungen an die Datenbank zu senden. Ein "Circuit-Breaker", der die geeigneten Aktionen auslöst, kann bei Erreichen dieses Schwellenwerts aktiviert werden.

Im geöffneten Zustand leitet der Trennschalter Anforderungen auf den/die Entschärfungspfad(e). Das kann ein sofortiger Ausfall oder eine andere Art des geordneten Ausstiegs sein. Beim Wechsel in den geöffneten Zustand löst der Trennschalter außerdem einen Zeitgeber aus. Beim Ablaufen des Zeitgebers wird der Trennschalter in einen halb geöffneten Zustand versetzt.

Im halb geöffneten Zustand wird eine eingeschränkte Anzahl Anforderungen über den normalen Pfad geleitet. Werden sie erfolgreich ausgeführt, wechselt der Trennschalter in den geschlossenen Zustand. Wenn die Verarbeitung dieser eingeschränkten Anzahl Anforderungen fehlschlägt, kehrt der Trennschalter zum geöffneten Zustand zurück.

Wenn Sie in Ihre Architektur einen Trennschalter einbeziehen, überlegen Sie folgende Punkte:

  • Ein Trennschalter kann je nach dem Typ der Ausnahme, die von einem Vorgang ausgelöst wird, im geöffneten Zustand verschiedene Entschärfungspfade oder verschiedene Entschärfungsmuster aufrufen.

  • Ein Trennschalter sollte alle Übergangszustände protokollieren. Dies ermöglicht den Operatoren, das Übergangsverhalten zu überwachen und die Zeitgeber zu optimieren, um längeres Verweilen im geöffneten Zustand oder häufiges Pendeln zwischen dem geöffneten und dem halb geöffneten Zustand zu verhindern.

  • Statt einen Zeitgeber für den Übergang vom geöffneten in den halb geöffneten Zustand zu verwenden, kann der Trennschalter auch in regelmäßigen Abständen den Standardpfad testen, um festzustellen, ob er wieder normal funktioniert.

  • Gehen Sie bei Vorgängen, die zu mehreren Shards führen, beim Einsatz von Trennschaltern sehr vorsichtig vor. Hier besteht die Gefahr, dass die Integrität auf Shardebene besteht, was zu zwei unerwünschten Szenarien führen kann:

    • Dem Übergang zu einem geöffneten Zustand, wenn nur ein Shard ausfällt.

    • Dem versehentlichen Übergang zu einem geschlossenen Zustand, wenn mindestens ein Shard normal ist.

Eine verbreitete Implementierung dieses Prinzips findet sich beim Zugriff auf Datenbanken oder Datendienste. Sobald eine Aktivität eines bestimmten Typs oder einer bestimmten Ebene einen Fehler aufweist, tritt der "Circuit-Breaker" in Aktion. Bei Daten wird der Fehler normalerweise dadurch ausgelöst, dass keine Verbindung mit einer Datenbank oder einem vorgeschalteten Datendienst hergestellt werden kann.

Wenn eine Datenbankressource nach 100 aufeinander folgenden Verbindungsversuchen nicht aufgerufen werden kann, ergibt es wenig Sinn, weitere Anforderungen an die Datenbank zu senden. Ein "Circuit-Breaker", der die geeigneten Aktionen auslöst, kann bei Erreichen dieses Schwellenwerts aktiviert werden.

Dies kann in einigen Fällen – insbesondere bei der Verbindung mit Datendiensten – zu einer Drosselung führen, weil ein Client die Anzahl der in einem bestimmten Zeitraum zulässigen Aufrufe überschreitet. Der "Circuit-Breaker" kann Verzögerungen zwischen den Aufrufen einbauen, bis die Verbindungen wieder erfolgreich hergestellt werden und die Toleranzwerte erfüllen.

In anderen Fällen ist der Datenspeicher möglicherweise nicht verfügbar. Wenn eine redundante Kopie der Daten verfügbar ist, kann das System einen Failover auf dieses Replikat ausführen. Wenn kein echtes Replikat verfügbar ist oder der Datenbankdienst in allen Datencentern eines Anbieters ausgefallen ist, muss ein sekundärer Lösungsansatz probiert werden. Dabei könnten Daten aus einer Datenversion beschafft werden, die über einen alternativen Datendienstanbieter angefordert werden. Diese alternative Quelle kann ein Cache, ein alternativer persistenter Datenspeichertyp beim aktuellen Cloudanbieter, ein separater Cloudanbieter oder ein lokales Datencenter sein. Wenn keine solche Alternative zur Verfügung steht, kann der Dienst auch einen eindeutigen Fehler zurückgeben, der dann vom Client entsprechend behandelt wird.

Beispiel für einen Trennschalter: Netflix

Die Onlinevideothek Netflix wird häufig als herausragendes Beispiel für eine resiliente Architektur genannt. Im Zusammenhang mit dem "Circuit-Breaker"-Muster von Netflix benennt das Team in seinem Netflix-Technologieblog mehrere Kriterien, die diesem Entwicklungsmuster zugrunde liegen. Dazu gehören:

  1. Eine Anforderung an den Remotedienst löst ein Timeout aus.

  2. Der Threadpool und die begrenzte Taskwarteschlange, die für die Interaktion mit einer Dienstabhängigkeit verwendet werden, haben eine Auslastung von 100 %.

  3. Die Clientbibliothek für die Interaktion mit einer Dienstabhängigkeit löst eine Ausnahme aus.

Alle diese Umstände tragen zur Gesamtfehlerrate bei. Wenn diese Fehlerrate die definierten Schwellenwerte überschreitet, wird der "Circuit-Breaker" ausgelöst und ein Fallbacksystem aktiviert, ohne eine Verbindung mit dem Remotedienst zu versuchen.

Im selben Blogeintrag führt das Netflix-Team aus, dass der "Circuit-Breaker" für jeden der Netflix-Dienste eine Fallbackregelung implementiert, die auf einer der folgenden drei Methoden basiert:

  1. Benutzerdefiniertes Fallback – eine Dienstclientbibliothek stellt eine aufrufbare Fallbackmethode bereit, oder auf einem API-Server (z. B. Cookie oder lokaler Cache) sind lokale Daten verfügbar, mit denen eine Fallbackantwort generiert wird.

  2. Fail-Silent (Ausfall ohne Benachrichtigung) – Eine Methode gibt einen NULL-Wert an den anfordernden Client zurück, was gut funktioniert, wenn die angeforderten Daten optional sind.

  3. Fail-Fast (schneller Abbruch) – Wenn Daten erforderlich (d. h. nicht optional) sind bzw. kein verlässliches Fallback verfügbar ist, wird eine 5xx-Antwort an den Client zurückgegeben. Dieser Ansatz basiert auf der Integrität der API-Server und ermöglicht eine schnelle Wiederherstellung, sobald die betroffenen Dienste wieder online sind. Das kann sich jedoch negativ auf das Client-UX-Design auswirken.

Zur Durchsetzung einer SLA muss eine Organisation festlegen, wie ihr Datendienst die folgenden Arten von Ausreißern behandelt: vertrauenswürdige Teilnehmer und Risikoteilnehmer.

Vertrauenswürdige Teilnehmer und weiße Listen

Vertrauenswürdige Teilnehmer sind Organisationen, mit denen die Organisation u. U. Sonderregelungen getroffen hat und deren Standard-SLA u. U. verhandelbar ist.

  • Drittparteien mit individuellen Vereinbarungen

    Einige Nutzer eines Diensts möchten vielleicht besondere Preiskonditionen oder Richtlinien aushandeln. In einigen Fällen kann ein hohes Aufkommen an Datenanforderungen einen Vorzugspreis rechtfertigen. In anderen Fällen könnte die Nachfrage nach einem bestimmten Datendienst den festgelegten Standardnutzungsrahmen sprengen. Diese Kunden sollten als vertrauenswürdige Teilnehmer gekennzeichnet werden, um zu vermeiden, dass sie versehentlich als Risikopartner eingestuft werden.

  • Weiße Listen

    Die normale Methode zur Kennzeichnung vertrauenswürdiger Teilnehmer ist die Erstellung einer weißen Liste. Eine weiße Liste enthält die vertrauenswürdigen Teilnehmer und wird vom Dienst herangezogen, um Geschäftsregeln zu ermitteln, die bei der Festlegung des Kundennutzungsrahmens angewendet werden. Weiße Listen funktionieren auf die Weise, dass ein IP-Adressbereich oder ein API-Schlüssel autorisiert wird.

    Beim Festlegen einer Nutzungsrichtlinie sollte eine Organisation angeben, ob weiße Listen unterstützt werden, wie sich ein Kunde für die weiße Liste qualifiziert, wie ein Kunde der weißen Liste hinzugefügt wird und unter welchen Umständen eine Kunde von der weißen Liste entfernt wird.

  • Behandlung von Risikoteilnehmern

    Wenn vertrauenswürdige Teilnehmer am einen Ende des Kundenspektrums stehen, bildet die Gruppe am anderen Ende das, was man als "Risikoteilnehmer" bezeichnen kann. Risikoteilnehmer stellen eines Belastung des Diensts dar, normalerweise durch den Versuch des "überhöhten Verbrauchs". In einigen Fällen ist schlechtes Verhalten einfach nur zufällig. In anderen Fällen wird es absichtlich – und in Ausnahmefällen – sogar böswillig herbeigeführt. Diese Teilnehmer werden als "riskant" eingestuft, und ihre Handlungen – ob absichtlich oder nicht – können die Verfügbarkeit eines oder mehrerer Dienste potenziell beeinträchtigen.

    Die Mehrbelastung aufgrund von Risikoteilnehmern kann dem Datendienstanbieter unnötige Kosten verursachen und den Zugriff der Kunden beeinträchtigen, die sich an die Nutzungsvereinbarungen halten und die in der SLA festgelegten, berechtigten Erwartungen erfüllt sehen möchten. Risikoteilnehmer sind deshalb in einer vorgeschriebenen, konsistenten Weise zu behandeln. Typische Maßnamen sind eine Zugriffsdrosselung und die Eintragung in eine schwarze Liste.

  • Einschränkung

    Organisationen sollten eine Strategie festlegen, wie sie mit Spitzenlasten der Datendienstconsumer umgehen. Der signifikante Anstieg des Datenverkehrs seitens eines Consumers kann eine unerwartete Mehrbelastung für den Datendienst bedeuten. Wenn solche Spitzen auftreten, kann die Organisation den Zugriff für diesen Consumer über einen bestimmten Zeitraum drosseln. In diesem Fall weist der Dienst alle Anforderungen des Consumers während eines bestimmten Zeitraums zurück, z. B. eine Minute, fünf Minuten oder zehn Minuten. Während dieses Zeitraums lösen die Anforderungen des betreffenden Consumers eine Fehlermeldung aus, die besagt, dass die Nutzung aufgrund übermäßigen Datenverkehrs eingeschränkt ist.

    Der Consumer, von dem die Anforderungen gesendet werden, kann sich darauf einstellen, indem er sein Verhalten ändert.

    Die Organisation sollte festlegen, ob die Zugriffsdrosselung implementiert werden soll, und dann entsprechende Geschäftsregeln definieren. Wenn die Organisation zu dem Schluss kommt, dass der Consumerzugriff gedrosselt werden kann, muss sie zusätzlich entscheiden, welche Verhaltensweisen eine Drosselung auslösen sollen.

  • Schwarze Listen

    Obwohl eine Drosselung auf das Verhalten von Risikoteilnehmern einwirken soll, führt dies nicht immer zum Erfolg. Sollte diese Maßnahme nicht den gewünschten Effekt haben, kann die Organisation den Consumer mit einer Sperre belegen. Im Unterschied zu einer weißen Liste kennzeichnet eine schwarze Liste alle Consumer, denen der Zugriff auf den Dienst in gewissem Rahmen verweigert wird. Der Dienst beantwortet die Anforderungen der auf die schwarze Liste gesetzten Teilnehmer in der vorgesehenen Weise, indem die Nutzung der Datendienstressourcen auf ein Minimum reduziert wird.

    Schwarze Listen wie weißen Listen basieren entweder auf einem API-Schlüssel oder einem IP-Adressbereich.

    Beim Festlegen einer Nutzungsrichtlinie sollte die Organisation angeben, welche Verhaltensweisen die Eintragung in die schwarze Liste rechtfertigen, wie der Eintrag angefochten werden kann und wie ein Consumer wieder von der schwarzen Liste entfernt wird.

Menschen machen Fehler. Ob ein Entwickler eine Codeänderung vornimmt, die unerwartete Folgen hat, ein Datenbankadministrator versehentlich eine Tabelle in einer Datenbank löscht oder ein Bediener vergisst, eine Änderung zu dokumentieren – es gibt viele Gründe, warum menschliches Verhalten die Resilienz eines Diensts beeinträchtigen kann.

Um den "menschlichen Faktor" einzudämmen, wäre die zahlenmäßige Einschränkung der Prozessbeteiligten die logische Konsequenz. Durch die Einführung der Automatisierung reduziert sich die Gefahr spontan auftretender, unbeabsichtigter Engpässe, die durch unerwartetes Verhalten auftreten und eine Gefährdung des Diensts bedeuten.

Es gibt ein Mem in der DevOps-Community, dessen Cartoonfigur sagt "Automate All the Things". In der Cloud werden die meisten Dienste über eine API verfügbar gemacht. Von Entwicklungstools über eine virtualisierte Infrastruktur und Plattformdienste bis zu SaaS (Software-as-a-Service)-Lösungen kann man alles in einem Skript programmieren.

Die Skripterstellung wird ausdrücklich empfohlen. Skripte sorgen für eine konsistente Bereitstellung und Verwaltung, sie sind vorhersagbar und zahlen sich als Investition schnell aus.

Automatisierte Bereitstellung

Die Automatisierung kommt vor allem bei der Erstellung und Bereitstellung von Lösungen zum Einsatz. Sie kann einem Entwicklerteam das Testen und Bereitstellen von Lösungen in mehreren Umgebungen erleichtern. Mithilfe automatisierter Buildvorgänge lassen sich alle Phasen wie Entwicklung, Tests, Staging, Betatests und Übernahme in das produktive System schnell und konsistent durchlaufen. Die konsistente Bereitstellung in mehreren Umgebungen trägt dazu bei, dass die Version im produktiven System als repräsentative getestete Lösung angesehen werden kann.

Betrachten Sie die folgenden Elemente als "Code": Skripts, Konfigurationsdateien und mit der Bereitstellung zusammenhängende Metadaten. Code schließt auch die Verwaltung dieser Artefakte in der Quellcodekontrolle ein, um dies zu erreichen:

  • Dokumentieren von Änderungen

  • Zulassen von Versionierung

  • Bereitstellen von rollenbasierter Zugriffssteuerung

  • Sicherstellen, dass Inhalte gesichert werden

  • Bereitstellen einer einzelnen Wahrheitsinstanz (SSOT, Single Source of Truth)

Einrichten und Automatisieren einer Testumgebung

Die Testphase ist ein weiterer Bereich, der automatisiert werden kann. Wie bereits die automatisierte Bereitstellung ist die Einrichtung einer automatisierten Testumgebung ein wertvolles Instrument, um die Resilienz eines Systems heute und in der Zukunft zu gewährleisten. Mit zunehmendem Codeumfang und vermehrter Nutzung des Diensts muss sichergestellt sein, dass alle erforderlichen Tests auf Funktions- und Skalierungsebene ausgeführt werden.

Automatisieren der Archivierung und Bereinigung von Daten

Einer der Bereiche, der wenig Beachtung findet, ist die Archivierung und Bereinigung von Daten. Die Datenbestände wachsen unaufhörlich weiter, und zwar in einem Maße und mit einer Diversifizierung, die bisher ohne Beispiel ist. Abhängig von der Datenbanktechnologie und den gesendeten Abfragen können überflüssige Daten die Antwortzeit des Systems verlängern und unnötige Kosten verursachen. Bei Resilienzplänen, die ein oder mehrere Datenspeicherreplikate vorsehen, kann das Entfernen aller überflüssigen Daten Verwaltungsaufgaben wie das Sichern und Wiederherstellen von Daten beschleunigen.

Erarbeiten Sie die Anforderungen für Ihre Lösung, indem Sie die Daten identifizieren, die für die Kernfunktionalität erforderlich sind, die zu Compliancezwecken benötigt werden, aber archiviert werden können, oder die überflüssig sind und gelöscht werden können.

Verwenden Sie die APIs der betreffenden Produkte und Dienste, um die Implementierung dieser Anforderungen zu automatisieren.

Beim Aufbau einer resilienten Architektur kommt es darauf an, sich die Bedeutung von Fehlerdomänen und Upgradedomänen zu vergegenwärtigen.

Fehlerdomänen

Fehlerdomänen schränken die Bereitstellung von Diensten aufgrund bekannter Hardwarebeschränkungen ein und verringern die Wahrscheinlichkeit eines Ausfalls für eine Computergruppe. Eine Fehlerdomäne ist als Gruppe von Computern definiert, die gleichzeitig ausfallen können. Diese zeichnen sich in der Regel durch physische Eigenschaften aus (sie befinden sich alle in einem Rack oder sind an dieselbe Stromversorgung angeschlossen).

Upgradedomänen

Upgradedomänen sind vergleichbar mit Fehlerdomänen. Upgradedomänen definieren ein reales Set von Diensten, die vom System gleichzeitig aktualisiert werden. Der beim Cloudanbieter implementierte Lastenausgleich muss die Upgradedomänen im Blick behalten, um sicherzustellen, dass die Last des Gesamtsystems bei der Aktualisierung einer bestimmten Domäne gleich verteilt ist und die Dienste verfügbar bleiben.

Upgrades können in diesem Rahmen erfolgen:

  • Auf der Hypervisorebene ("HostOS-Upgrade").

  • Auf der Betriebssystemebene ("GastOS-Upgrade").

  • Als Ergebnis der Bereitstellung eines Anwendungs- oder Dienstupgrades in der Umgebung.

Abhängig vom Cloudanbieter und den genutzten Plattformdiensten können Fehlerdomänen und Upgradedomänen automatisch bereitgestellt werden, als Opt-In-Lösung über APIs in den Dienst eingebunden werden oder auf eine Erstanbieter- oder Drittanbieterlösung angewiesen sein.

Resilienz während des Ausfalls einer Fehlerdomäne während eines Upgrades

Zwar unterscheiden sich Fehlerdomänen und Upgradedomänen, es gibt jedoch ein Szenario, bei dem eine Schnittmenge besteht. Bei diesem Szenario wird ein virtueller Computer durch einen Hardwareausfall offline gesetzt, während zur gleichen Zeit auf einer anderen VM-Instanz ein Upgrade erfolgt. In diesem Fall sind zwei VMs offline. Wenn eine Dienstbereitstellung nur zwei virtuelle Computer umfasst, ist der Dienst in diesem Fall offline. Berücksichtigen Sie diese Möglichkeit, wenn Sie die Anzahl der Instanzen bewerten, die Sie zum Erzielen der gewünschten SLA benötigen.

Cloud-Plattformen bieten häufig die Möglichkeit, ein Affinitätsniveau für eine Gruppe von Ressourcen festzulegen. Wir bezeichnen diese Ressourcen als eine "Affinitätsgruppe" oder eine "Affinitätsmenge". Dies unterstützt die zugrundeliegende Plattform bei der gemeinsamen Platzierung aufeinander bezogener Ressourcen und der Zuordnung von Instanzen in Fehler- und Upgradedomänen.

Lokale Lösungen setzen häufig auf Redundanz, um Verfügbarkeit und Skalierbarkeit zu gewährleisten. Aus Sicht der Verfügbarkeit konnten redundante Datencenter die Wahrscheinlichkeit der Geschäftskontinuität bei Infrastrukturausfällen erhöhen, die in einem bestimmten Datencenter oder einem Teilbereich davon auftreten.

Bei Anwendungen mit geografisch verteilten Consumern werden die Benutzer durch das Datenverkehrsmanagement und redundante Implementierungen an lokale Ressourcen umgeleitet, häufig mit geringerer Latenz.

noteHinweis
Die Resilienz von Daten, die die Redundanz mit einschließt, wird in diesem Abschnitt unter "Entwickeln eines Ansatzes für die Datenresilienz" als separates Thema behandelt.

Redundanz in der Cloud

Lokal wurde die Redundanz in der Vergangenheit durch doppelt vorhandene Hardware, Software und Netzwerke erzielt. In einigen Fällen wird sie in einem Cluster an einem einzigen Standort oder verteilt über mehrere Datencenter implementiert.

Bei der Entwicklung einer Cloudstrategie muss der Bedarf einer redundanten Lösung für drei Vektoren rationalisiert werden. Diese Vektoren umfassen den bereitgestellten Code in der Umgebung des Cloudanbieters, die Redundanz der Anbieter selbst und die Redundanz zwischen der Cloud und lokalen Implementierungen.

Redundante Bereitstellungen

Sobald sich eine Organisation für einen Cloudanbieter entschieden hat, muss sie eine Redundanzstrategie für die Bereitstellung in der Anbieterumgebung entwickeln.

Bei einer PaaS (Platform as a Service)-Lösung übernimmt diese Aufgabe zu einem großen Teil die zugrunde liegende Plattform. Bei einem IaaS (Infrastructure as a Service)-Modell trifft dies eher nicht zu.

  • Bereitstellen von "n" Rollen in einem Datencenter

    Bei der einfachsten Form der Redundanz wird die Lösung auf mehreren Instanzen innerhalb eines einzelnen Cloudanbieters bereitgestellt. Die Bereitstellung auf mehreren Instanzen kann die Downtime beschränken, die bei der Bereitstellung nur eines Knotens zu erwarten wäre.

    In vielen PaaS-Umgebungen wird der Zustand des virtuellen Computers, auf dem der Code gehostet wird, überwacht, und als instabil identifizierte virtuelle Computer können automatisch durch einen stabilen Knoten ersetzt werden.

  • Bereitstellen in mehreren Datencentern

    Während die Bereitstellung mehrerer Knoten in einem einzelnen Datencenter Vorteile bringt, muss berücksichtigt werden, dass es Situationen geben kann, in denen das gesamte Datencenter ausfällt. Auch wenn es nicht häufig vorkommt, können Naturkatastrophen, Kriege usw. dazu führen, dass der Dienst an einem bestimmten geografischen Standort nicht mehr verfügbar ist.

    Um die SLA zu erfüllen, kann es von Vorteil sein, die Lösung in mehreren Datencentern des ausgewählten Cloudanbieters bereitzustellen. Die folgenden Vorgehensweisen stehen zur Verfügung.

    1. Vollständig redundante Bereitstellungen in mehreren Datencentern

      Die erste Option ist eine vollständige redundante Lösung in mehreren Datencentern, die zusammen mit einem Datenverkehrsmanagement-Anbieter implementiert wird. Eine wichtige Überlegung bei diesem Redundanztyp besteht darin, wie er sich auf die Serverkosten auswirkt, die sich für jede weitere Datencenterbereitstellung um 100 % erhöhen.

    2. Partielle Failoverbereitstellung in sekundären Datencentern

      Ein anderer Ansatz ist eine partielle Bereitstellung in einem sekundären Datencenter kleineren Umfangs. Während die Standardkonfiguration beispielsweise aus 12 Serverinstanzen besteht, könnte das sekundäre Datencenter sechs Serverinstanzen umfassen.

      Nach einem Vorfall, von dem ausschließlich das primäre Datencenter betroffen war, würde dieser Ansatz in Kombination mit dem geeigneten Datenverkehrsmanagement Geschäftskontinuität bei einem beeinträchtigten Dienst gewährleisten.

      Da es sehr selten vorkommt, dass ein Datencenter vollständig offline geschaltet wird, wird dies häufig als kostengünstiger Ansatz im Serverkontext angesehen – insbesondere, wenn eine Plattform der Organisation die Möglichkeit bietet, problemlos neue Instanzen im zweiten Datencenter zu nutzen.

    3. Über mehrere Datencenter verteilte Bereitstellungen mit Sicherungsknoten

      In bestimmten Funktionsbereichen, besonders auf dem vertikalen Markt für Finanzdienstleistungen, müssen erhebliche Datenmengen innerhalb eines kurzen, unbeweglichen Zeitfensters verarbeitet werden. Unter diesen Umständen wird in kürzeren Bursts gearbeitet, und die Bereitstellung der Ergebnisse innerhalb dieses Zeitfensters rechtfertigt die Kosten für Redundanz.

      In diesen Fällen wird Code in mehreren Datencentern bereitgestellt. Die Arbeit wird geteilt und zur Verarbeitung auf die Knoten verteilt. Falls ein Datencenter einmal nicht verfügbar sein sollte, wird die für diesen Knoten vorgesehene Arbeit auf den Sicherungsknoten übertragen, der die Verarbeitung dann übernimmt.

    4. Mehrere Datencenterbereitstellungen mit einer an die geografische Lage angepassten Datencentergröße

      Bei diesem Ansatz werden redundante Bereitstellungen genutzt, die auf mehrere Datencenter verteilt sind. Die Größe der Datencenter ist jedoch an die Größe einer georelevanten Zielgruppe angepasst.

Anbieterredundanz

Während Datencenter-zentrische Redundanz positiv zu beurteilen ist, arbeiten SLAs auf "Serviceebene" gegen die Datencenterebene. Viele kommerzielle Dienste stellen heute neue Versionen in einem "Segment" der Produktionsumgebung bereit, um den Code in der Produktion zu überprüfen. Es besteht jedoch die Möglichkeit, dass auf die von einem Anbieter bereitgestellten Dienste in mehreren oder sogar allen Datencentern nicht mehr zugegriffen werden kann.

Im Hinblick auf die SLAs für eine Lösung ist es u. U. von Vorteil, zusätzlich Anbieterredundanz zu integrieren. Dazu müssen Cloudprodukte oder Clouddienste identifiziert werden, die über mehrere Cloudplattformen hinweg eingesetzt werden. Beispielsweise kann Microsoft SQL Server von den meisten Anbietern auf einem virtuellen Computer in einer Infrastruktur als Serviceangebot bereitgestellt werden.

Bei Diensten, die in der Cloud bereitgestellt werden, gestaltet sich die Situation schwieriger, da selbst für Kerndienste wie Server-, Speicher-, Warteschlangendienste usw. keine Standardschnittstellen verfügbar sind. Anbieterredundanz für diese Dienste lässt sich häufig nur durch eine Abstraktionsebene erzielen. Eine Abstraktionsebene mag zwar genügend Funktionalität für eine Lösung bieten, entwickelt sich jedoch nicht so schnell weiter wie die zugrunde liegenden Dienste und kann in einer Organisation die ungehinderte Einführung neuer Anbieterfunktionen erschweren.

Redundante Anbieterdienste können auf mehreren Ebenen implementiert werden – auf Ebene einer vollständigen Anwendung, einer Funktionseinheit oder eines Aspekts einer Funktionseinheit. Beurteilen Sie auf der entsprechenden Ebene, ob Server-, Daten- und Plattformdienste erforderlich sind, in welchen Bereichen wirklich Redundanz benötigt wird und auf welche Bereiche geeignete Ansätze angewendet werden können, um Leistungseinbußen im Rahmen zu halten.

Lokale Redundanz

Die Abhängigkeit von einem Cloudanbieter kann wirtschaftlich sinnvoll sein, allerdings gibt es auch bestimmte unternehmerische Aspekte, die aus Gründen der Compliance und/oder Geschäftskontinuität lokale Redundanz erfordern.

Im Hinblick auf die SLAs für eine Lösung ist es u. U. von Vorteil, zusätzlich lokale Redundanz zu integrieren. Dazu müssen private, in der Cloud bereitstellbare Produkte oder Clouddienste identifiziert werden, die über mehrere Cloudtypen hinweg eingesetzt werden. Genauso wie bei der Anbieterredundanz ist Microsoft SQL Server auch hier ein gutes Beispiel für ein Produkt, das lokal oder im Rahmen eines IaaS-Angebots bereitgestellt werden kann.

Bei Diensten, die in der Cloud bereitgestellt werden, ist dies problematischer, weil lokale Äquivalente mit gleichwertigen Schnittstellen und Fähigkeiten häufig fehlen.

Wenn redundante Anbieterdienste lokal benötigt werden, können sie auf mehreren Ebenen implementiert werden – auf Ebene einer vollständigen Anwendung, einer Funktionseinheit oder eines Aspekts einer Funktionseinheit. Beurteilen Sie auf der entsprechenden Ebene, ob Server-, Daten- und Plattformdienste erforderlich sind, in welchen Bereichen wirklich Redundanz benötigt wird und auf welche Bereiche geeignete Ansätze angewendet werden können, um Leistungseinbußen im Rahmen zu halten.

Methoden zur Konfiguration von Redundanz

Wenn es darum geht, die Methoden zur Konfiguration von Redundanz zu ermitteln, müssen auch Aspekte berücksichtigt werden, die bereits vor der Cloud gültig waren. Abhängig von den in der Lösung verwendeten Diensttypen werden einige Aspekte u. U. automatisch von der zugrunde liegenden Plattform behandelt. In anderen Fällen wird diese Aufgabe von Technologien wie Windows Fabric übernommen.

  1. Aktiv/Aktiv: Der Datenverkehr, der für einen ausgefallenen Knoten vorgesehen war, wird entweder an einen vorhandenen Knoten übergeben oder per Lastenausgleich auf die übrigen Knoten verteilt. Dies ist normalerweise nur möglich, wenn für die Knoten eine homogene Softwarekonfiguration verwendet wird.

  2. Aktiv/Passiv: Stellt eine vollständig redundante Instanz jedes Knotens bereit, die nur online geschaltet wird, wenn deren zugeordneter primärer Knoten ausfällt. In dieser Konfiguration wird normalerweise die meiste zusätzliche Hardware benötigt.

  3. N+1: Stellt einen einzelnen zusätzlichen Knoten bereit, der online geschaltet wird, um die Rolle des ausgefallenen Knotens zu übernehmen. Verfügt jeder primäre Knoten über eine heterogene Softwarekonfiguration, muss der zusätzliche Knoten grundsätzlich in der Lage sein, alle Rollen der primären Knoten anzunehmen, für die er zuständig ist. Dies gilt normalerweise für Cluster, auf denen mehrere Dienste gleichzeitig ausgeführt werden. Im Fall eines einzelnen Diensts findet eine Herabstufung zur Aktiv/Passiv-Konfiguration statt.

  4. N+M: Wenn ein einzelner Cluster zahlreiche Dienste verwaltet, bietet ein einzelner dedizierter Failoverknoten möglicherweise nicht genügend Redundanz. Unter diesen Umständen wird mehr als ein (M) Standbyserver bereitgestellt und verfügbar gemacht. Bei der Anzahl der Standbyservern muss zwischen Kosten und Grad der Zuverlässigkeit abgewogen werden.

  5. N-zu-1: Ermöglicht es dem Failoverstandbyknoten, vorübergehend zum aktiven Knoten zu werden, bis der ursprüngliche Knoten wiederhergestellt oder online geschaltet werden kann. Zu diesem Zeitpunkt muss für die Dienste oder Instanzen ein Fallback auf den ursprünglichen Knoten ausgeführt werden, um wieder hohe Verfügbarkeit zu gewährleisten.

  6. N-zu-N: "N-zu-N" ist eine Kombination aus "Aktiv/Aktiv" und "N+M" und verteilt die Dienste, Instanzen oder Verbindungen vom ausgefallenen Knoten auf die übrigen aktiven Knoten. Auf diese Weise kann zwar (wie bei "Aktiv/Aktiv") auf einen "Standbyknoten" verzichtet werden, gleichzeitig wird aber zusätzliche Kapazität auf allen aktiven Knoten erforderlich.

Unabhängig davon, ob Datenverkehr zur Aufrechterhaltung der Geschäftskontinuität immer nach geografischen Aspekten verteilt oder an verschiedene Datencenter geroutet wird, muss durch das Datenverkehrsmanagement sichergestellt werden, dass die an die Lösung gesendeten Anforderungen an die geeigneten Instanzen weitergeleitet werden.

Es ist zu beachten, dass durch die Abhängigkeit von einem Datenverkehrsmanagement-Dienst ein SPoF (Single Point of Failure = einzelne Fehlerquelle ) entsteht. Daher sollte die SLA des primären Datenverkehrsmanagement-Diensts der Anwendung sorgfältig überprüft und ermittelt werden, ob alternative Datenverkehrsmanagement-Funktionalität zugesichert wird.

Während die Webebene vieler hoch skalierbarer Cloudanwendungen sehr gut partitioniert ist, lässt die Skalierung der Datenebene in der Cloud zu wünschen übrig. Mittlerweile werden die unterschiedlichsten Endgeräte für den Cloudzugriff genutzt, während die Menge der generierten und abgefragten Daten eine nie dagewesene Dimension erreicht hat. Das Ziel, täglich 500.000 neue Benutzer zu unterstützen, wird mittlerweile als vertretbar angesehen.

Eine wirkungsvolle Partitionierungsstrategie ist für mehrere Bereiche von Bedeutung, z. B. für die Speicherung, Abfrage oder Pflege der Daten.

Aufteilung und Partitionierung

Da die unterschiedlichen Technologien Vor- und Nachteile aufweisen, werden häufig Technologien genutzt, die am besten für den jeweiligen Funktionsbereich geeignet sind.

Durch die Verwendung einer in Funktionseinheiten aufgeteilten Lösung können Sie die Datentechnologien wählen, die optimal für eine bestimmte Funktionseinheit geeignet sind. Beispielsweise können Inhalte eines einzelnen Benutzers auf einer Website im Tabellenspeicher abgelegt und Partitionen auf Benutzerebene verwendet werden, um die Antwortzeiten kurz zu halten. Die Tabellenzeilen können zur Bericht- und Analyseerstellung regelmäßig in einer relationalen Datenbank aggregiert werden.

Partitionierungsstrategien variieren häufig basierend auf den gewählten Technologien.

Beim Definieren Ihrer Strategie müssen Sie auch Ausreißer erkennen, die möglicherweise eine geänderte oder parallele Strategie erfordern. Wenn Sie beispielsweise die Website eines sozialen Netzwerks bereitstellen, kann ein normaler Benutzer vielleicht 500 Verbindungen haben, während ein Prominenter es auch auf 5.000.000 bringen kann.

Wenn die Website 100 Millionen Benutzer erwartet und Promis davon weniger als 50.000 ausmachen, würde die zugrundeliegende Partitionierungsstrategie für einen normalen Benutzer optimiert. Sie würden Promis anders verwalten. Während eine große Anzahl Benutzer in einer einzelnen Partition zusammengefasst würde, könnten Sie einem Promi ggf eine eigene Partition zuweisen.

Die "3 Vs"

Damit eine Organisation eine erfolgreiche Partitionierungsstrategie entwickeln kann, muss sie zunächst eine klare Vorstellung davon haben.

Die durch Gartner bekannt gewordenen "3 Vs" beleuchten Daten aus drei unterschiedlichen Perspektiven. Sobald Sie erkannt haben, in welcher Beziehung die 3 Vs zu Ihren Daten stehen, können Sie eine fundierte Entscheidung bei der Wahl der richtigen Partitionierungsstrategie treffen.

  • Menge

    Das Volumen bezieht sich auf die Größe der Daten. Das Volumen nimmt starken Einfluss auf die Partitionierungsstrategie. Volumenbeschränkungen einer bestimmten Datentechnologie können eine Partitionierung aufgrund von Größeneinschränkungen, der Abfrageleistung bei großen Datenmengen usw. erforderlich machen.

  • Velozität (Geschwindigkeit)

    Die Velozität bezieht sich auf die Geschwindigkeit, mit der die Datenmenge zunimmt. Für einen langsam wachsenden Datenspeicher werden Sie eine andere Partitionierungsstrategie entwickeln als für einen Speicher, auf den täglich 500.000 neue Benutzer zugreifen.

  • Vielfalt

    Die Vielfalt bezieht sich auf die verschiedenen, für die Funktionseinheit relevanten Datentypen. Es ist wichtig, die Bedeutung der unterschiedlichen Datentypen zu kennen, ob relationale Daten, Schlüssel-Wert-Paare, Profile sozialer Netzwerke, Bilder, Audiodateien, Videos usw. Mit dem richtigen Wissen wählen Sie nicht nur die geeignete Datentechnologie, sondern treffen auf bei der Partitionierungsstrategie die richtige Entscheidung.

Horizontale Partitionierung

Die wahrscheinlich bekannteste Form der Datenpartitionierung ist die horizontale Partitionierung. Bei der horizontalen Partitionierung wird anhand verschiedener Kriterien entschieden, ob ein Datenspeicher in mehrere Shards partitioniert werden soll. Jedes Shard umfasst das gesamte Schema sowie die Kriterien, die die Aufteilung der Daten in die entsprechenden Shards bewirken.

Die Partitionierung kann je nach Datentyp und -nutzung auf verschiedene Weisen erfolgen. Beispielsweise könnte eine Organisation Daten anhand des Nachnamens von Kunden partitionieren. In einem anderen Fall könnte die Partitionierung zeitbedingt sein, und nach einem Zeitintervall, wie Stunde, Tag, Woche oder Monat, erfolgen.

Abbildung 5: Beispiel für die horizontale Partitionierung nach dem Nachnamen

Vertikale Partitionierung

Eine andere Methode ist die vertikale Partitionierung. Sie optimiert die Platzierung von Daten in unterschiedlichen Speichern und ist häufig an der Datenvielfalt orientiert. Abbildung 5 zeigt ein Beispiel, in dem Metadaten zu einem Kunden in einem Speicher und Miniaturansichten und Fotos in getrennten Speichern abgelegt werden.

Durch die vertikale Partitionierung kann die Speicherung und Bereitstellung von Daten optimiert werden. Wird das Kundenfoto in Abbildung 5 beispielsweise selten angezeigt, kann die Rückgabe von 3 MB pro Datensatz bei einem PAYG (Pay As You Go)-Modell unnötige Kosten verursachen.

Abbildung 6: Beispiel für die vertikale Partitionierung.

Hybridpartitionierung

Häufig ist es angebracht, eine hybride Partitionierungsstrategie zu entwickeln. Dieser Ansatz vereint die Vorteile beider Ansätze in einer Lösung.

Abbildung 6 enthält ein Beispiel. Die bereits beschriebene vertikale Partitionierung wird erweitert und nutzt gleichzeitig die horizontal partitionierten Kundenmetadaten.

Abbildung 7: Beispiel für die horizontale Partitionierung.

Das Netzwerk ist das Herzstück des Cloudcomputings. Das Netzwerk ist unverzichtbar, da es das Fabric bzw. den Backbone darstellt, über das bzw. den Geräte eine Verbindung mit Diensten und Dienste eine Verbindung mit anderen Diensten herstellen. Bei jeder FailSafe-Anwendung müssen drei Netzwerkgrenzen beachtet werden.

Die Netzwerkgrenzen werden nachfolgend am Beispiel von Azure ausführlich erläutert:

  1. Rollengrenzen werden in der Regel als Ebenen bezeichnet. Typische Beispiele sind eine Webebene oder eine Geschäftslogikebene. Bei Azure wurden Rollen z. B. formal als Teil des Coredesigns eingeführt, um eine Infrastruktur zur Unterstützung der Multi-Tier-Eigenschaft moderner verteilter Anwendungen bereitzustellen. Azure gewährleistet, dass zum selben Dienst gehörige Rolleninstanzen im Bereich einer einzelnen Netzwerkumgebung gehostet und von einem einzelnen Fabric Controller verwaltet werden.

  2. Dienstgrenzen stellen Abhängigkeiten von Funktionen dar, die von anderen Diensten bereitgestellt werden. Typische Beispiele sind eine SQL-Umgebung für den Zugriff auf relationale Datenbanken sowie ein Service Bus zur Unterstützung von pub/sub-Messaging. Beispielsweise werden innerhalb von Azure Dienstgrenzen mithilfe des Netzwerks durchgesetzt: Es wird keine Garantie erteilt, dass eine Dienstabhängigkeit Teil der gleichen Netzwerk- oder der Fabric Controller-Umgebung ist. Dies kann zwar passieren, beim Entwurf einer zuverlässigen Anwendung wird jedoch davon ausgegangen, dass sich alle Dienstabhängigkeiten in einem anderen Netzwerk befinden, das von einem anderen Fabric Controller verwaltet wird.


    Abbildung 8

  3. Endpunktgrenzen befinden sich außerhalb der Cloud. Sie umfassen alle Consumerendpunkte. Hierbei handelt es sich normalerweise um Geräte, die eine Verbindung mit der Cloud herstellen, um Dienste zu nutzen. In dieser Entwurfsphase muss mit großer Sorgfalt vorgegangen werden, weil das Netzwerk aufgrund schwankender Leistung einen Unsicherheitsfaktor darstellt. Rollen- und Dienstgrenzen liegen innerhalb der Cloudgrenzen, wodurch ein gewisses Maß an Zuverlässigkeit und Bandbreite gewährleistet ist. Da externe Abhängigkeiten nicht sicher eingeschätzt werden können, ist die Fähigkeit des Geräts, Dienste (d. h. Daten und Interaktionen) zu nutzen, von besonderer Bedeutung.

    Das Netzwerk verursacht naturgemäß Latenzen, während Informationen von einem Punkt im Netzwerk zu einem anderen übertragen werden. Um sowohl eine optimale Benutzererfahrung zu gewährleisten als auch abhängige Dienste oder Rollen optimal zu unterstützen, sollten Anwendungsarchitektur und -entwurf Möglichkeiten bieten, Latenzen in einem vertretbaren Rahmen zu reduzieren und unvermeidbare Latenzen explizit zu verwalten. Häufig wird die Latenz verringert, indem Dienstaufrufe über das Netzwerk vermieden werden. Der lokale Zugriff auf Daten und Dienste ist ein wichtiger Faktor bei der Verringerung von Latenzen und führt gleichzeitig zu besseren Reaktionszeiten. Die Verwendung lokaler Daten und Dienste erhöht zusätzlich die Ausfallsicherheit. Solange die Benutzer- oder Anwendungsanforderungen unter Verwendung der lokalen Umgebung verarbeitet werden können, ist es nicht notwendig, mit anderen Rollen oder Diensten zu interagieren. Gleichzeitig werden Fehler vermieden, die entstehen, wenn abhängige Komponenten nicht verfügbar sind.

Caching

Als Caching wird ein Verfahren bezeichnet, mit dem die Datenzugriffsgeschwindigkeit verbessert werden kann, wenn Daten nicht lokal gespeichert werden können. Kaum ein moderner, durchsatzstarker Clouddienst kommt heute ohne Caching aus. Laut Wikipedia ermöglicht ein Cache den lokalen Zugriff auf Daten, die wiederholt von Anwendungen angefordert werden. Das Caching basiert auf zwei Grundideen:

  • Verwendungsmuster für die von Benutzern und abhängigen Anwendungen genutzten Daten sind überwiegend schreibgeschützt. In bestimmten Szenarien, z. B. E-Commerce-Websites, liegt der Prozentsatz des schreibgeschützten Zugriffs (auch als Browsing bezeichnet) bei bis zu 95 % aller Benutzerinteraktionen mit der Website.

  • Das Informationsmodell der Anwendung stellt eine zusätzliche Ebene semantischer Informationen bereit, die die Identifikation stabiler Einzeldaten unterstützt, die optimal für das Zwischenspeichern geeignet sind.

Gerätecaching

Obwohl das Gerätecaching keine zentrale Bedeutung in der FailSafe-Initiative einnimmt, bietet es eine der effizientesten Möglichkeiten, die Benutzerfreundlichkeit und Stabilität von Geräten und Dienstanwendungen zu verbessern. Es gibt zahlreiche Möglichkeiten, Cachingdienste auf der Geräte- oder Clientebene bereitzustellen, von der HTML5-Spezifikation mit nativen, in alle Standardbrowser implementierten Cachingfähigkeiten, bis hin zu lokalen Datenbankinstanzen wie SQL Server Compact Edition oder ähnlichen Lösungen.

Verteiltes Caching

Das verteilte Caching zeichnet sich durch leistungsstarke Funktionen aus. Diese Technologie verfolgt jedoch nicht den Zweck, eine relationale Datenbank oder einen anderen persistenten Speicher zu ersetzen, sondern die Reaktionsfähigkeit verteilter Anwendungen zu steigern, die naturgemäß netzwerkzentriert und anfällig für Netzwerklatenz sind. Ein Nebeneffekt des Cachings ist der verminderte Datenverkehr zum persistenten Datenspeicher, wodurch die Interaktionen mit dem Datendienst auf ein Minimum reduziert werden.

  • Für das Caching optimierte Informationsmodelle

    noteHinweis
    Dieser Abschnitt beruht zu einem großen Teil auf den hervorragenden Ausführungen von Pat Helland, die sich mit Daten in dienstorientierten Architekturen beschäftigen. Lesen Sie den vollständigen Artikel im Microsoft Developer Network.

    Zwischengespeicherte Daten sind von Natur aus veraltet, da sie nicht immer unbedingt aktuell sein müssen. Ein gutes Beispiel aus einem ganz anderen Kontext stellt ein Produktkatalog dar, der an Tausende von Haushalten geschickt wird. Die Daten, die zur Erstellung des Produktkatalogs verwendet wurden, waren zum Zeitpunkt der Drucklegung auf dem neuesten Stand. Sobald die Druckmaschinen angelaufen sind, verlieren die Daten aufgrund der während der Katalogproduktion verstrichenen Zeit an Aktualität. Da die zwischengespeicherten Daten veraltet sind, haben die Datenattribute beim Cachingentwurf eine zentrale Bedeutung im Hinblick auf Stabilität und Singularität:

    • Stabilität: Daten, die raum- und zeitübergreifend eindeutig interpretiert werden können. Häufig handelt es sich um Datenwerte, die sich nicht ändern. Beispielsweise haben die meisten Unternehmen kein Interesse daran, Kunden-IDs oder SKU-Nummern zu recyceln. Eine andere Möglichkeit, Daten Stabilität zu verleihen, ist das Festlegen eines Ablaufdatums. Der bereits erwähnte gedruckte Produktkatalog ist ein gutes Beispiel. Normalerweise werden im Einzelhandel Bestellungen aus zwei Erscheinungsperioden des Katalogs entgegen genommen. Wird ein Katalog viermal jährlich veröffentlicht, sind die darin enthaltenen Produktdaten sechs Monate gültig und können für die Informationsverarbeitung, z. B. zum Aufgeben und Ausführen von Bestellungen, verwendet werden.

      Stabile Daten werden häufig als Master- oder Verweisdaten bezeichnet. In der FailSafe-Initiative wird der Begriff "Verweisdaten" verwendet, da er semantisch umfassender als "Masterdaten" ist. In vielen Unternehmen hat der Begriff "Masterdaten" eine sehr spezifische Bedeutung und ist enger gefasst als "Verweisdaten".

    • Singularität: Daten, die durch die Zuordnung zu eindeutig identifizierbaren Instanzen ohne oder mit wenig gleichzeitigen Updates isoliert werden können. Betrachten Sie als Beispiel einen Warenkorb. Obwohl der Warenkorb offensichtlich aktualisiert wird, treten Updates relativ selten auf und können vollständig von der Speicherung und Verarbeitung isoliert werden.

      Die oben beschriebenen isolierbaren Daten werden als Aktivitäts- oder Sitzungsdaten bezeichnet.

      In Anbetracht dieser beiden Attribute ergibt sich folgendes Schema:


      Abbildung 9

  • Informationsmodelle

    Viele Anwendungsarchitekten oder -entwickler denken bei der Datenmodellierung an Objekt- oder Entitätsmodelle. Obwohl Objekt- oder Entitätsmodelle der Kunst und Wissenschaft der Datenmodellierung zuzuordnen sind, ist ein Informationsmodell für eine FailSafe-Anwendung weitaus vielschichtiger. 

    Bei einer ersten Betrachtung der für moderne verteilte Umgebungen erforderlichen Denkansätze lag der Schwerpunkt auf Stabilität und Singularität. In einem weiteren wichtigen Prozess muss verstanden werden, wie die Daten bei der Interaktion mit dem Benutzer/Gerät oder im Rahmen der zu implementierenden Geschäftsprozesse genutzt werden. Die objektorientierte Modellerstellung ist in vielen Bereichen dem Informationsdesign zuzuordnen:

    • Datenkapselung: Informationen zu verbergen oder den Zugriff auf Informationen zu blockieren, die für den Benutzer oder den Geschäftsprozess nicht von Bedeutung sind, ist eine der besten Methoden zur Vermeidung von Konflikten mit Ressourcen- oder freigegebenen Daten, die in einer relationalen Datenbank gespeichert und verwaltet werden.

      Der Unterschied zwischen einem typischen ERP-System und der Handhabung der meisten Bestandsszenarien bei Amazon.com ist ein hervorragendes Beispiel dafür, wie sich Parallelität durch die effiziente Kapselung von Informationen wirkungsvoll verbessern lässt. In einer typischen ERP-Systemimplementierung ist die Bestandstabelle (ausgehend von einer relationalen Datenbankimplementierung) eine der meistfrequentierten Tabellen. Die ERP-Anwendung versucht normalerweise, die Bestandsdaten zu sperren, bis der Benutzer die Transaktion abgeschlossen hat, und liefert der Anwendung die genauen Bestandszahlen, die zu Beginn der Geschäftstransaktion gültig waren. Einige Systeme, darunter SAP, verzichten auf Datenbanksperren, rufen aber eine Anwendungssperre im Warteschlangensystem ab. Ein großer Anteil an Techniken auf der Datenbankebene wurde entwickelt, um diese Überlastung zu beherrschen: optimistische Parallelitätssteuerung, "Dirty Reads" usw. Keine Arbeitet wirklich sauber, und alle haben Nebenwirkungen. In bestimmten Situationen können Sie die Tabelle auch sperren, dies wird jedoch relativ selten der Fall sein.

      Amazon.com hat das Problem auf viel einfachere Weise gelöst: Benutzern wurde ein optionales SLO (Service Level Objective) angeboten, das akzeptiert oder abgelehnt werden konnte. Das SLO wurde meist in der Form "Normalerweise in N Stunden verfügbar" präsentiert, ohne dass der Benutzer die tatsächliche Anzahl verfügbarer Bücher oder Artikel einsehen konnte. Trotzdem erhielt er Informationen zur Verfügbarkeit. Hier waren weder Datenbanksperren noch eine Verbindung mit der Datenbank erforderlich. War das System nicht in der Lage, das SLO zu erfüllen, erhielt der Käufer in der Regel ein Entschuldigungsschreiben (per E-Mail) sowie ein aktualisiertes SLO.

    • Austauschbare Ressourcen: Im Wörterbuch ist "austauschbar" wie folgt definiert: Fungibilität (insbesondere von Waren) liegt vor, wenn diese von solcher Art oder Beschaffenheit sind, dass sie ganz oder teilweise durch ein Äquivalent ausgetauscht oder ersetzt werden können. Der Hauptansatz zur weiteren Eindämmung der Konflikte beim Zugriff auf freigegebene Daten besteht darin, dem Benutzer durch die Datenmodellierung eine Möglichkeit zu bieten, mit einer austauschbaren (fungiblen) Dateninstanz anstatt mit einer spezifischen Instanz zu interagieren. Die Buchung eines Hotelzimmers ist ein gutes Beispiel. Bei der Buchung sind zahlreiche Angaben, wie Bettenanzahl, Meerblick, Raucher-/Nichtraucherzimmer usw., möglich, ohne dass jemals Zimmer "123" genannt werden muss. Bei dieser Art der Modellierung ist es uneingeschränkt möglich, Informationen zu Pools austauschbarer Daten zwischenzuspeichern, den Geschäftsprozess unter Verwendung des Pools auszuführen und erst nach Abschluss des Checkins ein Zimmer aus diesem Pool zu vergeben. Hybridmodelle, bei denen ein bestimmtes Zimmer zu Beginn des Checkins aus dem Pool entnommen werden, sind ebenfalls denkbar.

  • Cacheverwaltung

    Einer der wichtigsten Grundsätze einer erfolgreichen Cachingstrategie basiert darauf, dass die richtigen Informationen zum richtigen Zeitpunkt zwischengespeichert werden müssen. Für das Laden des Caches gibt es eine Vielzahl von Techniken: eine gute Übersicht ist in "Caches in der verteilten Umgebung" enthalten. In den folgenden Abschnitten werden zusätzliche Überlegungen zum FailSafe-Anwendungsentwurf angestellt, der auf verteiltem Caching beruht.

    • Verweisdaten: Wenn in der Hostumgebung (Fabric Controller oder Datencenter) ein Notfall auftritt, wird die Anwendung in eine andere Umgebung umgelagert. Wenn bereits eine Anwendungsinstanz aktiv ist ("Aktiv/Aktiv"), kann es gut sein, dass der Cache bereits zahlreiche relevante Informationen (insbesondere Verweisdaten) enthält. Falls eine neue Anwendungsinstanz hochgefahren wird, sind in den Cacheknoten keine Informationen enthalten. Die Anwendung sollte so konzipiert werden, dass die gewünschten Daten nach einem Cachefehlversuch automatisch geladen werden. Bei einer neuen Instanz können Sie eine Startroutine verwenden, durch die die Verweisdaten in einem Massenladevorgang in den Cache geladen werden. Am besten wäre eine Kombination beider Verfahren, da Benutzer aktiv werden können, sobald die Anwendung Ergebnisse von der Cloudinfrastruktur empfängt.

    • Aktivitätsdaten: Die für Verweisdaten beschriebenen grundlegenden Verfahren treffen auch auf Aktivitätsdaten zu. Allerdings unterscheiden sich Aktivitätsdaten in einem wichtigen Punkt. Es wird davon ausgegangen, dass Verweisdaten in einem persistenten Anwendungsspeicher verfügbar sind. Da sie seltener geändert werden, sollte die Synchronisierung kein Problem darstellen, obwohl sie berücksichtigt werden muss. Allerdings sind Aktivitätsdaten, obwohl sie isoliert sind und nicht so oft aktualisiert werden, flüchtiger als Verweisdaten. Im Idealfall werden Aktivitätsdaten vom verteilten Cache häufig persistent gespeichert und zwischen den verschiedenen Anwendungsinstanzen repliziert. Achten Sie darauf, dass der Abstand zwischen den Persistenz- und Synchronisierungsintervallen groß genug ist, um Konflikte zu vermeiden. Gleichzeitig müssen die Intervalle aber so nah beieinander liegen, dass Datenverluste auf ein Minimum beschränkt werden.

Die Beziehung zwischen Plattform und Anwendung wird besonders in puncto Zuständigkeit häufig falsch verstanden. Insbesondere im Hinblick auf Daten kann dies zu gravierenden Problemen führen.

Während eine Plattform wie Azure mehrere Kopien der Daten lokal speichert (und in einigen Diensten sogar Geo-Redundanz bietet), werden die gespeicherten Daten durch die Anwendung, die Arbeitsauslastung und die Komponentendienste gesteuert. Wenn die Anwendung eine Aktion ausführt, die zur Beschädigung der Anwendungsdaten führt, werden mehrere Datenkopien von der Plattform gespeichert.

Bei der Ermittlung von Fehlerzuständen und Schwachstellen müssen Anwendungsbereiche identifiziert werden, die eine Beschädigung der Daten verursachen können. Die Fehlerursache kann von fehlerhaftem Code bis zu nicht verarbeitbaren Nachrichten reichen. Der jeweilige Fehlerzustand bzw. die Schwachstelle sollte aber in jedem Fall aufgedeckt werden.

Absicherung auf Anwendungsebene

  • Idempotenz

    Eine Grundannahme bei Verbunddiensten besteht darin, dass diese Dienste nicht zu 100 % verfügbar sind und dass die Behandlung vorübergehender Fehler mithilfe einer Wiederholungslogik ein zentraler Implementierungsansatz ist. In Fällen, in denen eine Wiederholungslogik implementiert wird, besteht das Risiko, dass dieselbe Nachricht mehrere Male oder entgegengesetzt der normalen Reihenfolge gesendet wird.

    Designer sollten idempotente Prozesse entwickeln, um sicherzustellen, dass eine mehrfach gesendete Nachricht nicht zu einem unerwartet vollen oder belasteten Datenspeicher führt.

    Wenn beispielsweise Daten aller Anforderungen gesammelt werden, kann dies dazu führen, dass mehrere Datensätze hinzugefügt werden, wenn der Dienstvorgang mehrere Male aufgerufen wird. Eine alternative Methode besteht darin, den Code als intelligente UPSERT-Funktion zu implementieren, die ein Update ausführt, wenn ein Datensatz bereits vorhanden ist, und eine Einfügung, wenn nicht. Ein Zeitstempel oder globaler Bezeichner könnte dazu dienen, neue von bereits verarbeiteten Nachrichten zu unterscheiden, wobei nur neuere in die Datenbank eingefügt und vorhandene Datensätze aktualisiert werden, wenn die Nachricht aktueller ist als die in der Vergangenheit empfangene Nachricht.

  • Arbeitslastaktivitäten und Kompensationsverhalten

    Zusätzlich zur Idempotenz liefert der Begriff "Kompensationsverhalten" einen weiteren wertvollen Ansatz.

    Ein praktisches Beispiel für Kompensationsverhalten ist die Rückgabe eines Produkts, das mit einer Kreditkarte bezahlt wurde. In diesem Szenario bezahlt ein Verbraucher ein Produkt mit seiner Kreditkarte, und das Kreditkartenkonto des Verbrauchers wird mit dem Betrag belastet. Wenn der Verbraucher das Produkt an den Händler zurückgibt, wird eine Richtlinie ausgewertet, und wenn die Retoure der Richtlinie entspricht, stellt der Händler eine Gutschrift über den Kaufbetrag zugunsten des Kreditkartenkontos des Verbrauchers aus.

    Vor dem Hintergrund immer größerer vernetzter Systeme und einer zunehmenden Zahl von Verbunddiensten ist das genaue Verständnis des Begriffs "Kompensationsverhalten" besonders wichtig.

    Der Begriff "Transaktion" ist vielen Entwicklern von Branchenanwendungen bereits seit langem bekannt, er bezieht sich jedoch häufig auf die Transaktionsfunktionalität, die von lokalen Datentechnologien und zugehörigen Codebibliotheken verfügbar gemacht wird. Bezieht man das Konzept auf die Cloud, muss dieser Ansatz neu überdacht und auf die Orchestrierung verteilter Dienste angewendet werden.

    Die Orchestrierung von Diensten kann sich über mehrere verteilte Systeme erstrecken und in einen langwierigen und zustandsorientierten Prozess münden. Die Orchestrierung selbst läuft selten synchron ab, sie kann sich je nach Geschäftsumfeld über einen Zeitraum von Sekunden bis hin zu mehreren Jahren erstrecken.

    An einem Supply-Chain-Szenario, das 25 Organisationen in dieselbe Arbeitslastaktivität einbindet, können beispielsweise 25 oder mehr Systeme beteiligt sein, die in einer oder mehreren Dienstorchestrierungen vernetzt werden.

    Falls eine Transaktion erfolgreich verläuft, müssen die 25 Systeme davon in Kenntnis gesetzt werden. Für jeden Verbindungspunkt in der Aktivität können Teilnehmersysteme eine Korrelations-ID für Nachrichten bereitstellen, die sie von anderen Systemen empfangen. Je nach Aktivitätstyp kann der Empfang der Korrelations-ID bereits ausreichen, um die Transaktion als abgeschlossen anzusehen. In anderen Fällen wird – sobald die Interaktionen aller 25 Teilnehmer abgeschlossen sind – eine Bestätigungsmeldung an alle Teilnehmer gesendet (entweder direkt von einem Einzelgerät oder über die spezifischen Interaktionspunkte der einzelnen Systeme).

    Um Fehler in Verbundaktivitäten und/oder verteilten Aktivitäten zu behandeln, würde jeder Dienst eine Dienstschnittstelle und Vorgänge verfügbar machen, um Abbruchanforderungen für eine bestimmte Transaktionen unter Angabe eines eindeutigen Bezeichners zu empfangen. Hinter den Kulissen würden Workflows installiert werden, die den Abbruch dieser Aktivität kompensieren. Im Idealfall sind dies automatisierte Prozeduren, allerdings kann auch ein Mitarbeiter aufgefordert werden, manuell Abhilfe zu schaffen.

Sicherungen

Neben der Absicherung auf Anwendungsebene, um die Beschädigung von Daten zu vermeiden, gibt es zusätzliche Maßnahmen für den Fall, dass die Absicherung der Anwendung nicht ausreicht.

Der Resilienzplan sollte Prozesse zum partiellen oder vollständigen Erstellen und Wiederherstellen von Sicherungskopien des Datenspeichers vorsehen. Die Konzepte zum Sichern und Wiederherstellen von Daten sind zwar nicht neu, stellen in der Cloud jedoch neue Herausforderungen.

Bei der Entwicklung einer Sicherungsstrategie sollten Sie die Geschäftsanforderungen im Zusammenhang mit der Datenwiederherstellung kennen. Wenn ein Datenspeicher aufgrund eines Notfalls beschädigt oder offline geschaltet wird, sollten Sie wissen, welche Art und Menge von Daten wiederherstellt werden müssen und in welchem Zeitrahmen dies geschehen muss. Dies wirkt sich auf den gesamten Verfügbarkeitsplan aus und sollte bei der Sicherungs- und Wiederherstellungsplanung berücksichtigt werden.

  • Relationale Datenbanken

    Die Sicherung relationaler Datenbanken ist ein bekanntes Thema. Zahlreiche Unternehmen verfügen über Sicherungstools, -modelle und -prozesse, um Daten gemäß den Notfallwiederherstellungs- oder Complianceanforderungen zu sichern. In vielen Fällen können die gewohnten Sicherungstools, -modelle und -prozesse ohne oder mit nur geringfügigen Modifikationen eingesetzt werden. Darüber hinaus kommen neue Alternativen oder Varianten in Betracht, beispielsweise die Datensicherung und -speicherung in einem cloudbasierten BLOB-Speicher.

    Bei der Beurteilung vorhandener Prozesse und Tools sollte eine Methode gesucht werden, die für die cloudbasierte Lösung geeignet ist. Häufig wird mindestens eines der nachfolgend genannten Modelle eingesetzt, um verschiedene Fehlerzustände zu beheben.

    1. Vollständige Sicherung: Der gesamte Datenspeicher wird gesichert. Die Notwendigkeit einer vollständigen Sicherung ergibt sich aus der Datenmenge und dem Datenzuwachs. Eine vollständige Sicherung bezieht sich auf das komplette Dataset das gemäß der geltenden SLA für einen Dienst bereitgestellt werden muss. Mechanismen für diesen Sicherungstyp werden im Allgemeinen von der Datenbank/dem Anbieter des Datenbankdiensts oder dessen Anbieter-Ökosystem zur Verfügung gestellt.

    2. Zeitpunktwiederherstellung: Eine Zeitpunktsicherung spiegelt einen bestimmten Zeitpunkt im Lebenszyklus der Datenbank wider. Wenn beispielsweise am Nachmittag eine Beschädigung des Datenspeichers auftritt, könnten die Auswirkungen auf die Geschäftsabläufe so gering wie möglich gehalten werden, wenn eine mittags erstellte Zeitpunktsicherung wiederhergestellt wird.

      Da Internetkonnektivität für den Einzelnen immer wichtiger wird und jeder erwartet, dass ein Dienst rund um die Uhr verfügbar ist, wird die zeitnahe Wiederherstellung unverzichtbar.

    3. Synchronisierung: Die Datensynchronisierung kann zusätzlich zur traditionellen Sicherung verwendet werden. Daten könnten in mehreren Datencentern gespeichert und in regelmäßigen Intervallen zwischen Datencentern synchronisiert werden. Neben der Bereitstellung synchronisierter Daten in Lösungen, die das Datenverkehrsmanagement im Rahmen eines normalen Verfügbarkeitplans nutzen, ist auch ein Failover auf ein zweites Datencenter denkbar, um die Geschäftskontinuität aufrechtzuerhalten.

      Internetnutzer wollen ständig verbunden sein und Dienste konsumieren. Vor diesem Hintergrund sind Downtimes kaum noch tragbar und Synchronisierungslösungen ein praktikabler Ansatz.

      Synchronisierungsmuster:

      - zwischen Datencentern eines bestimmten Cloudanbieters

      - Cloudanbieter-übergreifend zwischen Datencentern

      - zwischen Datencentern von einem lokalen Standort zu einem bestimmten Cloudanbieter

      - zwischen Datencenter und Gerät zur Synchronisierung consumerspezifischer Datenslices

  • Relationale Shard-Datenbanken

    Ein häufiger Grund für den Wechsel in die Cloud ist die Notwendigkeit, hohe Benutzerzahlen und ein ständig wachsendes Datenverkehrsaufkommen zu bewältigen, z. B. für mobile Anwendungen oder soziale Netzwerke. Bei diesem Anwendungsmuster wird das Einzeldatenbank-Modell durch eine Reihe von Datenbankshards abgelöst, die jeweils einen Teilbereich des ganzen Datasets enthalten und für hohe Zugriffsraten optimiert sind. Ein kürzlich gestartetes Social Network-Projekt unter Azure wies zu Beginn 400 Datenbankshards auf.

    Jedes Shard stellt eine eigenständige Datenbank dar. Deshalb sollten Architektur und Verwaltung so ausgelegt sein, dass vollständige Sicherungen, Zeitpunktsicherungen sowie die Wiederherstellung von Sicherungen sowohl für einzelne Shards als auch für das komplette, aus allen Shards bestehende Dataset möglich sind.

  • NoSQL-Datenspeicher

    Sicherungsrichtlinien sollten nicht nur für relationale Datenspeicher, sondern auch für "Not only SQL" bzw. NoSQL-Datenspeicher in Betracht gezogen werden. Die meistverbreitete, von führenden Cloudanbietern angebotene Form von NoSQL-Datenbanken ist ein hoch verfügbarer, aus Schlüssel-Wert-Paaren bestehender Speicher, der oft als Tabellenspeicher bezeichnet wird.

    NoSQL-Speicher können hohe Verfügbarkeit unterstützen. In manchen Fällen bieten sie auch Geo-Redundanz zur Vermeidung von Datenverlusten, die aufgrund eines schwerwiegenden Ausfalls in einem spezifischen Rechenzentrum auftreten können. Diese Speicher weisen in der Regel keinen Mechanismus auf, der Schutz vor dem unbeabsichtigten Überschreiben oder Löschen von Inhalten bietet. Da Anwendungs- oder Benutzerfehler nicht automatisch von Plattformdiensten wie BLOB-Speichern behandelt werden, sollte eine Sicherungsstrategie evaluiert werden.

    Relationale Datenbanken sind in der Regel mit ausgereiften Sicherungstools ausgestattet, viele NoSQL-Speicher jedoch nicht. In diesen Architekturen werden häufig Datenkopien in einem NoSQL-Replikatspeicher erstellt. Anschließend wird mithilfe von Nachschlagetabellen ermittelt, welche Zeilen vom Quellspeicher in den Replikatspeicher kopiert wurden. Zur Datenwiederherstellung wird dieselbe Tabelle herangezogen, um wiederherstellbare Inhalte im Replikatspeicher zu identifizieren.

    Abhängig von der erforderlichen Geschäftskontinuität könnte dieses Replikat vom selben Cloudanbieter im selben Datencenter und/oder im selben NoSQL-Datenspeicher gehostet werden. Natürlich kommen auch andere Datencenter, Cloudanbieter und/oder NoSQL-Speichervarianten in Frage. Die Standortwahl richtet sich in hohem Maß nach der für den Arbeitslastdienst gewünschten SLA und weiteren Erfordernissen zur Einhaltung gesetzlicher Bestimmungen.

    Darüber hinaus wird die Entscheidung durch Kostenüberlegungen beeinflusst, insbesondere in Bezug auf Dateneingänge und -ausgänge. Für Datenbewegungen innerhalb ihrer Datencenter und in die eigene Cloudumgebung erheben Cloudanbieter u. U. keine Gebühren. Ausgehende Daten verursachen jedoch immer Kosten, und die Umlagerung von Daten auf eine zweite Cloudplattform könnte erhebliche Mehrkosten verursachen.

    noteHinweis
    Da die Nachschlagetabelle zur Schwachstelle werden könnte, sollte die Tabellenreplikation in den Resilienzplan einbezogen werden.

  • BLOB-Speicher

    Ähnlich wie bei relationalen und NoSQL-Datenspeichern wird auch bei BLOB-Speichern fälschlicherweise angenommen, dass die implementierten Verfügbarkeitsmerkmale die Implementierung einer Sicherungsrichtlinie überflüssig machen.

    BLOB-Speicher kann sogar geo-redundant sein, was aber – wie bereits erwähnt – nicht vor Anwendungsfehlern schützt. Da Anwendungs- oder Benutzerfehler nicht automatisch von Plattformdiensten wie BLOB-Speichern behandelt werden, sollte eine Sicherungsstrategie evaluiert werden.

    Als Sicherungsstrategien könnten ähnliche Ansätze wie für NoSQL-Speicher verwendet wurden. BLOBs sind meist sehr groß. Daher müssen die für die Datenbewegung anfallenden Kosten sowie die Zeit in der Sicherungs- und Wiederherstellungsstrategie berücksichtigt werden.

  • Wiederherstellen von Sicherungen

    Mittlerweile kennt wahrscheinlich jeder die Geschichte von der Organisation, die zwar Sicherungsrichtlinien aufgestellt und befolgt, aber nie geprüft hat, ob sich die Daten wiederherstellen lassen. Als der Notfall eines Tages tatsächlich eintrat und die Datenbanksicherung wiederhergestellt werden sollte, mussten die Mitarbeiter feststellen, dass die Sicherung falsch konfiguriert war und dass die Bänder, die jahrelang extern gelagert waren, die benötigten Daten gar nicht enthielten.

    Bei der Implementierung von Sicherungsprozessen sollten die Tests nicht außer Acht gelassen werden. So kann sichergestellt werden, dass Daten ordnungsgemäß wiederhergestellt werden können und dass die Wiederherstellung schnell und ohne Beeinträchtigung der Unternehmensabläufe verläuft.

CDNs (Content Delivery Networks = Netzwerke für die Inhaltsübermittlung) bieten eine gute Möglichkeit, die Verfügbarkeit und Benutzerfreundlichkeit bei der Bereitstellung häufig angeforderter Dateien zu erhöhen. Der Inhalt eines CDNs wird bei der ersten Verwendung auf einen lokalen Knoten kopiert und bei nachfolgenden Anforderungen von diesem Knoten bereitgestellt. Da der Inhalt nach einem bestimmten Zeitraum nicht mehr gültig ist, muss er bei der nächsten Anforderung erneut auf den lokalen Knoten kopiert werden.

Die Verwendung eines CDNs bietet viele Vorteile, verursacht jedoch auch eine Abhängigkeit. Wie bei jeder Abhängigkeit sollte die Behebung eines Dienstfehlers proaktiv angegangen werden.

Geeigneter Einsatz eines CDNs

Die Annahme, dass CDNs ein Allheilmittel für hohe Zugriffsraten sind, ist zwar weit verbreitet, aber falsch. In einem Fall war ein Kunde davon überzeugt, dass ein CDN die richtige Lösung für einen eBook-Onlinestore sei. War es jedoch nicht. Warum? In einem Katalog mit einer Million Büchern gibt es eine kleine Menge an Büchern, die häufig angefordert werden (die "Treffer"), und eine lange Reihe von Büchern, bei denen die Abfragehäufigkeit kaum vorhersagbar ist. Häufig angeforderte Titel wurden bei der ersten Anforderung auf den lokalen Knoten kopiert und sorgten so für kostengünstige lokale Skalierung und eine positive Nutzererfahrung. Für den "Long Tail" wird fast jede Anforderung zweimal kopiert – einmal auf den lokalen Knoten und dann in die Kundenumgebung – da Inhalte regelmäßig ablaufen, weil sie zu selten abgefragt werden. Das ist der Beweis, dass ein falsch eingesetztes CDN das Gegenteil des gewünschten Effekts erzielt – eine langsamere und kostenaufwändigere Lösung.

In vielen Fällen werden die Abläufe einer Lösung erst zu einem späteren Zeitpunkt im Lebenszyklus geplant. Wirklich resiliente Anwendungen müssen gemäß einem prozessorientierten Ansatz entwickelt werden. Dieser Ansatz umfasst normalerweise eine Reihe von Schlüsselaktivitäten wie die Erstellung eines Integritätsmodells, die Erfassung von Telemetriedaten, die Einbindung von Systemüberwachungsdiensten und -workflows sowie die Bereitstellung der Daten für Prozesse und Entwickler.

Entwicklungsteams übersehen häufig die Integrität von Anwendungen und ignorieren sie in manchen Fällen fast vollständig. Das hat zur Folge, dass Dienste häufig mit nur zwei bekannten Status in die Produktionsumgebung gelangen: bereit oder nicht bereit. Die Entwickler resilienter Dienste sollten auf Integritätsmodelle setzen, in denen die Integritätskriterien einer Anwendung, der eingeschränkte Integritätsstatus, Ausfallszenarien und Integritätsabhängigkeiten definiert sind.

Durch die proaktive Entwicklung eines Integritätsmodells werden Fehlerzustände und Schwachpunkte herausgearbeitet, die von den Entwicklern in der Entwurfsphase der Anwendung erkannt und im Rahmen einer What-If-Analyse untersucht werden müssen. Damit ein Integritätsmodell in Betrieb genommen werden kann, ist es auf Zustandsinformationen eines Diensts angewiesen. Diese Informationen müssen programmgesteuert übermittelt werden. Darüber hinaus bedarf es einer Schnittstelle für die interaktive Abfrage der Statusinformationen sowie bestimmter Mechanismen (bzw.der Mitnutzung vorhandener Mechanismen), über die Administratoren die Anwendungsintegrität in Echtzeit überwachen können. Schließlich muss gewährleistet sein, dass Administratoren bei Bedarf die richtige Maßnahme ergreifen können, um die Anwendung wieder in einen ordnungsgemäßen Zustand zu versetzen.

Definieren von Eigenschaften

Für Dienste oder Anwendungen sollte eine Diagnose ausgeführt werden, um die Datenpunkte und Wertbereiche anhand von mindestens drei verschiedenen Kategorien zu bewerten: Integrität, verminderte Integrität und nicht integer. Diese Informationen können verwendet werden, um die Selbstheilung der Dienste zu automatisieren.

Definieren von Schnittstellen

Nachdem die Integritätszustände definiert wurden, können über einen Dienst statusbezogene Schnittstellen verfügbar gemacht werden. Diese Schnittstellen bieten eine Reihe von Handlungsoptionen.

  • Übermitteln des Integritätsstatus an abonnierte Partnerdienste

    Ein Dienst sollte Zustandsinformationen an abonnierte Partnerdienste übermitteln. Diese Informationen sollten kompakt sein sowie aussagekräftige Statusinformationen und allgemeine Diagnosedaten umfassen.

    Der Partnerdienst sollte in der Lage sein, über den Dienst Zustandsmeldungen zu abonnieren. Die Übermittlung von Zustandsmeldungen kann auf eine Weise erfolgen, die an die Lösung angepasst ist. Eine Möglichkeit besteht darin, Updates zum Integritätszustand in eine Warteschlange zu stellen, aus der sie von Abonnenten abgerufen werden.

    Alternativ kann Abonnenten die Möglichkeit eingeräumt werden, einen Endpunkt bereitzustellen, auf dem eine bekannte Schnittstelle für Zustandsberichte verfügbar gemacht wird. Sobald sich Zustandsinformationen ändern, können die Informationen den Abonnenten über die Endpunkte zur Verfügung gestellt werden.

  • Bereitstellen von Schnittstellen für die Übermittlung von Telemetriedaten

    Telemetriedaten bringen einer Prozessumgebung enorme Vorteile, da sie helfen, den aktuellen Zustand der Anwendung und/oder Dienste auf mehreren Ebenen zu identifizieren. Sie geben schnell Aufschluss, wenn in der Umgebung etwas Untypisches passiert. Das ermöglicht fundierte Einblicke in alle Aktivitäten, die den Prozessbeteiligten, Diensten und Dashboards des Dienstanbieters zur Verfügung gestellt werden.

    Die Telemetriedaten umfassen z. B. Informationen über die durchschnittliche CPU-Nutzung, Fehler, Verbindungen, rollenspezifische Warteschlangen, Dienste und Verbundanwendungen, die auf den Diensten aufsetzen.

    Die anwendungsspezifische Telemetrie wird in der Regel nicht automatisch aktiviert und direkt von der Plattform überwacht. Deshalb muss die Telemetrie vom Dienst und von der Anwendung aktiviert werden.

  • Bereitstellen von Schnittstellen, um zusätzliche Zustandsdiagnoseinformationen vom Dienst abzufragen

    Idealerweise sollte ein Dienst auch Schnittstellen für die Abfrage zusätzlicher Zustandsdiagnoseinformationen enthalten. Auf der Basis der umfangreichen übermittelten Zustandsinformationen können Abonnentendienste zusätzliche Informationen anfordern, um zusammen mit dem Dienst, der die Zustandsinformationen bereitstellt, das weitere Vorgehen abzustimmen.

    Insbesondere wenn der Dienst bedenkliche Zustandsinformationen übermittelt, kann ein Consumerdienst auf der Basis zusätzlicher Informationen entscheiden, ob die Nutzung des Diensts fortgesetzt oder ein anderer Anbieter gewählt werden soll.

  • Bereitstellen von Schnittstellen, um die Integrität des Diensts auf Dienst- und Anwendungsebene wiederherzustellen

    Wenn die Zustandsinformationen von einem internen oder verwandten Dienst konsumiert werden, soll der Dienst vielleicht in der Lage sein, bekannte Probleme eigenständig zu beheben. Wie in der Humanmedizin braucht es eine Weile, den Integritätszustand des Diensts zu verstehen und in Abstimmung mit den Zustandsdaten die richtige Behandlungsmethode zu wählen.

    Ein Dienst sollte eine Schnittstelle verfügbar machen, damit er für entsprechende Maßnahmen zugänglich ist. Einfachere Maßnahmen reichen vom Neustart oder der erneuten Erstellung eines Images bis hin zum Failover auf einen anderen internen Daten- oder Dienstanbieter.

    Genaue Informationen über den Dienstzustand können dazu beitragen, dass der Dienstanbieter Fehlerzustände eines Systems schnell erkennt. Automatisierte Vorgänge können beschleunigte, konsistente und angeratene Abhilfemaßnahmen für bekannte Probleme herbeiführen und die Selbstheilung des Diensts unterstützen. In diesem Abschnitt werden die verschiedenen Aspekte der Integritätszustände ausführlich beschrieben.

Telemetrie ist "der Vorgang, Messwerte von etwas (wie etwa Druck, Geschwindigkeit oder Temperatur) mithilfe besonderer Gerätschaften zu erfassen und diese Messwerte dann per Funk an einen anderen Ort zu senden".

Das Erfassen von Telemetriedaten Ihres Dienstes ist wichtig. Telemetrie wird oftmals in vier verschiedene Typen kategorisiert: Benutzer, Geschäft, Anwendung und Infrastruktur.

Benutzertelemetrie misst das Verhalten eines einzelnen, angezielten Benutzers. Dies bietet Erkenntnisse über das Verhalten eines Benutzers und kann das Bereitstellen einer individuellen Erfahrung erheblich erleichtern.

Geschäftstelemetrie enthält auf Geschäftsaktivitäten bezogene Daten und KPIs (Leistungskennzahlen, Key Performance Indicator) für das Unternehmen. Beispiele für Geschäftstelemetrie sind etwa die Anzahl der einzelnen aktiven Benutzer auf einer Website, die Anzahl der betrachteten Videoclips usw.

Anwendungstelemetrie enthält Einzelheiten zu Integrität, Leistung und Aktivität der Anwendungsschicht und der von ihr abhängenden Dienste. Anwendungstelemetrie enthält z. B. Details zu Aufrufen und Anmeldungen von Datenclients, Ausnahmen, API-Aufrufen, Sitzungen usw.

Infrastrukturtelemetrie erfasst Details zur Integrität der zugrundliegenden Systeminfrastruktur. Dies kann Daten zu solchen Ressourcen wie der CPU, dem Arbeitsspeicher, dem Netzwerk, der verfügbaren Kapazität usw. umfassen.

Beim Festlegen der zu erfassenden Daten und der Weise ihrer Erfassung müssen Ihnen die Grundlagen der Daten und Ihre Ziel bei der Erfassung bekannt sein.

Legen Sie zuerst fest, ob der Zweck der Datenerfassung informativ ist oder zum Einleiten einer Aktion dienen soll. Die entscheidende Frage lautet: "Wie schnell muss ich reagieren?" Verwenden Sie die Daten nahezu in Echtzeit, um eine mögliche Aktion einzuleiten? Der Gegenentwurf dazu wäre die Verwendung der Daten in einem monatlichen Trendbericht. Die Antwort auf diese Fragen bildet den Input für den in der Architektur verwendeten Telemetrieansatz und die eingesetzten Technologien.

Bestimmen Sie im nächsten Schritt die Art von Frage(n), die Sie mithilfe der erfassten Telemetriedaten beantworten möchten. Möchten Sie Telemetrie einsetzen, um Antworten auf bereits bekannte Fragen zu finden, oder setzen Sie Telemetrie zur Erkundung ein? Beispielsweise stellen für ein Unternehmen KPIs Antworten auf wohlbekannte Fragen dar. Demgegenüber unternimmt ein Hersteller, der Gerätedaten auf Muster untersuchen möchten, die zu Fehlern führen, eine Reise ins Ungewisse. Für den Hersteller lassen sich die Fehler aus einem oder mehreren Elementen im System ableiten. Der Hersteller geht also erkundend vor und benötigt weitere Daten.

Wenn Sie Telemetrie verwenden, um Erkenntnisse zu gewinnen, dann müssen Sie auch den Zeitaufwand für das Erwerben dieser Erkenntnisse berücksichtigen. In manchen Fällen werden Sie Telemetrie nutzen, um eine Spitze in den Daten eines Gerätesensors zu erkennen, die ein Zeitfenster von Sekunden oder Minuten hat. In anderen Fällen können Sie Telemetrie verwenden, um den Benutzerzuwachs im wöchentlichen Rhythmus für eine Website zu untersuchen, die ein viel längeres Zeitfenster hat.

Erwägen Sie schließlich die Menge an Daten, die Sie aus einer Signalquelle innerhalb eines bestimmten Zeitrahmens erfassen können, um Einblicke zu gewinnen. Sie müssen die benötigte Menge der Quellsignale kennen. Anschließend können Sie die beste Möglichkeit finden, dieses Signal zu partitionieren und die geeignete Mischung aus lokalem und globalem Servereinsatz zu bestimmen.

Eine andere Überlegung betrifft das Aufzeichnen der Ereignisabfolge in Ihrer Telemetrie. Viele Organisationen verwenden standardmäßig Zeitstempel. Zeitstempel können sich jedoch zur Herausforderung entwickeln, da Serveruhren in und zwischen verschiedenen Datencentern inkonsistent sind. Zwar lässt sich die Uhrzeit regelmäßig aktualisieren, jedoch gibt es belegte Hinweise darauf, dass Serveruhren "driften" (im Lauf der Zeit ungenauer werden). Dieses Abdriften führt zur Veränderungen, die eine effektive Analyse beeinträchtigen können. Ziehen Sie bei Szenarien, in denen Präzision erforderlich ist, alternative Lösungen in Erwägung, etwa die Nutzung einer Vektoruhrimplementierung.

Fahren Sie nach dem Ermitteln eines Telemetrieansatzes mit dem Charakterisieren des Signals fort.

Das Signal kann als kontinuierlich oder diskret klassifiziert werden. Ein Beispiel für ein kontinuierliches Signal sind Ereignisdaten in Echtzeit. Protokolldateieinträge sind demgegenüber Teil eines diskreten Signals.

Um den Erfordernissen Ihres Ansatzes gerecht zu werden, müssen Sie ermitteln, wie viele Daten sich im Signal befinden. Wenn die Informationen fortlaufend sind, müssen Sie eine Samplingrate (die Häufigkeit von Stichproben) definieren. Sind sie diskret, müssen Sie die zu behaltenden oder auszufilternden Datensätze identifizieren.

Ferner müssen Sie die Zugriffsart ermitteln. In manchen Fällen ist eine Pushübermittlung der Telemetriedaten sinnvoll. In anderen Fällen rufen Sie die Telemetriedaten mittels Pull ab.

Bei höher entwickelten Systemen kann leicht die Situation eintreten, dass die aus der gepushten Telemetrie gewonnenen Einsichten Anlass zum Pull-Abruf weiterer Informationen geben. Wenn z. B. die gepushte Telemetrie auf einen nicht optimalen Status hinweist, können Sie mithilfe von Pull weitere Diagnosedaten abrufen.

Alle gesammelten Daten können unter bestimmten Umständen relevant sein, aber nicht alle Telemetriedaten müssen die ganze Zeit hindurch gesendet werden. Abhängig von der Art der Telemetrie und der zum Gewinnen von Einsichten erforderlichen Datenmenge ist es Ihnen möglicherweise möglich, sich auf den Abruf kleinerer Datenmengen zu beschränken. Sie können lokale Berechnung verwenden, um Aggregate, Stichproben oder Teilmengen zu generieren und diese Daten an den Dienst senden. Wenn die Daten, die Sie aus der standardmäßigen Telemetrie erhalten, auf einen suboptimalen Status hinweisen, kann der Dienst dann beispielsweise weitere Daten anfordern.

Überlegen Sie bei der Entwicklung einer Telemetriestrategie, welche Richtlinien geeignet sind. Telemetrie setzt verfügbare Verbindungen voraus, und das Senden von Daten über eine Verbindung ist mit Kosten verbunden. Erstellen Sie Richtlinien, die Kontext, Konnektivität und Kosten berücksichtigen, und passen Sie die Telemetrie entsprechend an.

Ihre Richtlinien müssen den Kontext des aktuellen Status berücksichtigen, um zu bestimmen, welche Telemetrie jetzt sinnvoller Weise gesendet wird. Die aus der zuvor empfangenen Telemetrie gewonnenen Erkenntnisse und die damit einhergehenden Geschäftserfordernisse speisen den Kontext. Dieser Kontext hilft, Richtung und Prioritäten bei der Telemetrie-Erfassung anzugeben.

Die Geräte können eine unterschiedliche Konnektivität (WiFi, LTE, 4G, 3G usw.) aufweisen, und die Konnektivität kann Schwankungen unterliegen. Die momentane Konnektivität des Geräts ist relevant für die Entscheidung, welche Daten übermittelt werden sollen. In Szenarien mit unzuverlässigen oder langsamen Verbindungen können Richtlinien die übermittelte Telemetrie priorisieren.

Konnektivität wird oft nur zu bestimmten Kosten bereitgestellt. Richtlinien berücksichtigen, ob eine Verbindung zurzeit einem Volumentarif unterliegt oder nicht. Bei einem Volumentarif ermitteln die Richtlinien die mit der Übermittlung verbundenen Kosten und, falls definiert, Nutzungslimite. Viele Geräte verwenden im Lauf des Tages verschiedene Arten von Verbindungen. Sie können bestimmte Telemetrie nach Maßgabe ihrer Übermittlungskosten priorisieren.

Verschiedene Zielgruppen möchten Telemetriedaten gerne aufnehmen und visualisieren. Betrieb und Entwicklung stellen zwei Felder dar, für die Visualisierung wichtig ist. Wie unten kurz umrissen, erfordern die Bedürfnisse der verschiedenen Zielgruppen verschiedene Auflösungen.

Die Visualisierung von Betriebsdaten auf hoher Ebene und allgemeiner Telemetriedaten ist wichtig für das Betriebspersonal. Automaische Benachrichtigungen wurden vermutlich auf der Grundlage von Telemetriedaten bereits eingerichtet. Das Betriebspersonal wünscht sich jedoch vermutlich ein Dashboard, das die Visualisierung der Leistung von Diensten jetzt und in der Vergangenheit unterstützt.

Bei entsprechend umfangreichen Anwendungen helfen diese Informationen, ein aktuelles Problem schnell zu erkennen oder ein zukünftiges Problem vorherzusagen. Sie können dem Betriebspersonal auch beim Erkennen der möglichen Auswirkungen und der zugrunde liegenden Ursachen helfen.

Abbildung 10

Die vorangehende Grafik zeigt eine Reihe von Informationen für eine umfangreiche soziale Website: durchschnittliche CPU-Nutzung der API-Rolle (in %), API-Fehler, Zahl der Onlinebenutzer, aktive Internetverbindungen, CPU-Nutzung der Webrolle (in %), Internetfehler, hardwarebasierte Internetverbindungen, gepoolte Internetverbindungen, Web-App-Warteschlange, softwarebasierte Verbindungen.

Telemetriedaten und der oben dargestellte Zustandsbericht sind insbesondere hilfreich, wenn ein Fehler behoben werden kann, ohne dass Codeänderungen an den Diensten selbst vorgenommen werden müssen. Aktivitäten, die in diesem Fall ausgeführt werden können, sind die Bereitstellung weiterer Rollen und das Recyceln von Instanzen.

Die Visualisierung von Telemetriedaten – sowohl historischer als auch echtzeitiger – kann für folgende Zwecke genutzt werden:

  • Problembehandlung

  • Manöverkritik für aktuelle Probleme bei Live-Websites

  • Schulung von neuem Betriebspersonal

Zusätzlich zum Betriebspersonal gehören Softwareentwickler zu den wichtigen Nutzern von Telemetriedaten. Fehler beziehen sich möglicherweise nicht auf die Betriebsumgebung, sondern auf den zugrunde liegenden Anwendungscode. Wenn ein Telemetriedashboard für Entwickler zur Verfügung steht, können diese gezielte Maßnahmen ergreifen.

Unten sind zwei Screenshots eines Beispielhilfsprogramms abgebildet, das für genau diesen Zweck erstellt wurde. Das Dashboard enthält ausführliche Informationen wie die Anzahl der Fehler, die Fehlerkategorien und weiterführende Informationen zu jeder Kategorie. Es umfasst zusätzlich Analysedaten wie die Gesamtanzahl der Fehler, die Gesamtanzahl fehlerhafter Rolleninstanzen und die Gesamtanzahl der Datenbanken mit einer Fehlerbedingung.

Abbildung 11

Abbildung 12

Bei umfangreichen Websites mit Millionen Nutzern treten höhere Fehlerraten auf, die jedoch noch akzeptabel sein können. Ein entwicklerspezifisches Dashboard mit Telemetriedaten kann dazu beitragen, ein echtes Problem zu identifizieren. Es gibt Auskunft darüber, ob das Problem beseitigt werden kann und wo der Fehler im Code aufgetreten ist.

Siehe auch

Anzeigen:
© 2014 Microsoft