Nginx+keeperAlive实现snmp服务的高可用

最新推荐文章于 2022-10-26 08:41:18 发布

菜鸟小学弟

最新推荐文章于 2022-10-26 08:41:18 发布

阅读量1.2k

点赞数

分类专栏： mid-tools 文章标签： java+nginx+keeperAliver

本文链接：https://blog.csdn.net/weixin_44734394/article/details/102726990

版权

mid-tools 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

- Nginx+keeperAlive实现snmp服务的高可用

由于公司给了任务要做snmp的高可用服务，在此对snmp一无所知，但还是得硬着头皮去做，没办法

1.准备工作了解snmp

Snmp理解应用
参考：https://www.cnblogs.com/xdp-gacl/p/4013984.html
使用Snmp协议作为远程监控的技术解决方案
参考：
https://www.cnblogs.com/xdp-gacl/tag/Snmp%E5%AD%A6%E4%B9%A0%E6%80%BB%E7%BB%93/
非常感谢这位大兄弟的博文让我对snmp有了深一步的认识

192.168.1.144 :为MIB有测试snmp发送的工具
Winds7:安装配置了snmp服务且开通了161端口，并且配置了可以接受的哪台机器

192.168.1.144-------->Win7 来达到对win7的监控效果。 161：服务器主动
<------
162端口则是win7出故障了，来告知192.168.1.144，有故障了。162:设备主动
如果本机开启了snmptrap用来被别人监控，那么自己的java代码的162端口则不你能启动端口不能绑定。
SnmpTrap_3.0加了用户名和密码，测试用户名就好了。

2.公司的项目snmp服务

1.snmp服务功能流程说明：

Controller ---- snmpReceiveThread:将原值转成值栈中就是一个消息队列中add(list),list为原值。
---- TaskManagerThread----TaskThread-----pretreatment:预处理返回preValue。
-----Analyser:分析模块返回AnalyserValue。
-----Consumer:数据消费。
线程采用单例模式设计：直接获取。

2.简单的demo
在这里插入图片描述

这两张图片助于理解网络编程

Udp:传输步骤。1，拿到地址。2，开始监听。3，创建内容。“不可靠协议”！
//初始化监听
		//snmptrap.listenaddress=udp\:127.0.0.1/162  
		String snmpAddress = ConfigManager.getInstance().getProperty("snmptrap.listenaddress");
		//127.0.0.1/162  
		Address targetAddress = GenericAddress.parse(snmpAddress);
		Snmp snmp = new Snmp(new DefaultUdpTransportMapping());
		snmp.listen();
		// 设置 target
		CommunityTarget target = new CommunityTarget();
		target.setAddress(targetAddress);
		// 超时时间
		target.setTimeout(1500);
		// snmp版本
		target.setVersion(SnmpConstants.version2c);
		
		// 创建 PDU
		PDU pdu = new PDU();
		if ("1".equals(s)) {//存储
			//oid
			pdu.add(new VariableBinding(new OID("1.3.6.1.6.3.1.1.4.1.0"),
					new OctetString("1.3.6.1.4.1.7777")));
			//ip
			pdu.add(new VariableBinding(new OID("1.3.6.1.4.1.7777.1"),
					new OctetString(snmp_ip)));
			//errorCode
			pdu.add(new VariableBinding(new OID("1.3.6.1.4.1.7777.3"),
					new OctetString("0")));
			//告警内容
			pdu.add(new VariableBinding(new OID("1.3.6.1.4.1.7777.2"),
					new OctetString(snmpAlarm)));
		}
	ResponseEvent respEvnt = snmp.send(pdu, target);

3.运用

理解了上面的之后对公司项目有了一个重新的认识，项目本身是来监控一些设备情况的，而且用的是snmptrap编程，也就是机器故障主动发到这个服务上来，这个服务来做进一步的解析。

keepalived高可用工作原理：
keepalived是以VRRP协议为实现基础的，VRRP全称Virtual Router Redundancy Protocol，即虚拟路由冗rong余协议。
在这里插入图片描述
原理：心跳检查（组播），（选举）（实现高可用的）
虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip（VIP = Virtual IP Address，虚拟IP地址，该路由器所在局域网内其他机器的默认路由为该vip），master会发组播，当backup收不到VRRP包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。

keepalived主要有三个模块，分别是core、check和VRRP。core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查，包括常见的各种检查方式。VRRP模块是来实现VRRP协议的。

1.当nginx主服务器宕机或发生异常，总之以任何理由造成服务器上的健康监测程序发生异常，无法和从服务器上的健康监测程序通信，此时从服务器上的健康监测机制就会认为主服务器挂了，从而将vip绑定到自身，成功上位，充当主服务器的角色。
2.在keepalive机制中，主服务器终究是主服务器，一旦主服务器恢复，边从新绑定vip，继续充当主服务器，而从服务器又成为了热备。
在这里插入图片描述
3.

一：安装

分别在主备nginx上面的服务器机器上安装keepalived。

二：配置

修改主和备nginx服务器上的keepalived 配置文件 /etc/keepalived/keepalived.conf 文件。

主机：
修改主nginx下/etc/keepalived/keepalived.conf文件
! Configuration File for keepalived

#全局配置
global_defs {
notification_email { #指定keepalived在发生切换时需要发送email 到的对象，一行一个
XXX@XXX.com
}
notification_email_ from XXX@XXX.com #指定发件人
#smtp_ server XXX. smtp.com #指定smtp服务器地址
#smtp _connect_timeout 30 #指定smtp连接超时时间
router_ id LVS_DEVEL #运行 keepalived机器的一个标识
} 
vrrp_instance VI_1 { 
state MASTER #标示状态为MASTER 备份机为BACKUP
interface eth0 #设置实例绑定的网卡
virtual_ router_id 51 #同一实例下virtual_router_id必须相同
priority 100 #MASTER权重要高于BACKUP 比如BACKUP为99 
advert_ int 1 #MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒
authentication { #设置认证
auth_type PASS #主从服务器验证方式
auth_pass 8888
}
virtual_ipaddress { #设置vip
192.168.101.100 #可以多个虚拟IP，换行即可
}
}

备用机：
配置备nginx时需要注意：需要修改state为BACKUP , priority比MASTER低，virtual_router_id和master的值一致

! Configuration File for keepalived 
#全局配置
global_defs {
notification_email { #指定keepalived在发生切换时需要发送email到的对象，一行一个
XXX@XXX.com
}
notification_email_ from XXX@XXX.com #指定发件人
#smtp_server XXX. smtp.com #指定smtp服务器地址
#smtp_connect_ timeout 30 #指定smtp连接超时时间
router_id LVS_ DEVEL #运行keepalived机器的一个标识
} 
vrrp_instance VI_1 { 
state BACKUP #标示状态为MASTER 备份机为BACKUP
interface eth0 #设置实例绑定的网卡
virtual_router_id 51 #同一实例下virtual_router_id必须相同
priority 99 #MASTER权重要高于BACKUP 比如BACKUP为99 
advert_int 1 #MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒
authentication { #设置认证
auth_type PASS #主从服务器验证方式
auth_pass 8888
}
virtual_ipaddress { #设置vip
192.168.101.100 #可以多个虚拟IP，换行即可
}
}

测试：

主备nginx都启动keepalived及nginx。
service keepalived start
./nginx

初始状态

查看主nginx的eth0设置：
vip绑定在主nginx的eth0上。
查看备nginx的eth0设置：
vip没有绑定在备nginx的eth0上。
访问ccc.test.com，可以访问。

主机宕机

在这里插入图片描述

主机恢复

在这里插入图片描述

问题：

1.2.8. 解决nginx进程和keepalived不同时存在问题
1.2.8.1. 问题描述
keepalived是通过检测keepalived进程是否存在判断服务器是否宕机，如果keepalived进程在但是nginx进程不在了那么keepalived是不会做主备切换，所以我们需要写个脚本来监控nginx进程是否存在，如果nginx不存在就将keepalived进程杀掉。
1.2.1.2. nginx进程检测脚本
在主nginx上需要编写nginx进程检测脚本（check_nginx.sh），判断nginx进程是否存在，如果nginx不存在尝试重启nginx，若无法启动，就将keepalived进程杀掉，check_nginx.sh内容如下：

#!/bin/sh
 如果进程中没有nginx，尝试重启nginx进程，若还是没有，则将keepalived进程kill掉、
A=`ps -C nginx --no-header |wc -l` ## 查看是否有nginx进程 把值赋给变量A 
if [ $A -eq 0 ];then 
/usr/local/nginx/sbin/nginx　　　　## 重启nginx进程 
sleep 2　　　　　　　　　　　　　　　　## 等待时间
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then　　## 还是没有nginx进程 
killall keepalived　　　　　　　## 杀掉keepalived
fi
fi
将check_nginx.sh拷贝至/etc/keepalived下，

脚本测试：
将nginx停止，将keepalived启动，执行脚本：sh /etc/keepalived/check_nginx.sh

从执行可以看出自动将keepalived进程kill掉了。
1.2.8.3. 修改keepalived.conf
修改主nginx的keepalived.conf，添加脚本定义检测：参考keepalived之vrrp_script详解；
注意下边红色标识地方：
#全局配置 
global_defs { 
notification_email { #指定keepalived在发生切换时需要发送email到的对象，一行一个 
XXX@XXX.com 
} 
notification_email_from miaoruntu@itcast.cn #指定发件人 
#smtp_server XXX.smtp.com #指定smtp服务器地址 
#smtp_connect_timeout 30 #指定smtp连接超时时间 
router_id LVS_DEVEL #运行keepalived机器的一个标识 
}
 keepalived会定时执行脚本并对脚本执行的结果进行分析,动态调整vrrp_instance的优先级。 
##如果脚本执行结果为0,并且weight配置的值大于0,则优先级相应的增加。如果脚本执行结果非0, 
##并且weight配置的值小于 0,则优先级相应的减少。其他情况,维持原本配置的优先级,即配置文件中priority对应的值。

vrrp_script check_nginx { 
script "/etc/keepalived/check_nginx.sh" ##监控脚本 
interval 2 ##时间间隔，2秒 
weight -20 ##权重 
} 
vrrp_instance VI_1 { 
state MASTER #标示状态为MASTER 备份机为BACKUP 
interface eth0 #设置实例绑定的网卡 
virtual_router_id 51 #同一实例下virtual_router_id必须相同 
priority 100 #MASTER权重要高于BACKUP 比如BACKUP为80 
advert_int 1 #MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒 
authentication { #设置认证 
auth_type PASS #主从服务器验证方式 
auth_pass 8888 
} 
track_script { 
check_nginx #监控脚本 
} 
virtual_ipaddress { #设置vip 
192.168.101.100 #可以多个虚拟IP，换行即可 
} 
}
修改后重启keepalived
接着看下面这段配置，这段配置的意思是，每隔2秒中去执行/etc /keepalived /nginx_check.sh 脚本一次，这项检查从开始便一直进行，interval表示间隔时间，weight -20的意思是，脚本执行成功后把当前节点的优先级降低20。
vrrp_script chk_nginx {
script "/etc/keepalived/nginx_check.sh"
interval 2
weight -20
}

state MASTER表示该节点角色定义为MASTER，interface eth0是指虚拟机的网卡是eth0。virtual _ router _ id 51这项配置非常重要，两个节点的这项配置的值必须一样，否则会出现乱七八糟的问题，这里我把virtual_router_id的值设置为51。mcast_src_ip 192.168.101.3这项配置是指定当前节点的真实IP。priority 100的意思是优先级，这里暂且设置为100，当然也可以是其它值。优先级在keepalived实现高可用方面起着至关重要的作用，keepalived服务器就是根据优先级来选择当前提供服务的设备的，192.168.101.3刚开始设置的优先级是100,192.168.101.4 刚开始设置的优先级是 90，这样keepalived 一开始去检查优先级，发现192.168.101.3 这台设备的优先级高，于是便让该设备对外提供服务，当192.168.101.3这台设备的nginx挂掉后，由于nginx_check.sh 脚本每两秒执行一次，发现192.168.101.3这个节点没有nginx进程后便尝试进行重新启动nginx，如果重新启动还是不行的话，就杀掉所有的keepalived进程，并告诉keepalived服务器192.168.101.3 这个节点的nginx 挂掉了同时会把这个节点的优先级减20，从而优先级变为了80，这样下次keepalived 来检查优先级发现192.168.101.4这个节点的优先级比较高（90），于是便让192.168.101.4 这个节点对外提供服务，同理，这个节点发生故障的话，也会再去让另外一个节点来提供服务，这就实现了高可用。
1.2.8.4. Keepalived中Master和Backup角色选举策略
在Keepalived集群中，其实并没有严格意义上的主、备节点，虽然可以在Keepalived配置文件中设置“state”选项为“MASTER”状态，但是这并不意味着此节点一直就是Master角色。控制节点角色的是Keepalived配置文件中的“priority”值，但并它并不控制所有节点的角色，另一个能改变节点角色的是在vrrp_script模块中设置的“weight”值，这两个选项对应的都是一个整数值，其中“weight”值可以是个负整数，一个节点在集群中的角色就是通过这两个值的大小决定的。
在一个一主多备的Keepalived集群中，“priority”值最大的将成为集群中的Master节点，而其他都是Backup节点。在Master节点发生故障后，Backup节点之间将进行“民主选举”，通过对节点优先级值“priority”和““weight”的计算，选出新的Master节点接管集群服务。
在vrrp_script模块中，如果不设置“weight”选项值，那么集群优先级的选择将由Keepalived配置文件中的“priority”值决定，而在需要对集群中优先级进行灵活控制时，可以通过在vrrp_script模块中设置“weight”值来实现。下面列举一个实例来具体说明。
假定有A和B两节点组成的Keepalived集群，在A节点keepalived.conf文件中，设置“priority”值为100，而在B节点keepalived.conf文件中，设置“priority”值为80，并且A、B两个节点都使用了“vrrp_script”模块来监控nginx服务，同时都设置“weight”值为10，那么将会发生如下情况：
在两节点都启动Keepalived服务后，正常情况是A节点将成为集群中的Master节点，而B自动成为Backup节点，此时将A节点的nginx服务关闭，通过查看日志发现，并没有出现B节点接管A节点的日志，B节点仍然处于Backup状态，而A节点依旧是Master状态，在这种情况下整个HA集群将失去意义。

“weight”值为正数时
“weight”值为负数时
以上两种情况的更新策略参考博文：keepalived之vrrp_script详解
1.2.8.5 测试
回到负载均衡高可用的初始状态，保证主、备上的keepalived、nginx全部启动。
停止主nginx服务
观察keepalived日志：
tail -f /var/log/keepalived.log

查看keepalived进程已经不存在。
查看eth0已经没有绑定vip。

菜鸟小学弟

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Nginx+keeperAlive实现snmp服务的高可用

- Nginx+keeperAlive实现snmp服务的高可用由于公司给了任务要做snmp的高可用服务，在此对snmp一无所知，但还是得硬着头皮去做，没办法1.准备工作了解snmpSnmp理解应用参考：https://www.cnblogs.com/xdp-gacl/p/4013984.html使用Snmp协议作为远程监控的技术解决方案参考：https://www.cnblogs.c...
复制链接

扫一扫