Aktiv-Aktiv oder Aktiv-Passiv: Was ist die richtige Wahl?

An einem Montagmorgen reagiert das Bestellsystem langsam und wird dann unzugänglich. Der Webshop nimmt weiterhin Bestellungen an, aber das Lager sieht sie nicht, der Kundenservice kann keinen genauen Status angeben und die Rechnungsstellung stoppt. In solchen Fällen wird es zu einer geschäftlichen Frage, ob aktive-aktive oder aktive-passive Systemarchitektur kritische Dienste schützt.

Die beiden Ansätze werden oft nur als Infrastrukturentscheidung betrachtet. Tatsächlich bestimmen sie, was mit dem Betrieb passiert, wenn ein Server, eine Anwendung, eine Netzwerkverbindung oder sogar ein ganzer Standort ausfällt. Die richtige Wahl hängt nicht davon ab, welche fortschrittlicher klingt, sondern davon, welche Geschäftsprozesse nicht unterbrochen werden dürfen, wie viel Datenverlust akzeptabel ist und wie gut die Organisation in der Lage ist, die gewählte Lösung sicher zu betreiben.

Was bedeutet aktive-aktive und aktive-passive Betriebsweise?

In einer aktive-aktive Konfiguration führen zwei oder mehr Systeminstanzen gleichzeitig wesentliche Arbeiten aus. Beispielsweise bedienen zwei Anwendungsserver parallel die Benutzer des Webshops, und ein Lastverteiler verteilt die Anfragen zwischen ihnen. Wenn eine Instanz ausfällt, arbeitet die andere weiter, in der Regel unbemerkt oder mit nur kurzer Unterbrechung.

In einer aktive-passive Konfiguration arbeitet das primäre System, während das sekundäre in Bereitschaft ist. Das Backup-System erhält kontinuierlich oder in festgelegten Intervallen die Daten des primären Systems, bedient jedoch im Normalbetrieb keine Benutzer. Im Fehlerfall übernimmt es die Rolle. Dies wird als Failover bezeichnet, also als automatisches oder manuelles Umschalten.

Auf den ersten Blick mag die aktive-aktive Lösung eindeutig besser erscheinen: Zwei funktionierende Systeme sind besser als ein funktionierendes und ein wartendes. Dies gilt jedoch nur, wenn die Anwendung, die Datenverwaltung, das Netzwerk und die Betriebsprozesse in der Lage sind, den parallelen Betrieb zu handhaben. Eine fehlerhaft gestaltete aktive-aktive Umgebung kann nicht nur teurer sein, sondern auch schwerer diagnostizierbare Fehler verursachen.

Verfügbarkeit ist nicht gleichbedeutend mit mehreren Servern

Viele Unternehmen haben einen zweiten Server, ein Backup oder sogar eine Ersatz-Internetverbindung, und dennoch kann man nicht von echter hoher Verfügbarkeit sprechen. Der Grund ist einfach: Die Ursache des Ausfalls ist oft nicht der Server selbst.

Wenn der Webshop und die Lagerverwaltung von derselben Datenbank, demselben Netzwerkgerät oder demselben externen Dienstleister abhängen, lösen zwei Anwendungsserver die gemeinsame Fehlerursache nicht. Dasselbe gilt, wenn das System funktioniert, aber die zur Verarbeitung eingehender Bestellungen benötigte Excel-Datei nur auf dem Computer eines Mitarbeiters vorhanden ist.

Verfügbarkeit sollte daher als Geschäftsdienstleistung interpretiert werden. Es geht nicht darum, ob eine virtuelle Maschine läuft, sondern darum, ob das Lager die Ware übergeben kann, der Frachtbrief erstellt wird, die Bestellung zur Rechnungsstellung gelangt und die Geschäftsführung verlässliche Informationen über den Betrieb erhält.

Beginnen Sie bei den kritischen Punkten des Prozesses

