可信服务器池

可信服务器池 （Reliable Server Pooling - RSerPool） 是一个用于管理及访问服务器池的计算机软件框架协议。目前，IETF的 RSerPool工作组指导下，其协议框架正处在标准化过程中。

**引  言**
用可信服务器池（Reliable Server Pooling - RSerPool）的术语，可信服务器池中的一个服务器叫池元素(PE - Pool Element), 每个PE 用一个32 位比特的PE ID 标识. 每个PE 标识由 PE 注册到服务器池中时随机选择。所有服务器池的标识集合称为句柄空间。在旧文献中，句柄空间又叫名字空间。为了避免与域名系统(DNS)相混淆, RSerPool 不再使用名字空间的术语。句柄空间中的每个服务器池由一个唯一的池句柄（PH）标识，池句柄是一个任意的字节向量。通常它用 ASCII 或 Unicode 码来表示这个池的名字，例如像："DownloadPool" 或 "WebServerPool"。
每个句柄空间有一个确定的管理范围〔如，一个组织，一个机构或一个公司〕，这个确定的范围被称为操作范围。很明显，在一个句柄空间内管理全球性的 Internet 的池并不是 RSerPool 的目标。由于操作范围的局限，使用“无层次”句柄空间管理是可行的。也就是说，与域名系统相比，RSerPool 句柄空间〔PHs〕没有使用层次管理结构。这种非层次的管理方式简化了句柄空间的管理。
在一个操作范围内，句柄空间由一组冗余的池注册器（Pool Registrars - PR）管理，这组注册器称为 ENRP （Endpoint Handlespace Redundancy Protocol） 服务器或者叫名字服务器（Name Servers -NS ）。为了避免一个 PR 成为一个失败的单点 （Single Point of Failure - SPoF ），PRs 必须由多个PR 组成。一个操作范围内的每个PR 由它的注册 ID （PR ID）标识，其标识符是一个32-bit 的随机数，但不必保证 PR IDs 的唯一性。每个 PR 包含了一个完整的操作范围句柄空间的拷贝。一个操作范围内的所有 PRs 通过使用 ENRP 协议来同步句柄空间的视图。 旧版的 ENRP 协议使用了终端名字空间冗余协议 （Endpoint Namespace Redundancy Protocol）的术语，为了避免与域名系统混淆，这个命名已经被替换，但缩写仍然依旧。由于通过 ENRP 协议实现同步，一个操作范围内的所有 PRs 有相同的功能。也就是说，任何一个 PR 失效，其它的 PR 能无缝地替代失效 PR 的工作。
在一个操作范围内，一个 PE 可以使用 ASAP （Aggregate Server Access Protocol）协议通过请求注册或请求注销把它自己加入任意一个 PR 或从任意一个 PR 注销自己。一旦注册成功，这个 PR 将成为该 PE 的PR-H（Home-PR）。 PR-H 不仅通知该操作范围内其它 PRs 关于它的 PEs 的注册或注销信息，它也要通过 ASAP Keep-Alive messages 监视它的 PEs 工作的有效性。由 PR-H 发出的一个keep-alive message  报文必须在一个确定的时间间隔内被它的 PEs 确认。如果该 PE 不能在一个确定的时间间隔内应答，那幺该 PE 被假定失效了，并立即从句柄空间中注销。通常，紧接着，期待一个 PE 再注册。在再注册时，很有可能这个 PE 改变它的传送地址列表或它的策略信息。
为了使用一个池的服务，一个客户端 - 用 RSerPool 的术语被称为 PU （Pool User）- 首先必须请求该操作范围内任一个 PR 服务器池的池句柄 PH 解析成一个 PE 标识列表。这个选择过程称为处理解析。一旦被请求的池存在，该 PR 将根据池成员选择策略（Pool Member Selection Policy- 简称为池策略Pool Policy）选择一个 PE 标识列表。 
例如，可选的池策略有随机选择（random selection）或最小负载 PE （Least Used）。第一种策略不需要任何选择信息，PEs 被随机地选择；而第二种策略需要维护更新的负载信息，以便选择当前最小负载的 PE。通过使用合适的选择策略，可以将请求负载均衡地分配到池元素中，以达到负载均衡的目的。
从一个 PR 收到 PE 标识列表后，一个 PU 会把这个列表信息写入到自己本地的缓冲存储器（简称 PU 方缓存 - PU-side Cache）中。从 PU 方缓存， 该 PU 将再次使用池策略选择一个 PE 并通过像基于 SCTP 协议之上的 HTTP 或 TCP 这样的应用协议与这个 PE 建立联接。通过这个联接，PU 可以使用由于服务器 PE 提供的服务。如果联接建立失败或在服务过程失效，通过重复上面描述的联接过程选择一个新的 PE。如果 PU 方缓存中的信息没有超时或失效，一个 PE 的标识可以直接地从该缓存中选取，而不需再请求 PR 执行解析处理的过程。当 PU 与一个新的 PE 重建联接后，该 PU 与前一个 PE 的应用会话状态信息必须在这个新 PE 上重现。这个会话状态信息在新 PE 上的恢复过程叫 Failover 过程， 当然它也是一个特定的应用过程。例如，用文件传协议（FTP）下载文件的例子，failover 过程意谓着需要告诉新的 FTP 服务器的文件名，以及最后收到的数据位置。这样，新的 FTP 服务器就能够恢复下载会话过程。由于 failover 过程是高度地依赖于特定的应用，尽管 RSerPool 通过它的会话层机制支持任意 failover 的实施方案， 但 failover 并不属于 RSerPool 的一部分。
为了实现 RSerPool 池成员的自动配置，PRs 可以通过基于IPmulticast 的 UDP 报文协议来通告所有池成员。 PEs, PUs 和其它的 PRs 都可以收到这些通告，并且在操作范围内这些通告允许池成员获悉当前有效的 PRs 列表。使用 IP 多地址（IP  multicast ）取代广播传送的优点是这种机制可以工作在路由器之上 （例如，通过虚拟专用网VPN 互联的局域网LAN），并且这些通告只会被对此感兴趣的成员监听并处理。对于IP 多地址传送无效的情况，可以使用静态方式配置 PRs 的地址。

