RSerPool

Reliable Server Pooling (RSerPool) ist ein Protokollrahmenwerk zur Verwaltung von Server-Pools sowie zur Durchführung von logischen Sitzungen (Sessions) von Clients mit solchen Pools. Als Teil der Sitzungsverwaltung übernimmt RSerPool dabei insbesondere die Auswahl eines Servers aus dem Pool (Lastverteilung, Lastbalancierung) sowie bei Ausfall des Servers die Umschaltung (Failover) zu einem Ersatzserver im Pool. RSerPool wurde durch die IETF RSerPool-Arbeitsgruppe entwickelt und im September 2008 in RFC 5351 bis RFC 5356 als Internet-Standard festgeschrieben.

Grundidee von RSerPool

Bei bestimmten Client/Server-Anwendungen kann sehr hoher Schaden durch Ausfall des Servers entstehen. Im Falle von e-Commerce suchen sich z. B. die potentiellen Kunden einfach einen anderen Anbieter. Um den kritischen Dienst auch im Falle eines Serverausfalls weiter erbringen zu können, ist eine Redundanz der Server notwendig. Das heißt, es gibt mindestens zwei Server; fällt nun einer aus, so übernimmt ein anderer einfach dessen Aufgaben.

Ziel von Reliable Server Pooling, das sich zurzeit in der Standardisierung durch die IETF RSerPool-Arbeitsgruppe befindet, ist ein vereinheitlichtes Verfahren zur Verwaltung von Server-Pools (Server können z. B. dynamisch zum Pool hinzugefügt oder wieder daraus entfernt werden) und zum Zugriff von Clients auf die Pools. Aus Sicht der Client-Applikation ist ein Server-Pool ein logischer Server, zu welchem eine Sitzung (engl. Session) aufgebaut wird. RSerPool kümmert sich dabei um Serverauswahl (insbesondere auch Lastverteilung), Verbindungsaufbau, Überwachung der Verbindung und Neuauswahl eines Servers im Fehlerfall.

Nähere Beschreibung von RSerPool

Reliable Server Pooling (RSerPool) ist ein Protokollrahmenwerk für die Verwaltung von und den Zugriff auf Server Pools. Es befindet sich zurzeit in der Standardisierung durch die IETF RSerPool Arbeitsgruppe.

In der Terminologie von RSerPool werden Server als Pool Elemente (PE) bezeichnet. Die Menge aller PEs, die den gleichen Dienst anbieten, bilden einen Pool. Ein PE wird innerhalb eines Pools durch einen 32-Bit Pool Element Identifier (PE ID) identifiziert. Die PE ID wird zufällig bestimmt wenn sich ein PE zu einem Pool registriert. Die Gesamtheit aller Pools wird Handlespace genannt. In früheren Publikationen kann die Bezeichnung auch Namespace lauten. Die Umbenennung erfolgte, um Verwechselungen mit dem Domain Name System zu vermeiden. Jeder Pool in einem Handlespace wird durch einen eindeutigen Pool Handle (PH) identifiziert, welcher ein zufällig ausgewählter Byte-Vektor ist. Normalerweise handelt es sich dabei um einen Namen in ASCII- oder Unicode-Kodierung, wie beispielsweise "DownloadPool" oder "WebServerPool".

Jeder Handlespace besitzt einen begrenzten Einsatzbereich (Operation Scope, z. B. eine Organisation oder Firma). Es ist ausdrücklich kein erstrebenswertes Ziel von RSerPool, alle weltweiten Pools innerhalb eines einzigen Handlespace zu verwalten. Wegen der lokalen Bedeutung des Einsatzbereiches ist es möglich, den Handlespace "flach" zu halten. Dies bedeutet, dass es für PHs keine Hierarchie gibt – im Gegensatz zum Domain Name System mit seinen Toplevel- und Sub-Domains. Dieser Gegensatz führt zu einer signifikanten Vereinfachung der Verwaltung des Handlespaces.

