转 LVS体系结构分析

问题

如今，无论在企业网、园区网还是在广域网如Internet上，业务量的发展都超出了过去最乐观的估计；同时，用户不断地追求更高的机器性能，而升级单一的服务器系统，往往造成过高的投入和维护成本，性价比大大低于预期。这一切，不仅对硬件，也对软件平台提出了更高的要求：

• 可扩展性：良好可扩展性的计算机系统能够使得性能随着成本的增加而线性的增长。并且很容易对其进行精简或者扩充。
• 全天候的可用性支持：严格的商业环境需要软硬件系统提供透明的、自动适应的可用性支持，保证24×7的系统正常运行。
• 可管理性：系统可以很庞大，但是要能够易于管理。
• 相对的成本/性能优势：构造这样的系统，在投入成本上是经济的，容易根据具体的需求定制合适价位的目标系统。

---

回页首

解决

通过之前的分析我们知道，集群系统在成本、效益上的的高度可扩展性正是解决这个问题的有效思路。通过相对总体成本较低的计算机群集，可以实现单一系统无法提供的强大性能。这里我们针对互联网的应用情况提出具备以下特性的系统：

• 高可扩展性
• 高可用性
• 高性能

不妨称之为"三高"系统。

---

回页首

LVS体系结构介绍

Linux Virtual Server项目是由 章文嵩博士（ 开放源码及Linux内核的开发者。著名的Linux集群项目－－LVS(Linux Virtual Server) 的创始人和主要开发人员。他目前工作于国家并行与分布式处理重点实验室，主要从事集群技术、操作系统、对象存储与数据库的研究。他还在自由软件的开发上花费了大量时间，并以此为乐。）主持的著名开放源码项目，一个实现"三高"系统的解决方案。LVS旨在解决高速发展的Web商务中日益凸现的问题：如何在有限资金投入的情况下，最大幅度的提高Web站点的潜在服务性能。

LVS是一个Linux平台下的软件工具。通过LVS，你可以快捷方便的组建一个带有第四层负载均衡功能的集群系统。并且，借助第三方的工具包，还可以实现对LVS集群进行可用性支持的功能扩展。首先让我们来看一下LVS的体系结构示意图：

图一：LVS的三层体系结构示意图

从上图我们看出，LVS的抽象体系结构分为三个层次。 第一层是负载均衡器，这是集群的唯一入口。从客户端的角度看，集群通过这层的服务体现为一个基于IP地址的单一系统映像（SSI），整个集群共用这个虚拟地址，通过它客户端可以把整个集群看作一个独立的具有合法IP地址的主机系统，客户端的所有访问都发往这个虚拟IP地址。

但我们也发现，如果仅有一台负载均衡器，容易造成负载均衡器成为集群的单点失效，使其成为集群中最脆弱的环节。因此，有必要提供容错机制，能够在负载均衡器失效的时候进行自动检测并平滑替换，也就是常说的HA技术。在上图的结构中，有一个以备份均衡身份运行的结点实时地监控负载均衡器的运行状态，并根据检测到的状态做出响应：报警、接管、恢复。具体细节将在HA章节讨论。

第二层是提供实际服务的服务器群。客户端发出的服务请求经过均衡器处理以后，转交到服务池由具体的服务器响应请求并返回数据。通常我们会在服务结点池上提供Web服务、FTP服务或者视频点播服务。由于单一系统无法应付高峰值得数据访问，那么通过多台服务器分担这些负载就比较经济可行了。

服务器结点也有可能出现暂时失效的情况，特别是在结点提供多种服务的时候，系统的随机故障或外部环境的突变都可能造成该节点的某个服务暂时不可用。因此，由负载均衡扩展出的容错机制要能够识别这种错误，及时进行处理。同样，当错误排除后，集群能够自动识别恢复事件，把好的结点重新纳入集群继续运行。

第三层是存储服务系统，为整个集群内部运行提供稳定、一致的文件存取服务。这一层作为LVS集群的扩展，可以为集群节点池提供单一的文件系统入口，即在每一台服务结点上都共用同一个根（/）；并且自动完成不同结点访问文件系统所引发的文件锁定、负载均衡、容错、内容一致、读写事务等底层功能，对应用层提供一个透明的文件访问服务。

LVS集群属于松耦合集群系统。由于LVS在IP层上实现了SSI，因此不需要在集群中部署特殊的中间件层或者OS扩展，对服务器结点OS的兼容性比较好。对于部署LVS的内部结点而言，基本上可以兼容多数的IP应用，不需要做复杂的移植和安装工作，每个内部结点可以看成相对独立的服务器系统。即使在负载均衡器上，IPVS的核心功能也是透明的提供给用户空间，不影响本机的正常的网络应用。

其实在现实中，有许多技术能够实现这样的系统。它们借助在某个层面上的负载均衡，将网络请求化整为零，由大量集群的服务结点来共同分担，以实现性能最大化的一项集群技术。

---

回页首

负载均衡技术

