[[426460]]

引言

Zookeeper集群部分節(jié)點(diǎn)連接數(shù)量瞬時跌零，導(dǎo)致不少服務(wù)發(fā)生重連，對業(yè)務(wù)造成了影響(驚嚇)，本文就發(fā)生的現(xiàn)象進(jìn)行分析和整理。

一、ZK監(jiān)控情況

zk集群部分節(jié)點(diǎn)服務(wù)發(fā)生重連

伴隨著集群CPU也發(fā)生抖動

ZK日志主要為Socket關(guān)閉等

[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) 

小結(jié)： zk節(jié)點(diǎn)不穩(wěn)定，導(dǎo)致服務(wù)發(fā)生重新注冊。

二、ZK系統(tǒng)日志

節(jié)點(diǎn)x.x.x.15 系統(tǒng)日志在「2021-09-26T19:16:50」「2021-09-26T19:17:50」均發(fā)生SYN flooding。

x.x.x.89 系統(tǒng)日志在「2021-09-26T19:16:50」和 「2021-09-26T19:17:50」均發(fā)生SYN flooding。

x.x.x.45 系統(tǒng)日志如下「2021-09-26T19:17:50」發(fā)生SYN flooding。

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

可以確定的是發(fā)送了大量請求到zk節(jié)點(diǎn)，節(jié)點(diǎn)處理不過來了。

三、解決方式

SYN flood維基釋意

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

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

第一步：Client發(fā)送[SYN]報文到Server。Client進(jìn)入SYN_SENT狀態(tài)，等待Server響應(yīng)。[SYN]報文序號Seq=x《備注：截圖中Seq=0》

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

第三步：Client收到后，發(fā)送[ACK]報文到Server，包序號Seq=x+1，ACK=y+1。Server收到后Client/Server進(jìn)入ESTABLISHED狀態(tài)。

解決方式：

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

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

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

四、ZK參數(shù)優(yōu)化

ZK配置調(diào)整

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

Jvm參數(shù)

在zookeeper/conf創(chuàng)建java.env文件

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

日志滾動

conf/log4j.properties調(diào)整為滾動輸出

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調(diào)整日志輸出方式

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 

系統(tǒng)參數(shù)調(diào)整

limits.conf 設(shè)置用戶能打開的最大文件數(shù)

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

/etc/sysctl.conf調(diào)整

vim /etc/sysctl.conf 
 
# 表示開啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認(rèn)為0，表示關(guān)閉； 
net.ipv4.tcp_syncookies = 1 
 
# 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；為1，開啟     
net.ipv4.tcp_tw_reuse = 1 
 
# 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉；為1，開啟；     
net.ipv4.tcp_tw_recycle = 1   
  
# 修改系統(tǒng)默認(rèn)的 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     

本文轉(zhuǎn)載自微信公眾號「瓜農(nóng)老梁」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系瓜農(nóng)老梁公眾號。