Posts Tagged: ipvsadm


17
十 10

大流量、高负载LVS系统优化

Linux环境

CentOS 5.5

名词

LVS   :   Linux Virtual Server

IPVS :   IP Virtual Server,IPVS 是 LVS 实现的关键。

IPVS connection hash table  :  IPVS连接哈希表,用来“跟踪”进来、出去的网络包(for input and output packets lookups of IPVS)。

ip_vs_conn 结构体: 定义在内核档 include/net/ip_vs.h 中。该结构体(对象)是 IPVS 的调度对象。在 32 位系统上 128字节,64位系统上 192 字节。

IPVS connection hash table

内核中的代码:net/netfilter/ipvs/ip_vs_conn.c

int ip_vs_conn_tab_bits;
编译时可以定,Kconfig文件中说明该值的大小应该在 8 到 20 之间。当ip_vs_conn_tab_bits=20 时,哈希表的的大小(条目)为 pow(2,20),即 1048576,约 104 万,足够用了。
int ip_vs_conn_tab_size;
IPVS哈希连接表的条目数(list_head结构数)。

ip_vs_conn_tab_size = 1 << ip_vs_conn_tab_bits;
哈希表的大小(条目数)是 2 的 ip_vs_conn_tab_bits 次方。

ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(struct list_head));
其中 IPVS连接哈希表占用的内存大小是 ip_vs_conn_tab_size * sizeof(struct list_head)

内核Kconfig文件中说一个哈希条目点用8个字节,但是实示上,一个条目占用的内存大小是和 list_head 结构体的大小相关, (可能)在32位的内核里是8个字节,64位的内核里是16个字节。当加载ip_vs模块的时候,使用dmesg可以看到具体的信息:

在32位系统上

