集群及LVS基础知识整理

目录

1、常见集群环境介绍

2、LVS三种类型介绍

3、LVS各种调度算法介绍

1、常见集群环境介绍

    在说lvs前先来说说集群,根据所适用场景的不同,IT人员可能希望服务器运行的时间更长,最好一年365天,一天72小时都不间断的运行,也可能希望应用程序运行得更快,而有些数字领域里则需要进行大规模的数值运算,这些都会涉及到计算机群集。

    最常见的集群有以下三种类型:负载均衡集群(LB:Load Balance),高可用集群(HA:High Availability),高性能集群(HP:High Performance)。

    LB集群主要有应用层和传输层两个层次上的实现,有硬件的实现,也有开源软件的实现,硬件类型的LB设备主要有美国的F5的BIG/IP、思杰的NetScaler、A10、Array、RadWare,开源软件的实现主要有LVS(工作在四层)、Haproxy(四层、七层都可实现,但主要是七层的实现)、nginx(应用层的实现)。

    HA集群中开源的解决方案主要有heartbeat、keepalived、corosync+pacemaker、cman+rgmanager、cman+pacemaker。

    HP集群使用在一些特殊的场景,此处不讨论。

2、LVS三种类型介绍

先对LVS的一些基础知识做一些介绍:

    LVS全称为Linux Virtual Server(Linux虚拟服务)工作在OSI七层模型中的第四层,是四层交换技术,它是工作在内核中的一段代码,根据目标地址和目标端口实现数据转发,它并且是工作在netfiler框架上。LVS分为两个部份,一部份工作在内核,叫ipvs,另一部份工作在用户空间,叫ipvsadmin,用此用户空间工具编写调度规则。

    LVS的架构类型大体上分为三种类型,一是VS/NAT,二是VS/DR,三是VS/TUN。下边分别对这三种类型进行阐述。

2.1、VS/NAT(virtual server/network address translation 虚拟服务/网络地址转换)

此类型的网络拓朴如下图:

wKiom1VKwyXxPViZAAMtOT1Qf5w060.jpg

术语说明:

director表示调度器,这里指的就是lvs服务器;

real server表示在调度器后端的真实为外提供实际应用服务的服务器;

cip表示访问应用服务的客户端的ip地址;

vip表示director对外提供服务的那个ip地址;

dip表示与后端服务器接入同一网络的ip地址;

rip表示后端服务器的ip地址。


VS/NAT类型调度的大致过程:

    首先客户端向director的vip发起服务请求,在netfiler框架上的INPUT链上ipvs发现客户端请求的是自己定义好的集群服务,那director采用静态或动态算法从自己的规则中挑选出一个real server出来,再把客户端请求报文做DNAT转换,把请求报文的目的地址修改成已挑选出real server的ip地址,然后重新封装报文发送给real server;而当real server收到director的请求报文后,就会分析此报文看对方请求的是什么资源,再把资源准备好封装成响应报文发送给director,director再做SNAT,把源地址修改成自己的vip地址后把报文发送给客户端;在客户端看来他是直接访问的是director,而作出响应的也是director,其后端的real server对客户端是不可见的,对用户是透明的。


VS/NAT类型的工作特性总结如下:

a、内部的real server应用服务器使用私有地址,real server的网关必须指向dip;

b、请求报文与响应报文都需要经过director,对director的负载压力较大,在高负载场景,director易成为性能瓶颈;

c、对外提供服务的端口和real server提供服务的端口可不相同,即支持端口映射;

d、real server对操作系统不做任何修改,所以可以使用任意的操作系统。   


2.2、VS/DR(virtual server/direct routing 虚拟服务/直接路由)

此类型的拓扑大致有以下两种,第一种:

wKioL1VKxLzhti1oAAMtXaQFAfY315.jpg

说明:这种VS/DR类型架构中director只有一张网卡接入到网络中,vip与dip都配置在这网卡上,用子接口的方式加以区别。 

第二种拓扑:

wKioL1VKxO_hmbShAAPob7GB8nM905.jpg


VS/DR类型的大致调度过程:

    客户端请求报文到达director的vip后,director发现是请求是一个集群服务,director采用静态或动态算法挑选出一个real server,这时director不再像VS/NAT中会修改报文中ip首部的目标ip,而是把目标MAC修改成已挑选real server的rip的MAC地址,因dip与rip是在同一个二层网络中,只需要MAC地址即可完成寻址,所以被修改了目的MAC的报文能成功送到real server,real server把报文拆开后发现目的MAC的确是rip上的MAC,所以它会处理这个报文,real server把客户端要请求的资源准备好后,强行让报文从“lo:0”这样的子接口上送出去,这个接口配置了vip的地址,每个real server都会配置rip与vip的地址,所以为了让vip地址不会导致冲突,所以各real server都要采取一定的机制让配置在"lo:0"上的vip地址不被网络上的其他设备得知,这个地址只是用在响应报文中把响应报文的源地址封装成vip的,这样响应报文就可通过real server直接到达客户端,而不必再通过director的再次转发,这样,接入的报文通过director,而响应报文则直接送到客户端,而客户端看到的报文也是从vip送回来的(其实是从real server来的),这种VS/DR模型让director得到的解放,只处理接入报文,压力也变得更小,能带动的real server也更多,处理并发能力更强,但后端real server配置比较麻烦。


