小集群中扩容机器网络不通问题分析

最新推荐文章于 2023-01-25 10:08:33 发布
最新推荐文章于 2023-01-25 10:08:33 发布
阅读量1.5k 收藏 2
点赞数 2
文章标签： 网络 linux 服务器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhangguanshi/article/details/121301631
版权

背景：

业务自动扩容出现机器问题，新扩容机器无法访问原有集群机器的服务问题。查了比较长时间，这里总结下排除信息和过程。初步结论是小集群中扩缩容节点使用了内网IP复用而ARP cache没有回收造成的网络不通的问题。

案例：

产研反馈：之前发现的网络问题又出现了（说明之前出现过3次以上），某服务到部分节点不通，试了下 这几个方向都是 ping 不通的，为了便于说明，把几台机器做个编号：

机器A: xx.xx.2.217

机器B：xx.xx.3.115

机器C：xx.xx.1.185

机器D：xx.xx.3.71

  1. 现象

初步分析是基于aws自动扩容组新扩出来的机器A，通过内网IP无法ping到集群中原有机器BCD，部分能通部分不通。首先想到是arp问题，分析现象是机器B上的IP A217对应 的mac地址一直处于STALE状态，腐化但不被删除，缓存时间可长达数天，远远超过了arp cache默认时间 60s。集群中其他机器B缓存了该IP错误的mac地址，导致A无法调用B的服务。217能ping 到BCD等机器，三台机器能收到arp包，但无法收到他们的回包（tcpdump分析）。

部分能通信的机器上此时对应机器A 的mac 是 xx:xx:xx:59:91:b2，正常机器

# arp|grep 217
ip-xx-xx-2-217.ap-south  ether   xx:xx:xx:59:91:b2   C                     eth0

集群原有机器B、C、D上的mac addr是xx:xx:xx:35:94:dc ，缓存了不一样的mac ，如下：

 # arp|grep 217 
ip-xx-xx-2-217.ap-south  ether   xx:xx:xx:35:94:dc   C                     eth0

xx:xx:xx:35:94:dc 可能是上次分配IP 217时绑定过的mac addr。mac 缓存记录状态持续处于STALE状态，如下：

# ip neigh ls all|grep 217
xx.xx.2.217 dev eth0 lladdr xx:xx:xx:35:94:dc STALE

在217 ping 185 ，第十个包才收到回应

$ ping xx.xx.1.185

PING xx.xx.1.185 (xx.xx.1.185) 56(84) bytes of data.

64 bytes from xx.xx.1.185: icmp_seq=10 ttl=64 time=0.127 ms //不清楚原因

64 bytes from xx.xx.1.185: icmp_seq=11 ttl=64 time=0.121 ms

64 bytes from xx.xx.1.185: icmp_seq=12 ttl=64 time=0.107 ms

  1. 初步猜测与分析方向：

  1. 怀疑是arp缓存过期慢问题，如果关闭arp缓存可能可以解决

担心风险：关闭后任何机器跟其他机器通信都要arp解析mac地址，担心对性能，arp广播数量暴涨影响。

  1. 怀疑跟aws auto scaling group+ spot有关

怀疑spot IP重分配太快，导致上一次没有在交换机被清理，下一次又用到了同一IP，导致现在问题。

准备关闭spot ，但为了arp 问题关闭spot貌似是在回避问题绕过问题，spot好技术不能使用。spot的分配时实际并没有频繁，10+次/天。

  1. 怀疑无回包可能是本机路由有缓存且是错误缓存

A217存活期间，怀疑是mac所在老机器还活着，且时不时跟集群现有机器b、c、d通信，导致mac一直未更新。查看路由是空的。

@ip-xx-xx-0-236:~$ route -Cn

Kernel IP routing cache

Source Destination Gateway Flags Metric Ref Use Iface

通过tcpdump观察，发现并没有这个其他机器用这个mac地址通讯

  1. 怀疑是路由缓存后“本地确认”问题

用iptables drop掉的情况，阻断再次连接，结果缓存还是存在，未被清理。

