建站
咨詢
售后
建站咨詢
新聞中心
引言
Zookeeper集群部分節(jié)點連接數(shù)量瞬時跌零，導致不少服務發(fā)生重連，對業(yè)務造成了影響(驚嚇)，本文就發(fā)生的現(xiàn)象進行分析和整理。
創(chuàng)新互聯(lián)是一家專注于成都網(wǎng)站設計、成都網(wǎng)站建設與策劃設計,麥蓋提網(wǎng)站建設哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設十多年,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:麥蓋提等地區(qū)。麥蓋提做網(wǎng)站價格咨詢:028-86922220
創(chuàng)新互聯(lián)是由多位在大型網(wǎng)絡公司、廣告設計公司的優(yōu)秀設計人員和策劃人員組成的一個具有豐富經(jīng)驗的團隊，其中包括網(wǎng)站策劃、網(wǎng)頁美工、網(wǎng)站程序員、網(wǎng)頁設計師、平面廣告設計師、網(wǎng)絡營銷人員及形象策劃。承接：網(wǎng)站設計、成都網(wǎng)站設計、網(wǎng)站改版、網(wǎng)頁設計制作、網(wǎng)站建設與維護、網(wǎng)絡推廣、數(shù)據(jù)庫開發(fā),以高性價比制作企業(yè)網(wǎng)站、行業(yè)門戶平臺等全方位的服務。
一、ZK監(jiān)控情況
zk集群部分節(jié)點服務發(fā)生重連
伴隨著集群CPU也發(fā)生抖動
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節(jié)點不穩(wěn)定，導致服務發(fā)生重新注冊。
二、ZK系統(tǒng)日志
節(jié)點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。
小結： 在問題發(fā)生時間段三個節(jié)點均在「2021-09-26T19:17:50」附近有系統(tǒng)錯誤日志發(fā)生SYN flooding。另外，這三個節(jié)點「2021-09-26T12:54:03」均有SYN flooding錯誤日志，但是未發(fā)現(xiàn)ZK節(jié)點連接斷開情況。那是由于zk抖動客戶端重連觸發(fā)了SYN flooding ? 還是由于先發(fā)生SYN flooding導致客戶端zk的客戶端。
可以確定的是發(fā)送了大量請求到zk節(jié)點，節(jié)點處理不過來了。
三、解決方式
SYN flood維基釋意
- SYN flood或稱SYN洪水、SYN洪泛是一種拒絕服務攻擊，起因于攻擊者發(fā)送一系列的SYN（TCP握手）請求到目標系統(tǒng)。
- SYN flood攻擊目前有兩種方法，不過都與服務端沒收到ACK有關。惡意用戶可以跳過發(fā)送最后的ACK信息；或者在SYN里透過欺騙來源IP地址，這讓服務器送SYN-ACK到假造的IP地址，因此永不可能收到ACK。這兩個案例服務器會花點時間等抄收通知，故一個簡單的網(wǎng)絡壅塞可能是由于沒有ACK造成的。
也就是客戶端發(fā)送大量TCP連接，TCP的等待隊列被塞滿，導致CPU內存等資源不足，無法提供服務。關于TCP三次握手詳見以前文章《HTTP/2協(xié)議之連接前言【原理筆記】》有回顧，文中通過抓報文分析了三次握手過程。
第一步：Client發(fā)送[SYN]報文到Server。Client進入SYN_SENT狀態(tài)，等待Server響應。[SYN]報文序號Seq=x《備注：截圖中Seq=0》
第二步：Server收到后發(fā)送[SYN,ACK]報文給Client，ACK為x+1(備注：截圖中ACK=1); [SYN,ACK]報文序號為y(備注：截圖中Seq=0),Server進入SYN_RECV狀態(tài)
第三步：Client收到后，發(fā)送[ACK]報文到Server，包序號Seq=x+1，ACK=y+1。Server收到后Client/Server進入ESTABLISHED狀態(tài)。
解決方式：
參考下面文章主要對tcp_max_syn_backlog(能接受SYN同步包的最大客戶端數(shù))和somaxconn(服務端所能accept即處理數(shù)據(jù)的最大客戶端數(shù)量)參數(shù)做了調大處理。
- https://access.redhat.com/solutions/30453
小結： 通過調整系統(tǒng)參數(shù)和升級zk集群配置來應對，當前的4C8G配置過低，出現(xiàn)的該系統(tǒng)錯誤日志總體來說是資源處理不過來了。不升級可能在未來某個時間對公司所有服務造成不可計量和不可承受的損失，在相對低峰期升級，同樣會對全部服務影響，但是可控可應急，兩害相權取其輕。
四、ZK參數(shù)優(yōu)化
ZK配置調整
- # ZK中的一個時間單元
- tickTime=2000
- # 默認10，F(xiàn)ollower在啟動過程中，會從Leader同步所有最新數(shù)據(jù)，將時間調大些
- initLimit=30000
- # 默認5，Leader與flower的心跳檢測，超過后flower表示下線，略微調大一些
- syncLimit=10
- # 默認60，單客戶端IP級別與單zk節(jié)點的連接數(shù)限制，調整為2000
- maxClientCnxns=2000
- # 最大的會話超時時間，其實交給客戶端了
- # 默認的Session超時時間是在2 * tickTime ~ 20 * tickTime這個范圍
- maxSessionTimeout=60000000
- # 兩次事務快照之間可執(zhí)行事務的次數(shù)，默認的配置值為100000
- snapCount=3000000
- # 日志文件大小kb，切換快照生成日志
- preAllocSize=131072
- # 自動清理snapshot和事務日志，清理頻率，單位是小時
- autopurge.purgeInterval=6
- # 保留的文件數(shù)目，默認3個
- autopurge.snapRetainCount=10
- # 存儲快照文件snapshot的目錄
- dataDir=/data/zookeeper
- # 事務日志輸出目錄
- 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調整為滾動輸出
- 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
系統(tǒng)參數(shù)調整
limits.conf 設置用戶能打開的最大文件數(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調整
- vim /etc/sysctl.conf
- # 表示開啟SYN Cookies。當出現(xiàn)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
- # 修改系統(tǒng)默認的 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
本文轉載自微信公眾號「瓜農(nóng)老梁」，可以通過以下二維碼關注。轉載本文請聯(lián)系瓜農(nóng)老梁公眾號。
網(wǎng)頁題目：ZKSYNFlood與參數(shù)優(yōu)化
標題來源：http://fisionsoft.com.cn/article/djisooo.html
