Zusammenfassung

  • SCTP kann innerhalb einer Assoziation einen anderen erreichbaren Pfad zum gleichen Endpoint verwenden. RSerPool kann dagegen einen anderen Pool Element als Kandidaten liefern. Pfadkontinuität und serverübergreifende Sitzungskontinuität benötigen unterschiedliche Nachweise.
  • RFC 5351 sagt ausdrücklich, dass Failover mit Anwendungszustand oder Transaktionsstatus ohne anwendungsspezifisches Wissen nicht allgemein definiert werden kann. Eine neue Adresse beweist weder den Commit-Stand der alten Operation noch sichere Wiederholung.
  • Eine belastbare Kette trennt Handle-Geltung, Registrierung, Auswahl, Transporterreichbarkeit, Anwendungsidentität, Commit-Grenze, übergebenen Zustand, Idempotenz, dauerhafte Ausführung und beobachtetes Ergebnis.

Zwei Wechsel trugen denselben Namen

SCTP wurde für mehrere für RSerPool wichtige Beziehungen verwendet. Multihoming erlaubt einem Endpoint, mehrere Transportadressen zu besitzen. Pfadüberwachung und Heartbeats können eine unbrauchbare Adresse erkennen und Daten über einen anderen Pfad zum gleichen Peer senden.

Bei diesem Wechsel kann die Assoziation bestehen bleiben. Der entfernte Prozess, sein Speicher und seine Anwendungssitzung ändern sich nicht notwendigerweise. Die Kontinuität liegt auf der Transport- und Pfadebene.

RSerPool adressiert eine andere Lage. Ein Pool User löst einen Handle auf und erhält einen oder mehrere Pool Elements. Fällt der verwendete Server aus, kann er den nächsten Kandidaten anfordern. Der Peer kann nun ein anderer Prozess mit anderem Speicher und anderem Sicherheitskontext sein.

Wer beide Vorgänge als einen grünen „Failover“-Zähler darstellt, verliert genau die Grenze, an der Zustand verloren gehen kann. Monitoring muss Pfadwechsel, Assoziationsverlust, Element-Neuwahl und Zustandswiederherstellung getrennt benennen.

Ein Handle bezeichnete einen Kandidatenraum

Der Pool Handle ist in RFC 5351 eine eindeutige Bytefolge in einem flachen Handlespace mit begrenztem Betriebsbereich. Seine Administration war nicht Gegenstand der Protokolldokumente. RFC 3237 verlangt zusätzliche Mechanismen für die Verbindung verschiedener Namensräume.

Eine erfolgreiche Auflösung beweist deshalb, dass der befragte Bereich den Handle kennt. Sie beweist nicht, dass ein anderes Gebiet dieselbe Bedeutung, dieselben Betreiber oder dieselbe Vertrauenswurzel verwendet.

Auch das Anwendungsprotokoll zwischen Pool User und Pool Element bleibt anwendungsspezifisch. RSerPool setzt passende Konfiguration voraus, verhandelt aber nicht automatisch Version, Funktionsumfang oder Zustandsformat.

Der Handle ist ein nützlicher Zeiger auf einen Kandidatenraum. Er ist kein globales Identitätszertifikat und keine Garantie, dass jeder Kandidat die konkrete Sitzung fortsetzen kann.

ENRP synchronisierte Mitgliedschaft, nicht Prozessspeicher

ENRP-Server tauschen Änderungen am Handlespace aus, senden Presence, vergleichen Prüfsummen und synchronisieren inkonsistente Teilmengen. Beim Ausfall eines Servers handeln die übrigen die Übernahme seiner Home-ENRP-Rolle aus.

Damit wird der Registrierungsdienst fehlertoleranter. Synchronisiert werden Pool-Handles und Elementinformationen. Arbeitsspeicher, Datenbank-Commit, Nutzerkontext und Geschäftsstatus gehören nicht automatisch dazu.

