云计算、AI、云原生、大数据等一站式技术学习平台

网站首页 > 教程文章 正文

OpenStack 计算节点 ARP表 溢出导致批量宕机案例分析

jxf315 2025-01-18 20:57:49 教程文章 55 ℃


一、问题现象

1. 故障表现

时间:2025年1月X日 03:15 AM
影响范围:10台OpenStack计算节点近乎同时宕机
故障持续:约30分钟
业务影响:
- 约300+虚拟机实例离线
- 多个业务系统访问中断
- 云平台管理面板报警

疑似原因:
	当网络设备需要通信时,Neighbour表负责存储IP地址和MAC地址的对应关系,它引用了ARP缓存的内容。当Neighbour表发生溢出时,意味着ARP表已达到容量上限,此时系统将拒绝新的网络连接请求,从而导致网络连接异常。云平台的监控系统检测到这种网络连通异常后,会通过IPMI带外管理接口向服务器发送强制下电关机命令,以保护系统。
	
完整的故障链路:
Neighbour表溢出 → 网络连接异常 → 触发保护机制 → IPMI强制关机

建议调优:
	系统需要调整内核参数以解决ARP缓存溢出问题。虽然IPv4的ARP缓存条目数已经完成调优,但由于主机主要使用IPv6地址通信,而IPv6的ARP缓存条目数仍然使用默认值,因此需要在/etc/sysctl.conf文件中添加IPv6的ARP缓存条目数配置项进行优化。

vi /etc/sysctl.conf
添加三项内核参数设置
net.ipv6.neigh.default.gc_thresh1=8192
net.ipv6.neigh.default.gc_thresh2=32768
net.ipv6.neigh.default.gc_thresh3=65536

保存退出后再执行
sysctl -p  #生效查看

v4/v6参数配置如下:
ARP缓存条目数--内核参数是:
net.ipv4.neigh.default.gc_thresh1=8192
net.ipv4.neigh.default.gc_thresh2=32768
net.ipv4.neigh.default.gc_thresh3=65536

net.ipv6.neigh.default.gc_thresh1=8192
net.ipv6.neigh.default.gc_thresh2=32768
net.ipv6.neigh.default.gc_thresh3=65536

2. 日志记录

1. messages日志:
[XXX.XXX] net_ratelimit: 15863 callbacks suppressed
[XXX.XXX] neighbour: ndisc_cache: neighbor table overflow!

2. dmesg日志:
[XXX.XXX] IPv6: neighbor table overflow!
[XXX.XXX] ndisc_cache: neighbor table overflow

3. OpenStack Nova日志:
ERROR nova.compute.manager [req-xxx] Error during service update


二、环境信息

1. 系统配置

1. 硬件配置:
   - CPU: 2路Intel Xeon Gold 6248R
   - 内存: 512GB
   - 网卡: 4x25Gb Mellanox ConnectX-5

2. 软件环境:
   - OS: CentOS 7.9
   - Kernel: 3.10.0-1160.el7
   - OpenStack: Train版本
   - Neutron: DVR部署模式
   - 虚拟化: KVM/QEMU

3. 网络配置:
   - 管理网: IPv4
   - 业务网: IPv4 + IPv6双栈
   - SDN: OVS + VXLAN

2. 当前参数配置

# IPv4参数(已优化)
net.ipv4.neigh.default.gc_thresh1=8192
net.ipv4.neigh.default.gc_thresh2=32768
net.ipv4.neigh.default.gc_thresh3=65536

# IPv6参数(默认值)
net.ipv6.neigh.default.gc_thresh1=128    # 过低
net.ipv6.neigh.default.gc_thresh2=512    # 过低
net.ipv6.neigh.default.gc_thresh3=1024   # 过低

# 网络相关参数
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1


三、原因分析

1. 直接原因

1. 触发链:
   - IPv6 Neighbour表溢出
   - 新建网络连接被拒绝
   - 网络连通性检测失败
   - IPMI执行强制关机

2. 参数分析:
   - gc_thresh1: 垃圾回收启动阈值
   - gc_thresh2: 垃圾回收积极处理阈值
   - gc_thresh3: 最大允许条目数

3. 数据统计:
   - 每台计算节点平均运行30-35个虚拟机
   - 每个虚拟机占用3-5个ARP表项
   - 总需求量:35 VMs * 5 entries * 2 (IPv4+IPv6) = 350条目

2. 深层原因

1. 架构特点:
   - OpenStack DVR模式需要更多ARP表项
   - 虚拟机频繁迁移导致ARP表快速增长
   - IPv6无状态自动配置(SLAAC)产生额外邻居表项

2. 业务特征:
   - 大量容器化应用
   - 微服务架构导致连接数倍增
   - CI/CD流水线频繁创建销毁实例

