LB-lvs

LB:解决方案

硬件：

F5 BIG-IP最贵最成熟银行证券，一般的电商总入口，大众点评

CitrixNetscaler 硬件级别负载均衡

A10   比前两款产品便宜的多

Array

Redware

软件：

LVS:Linux virtual server

中国人章文嵩 ：正明

类似于iptables

 ipvs:工作在内核中的类似于 netfilter

 ipvs:框架，需要依赖于规则完成转发

被input链上的规则匹配到强行转发至postrouting

ipvs集群服务

172.16.100.7：80

定义一个或多个服务器

LVS NAT的特性：

1，RS应该使用私有地址；

2，RS的网关必须指向DIP；

3，RIP和DIP必须在同一网段内；

4，请求和响应的报文都得经过Director，在高负载场景中，Director很可能成为系统性能瓶颈

5，支持端口映射

6，RS可以使用任意支持集群服务的OS；

LVS DR类型：

1，让前端路由器将请求发往VIP时，只能是Director上的VIP

解决方案：

（1）静态地址绑定：

未必有路由器的配置权限；

Director调用时静态地址绑定将难以适用；

（2）arptables

（3）修改Linux内核参数，将RS上的VIP配置为lo接口的别名，限制linux仅对对应接口的ARP请求做响应；

 

LVS DR类型的特性：

1，RS可以使用私有地址，但可以使用公网地址，此时可以直接通过互联网连入RS以实现配置，监控等；

2，RS的网关一定不能指向DIP；

3，RS跟Directory要在同一物理网络内（不能由路由器分隔）；

4，请求报文经过Directory，但响应报文一定不经过Director

5，不支持端口映射

6，RS可以使用大多数的操作系统；

 

LVS TUN类型： IP隧道（用的不多）

1，RIP，DIP，VIP都得是公网地址；

2，RS的网关不会指向也不可能指向DIP

3，请求报文经过Directory，但响应报文一定不经过Director;

4，不支持端口映射；

5，RS的OS必须得支持隧道功能

调度算法：Scheduling Method

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

rr: Round Robin

wrr: weighted RR

sh: source hashing

dh: destination hashing(前端有多个防火墙时，进来的请求从同一个防火墙出去)

动态方法：根据算法及RS当前的负载状况

Lc:  LeastConnection

Overhead=active*256 + Inactive

结果中，最小者胜出

wlc: weight lc

Overhead=(Active*256+Inactive)/weight

Sed: shortest expect delay

Overhead=(Active+1)*256/weight

Nq: Nerver Queue

Lblc: Locality-based Least Connection

dh+lc

Lblcr: Replicated and Locality-based Least Connection

 

Session持久机制：

1，session绑定：始终将同一个请求者的连接定向至同一个RS（第一次请求仍由调度方法选择）；没有容错能力

2，session复制：在RS之间同步session，因此，每个RS持集群中所有的session；对于大规模集群环境不适用；

3，session服务器，利用单独部署的服务器来同一管理session;