Zeit bleibt sichtbar. Ein Element kann unmittelbar nach einem Keep-Alive ausfallen. Eine Abmeldung kann noch propagieren. RFC 5352 erlaubt gecachte Auflösung mit einem Stale-Timer; ein noch nicht altes Ergebnis wird gewöhnlich verwendet.

„Nicht stale“ bedeutet innerhalb einer Altersregel, nicht aktuell erreichbar. Selbst eine neue Anfrage kann den Ausfall nach der Antwort nicht verhindern. Das Protokoll begrenzt Unsicherheit, es beseitigt sie nicht.

Auswahlpolitik ordnete, sie prognostizierte nicht

RFC 5356 definiert Round Robin, gewichtete Varianten, Zufall, Priorität und lastabhängige Verfahren. Diese Regeln machen Auswahl nachvollziehbar.

Die Bedeutung von Load bleibt anwendungsabhängig und außerhalb von RSerPool. Elemente desselben Pools müssen dieselbe Definition verwenden, doch diese kann Nutzerzahl, CPU oder Speicher abbilden. Keine Definition muss Replikationsrückstand, Sperren oder Berechtigungen erfassen.

Der am wenigsten belastete Kandidat kann daher der falsche Wiederherstellungsort sein. Ein Prioritätswert kann Kosten oder Standort ausdrücken, ohne Zustandsfrische zu messen.

Für eine spätere Prüfung müssen Politik, Messdefinition, Zeitpunkt, Kandidatenmenge und Werte erhalten bleiben. Nur die Siegeradresse zu speichern, verwandelt eine bedingte Entscheidung in eine scheinbar objektive Wahrheit.

Der nächste Server kannte den alten Commit nicht

RFC 5351 zeigt eine einfache Nutzung: statt fester primärer und sekundärer Hostnamen fragt die Anwendung nach einem primären Server und nach einem Fehler nach dem nächsten. Dabei meldet sie den vorherigen Kandidaten als ausgefallen.

Der Verbindungsabbruch sagt nicht, ob die alte Anfrage den Server erreichte. Sie kann vor Verarbeitung verloren gegangen, vor Commit abgebrochen, nach Commit beantwortet oder nach Commit ohne zugestellte Antwort geblieben sein.

Eine Wiederholung am neuen Element ist je nach Fall notwendig oder schädlich. Der Pool-Layer kennt die fachliche Commit-Grenze nicht. RFC 5351 nennt diese Grenze ausdrücklich: zustands- oder transaktionsabhängiger Failover benötigt Anwendungswissen.

Ein belastbarer Dienst braucht Operations-ID, Commit-Receipt, Deduplizierung und gegebenenfalls Kompensation. GETNEXTSERVER liefert den Ort des nächsten Versuchs, nicht dessen Bedeutung.

Das Cookie war nicht der SCTP-State-Cookie

RSerPool bietet ein optionales Anwendungszustands-Cookie. Das Pool Element sendet es, der User bewahrt das zuletzt empfangene auf und gibt es beim Wechsel an das neue Element. Für den User bleibt es undurchsichtig.

SCTP besitzt ebenfalls einen State-Cookie-Begriff für den Aufbau einer Assoziation. Die gleiche Alltagssprache darf die beiden Mechanismen nicht verschmelzen. Der SCTP-Cookie schützt und etabliert Transportzustand; der RSerPool-Cookie kann anwendungsspezifische Information tragen.

RFC 5351 empfiehlt Signatur und Prüfung des RSerPool-Cookies; RFC 5352 lässt Details offen. Eine gültige Signatur beweist Herkunft und Integrität unter einem Schlüsselmodell, nicht Aktualität, Vollständigkeit oder Kompatibilität.

Das zuletzt empfangene Cookie kann vor dem letzten Commit entstanden sein. Der neue Server kann eine andere Version verstehen. Mitgliedschaft im Pool beweist nicht Cookie-Unterstützung, da die entsprechenden Rollen nicht überall gleich verpflichtend sind.

Eine Business Card war eine lokale Empfehlung

