标签：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 虚拟服务/网络地址转换）
此类型的网络拓朴如下图：
术语说明：
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 虚拟服务/直接路由）
此类型的拓扑大致有以下两种，第一种：
说明：这种VS/DR类型架构中director只有一张网卡接入到网络中，vip与dip都配置在这网卡上，用子接口的方式加以区别。
第二种拓扑：
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 虚拟服务/隧道)
大致拓扑如下图：
基于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全部使用公网地址；
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集群系统。
本文出自 “专注运维，与Linux共舞” 博客，请务必保留此出处http://zhaochj.blog.51cto.com/368705/1643712
标签：lvs
原文地址：http://zhaochj.blog.51cto.com/368705/1643712
