Reliable Server Pooling

Reliable Server Pooling ( RSerPool ) is a protocol framework for managing server pools as well as for the implementation of logical sessions ( Sessions ) from clients using such a pool. As part of the session management RSerPool assumes particular to select a server from the pool (load distribution, load balancing ) as well as at the server failure, the switchover ( failover ) to a spare server in the pool. RSerPool was developed by the IETF RSerPool Working Group and recognized in September 2008 RFC 5351 RFC 5356 to as an Internet standard.

Basic idea of RSerPool

For certain client / server applications can result in substantial damage caused by failure of the server. In the case of e -commerce, for example, the potential customers always find another provider. In order to provide the critical service in the event of a server failure, further, a redundancy of the server is necessary. That is, there are at least two servers; now falls from a so another simply takes its responsibilities.

The aim of Reliable Server Pooling, which is currently in the standardization by the IETF RSerPool Working Group, a unified method of managing server pools is (server can be dynamically added, for example, to the pool or back away from it ) and access from clients on the pools. From the perspective of the client application, a server pool is a logical server to which a session (English session) is established. RSerPool it takes care of server selection (in particular load balancing), connection establishment, connection monitoring and reselection of a server error occurs.

Further description of RSerPool

Reliable Server Pooling ( RSerPool ) is a protocol framework for the management of and access to server pools. It is currently being standardized by the IETF RSerPool Working Group.

In the terminology of RSerPool server as a pool elements (PE ), respectively. The set of all PEs that offer the same service, form a pool. A PE is identified within a pool by a 32- bit identifier pool element (PE ID). The PE ID is determined randomly when a PE registered to a pool. The totality of all pools is called handlespace. In previous publications may be denominated the namespace name. The name was changed to avoid confusion with the Domain Name System. Each pool in a handlespace is identified by a unique pool handle ( PH), which is a randomly selected byte vector. Usually it involves a name in ASCII or Unicode encoding, such as "Download Pool " or " Web server pool ".

Each handlespace has a limited range (operation scope, such as an organization or company). It is expressly not a desirable goal of RSerPool to manage all global pools within a single handlespace. Because of the local importance of the field of application, it is possible to keep the handlespace "flat". This means that there is no hierarchy for PHs are - in contrast to the Domain Name System, with its top-level and sub-domains. This contrast leads to a significant simplification of the management of the handle namespaces.

Within a field of application a handlespace of redundant existing pool registrars (PR ) is managed. PRs are also referred to as ENRP server or name server (NS). Your redundancy is necessary so that a single PR does not have a single point of failure ( single point of failure ) can be. Each PR from a range of application is with his registrar ID ( ID PR ), a 32- bit random number identified. It is not necessary to ensure the uniqueness of PR IDs. A PR contains a complete copy of the Handle spaces of a field of application. The PRs of the same application range from their point of view on the handlespace by the Endpoint handlespace Redundancy Protocol ( ENRP ). Older versions of this protocol are named Endpoint namespace Redundancy Protocol; this designation was removed to avoid confusion with DNS. Due to the synchronization of the handlespace by ENRP the functionality of PRs within a field of application is the same. This means that the tasks of a no longer accessible PRs can be adopted by any other PR of the application.

By using the Aggregate Server Access Protocol (ASAP ), a PE may add to a pool or unsubscribe from its pool again. For this purpose, an arbitrary PR of the application area can be used. In the event of a successful registration of chosen by the PE PR for Home -PR (PR- H) of the PEs. The PR- H not only informs the other PRs about the completed registration or deregistration of its PEs, but it also monitors the availability of its PEs by keep- alive messages. A keep -alive message from his PR -H will have to confirm a PE within a certain period of time. Replies the PE is not within a predetermined time frame, it is considered to be no longer accessible and permanently removed from the handlespace. It is also expected from a PE that it regularly again and again re - registered. In such a re-registration, it is also possible for a PE to update its list of transport addresses and other information.

A client of a pool is referred to in the terminology of RSerPool as a pool user ( PU). In order to use the service of the pool, he asks for any PR the range of use of the resolution of the pool PHs in a list of PE identities. This process is referred to as a handle resolution. If there is the pool, the PR selects based on the specified selection rule for the pool (Pool Member Selection Policy, also abbreviated as pool Policy referred to ) the desired list of PE identities.

Possible pool policies, for example, random ( Random), round robin (Round Robin ) or PEs with the lowest utilization (Least Used). While in the first two cases no additional information about the PEs are required (non- adaptive policies ), is a current load information of PEs required ( Adaptive Policy ) for the Least Used selection. Although this requires regular updates of the status data (via a re-registration ), but can also achieve a considerably improved load distribution in the pool under the circumstances.

After obtaining a list of PE identities by PR can write these PE identities in its local cache, a PU. This memory is also called PU -side cache ( engl. PU -side cache). For this cache of PU now selects in turn the basis of the pool Policy exactly one PE from. For this selected PE he then establishes a connection with the Protocol on the application - for example, HTTP over SCTP or TCP in the case of a web server - and then use the actual application of the server. If connection fails or disconnects during the service usage from, a new PE is selected. Is not getting old, the information in the cache, it can be used to select the cache directly. Otherwise, a new request for handle resolution at a PR is required and the whole process repeats itself. Finally is a link to a new PE built, the status of the lower end broch session on the new PE needs to be restored. The procedure to be carried out for this purpose is called failover procedure and is application-specific. If the FTP download, for example, the new PE of the file name, and the last receiving file position must be notified. In order for the new PE is then able to resume the download at the point of interruption.

To allow PEs and PUs automatically finding PRs PRs, can send (so-called Announces ) over UDP over IP multicast announcements. By listening to the Announce messages in a specified multicast group PEs and PUs are then able to learn a list of the multicast domain in their PRs. By the use of multicast, as opposed to broadcasting the mechanism works via router limits. In the case of a switched Ethernet is also achieved that the multicast messages are forwarded only to those ports that really interested because devices are connected. If not available multicast, PR addresses must be statically configured, of course.

Implementations

The following implementations of RSerPool are currently known:

  • RSPLIB Project at the University of Duisburg -Essen
  • Motorola
  • Cisco
  • Fachhochschule Münster

Standardization documents

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 ) parameter
  • RFC 5355 - Threats Introduced by Reliable Server Pooling ( RSerPool ) and Requirements for Security in Response to Threats
  • RFC 5356 - Reliable Server Pooling Policies
  • RFC 5525 - Reliable Server Pooling MIB module definition

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

Further 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
  • Takeover Suggestion Flag for the ENRP Handle Update Message
Internet Engineering Task Force Keepalive
677497
de