RSerPoolji简介与安装配置

这几天专门研究下thomas的可信赖服务器池（RSerPool）.
RSserPool核心概念： 三个实体元素： Registrar: poolElement: poolUser:
两个专有协议： ENRP（Endpoint HaNdlespace Redundancy Protocol） ASAP (Aggregate Server Access Protocol)
以及一个基础协议： sctp :
下面我们来分别理解下每一个元素于协议的作用于处于什么样的位置 为了方便理解，我们直接举个具体的例子。假设这里我们正在用浏览器上网，那么我们需要连接到服务器上去。 在假设google正在使用我们的RSerPool技术。于是我们敲入www.google.com 于是我们便连接到了google的服务器。但事实上google绝对不仅仅一台服务器，而是很多台。那么假设有一个容器需要协调这么多的服务器工作，我们便有了服务器池的概念(正确，但其范围及概念更加广泛)，这有点类似于连接池的概念。那么其中的每一台服务器，我们就叫他poolElement. 想推这些池元素而言，我们这些访问服务的计算机就是poolUser，即池用户。对于服务器池而言，他们需要一个协调维护者，比如存储poolElement每一个的名字或者ID ，如果哪一个当机了，又维护者决定哪一个顶上，所有便有了Registrar的概念。那么我们会想，registrar 是如何和服务器池中的poolElement通信的呢。对需要一个协议，也就是ASAP，聚合服务器访问协议（姑且这么翻译）（注：周老师的译稿我在网上始终打不开，不知什么缘故，原因是我国禁止封锁了这个网站）。一般服务器都需要冗余，Registrars 也不例理外，所以他们之间也需要协调，有协调就有通信，有通信就有协议，于是ENRP 便产生了，也即（端点处理域冗余协议。（是这样的） 我们再看看官方的解释：



