线上服务器故障报告
- 故障描述
?近期，多個地市州的酒店用戶頻繁出現錯誤代碼：10071故障
故障一：故障發生時間為早上6點至10點之間。
故障二：個別酒店在晚上（用戶高峰期）會出現故障，服務時而正常，時而異常
- 故障原因
經排查（網絡部路由跟蹤，定位），故障原因基本定位在是由于酒店EPG服務器主備倒換后向上級網絡設備上報新MAC地址與ip不匹配造成。經進一步的分析觀察，發現歡旅服務器主備nginx早上6點到10點時間vip發生隨機飄移現象，由于linux內核網絡連接跟蹤參數nf_conntrack設置不合理，線上設置參數為：
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_max = 65536
由于早高峰，用戶并發過多導致網絡連接數持續增加，超過最大網絡跟蹤數，導致 IP 包被丟掉，連接無法建立。
VIP：192.168.xx.9x
Nginx主機：192.168.xx.60
Nginx備機：192.168.xx.61
- 解決思路
查看業務服務器服務是否正常，正常的情況下，查看/var/log/messages日志，具體定位vip發生飄移情況。
同時查看nginx網絡情況，netstat -s grep |reject
- 故障分析過程
?
?????2021年07月20日60日志：
2021年07月26日60日志：
2021年07月28日61日志：
通過日志在6點07分發生大量請求，導致網絡連接跟蹤數陡增，超越最大值，發現VIP漂移發生飄移過程中，keeplived運行在搶占模式下VIP頻繁切換，上圖中可見，導致ARP沒有及時廣播給網關，即MAC地址和IP地址匹配錯誤。
VIP漂移的原因是連接跟蹤模塊Netfilter connection tracking（nf_conntrack）模塊參數設置偏小，即：net.netfilter.nf_conntrack_max = 65536
查看方法：cat /proc/sys/net/netfilter/nf_conntrack_max
早高峰導致跟蹤鏈接數超過了65536，
查看方法：cat /proc/sys/net/netfilter/nf_conntrack_count
同時，查看nginx網絡情況，netstat -s grep |reject
?
發現出現了大量丟包。并且通過抓包發現，有部分請求拒絕了鏈接：
?發現tcp鏈接直接失敗，客戶端連接服務器連接建立失敗。
vip： 172.16.15.58
主：172.16.15.57
備：172.16.0.75
通過修改linux的內核參數：net.netfilter.nf_conntrack_max = 16384
?模擬并發3000,一共50W次請求：
ab -c 3000 -n 500000 http://172.16.15.58/index.html
通過觀察系統日志，發現與線上早高峰故障相同，如下所示：
?
6日凌晨在生產環境下進行壓力測試
ab -n 100000 ?-c 5000 http://110.190.92.10x:10080/iptv-interface/apk/queryIndex?stbId=hl1
?
?
?
- 分析結果
Linux內核參數nf_conntrack 跟蹤所有網絡連接，記錄存儲在 1 個哈希表里。首先根據五元組算出哈希值，分配一個桶，如果有沖突就在鏈表上遍歷，直到找到一個精確匹配的。如果沒有匹配的則新建。
即使來自客戶端的訪問量過高會塞滿哈希表。
連接記錄會在哈希表里保留一段時間，根據協議和狀態有所不同，直到超時都沒有收發包就會清除記錄。如果服務器比較繁忙，新連接進來的速度遠高于釋放的速度，把哈希表塞滿了，新連接的數據包就會被丟掉。從而出現生產環境錯誤日志：Jan? 5 06:07:00 IPTV-HOTEL-WEB2 kernel: nf_conntrack: table full, dropping packet.
通過tcp抓包分析，發現大量丟包，同事查看tcp連接數也比較高，所以查詢資料發現和兩階段等待時間有關系，需要調整內核參數：
???sysctl?-w?net.ipv4.tcp_tw_recycle=0
sysctl?-w?net.ipv4.tcp_timestamps=1
因為服務器同時開啟了tcp_tw_recycle和timestamps，而客戶端正是使用NAT來訪問服務器，造成啟動時間相對較短的客戶端得不到服務器的正常響應。如果服務器作為服務端提供服務，且明確客戶端會通過NAT網絡訪問，或服務器之前有7層轉發設備會替換客戶端源IP時，是不應該開啟tcp_tw_recycle的，而timestamps除了支持tcp_tw_recycle外還被其他機制依賴，推薦繼續開啟。
- 解決方案
為了防止vip不正常的浮動，將linux內核參數進行優化，優化項主要為:
經過生產環境下的服務器內存為8G，按照linux的通用設置規則:CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)
現有服務器參數設置為:對于生產環境下服務配置為 8G 內存的機器：(8 * 1024^3) / 16384 / (64 / 32) = 262144
sysctl net.netfilter.nf_conntrack_tcp_timeout_established=6000
#編輯文件vim /etc/sysctl.conf
，加入以下內容：
net.ipv4.tcp_fin_timeout = 30
#然后執行 /sbin/sysctl -p 讓參數生效
最終linux網絡連接追蹤參數優化為:
net.netfilter.nf_conntrack_buckets = 131072
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 6000
當VIP漂移或者服務故障的時候，通過郵件(短信)發送告警，從而在第一時間對故障進行處理。
????sysctl?-w?net.ipv4.tcp_tw_recycle=0
sysctl?-w?net.ipv4.tcp_timestamps=1
【引用別人博客】在一條正常的TCP流中，按序接收到的所有TCP數據包中的timestamp都應該是單調非遞減的，這樣就能判斷那些timestamp小于當前TCP流已處理的最大timestamp值的報文是延遲到達的重復報文，可以予以丟棄
TIME_WAIT狀態是TCP四次揮手中主動關閉連接的一方需要進入的最后一個狀態，并且通常需要在該狀態保持2*MSL（報文最大生存時間），它存在的意義有兩個：
1.可靠地實現TCP全雙工連接的關閉：關閉連接的四次揮手過程中，最終的ACK由主動關閉連接的一方（稱為A）發出，如果這個ACK丟失，對端（稱為B）將重發FIN，如果A不維持連接的TIME_WAIT狀態，而是直接進入CLOSED，則無法重傳ACK，B端的連接因此不能及時可靠釋放。
2.等待“迷路”的重復數據包在網絡中因生存時間到期消失：通信雙方A與B，A的數據包因“迷路”沒有及時到達B，A會重發數據包，當A與B完成傳輸并斷開連接后，如果A不維持TIME_WAIT狀態2*MSL時間，便有可能與B再次建立相同源端口和目的端口的“新連接”，而前一次連接中“迷路”的報文有可能在這時到達，并被B接收處理，造成異常，維持2*MSL的目的就是等待前一次連接的數據包在網絡中消失。
TIME_WAIT狀態的連接需要占用服務器內存資源維持，Linux內核提供了一個參數來控制TIME_WAIT狀態的快速回收：tcp_tw_recycle，它的理論依據是：
在PAWS的理論基礎上，如果內核保存Per-Host的最近接收時間戳，接收數據包時進行時間戳比對，就能避免TIME_WAIT意圖解決的第二個問題：前一個連接的數據包在新連接中被當做有效數據包處理的情況。這樣就沒有必要維持TIME_WAIT狀態2*MSL的時間來等待數據包消失，僅需要等待足夠的RTO（超時重傳），解決ACK丟失需要重傳的情況，來達到快速回收TIME_WAIT狀態連接的目的。
在多個客戶端使用NAT訪問服務器時會產生新的問題：同一個NAT背后的多個客戶端時間戳是很難保持一致的（timestamp機制使用的是系統啟動相對時間），對于服務器來說，兩臺客戶端主機各自建立的TCP連接表現為同一個對端IP的兩個連接，按照Per-Host記錄的最近接收時間戳會更新為兩臺客戶端主機中時間戳較大的那個，而時間戳相對較小的客戶端發出的所有數據包對服務器來說都是這臺主機已過期的重復數據，因此會直接丟棄。
當vip浮動情況仍未得到改善后，先考錄PlanB,實施單機策略，最終考慮實施planC，將現有的軟負載替換為F5硬負載，從而從本源解決VIP發生浮動時，不能準確向上級網絡設備上報對應的MAC地址。
PlanA：持續觀察雙機狀況
PlanB：單機運行，去掉備機
PlanC: 硬負載實施
參考一下博文：
https://blog.csdn.net/weixin_34221332/article/details/86081600?utm_medium=distribute.wap_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-4.withoutpaiwithsearchfrombaidu_wap&depth_1-utm_source=distribute.wap_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-4.withoutpaiwithsearchfrombaidu_wap
https://blog.csdn.net/weixin_34221332/article/details/86081600?utm_medium=distribute.wap_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-4.withoutpaiwithsearchfrombaidu_wap&depth_1-utm_source=distribute.wap_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-4.withoutpaiwithsearchfrombaidu_wap
https://blog.csdn.net/majianting/article/details/96476375
https://blog.csdn.net/majianting/article/details/96476375
總結