其实，负载均衡并非传统意义上的"均衡"，一般来说，它只是把有可能拥塞于一个地方的负载交给多个地方分担。如果将其改称为"负载分担"，也许更好懂一些。说得通俗一点，负载均衡在网络中的作用就像轮流值日制度，把任务分给大家来完成，以免让一个人累死累活。不过，这种意义上的均衡一般是静态的，也就是事先确定的"轮值"策略 。

与轮流值日制度不同的是，动态负载均衡通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理分配出去。结构上分为本地负载均衡和地域负载均衡(全局负载均衡)，前一种是指对本地的服务器集群做负载均衡，后一种是指对分别放置在不同的地理位置、在不同的网络及服务器群集之间作负载均衡。

负载均衡体系中，每个服务结点运行一个所需服务器程序的独立拷贝，诸如Web、FTP、Telnet或e-mail服务器程序。对于某些服务（如运行在Web服务器上的那些服务）而言，程序的一个拷贝运行在群集内所有的主机上，而网络负载均衡则将工作负载在这些主机间进行分配。对于其他服务（例如e-mail），只有一台主机处理工作负载，针对这些服务，网络负载均衡允许网络通讯量流到一个主机上，并在该主机发生故障时将通讯量移至其他主机。

---

回页首

负载均衡实现结构

总的来说，在现有网络结构之上，负载均衡提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。主要任务如下：

• 解决网络拥塞问题，服务就近提供，实现地理位置无关性
• 为用户提供更好的访问质量
• 提高服务器响应速度
• 提高服务器及其他资源的利用效率
• 避免了网络关键部位出现单点失效

对这样一个网络的负载均衡技术，我们从网络的不同实现层次入手，针对具体的性能瓶颈进行分析。从客户端应用为起点纵向考量，可以把负载均衡技术分为客户端负载均衡技术、应用服务器技术、高层协议交换、网络接入协议交换等几个不同层次的实现方式：

负载均衡的层次

目前在每一个层次都有大量的技术实现负载均衡的主要功能，其优缺点也各不相同，而对于我们了解LVS的目的而言，只需要关心网络接入协议的负载均衡技术即可。这一层次的负载均衡技术特点是：

• 执行效率高，因为基于底层的协议，可以通过硬件体系进行部署，也可以在OS的核心层实现。
• 兼容性强，接入协议往往能够兼容大多数现有的主流网络应用，比如IPv4体系中的IP层。
• 体系实现相对简单，比起基于内容的高层交换，它不需要复杂的模式匹配机制，主要通过端口映射进行数据交换，规则简单。

下面我们就分析一下基于负载均衡技术的LVS框架与实现方法。

---

回页首

LVS的IP负载均衡技术

根本上将，LVS的实现基础是IP交换，也就是前面提到的接入协议交换技术。但LVS的体系结构具备一定的可扩展性，可以实现高性能、高可扩展性、易管理性等诸多特点，成为一个以负载均衡为核心的真正意义的集群系统。

首先我们了解一下LVS的负载均衡模型，共有三种：地址转换（NAT）、IP隧道（IP Tunneling）和直接路由（DR）模型。

◆地址转换模式NAT

NAT结构图与NAT包处理流程

我们看到，NAT的网络结构呈现为一种类似防火墙的私有网结构，中间的虚线表示网络隔离带。通过内部IP地址，将服务结点池同互联网隔离开来。服务结点无法和客户端直接通信，不论是请求数据还是应答数据，都需要经过负载均衡器进行IP包处理工作。

NAT中主要的工作就是改写IP包的源、目的地址信息，使得发向VIP的请求数据经过改写后重新指向内部主机；同样内部的应答数据经过负载均衡器改写后，以VIP作为源地址发至请求者。这样的模式也称作网络地址转换（也有叫做IP地址伪装），我们在代理服务器、Iptables、透明网关等应用中，都使用到这种模型，可以说这是一件比较成熟的技术。

由于使用NAT方式，要对进入和流出集群的网络包进行改写包头地址的工作，在负荷比较重的时候会影响整个集群的性能，负载均衡器容易成为瓶颈。

◆ IP隧道模式 IPIP

IPIP结构图与IPIP包处理流程

IPIP模式采用的是开放的网络结构，服务结点拥有合法的互联网IP地址，可以通过路由路径将应答包直接返回给客户端。因此，负载均衡器仅仅处理进入集群的请求数据包，而返回包不经过路由器。因此，这种模式称作单工连接模式（单方向连接工作模式）。负载均衡器和服务结点的连接可以是LAN，也可以在不同的网络上，只需要保证负载均衡器能够将IP包发送至服务结点即可。

负载均衡器收到客户端的请求包后，通过IPIP协议为该IP包重新处理，形成以选定的服务结点为目的IP的新的IP包，原有的IP包数据则封装在新的IP包里。服务结点收到均衡器发来的IPIP数据后，将该包解开，根据其内的客户端地址（源地址）将处理结果直接返回给客户端，而应答包的源地址则成为集群的虚拟地址VIP。

IPIP模式的技术在其他领域也有体现，因为对IP进行重新封装，整个过程对应用层仍然是透明的。PPTP协议就是对IP隧道协议的一种应用。不过目前IPIP仅仅在Linux系统上实现。该协议必须在Kernel中打开设备选项支持，通过tunel设备绑定VIP，服务结点在返回应答数据时，可以以VIP作为源地址构筑应答包。

