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 entgegen, 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 die kritischen 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 stillstehen 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 aktives-aktives und aktives-passives Arbeiten?

Bei einer aktiven-aktiven Konfiguration arbeiten zwei oder mehr Systeminstanzen gleichzeitig. 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, normalerweise unbemerkt oder mit kurzer Unterbrechung.

Bei einer aktiven-passiven 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 aber 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 das aktive-aktive als die eindeutig bessere Lösung erscheinen: Zwei funktionierende Systeme sind besser als eines, das arbeitet, und eines, das wartet. Dies ist jedoch nur dann der Fall, 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 zu diagnostizierende Fehler verursachen.

Verfügbarkeit ist nicht gleichbedeutend mit mehreren Servern

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

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

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

Beginnen Sie an den kritischen Punkten des Prozesses

Es ist ratsam, zuerst zu klären, welche Prozesse wie viel Ausfallzeit tolerieren können. Ein mehrstündiger Ausfall eines internen Dokumentenarchivs kann unangenehm sein, aber handhabbar. Ein Produktionssteuerungssystem, ein Online-Zahlungsprozess oder eine Bestellverarbeitung kann bereits nach zehn Minuten zu direktem Umsatz- und Kundenvertrauensverlust führen.

Ebenso wichtig ist die Grenze des Datenverlusts. Wenn ein System mit Daten von vor einer Stunde wiederhergestellt werden kann, bedeutet das eine andere technische Lösung und Kosten als wenn nur wenige Sekunden Datenverlust zulässig sind. Diese Ebenen werden in der Regel mit RTO- und RPO-Zielwerten beschrieben. Das RTO gibt an, wie lange es dauern darf, bis der Dienst wiederhergestellt ist. Das RPO gibt an, wie viel 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 „hohe Verfügbarkeit“ im Plan steht, sondern beispielsweise, dass die Bestellverarbeitung maximal 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 effektive Wahl. Besonders dann, wenn die Zustandsverwaltung der Anwendung komplex ist, auf einem einzigen Datenbank-Schreiber 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 dokumentierten Umschaltverfahren, regelmäßigen Tests und angemessener Überwachung zuverlässiger sein als eine erzwungene aktive-aktive Konfiguration.

Der Vorteil des aktiven-passiven Modells ist die geringere betriebliche 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. Der Nachteil ist, dass das Umschalten Zeit in Anspruch nehmen kann, insbesondere wenn eine manuelle Entscheidung, DNS-Änderung, Dienststart oder Datenprüfung erforderlich ist.

„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, 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 dem Umsatz, der Produktion oder vertraglichen Verpflichtungen verbunden ist. Dies kann ein stark frequentierter Webshop, ein Kundenportal, ein kontinuierlich arbeitendes Logistiksystem oder eine Anwendung sein, deren Last periodisch stark ansteigt.

Das Modell bietet nicht nur Fehlertoleranz, sondern auch Kapazität. Wenn die beiden aktiven Anwendungsserver den Verkehr verteilen, können die Ressourcen auch im Normalbetrieb genutzt werden. Bei einem Ausfall 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 70-80 Prozent Auslastung. Bei einem Ausfall bleibt das System technisch erreichbar, wird jedoch geschäftlich unbrauchbar langsam.

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

Deshalb kann und sollte nicht jede Anwendung aktiv-aktiv gemacht 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? Woher weiß man, dass ein echter Fehler aufgetreten ist und nicht nur eine vorübergehende Verlangsamung? Wie wird überprüft, ob das sekundäre System wirklich aktuell ist? Wer informiert die Benutzer, wenn der Dienst teilweise verfügbar ist?

Besondere Aufmerksamkeit erfordert die Split-Brain-Situation. Dies 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 wird die Redundanz selbst zur Fehlerquelle.

Auch die geplante Wartung muss geprüft 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 einen nächtlichen Ausfall und manuelle Eingriffe erfordert, bleibt das langfristige Betriebsrisiko des Systems hoch.

Die richtige Entscheidung beginnt mit dem Prozess

Ein Unternehmen benötigt kein aktives-aktives System, nur weil große Technologieunternehmen es verwenden. Und es sollte sich nicht für eine aktive-passive Konfiguration entscheiden, nur weil sie günstiger erscheint. Die Entscheidung sollte davon geleitet werden, wie die Informationen vom Auftrag bis zur Erfüllung, von der Produktionsanweisung bis zum Fertigprodukt oder von der Kundenanforderung bis zur Rechnung fließen.

Vor der Systemplanung müssen die Abhängigkeiten aufgedeckt werden: Aus welcher Anwendung kommen 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 dasjenige, dessen Ausfallverhalten bekannt ist, dessen Umschaltung kontrolliert ist, dessen Daten geschützt sind und das vom eigenen Team oder einem benannten 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 benötigt, sondern ein klarerer Betriebsplan.