-
如奕老师主讲
第
1<
/p>
章
F5
基础
1.1
集群
1.1.1
背景介绍
Internet
的飞速发展给网络带宽和服务器带来巨大的挑战。从网络技术
的发展来看，网
络带宽的增长远高于处理器速度和内存访问速度的增长。大部分网站都需
要提供每天
24
小
时、
每星期
7
天的服务，
对电子商
务等网站尤为突出，
任何服务中断和关键性的数据丢失都
会造成
直接的商业损失。所以这对网络服务的可靠性提出了越来越高的要求。
现在
Web
服务中越来越多地使用
CGI
、动态主页等
CPU
密集型
应用，这对服务器的性
能有较高要求。
未来的网络服务会提供更
丰富的内容、更好的交互性、
更高的安全性等，需
要服务器具有
更强的
CPU
和
I/O
处理能力。例如，通过
HTTPS
（
< br>Secure HTTP
）取一个静态页
面需要的处理性
能比通过
HTTP
的高一个数量级，
H
TTPS
正在被电子商务站点广为使用。所
以，网络流量并不能
说明全部问题，要考虑到应用本身的发展也需要越来越强的处理性能。
因此，
对用硬件和软件方法实现高可伸缩、
高可用网络
服务的需求不断增长，
这种需求
可以归结以下几点：
可伸缩性（
Scalability
）
：当服务的负载增长时，系统能被扩展来满足需求，且不降低服
务质量。
高可用性
（
Availability
）
：
尽管部分硬件和软件会发生故障，
整个系统的服务必须是每天
24
小时每星期
7
天可
用的。
可管理性（
Manageab
ility
）
：整个系统可能在物理上很大，但应该容易管理。
价格有效性（
Cost-effec
tiveness
）
：整个系统实现是经济的、易支付的。
1.1.2
服务器集群系统
对称多处理（
Symmetric Multi-Proces
sor
，简称
SMP
）是由多个对称的
处理器、和通过
总线共享的内存和
I/O
部件所组成的计算机系统。
SMP
是一种低并行度的结构，<
/p>
是我们通常
所说的
紧耦合多处理系统
，它的可扩展能力有限，但
SMP
的优点是单一系统映像（
Single
System Image
）
，有共享
的内存和
I/O
，易编程。
由于
SMP
的可扩展能力有限，
SMP
服务器显然不能满足高可伸缩、高可用网络服务中
的负载处理能力不断增长需求。
随着负载不断增长，
会导致服
务器不断地升级。
这种服务器
升级有下列不足：
一是升级过程繁琐，
机器切换会使服务暂时中断，
并造
成原有计算资源的
浪费；二是越往高端的服务器，所花费的代价越大；三是
SMP
服务器是单一故障点（
Single
Point of Failure
）
，一旦该服务器或应用软件失效，会导致整个服务的中断。
如奕老师主讲
通过高性能网络或局域
网互联的服务器集群正成为实现高可伸缩的、
高可用网络服务的
有效结构。这种松耦合结构的服务器集群系统有下列优点：
性
能：
网络服务的工作负载通常是大量相互独立的任务，
通过一组
服务器分而治之，
可
以获得很高的整体性能。
< br>
性能
/
价格比：组成集群系统
的
PC
服务器或
RISC
服务器和标准网络设备因为大规模生
产降低成本，价格低，具有最高的性能<
/p>
/
价格比。若整体性能随着结点数的增长而接近线性
增加，
该系统的性能
/
价格
比接近于
PC
服务器。
所以，
这种松耦合结构比紧耦合的多处理器
系统具有更好的性能
/
价格比。
可伸缩性：
集群系统中的结点数目可以增长到几千个，
乃至上万个，
其伸缩性远超过单
台超级计算机。
高可用性：
在硬件和软件上都有冗余，通过检测软硬件的故障，将故障屏蔽，
由存活结
点提供服务，可实现高可用性。
当然，用服务器集群系统实现可伸缩网络服务也存在很多挑战性的工作：
透明性
（
Transparency
）
：
如何高效地使得由多个独立计算机组成的松藕
合的集群系统构
成一个虚拟服务器；
客户端应用程序与集群系统
交互时，
就像与一台高性能、
高可用的服务
器交互一样，
客户端无须作任何修改。
部分服务器的切入和
切出不会中断服务，
这对用户也
是透明的。
性能（
Performance
）
：性能要接近线性加速，这需要设计很好的软硬件的体系结构，消
除系统可能存在的瓶颈。将负载较均衡地调度到各台服务器上。
< br>高可用性
（
Availability
< br>）
：
需要设计和实现很好的系统资源和故障的监测和处理
系统。
当
发现一个模块失败时，
要这模
块上提供的服务迁移到其他模块上。
在理想状况下，
这种迁移<
/p>
是即时的、自动的。
可管理性（
Manageability
）
：要使集群系
统变得易管理，就像管理一个单一映像系统一
样。在理想状况下，软硬件模块的插入能做
到即插即用（
Plug &
Play
）
。
可编程性（
Programmability
）
：在集群系统上，容易开发应用程序。
1.2Linux
集群系统
针对高可伸缩、高可用网络服务的需求，我们给出了基于
IP
层和基于内容请求分发的
负载平衡调度解决方法，并在
Linux
内核中实现了这些方法，将一组服务器构成一个实现可
< br>伸缩的、高可用网络服务的虚拟服务器。
虚拟服务器的
体系结构如图
1
所示，
一组服务器通过
高速的局域网或者地理分布的广域
网相互连接，在它们的前端有一个负载调度器（
Load Balancer
）
。负载调度器
能无缝地将网
络请求调度到真实服务器上，
从而使得服务器集群
的结构对客户是透明的，
客户访问集群系
统提供的网络服务就像
访问一台高性能、
高可用的服务器一样。
客户程序不受服务器集
群的
如奕老师主讲
影响不需作任何修
改。系统的伸缩性通过在服务集群中透明地加入和删除一个节点来达到，
通过检测节点或
服务进程故障和正确地重置系统达到高可用性。
由于我们的负载调度技术是
在
Linux
内核中实现的，我们称之为
Linux
虚拟服务器（
Linux
Virtual Server
）
。
图
1
：虚拟
服务器的结构
Linux Virtual Server<
/p>
项目的目标：
使用集群技术和
Linux
操作系统实现一个高性能、
高可
用的服
务器，它具有很好的可伸缩性（
Scalability
）
、可靠性（
Reliability
）和可
管理性
（
Manageability
）
。
目前，
LVS
项目已提供了一个实现可伸缩网络服务的
Linux
Virtual Server
框架，如图
2
< br>所示。在
LVS
框架中提供了含有三种
< br>IP
负载均衡技术的
IP
虚拟服
务器软件
IPVS
、基于内容
请求分发
的内核
Layer-7
交换机
KTCP
VS
和集群管理软件。
可以利用
LVS
框架实现高可伸缩的、
高可用的
Web
、
Cache
、
Mail
和
Media
等网络服务；
在此基础上，可以开发支持庞大用户数
的、高可伸缩的、高可用的电子商务应用。
如奕老师主讲
图
2
：
Lin
ux
虚拟服务器框架
1.2.1Linux IPVS
在调度器的实现技术中，<
/p>
IP
负载均衡技术是效率最高的。在已有的
IP
负载均衡技术中
有通过网络地址转换（
< br>Network Address Translation
）将一组服务器构成
一个高性能的、高可
用的虚拟服务器，我们称之为
VS/NAT
技术（
Virtual Server via
Network Address Translation
）
，
大多数商品化的
IP
负载均衡调度器
产品都是使用此方法，
如
Cisco
的
LocalDirector
、
F5<
/p>
的
Big/IP
和
Alteon
的
ACEDirector
。
在分析
VS/NAT
的缺点和网
络服务的非对称性的基础上，
我们提出
通过
IP
隧道实现虚拟服务器的方法
VS/TUN
（
Virtual Server via IP Tunne
ling
）
，
和通过直接路
由实现虚拟服务器的方法
VS/DR
（
Virtual Server via Direct Routing
）
，它们可以极大地提高系
统的伸缩性。所以，
IPVS
软件实现了这三种
IP
负载均衡技术，它们的大致原理如下：
(1)Virtual Server via Network Address T
ranslation
（
VS/NAT
）
：通过网络地址转换，调度器
重写请求报文的目标地址，
根据预设的调度算法，
将请求分派给后端的真实服务器；
真实服
务器的响应报文通过调度器时，
报文的源地
址被重写，
再返回给客户，
完成整个负载调度过
程。
(2)Virtual Server via
IP Tunneling
（
VS/TUN
）
：采用
NAT
技术时，由于请求
和响应报文都
必须经过调度器地址重写，
当客户请求越来越多时
，
调度器的处理能力将成为瓶颈。
为了解
决这个问题，调度器把请求报文通过
IP
隧道转发至真实服务
器，而真实服务器将响应直接
返回给客户，
所以调度器只处理请
求报文。
由于一般网络服务应答比请求报文大许多，
采用
VS/TUN
技术后，集群系统的最大吞吐
量可以提高
10
倍。
(3)Virtual Server via Direct Routing
（
VS/DR
）
：<
/p>
VS/DR
通过改写请求报文的
MAC<
/p>
地址，将
请求发送到真实服务器，
而真实
服务器将响应直接返回给客户。
同
VS/TUN
技术一样，
VS/DR
技术可极大地提高集群系统的伸
缩性。这种方法没有
IP
隧道的开销，对集群中的真实服务
如奕老师主讲
器也没有必须支持
IP
隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同
一物理网段上。
针对不同的网络服务
需求和服务器配置，
IPVS
调度器实现了如下八种负载调度算
法：
(1)
轮叫（
Round Robin
）
：调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到
集
群中的真实服务器上，
它均等地对待每一台服务器，
而不管服务器上实际的连接数和系统负
载。
(2)
加权轮叫（
Weighted
Round Robin
）
：调度器通过“加权轮叫”调度算法
根据真实服务
器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理
更多的访问流
量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。<
/p>
(3)
最少链接（
Least Con
nections
）
：调度器通过
最少连接
调度算法动态地将网络请求调
度到已建立的链接数最少的服务器上。
如果集群系统的真实服务器具
有相近的系统性能，
采
用
最小连接
调度算法可以较好地均衡负载。
(4)
加权最少链接（
Weighted Least Connections
）
：
在集群系统中的服务器性能差异较大
的情况下，
调度器采用“加
权最少链接”
调度算法优化负载均衡性能，
具有较高权值的服务
器将承受较大比例的活动连接负载。
调度器可以自动问询真实服
务器的负载情况，
并动态地
调整其权值。
(5)
基于局部性的最少链接
（<
/p>
Locality-Based Least Connections
< br>）
：
“基于局部性的最少链接”
调度算法是针对目标
IP
地址的负载均
衡，目前主要用于
Cache
集群系统。该算法根据请求
的目标
IP
地址找出该目标
< br>IP
地址最近使用的服务器，若该服务器是可用的且没有超载，将
请求发送到该服务器；
若服务器不存在，
或者该服务器
超载且有服务器处于一半的工作负载，
则用“最少链接”的原则选出一个可用的服务器，
将请求发送到该服务器。
(6)
带复
制的基于局部性最少链接
（
Locality-Based
Least Connections with Replication
）
：
“带
复制的基于局部性最少链接”调度算法也
是针对目标
IP
地址的负载均衡，目前主要用于
Cache
集群系统。它与
LBLC
< br>算法的不同之处是它要维护从一个目标
IP
地址到一组服
务器的
映射，而
LBLC
算法维护从一
个目标
IP
地址到一台服务器的映射。该算法根据请求的目标<
/p>
IP
地址找出该目标
IP
地址对应的服务器组，按
最小连接
原则从服务器组中选出一台服务器，
若服务器没有超载，将
请求发送到该服务器，若服务器超载；则按“最小连接”原则从这个
集群中选出一台服务
器，
将该服务器加入到服务器组中，
将请求发送到该服务器。<
/p>
同时，当
该服务器组有一段时间没有被修改，
将最忙的服务器从服务器组中删除，
以降低复制的程度。
(7)
目标地址散列（
Destina
tion Hashing
）
：
“目标
地址散列”调度算法根据请求的目标
IP
地址，作为散列键（<
/p>
Hash Key
）从静态分配的散列表找出对应的服务器，若该
服务器是可用
的且未超载，将请求发送到该服务器，否则返回空。
(8)
源地址散列（
Source
Hashing
）
：
“源地址散列”调
度算法根据请求的源
IP
地址，作为
散
列键
（
Hash Key
）
从静态分配的散列表找出对应的服务器，
若该服务器是可用的且未超载，<
/p>
如奕老师主讲
将请求发送到该服务器，否则返回空。
1.2.2
虚拟服务器的实现方法
<
/p>
在网络服务中，
一端是客户程序，另一端是服务程序，在中间可能
有代理程序。由此看
来，
可以在不同的层次上实现多台服务器的
负载均衡。
用集群解决网络服务性能问题的现有
方法主要分为以
下四类。
1.2.2.1
基于
RR-
DNS
的解决方法
NCSA
的可伸缩的
WEB
服务器系统就是最早基于
RR-DNS
（
Round-Robin
Domain Name
System
）的原型系统。它的结
构和工作流程如下图所示：
图
3
：基于
RR-DNS
的可伸缩
WEB
服务器
有一组
WEB
服务器，他们通过分布式文件系统
AFS(Andrew File System)
来共享所有
的
HTML
文档。这组服务器拥有相同的域名（如
）
，当用户按照这个域名访
问时
, RR-DNS
服务器会把域名轮流解析到这组服务器的
不同
IP
地址，从而将访问负载分到
各
台服务器上。
如奕老师主讲
这种方法带来几个问题。
第一，
域名服务器是
一个分布式系统，
是按照一定的层次结构
组织的。
当用户就域名解析请求提交给本地的域名服务器，
它会因不能直接解析而向上
一级
域名服务器提交，上一级域名服务器再依次向上提交，直到
RR-DNS
域名服器把这个域名解
析到其中一台服务器的
IP
地址。
可见，
从用户到
RR-DNS
间存在多台域名服器，而它们都会
缓冲已解析的名字到
IP
地址的映射
,
这会导致该域名服器组下所有用户都会访问同一
WEB
服
务器，出现不同
WEB
服务器间严重的负载不平衡。为了保证在域名服务器中域名到
IP<
/p>
地址
的映射不被长久缓冲，
RR-DNS
在域名到
IP
地址的映射上设置一个<
/p>
TTL(Time To Live)
值，
过了
这一段时间，
域名服务器将这个映射从缓冲中淘汰。
当用户请求，
它会再向上一级域名服器
提交
请求并进行重新影射。这就涉及到如何设置这个
TTL
值，若这
个值太大，在这个
TTL
期
间，很多请
求会被映射到同一台
WEB
服务器上，同样会导致严重的负载不
平衡。若这个值
太小，例如是
0
，会导
致本地域名服务器频繁地向
RR-DNS
提交请求，增加了域名
解析的网
络流量，同样会使
RR-
DNS
服务器成为系统中一个新的瓶颈。
第二，用户机器会缓冲从名字到
IP
地址的映射，而不受<
/p>
TTL
值的影响，用户的访问请
求会被送
到同一台
WEB
服务器上。由于用户访问请求的突发性和访问方
式不同，例如有的
人访问一下就离开了，
而有的人访问可长达几个小时，
所以各台服务器间的负载仍存在倾斜
（
Skew
）而不能控制。假设用户在每个会话中平均
请求数为
20
，负载最大的服务器获得的
请求数额高于各服务器平均请求数的平均比率超过百分之三十。
也就是说，
当
TTL
值为
0
时，
因为用户访问的突发性也会存在着较严重的负载不平衡。
第三，
系统的可靠性和可维护性差。
若一台服务器失效，
会导致将域名解析到该服务器
的用户看到服务中断，即使用户按
“Reload”
按钮，也无济于事。系统管理员也不能随时地
将一台服务器切出服务进行
系统维护，
如进行操作系统和应用软件升级，
这需要修改
RR-DNS
服务器中的
IP
地址列表，把该服务器的
IP
地址从中划掉，然后等上
几天或者更长的时间，
等所有域名服器将该域名到这台服务器的映射淘汰，和所有映射到
这台服
务器的客户机不
再使用该站点为止。
1.2.2.2
基于客户端的解决方法
基于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识，
进而把以负载
均衡的方式将请求发到不同的服务器。例如，
Netscape Navigator
浏览器访问
Net
scape
的主
页时，
它会随机地从一
百多台服务器中挑选第
N
台，
最后将请
求送往
。
然
而，这不是很好的解决方法，
Netscape
只是利用它的
Navigator
避免了
RR-DNS
解析的麻烦，
当使用
< br>IE
等其他浏览器不可避免的要进行
RR-DNS
解析。
Smart Client
是
Berk
eley
做的另一种基于客户端的解决方法。服务提供一个
Ja
va Applet
在客户方浏览器中运行，
Applet
向各个服务器发请求来收集服务器的负载等信息，
再根据这
些信息将客户的请求发到相应的服务器。高可用性也在
Applet
中实现，当服务器没有响应
时，
Apple
t
向另一个服务器转发请求。这种方法的透明性不好，
Appl
et
向各服务器查询来收
如奕老师主讲
集信息会增加额外的网络流量，不具有普遍的适用性。
1.2.2.3
基于应用层负载均衡调度的解决方法
< br>
多台服务器通过高速的互联网络连接成一个集群系统，
在前端有一个基于应用层的负载
调度器。
当用户访问请求到达调
度器时，
请求会提交给作负载均衡调度的应用程序，
分析请
求，根据各个服务器的负载情况，选出一台服务器，重写请求并向选出的服务器访问，
取得
结果后，再返回给用户。
应用层负载均衡调度的典型代表有
Zeus
负载调度
器、
pWeb
、
Reverse-Pr
oxy
和
SWEB
等。
Zeus
负载调度器是
Zeus
公司的商业产品，
它是在
Zeus Web
< br>服务器程序改写而成的，
采用单
进程事件驱动的服务器结
构。
pWeb
就是一个基于
Apach
e 1.1
服务器程序改写而成的并行
WEB
< br>调度程序，当一个
HTTP
请求到达时，
pWeb
会选出一个服务器，重写请求并向这个服
务器
发出改写后的请求，等结果
返回后，再将结果转发给客户。
Reverse-
Proxy
利用
Apache
1.3
.1
中的
Proxy
模块和
Rewrite
模块实现一个可伸缩
WEB
服务器，
它与
pWeb
的不同之处在
于它要先从
Proxy
的
cache
中查找后，若
没有这个副本，再选一台服务器，向服务器发送
请求，
< br>再将服务器返回的结果转发给客户。
SWEB
是利用
HTTP
中的
redirect
错误代码，
将客
户请求到
达一台
WEB
服务器后，这个
WEB
服务器根据自己的负载情况，自己处理请求，
或者通过
redirect
错误代码将客户引到另一台
WEB
服务器，
以实现一个
可伸缩的
WEB
服务
器。
基于应用层负载均衡调度的多服务器解
决方法也存在一些问题。
第一，
系统处理开销特
别大，
致使系统的伸缩性有限。
当请求到达负载均衡调
度器至处理结束时，
调度器需要进行
四次从核心到用户空间或从
用户空间到核心空间的上下文切换和内存复制；需要进行二次
TCP
连接，一次是
从用户到调度器，另一次是从调度器到真实
服务器；需要对请求进行分
析和重写。
这些处理都需要不小的Ｃ
ＰＵ、内存和网络等资源开销，且处理时间长。所构成
系统的性能不能接近线性增加的，
一般服务器组增至
3
或
4
台时，
调度器本身可能会成为新
的瓶颈。所以，
这种基于应用层负载均衡调度的方法的伸缩性极其有限。第二，基于
应用层
的负载均衡调度器对于不同的应用，需要写不同的调度器。以上几个系统都是基于
HTTP
协
议，若对于
FTP
、
Mail
、
POP3
等应用，都需要重写调度器。
1.2.2.4
基于
IP
层负载均衡调度的解决方法
用户通过虚拟
IP
地址（
Virtual IP Address<
/p>
）访问服务时，访问请求的报文会到达负载调
度器，由它进行负载
均衡调度，从一组真实服务器选出一个，将报文的目标地址
Virtual IP
Address
改写成选定服务器的地址，报文的目标端口改写成选
定服务器的相应端口，最后将
报文发送给选定的服务器。
真实服
务器的回应报文经过负载调度器时，
将报文的源地址和源
端口改
为
Virtual IP Address
和相应的端口，
再把报文发给用户。
Berkeley
的<
/p>
MagicRouter
、
Cisco<
/p>
的
LocalDirector
、
Alteon
的
A
CEDirector
和
F5
的
Big/IP
等都是使用网络地址转换方法。
MagicRouter
是在
Linu
x 1.3
版本上应用快速报文插入技术，使得进行负载均衡调度的用
< br>如奕老师主讲
户进程访问网络设备接近核心空间的速度
，
降低了上下文切换的处理开销，
但并不彻底，
它
只是研究的原型系统，没有成为有用的系统存活下来。
Cisco
的
LocalDirector
< br>、
Alteon
的
ACEDir
ector
和
F5
的
< br>Big/IP
是非常昂贵的商品化系统，它们支持部分
T
CP/UDP
协议，有些在
ICMP
处
理上存在问题。
1.2.3VS/NAT
< br>由于
IPv4
中
IP
地址空间的日益紧张和安全方面的原因，很多网络使用保留
IP
地址
（
10.0.0.0/
255.0.0.0
、
172.16.0.0/
255.128.0.0
和
192.168.0.0
/
255.255.0.0
）
。这些地
址不在
Internet
上使用，而是专门为内部网络预留的。
当内部网络中的主机要访问
Internet
或被
Internet
访问时，就需要采用网络地址转换（
Network Address Translation,
以下简称
NAT
）
，
将内部地址转
化为
Internets
上可用的外部地址。
< br>NAT
的工作原理是报文头（目标地址、源
地址和端口等
）被正确改写后，客户相信它们连接一个
IP
地址，而不同
IP
地址的服务器组
也认为它们是与客户直
接相连的。由此，可以用
NAT
方法将不同
IP
地址的并行网络服务变
成在一个
IP
地址上的一个虚拟服务。
VS
/NAT
的体系结构如图
4
所示。
在一组服务器前有一个调度器，
它们是通过
Switch/HUB
相连接的。
这些服务器提供相同的网络服
务、
相同的内容，
即不管请求被发送到哪一台服务
器，
执行结果是一样的。
服务的内容可以复制到每台
服务器的本地硬盘上，
可以通过网络文
件系统（如
NFS
）共享，也可以通过一个分布式文件系统来提供。
如奕老师主讲
图
4
：
VS/NAT
的体系结
构
客户通过
Virtual IP
Address
（虚拟服务的
IP
地址
）访问网络服务时，请求报文到达调度
器，调度器根据连接调度算法从一组真实服务器中
选出一台服务器，将报文的目标地址
Virtual IP
Address
改写成选定服务器的地址，
报文的目标端口改写
成选定服务器的相应端口，
最后将修改后的报文发送给选出的服务器。同时，调度器在连
接
Hash
表中记录这个连接，
当这
个连接的下一个报文到达时，从连接
Hash
表中可以得到原选
定服务器的地址和端口，
进行同样的改写操作，
并将报文传给原
选定的服务器。
当来自真实服务器的响应报文经过调
度器时，调
度器将报文的源地址和源端口改为
Virtual IP Address
和相应的端口，再把报文发
给用户。当连接终止或超时，调度器将这个连接从
连接
Hash
表中删除。
在
一些网络服务中，它们将
IP
地址或者端口号在报文的数据中传送，若我们只对报文
头的
IP
地址和端口号作转换，这样就会出现不一致
性，服务会中断。所以，针对这些服务，
需要编写相应的应用模块来转换报文数据中的<
/p>
IP
地址或者端口号。我们所知道有这个问题
的网络服务有
FTP
、
IRC
、
H.323
、
CUSeeMe
、
Real
Audio
、
Real
Video
、
Vxtreme / Vosiac
、
VDOLive
、
VIV
OActive
、
True Speech
、
RSTP
、
PPTP
、
StreamWorks
、
NTT AudioLink
、
NTT
SoftwareVision
、
Yamaha
MIDPlug
、
iChat Pager
、
Quake
和
Diablo
。
-
-
-
-
-
-
-
-
-
上一篇：三年级下册英语跟读
下一篇：(完整版)最专业的无人机中文英语对应词汇