◆ 直接路由模式 DR

DR结构图与DR包处理流程

和IPIP模式一样，DR模式也是采用单工的连接方式，应答数据不再经过均衡器而直接返回给客户端。服务结点也必须拥有能够到达客户端的合法IP地址。而且，DR模式中，负载均衡器和服务结点必须位于同一个网段。

负载均衡器接收到客户端请求后，选择合适的服务结点，然后改写该请求包的MAC地址部分，使之成为目的服务结点的MAC地址，再将此包广播到均衡器所在的网段。由于每个服务结点都拥有一个虚拟的网括设备（可以是dummy0或者lo:0），这些设备上绑定了和均衡器一样的VIP，只是该设备并不响应对VIP的RAP解析，不会和均衡器的Vip地址冲突。负载均衡器收到符合自身MAC的IP包后，经过处理后直接将应答数据返回给客户，而此时的源地址仍然是VIP。这样，在客户端看来，访问的和接受响应的始终是集群的VIP地址了。

---

回页首

综合比较

虽然LVS支持三种负载均衡模式，但是从上面的分析我们发现，根据负载均衡器处理IP包的进出方式，LVS实际上包含了两种模型：单工处理和双工（双向连接工作模式）处理。显然，NAT地址转换模式属于双工连接处理，在这种模式下，负载均衡器不但需要处理进入集群的IP包，而且还要处理集群内部节点返回的应答IP包，一个用户从发出访问请求到接受响应，都要经过集群的核心负载均衡器的处理，因此称之为双工连接处理。而其他两种模式中，负载均衡器仅仅处理进入集群的IP请求包，而集群内部结点的响应数据则不再通过负载均衡器返回客户端，而是通过节点到客户端的路由通道直接发送到目的地。由于均衡器仅处理一次完整连接的IP请求部分，而对IP的应答数据则不处理，所以称之为单工连接模式。

二者比较，有什么有缺点呢。要知道，在现今的Web世界中，大多数的网络请求比较小，无非是一些URL页面请求，GET或者POST表单，在么就是某些指令等等，这些数据基本上在几百到几K个字节。对这样的IP数据包进行处理是比较轻松的事。而相反，Web中的应答数据通常很大，一个普通的Web页面也要几十K，更何况返回的如果是视频、音频流了，加上日益疯狂的网络下载，即使再强劲的处理器也无法承受这样大量的IP包处理工作。

因此，在IP负载均衡中，如果使用双工模式（NAT），不仅要对进入集群的请求做出处理（改写IP包的源、目的地址），还要对服务结点返回的大量数据做同样的工作。那么，随着集群服务节点池规模的增长，负载均衡器的处理能力很快就会达到饱和，也大大影响了LVS集群的规模可扩展性。而使用IPIP或者DR模式，负载均衡器只需要处理相对很少的IP数据包，对于大量的返回数据，都由服务节点通过路由器、交换机等设备直接返回给客户端。因此在规模可扩展性这一点上，单工模式有可扩展性方面的优势。

事物的存在总有他的道理。作者当初设计这三种负载模型，肯定是各有其有缺点的。NAT也并非一无是处。NAT虽然在性能表现上弱于其它两种模型，但是集群结点支持更多的操作系统，在网络安全性方面也比较高一些。以下是三者在各方面的比较：

三种模式的比较

	NAT模式	IPIP模式	DR模式
对服务结点的要求	服务结点可以是任何操作系统	服务结点必须支持IP隧道协议，目前只有Linux	服务结点支持虚拟网卡设备，能够禁用该设备的ARP响应功能
网络要求	拥有私有IP地址的局域网络	拥有合法IP地址的局域网或者广域网	拥有合法IP地址的局域网，服务结点与均衡器必须在同一个网段
通常支持的结点数量	10~20个，试均衡器的处理能力而定	较高，可以支持到100个服务结点	较高，可以支持到100个服务结点
网关	均衡器即为服务结点的网关	服务结点同自己的网关或者路由器连接，不经过均衡器	服务结点同自己的网关或者路由器连接，不经过均衡器
服务结点安全性	较好，采用内部IP，服务结点隐蔽	较差，采用公用IP地址，结点完全暴露	较差，采用公用IP地址，结点完全暴露
IP要求	仅需要一个合法IP地址作为VIP	除VIP外，每个服务结点需拥有合法的IP地址，可以直接路由至客户端	除VIP外，每个服务结点需拥有合法的IP地址，可以直接路由至客户端

综上所述，我们在选择LVS作为集群负载均衡解决方案的时候，首先根据单前应用环境的情况确定使用哪一种IP负载均衡结构。如果你只拥有一个合法的IP地址，或者你需要构造一个安全的集群，又不太担心性能问题的话，完全可以使用NAT模式；如果对性能有比较高的要求，而应用又是基于Linux的话，使用IPIP或者DR模式一定会给你一个惊喜。

<!-- CMA ID: 21311 --><!-- Site ID: 10 --><!-- XSLT stylesheet used to transform this file: dw-article-6.0-beta.xsl -->