3. 运维因素:
   - 未及时调整IPv6参数
   - 监控告警阈值设置不合理
   - 缺乏定期清理机制


四、解决方案

1. 紧急处理

# 1. 修改系统参数
cat >> /etc/sysctl.conf << 'EOF'
# IPv6 ARP缓存优化
net.ipv6.neigh.default.gc_thresh1=8192
net.ipv6.neigh.default.gc_thresh2=32768
net.ipv6.neigh.default.gc_thresh3=65536

# 网络优化
net.core.somaxconn=65535
net.ipv4.tcp_max_syn_backlog=65535
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.default.accept_ra=0
EOF

# 2. 应用配置
sysctl -p

# 3. 清理ARP缓存
ip neigh flush all

2. 监控加强

#!/bin/bash
# /usr/local/bin/neigh_monitor.sh

LOG_DIR="/var/log/neigh_monitor"
mkdir -p $LOG_DIR

monitor_neigh() {
    while true; do
        DATE=$(date '+%Y%m%d_%H%M%S')
        LOG_FILE="$LOG_DIR/neigh_$DATE.log"
        
        echo "=== System Time: $(date) ===" >> $LOG_FILE
        echo "=== IPv6 Neighbour Table ===" >> $LOG_FILE
        ip -6 neigh show >> $LOG_FILE
        echo "Total IPv6 entries: $(ip -6 neigh show | wc -l)" >> $LOG_FILE
        
        echo "=== IPv4 ARP Table ===" >> $LOG_FILE
        ip -4 neigh show >> $LOG_FILE
        echo "Total IPv4 entries: $(ip -4 neigh show | wc -l)" >> $LOG_FILE
        
        echo "=== Memory Usage ===" >> $LOG_FILE
        free -m >> $LOG_FILE
        
        echo "=== Network Connections ===" >> $LOG_FILE
        ss -s >> $LOG_FILE
        
        sleep 300
    done
}

monitor_neigh &

3. 长期优化

1. 网络架构优化:
   - 实施网络分段
   - 引入负载均衡
   - 优化路由策略
   - 部署SDN控制器

2. 系统优化:
   - 升级内核版本
   - 优化TCP/IP栈
   - 调整网络缓冲区
   - 实施QoS策略

3. OpenStack优化:
   - 优化Nova配置
   - 调整Neutron参数
   - 实施虚拟机反亲和性
   - 控制单节点虚拟机密度


五、预防措施

1. 监控告警

#!/bin/bash
# /usr/local/bin/neigh_alert.sh

THRESHOLD_IPV4=50000
THRESHOLD_IPV6=50000
ALERT_EMAIL="cloud-admin@example.com"
ALERT_PHONE="13800138000"

check_neigh_table() {
    IPV4_SIZE=$(ip -4 neigh show | wc -l)
    IPV6_SIZE=$(ip -6 neigh show | wc -l)
    
    if [ $IPV4_SIZE -gt $THRESHOLD_IPV4 ] || [ $IPV6_SIZE -gt $THRESHOLD_IPV6 ]; then
        MESSAGE="WARNING: Neighbour table near capacity\n"
        MESSAGE+="IPv4 Size: $IPV4_SIZE\n"
        MESSAGE+="IPv6 Size: $IPV6_SIZE\n"
        MESSAGE+="Threshold: $THRESHOLD_IPV4"
        
        echo -e $MESSAGE | mail -s "Neighbour Table Alert" $ALERT_EMAIL
        # 调用短信告警接口
        curl -X POST "http://sms-api/send" \
             -d "phone=$ALERT_PHONE&message=$MESSAGE"
    fi
}

# 每5分钟执行一次
while true; do
    check_neigh_table
    sleep 300
done

2. 自动化运维

# 1. 定期清理脚本
cat > /usr/local/bin/clean_neigh.sh << 'EOF'
#!/bin/bash
# 每天凌晨3点执行清理
ip neigh flush all
ip -6 neigh flush all
EOF

# 2. 添加到crontab
echo "0 3 * * * /usr/local/bin/clean_neigh.sh" >> /etc/crontab

# 3. 自动备份配置
echo "0 0 * * * tar -czf /backup/sysctl-$(date +\%Y\%m\%d).tar.gz /etc/sysctl.conf" >> /etc/crontab


六、经验总结

1. 技术层面

1. 参数调优:
   - 系统参数需要根据实际负载调整
   - IPv6配置不能照搬IPv4参数
   - 需要考虑业务增长预留空间

2. 架构设计:
   - 合理规划网络架构
   - 实施多层次监控
   - 建立完善的备份机制

2. 运维层面

1. 定期评估:
   - 系统容量评估
   - 性能基线更新
   - 参数配置审计

2. 团队建设:
   - 加强技术培训
   - 进行故障演练
   - 建立值班制度
最近发表
标签列表