Session Replication
Sitzungen zwischen Instanzen kopieren
Die Idee und ihr Nutzen
Ein Kunde füllt im Schadenportal seiner Versicherung ein Formular in mehreren Schritten aus. Jeder abgeschickte Schritt geht an Portalserver A, einen der Server, auf denen das Schadenportal läuft, und Portalserver A speichert die Angaben in der Sitzung des Kunden. Eine Sitzung ist ein Speicherbereich auf dem Server, in dem der Server für einen angemeldeten Nutzer Zwischenstände aufbewahrt. Damit die Angaben einen Ausfall von Portalserver A überstehen, überträgt Portalserver A die Sitzungsdaten fortlaufend an Portalserver B, einen zweiten Server, auf dem dasselbe Schadenportal läuft. Fällt Portalserver A aus, setzt Portalserver B die Sitzung aus seiner Kopie fort: Der Kunde bleibt angemeldet und findet die übertragenen Angaben wieder. Dieses Kopieren von Sitzungen heißt Session Replication, auf Deutsch Sitzungsreplikation.
Wie funktioniert es?
Der Kunde gibt im Schadenformular Schadendatum und Adresse ein und schickt beide Schritte ab. Der Lastverteiler, ein Programm, das eingehende Anfragen auf die Portalserver verteilt und Ausfälle erkennt, leitet die Angaben an Portalserver A weiter. Portalserver A speichert die Angaben in der Sitzung und kopiert die Sitzung mit Anmeldung, Schadendatum und Adresse zu Portalserver B. Im nächsten Schritt gibt der Kunde den geschätzten Schadenbetrag ein und schickt ihn ab. Portalserver A nimmt den Betrag an, ohne auf Portalserver B zu warten, und fällt aus, bevor der Betrag bei Portalserver B ankommt. Der Kunde macht im Formular weiter. Der Lastverteiler erkennt den Ausfall von Portalserver A und schickt die nächste Anfrage des Kunden an Portalserver B. Portalserver B findet die Sitzung in seiner Kopie: Der Kunde bleibt angemeldet, und das Formular zeigt Schadendatum und Adresse wieder an. Den Schadenbetrag kennt Portalserver B nicht, und der Kunde muss ihn erneut eingeben.
Portalserver A führt die Sitzung in seinem Arbeitsspeicher, dessen Inhalt bei einem Ausfall des Servers verloren geht. Zur Sitzung gehören der Anmeldestatus und die vorläufigen Formularangaben. Jede Änderung an der Sitzung überträgt Portalserver A an Portalserver B, der eine Kopie der Sitzung bereithält. Laufen mehr als zwei Portalserver, kann ein Portalserver auch an mehrere andere kopieren. Das Team, das das Schadenportal betreibt, legt fest, ob Portalserver A beim Kopieren auf eine Bestätigung von Portalserver B wartet. Wartet Portalserver A nicht, heißt das Kopieren asynchron: Die Antwort an den Kunden geht sofort hinaus, aber die jüngste Änderung kann beim Ausfall fehlen. Wartet Portalserver A auf die Bestätigung, heißt das Kopieren synchron: Portalserver A bestätigt dem Kunden eine Angabe erst, wenn Portalserver B sie hat. Dann geht keine bestätigte Angabe verloren, aber jede Antwort an den Kunden dauert länger.
Die Sitzungsreplikation erfasst nur, was den Server erreicht hat. Angaben, die der Kunde in seinen Browser getippt, aber noch nicht abgeschickt hat, kann kein Server kopieren.
Sitzungsreplikation: Server B übernimmt die Sitzung, der letzte Betrag fehlt
Wann ist es sinnvoll und wann nicht?
Sitzungsreplikation lohnt sich
- Eine bestehende Anwendung hält ihre Sitzungen im Arbeitsspeicher des Servers, und diese Sitzungen sollen einen Serverausfall überstehen. Ohne Kopie hat Portalserver B nach einem Ausfall keine Daten über den Kunden. Der Kunde muss sich womöglich neu anmelden und alle Formularangaben noch einmal eingeben. Bei einem langen Formular bricht mancher Kunde die Schadenmeldung dann ab.
- Ein gemeinsamer Sitzungsspeicher, in dem alle Portalserver die Sitzungen lesen und schreiben, kommt nicht in Frage, etwa weil die Versicherung dafür keinen weiteren ausfallsicheren Dienst betreiben will. Ohne Sitzungsreplikation liegt jede Sitzung dann nur auf einem einzigen Portalserver, und ein Ausfall dieses Servers löscht sie. Für die Sitzungsreplikation braucht die Versicherung keinen weiteren Dienst, weil die Portalserver die Sitzungen untereinander kopieren.
- Die Anwendung läuft auf wenigen Servern. Das Schadenportal läuft auf zwei Portalservern. Mit jedem weiteren Server, der alle Sitzungen erhält, wachsen Netzverkehr und Speicherbedarf für das Kopieren. Bei zwei Portalservern geht jede Änderung an einer Sitzung nur einmal über das Netz.
Sitzungsreplikation ist nicht das Richtige
- Die Anwendung wird neu gebaut oder läuft auf vielen Servern. Bei einer neuen Anwendung kann das Team von Anfang an festlegen, dass die Sitzungen nicht im Arbeitsspeicher der Portalserver liegen. Bei vielen Servern wüchse der Aufwand für das Kopieren mit jedem weiteren Server. Dann baut das Team die Portalserver so, dass sie selbst keine Sitzungsdaten halten, wie es Stateless Services beschreibt. Die Sitzungen liegen dann in einem gemeinsamen Sitzungsspeicher, zum Beispiel einem Schlüssel-Wert-Speicher, der zu jeder Sitzungskennung die Sitzungsdaten ablegt. Jeder Portalserver kann so jede Anfrage bearbeiten, und kein Portalserver muss Sitzungen an andere kopieren. Netzverkehr und Arbeitsspeicher für das Kopieren wachsen deshalb nicht mit jedem weiteren Server. Der gemeinsame Sitzungsspeicher ist allerdings ein weiterer Dienst, der selbst ausfallsicher betrieben werden muss.
- Keine abgeschickte Angabe darf verloren gehen, auch wenn beide Portalserver ausfallen. Mit Sitzungsreplikation liegen die Angaben nur im Arbeitsspeicher der Portalserver, und fallen beide aus, sind die Angaben verloren. Dann speichert das Schadenportal jede abgeschickte Angabe sofort als Entwurf der Schadenmeldung in einer Datenbank. Jeder Portalserver liest den Entwurf dort, und kein Portalserver muss Sitzungsdaten an einen anderen kopieren.
Nachteile und typische Fehler
Das Kopieren braucht Netzverkehr und auf jedem Server, der eine Kopie hält, zusätzlichen Arbeitsspeicher; beides wächst mit der Zahl der Server. Alles, was in der Sitzung liegt, muss sich in eine übertragbare Form umwandeln lassen, also in Daten wie Schadendatum und Adresse, die Portalserver A über das Netz an Portalserver B schicken kann. Sitzungsdaten enthalten oft vertrauliche Angaben, etwa Adressen oder Anmeldedaten. Die Kopien auf Portalserver B brauchen deshalb denselben Schutz wie die Sitzungen auf Portalserver A und müssen ebenso rechtzeitig gelöscht werden.
Typische Fehler und woran man sie erkennt:
- Verlorene letzte Eingabe: Portalserver A kopiert asynchron und fällt aus, bevor die jüngste Änderung bei Portalserver B angekommen ist. Erkennbar ist das an Kunden, die nach einem Serverausfall die zuletzt abgeschickte Angabe erneut eingeben müssen.
- Nicht übertragbarer Inhalt: Die Anwendung legt in der Sitzung etwas ab, das sich nicht in eine übertragbare Form umwandeln lässt, etwa eine geöffnete Verbindung zur Datenbank. Portalserver A kann diesen Teil nicht an Portalserver B schicken, und nach der Übernahme fehlt er Portalserver B. Erkennbar ist das an Fehlermeldungen beim Kopieren oder an Sitzungen, denen nach der Übernahme einzelne Angaben fehlen.
- Nicht gelöschte Kopie: Der Kunde meldet sich ab, und Portalserver A löscht seine Sitzung. Die Löschung überträgt Portalserver A aber nicht an Portalserver B. Die Kopie mit der Adresse des Kunden bleibt auf Portalserver B liegen, und jeder, der auf Portalserver B zugreifen darf, kann die Adresse noch lesen. Erkennbar ist das an Sitzungen auf Portalserver B, die nach der Abmeldung des Kunden noch vorhanden sind.
- Wachsender Kopieraufwand: Das Team erweitert das Schadenportal auf vier Portalserver, und jeder Portalserver kopiert alle seine Sitzungen an die drei anderen. Jeder Portalserver hält dann alle Sitzungen des Schadenportals im Arbeitsspeicher, und jede Änderung an einer Sitzung geht dreimal über das Netz statt einmal wie bei zwei Portalservern. Erkennbar ist das an wachsendem Netzverkehr zwischen den Portalservern und knappem Arbeitsspeicher, sobald ein weiterer Server dazukommt.
Weiterführend
Verwandte Ansätze
- Sticky Sessions: Der Lastverteiler schickt alle Anfragen eines Kunden an denselben Portalserver, der die Sitzung im Arbeitsspeicher hält. Sitzungsreplikation ergänzt das, damit ein anderer Server übernehmen kann, wenn dieser Portalserver ausfällt.
- Load Balancing: verteilt Anfragen auf mehrere Server und lässt einen gestörten Server aus. Dass der Lastverteiler den Ausfall von Portalserver A erkennt, ist die Voraussetzung dafür, dass die nächste Anfrage bei Portalserver B ankommt.
- Redundancy and Failover: hält einen Ersatz bereit und schaltet bei einem Ausfall auf ihn um. Mit Sitzungsreplikation hält der Ersatzserver auch eine Kopie der Sitzungen der Kunden.
- Replication: beschreibt das Kopieren von Daten auf weitere Rechner allgemein, mit derselben Abwägung zwischen Warten auf die Bestätigung der Kopie und schneller Antwort.
Quellen
- Apache Tomcat: Clustering/Session Replication How-To: offizielle Dokumentation eines Webservers für Java, die das Kopieren an alle Server und an einen einzelnen Ersatzserver, die Wahl zwischen synchronem und asynchronem Kopieren, die Grenzen bei vielen Servern und das Verhalten bei einem Ausfall beschreibt.
- Adam Wiggins: The Twelve-Factor App, VI. Processes: begründet die Alternative, Server ohne eigene Sitzungsdaten zu bauen und Sitzungen in einem gemeinsamen Speicher mit Ablaufzeit zu halten.