Innerhalb eines Einsatzbereiches wird ein Handlespace von redundant vorhandenen Pool Registrars (PR) verwaltet. PRs werden auch als ENRP Server oder Name Server (NS) bezeichnet. Ihre Redundanz ist notwendig, damit ein einzelner PR nicht zum Single Point of Failure (SPoF) werden kann. Jeder PR aus einem Einsatzbereich wird mit seiner Registrar ID (PR ID), einer 32-Bit-Zufallszahl, identifiziert. Es ist dabei nicht notwendig eine Eindeutigkeit von PR IDs zu gewährleisten. Ein PR enthält eine komplette Kopie des Handlespaces eines Einsatzbereiches. Die PRs eines Einsatzbereiches gleichen ihre Sicht auf die Handlespace durch das Endpoint Handlespace Redundancy Protocol (ENRP) ab. Ältere Versionen dieses Protokolles haben die Bezeichnung Endpoint Namespace Redundancy Protokoll; diese Bezeichnung wurde abgelöst um Verwechselungen mit DNS zu vermeiden. Wegen der Synchronisation der Handlespace durch ENRP ist die Funktionalität der PRs innerhalb eines Einsatzbereiches identisch. Dies bedeutet, dass die Aufgaben eines nicht mehr erreichbaren PRs durch jeden anderen PR des Einsatzbereiches übernommen werden können.

Durch die Benutzung des Aggregate Server Access Protocol (ASAP) kann sich ein PE zu einem Pool hinzufügen oder sich aus seinem Pool wieder abmelden. Dazu kann ein beliebiger PR des Einsatzbereiches verwendet werden. Für den Fall einer erfolgreichen Registrierung wird der vom PE ausgesuchte PR zum Home-PR (PR-H) des PEs. Der PR-H informiert nicht nur die anderen PRs über die erfolgte Registrierung oder Deregistrierung seiner PEs, sondern er überwacht auch die Erreichbarkeit seiner PEs durch Keep-Alive-Nachrichten. Eine Keep-Alive Nachricht von seinem PR-H muss ein PE innerhalb einer bestimmten Zeitspanne bestätigen. Antwortet das PE nicht innerhalb eines vorgegebenen Zeitrahmens, so wird es als nicht mehr erreichbar betrachtet und umgehend aus dem Handlespace entfernt. Weiterhin wird von einem PE erwartet, dass es sich regelmäßig immer wieder re-registriert. Bei einer solchen Re-Registrierung ist es für ein PE zudem möglich, die Liste seiner Transportadressen und weitere Informationen zu aktualisieren.

Ein Client eines Pools wird in der Terminologie von RSerPool als Pool User (PU) bezeichnet. Um den Dienst des Pools zu nutzen, fragt er bei einem beliebigen PR des Einsatzbereiches um die Auflösung des Pool-PHs in eine Liste von PE-Identitäten an. Dieser Vorgang wird als Handle Resolution bezeichnet. Existiert der Pool, so wählt der PR anhand der für den Pool festgelegten Auswahlregel (Pool Member Selection Policy, auch abgekürzt als Pool Policy bezeichnet) die gewünschte Liste von PE-Identitäten aus.

Mögliche Pool Policys sind beispielsweise Zufall (Random), Reihum (Round Robin) oder PEs mit der geringsten Auslastung (Least Used). Während in den ersten beiden Fällen keine Zusatzinformationen über die PEs notwendig sind (Nicht-Adaptive Policys), ist für die Least-Used-Auswahl eine aktuelle Lastinformation der PEs erforderlich (Adaptive Policy). Dies erfordert zwar regelmäßige Updates der Zustandsdaten (über eine Re-Registrierung), kann jedoch unter Umständen auch eine erheblich besserer Lastverteilung im Pool erreichen.