IPVS: Registered protocols (TCP, UDP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
IPVS: ipvs loaded.

在64位的系统上:

IPVS: Registered protocols (TCP, UDP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
IPVS: ipvs loaded.

哈希冲突,是哈希算法的致命伤。“IPVS”使用“链表策略”(chaining scheme) 解决哈希冲突。当有大量的连接时,一个大的 “IPVS连接哈希表”将大大减少冲突。减少了冲突,意为着IPVS定位 ip_vs_conn 对象的速度更快。

下图示意了哈希表(Hash Table)这种数据结构。引用

哈希表

如上图所示,首先分配一个指针数组,数组的每个元素是一个链表的头指针,每个链表称为一个槽(Slot)。哪个数据应该放入哪个槽中由哈希函数决定,在这个例子中我们简单地选取哈希函数h(x) = x % 11,这样任意数据x都可以映射成0~10之间的一个数,就是槽的编号,将数据放入某个槽的操作就是链表的插入操作。
如果每个槽里至多只有一个数据,可以想像这种情况下search、insert和delete操作的时间复杂度都是O(1),但有时会有多个数据被哈希函数映射到同一个槽中,这称为碰撞(Collision),设计一个好的哈希函数可以把数据比较均匀地分布到各个槽中,尽量避免碰撞。如果能把n个数据比较均匀地分布到m个槽中,每个糟里约有n/m个数据,则search、insert和delete和操作的时间复杂度都是O(n/m),如果n和m的比是常数,则时间复杂度仍然是O(1)。一般来说,要处理的数据越多,构造哈希表时分配的槽也应该越多,所以n和m成正比这个假设是成立的。

关联到IPVS,ip_vs_conn_tab_size 指的就是“槽”的数量。 N 指的应该是所有的调度对象 struct ip_vs_conn 的数量。

确定 ip_vs_conn_tab_bits 的最佳值:

假如你的 LVS 上每秒有 W 个“连接”建立, 平均每个“连接”将要保持 S 秒,即每个连接工作 S 秒,最佳 ip_vs_conn_tab_bits 值应该满足 2 的 ip_vs_conn_tab_bits 次方靠近 W*S。最佳的 ip_vs_conn_tab_bits = log(W*S,2).

还有一个容易的方法:

使用 slabtop 观察 ip_vs_conn 结构的数量(OBJS),当然,应该是在系统流量最高的时候取得这个值,对该值求以 2为底 的对数,log(OBJS,2)。

获取ip_vs_conn OBJS的值:awk ‘/ip_vs_conn/{print $3}’ /proc/slabinfo

这个最佳值,以我理解,就是上面 “哈希表”结构说明中提到的M值,而 OBJS 就是 N 值 ,当M接近 N的时候,哈希表的复杂度为O(1),为最佳状态。

使我不解的是,这里为什么不设置的更大一些,仅仅是浪费一些内存而且(一个条目用去8或者16个字节)。即使取最大值 20,在64位内核上,也才只占去16M的内存,在32位的内核上,占去8M内存。

IPVS的默认值是12,32位机用掉 32K,64位机用掉 64K内存。假如不是因为小内存容易使用CPU缓存,那么就一定是为了节省内存,在服务器上,这样的策略,明显落后了。

问题的关键是查明 vmalloc() 函数的作用。

vmalloc() 函数的作用:

申请逻辑地址连续的内存,返回首内存地址。

看来IPVS连接哈希表的大小,与使用的内存(是高速缓存,还是普通内存)并无影响。

调整 ip_vs_conn_tab_bits的方法:

新的IPVS代码,允许调整 ip_vs_conn_bits 的值。而老的IPVS代码则需要通过重新编译来调整。

在发行版里,IPVS通常是以模块的形式编译的。

确认能否调整使用命令 modinfo -p ip_vs(查看 ip_vs 模块的参数),看有没有 conn_tab_bits 参数可用。假如可以用,那么说时可以调整,调整方法是加载时通过设置 conn_tab_bits参数:

在 /etc/modprobe.conf 添加下面一行

options ip_vs conn_tab_bits=20

假如没有 conn_tab_bits 参数可用,则需要重新调整编译选项,重新编译。

很不幸,即使将CentOS 5 内核升级到最新版,也不支持这个参数,只能自定义编译了。

另外,假如IPVS支持调整 ip_vs_conn_tab_bits,而又将IPVS集成进了内核,那么只能通过重启,向内核传递参数来调整了。在引导程序的 kernel 相关的配置行上,添加:ip_vs.conn_tab_bits=20 ,然后,重启。

最终建意:

增大哈希表,调到 ip_vs_conn_tab_bits 到 20 。有一种说法是哈希表过大,会影响性能。但是根据我对哈希算法的理解,这种说法没有道理。
另一个有力的证据是,IPVS的作者章文松博士也是这样配置的。

Netwrok

增加LVS主机的网络吞吐能力,有利于提高LVS的处理速度和能力。

1. 使用更快的网卡,比如使用千兆、万兆的网卡。

2. 可以进一步将两块或多块网卡绑定(多块网卡的绑定有待验证),bonding 时 mode=0 (balance-rr)或者 mode=4(802.3ad,需要交换机支持聚合端口),miimon=80或者 miimon=100(毫秒)。

TCP/IP

/etc/sysctl.conf

net.core.netdev_max_backlog = 60000

Hardware

IPVS的运行,使用的服务器资源主要是 CPU、内存I/O、网络I/O;IPVS完全运行在内存中,并且运行在内核态。

当IPVS的应用在DR模式时,即不耗CPU,也不耗I/O,运行非常快,所以系统负载非常的低,跟据我的经验,一般负载总是0。所以 LVS 应用对服务器的配置要求非常低。以为 LVS 很重要,所以配置一个相当高端的服务器,实在是一种浪费。

其实我们可以做一下计算:

以64位系统为例,一个哈希表条目,16个字节,一个 ip_vs_conn 结构 192字节。以哈希表的冲突尽可能的少为场景(将 ip_vs_conn_tab_bits 设置为最大值 20 ),那么:

pow(2,20)=1048576

pow(2,20)*(16+192)/1024/1024 = 208 M

就是说,当系统当前有100 万连接的时候,才用去内存 208 M,所以  IPVS 的主机,即使是1G的内存,也足以承载负载。

2011/03/03 补充:

关于最大“连接数限制”,这里的哈希表的长度,并不是LVS最大连接数限制。LVS使用哈希链表解决“哈希冲突”,当连接数大于这个值时,必然会出现哈稀冲突,会(稍微)降低性能,但是并不对在功能上对LVS造成影响。

关于提高网卡流量,需要使用支持“多队列的的网卡”(网卡驱动),以及irqbalance服务。多队列可是提高网卡吞吐量,irqbalance可以将“中断”分布到多个CPU上,提高CPU使用率(降低系统负载)。需要说明的是,多队列的网卡在目前还是高端产品,还需要额外购买。

内核参数的调整

最大打开文件数限制

/etc/security/limits.conf
root soft nofile 65535
root hard nofile 65535
daemon soft nofile 65535
daemon hard nofile 65535
/etc/sysctl.conf
net.ipv6.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries =2
# tweak for lvs
net.core.netdev_max_backlog = 60000

 

 

参考:

http://learn.akae.cn/media/ch26s03.html

http://wenku.baidu.com/view/9bddcb09581b6bd97f19ea3d.html

http://www.hudong.com/wiki/%E5%93%88%E5%B8%8C%E8%A1%A8%E7%AE%97%E6%B3%95

 


12
十一 08

关于Piranha组件中nanny的超时问题

今天集群中的一个App节点因为程序错误(我称之为撞车,系统的负载能力跟高速公路的车辆通行能力很相似,可以类比)导致系统负载急剧增加,直至没有响应,挂掉了。

本来按照预计,挂掉的节点应该在6秒钟内权值(weight)被自动降为零。然后等了一分钟,也没有被降权,立刻意识到,nanny遇到了我之前做监按、写监控经常遇到的问题,超时问题。

nanny在App高负载的情况下迟迟得不到应答(不知道进行到了哪一步),不知怎么办是好了。

在配置文件里明明是有timeout配置的,不知道为什么没有生效,看来到目前为止,我们的LVS集群,还是不能完全无人值守的,占个位置,等待新的研究结果:

………………


15
九 08

Piranha for LVS

食人鱼(Piranha)是南美洲食肉的淡水。它们通常15—25厘米(6—10英寸)长,虽然有时发现有长度达到40厘米的。食人鱼具有尖利的牙齿(能够轻易咬断用造的鱼钩或是一个人的手指[1]),非常凶猛,一旦发现猎物,往往群起而攻之。可以10分鐘內將一隻活牛吃剩一排白骨。当地人用它们的牙齿来做工具和武器。亚马逊河圭亚那河巴拉圭河、等河流是食人鱼经常出没的场所。

piranha,水虎鱼,食人鱼

piranha,水虎鱼,食人鱼

piranha,水虎鱼,食人鱼

piranha,水虎鱼,食人鱼

piranha:

Summary     : Cluster administation tools
Description : Various tools to administer and configure the Linux Virtual Server as well as heartbeating and failover components.  The LVS is a dynamically adjusted kernel routing mechanism that provides load balancing primarily for web and ftp servers though other services are supported.

piranha的组件:

/usr/sbin/pulse
heartbeating daemon for monitoring the health of cluster nodes.

/usr/sbin/lvsd
daemon to control the Red Hat clustering services.

/usr/sbin/nanny
tool to monitor status of service in a cluster.

/usr/sbin/fos
failover services daemon to control the Red Hat clustering service.

/usr/sbin/send_arp
tool  to  notify network of a new IP address / MAC address mapping.
这个工具非常有用。之前有一篇《send_arp的一个角本,我曾经简单介绍过。

On LVS router, there are three service which need to be set to activate at boot time.

  • piranha-gui
  • pulse
  • sshd

If you are clustering multi-port services or using firewall marks, you must enable the iptables service.


11
四 08

关于LVS的几个新认识

1. LVS调度的最小单位是“连接”。
2. 当apache的KeepAlive被设置成Off时,“连接”才能被较均衡的调度。
3. 在不指定-p参数时,LVS才真正以“连接”为单位按“权值”调度流量。
4. 在指定了-p参数时,则一个client在一定时间内,将会被调度到同一台RS。(曾经发生过蜘蛛来抓取的时候,几乎所有的请求都调度到一台RS上)
5. 可以通过”ipvsadm –set tcp tcpfin udp”来调整TCP和UDP的超时,让连接淘汰得快一些。
6. 在NAT模式时,RS的PORT参数才有意义。
7. DR和TUN模式时,InActConn 是没有意义的(Thus the count in the InActConn column for LVS-DR, LVS-Tun is inferred rather than real.)

2011-2-17 新增:

8. NAT模式,RS不用做任何修改(配置)。
9. NAT模式,LVS的负载能力(未经测试)、带宽容易成为瓶颈。
10. DR模式,RS需要关闭相关ARP响应,配置 VIP/32  网络接口。
11. DR模式,一般认为 RS 和 LVS 需要在同一 VLAN (same local network ),因为 VIP 需要在 LVS 和 RS 上为有效 IP。


13
十二 07

ipvs的八种调度方法

  1. 轮叫(Round Robin)
    调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。
  2. 加权轮叫(Weighted Round Robin)
    调度器通过”加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
  3. 最少链接(Least Connections)
    调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用”最小连接”调度算法可以较好地均衡负载。
  4. 加权最少链接(Weighted Least Connections)
    在集群系统中的服务器性能差异较大的情况下,调度器采用”加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
  5. 基于局部性的最少链接(Locality-Based Least Connections)
    ” 基于局部性的最少链接” 调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器 是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用”最少链接”的原则选出一个可用的服务 器,将请求发送到该服务器。
  6. 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication) “带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组,按”最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按”最小连接”原则从这个集群中选出一 台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的 程度。
  7. 目标地址散列(Destination Hashing)
    “目标地址散列”调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
  8. 源地址散列(Source Hashing)
    “源地址散列”调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

16
八 07

ipvsadm命令参考

由 wensong 在 周四, 2006-02-16 19:05 提交 对ipvsadm 的命令参考,并根据自己使用的经验,进行了一个简单的翻译,希望对ipvsadm 的使用者有一定的帮助。

为了更好的让大家理解这份命令手册,将手册里面用到的几个术语先简单的介绍一下:

1,virtual-service-address:是指虚拟服务器的ip 地址
2,real-service-address:是指真实服务器的ip 地址
3,scheduler:调度方法
(lna@networksbase.com 翻译 ipvsadm v1.21 2004 年4 月)
ipvsadm 的用法和格式如下:
ipvsadm -A|E -t|u|f virutal-service-address:port [-s scheduler] [-p
[timeout]] [-M netmask]
ipvsadm -D -t|u|f virtual-service-address
ipvsadm -C
ipvsadm -R
ipvsadm -S [-n]
ipvsadm -a|e -t|u|f service-address:port -r real-server-address:port
[-g|i|m] [-w weight]
ipvsadm -d -t|u|f service-address -r server-address
ipvsadm -L|l [options]
ipvsadm -Z [-t|u|f service-address]
ipvsadm –set tcp tcpfin udp
ipvsadm –start-daemon state [--mcast-interface interface]
ipvsadm –stop-daemon
ipvsadm -h
命令选项解释:
有两种命令选项格式,长的和短的,具有相同的意思。在实际使用时,两种都可以。
-A –add-service 在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也就是增加一台新的虚拟服务器。
-E –edit-service 编辑内核虚拟服务器表中的一条虚拟服务器记录。
-D –delete-service 删除内核虚拟服务器表中的一条虚拟服务器记录。
-C –clear 清除内核虚拟服务器表中的所有记录。
-R –restore 恢复虚拟服务器规则
-S –save 保存虚拟服务器规则,输出为-R 选项可读的格式
-a –add-server 在内核虚拟服务器表的一条记录里添加一条新的真实服务器记录。也就是在一个虚拟服务器中增加一台新的真实服务器
-e –edit-server 编辑一条虚拟服务器记录中的某条真实服务器记录
-d –delete-server 删除一条虚拟服务器记录中的某条真实服务器记录
-L|-l –list 显示内核虚拟服务器表
-Z –zero 虚拟服务表计数器清零(清空当前的连接数量等)
–set tcp tcpfin udp 设置连接超时值
–start-daemon 启动同步守护进程。他后面可以是master 或backup,用来说明LVS Router 是master 或是backup。在这个功能上也可以采用keepalived 的VRRP 功能。
–stop-daemon 停止同步守护进程
-h –help 显示帮助信息
其他的选项:
-t –tcp-service service-address 说明虚拟服务器提供的是tcp 的服务
[vip:port] or
-u –udp-service service-address 说明虚拟服务器提供的是udp 的服务
[vip:port] or
-f –fwmark-service fwmark 说明是经过iptables 标记过的服务类型。
-s –scheduler scheduler 使用的调度算法,有这样几个选项
rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,
默认的调度算法是: wlc.
-p –persistent [timeout] 持久稳固的服务。这个选项的意思是来自同一个客户的多次请求,将被同一台真实的服务器处理。timeout 的默认值为300 秒。
-M –netmask netmask persistent granularity mask
-r –real-server server-address 真实的服务器
-g –gatewaying 指定LVS 的工作模式为直接路由模式(也是LVS 默认的模式)
-i –ipip 指定LVS 的工作模式为隧道模式
-m –masquerading 指定LVS 的工作模式为NAT 模式
-w –weight weight 真实服务器的权值
–mcast-interface interface 指定组播的同步接口
-c –connection 显示LVS 目前的连接 如:ipvsadm -L -c
–timeout 显示tcp tcpfin udp 的timeout 值 如:ipvsadm -L –timeout
–daemon 显示同步守护进程状态
–stats 显示统计信息
–rate 显示速率信息
–sort 对虚拟服务器和真实服务器排序输出
–numeric -n 输出IP 地址和端口的数字形式