**实施 RSerPool**
RSerPool 具体实施可以从下面链接中获悉:-  RSPLIB Project date=20170807145017 - Motorola 公司- Cisco 公司- Münster University of Applied Sciences

**RSerPool 标准文档**

**RSerPool RFCs 文档**
 RFC 3237 - RSerPool 需求- 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

**RSerPool 工作组草案**
  Architecture for Reliable Server Poolingdate=20070313140740  - RSerPool 体系结构-  Comparison of Protocols for Reliable Server Poolingdate=20070313140718  - RSerPool 协议比较-  TCP Mapping for Reliable Server Pooling Enhanced Modedate=20070918054435  - 关于RSerPool 增强模式 TCP 映射-  Services Provided By Reliable Server Poolingdate=20070918054323  -  RSerPool 的服务功能-  Reliable Server Pooling Sockets API Extensionsdate=20070918054424  - RSerPool 套接字 API 扩展

**其它工作草案**
  Handle Resolution Option for ASAP date=20240630135649 -  Least-Used Policy for Reliable Server Pooling date=20240630135640 -  Reliable Server Pooling Applicability for IP Flow Information Exchange date=20240705163939 -  Applicability of Reliable Server Pooling for Real-Time Distributed Computing date=20240630135707 -  Reliable Server Pooling (RSerPool) Bakeoff Scoring date=20240630135640 -  Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility date=20240510013807 -  Takeover Suggestion Flag for the ENRP Handle Update Message date=20240630135648 -  The Applicability of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL) date=20240630135656 -  Ideas for a Next Generation of the Reliable Server Pooling Framework date=20240630140038 

**其它链接**
  Thomas Dreibholz's Reliable Server Pooling (RSerPool) Pagedate=20170807145017 -  IETF RSerPool Working Groupdate=20160321171030