集群

什么是集群

计算机集群简称集群是一种计算机系统,它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上,他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点,通常通过局域网连接,但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机,比如工作站或超级计算机性能价格比要高得多。

集群就是一组独立的计算机,通过网络连接组合成一个组合来共同完一个任务

LVS在企业架构中的位置

lvs的优点 lvs的三种工作模式_服务器

集群的特点

1)高性能performance
2)性价比
3)可伸缩性
4)高可用性

常用集群软硬件

常用开源集群软件有:lvs,keepalived,haproxy,nginx,apache,heartbeat

常用商业集群硬件有:F5,Netscaler,Radware,A10等

LVS简介

LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统。
LVS采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。为此,在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性

可以访问
观看 吴佳明(普空):LVS在大规模网络环境中的应用 的视频

LVS 的四种工作模式原理简介及优缺点

1、NAT模式

原理

这个是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时(请求的目的IP为VIP),根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址(RIP),这样真实服务器(RS)就能够接收到客户的请求数据包了。真实服务器响应完请求后,查看默认路由(NAT模式下我们需要把RS的默认路由设置为LB服务器。)把响应后的数据包发送给LB,LB再接收到响应包后,把包的源地址改成虚拟地址(VIP)然后发送回给客户端。

lvs的优点 lvs的三种工作模式_lvs的优点_02


原理图简述:

1)客户端请求数据,目标IP为VIP

2)请求数据到达LB服务器,LB根据调度算法将目的地址修改为RIP地址及对应端口(此RIP地址是根据调度算法得出的。)并在连接HASH表中记录下这个连接。

3)数据包从LB服务器到达RS服务器webserver,然后webserver进行响应。Webserver的网关必须是LB,然后将数据返回给LB服务器。

4)收到RS的返回后的数据,根据连接HASH表修改源地址VIP&目标地址CIP,及对应端口80.然后数据就从LB出发到达客户端。

5)客户端收到的就只能看到VIP\DIP信息。

NAT模式优缺点:

1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写,因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈,一般要求最多之能10-20台节点

2、只需要在LB上配置一个公网IP地址就可以了。

3、每台内部的节点服务器的网关地址必须是调度器LB的内网地址。

4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

2、TUN模式(隧道模式)

原理
virtual server via ip tunneling模式:采用NAT模式时,由于请求和响应的报文必须通过调度器地址重写,当客户请求越来越多时,调度器处理能力将成为瓶颈。为了解决这个问题,调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文,由于一般网络服务应答数据比请求报文大很多,采用VS/TUN模式后,集群系统的最大吞吐量可以提高10倍。

VS/TUN的工作流程图如下所示,它和NAT模式不同的是,它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后解开IP tunnel后,进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。

Tunnel原理流程图:

lvs的优点 lvs的三种工作模式_lvs的优点_03

原理图过程简述:

1)客户请求数据包,目标地址VIP发送到LB上。

2)LB接收到客户请求包,进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。

3)RS节点服务器根据IP Tunnel包头信息(此时就有一种逻辑上的隐形隧道,只有LB和RS之间懂)收到请求包,然后解开IP Tunnel包头信息,得到客户的请求包并进行响应处理。

4)响应处理完毕之后,RS服务器使用自己的出公网的线路,将这个响应数据包发送给客户端。源IP地址还是VIP地址。

NAT模式优缺点:
优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

缺点:隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上。

3、DR模式(直接路由模式)

原理
DR模式是通过改写请求报文的目标MAC地址,将请求发给真实服务器的,而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样,DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销,对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上,必须在同一个局域网环境。

DR模式是互联网使用比较多的一种模式。

DR模式原理图:

lvs的优点 lvs的三种工作模式_服务器_04

DR模式将报文直接路由给目标真实服务器。在DR模式中,调度器根据各个真实服务器的负载情况,连接数多少等,动态地选择一台服务器,不修改目标IP地址和目标端口,也不封装IP报文,而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址,并且又在同一个局域网。那么根据局域网的通讯原理,真实复位是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候,解开IP包头查看到的目标IP是VIP。(此时只有自己的IP符合目标IP才会接收进来,所以我们需要在本地的回环借口上面配置VIP。
另:由于网络接口都会进行ARP广播响应,但集群的其他机器都有这个VIP的lo接口,都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。)然后真实服务器做成请求响应,之后根据自己的路由信息将这个响应数据包发送回给客户,并且源IP地址还是VIP。

DR模式小结:

1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP,目的地址仍然是VIP地址。

2、请求的报文经过调度器,而RS响应处理后的报文无需经过调度器LB,因此并发访问量大时使用效率很高(和NAT模式比)

3、因为DR模式是通过MAC地址改写机制实现转发,因此所有RS节点和调度器LB只能在一个局域网里面

4、RS主机需要绑定VIP地址在LO接口上,并且需要配置ARP抑制。

5、RS节点的默认网关不需要配置成LB,而是直接配置为上级路由的网关,能让RS直接出网就可以。

6、由于DR模式的调度器仅做MAC地址的改写,所以调度器LB就不能改写目标端口,那么RS服务器就得使用和VIP相同的端口提供服务。

官方三种负载均衡技术比较总结表:

lvs的优点 lvs的三种工作模式_fullnat_05

LVS-FULLNAT转发模式

在大规模的网络下,在淘宝的业务中,官方LVS满足不了需求;原因有3点,
1) 刚才讲三种转发模式,部署成本比较高;
2) 和商用的负载均衡比,LVS没有DDOS防御攻击功能;
3) 主备部署模式,性能无法扩展;一个VIP下的流量特别大怎么办?

FULLNAT原理:
FULLNAT转发数据包是类似NAT模式,IN和OUT数据包都是经过LVS;唯一的区别:后端RealServer 或者交换机不需要做任何配置。
FULLNAT的主要原理是引入local address(内网ip地址),cip-vip转换为lip->rip,而 lip和rip均为IDC内网ip,可以跨vlan通讯

NAT原理图:

lvs的优点 lvs的三种工作模式_lvs_06

FULLNAT原理图:

lvs的优点 lvs的三种工作模式_lvs的优点_07

如图所示,相比NAT模式,FullNAT多了一个Local IP,IP地址转换时,源和目的IP都改了,即SNAT+DNAT。

FULLNAT模式的优缺点:
FULLNAT一个最大的问题是:RealServer无法获得用户IP;为了解决这个问题我们提出了TOA的概念,主要原理是:将client address放到了TCP Option里面带给后端RealServer,RealServer上通过toa内核模块hack了getname函数,给用户态返回TCP Option中的client ip。

http://atong.blog.51cto.com/2393905/1348602