sudo iptables -A INPUT -s xx.xx.2.217 -j DROP
236:~$ ip -s -s neigh show |grep 2.217
xx.xx.2.217 dev eth0 lladdr xx:xx:xx:59:91:b2 used 240332/240326/240281 probes 1 STALE
236:~$ sudo iptables -A INPUT -s xx.xx.2.217 -j DROP
236:~$ date
Mon Aug 10 02:23:52 UTC 2020
236:~$ date
Mon Aug 10 03:16:43 UTC 2020
236:~$ sudo iptables -D INPUT -s xx.xx.2.217 -j DROP

发现依然是STALE状态

  1. 怀疑arp mac记录状态机在不断变化，续租更新到STALE状态

~$ watch -n1 "ip -s -s neigh show |grep 217"

Every 1.0s: ip -s -s neigh show |grep 217 Mon Aug 10 04:05:54 2020

xx.xx.2.217 dev eth0 lladdr xx:xx:xx:59:91:b2 used 246119/246114/246068 probes 1 STALE

状态没有变化，也就是没有经过delay、reachable、probe等状态

其实能想到，扩容机器下线很久后，都还有arp缓存，跟“续租”没啥关系；

  1. 怀疑过期时间参数配置错误，太长导致一直没更新

217机器A回收3天后，115等多台机器还是保留着这个arp cache 。

$ ip -s neigh list|grep 217

xx.xx.2.217 dev eth0 lladdr xx:xx:xx:35:94:dc used 173095/173065/173028 probes 4 STALE

ps: 173095/173065/173028

表示这条记录存在了过了48小时多。远超过net.ipv4.neigh.*.gc_interval = 30 时间30s。

  1. 初步确认现象并多机器验证：

当机器A回收很久后，机器BCD的arp cache记录没有被清理，机器BCD上的对应机器A217的mac addr是过期的错误的mac，下次如果有机器复用了IP217，BCD还是回包到老mac上，导致新A217无法跟BCD正常通信。

举一反三并验证问题：怀疑集群中还有大量这种情况。之前自动扩容出来，然后被缩容掉的ip还被集群中其他主机arp 缓存了，找了一台现有机器xx-xx-0-236分析

 #ip -s -s neigh show |grep STA
xx.xx.0.77 dev eth0 lladdr 06:5f:b9:b3:d4:1e used 160634/160608/160583 probes 4 STALE
xx.xx.2.167 dev eth0 lladdr 06:36:73:af:f7:ee used 409277/409246/409226 probes 4 STALE
xx.xx.0.40 dev eth0 lladdr 06:80:0a:a6:c7:ba used 878/873/847 probes 1 STALE
xx.xx.1.179 dev eth0 lladdr 06:fd:14:c9:60:40 used 165297/165272/165240 probes 1 STALE
xx.xx.3.130 dev eth0 lladdr 06:62:80:a0:43:0a used 1230063/410256/410226 probes 4 STALE  //长达14天
xx.xx.3.18 dev eth0 lladdr 06:d1:f4:27:6b:64 used 161097/161069/161043 probes 4 STALE
...

有大量IP是长时间被缓存的，是扩容后缩容了，被集群其他主机缓存了，长时间没被清理，多找了几台分析，证实了集群中大量存在STALE，基本确定是本机arp cache不删除问题。

  1. 根因分析

确定没有回收，大概率是跟gc相关参数配置有关。

查看MAC cache gc内核参数：

net.ipv4.neigh.*.gc_interval = 30
net.ipv4.neigh.*.gc_stale_time = 60
net.ipv4.neigh.*.gc_thresh1 = 128
net.ipv4.neigh.*.gc_thresh2 = 512
net.ipv4.neigh.*.gc_thresh3 = 1024
net.ipv4.neigh.*.gc_stale_time = 60

gc_interval间隔是30s，gc_state_time=60s，应该很快被回收才对，但没有回收，应该是根本原因。

  1. 相关参数

跟gc相关的内核参数有14个：

net.ipv4.conf.*.arp_accept = 0
net.ipv4.conf.*.arp_announce = 0
net.ipv4.conf.*.arp_filter = 0
net.ipv4.conf.*.arp_ignore = 0
net.ipv4.conf.*.arp_notify = 0
net.ipv4.conf.*.drop_gratuitous_arp = 0
net.ipv4.conf.*.proxy_arp = 0
net.ipv4.conf.*.proxy_arp_pvlan = 0
net.ipv4.neigh.*.gc_interval = 30
net.ipv4.neigh.*.gc_stale_time = 60
net.ipv4.neigh.*.gc_thresh1 = 128
net.ipv4.neigh.*.gc_thresh2 = 512
net.ipv4.neigh.*.gc_thresh3 = 1024
net.ipv4.neigh.*.gc_stale_time = 60

  1. GC过程及条件

