Reliable server pooling

from Wikipedia, the free encyclopedia

Reliable Server Pooling (RSerPool) is a protocol framework for the administration of server pools and for the implementation of logical sessions of clients with such pools. As part of the session management, RSerPool takes on in particular the selection of a server from the pool (load distribution, load balancing) and, if the server fails, the switchover (failover) to a replacement server in the pool. RSerPool was developed by the IETF RSerPool working group and laid down as an Internet standard in RFC 5351 to RFC 5356 in September 2008 .

Basic idea of ​​RSerPool

With certain client / server applications, very high damage can result from failure of the server. In the case of e-commerce, z. B. the potential customers simply another provider. In order to be able to continue providing the critical service even in the event of a server failure, redundancy of the servers is necessary. That is, there are at least two servers; if one of them fails, another simply takes over his duties.

The aim of Reliable Server Pooling, which is currently being standardized by the IETF RSerPool working group, is a unified procedure for managing server pools (servers can be dynamically added to or removed from the pool, for example) and for access from clients to the pools. From the perspective of the client application, a server pool is a logical server to which a session is established. RSerPool takes care of server selection (especially load distribution), connection establishment, monitoring of the connection and new selection of a server in the event of an error.

More detailed description of RSerPool

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

In the terminology of RSerPool, servers are referred to as pool elements (PE). The set of all PEs that offer the same service form a pool. A PE is identified within a pool by a 32-bit pool element identifier (PE ID). The PE ID is determined randomly when a PE registers for a pool. The totality of all pools is called the handlespace . In previous publications, the term can also be namespace. 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 this is a name in ASCII or Unicode encoding, such as "DownloadPool" or "WebServerPool".

Each handlespace has a limited area of ​​application (operation scope, e.g. an organization or company). It is explicitly not a desirable goal of RSerPool to manage all global pools within a single handlespace. Because of the local importance of the area of ​​application, it is possible to keep the handle space "flat". This means that there is no hierarchy for PHs - 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 space.

A handle space is managed by redundant pool registrars (PR) within an application area . PRs are also known as ENRP servers or name servers (NS). Their redundancy is necessary so that a single PR cannot become a single point of failure (SPoF). Each PR from an application area is identified with its Registrar ID (PR ID), a 32-bit random number. It is not necessary to guarantee the uniqueness of PR IDs. A PR contains a complete copy of the handle space of an application area. The PRs of an application area compare their view of the handlespace using the Endpoint Handlespace Redundancy Protocol (ENRP). Older versions of this protocol are called Endpoint Namespace Redundancy Protocol; this designation was replaced to avoid confusion with DNS. Because the handlespace is synchronized by ENRP, the functionality of the PRs is identical within an application area. This means that the tasks of a PR who can no longer be reached can be taken over by any other PR in the field of activity.

By using the Aggregate Server Access Protocol (ASAP), a PE can add itself to a pool or log off from its pool. Any PR of the area of ​​application can be used for this. In the event of a successful registration, the PR selected by the PE becomes the PE's home PR (PR-H). The PR-H not only informs the other PRs that its PEs have been registered or deregistered, but also monitors the availability of its PEs by means of keep-alive messages. A keep-alive message from its PR-H must be confirmed by a PE within a certain period of time. If the PE does not respond within a specified time frame, it is considered to be no longer accessible and is immediately removed from the handlespace. Furthermore, a PE is expected to regularly re-register again and again. With such a re-registration it is also possible for a PE to update the list of its transport addresses and other information.

A client of a pool is referred to as a pool user (PU) in RSerPool terminology . In order to use the pool service, he asks any PR in the area of ​​application to resolve the pool PH into a list of PE identities. This process is known as handle resolution. If the pool exists, the PR selects the desired list of PE identities based on the selection rule established for the pool ( pool member selection policy , also known as pool policy for short ).

Possible pool policies are, for example, random (random), round robin or PEs with the lowest utilization (least used). While no additional information about the PEs is necessary in the first two cases (non-adaptive policies), current load information on the PEs is required for the least-used selection (adaptive policy). Although this requires regular updates of the status data (via re-registration), it can, under certain circumstances, also achieve a considerably better load distribution in the pool.

After receiving a list of PE identities from the PR, a PU can write these PE identities into its local cache. This memory is also referred to as a PU-side cache. The PU now in turn selects exactly one PE from this cache using the pool policy. It then establishes a connection to the selected PE using the application's protocol - e.g. B. HTTP over SCTP or TCP in the case of a web server - and then uses the actual application of the server. If the connection setup fails or if the connection breaks off while the service is being used, a new PE is dialed. If the information in the cache is not out of date, the cache can be used directly for selection. Otherwise, a new request for handle resolution with a PR is necessary and the entire process is repeated. If a connection to a new PE is finally established, the status of the interrupted session must be restored on the new PE. The procedure to be carried out for this is called the failover procedure and is application-specific. In the case of an FTP download, e.g. B. the file name and the last received file position can be communicated to the new PE. The new PE is then able to continue the download at the point of interruption.

In order to enable PEs and PUs to find PRs automatically, PRs can send announcements over UDP via IP multicast . By listening to the announce messages in a defined multicast group, PEs and PUs are then able to learn a list of the PRs currently available in their multicast domain. By using multicast as opposed to broadcast, the mechanism also works across router boundaries. In the case of a switched Ethernet, it is also achieved that the multicast messages are only forwarded to those ports via which devices that are really interested in them are connected. If multicast is not available, PR addresses must of course be configured statically.

Implementations

The following implementations of RSerPool are currently known:

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) Parameters
  • 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

More drafts

Web links

Individual evidence

  1. ↑ a b Reliable Server Pooling (rserpool) Charter. February 19, 2006, accessed October 3, 2019 .