[[426460]]

引言

Zookeeper集群部分節點連接數量瞬時跌零，導致不少服務發生重連，對業務造成了影響(驚嚇)，本文就發生的現象進行分析和整理。

一、ZK監控情況

zk集群部分節點服務發生重連

伴隨著集群CPU也發生抖動

ZK日志主要為Socket關閉等

[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2182:NIOServerCnxn@368] - caught end of stream exception 
ndOfStreamException: Unable to read additional data from client sessionid 0x0, likely client has closed socket 
at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:239) 
at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:203) 
at java.lang.Thread.run(Thread.java:745) 

小結： zk節點不穩定，導致服務發生重新注冊。

二、ZK系統日志

節點x.x.x.15 系統日志在「2021-09-26T19:16:50」「2021-09-26T19:17:50」均發生SYN flooding。

x.x.x.89 系統日志在「2021-09-26T19:16:50」和 「2021-09-26T19:17:50」均發生SYN flooding。

x.x.x.45 系統日志如下「2021-09-26T19:17:50」發生SYN flooding。

小結： 在問題發生時間段三個節點均在「2021-09-26T19:17:50」附近有系統錯誤日志發生SYN flooding。另外，這三個節點「2021-09-26T12:54:03」均有SYN flooding錯誤日志，但是未發現ZK節點連接斷開情況。那是由于zk抖動客戶端重連觸發了SYN flooding ? 還是由于先發生SYN flooding導致客戶端zk的客戶端。

可以確定的是發送了大量請求到zk節點，節點處理不過來了。

三、解決方式

SYN flood維基釋意

SYN flood或稱SYN洪水、SYN洪泛是一種拒絕服務攻擊，起因于攻擊者發送一系列的SYN（TCP握手）請求到目標系統。 
SYN flood攻擊目前有兩種方法，不過都與服務端沒收到ACK有關。惡意用戶可以跳過發送最后的ACK信息；或者在SYN里透過欺騙來源IP地址，這讓服務器送SYN-ACK到假造的IP地址，因此永不可能收到ACK。這兩個案例服務器會花點時間等抄收通知，故一個簡單的網絡壅塞可能是由于沒有ACK造成的。 

也就是客戶端發送大量TCP連接，TCP的等待隊列被塞滿，導致CPU內存等資源不足，無法提供服務。關于TCP三次握手詳見以前文章《HTTP/2協議之連接前言【原理筆記】》有回顧，文中通過抓報文分析了三次握手過程。

第一步：Client發送[SYN]報文到Server。Client進入SYN_SENT狀態，等待Server響應。[SYN]報文序號Seq=x《備注：截圖中Seq=0》

第二步：Server收到后發送[SYN,ACK]報文給Client，ACK為x+1(備注：截圖中ACK=1); [SYN,ACK]報文序號為y(備注：截圖中Seq=0),Server進入SYN_RECV狀態

第三步：Client收到后，發送[ACK]報文到Server，包序號Seq=x+1，ACK=y+1。Server收到后Client/Server進入ESTABLISHED狀態。

解決方式：

參考下面文章主要對tcp_max_syn_backlog(能接受SYN同步包的最大客戶端數)和somaxconn(服務端所能accept即處理數據的最大客戶端數量)參數做了調大處理。

https://access.redhat.com/solutions/30453 

小結： 通過調整系統參數和升級zk集群配置來應對，當前的4C8G配置過低，出現的該系統錯誤日志總體來說是資源處理不過來了。不升級可能在未來某個時間對公司所有服務造成不可計量和不可承受的損失，在相對低峰期升級，同樣會對全部服務影響，但是可控可應急，兩害相權取其輕。

四、ZK參數優化

ZK配置調整

# ZK中的一個時間單元 
tickTime=2000 
  
# 默認10，Follower在啟動過程中，會從Leader同步所有最新數據，將時間調大些 
initLimit=30000 
 
# 默認5，Leader與flower的心跳檢測，超過后flower表示下線，略微調大一些    
syncLimit=10 
 
# 默認60，單客戶端IP級別與單zk節點的連接數限制，調整為2000     
maxClientCnxns=2000 
 
# 最大的會話超時時間，其實交給客戶端了 
# 默認的Session超時時間是在2 * tickTime ~ 20 * tickTime這個范圍     
maxSessionTimeout=60000000     
     
# 兩次事務快照之間可執行事務的次數，默認的配置值為100000 
snapCount=3000000 
 
# 日志文件大小kb，切換快照生成日志 
preAllocSize=131072     
 
# 自動清理snapshot和事務日志，清理頻率，單位是小時     
autopurge.purgeInterval=6   
 
# 保留的文件數目，默認3個     
autopurge.snapRetainCount=10 
 
# 存儲快照文件snapshot的目錄     
dataDir=/data/zookeeper 
 
# 事務日志輸出目錄 
dataLogDir=/data/zookeeper/log     

Jvm參數

在zookeeper/conf創建java.env文件

export JVMFLAGS="-Xms10G -Xmx10G -Xmn4G -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/zkout/gc/gc-%t.log $JVMFLAGS" 

日志滾動

conf/log4j.properties調整為滾動輸出

zookeeper.root.logger=INFO, ROLLINGFIL 
 
zookeeper.log.dir=/data/zkout/logs 
 
log4j.appender.ROLLINGFILE=org.apache.log4j.DailyRollingFileAppender 
#log4j.appender.ROLLINGFILE.Threshold=${zookeeper.log.threshold} 
#log4j.appender.ROLLINGFILE.File=${zookeeper.log.dir}/${zookeeper.log.file} 
log4j.appender.ROLLINGFILE.DatePattern='.'yyyy-MM-dd 
 
log4j.appender.ROLLINGFILE.MaxFileSize=100MB 

zkEnv.sh調整日志輸出方式

if [ "x${ZOO_LOG_DIR}" = "x" ] 
then 
    ZOO_LOG_DIR="/data/zkout/logs/" 
fi 
 
if [ "x${ZOO_LOG4J_PROP}" = "x" ] 
     
then 
    # ZOO_LOG4J_PROP="INFO,CONSOLE" 
    ZOO_LOG4J_PROP="INFO,ROLLINGFILE" 
fi 

系統參數調整

limits.conf 設置用戶能打開的最大文件數

vim /etc/security/limits.conf 
# End of file 
root soft nofile 655360  #根據部署用戶 
root hard nofile 655360 
* soft nofile 655360 
* hard nofile 655360 

/etc/sysctl.conf調整

vim /etc/sysctl.conf 
 
# 表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉； 
net.ipv4.tcp_syncookies = 1 
 
# 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉；為1，開啟     
net.ipv4.tcp_tw_reuse = 1 
 
# 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉；為1，開啟；     
net.ipv4.tcp_tw_recycle = 1   
  
# 修改系統默認的 TIMEOUT 時間     
net.ipv4.tcp_fin_timeout = 5     
 
# the kernel's socket backlog limit     
net.core.somaxconn = 65535 
 
# the application's socket listen backlog     
net.ipv4.tcp_max_syn_backlog = 100000 
  
sysctl -p     

本文轉載自微信公眾號「瓜農老梁」，可以通過以下二維碼關注。轉載本文請聯系瓜農老梁公眾號。