gc_interval，gc_thresh1，gc_thresh2，gc_thresh3，gc_stale_time。

gc_thresh3是arp_tbl中允许拥有的邻居数量的上限，一旦超过这个上限，并且表中没有可以清理掉的垃圾邻居，那么就无法创建新的邻居，这个 值缺省被置为1024。

gc_thresh2是第二个阀值，如果表中的邻居数量超过这个阀值，并且在需要创建新的邻居时，发现已经超过5秒时间表没有被刷 新过，则必须立即刷新arp_tbl表，进行强制垃圾回收，这个值缺省被置为512。

gc_thresh1是触发真正清理的条目数量下限阈值，它缺省被置为128。

gc_interval应该是常规的垃圾回收间隔时间，缺省置为30秒。间隔这个时间后执行gc动作，符合条件的缓存记录从arp_tbl表中删除。

gc_stale_time 是STALE状态的记录生存时间。

常规垃圾回收的定时器，其定时处理函数是neigh_periodic_timer。

  1. ARP 缓存状态机

  1. 确定原因

neigh/default/gc_thresh1 - INTEGER Minimum number of entries to keep. Garbage collector will not purge entries if there are fewer than this number. Default: 128

我们的集群都较小小，gc_thresh*是针对cache条目数量的，可能都不到128

static void neigh_periodic_work(struct work_struct *work)
{
	struct neigh_table *tbl = container_of(work, struct neigh_table, gc_work.work);
	...
	if (atomic_read(&tbl->entries) < tbl->gc_thresh1)
		goto out;

所以当缓存中的条目数量少于gc_threash1时，根本不会执行gc过程，直接goto out跳出了

我们生产的集群都比较小，查看arp -a|wc -l，发现都在50-100之间，基本判断<128，没有达到进行真正回收的阈值下限。我们尝试 把gc 条件的条目数设置小一点，使之触发gc。

$sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=30

结果很快回收了，1分钟左右

小结：之前的128是不合适的，设为30其实也不一定合适，还真有可能arp cache entries<30的，所以设置为0或1可能是更好的选择

  1. GC过程原理再次理解：

在gc_interval间隔时间后，会触发执行arp cache gc，但真正要不要执行purge ，还要看cache 中的条目数量， gc_thresh1就是这个下限。少于这个数量就不会真正执行purge。

我们的集群都比较小，cache数量基本在50-100条左右，gc_thresh1默认值是128 ，导致一直没有真正删掉cache 条目

总结综述：arp cache长期不更新的情况

现象：ec2 A 217是新扩容机器 ，起来后跟集群中原有机器ec2 BCD通信，BCD会缓存A的mac addr。当 A 被回收后，BCD主机中对应A217 的arp cache 没有清理，被标识为STALE状态。当A之前用的IP 217被下次弹出的E 使用了，会出现E跟BCD服务调用不同的情况，从应用层看无法建立连接。从三层看是E能ping BCD, 但BCD无法回包到E。这些arp缓存记录长期不清理。

根因：是小集群中单台机器互相通信的机器数量少，没达到进行gc的条目数量，根因是机器的arp 参数配置不科学，没有根据小集群的特点进行配置。跟交换机缓存、路由缓存、arp续租等都没有关系。

GC有三层控制：1、触发gc动作，2、cache记录已经过期，3、cache列表中记录数达到gc_thresh*阈值。

解决方案比较：

从单台上来看很简单,有几种方法都可以：

  1. 定时arp flush 一次（按天/小时）比关闭arp cache风险小

缺点：但flush之前一段时间还是有业务风险

  1. 改基础镜像，每次开新机器都要自动使用小gc_thresh1参数

缺点：在底层改动，不确定是否适用其他业务，SA同学不同意

  1. 把gc 条件的条目数gc_thresh1（默认128）设置小一点（小集群中能达到的互相通信的机器数量，可能是个位数），使之真正清理cache记录。

缺点：必须全网每台机器改一遍，以后新扩的机器都要改。在ec2初始化完成后SRE验收时或是在使用部署服务时去改。

  1. 新实例启动时广播arp

缺点：原理可行但AWS vpc不支持广播因此无法执行

为什么要记录这个文档

因为这是一个小集群，很容易出现arp cache数量小于默认参数128的情况

有人理解为关闭arp cache就好，借此机会深入复习理解ARP原理

在分析过程中也发现国外有用户碰到这个问题，貌似没有彻底解决。如：linux - When do STALE arp entries become FAILED when never used? - Server Fault

参考资料：

阿里云开发者社区-云计算社区-阿里云

Linux实现的ARP缓存老化时间原理解析_Netfilter,iptables/OpenVPN/TCP guard:-(-CSDN博客_arp老化时间

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

arp(7) - Linux manual page

https://github.com/torvalds/linux/blob/47ec5303d73ea344e84f46660fff693c57641386/net/core/neighbour.c

观石
关注
  • 2
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Apache Hadoop2.6.2 小集群搭建
技术大神之路
03-31 890
1. 拓扑结构图4台机器，搭建图如下 1,2,3,4 分别记做 Hagrid01，Hagrid02，Hagrid03，Hagrid04 NN指的是 Namenode JN指的是JournalNode DN指的是DataNode 生产环境下，Active NN 和 Standby NN 都应该单独占用一台机器，这里为了节省资源，StandbyNN上也做了 JN 和 DN 2. 对每台机器
电网大数据挖掘与机器学习.pptx
最新发布
05-22
- **云存储**：利用云计算平台提供的服务，如数据备份、容灾以及弹性扩容等功能，提高数据的安全性和可用性。 - **数据仓库**：构建面向业务分析的主题数据仓库，以满足不同场景下的数据查询和分析需求。 #### 五、...
Linux中arp表的老化机制
caofengtao1314的专栏
08-20 3749
转发网址：https://www.cnblogs.com/lsgxeva/p/13749751.html Linux内核网络协议栈中自动维护着一堆网络协议，这堆网络协议在内核中也是不同的存在，对于arp，Linux内核就提供了一种缓存机制来维护这张表。 实际的使用场景是，网络设备维护的arp表与内核维护的arp表相同步，一旦有变化，便通过钩子通知到上层的arp模块。但对于网络设备的arp模块来说，还需要实现一个arp老化时间的功能，这个功能的实现便也依靠了linux内核的arp表老化。 内核是如何维护
mysql小集群
Jerry_Pan1990的博客
06-25 264
初学者的一些笔记，有不妥的地方，请多多包涵。本人在虚拟机上，用 docker 安装了 四台 mysql ： **********************************************************************************************************1、 配置各个 msyql 服务的 my.cnf ：两台主机：除常规配置外：ma...
Hadoop入门第四篇：手动搭建自己的hadoop小集群
weixin_30670925的博客
08-18 150
前言 　　好几天没有更新了，本来是应该先写HDFS的相关内容，但是考虑到HDFS是我们后面所有学习的基础，而我只是简单的了解了一下而已，后面准备好好整理HDFS再写这块。所以大家在阅读这篇文章之前，请先了解HDFS的相关基本概念。 本次搭建是手动在三台机器上搭建的，后续会尝试用docker或者apache ambari来搭建管理集群，这次搭建只是能够通过动手去更深的了解hadoop...
小集群的使用说明
moyu5021的博客
01-10 961
摘要：描述了小集群的简单使用，供学生参考
搭建小集群步骤
deaqx88824的专栏
11-11 171
设置网卡 装gcc 挂载redhat iso，装unixODBC 挂载samba mount //192.168.2.2/pub /HDFS -o username=lixun,password=123456 将这个命令 写进/etc/rc.d/rc.local ，在最后添加。 更改local 教程 https://jingyan.baidu.com...
【机器视觉】华为 HoloSens IVS3800X V8.1.0 产品概述 V1.0.docx
09-23
- **扩容**：支持灵活的扩容方案，可根据实际需求增加服务器或利用已有资源。 #### 十六、安全性 - **安全性设计**：从物理层到应用层全方位的安全防护措施，保障系统运行安全。 #### 十七、开放易集成 - **开放...
监控项目中存储服务器、IP-SAN、云存储方案的优劣势对比.pdf
05-24
更方便且安全的扩容方式，只需在存储后端添加扩展柜即可完成扩容；更便捷的管理，可通过网页的形式对存储系统进行管理、监控。该方案非常适用于绝大多数集中式视频监控存储情形。然而，该方案也存在一些缺点，如部署...
腾讯 clickhouse应用实践.pdf
05-25
腾讯的扩容方案是基于 Shard 的，首先安装新的 Shard 机器，然后创建表结构，最后批量修改当前集群的配置文件增加新的 Shard。 大批量，少批次 Write Model ClickHouse 的 Write Model 是非常重要的，需要根据实际...
kubernetes小集群搭建第一次实验
qq_41686966的博客
07-04 515
kubernetes小集群搭建第一次实验master:192.168.79.31  同时作为nodenode:192.168.79.311、master、node各执行yum install etcd kubernetes flannel net-tools -y2、配置高可用etcd，配置文件/etc/etcd/etcd.conf内容如下：master：ETCD_DATA_DIR="/var/l...
GARP(Gratuitous ARP)
redwingz的博客
10-29 2450
内核函数arp_is_garp判断ARP报文是否为GARP，先决条件是发送者IP和目标IP地址相同，另外，对于ARP回复（REPLAY）报文，要求如果目标硬件地址存在，需要与发送者硬件地址相等。最后，要求ARP报文的发送者IP为单播地址，否则，判定报文不是garp。 static bool arp_is_garp(struct net *net, struct net_device *dev, int *addr_type, __be16 ar_op, __b
邻居表项的回收控制
redwingz的博客
11-14 2734
内核中存在3个阈值控制邻居表项的回收： gc_thresh1 表示最小可保留的表项数量，如果表项数量小于此值GC（Garbage collector）不进行回收操作，默认为128； gc_thresh2 当表项数量超过此值时，GC将会清空大于5秒的表项，默认为512； gc_thresh3 最大可允许的非永久表项数量。如果系统拥有庞大的接口数量，或者直连了大量的设备，应增大此值。默认值为1024。 另外，gc_interval不太清楚有什么用处，默认值为30秒钟。 对于IPv4，可通过以下PROC
第三十六章：路由：相关主题
weixin_42525458的博客
10-08 496
前面看的已经全忘了，看了个寂寞，哎，再也不看这种比较硬核的书了。
1、linux内核参数注释,Linux系统优化部分内核参数调优中文注释
weixin_42481708的博客
05-12 303
应用服务器sysctl.conf部分参数## network configurationsnet.ipv4.ip_forward = 0 # IP packet forwardingnet.ipv4.tcp_tw_reuse=1net.ipv4.tcp_tw_recycle=1net.ipv4.tcp_fin_timeout=30 #60,每条至多占 1.5K 的内存net.ipv4.tcp_k...
Kubernetes（K8S）内核优化常用参数详解
小云的博客
02-10 4221
net.ipv4.tcp_keepalive_time=600 net.ipv4.tcp_keepalive_intvl=30 net.ipv4.tcp_keepalive_probes=...
IP 命令详解
hunyxv的博客
07-13 1万+
命令格式： ip [ OPTIONS ] OBJECT { COMMAND | help }OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] | -f[amily] { inet | inet6 | ipx | dnet | link } | -o[neline] | -n[etns] name } OBJECT := { link |
【笔记】openwrt - full cone NAT（全锥NAT）、解决“arp_cache: neighbor table overflow!”
热门推荐
LawssssCat的博客
01-25 7万+
最近安装了比特彗星（bitcomet）后，老是收到警告说日志的接收超过每秒上限了。一看日志，好家伙，一堆的日志，还是kernel的，还是info的？网上找问题原因、解决方法，最接近的就是lede的这个issue两个东西共同造成的在openwrt中打开了FullCone NAT（全锥NAT）在比特彗星（bitcomet）中默认设置了network.max_udp_pkt_per_sec（每秒最大udp数据包发送量）为1000但至于这些东西是什么？做什么的？什么意思？为啥这样这样就会有日志警告？
redis集群的扩容机制
08-20
Redis集群的扩容机制是通过添加新的节点来实现的。扩容可以分为两个步骤：添加新节点和数据迁移。 首先，您需要在现有的Redis集群中添加一个或多个新的节点。可以使用`redis-trib.rb`或Redis Cluster的命令行工具来...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值