The figure above shows the building blocks of the RSerPool architecture, which has been defined by the IETF RSerPool WG in [draft-ietf-rserpool-arch]. In the terminology of RSerPool a server is denoted as a Pool Element (PE). In its Pool, it is identified by its Pool Element Identifier (PE ID), a 32-bit number. The PE ID is randomly chosen upon a PE's registration to its pool. The set of all pools is denoted as the Handlespace. In older literature, it may be denoted as Namespace. This denomination has been dropped in order to avoid confusion with the Domain Name System (DNS). Each pool in a handlespace is identified by a unique Pool Handle (PH), which is represented by an arbitrary byte vector. Usually, this is an ASCII oder Unicode name of the pool, e.g. "DownloadPool" or "WebServerPool".
上面的示意图展示了RSserPool体系的结构的各个模块图。在RSerPool技术中，一个服务器都被名名为一个池元素。在其池中，每个服务器（或池元素）被３２比特的PE ID 所唯一标识。ＰＥＩＤ　由ＰＥ在相相应池注册的过程中随基产生。一系列池构成一个处理域（Handlespace）.以前是叫做名字空间，但为了避免于域名系统（ＤＮＳ）中的概念想混淆改为处理域。在处理域中，每一个池都由一个唯一的由任意字节向量构成的池处理（PoolHandle(PH)）所标志。通常情况下，池处理是某个池ＡＳＣＩＩ的ＵＮＩＣＯＤＥ名字。比如“下载池”或者"web服务器池“。
Each handlespace has a certain scope (e.g. an organization or company), denoted as Operation Scope. It is an explicit non-goal of RSerPool to manage the global Internet's pools within a single handlespace. Due to the limitation of operation scopes, it is possible to keep the handlespace "flat". That is, PHs do not have any hierarchy in contrast to the Domain Name System with its top-level and sub-domains. This constraint results in a significant simplification of the handlespace management.
每一个处理域都有一个确定的范围（域）（比如一个组织或者一家公司），并且被赋予一个操作域，显然在一个单一的处理域中管理全球因特网池并不是RSerPool的目标。由于控制域的限制，我们很可能去使控制域“平坦”的而非具有层次。也就是说，和域名系统相比，PHs并没有层次结构，比如顶层域含有子域。RSerPool的这种限制简化了处理域的管理。
Within an operation scope, the handlespace is managed by redundant Registrars. In literature, this component is also denoted as ENRP Server or Name Server. Since "registrar" is the most expressive term, this denotation is used in the whole document. PRs have to be redundant in order to avoid a PR to become a single point of failure (SPoF). Each PR of an operation scope is identified by its Registrar ID (PR ID), which is a 32-bit random number. It is not necessary to ensure uniqueness of PR IDs. A PR contains a complete copy of the operation scope's handlespace. PRs of an operation scope synchronize their view of the handlespace using the Endpoint HaNdlespace Redundancy Protocol (ENRP) defined in [draft-ietf-rserpool-enrp,draft-ietf-rserpool-common-param]. Older versions of this protocol use the term Endpoint Namespace Redundancy Protocol; this naming has been replaced to avoid confusion with DNS, but the abbreviation has been kept. Due to handlespace synchronization by ENRP, PRs of an operation scope are functionally equal. That is, if any of the PRs fails, each other PR is able to seamlessly replace it.
在一个操作域中，每个处理域由相应的冗余的Registrars所管理。从含义来看，这个组件也可以被称作ENRP 服务器或者名字服务器。但既然“registrar”是最能表达相应意思的一个词汇，我们在整个文档中都将使用这个词汇。PRs 为了防止出现单点失效（single point failure）必须具有冗余。操作域中的每一个PR都由一个32比特的随机数所标志，我们称作Registrar ID(PR ID).并不需要确保PR IDs的唯一性。一个 PR包含了操作域中处理域的完全拷贝。在操作域中的每个PR都同步处理域的内容通过 Endpoint HaNdlespace Redundancy Protocol(ENRP,端点处理域冗余协议)。旧版协议中使用Endpoint Namespace Redundancy Protocol，这个名字被现在的名字替换，依然是由于避免为了和DNS 想混淆，但它的缩写形式仍然是相同的。由处理域通过ENRP进行同步，一个操作域中的PRs 是功能等同的。。。也就是说PRs中的任何一个PR失效，都可由另一个PR 所代替。
Using the Aggregate Server Access Protocol (ASAP), defined in [draft-ietf-rserpool-asap,draft-ietf-rserpool-common-param] a PE can add itself to a pool or remove it from by requesting a registration or deregistration from an arbitrary PR of the operation scope. In case of successful registration, the PR chosen for registration becomes the PE's Home-PR (PR-H). A PR-H not only informs the other PRs of the operation scope about the registration or deregistration of its PEs, it also monitors the availability of its PEs by ASAP Keep-Alive messages. A keep-alive message by a PR-H has to be acknowledged by the PE within a certain time interval. If the PE fails to answer within a certain timeout, it is assumed to be dead and immediately removed from the handlespace. Furthermore, a PE is expected to re-register regularly. At a re-registration, it is also possible for the PE to change its list of transport addresses or its policy information (to be explained later).
一个PE 可以通过向相应操作于域中的任意PR 请求注册或者注销而将他自己加入或者移出服务器池，这是通过ASAP协议完成的。一旦成功注册，该台PR 就成为相应PE的 Home-PR(PR-H)(有点凹口，也就是说，PE a 向PR b 注册，那么注册成功后b 就称作a的PR－H)。一个 PR－H不仅通知其他的PRs某个PE 的注册与注销，同时也通过ASAP Keep-Alive信息来监视PE的有效性。一个Keep-Alive 信息周期性的被PR－H 发送给PE。如果PE在规定的时限内为能够回答，该PE就被PR－H认为失效，并被移出服务器池。进一步的，一个PE 也被要求周期性的从新注册。在从新注册中，PE 就有可能改变传输地址列表以及策略信息守（这将在稍后解释）。
To use the service of a pool, a client - called Pool User (PU) in RSerPool terminology - first has to request the resolution of the pool's PH to a list of PE identities at an arbitrary PR of the operation scope. This selection procedure is denoted as Handle Resolution. For the case that the requested pool is existing, the PR will select a list of PE identities according to the pool's Pool Member Selection Policy, also simply denoted as Pool Policy.
为了使用池服务，客户，也就是Pool User(PU)，首先必须请求操作域中的任意一个PR对池的PH（PH也就是前面提到的pool的ID）解析并得到PE ID列表（个人认为的过程：首先PU 给任意某个PR 发送一个PH，也就是Pool 的ID，然乎由PR 进行解析，判断这个相应的池是否存在，如果存在，这根据池成员选这策略得到一张列表返还）。这个过程被称作解析处理（Handle Resolution）.在池可用的情况下，PR 会根据池的池成员选择策略（简称池策略）选择一个PE ID 的列表。
Possible pool policies are e.g. a random selection (Random) or the least-loaded PE (Least Used). While in the first case it is not necessary to have any selection information (PEs are selected randomly), it is required to maintain up-to-date load information in the second case of selecting the least-loaded PE. Using an appropriate selection policy, it is e.g. possible to equally distribute the request load onto the pool's PEs.
可能的池策略是随机选择或者选择最少被加载的PE（即最少被使用原则）。第一种情况不需要任何额外的选择信息。第二种情况需要维持一个最新的加载信息。一个合适的策略是经可能的是负荷均匀的落在由每台服务器（PE）上。
After reception of a list of PE identities from a PR, a PU will write the PE information into its local cache. This cache is denoted as PU-side Cache. Out of its cache, the PU will select exactly one PE - again using the pool's selection policy - and establish a connection to it using the application's protocol, e.g. HTTP over SCTP or TCP in case of a web server. Using this connection, the service provided by the server is used. For the case that the establishment of the connection fails or the connection is aborted during service usage, a new PE can be selected by repeating the described selection procedure. If the information in the PU-side cache is not outdated, a PE identity may be directly selected from cache, skipping the effort of asking a PR for handle resolution. After re-establishing a connection with a new PE, the state of the application session has to be re-instantiated on the new PE. The procedure necessary for session resumption is denoted as Failover Procedure and is of course application-specific. For an FTP download for example, the failover procedure could mean to tell the new FTP server the file name and the last received data position. By that, the FTP server will be able to resume the download session. Since the failover procedure is highly application-dependent, it is not part of RSerPool itself, though RSerPool provides far reaching support for the implementation of arbitrary failover schemes by its Session Layer mechanisms.
在接受到PR 返回的PE　ID列表后，PU会将其缓存在本地的缓存中，该缓存称为PU-side Cache.一旦缓存溢出，PU江湖再次通过池选择策略选择一个PE并且通过应用层协议建立连接，比如（应用层协议）建立在sctp 或者TCP之上的HTTP（该协议可用于web服务）。建立好连接后，那么服务器的服务将可以使用。假设建立连接失败或者在服务正在使用的时候连接被中断，那么一个新的PE将会被选择。如果PU 端的缓存信息没有过期，PE 将被直接从缓存中选取而无须重复解析过程。在与新的PE重建连接后，应用层信息也将在新的PE中重初始化。重建会话的过程被乘坐Failover过程。以FTP下载为例子，整个failover过程意味着告诉信的ＦＴＰ服务器文件名字以及被传递接受数据的位置（类似于断点续传中端点的概念）。通过上面的步骤，新的ＦＴＰ服务器就可以恢复下载的会话。由于failover的是高度程序独立的，应此他的实现并不是RSerPool的一个部分，尽管RSerPool在会话层提供了了任意failover模式。
To make it possible for RSerPool components to configure automatically, PRs can announce themselves via UDP over IP multicast. These announces can be received by PEs, PUs and other PRs, allowing them to learn the list of PRs currently available in the operation scope. The advantage of using IP multicast instead of broadcast is that this mechanism will also work over routers (e.g. LANs connected via a VPN) and the announces will - for the case of e.g. a switched Ethernet - only be heard and processed by stations actually interested in this information. For the case that IP multicast is not available, it is of course possible to statically configure PR addresses.
为使RSerPollP组件配置自动化，ＰRs通过基于ＩＰ多播UDP互相传递信息（通知）的。这些通知将被ＰＥ或者其他的ＰＲs接受。这可以让其他的ＰＥ活ＰＲs学习到d当前操作域中可用ＰＲs的列表。使用ＩＰ多播而非广播主要是因为该机制可以工作在路由器上，比如基于虚拟专用网(VPN)连接的局域网（LANs）以及通知将只会被那些对这些信息感兴趣的站点解听到（比如在交换以太网中）。如果IP 多播不被支持的华，当然也可以静态配置如有地址。
下面是安装过程，这整个安装过程并不想象的那么简单。我花了三天多时间才基本装好，还有一些问题依然没有解决。
1，首先是系统要求。我装的是Ubuntu 8.04 -hardy Heron-released in April 2008,是桌面版本的。桌面用的是GNOME.KDE应该没问题。
2 ，软件要求，必须要有GCC 编译器。这个系统默认就会装，但是装的并不全，最好是通过下面两条命令。
sudo apt-get install gcc --build-essensial
sudo apt-get install g++
3 源码 glib, sctplib ,socketapi ,rsplib 准备（这是按照Thomas 安装说明中所要求的，但有问题，至少我装了两次系统都没有解决）
4 安装 glib
sudo ./configure
sudo make
sudo make install
安装没问题。但是当你安装sctplib 时候就有问题了。在检查依赖性时候会出现两种情况：
第一种，提示没哟找到glib,
第二种，提示有某一低版本却找到一高版本。
解决办法有：（最好的）直接安装GTK开发包
输入如下命令：
sudo apt-get install libgtk2.0-common libgtk2.0-dev
这样让人心烦的glib 问题就全被系统自己解决了。
第二中方法是主要是从问题的原因入手，之所以安装好glib 之后找不到glib 是应为glib 被方在了/usr/local/lib目录下，系统是默认不找这个目录的
，我们必须把他发在/usr/lib目录。（在你看些这个目录你就知道，大部分程序包都是放在／usr/lib目录下的，/usr/local/lib却是空空如也）
所以，你必须将执行这些命令
sudo ./configure --prifix=/usr
sudo make
sudo make install
第三种方案是将
/usr/local/lib 目录添加到/etc/ld.so.conf中去。
事实上我个人觉得应该作两个工作，把第一第三种方法都做一下，应为下面装的一些包也是要放在/usr/local/lib目录下的。
5 安装sctplib
这个没有什么问题。敲那三个命令就可以了。
6安装socketapi
thomas网站上提供的包似乎有问题，因为在make的时候会提示构造函数的什么问题。因此我在linuxQuestion上问了下，可爱的knudfl(http://www.linuxquestions.org/questions/linux-software-2/socketapi-compile-problems-654728/#post3211135 )提供了一个最新的下载地址：http://ppa.launchpad.net/dreibh/ubuntu/pool/main/s/socketapi/。
我编译通过没有问题。
6 安装rsplib
安装最新版本的rsplib 会提示socketapi 版本过低，但我查阅了一下，感觉前面的那个socketapi已经是最高的了，所以我换了个rsplib2.2.0版本后就能顺利依赖性检查
基本没有什么其他问题只是在使用./configure时，使用下面的命令代替
./configure --disale-kernel-sctp
否则提示你的内核没有sctp，你必须手工将sctp继承进内核，很难。应此你可以使用嗯上面我们安装的sctp.
7 单机环境测试
因为至少要三台到四太机器，所以虚拟机是不错的选择。我的博客有具体的虚拟机配置教程，其中包括安装遇到的bug修改问题。 http://coolcat-allwefantasy.blogspot.com/

(感谢周老师的批注与修改)