Zwei Anwendungsserver können dieselbe Ausfallursache behalten

Ein zweiter Anwendungsserver kann einen ausgefallenen Prozess ersetzen. Ob der Kunde danach weiterarbeiten kann, hängt aber auch von den gemeinsam genutzten Komponenten ab. Die nächste Investition sollte deshalb einen benannten Ausfall abdecken, statt nur die Serverzahl zu erhöhen.

Microsoft empfiehlt, Redundanz entlang kritischer Abläufe auf Rechenleistung, Daten und Netzwerk zu betrachten. Eine verdoppelte Anwendungsschicht beantwortet die Frage nach dem gesamten Ablauf noch nicht.

Den gemeinsamen Weg sichtbar machen

Im erfundenen Beispiel öffnen Kunden eine Projektliste. Zwei Anwendungsinstanzen auf getrennten virtuellen Maschinen lesen dafür dieselbe Datenbank. Vorgeschaltet ist ein einzelner selbst betriebener Loadbalancer. Er verteilt Anfragen; ein intern redundant verwalteter Zugangsdienst ist hier nicht gemeint. Auf den Anwendungsinstanzen liegen keine allein dort benötigten Sitzungsdaten.

Die Kennungen in der Tabelle gehören nur zu diesem Beispiel. Es gibt zunächst keinen Ersatz für Datenbank oder Loadbalancer. Die Tabelle beschreibt erwartete Auswirkungen, keine gemessene Verfügbarkeit.

Welche Störung die zweite Instanz abdecken kann

Selbst der erste Fall ist eine zu prüfende Erwartung. Wenn die verbleibende Maschine überlastet wird oder die Umleitung nicht greift, reicht ihre bloße Existenz nicht aus. Auch zwei VMs können Standort, Stromversorgung oder andere Infrastruktur teilen; die tatsächlichen Ausfallbereiche müssen zur Anforderung passen.

Die gemeinsame Datenebene gezielt behandeln

Soll die Projektliste auch beim Datenbankausfall verfügbar bleiben, braucht die Datenebene einen geeigneten Ansatz für Verfügbarkeit und Umschaltung. Dabei sind zulässiger Datenverlust, Konsistenz und das Verhalten laufender Schreibvorgänge zu klären. Ein zweiter Datenbankprozess allein beweist ebenfalls keinen sicheren Weiterbetrieb.

Microsoft unterscheidet laufende Replikate und zeitbezogene Sicherungskopien. Ein Backup dient einem Wiederherstellungsweg und ist nicht automatisch eine sofort verfügbare laufende Ersatzdatenbank. Replikation ersetzt keine geprüfte Wiederherstellung nach einer unbeabsichtigten Datenänderung. Die benötigten Maßnahmen hängen vom Geschäftsziel ab.

Mit dem betroffenen Benutzerablauf entscheiden

Microsofts Ausfallanalyse folgt jedem kritischen Ablauf und seinen internen sowie externen Abhängigkeiten. Für unser Beispiel sollten die drei Tabellenfälle in einer freigegebenen Testumgebung einzeln geprüft werden. Festzuhalten sind Erkennung, Verhalten beim Laden der Projektliste, Wiederanlauf und verantwortliche Rolle.

Wenn ein vereinbarter Wiederherstellungsweg eine Datenbankunterbrechung ausreichend abdeckt, kann die zusätzliche Anwendungsinstanz trotzdem für Prozessausfälle oder Wartung sinnvoll sein. Verlangt das Geschäft Weiterbetrieb auch bei Datenbank- oder Zugangsausfall, bleiben genau diese Lücken offen. Eine Verfügbarkeitsquote lässt sich aus der Zahl der Maschinen nicht ableiten.

Quellen

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup