当前位置:首页 > CN2资讯 > 正文内容

eplices服务器开启 epg服务器连接失败

13小时前CN2资讯

一、 故障现象

部分机顶盒用户出现大面积登录APP时,界面停留在登陆页面,无反应。

 

二、 现象初步分析

本次问题出现时,所有AAA出现了异常流量波动,在AAA异常流量段期间接到用户故障报障。此时主要表现在LVS集群显示真实的EPG 服务器不停的被踢出集群和加入(UP/DOWN),导致了用户调度到EPG后出现了异常显示。

AAA异常流量图

 

三、 问题排查过程

接到故障后第一时间对AAA/EPG后台日志进行了查看,发现用户接入认证和响应都正常,观察到EPG 的LVS集群中有服务器的inactive连接数异常并且随机出现不同EPG服务器被踢出和加入集群,随后对EPG 的LVS集群的状态进行了跟踪和抓包分析,为了快速恢复业务随后重启了EPG tomcat并进行了LVS的主备切换,业务故障恢复。

 

四、 诊断分析结果

   出现故障时通过LVS的日志可以看到5台EPG服务器在轮询的出现连接失败和连接成功的情况,也就是一台OK后,另一台出现连接失败,如此反复的表现在5台EPG服务器上

此时被UP/DOWN的EPG会出现大量的inactive

 

此时对集群出现UP/DOWM的服务器进行抓包,发现客户端发出了SYN报

文,但是EPG服务器没有响应,并且响应报文发不出去不停的retransmission。

进一步查看该EPG的资源消耗情况netstat发现大量的SYN-RECV

 

通过上面的现象判断是EPG的socket资源被耗尽进而出现了响应客户端异常,导致了LVS检测EPG服务器异常,因集群是5台EPG服务器,一台异常后LVS集群把用户调度到其它EPG服务器,此时异常用户也对该服务器产生了影响出现了该服务器也被资源耗尽,依次循环。根据当前的用户量程度来看一般EPG的资源应该是可以满足,进一步查看资源情况发现是EPG的句柄数被耗尽导致的,当重启EPG后,资源被释放句柄数被释放问题故障就恢复了。查看EPG服务器发现系统的默认句柄数为1024。

LVS原理分析:

当有异常用户访问EPG时,SYN消息先发送到LVS,LVS会建立一个调度表,显示用户与EPG的TCP对应关系,EPG会直接返回ACK给用户端不经过LVS,只有LVS收到用户端发送的FIN时,表项的对应关系才会删除该用户客户端的EPG对应关系。

当用户访问突然异常且量大的时候EPG默认的句柄数只有1024,这样会导致LVS踢出该EPG,但是此时LVS建立的表里面的TCP关系还在所以inactive数会变的特别大,根据LVS调度策略用户会被调度到其它EPG真实服务器,这样就会形成恶性循环,所有集群的EPG真实服务器会被资源耗尽。

 

五、处理优化措施

从上述分析来看本次故障根本原因是EPG真实服务器的句柄数采用默认的1024,一旦出现异常用户访问的时候就会变的脆弱,目前修改为了204800。经过本次故障,对系统的参数做了确认和文档化

 

六、参数修改记录

修改记录一:net.ipv4.tcp_timestamps = 0

原因如下

1、slb服务器为了优化性能,调整以下内核参数:

net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_tw_recycle = 1

当这两个参数都打开时,tcp需要校验syn包的时间戳(timestamp)对集团用户有影响使其接入失败。

 

2、当满足以下条件,syn包将会被忽略,不会回复ack包:

        a、该源ip的上次tcp通讯发生在60s内。

        b、该源ip的上次tcp通讯的timestamp 大于本次tcp。

        注:tcp通讯的timestamp 为系统启动到当前的时间。

 

3、解释现象:

        a、为什么普通的用户播放正常,集团用户不行?

            一个ip对应一个普通用户,那么普通用户的tcp通讯的timestamp是一直增大的,即不会满足2中的b条件。

            集团用户是做了NAT的,一个ip对应多个客户端,只有tcp通讯的timestamp比较大的客户端(大堂)才能请求成功,timestamp比较小的(房间)请求就失败。

 

        b、房间偶尔又能播放?

             该源ip的上次tcp通讯发生在60s之外了。

 

修改记录二:net.ipv4.tcp_max_tw_buckets = 5000

TIME_WAIT状态的连接过多,会影响到大并发。

 

修改记录三:net.ipv4.tcp_synack_retries = 0

net.core.somaxconn = 65535

原因如下:

SYN Flood(TCP洪水攻击优化)

tcp_synack_retries:表示回应第二个握手包(SYN+ACK包)给客户端IP后,如果收不到第三次握手包(ACK包)后,不进行重试,加快回收“半连接”,不要耗光资源。可以把tcp_synack_retries改为0,因为客户端还有tcp_syn_retries参数,默认是5,即使服务器端没有重发SYN+ACK包,客户端也会重发SYN握手包。

net.core.somaxconn:最大的监听队列的长度,默认限制为128,在高突发的请求中可能会导致链接超时或触发重传。

 

修改记录四:

括号值为修改后的值,(X)代表删除。

net.ipv4.tcp_fin_timeout = 5 (1) net.ipv4.tcp_max_syn_backlog = 10240(262144) net.ipv4.tcp_max_tw_buckets = 5000(6000) net.ipv4.tcp_mem = 24794688 33059584 49589376 (X) net.ipv4.tcp_retries1 = 3 (2) net.ipv4.tcp_retries2 = 15(2) net.ipv4.tcp_keepalive_intvl = 75(2) net.ipv4.tcp_keepalive_probes = 9(3) net.ipv4.tcp_keepalive_time = 7200(2) net.ipv4.tcp_rmem = 4096 87380 4194304(X) net.ipv4.tcp_syn_retries = 2 net.ipv4.tcp_timestamps = 0(1)// timestamps可单独起效 net.ipv4.tcp_tw_recycle = 1(0)// 需要timestamps起效,此项才奇效,单独开启无意义 net.ipv4.tcp_wmem = 4096 16384 4194304(X) net.ipv4.udp_mem = 24794688 33059584 49589376(X) net.ipv4.udp_rmem_min = 4096(X) net.ipv4.udp_wmem_min = 4096(X) net.core.rps_sock_flow_entries = 65535 // nf_conntrack 避免iptables的conntrack模块故障 net.netfilter.nf_conntrack_acct = 0 net.netfilter.nf_conntrack_checksum = 1 net.netfilter.nf_conntrack_events = 1 net.netfilter.nf_conntrack_events_retry_timeout = 5 net.netfilter.nf_conntrack_expect_max = 256 net.netfilter.nf_conntrack_generic_timeout = 6 net.netfilter.nf_conntrack_helper = 1 net.netfilter.nf_conntrack_icmp_timeout = 3 net.netfilter.nf_conntrack_log_invalid = 0 net.netfilter.nf_conntrack_max = 524288 net.netfilter.nf_conntrack_tcp_be_liberal = 0 net.netfilter.nf_conntrack_tcp_loose = 1 net.netfilter.nf_conntrack_tcp_max_retrans = 2 net.netfilter.nf_conntrack_tcp_timeout_close = 5 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 6 net.netfilter.nf_conntrack_tcp_timeout_established = 5 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 3 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 3 net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 3 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 3 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 3 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 2 net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 3 net.netfilter.nf_conntrack_timestamp = 0 net.netfilter.nf_conntrack_udp_timeout = 3 net.netfilter.nf_conntrack_udp_timeout_stream = 3 net.nf_conntrack_max = 524288

 

修改记录五:

net.ipv4.tcp_max_tw_buckets = 6000 (262144)

原因:tcp_max_tw_buckets的默认值为262144

 

修改记录六:

增加修改文件句柄数:在/root/.bash_profile增加ulimit -n 204800

 



    你可能想看:

    扫描二维码推送至手机访问。

    版权声明:本文由皇冠云发布,如需转载请注明出处。

    本文链接:https://www.idchg.com/info/23471.html

    分享给朋友:

    “eplices服务器开启 epg服务器连接失败” 的相关文章

    CN2 GIA VPS推荐:最佳虚拟专用服务器选择

    CN2 GIA VPS概述 在当今数字时代,寻找一个稳定且高效的虚拟专用服务器(VPS)成为很多企业和个人用户的需求。而CN2 GIA VPS凭借其卓越的性能和稳定的连接,受到了越来越多的关注。简单来说,CN2 GIA是一种中国电信提供的高质量网络传输线路,可以确保数据的快速和安全传输。 我曾尝试过...

    如何高效使用测速脚本监测网络性能

    在互联网的快速发展中,网络测速变得越来越重要。作为一个互联网用户,了解自己的网络性能是否稳定,以及在不同时间与地点的表现,能帮助我们更好地选择服务和进行问题排查。网络速度直接影响了我们的在线体验,无论是看视频、玩游戏,还是进行远程办公,网络性能都扮演着至关重要的角色。 测速脚本出现在这样的背景下,它...

    Hostodo VPS主机使用体验与性能评测

    当我第一次听说Hostodo时,正是2014年,这家美国VPS主机商在市场上开始崭露头角。印象中,它的低价VPS产品让我感到十分吸引,尤其是在对比市场上其他的主机商时,Hostodo的性价比确实相当有优势。它主营的KVM型和NVMe硬盘的KVM型VPS在当时的市场中并不是常见的选择,迅速吸引了许多站...

    深入了解M247 VPS:价格、性能与适用场景全分析

    M247 VPS概述 在如今数字化时代,云计算的需求不断上升,各种VPS(虚拟专用服务器)服务也层出不穷。今天我想和大家分享的是M247 VPS,它是一家相对年轻但却在行业内逐渐崭露头角的服务商。M247成立于2012年,隶属于M24Seven Group旗下,提供多种服务,包括VPS、虚拟主机、服...

    AWS VPS Free: 如何利用AWS Free Tier免费服务轻松构建云计算项目

    当我第一次接触AWS (亚马逊网络服务) 的时候,最吸引我的就是他们提供的各种免费的VPS服务。AWS的VPS免费服务实际上是一种叫做AWS Free Tier的计划,它允许用户在一定条件下使用AWS的多种服务而无需支付费用。这项计划的意义在于,它为刚入门的开发者和小型企业提供了一个绝佳的机会,能够...

    RackNerd在纽约的数据中心服务与优势

    RackNerd在纽约的数据中心的服务确实引人关注。从基础服务到多样化的产品,RackNerd为各类客户提供了丰富的选择。我对于他们的虚拟主机和独立服务器十分赞赏。这些服务不仅安全可靠,而且具有灵活的配置选项,满足了各种不同需求的用户。对于初创企业或者需要特别高可用性的业务,选择RackNerd无疑...