1.当用户请求到达DirectorServer,此时请求的数据报文会先到内核空间的PREROUTING链。
此时报文的源IP为CIP,目标IP为VIP
2. PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
3. IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将
目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改,
仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址
4. 由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,
那么此时数据包将会发至Real Server。
5. RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给
eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP
6.响应报文最终送达至客户端
7.数据流向:DR:client ->vs(调度server1) ->RS(server2.3) ->client
特点1:保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS
RS可以使用私有地址;也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问
RS跟Director Server必须在同一个物理网络中
所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
不支持地址转换,也不支持端口映射
RS可以是大多数常见的操作系统
RS的网关绝不允许指向DIP(因为我们不允许他经过director)
RS上的lo接口配置VIP的IP地址
缺陷:RS和DS必须在同一机房中
LVS 由2部分程序组成,包括 ipvs 和 ipvsadm。
1. ipvs(ip virtual server):一段代码工作在内核空间,叫ipvs,是真正生效实现调度的代码。
2. ipvsadm:另外一段是工作在用户空间,叫ipvsadm,负责为ipvs内核框架编写规则,定义谁是
集群服务,而谁是后端真实的服务器(Real Server)
1.轮叫调度(RoundRobin Scheduling)
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,
即每次调度执行 i = (i + 1) mod n,并选出第 i 台服务器。算法的优点是其简洁性,它无需记录
当前所有连接的状态,所以它是一种无状态调度。
2.加权轮叫调度(Weighted RoundRobin Scheduling)
加权轮叫调度 (Weighted RoundRobin Scheduling)算法可以解决服务器间性能不一的情况,
它用相应的权值表示服务器的处理性能,服务器的缺省权值为 1。假设服务器 A 的权值为
1,B 的 权值为 2,则表示服务器 B 的处理性能是 A 的两倍。加权轮叫调度算法是按权值的高
低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服 务器比权值低的服务
器处理更多的连接,相同权值的服务器处理相同数目的连接数。
3.最小连接调度(LeastConnection Scheduling)
最小连接调度(Least Connection Scheduling)算法是把新的连接请求分配到当前连接数最小
的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服
务 器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台
服务器,其连接数加 1;当连接中止或超时,其连接数减一。
4.加权最小连接调度(Weighted LeastConnection Scheduling)
加权最小连接调 度(Weighted LeastConnection Scheduling)算法是最小连接调度的超集,各
个服务器用相应的权值表示其处理性能。服务器的缺省权值为 1,系统管理员可以动态地设
置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权
值成比例。
5.基于局部性的最少链接(LocalityBased Least Connections Scheduling)
基 于局部性的最少链接调度(LocalityBased Least Connections Scheduling,以下简称为
LBLC)算法是针对请求报文的目标 IP 地址的负载均衡调度,目前主要用于 Cache 集群系统,
因为在 Cache 集群中 客户请求报文的目标 IP 地址是变化的。这里假设任何后端服务器都可以
处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标 IP 地址的 请
求调度到同一台服务器,来提高各台服务器的访问局部性和主存 Cache 命中率,从而整个集
群系统的处理能力。LBLC 调度算法先根据请求的目标 IP 地址 找出该目标 IP 地址最近使用的
服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者
该服务器超载且有服务器处于其一半的工 作负载,则用“最少链接”的原则选出一个可用的服
务器,将请求发送到该服务器。
6.带复制的基于局部性最少链接(LocalityBased Least Connections with Replication
Scheduling)
带 复制的基于局部性最少链接调度(LocalityBased Least Connections with Replication
Scheduling,以下简称为 LBLCR)算法也是针对目标 IP 地址的负载均衡,目前主要用于 Cache
集群系统。它与 LBLC 算法的不同之处是它要 维护从一个目标 IP 地址到一组服务器的映射,
而 LBLC 算法维护从一个目标 IP 地址到一台服务器的映射。对于一个“热门”站点的服务请
求,一台 Cache 服务器可能会忙不过来处理这些请求。这时,LBLC 调度算法会从所有的
Cache 服务器中按“最小连接”原则选出一台 Cache 服务器,映射该“热门”站 点到这台 Cache 服
务器,很快这台 Cache 服务器也会超载,就会重复上述过程选出新的 Cache 服务器。这样,可
能会导致该“热门”站点的映像会出现 在所有的 Cache 服务器上,降低了 Cache 服务器的使用
效率。LBLCR 调度算法将“热门”站点映射到一组 Cache 服务器(服务器集合),当该“热
门”站点的请求负载增加时,会增加集合里的 Cache 服务器,来处理不断增长的负载;当
该“热门”站点的请求负载降低时,会减少集合里的 Cache 服务器 数目。这样,该“热门”站点
的映像不太可能出现在所有的 Cache 服务器上,从而提供 Cache 集群系统的使用效率。
LBLCR 算法先根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组;按“最小连接”原
则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器
超载;则按 “最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,
将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服 务器从服
务器组中删除,以降低复制的程度。
7.目标地址散列调度(Destination Hashing Scheduling)
目标地址散列调度 (Destination Hashing Scheduling)算法也是针对目标 IP 地址的负载均衡,
但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标 IP 地址映射到一台服务
器。目标地址散列调度算法先根据请求的目标 IP 地址,作为散列键(Hash Key)从静态分配
的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则
返回空。
8.源地址散列调度(Source Hashing Scheduling)
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根
据请求的源 IP 地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该
服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标
地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求
的目标 IP 地址换成请求的源 IP 地址,所以这里不一一叙述。在实际应用中,源地址散列 调
度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入
口。
关于集群的负载调度技术,可以基于IP、端口、内容等进行分发,其中基于IP的负载调度是效率最高的。
基于IP的负载均衡模式中,常见的有以下三种工作模式:
(1)地址转换,简称NAT模式,负载均衡调度器作为网关,服务器和负载调度器在同一个私有网络,安全性较好。
(2)IP隧道,简称TUN模式,负载调度器仅作为客户机的访问入口,各节点通过各自的Internet连接直接回应
客户机,不在经过负载调度器,服务器的节点分散在互联网的不同位置,具有独立的共有IP地址,通过专用的IP
隧道与负载调度器相互通信。
(3)直接路由,简称DR模式,与TUN模式类似,但各节点不是分散在各地,而是与调度器位于同一个物理网络,
负载调度器与各节点服务器通过本地网络连接,不需要建立专用的ip隧道。
以上三种模式中,NAT方式只需要一个公网地址,从而成为最容易的一种负载均衡模式,安全性也比较好,许多硬件负载均衡
设备就是采用这种方式;相比较而言,DR模式和TUN模式的负载能力更强大,使用范围更广,但节点的安全性要稍差一些。
VS/DR 利用大多数 Internet 服务的非对称特点,负载调度器中只负责调度请求,
而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量
调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的
HUB 相连。VIP 地址为调度器和服务器组共享,调度器配置的 VIP 地址是对外可见的,用于接收虚拟
服务的请求报文;所有的服务器把 VIP 地址配置在各自的 NonARP 网络设备上,它对外面是不可见
的,只是用于处理目标地址为VIP的网络请求。
1.搭建实验环境:
【server1】:
(1)添加yum源功能包:
[root@server1 varnish]# /etc/init.d/varnish stop 关闭varnish
Stopping Varnish Cache: [ OK ]
[root@server1 varnish]# /etc/init.d/httpd stop 关闭httpd
Stopping httpd: [ OK ]
[root@server1 varnish]# cd
[root@server1 ~]# ls
anaconda-ks.cfg install.log varnish-3.0.5-1.el6.x86_64.rpm :wq
bansys.zip install.log.syslog varnish-libs-3.0.5-1.el6.x86_64.rpm
[root@server1 ~]# rm -fr * 删除所有
[root@server1 ~]# ls
[root@server1 ~]# cd /etc/yum.repos.d/
[root@server1 yum.repos.d]# ls
rhel-source.repo
[root@server1 yum.repos.d]# vim rhel-source.repo 配置yum源添加其他的包
编辑内容:
(2)重新加载yum源:
(3)下载ipvsadm服务:
(3)添加策略:
(4)添加虚拟ip:【server1.2.3】都需要添加,保证在一个vlan里
(5)打开【server2】【server3】httpd服务
2.载真机上进行测试:
[root@foundation48 Desktop]# arp -an|grep 100 先查看MAC地址刚才做了验证偶然性
? (192.168.1.100) at 38:a4:ed:17:5a:c9 [ether] on wlp0s20f0u2
? (172.25.254.100) at 52:54:00:42:fc:3a [ether] on br0
[root@foundation48 Desktop]# arp -d 172.25.254.100 删除
[root@foundation48 Desktop]# arp -an|grep 100 查看为空,MAC再不会发生改变解决了偶然性
? (192.168.1.100) at 38:a4:ed:17:5a:c9 [ether] on wlp0s20f0u2
? (172.25.254.100) at on br0
[root@foundation48 Desktop]# ping 172.25.254.100 连接一下虚拟IP
[root@foundation48 Desktop]# curl 172.25.254.100 会进行轮询
bbs.westos.org
[root@foundation48 Desktop]# curl 172.25.254.100
www.westos.org
[root@foundation48 Desktop]# curl 172.25.254.100
bbs.westos.org
[root@foundation48 Desktop]# curl 172.25.254.100
www.westos.org
在网页上测试:
1.【首先添加解析】
[root@foundation48 Desktop]# vim /etc/hosts 添加解析
2.【测试】网页进行测试每刷新一次就会发生轮询: