掌握什么是负载均衡及负载均衡的做用和意义。html
了解lvs负载均衡的三种模式。前端
了解lvs-DR负载均衡部署方法。linux
掌握nginx实现负载均衡的方法。nginx
掌握lvs+nginx负载均衡拓扑结构。c++
一台普通服务器的处理能力是有限的,假如能达到每秒几万个到几十万个请求,但却没法在一秒钟内处理上百万个甚至更多的请求。但若能将多台这样的服务器组成一个系统,并经过软件技术将全部请求平均分配给全部服务器,那么这个系统就彻底拥有每秒钟处理几百万个甚至更多请求的能力。这就是负载均衡最初的基本设计思想。web
负载均衡是由多台服务器以对称的方式组成一个服务器集合,每台服务器都具备等价的地位,均可以单独对外提供服务而无须其余服务器的辅助。经过某种负载分担技术,将外部发送来的请求按照某种策略分配到服务器集合的某一台服务器上,而接收到请求的服务器独立地回应客户的请求。负载均衡解决了大量并发访问服务问题,其目的就是用最少的投资得到接近于大型主机的性能。 算法
DNS(Domain Name System,域名系统),因特网上做为域名和IP地址相互映射的一个分布式数据库,可以使用户更方便的访问互联网,而不用去记住可以被机器直接读取的IP数串。经过主机名,最终获得该主机名对应的IP地址的过程叫作域名解析(或主机名解析)。DNS协议运行在UDP协议之上,使用端口号53。shell
DNS负载均衡技术是最先的负载均衡解决方案,它是经过DNS服务中的随机名字解析来实现的,在DNS服务器中,能够为多个不一样的地址配置同一个名字,而最终查询这个名字的客户机将在解析这个名字时获得其中的一个地址。所以,对于同一个名字,不一样的客户机会获得不一样的地址,它们也就访问不一样地址上的Web服务器,从而达到负载均衡的目的。数据库
以下图:apache
优势:实现简单、实施容易、成本低、适用于大多数TCP/IP应用;
缺点:
一、 负载分配不均匀,DNS服务器将Http请求平均地分配到后台的Web服务器上,而不考虑每一个Web服务器当前的负载状况;若是后台的Web服务器的配置和处理能力不一样,最慢的Web服务器将成为系统的瓶颈,处理能力强的服务器不能充分发挥做用;
二、可靠性低,若是后台的某台Web服务器出现故障,DNS服务器仍然会把DNS请求分配到这台故障服务器上,致使不能响应客户端。
三、变动生效时间长,若是更改NDS有可能形成至关一部分客户不能享受Web服务,而且因为DNS缓存的缘由,所形成的后果要持续至关长一段时间(通常DNS的刷新周期约为24小时)。
基于四层交换技术的负载均衡是经过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器与请求客户端创建TCP链接,而后发送Client请求的数据。
以下图:
client发送请求至4层负载均衡器,4层负载均衡器根据负载策略把client发送的报文目标地址(原来是负载均衡设备的IP地址)修改成后端服务器(能够是web服务器、邮件服务等)IP地址,这样client就能够直接跟后端服务器创建TCP链接并发送数据。
具备表明意义的产品:LVS(开源软件),F5(硬件)
优势:性能高、支持各类网络协议
缺点:对网络依赖较大,负载智能化方面没有7层负载好(好比不支持对url个性化负载),F5硬件性能很高但成本也高须要人民币几十万,对于小公司就望而却步了。
基于七层交换技术的负载均衡也称内容交换,也就是主要经过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的服务器。
以下图:
七层负载均衡服务器起了一个代理服务器的做用,client要访问webserver要先与七层负载设备进行三次握手后创建TCP链接,把要访问的报文信息发送给七层负载均衡;而后七层负载均衡再根据设置的均衡规则选择特定的webserver,而后经过三次握手与此台webserver创建TCP链接,而后webserver把须要的数据发送给七层负载均衡设备,负载均衡设备再把数据发送给client。
具备表明意义的产品:nginx(软件)、apache(软件)
优势:对网络依赖少,负载智能方案多(好比可根据不一样的url进行负载)
缺点:网络协议有限,nginx和apache支持http负载,性能没有4层负载高
四层负载使用lvs软件或F5硬件实现。
七层负载使用nginx实现。
以下图是lvs+nginx的拓扑结构:
在keepalived+nginx的主备容灾高可用的架构中,nginx是做为外部访问系统的惟一入口,理论上一台nginx的最大并发量能够高达50000,可是当并发量更大的时候,keepalived+nginx的高可用机制是没办法知足需求的,由于keepalived+nginx的架构中确确实实是一台nginx在工做,只有当master宕机或异常时候,备份机才会上位。那么如何解决更大的高并发问题呢,也许会问能不能搭建nginx集群,直接对外提供访问?
很显然这是欠稳当的,由于当nginx做为外部的惟一访问入口,没办法直接以集群的形式对外提供服务,没有那么多的公网ip资源可用,既太浪费也不友好。可是在内网环境下,是能够用nginx集群(nginx横向扩展服务集合)的,固然总得有一个对外入口,因此须要在nginx集群之上,在加一层负载均衡器,做为系统的惟一入口。
LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立,是中国国内最先出现的自由软件项目之一。
运行 lPVS软件的服务器,在整个负载均衡集群中承担一调度角色 软件的服务器,(即 向真实服务器分配从客户端过来的请求。LVS中的调度方法有三种 :NAT(Network Address Translation网络地址转换)、TUN(tunnel 隧道)、DR(direct route 直接路由)
请求由LVS接受,由真实提供服务的服务器(RealServer, RS)直接返回给用户,返回的时候不通过LVS。
DR模式下须要LVS服务器和RS绑定同一个VIP, 一个请求过来时,LVS只须要将网络帧的MAC地址修改成某一台RS的MAC,该包就会被转发到相应的RS处理,注意此时的源IP和目标IP都没变,RS收到LVS转发来的包,发现MAC是本身的,发现IP也是本身的,因而这个包被合法地接受,而当RS返回响应时,只要直接向源IP(即用户的IP)返回便可,再也不通过LVS。
DR模式下,lvs接收请求输入,将请求转发给RS,由RS输出响应给用户,性能很是高。
它的不足之处是要求负载均衡器与RS在一个物理段上。
NAT(Network Address Translation)是一种外网和内网地址映射的技术。NAT模式下,LVS须要做为RS的网关,当网络包到达LVS时,LVS作目标地址转换(DNAT),将目标IP改成RS的IP。RS接收到包之后,处理完,返回响应时,源IP是RS IP,目标IP是客户端的IP,这时RS的包经过网关(LVS)中转,LVS会作源地址转换(SNAT),将包的源地址改成VIP,对于客户端只知道是LVS直接返回给它的。
NAT模式请求和响应都须要通过lvs,性能没有DR模式好。
TUN模式是经过ip隧道技术减轻lvs调度服务器的压力,许多Internet服务(例如WEB服务器)的请求包很短小,而应答包一般很大,负载均衡器只负责将请求包分发给物理服务器,而物理服务器将应答包直接发给用户。因此,负载均衡器能处理很巨大的请求量。相比NAT性能要高的多,比DR模式的优势是不限制负载均衡器与RS在一个物理段上。可是它的不足须要全部的服务器(lvs、RS)支持"IP Tunneling"(IP Encapsulation)协议。
vip:192.168.101.100
lvs-director:192.168.101.8
nginx1:192.168.101.3
nginx2:192.168.101.4
在192.168.101.8上安装lvs
centos6.5自带lvs,检查linux内核是否集成lvs模块:
modprobe -l | grep ipvs
yum install -y gcc gcc-c++ makepcre pcre-devel kernel-devel openssl-devel libnl-devel popt*
将ipvsadm-1.26.tar.gz拷贝至/usr/local/下
cd /usr/local tar -zxvf ipvsadm-1.26.tar.gz cd ipvsadm-1.26 make make install
校验是否安装成功:
在192.168.101.3和192.168.101.4上安装nginx。
建立nginx-lvs.conf,http内容以下:
http { include mime.types; default_type application/octet-stream; sendfile on; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } }
ifconfig eth0:0 192.168.101.100 broadcast 192.168.101.100 netmask 255.255.255.255 up
此处在eth0设备上绑定了一个虚拟设备eth0:0,同时设置了一个虚拟IP是192.168.101.100,而后指定广播地址也为192.168.101.100,须要特别注意的是,虚拟ip地址的广播地址是它自己,子网掩码是255.255.255.255。
route add -host 192.168.101.100 dev eth0:0
echo "1" >/proc/sys/net/ipv4/ip_forward
参数值为1时启用ip转发,为0时禁止ip转发。
ipvsadm --clear
ipvsadm -A -t 192.168.101.100:80 -s rr
-s rr表示采用轮询策略。
:80表示负载转发的端口是80
ipvsadm -a -t 192.168.101.100:80 -r 192.168.101.3:80 -g ipvsadm -a -t 192.168.101.100:80 -r 192.168.101.4:80 -g
在新加虚拟IP记录中添加两条新的Real Server记录,-g表示指定LVS 的工做模式为直接路由模式。
lvs进行负载转发须要保证lvs负载的端口要和nginx服务的端口的一致,这里都为80。
ipvsadm
在lvs的DR和TUn模式下,用户的访问请求到达真实服务器后,是直接返回给用户的,而再也不通过前端的Director Server,所以,就须要在每一个Real server节点上增长虚拟的VIP地址,这样数据才能直接返回给用户。
ifconfig lo:0 192.168.101.100 broadcast 192.168.101.100 netmask 255.255.255.255 up /sbin/route add -host 192.168.101.100 dev lo:0
arp_announce :定义不一样级别:当ARP请求经过某个端口进来是否利用这个接口来回应。
0 -利用本地的任何地址,无论配置在哪一个接口上去响应ARP请求;
1 - 避免使用另一个接口上的mac地址去响应ARP请求;
2 - 尽量使用可以匹配到ARP请求的最佳地址。
arp_ignore:当ARP请求发过来后发现本身正是请求的地址是否响应;
0 - 利用本地的任何地址,无论配置在哪一个接口上去响应ARP请求;
1 - 哪一个接口上接受ARP请求,就从哪一个端口上回应。
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce sysctl -p #使用修改生效
sysctl -p #使用修改生效
因为lvs设置为rr轮询策略,当访问虚IP http://192.168.101.100,每次刷新请求经过lvs负载到不一样的服务器。
一、测试时须要在nginx的http中设置keepalive_timeout 0; 取消使用http持久链接模式,保证每次客户端发起请求都须要向服务端创建链接,这样作是为了每次刷新页面都要通过lvs负载转发。
二、lvs进行负载转发须要保证lvs负载的端口要和nginx服务的端口的一致,这里都为80。
keepalive_timeout说明:
在nginx中keepalive_timeout的默认值是75秒,默认使用http持久链接模式,可以使客户端到服务器端的链接持续有效,当出现对服务器的后继请求时,可避免创建或从新创建链接。生产环境建议keepalive_timeout不要设置为0。
修改192.168.101.3和192.168.101.4下html目录中index.html的内容使之个性化。
第一次请求:http://192.168.101.100
刷新,至关于第二次请求:
依次交替测试,发现每次请求被负载到不一样的nginx上。
任意中止掉一个nginx,请求http://192.168.101.100继续能够浏览,因为lvs采用轮询策略若是其中一个nginx请求不可到达则去请求另外的nginx。
为了方便配置启动lvs将上边Director Server和Real Server的配置过程封装在shell脚本中。
在/etc/init.d下建立lvsdr,内容以下:
#!/bin/sh # 定义虚拟ip VIP=192.168.101.100 #虚拟 ip根据需求修改 # 定义realserver,并已空格分开,根据需求修改 RIPS="192.168.101.3 192.168.101.4" # 定义提供服务的端口 SERVICE=80 # 调用init.d脚本的标准库 . /etc/rc.d/init.d/functions case $1 in start) echo "Start LVS of DR Mode" # 开启ip转发 echo "1" > /proc/sys/net/ipv4/ip_forward # 绑定虚拟ip ifconfig eth0:0 $VIP broadcast $VIP netmask 255.255.255.255 up route add -host $VIP dev eth0:0 # 清除lvs规则 ipvsadm -C # 添加一条虚拟服务器记录 # -p指定必定的时间内将相同的客户端分配到同一台后端服务器 # 用于解决session的问题,测试时或有别的解决方案时建议去掉 ipvsadm -A -t $VIP:$SERVICE -s rr # 添加真实服务器记录 for RIP in $RIPS do echo $RIP:$SERVICE; ipvsadm -a -t $VIP:$SERVICE -r $RIP:$SERVICE -g done # 设置tcp tcpfin udp的超时链接值 ipvsadm --set 30 120 300 ipvsadm ;; stop) echo "Stop LVS DR" ifconfig eth0:0 down ipvsadm -C ;; *) echo "Usage:$0 {start ¦ stop}" exit 1 esac
修改脚本权限:chmod +x /etc/init.d/lvsdr
启动Director server:service lvsdr start
中止Director server:service lvsdr stop
在/etc/init.d下建立lvsdr,内容以下:
#!/bin/sh VIP=192.168.101.100 #虚拟ip,根据需求修改 . /etc/rc.d/init.d/functions case $1 in start) echo "lo:0 port starting" # 为了相应lvs调度器转发过来的包,需在本地lo接口上绑定vip ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up # 限制arp请求 echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce ;; stop) echo "lo:0 port closing" ifconfig lo:0 down echo "0" > /proc/sys/net/ipv4/conf/lo/arp_ignore echo "0" > /proc/sys/net/ipv4/conf/lo/arp_announce echo "0" > /proc/sys/net/ipv4/conf/all/arp_ignore echo "0" > /proc/sys/net/ipv4/conf/all/arp_announce ;; *) echo "Usage: $0 {start ¦ stop}" exit 1 esac
修改脚本权限:chmod +x /etc/init.d/lvsdr
启动real server:service lvsdr start
中止real server:service lvsdr stop
参考nginx教案。
lvs采用DR模式基本上没有性能瓶颈,用户请求输入至lvs通过负载转发到后台服务上,经过后台服务输出响应给用户。nginx的负载性能远没有lvs好,lvs四层+nginx七层负载的好处是最前端是lvs接收请求进行负载转发,由多个nginx共同完成七层负载,这样nginx的负载性能就能够线性扩展。
vip:192.168.101.100
lvs-director:192.168.101.8
nginx1:192.168.101.3 安装nginx
nginx2:192.168.101.4 安装nginx
tomcat1:192.168.101.5 安装tomcat
tomcat2:192.168.101.6 安装tomcat
vip:192.168.101.100
lvs-director:192.168.101.8
参考lvs四层负载DR模式进行配置
nginx1:192.168.101.3 安装nginx
nginx2:192.168.101.4 安装nginx
参考lvs四层负载DR模式进行配置,须要修改nginx的配置文件使每一个nginx对两个tomcat进行负载,以下:
http { include mime.types; default_type application/octet-stream; sendfile on; upstream tomcat_server_pool{ server 192.168.101.5:8080 weight=10; server 192.168.101.6:8080 weight=10; } server { listen 80; server_name localhost; location / { proxy_pass http://tomcat_server_pool; index index.jsp index.html index.htm; } } }
请求http://192.168.101.100,lvs负载到不一样的nginx上,若是中止任意一台nginx或中止任意一台tomcat不影响访问。
lvs做为负载均衡器,全部请求都先到达lvs,可见lvs处于很是重要的位置,若是lvs服务器宕机后端web服务将没法提供服务,影响严重。
为了屏蔽负载均衡服务器的宕机,须要创建一个备份机。主服务器和备份机上都运行高可用(High Availability)监控程序,经过传送诸如“I am alive”这样的信息来监控对方的运行情况。当备份机不能在必定的时间内收到这样的信息时,它就接管主服务器的服务IP并继续提供负载均衡服务;当备份管理器又从主管理器收到“I am alive”这样的信息时,它就释放服务IP地址,这样的主服务器就开始再次提供负载均衡服务。
keepalived是集群管理中保证集群高可用的一个服务软件,用来防止单点故障。
Keepalived的做用是检测web服务器的状态,若是有一台web服务器死机,或工做出现故障,Keepalived将检测到,并将有故障的web服务器从系统中剔除,当web服务器工做正常后Keepalived自动将web服务器加入到服务器群中,这些工做所有自动完成,不须要人工干涉,须要人工作的只是修复故障的web服务器。
keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。
虚拟路由冗余协议,能够认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(该路由器所在局域网内其余机器的默认路由为该vip),master会发组播,当backup收不到VRRP包时就认为master宕掉了,这时就须要根据VRRP的优先级来选举一个backup当master。这样的话就能够保证路由器的高可用了。
keepalived主要有三个模块,分别是core、check和VRRP。core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查,包括常见的各类检查方式。VRRP模块是来实现VRRP协议的。
详细参考:Keepalived权威指南中文.pdf
vip:192.168.101.100
lvs-director:192.168.101.8 主lvs
lvs-director:192.168.101.9 备lvs
nginx1:192.168.101.3 安装nginx
nginx2:192.168.101.4 安装nginx
tomcat1:192.168.101.5 安装tomcat
tomcat2:192.168.101.6 安装tomcat
分别在主备lvs上安装keepalived,参考“安装手册”进行安装:
修改主lvs下/etc/keepalived/keepalived.conf文件
! Configuration File for keepalived global_defs { notification_email { #xxxx@itcast.com # 发生故障时发送的邮箱 } #notification_email_from xxxx@itcast.com # 使用哪一个邮箱发送 #smtp_server xxx.com # 发件服务器 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER # 标示为主lvs interface eth0 # HA检测端口 virtual_router_id 51 # 主备的virtual_router_id 必须相同 priority 100 # 优先级,备lvs要比主lvs稍小 advert_int 1 # VRRP Multicast 广播周期秒数 authentication { # 定义认证 auth_type PASS # 认证方式为口令认证 auth_pass 1111 # 定义口令 } virtual_ipaddress { # 定义vip 192.168.101.100 # 多个vip可换行添加 } } virtual_server 192.168.101.100 80 { delay_loop 6 # 每隔6秒查看realserver状态 lb_algo wlc # 调度算法为加权最小链接数 lb_kind DR # lvs工做模式为DR(直接路由)模式 nat_mask 255.255.255.0 persistence_timeout 50 # 同一IP 的链接50秒内被分配到同一台realserver(测试时建议改成0) protocol TCP # 用TCP监测realserver的状态 real_server 192.168.101.3 80 { # 定义realserver weight 3 # 定义权重 TCP_CHECK { # 注意TCP_CHECK和{之间的空格,若是没有的话只会添加第一个realserver connect_timeout 3 # 三秒无响应超时 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 192.168.101.4 80 { weight 3 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }
修改备lvs下/etc/keepalived/keepalived.conf文件
配置备lvs时须要注意:须要修改state为BACKUP , priority比MASTER低,virtual_router_id和master的值一致
! Configuration File for keepalived global_defs { notification_email { #xxxx@itcast.com # 发生故障时发送的邮箱 } #notification_email_from xxxx@itcast.com # 使用哪一个邮箱发送 #smtp_server xxx.com # 发件服务器 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state BACKUP # 标示为备lvs interface eth0 # HA检测端口 virtual_router_id 51 # 主备的virtual_router_id 必须相同 priority 99 # 优先级,备lvs要比主lvs稍小 advert_int 1 # VRRP Multicast 广播周期秒数 authentication { # 定义认证 auth_type PASS # 认证方式为口令认证 auth_pass 1111 # 定义口令 } virtual_ipaddress { # 定义vip 192.168.101.100 # 多个vip可换行添加 } } virtual_server 192.168.101.100 80 { delay_loop 6 # 每隔6秒查看realserver状态 lb_algo wlc # 调度算法为加权最小链接数 lb_kind DR # lvs工做模式为DR(直接路由)模式 nat_mask 255.255.255.0 persistence_timeout 50 # 同一IP 的链接50秒内被分配到同一台realserver(测试时建议改成0) protocol TCP # 用TCP监测realserver的状态 real_server 192.168.101.3 80 { # 定义realserver weight 3 # 定义权重 TCP_CHECK { # 注意TCP_CHECK和{之间的空格,若是没有的话只会添加第一个realserver connect_timeout 3 # 三秒无响应超时 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 192.168.101.4 80 { weight 3 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }
注意:使用keepalived就不用手动配置启动lvs,在主、备lvs上启动keepalived便可。
主备lvs(192.168.101.八、192.168.101.9)都启动keepalived。
service keepalived start
192.168.101.三、192.168.101.4启动nginx和lvs的realserver配置
cd /usr/local/nginx/sbin ./nginx -c /usr/local/nginx/conf/nginx-lvs.conf
启动lvs的realserver配置:
service lvsdr start
注意:real server的lvs配置须要使用lvsdr脚本。
略
查看主lvs的eth0设置:
vip绑定在主lvs的eth0上。
查询lvs状态:
查看备lvs的eth0设置:
vip没有绑定在备lvs的eth0上。
访问http://192.168.101.100,能够正常负载。
将主lvs的keepalived中止或将主lvs关机(至关于模拟宕机),查看主lvs的eth0:
eth0没有绑定vip
查看备lvs的eth0:
vip已经漂移到备lvs。
访问http://192.168.101.100,能够正常负载。
将主lvs的keepalived启动。
查看主lvs的eth0:
查看备lvs的eth0:
vip漂移到主lvs。
查看备lvs的eth0:
eth0没有绑定vip
访问http://192.168.101.100,能够正常负载。
上边主备方案是当前只有一台lvs工做,这形成资源浪费,能够采用双主结构,让两台lvs当前都进行工做,采用dns轮询方式,当用户访问域名经过dns轮询每台lvs,双主结构须要两个vip,这两个vip要绑定域名。
一样,在每台lvs上安装keepalived软件,当keepalived检测到其中一个lvs宕机则将宕机的vip漂移到活动lvs上,当lvs恢复则vip又从新漂移回来。
每台lvs绑定一个vip,共两个vip,DNS设置域名对应这两个vip,经过DNS轮询每次解析到不一样的vip上即解析到不一样的lvs上。
其中一个主机宕机,每台lvs上安装的keepalived程序会检测到对方宕机,将宕机一方的vip漂移至活动的lvs服务器上,这样DNS轮询所有到一台lvs继续对外提供服务。
当主机恢复又回到初始状态,每一个vip绑定在不一样的lvs上。
前端使用1到2台lvs做为负载基本能够知足中小型网站的并发要求,当lvs的负载成为瓶颈此时就须要对lvs进行优化、扩展。
OSPF(Open Shortest Path First开放式最短路径优先)是一个内部网关协议(Interior Gateway Protocol,简称IGP),用于在单一自治系统(autonomous system,AS)内决策路由。
LVS(DR)经过ospfd,作lvs集群,实现一个VIP,多台LVS同时工做提供服务,这种方案须要依赖三层交换机设备实现。
用户请求(VIP:42.xx.xx.100)到达三层交换机以后,经过对原地址、端口和目的地址、端口的hash,将连接分配到集群中的某一台LVS上,LVS经过内网(10.101.10.x)向后端转发请求,后端再将数据返回给用户。
LVS-ospf集群模式的最大优点就在于:
1.LVS调度机自由伸缩,横向线性扩展(最大8台,受限于三层设备容许的等价路由数目maximum load-balancing);
2.LVS机器同时工做,不存在备机,提升利用率;
3.作到了真正的高可用,某台LVS机器宕机后,不会影响服务
上面讲的是一组双主结构,能够采用多组双主结构达到横向扩展lvs的目的,此方案须要每台lvs都绑定一个vip(公网ip),DNS设置域名轮询多个vip,以下图:
若是资金容许能够购买硬件设置来完成负载均衡,性能不错的有F五、Array等均可以知足超高并发的要求。