Es ist ratsam, zunächst genau zu klären, welche Prozesse wie viel Ausfallzeit tolerieren können. Ein interner Dokumentenspeicher, der für einige Stunden ausfällt, kann unangenehm, aber handhabbar sein. Ein Produktionssteuerungssystem, ein Online-Zahlungsprozess oder eine Bestellverarbeitung kann bereits nach zehn Minuten zu direkten Einnahme- und Kundenvertrauensverlusten führen.

Ebenso wichtig ist die Grenze des Datenverlusts. Wenn ein System mit Daten von vor einer Stunde wiederhergestellt werden kann, erfordert dies eine andere technische Lösung und Kosten als wenn nur wenige Sekunden Datenverlust zulässig sind. Diese Ebenen werden in der Regel durch RTO- und RPO-Zielwerte beschrieben. Die RTO gibt an, wie schnell der Dienst wiederhergestellt werden muss. Die RPO gibt an, wie viele Daten maximal im Vergleich zum Zustand vor dem Fehler verloren gehen dürfen.

Hinter den Zahlen sollte immer eine konkrete geschäftliche Konsequenz stehen. Das Ziel sollte nicht sein, dass im Plan „hohe Verfügbarkeit“ steht, sondern beispielsweise, dass die Bestellverarbeitung höchstens 15 Minuten ausfallen darf und keine bezahlte Bestellung verloren gehen darf.

Wann ist das aktive-passive Modell gerechtfertigt?

Die aktive-passive Architektur ist für viele wachsende Unternehmen eine vernünftige und effiziente Wahl. Besonders dann, wenn die Zustandsverwaltung der Anwendung komplex ist, auf einem einzigen Datenbankschreiber basiert oder die Software von vornherein keine parallele Bedienung unterstützt.

Stellen Sie sich ein Produktionsunternehmen vor, bei dem die Produktionsdaten von einem zentralen System verwaltet werden. Mehrere Arbeitsstationen sind mit dem System verbunden, aber die Konsistenz der Datenbank hat Vorrang. Hier kann eine sorgfältig aufgebaute primär-bereitstehende Datenbank mit dokumentiertem Umschaltverfahren, regelmäßigen Tests und angemessener Überwachung zuverlässiger sein als eine erzwungene aktive-aktive Konfiguration.

Der Vorteil des aktive-passive Modells liegt in der geringeren betrieblichen Komplexität. Es gibt weniger Datenkonflikte durch paralleles Schreiben, die Fehlersuche kann einfacher sein, und das Betriebsteam hat klarer, welches System das primäre ist. Nachteilig ist, dass das Umschalten Zeit in Anspruch nehmen kann, insbesondere wenn manuelle Entscheidungen, DNS-Änderungen, Dienststarts oder Datenüberprüfungen erforderlich sind.

„Passiv“ darf nicht bedeuten, dass es vergessen wurde. Die Backup-Umgebung muss aktualisiert, überwacht und getestet werden. Ein nur auf dem Papier existierender Notfallplan scheitert in der Regel dann, wenn die Organisation ihn am dringendsten benötigt.

Wann bietet das aktive-aktive Modell echten Mehrwert?

Die aktive-aktive Konfiguration ist dort gerechtfertigt, wo die kontinuierliche Verfügbarkeit des Dienstes direkt mit Einnahmen, Produktion oder vertraglichen Verpflichtungen verbunden ist. Dazu gehören ein stark frequentierter Webshop, ein Kundenportal, ein kontinuierlich arbeitendes Logistiksystem oder eine Anwendung, deren Belastung zeitweise erheblich ansteigt.

Das Modell kann nicht nur Fehlertoleranz, sondern auch Kapazität bieten. Wenn die beiden aktiven Anwendungsserver den Verkehr verteilen, können die Ressourcen auch im Normalbetrieb genutzt werden. Bei Ausfall einer Instanz muss die verbleibende Kapazität jedoch weiterhin die kritische Last tragen können. Dies fehlt in vielen Plänen: Es gibt zwei Server, aber beide arbeiten bereits an einem normalen Tag mit einer Auslastung von 70-80 Prozent. Bei einem Ausfall bleibt das System technisch erreichbar, wird aber geschäftlich unbrauchbar langsam.

In einer aktive-aktive Umgebung ist die schwierigste Frage in der Regel die der Daten. Wenn zwei Standorte oder zwei Datenbankinstanzen gleichzeitig Änderungen empfangen, muss geregelt werden, welche Daten im Konfliktfall gültig sind. Dasselbe Lagerstück kann nicht unabhängig voneinander über zwei Kanäle verkauft werden. Das System benötigt einheitliche Geschäftsregeln, Transaktionsverwaltung und kontrollierte Synchronisation.

Daher kann und sollte nicht jede Anwendung auf aktive-aktive umgestellt werden. Oft ist die richtige Lösung, dass der Webdienst aktiv-aktiv ist, während die Datenbank oder ein kritischer Hintergrundprozess aktiv-passiv bleibt. Hohe Verfügbarkeit ist oft eine unterschiedliche Kombination von Schichten, nicht ein einziges Etikett.

Das Umschalten funktioniert nur, wenn es regelmäßig geübt wird

Die meisten Risiken treten nicht im Architekturdiagramm, sondern im Betrieb auf. Wer ist berechtigt, das Umschalten zu initiieren? Wie erkennt man, dass ein echter Fehler aufgetreten ist und nicht nur eine vorübergehende Verlangsamung? Wie wird überprüft, ob das sekundäre System wirklich auf dem neuesten Stand ist? Wer informiert die Benutzer, wenn der Dienst nur teilweise verfügbar ist?

Besondere Aufmerksamkeit erfordert die Split-Brain-Situation. Diese tritt auf, wenn zwei Systeminstanzen sich gegenseitig als fehlerhaft wahrnehmen und beide als primär zu arbeiten beginnen. Wenn beide in dieselben Geschäftsdaten schreiben können, kann die Dateninkonsistenz schnell zu einem ernsthaften Problem werden. Ohne geeignete Quorum-Mechanismen, Netzwerkkonfiguration und Datenbankstrategie kann die Redundanz selbst zur Fehlerquelle werden.

Auch geplante Wartungen müssen berücksichtigt werden. Ein gutes Verfügbarkeitsmodell ist nicht nur bei unerwarteten Ausfällen wertvoll. Auch dann, wenn Sicherheitsupdates, Hardwareaustausch oder Versionswechsel erforderlich sind. Wenn jede Änderung nächtliche Ausfallzeiten und manuelle Eingriffe erfordert, bleibt das langfristige Betriebsrisiko des Systems hoch.

Die richtige Entscheidung beginnt mit dem Prozess

Ein Unternehmen benötigt keine aktive-aktive Lösung, nur weil große Technologieunternehmen sie verwenden. Und es sollte keine aktive-passive Konfiguration wählen, nur weil sie günstiger erscheint. Die Entscheidung sollte davon geleitet werden, wie Informationen vom Auftrag bis zur Erfüllung, von der Produktionsanweisung bis zum Fertigprodukt oder von der Kundenanfrage bis zur Rechnung fließen.

Vor der Systemplanung müssen die Abhängigkeiten aufgedeckt werden: Aus welcher Anwendung stammen die Daten, wo erfolgt die manuelle Dateneingabe, welches System ist die einzige verlässliche Quelle und wo stockt die Arbeit bei einem Ausfall. Im CGAT-Ansatz ist die technologische Architektur eine Antwort auf diese betrieblichen Fragen, keine eigenständige Produktliste.

Das beste Design ist nicht unbedingt das komplizierteste. Das gute System ist eines, dessen Ausfallverhalten bekannt ist, dessen Umschaltung überprüft ist, dessen Daten geschützt sind und das vom eigenen Team oder einem beauftragten Partner langfristig sicher betrieben werden kann. Wenn dies vor dem nächsten geplanten Ausfall oder unerwarteten Fehler nicht eindeutig gesagt werden kann, dann wird nicht ein weiterer Server, sondern ein klarerer Betriebsplan benötigt.