keepalived小测试

Feb

2010

keepalived可以保证虚拟IP的稳定性，虽然在使用，但没有很详细的了解，试图通过测试能够避免一些未知问题。现在发现的问题是IP接管被奇怪的转移，还有待考察。。。

硬件环境：

两个机器 192.168.1.44(MASTER) 192.168.1.38(BACKUP)
虚拟IP 192.168.1.69

配置（44）：

[root@localhost ~]# cat /etc/keepalived/keepalived.conf
#! Configuratio File for keepalived
vrrp_script chk_nginx_port {
        script "</dev/tcp/127.0.0.1/80" # connects and exits
        interval 1                      # check every second
        weight -20                      # default prio: -20 if connect fails
}
global_defs {
        notification_email {
                root
        }
        notification_email_from root
        smtp_server localhost
        smtp_connect_timeout 30
        router_id local128
}
vrrp_instance VI_m1 {
        state MASTER #主服务器配置
        interface eth0  #网卡0
        virtual_router_id 110 #router_id 一定要一致
        priority 110 #主从征用的权重主服务器一定要大于从服务器
        advert_int 1 #一秒检查一次
        authentication { #认证的密码
                auth_type PASS
                auth_pass WeMoshLzy
        }
        virtual_ipaddress {
                192.168.1.69 label eth0:1 #要切换的ip
        }
        track_script {
                chk_nginx_port # 检查的脚本
        }
}

38的配置：
修改 state MASTER 为 state BACKUP
priority 改为 100

web服务器（首页内容要不同）启动后，启动keepalived，开始测试。

查看IP的方式：

[root@localhost ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:5d:e9:7b brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.44/24 brd 192.168.1.255 scope global eth0
    [color=#FF0000]inet 192.168.1.69/32 scope global eth0:1[/color]
    inet6 fe80::20c:29ff:fe5d:e97b/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

也就是现在69的ip是在44的机器上监听着：

[root@aslibra ~]# curl http://192.168.1.69/
44

我们做个脚本，看看切换过程都有哪些问题：

[root@aslibra ~]# while true; do date;curl http://192.168.1.69/;sleep 1;done;
Tue Feb  2 11:13:46 CST 2010
44

//关闭44的web服务后

Tue Feb  2 11:13:47 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:13:48 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:13:49 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:13:50 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:13:51 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:13:52 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:13:53 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:13:54 CST 2010
curl: (7) couldn't connect to host

//7秒后，38的机器接过了服务

Tue Feb  2 11:13:55 CST 2010
38
Tue Feb  2 11:13:56 CST 2010
38
...
Tue Feb  2 11:15:28 CST 2010
38
Tue Feb  2 11:15:29 CST 2010
38
Tue Feb  2 11:15:30 CST 2010
44
Tue Feb  2 11:15:31 CST 2010
44
Tue Feb  2 11:15:32 CST 2010
44
Tue Feb  2 11:15:33 CST 2010
44
Tue Feb  2 11:15:34 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:15:35 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:15:36 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:15:37 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:15:38 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:15:39 CST 2010
curl: (7) couldn't connect to host
Tue Feb  2 11:15:40 CST 2010
38
Tue Feb  2 11:15:41 CST 2010
38

其它：

Tue Feb  2 20:53:31 CST 2010
44
Tue Feb  2 20:53:32 CST 2010
44
Tue Feb  2 20:53:33 CST 2010
test
Tue Feb  2 20:53:37 CST 2010
test
Tue Feb  2 20:53:38 CST 2010
test

这个可以进行随意的中断服务或者软件，来检查是否有问题：

1 中断web服务会产生7秒左右的无法访问的时间
2 停止其中一个keepalived的服务，也可能导致中断或者是几秒的等待时间
3 看来还是没太放心

另外，keepalived的监听有点奇特：

[root@aslibra ~]# netstat -nlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
。。。
raw   109500      0 0.0.0.0:112                 0.0.0.0:*                   7           25009/keepalived
raw        0      0 0.0.0.0:112                 0.0.0.0:*                   7           25009/keepalived
raw        0      0 0.0.0.0:255                 0.0.0.0:*                   7           25009/keepalived
raw        0      0 0.0.0.0:255                 0.0.0.0:*                   7           25007/keepalived
raw        0      0 0.0.0.0:255                 0.0.0.0:*                   7           25009/keepalived
raw        0      0 0.0.0.0:255                 0.0.0.0:*                   7           25007/keepalived

raw的协议是什么？

引用

有关raw socket的一些知识

    众所周知,通过socket编程,我们能够实现机器之间的通信.在TCP/IP协议簇(PF_INET)中,可以建立面向连接的SOCK_STREAM类型的socket,非连接的SOCK_DGRAM类型的socket.事实上,在所有的网络程序中,也是这两种socket用的最为广泛.除此之外,还有一些不常用的socket类型,它们却是在某些网络通信中担当重要的角色.这里要讲的就是这么一种socket,称之为raw socket.

    raw socket的作用主要在三个方面:
    1.通过raw socket来接受发向本机的ICMP,IGMP协议包,或者用来发送这些
    协议包.
    2.接受发向本机的但TCP/IP栈不能够处理的IP包.
    3.用来发送一些自己制定源地址特殊作用的IP包(自己写IP头,TCP头等等)

    我们知道,平时我们想看一看网络是否通达,就用ping命令测试一些.ping命令用的是ICMP协议.因此,我们不能够通过建立一个SOCK_STREAM或SOCK_DGRAM来发送这个包,只能够自己亲自来构建ICMP包来发送.这是一种情况.另一种情况是:现在许多操作系统在实现网络部分的时候,通常只实现了常用的几种协议,如tcp,udp,icmp等,但象其它的如ospf,ggp等协议,操作系统往往没有实现,如果自己有必要编写位于其上的应用,就必须借助raw socket来实现,这是因为操作系统遇到自己不能够处理的数据包(ip头中的protocol所指定的上层协议不能处理).就将这个包交给raw socket.而最后一种使用raw socket的目的主要是用来构建一些特殊的协议头,比如我们想对某台机器进行denial of service类型的攻击,但是有不想留下痕迹,让别人知道IP包的来源,这时候就可以使用raw socket来发送这些伪造源地址信息的包,这其实也是这种攻击所采用的主要技术手段.当然了,我说的是HACKER行为,之所以想要处理这些特殊的IP包,通常也是为了诊断网络的目的.

参考阅读：

1 raw socket protocol
2 keepalived
3 keepalived 简单配置自动切换ip实现HA
4 keepalived权威指南

原创内容如转载请注明：来自阿权的书房

收藏本文到网摘