Ein Pool Element kann einen anderen Kandidaten empfehlen, etwa wegen Last oder weil dieser angeblich den aktuelleren Zustand besitzt. Das kann den Suchraum verbessern.

Die Empfehlung ist dennoch eine Aussage eines Teilnehmers. Der Zielserver kann später ausfallen, seine Replikation kann hinterherhinken, und „next best“ kann nach einem anderen Kriterium bestimmt worden sein als die aktuelle Operation benötigt.

Der Empfänger muss Erreichbarkeit, Identität, Anwendungsfähigkeit und Zustandsversion erneut prüfen. Die Karte ordnet Kandidaten; sie zertifiziert keine Zustandsäquivalenz.

Provenienz sollte sichtbar bleiben: wer empfahl wen, wann und warum. Ohne diese Angaben wird Beratung zu einer Autorität, die das Verfahren nicht trägt.

Abmeldung und laufende Arbeit folgten verschiedenen Uhren

RFC 3237 verlangt, dass ein abgemeldetes Pool Element bestehende Nutzer weiter bedienen kann, während neue Verbindungen woanders landen. Das ermöglicht geordnetes Draining.

Ein Element, das im Handlespace nicht mehr auswählbar ist, kann also weiterhin Arbeit halten. Orchestrierung darf es nicht allein aufgrund der Abmeldung beenden.

Umgekehrt kann ein registriertes Element noch nicht bereit sein. Daten, Caches, Schlüssel oder Richtlinien können fehlen. Registrierung ist Auswahlberechtigung; Application Readiness ist ein eigener Nachweis.

Sicherer Betrieb braucht zwei Zähler: keine neuen Zuweisungen und keine alten Sitzungen. Erst beide zusammen erlauben das Stoppen.

Pool-Sicherheit und Geschäftsautorisierung blieben getrennt

RFC 5355 beschreibt gefälschte Registrierungen, bösartige ENRP-Server, manipulierte Auflösung, Replay und DoS. Gegenseitige Authentisierung und Autorisierung sollen die Infrastruktur schützen, im Modell eines administrativen Bereichs mit TLS und PSK.

Diese Kontrollen entscheiden, wer am Pool teilnehmen darf. Sie entscheiden nicht, ob ein Endnutzer eine konkrete Geschäftsoperation am Ersatzserver ausführen darf.

Beim Wechsel muss die Anwendung den Principal und dessen Rechte prüfen. Der alte Kontext kann abgelaufen oder servergebunden sein. RFC 3237 lässt das Teilen von Sicherheitszustand außerhalb des RSerPool-Umfangs.

Infrastrukturmitgliedschaft, Nutzerrecht und Erlaubnis zum Zustandstransfer sind drei Entscheidungen. Verfügbarkeit darf sie nicht abkürzen.

Zehn Belege statt eines Failover-Symbols

Der Handle gilt im richtigen Bereich. Das Element ist in der konsultierten Sicht registriert. Die bekannte Politik wählt es. Der Transport erreicht es. Anwendung und Principal werden akzeptiert. Der Status der alten Operation ist bekannt. Übertragener Zustand ist authentisch, frisch, vollständig und kompatibel. Wiederholung ist sicher. Die Wirkung ist dauerhaft. Eine unabhängige Beobachtung bestätigt das Ergebnis.

SCTP kann zum Erreichbarkeitsbeleg beitragen. ENRP kann Registrierung und Auswahl belegen. Die Anwendung besitzt Commit und Replay. Kein Beleg ersetzt den nächsten.

IANA führt Nachrichtentypen, Parameter, Fehlerursachen und Policy-Nummern. Das ist interoperable Symbolkoordination, kein Einsatz- oder Gesundheitsnachweis.

Lu Hengs Texte über minimale Spezifikation und Realitätsebenen dienen als offengelegte Analyse: ein gemeinsamer Handle ist kleiner als lokale Ausführungsgewalt, und symbolischer Zustand ist nicht physisches Ergebnis. Die RFCs und IANA tragen die Fakten.