Nach Erhalt einer Liste von PE Identitäten vom PR kann ein PU diese PE-Identitäten in seinen lokalen Cache schreiben. Dieser Speicher wird auch als PU-seitiger Cache (engl. PU-Side Cache) bezeichnet. Aus diesem Cache wählt der PU nun wiederum anhand der Pool Policy genau ein PE aus. Zu diesem ausgewählten PE baut er dann eine Verbindung mit dem Protokoll der Anwendung auf - z. B. HTTP über SCTP oder TCP im Falle eines Web-Servers - und nutzt dann die eigentliche Anwendung des Servers. Schlägt der Verbindungsaufbau fehl oder bricht die Verbindung während der Dienstnutzung ab, so wird ein neues PE gewählt. Ist die Information im Cache noch nicht veraltet, so kann zur Auswahl direkt der Cache verwendet werden. Ansonsten ist eine erneute Anfrage zur Handle Resolution bei einem PR notwendig und der komplette Vorgang wiederholt sich. Ist schließlich eine Verbindung zu einem neuen PE aufgebaut, so muss der Status der unterbrochenden Sitzung auf dem neuen PE wiederhergestellt werden. Die hierzu durchzuführende Prozedur wird als Failover-Prozedur bezeichnet und ist applikationsspezifisch. Im Falle eines FTP-Download muss z. B. dem neuen PE der Dateiname sowie die zuletzt empfangende Dateiposition mitgeteilt werden. Damit ist das neue PE dann in der Lage, den Download an der Unterbrechungsstelle fortzusetzen.

Um PEs und PUs das automatische Finden von PRs zu ermöglichen, können PRs über UDP via IP Multicast Ankündigungen (sogenannte Announces) verschicken. Durch Mithören der Announce-Nachrichten in einer festgelegten Multicast-Gruppe sind PEs und PUs dann in der Lage, eine Liste der aktuell in ihrer Multicast-Domäne verfügbaren PRs zu lernen. Durch die Verwendung von Multicast im Gegensatz zu Broadcast funktioniert der Mechanismus auch über Routergrenzen hinweg. Im Fall eines geswitchten Ethernets wird zudem erreicht, dass die Multicast-Nachrichten nur an diejenigen Ports weitergeleitet werden, über die auch wirklich daran interessierte Geräte angeschlossen sind. Ist Multicast nicht verfügbar, müssen PR-Adressen natürlich statisch konfiguriert werden.

Implementierungen

Folgende Implementierungen von RSerPool sind zurzeit bekannt:

• RSPLIB Project der Universität Duisburg-Essen
• Motorola
• Cisco
• Fachhochschule Münster

Standardisierungsdokumente

RFCs

• RFC 3237 - Requirements for Reliable Server Pooling
• RFC 5351 - An Overview of Reliable Server Pooling Protocols
• RFC 5352 - Aggregate Server Access Protocol (ASAP)
• RFC 5353 - Endpoint Handlespace Redundancy Protocol (ENRP)
• RFC 5354 - Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
• RFC 5355 - Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
• RFC 5356 - Reliable Server Pooling Policies

Working Group Drafts

• Reliable Server Pooling: Management Information Base using SMIv2
• Architecture for Reliable Server Pooling
• Comparison of Protocols for Reliable Server Pooling
• TCP Mapping for Reliable Server Pooling Enhanced Mode
• Services Provided By Reliable Server Pooling
• Reliable Server Pooling Sockets API Extensions

Weitere Drafts

• Handle Resolution Option for ASAP
• Least-Used Policy for Reliable Server Pooling
• Reliable Server Pooling Applicability for IP Flow Information Exchange
• Applicability of Reliable Server Pooling for Real-Time Distributed Computing
• Reliable Server Pooling (RSerPool) Bakeoff Scoring
• Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility

Weblinks

• Thomas Dreibholz's Reliable Server Pooling (RSerPool) Page
• IETF RSerPool Working Group