可信服務器池

可信服務器池 （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