VS/DR类型的工作特性总结如下:

a、各real server的lo回环地址上需要配置一个子接口,此子接口的ip为vip地址,并保证此ip不接受外界任何的ARP请求;

b、此系统需要保证前端路由将目标地址为vip的报文统统发往directory的vip地址,而不能发往real server上的vip;

 解决方案:方案一、在前端路由器上进行静态地址绑定,但路由器是运营商的,不具有路由器的管理权限;方案二、修改real sedrver的arptables防火墙,使其忽略对对lo接口上arp报文的响应,并不主动向网络通报lo接口上的信息;方案三、修改real server上系统的内核参数,使系统不接收对lo接口的arp的请求报文,也不主动通报lo接口的信息,这在2.6以后的内核中很容易实现。

c、real server可以使用私有地址,也可以使用公网地址;

d、real server跟directory必须在同一物理网络中,这是因为directory要将报文转发给real server时,并没有改变目标IP(保持vip),而是把目标MAC修改成了从各real server挑选出来的rip的MAC地址,而MAC之间的通信是基于二层的,所以不能跨网段进行,这就导致采用VS/DR构架的系统只能在同一个机房实现;

e、请求报文经过directory,但响应报文必须不能经过directory,不支持端口映射功能;

f、real server可以是大多数常见的操作系统,只要支持隐藏arp通告的相关功能;

g、real server的网关绝对不允许指向dip。


2.3、VS/TUN(virtual server/tunneling 虚拟服务/隧道)

 大致拓扑如下图:

wKiom1VKxLaBJ5avAAUwgfl0TZA654.jpg

基于VS/TUN类型的集群主要是用在架设cache server集群上,调度器与real server可能不在同一个物理网络中,所以可跨地域、跨机房部署。


VS/TUN类型调度的大致过程:

    VS/TUN类型利用了IP隧道技术,把一个IP报文封装了另一个IP报文,这可以使把目标为一个IP的报文能封装转发到另一个IP地址。请求报文到达director后,director采用静态或动态算法挑选一个在隧道上的real server地址,把原来的源地址为cip,目标地址为vip的ip报文又封装在另一个IP报文上,把此IP报文送到隧道上转以给real server,real server拆开报文看到目标地址是vip,而自己的“lo:0”接口上又配置了vip,所以能正常的处理此报文,将响应报文准备好后,又可直接送达到cip。


VS/TUN类型工作的特性:

a、rip、dip、vip全部使用公网地址;(dip与rip似乎也可以使用私有ip,这个不确定)

c、请求报文经过directory,但响应报文不会经过directory,不支持端口映射功能;

d、real server的操作系统必须支持隧道功能。


3、LVS各种调度算法介绍

3.1、静态调度算法

静态调度算法仅根据调度算法本身进行调度。

a)、rr:round robin(轮流,轮询,轮叫),这种算法是起点公平,但根据时间推移,各real server会产生负载不均衡的情况;

b)、wrr:weighted round robin(加权的轮询),用于real server服务器硬件性能不同时的场景;

c)、sh:source hashing(源地址hash),表示来源于同一个cip的请求将始终被定向到同一个rs,使用在需要session保持的场景,但这种算法又打破了负载均衡的初衷;

d)、dh:destination hashing(目标地址hash),表示访问同一地址的资源始终被定向到同一个real server,用在内部访问外部网络时有两个出口(防火墙)时的特殊场景;

3.2、动态调度算法

动态调度算法根据算法及各real server当前的负载状况进行衡量计算后再进行调度。

e)、lc:least connection(最少连接),lc算法是把新的连接调度给当前连接数最小的real server;

Overhead(负载)=Active*256+Inactive,值越小,越先被调度到

f )、wlc:weighted least connection(带权重的最少连接),此算法是lc算法的一个补充,各real server用一个权值来代表其处理能力,director尽可能使用其调度按照其权值的比例来调度,这是IPVS的默认算法;

Overhead(负载)=(Active*256+Inactive)/weighted,这种算法会导致一种现象,在集群初始状态时,各real server没有活动连接,而在director的调度规则中把权重小的real server排在了前边,那最开始director会调度到权重小的real server上,而在现实中我们希望是先调度到处理能力强的(权重大)real server上;

g)、sed:shoutest expection delay(最短期望延迟),表示让在初始状态时能让director挑选到权重大的real server,即使是权重小的real server在director规则中的前边,这种算法在各real server权重相差较大时会导致权重小的real server在一段时间内不会分配连接请求;

 Overhead=(Active+1)*256/weight

h)、nq:never queue(永不排队),表示在初始状态时director会依据weight的大小至上而下的为每一个RS分配一个连接,保证每一个real server都能在最短的时间内得到连接请求,解决了sed算法中real server有可能会在一段时间内不会分配到连接请求的问题;

i)、lblc:Locality-Based Least Connection(基于局部性的最少连接),此算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统;

j)、lblcr:Replication lblc(带复制功能的lblc),此算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统。

你可能感兴趣的:(集群,LVS,基础知识)