相关概念html
Virtual Server via Network Address Translation(VS/NAT)
经过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文经过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。前端
Virtual Server via IP Tunneling(VS/TUN)
采用NAT技术时,因为请求和响应报文都必须通过调度器地址重写,当客户请求愈来愈多时,调度器的处理能力将成为瓶颈。为了解决这个问题,调度器把请求报 文经过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,因此调度器只处理请求报文。因为通常网络服务应答比请求报文大许多,采用 VS/TUN技术后,集群系统的最大吞吐量能够提升10倍。linux
Virtual Server via Direct Routing(VS/DR)
VS/DR经过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术同样,VS/DR技术可极大地 提升集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,可是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。算法
三种IP负载均衡技术的优缺点概括在下表中:服务器
_ | VS/NAT | VS/TUN | VS/DR |
Server | any | Tunneling | Non-arp device |
server network | private | LAN/WAN | LAN |
server number | low (10~20) | High (100) | High (100) |
server gateway | load balancer | own router | Own router |
注: 以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡,调度器的硬件配置与后端服务器的硬件配置相同,并且是对通常Web服务。使用更 高的硬件配置(如千兆网卡和更快的处理器)做为调度器,调度器所能调度的服务器数量会相应增长。当应用不一样时,服务器的数目也会相应地改变。因此,以上数 据估计主要是为三种方法的伸缩性进行量化比较。网络
NAT模式详解:负载均衡
VS/NAT的体系结构如图所示。在一组服务器前有一个调度器,它们是经过Switch/HUB相链接的。这些服务器 提供相同的网络服务、相同的内容,即无论请求被发送到哪一台服务器,执行结果是同样的。服务的内容能够复制到每台服务器的本地硬盘上,能够经过网络文件系 统(如NFS)共享,也能够经过一个分布式文件系统来提供。less
客 户经过Virtual IP Address(虚拟服务的IP地址)访问网络服务时,请求报文到达调度器,调度器根据链接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址 Virtual IP Address改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。同时,调度器在链接Hash 表中记录这个链接,当这个链接的下一个报文到达时,从链接Hash表中能够获得原选定服务器的地址和端口,进行一样的改写操做,并将报文传给原选定的服务 器。当来自真实服务器的响应报文通过调度器时,调度器将报文的源地址和源端口改成Virtual IP Address和相应的端口,再把报文发给用户。咱们在链接上引入一个状态机,不一样的报文会使得链接处于不一样的状态,不一样的状态有不一样的超时值。在TCP 链接中,根据标准的TCP有限状态机进行状态迁移,这里咱们不一一叙述,请参见W. Richard Stevens的《TCP/IP Illustrated Volume I》;在UDP中,咱们只设置一个UDP状态。不一样状态的超时值是能够设置的,在缺省状况下,SYN状态的超时为1分钟,ESTABLISHED状态的超 时为15分钟,FIN状态的超时为1分钟;UDP状态的超时为5分钟。当链接终止或超时,调度器将这个链接从链接Hash表中删除。tcp
这样,客户所看到的只是在Virtual IP Address上提供的服务,而服务器集群的结构对用户是透明的。对改写后的报文,应用增量调整Checksum的算法调整TCP Checksum的值,避免了扫描整个报文来计算Checksum的开销。
在 一些网络服务中,它们将IP地址或者端口号在报文的数据中传送,若咱们只对报文头的IP地址和端口号做转换,这样就会出现不一致性,服务会中断。因此,针 对这些服务,须要编写相应的应用模块来转换报文数据中的IP地址或者端口号。咱们所知道有这个问题的网络服务有FTP、IRC、H.32三、 CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。
下面,举个例子来进一步说明VS/NAT,如图所示:
VS/NAT 的配置以下表所示,全部到IP地址为202.103.106.5和端口为80的流量都被负载均衡地调度的真实服务器172.16.0.2:80和 172.16.0.3:8000上。目标地址为202.103.106.5:21的报文被转移到172.16.0.3:21上。而到其余端口的报文将被拒 绝。
Protocol | Virtual IP Address | Port | Real IP Address | Port | Weight |
TCP | 202.103.106.5 | 80 | 172.16.0.2 | 80 | 1 |
172.16.0.3 | 8000 | 2 | |||
TCP | 202.103.106.5 | 21 | 172.16.0.3 | 21 | 1 |
从如下的例子中,咱们能够更详细地了解报文改写的流程。
访问Web服务的报文可能有如下的源地址和目标地址:
SOURCE | 202.100.1.2:3456 | DEST | 202.103.106.5:80 |
调度器从调度列表中选出一台服务器,例如是172.16.0.3:8000。该报文会被改写为以下地址,并将它发送给选出的服务器。
SOURCE | 202.100.1.2:3456 | DEST | 172.16.0.3:8000 |
从服务器返回到调度器的响应报文以下:
SOURCE | 172.16.0.3:8000 | DEST | 202.100.1.2:3456 |
响应报文的源地址会被改写为虚拟服务的地址,再将报文发送给客户:
SOURCE | 202.103.106.5:80 | DEST | 202.100.1.2:3456 |
这样,客户认为是从202.103.106.5:80服务获得正确的响应,而不会知道该请求是服务器172.16.0.2仍是服务器172.16.0.3处理的。
优缺点:
TUN模式详解
在VS/NAT 的集群系统中,请求和响应的数据报文都须要经过负载调度器,当真实服务器的数目在10台和20台之间时,负载调度器将成为整个集群系统的新瓶颈。大多数 Internet服务都有这样的特色:请求报文较短而响应报文每每包含大量的数据。若是能将请求和响应分开处理,即在负载调度器中只负责调度请求而响应直 接返回给客户,将极大地提升整个集群系统的吞吐量。
IP隧道(IP tunneling)是将一个IP报文封装在另外一个IP报文的技术,这可使得目标为一个IP地址的数据报文能被封装和转发到另外一个IP地址。IP隧道技 术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态创建的,隧道一端有一个IP地址,另外一端也有惟一的IP地址。
咱们利用IP隧道技术将请求报文封装转 发给后端服务器,响应报文能从后端服务器直接返回给客户。但在这里,后端服务器有一组而非一个,因此咱们不可能静态地创建一一对应的隧道,而是动态地选择 一台服务器,将请求报文封装和转发给选出的服务器。这样,咱们能够利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。 VS/TUN的体系结构如图4所示,各个服务器将VIP地址配置在本身的IP隧道设备上。
VS/TUN 的工做流程如图所示:它的链接调度和管理与VS/NAT中的同样,只是它的报文转发方法不一样。调度器根据各个服务器的负载状况,动态地选择一台服务器, 将请求报文封装在另外一个IP报文中,再将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封得到原来目标地址为VIP的报文,服务器发 现VIP地址被配置在本地的IP隧道设备上,因此就处理这个请求,而后根据路由表将响应报文直接返回给客户。
在这里须要指出,根据缺省的TCP/IP协议栈处理,请求报文的目标地址为VIP,响应报文的源地址确定也为VIP,因此响应报文不须要做任何修改,能够直接返回给客户,客户认为获得正常的服务,而不会知道到底是哪一台服务器处理的
DR模式详解
跟VS/TUN 方法相同,VS/DR利用大多数Internet服务的非对称特色,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,能够极大地提升整个集群 系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法相似(其中服务器上的IP地址配置方法是类似的),但IBM的 NetDispatcher是很是昂贵的商品化产品,咱们也不知道它内部所使用的机制,其中有些是IBM的专利。
VS/DR的体系结构如图 所示:调度器和服务器组都必须在物理上有一个网卡经过不分断的局域网相连,如经过高速的交换机或者HUB相连。VIP地址为调度器和服务器组共享,调度 器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;全部的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只 是用于处理目标地址为VIP的网络请求。
VS/DR 的工做流程如图所示:它的链接调度和管理与VS/NAT和VS/TUN中的同样,它的报文转发方法又有不一样,将报文直接路由给目标服务器。在VS/DR 中,调度器根据各个服务器的负载状况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改成选出服务器的MAC地址,再将修改后 的数据帧在与服务器组的局域网上发送。由于数据帧的MAC地址是选出的服务器,因此服务器确定能够收到这个数据帧,从中能够得到该IP报文。当服务器发现 报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,而后根据路由表将响应报文直接返回给客户。
在VS/DR中,根据缺省的TCP/IP协议栈处理,请求报文的目标地址为VIP,响应报文的源地址确定也为VIP,因此响应报文不须要做任何修改,能够直接返回给客户,客户认为获得正常的服务,而不会知道是哪一台服务器处理的。
DR模式的优缺点:
ipvsadm的功能
添加:-A|E -t|u|f service-address [-s scheduler]
[-p [timeout]] [-M netmask]
-t tcp协议集群
-u udp协议集群
-f 防火墙标记 service-adress=Mark Number
service-address: ip:port -s (能够省略,默认为wlc)
轮叫调度 rr (Round Robin)
加权轮叫调度 wrr(Weighted Round Robin)
最少连接调度 lc(Least Connections)
加权最少连接调度 wlc(Weighted Least Connections)
$ipvsadm -A -t 192.168.1.114:80 -s rr
修改: -E
删除: —D
添加: ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower]
-t|u|f service-address:事先定义好的某集群服务
[-g|i|m]: LVS的类型
-g: DR (Direct Routing)默认
-i: TUN (Tunneling)
-m: NAT (Network Address Translation)
[-w weight]: 定义服务器权重
ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.129 -m -w 1
ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.132 -m -w 3
修改: -e
删除: -d
-L|l
-n :数字格式显示主机地址和端口
--stats:统计数据
--rate: 速率
--timeout:显示tcp,tcpfin,udp的会话超时时长
-c:显示当前的ipvs的链接情况
删除全部集群服务
-C:清空ipvs的规则
保存规则
-S
#ipvsadm -S >/path/to/somefile
载入此前规则
-R
#ipvsadm -R >/path/to/somefile(默认:/etc/sysconfig/ipvsadm)
NAT模型:
Linux系统默认是禁止数据包转发的。所谓转发即当主机拥有多于一块的网卡时,其中一块收到数据包,根据数据包的目的ip地址将包发往本机另外一网卡,该网卡根据路由表继续发送数据包。这一般就是路由器所要实现的功能。
NAT模型
$ipvsadm -A -t 192.168.1.114:80 -s wrr
$ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.129 -m -w 1
$ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.132 -m -w 3
echo "1" > /proc/sys/net/ipv4/ip_forward
192.168.11.129/132指向192.168.11.131
官方参考资料:
http://www.linuxvirtualserver.org/zh/lvs1.html
http://www.linuxvirtualserver.org/zh/lvs2.html