1. 程式人生 > >企業運維故障案例

企業運維故障案例

運維故障案例

NGINX

可以作為反向代理服務器,還可以按照調度規則實現動靜分離,可以按照輪詢、ip_hash、URL——hash、權重等多種方式對後端服務器做負載均衡,還支持後端服務器的健康檢查。

用upstream均衡,均衡的時候有很多算法

upstream yinxingyouyou_web {

ip_hash

server 192.168.1.100 weight=1 max_fails=2 fail_timeout=10s;

server 192.168.1.101 weight=1 max_fails=2 fail_timeout=10s;

}

ip_hash是保持會話登錄不變,但是不能保證平均均衡,而這個會話是保存在redis裏的,加在數據庫前面的一層緩存

nginx+tomcat+redis+mysql-AB tomcat連redis,redis連tomcat有驅動,開發會寫好

·upstream的 fail_timeout和max_fails,用來判斷負載均衡upstream中的某個server是否失效。在fail_timeout的時間內,nignx與upstream中某個server的連接嘗試失敗了max_fails次,則nginx會認為該server已經失效。在接下來的 fail_timeout時間內(不宜太短,網絡有延遲),nginx不再將請求分發給失效的server。

·如果max_fails=0,即關閉後端服務器健康檢查,如果權重一樣,那麽每次請求都會有機會發到後端不可用的服務器。

·proxy_connect_timeout nginx與後端連接的超時時間,單位為秒,默認為60秒。我們在nginx錯誤日誌裏面看到的(110: Connection timed out),就是指nginx與後端連接已經超時。報502錯誤。

·proxy_read_timeout 建立連接後,nginx等候讀取後端服務器響應的時間,默認為60秒。在一些比較繁忙的後端,比如線程數經常達到峰值了的tomcat,這個值註意不要設得太低,雖然線程數已經用光,但請求已經進入待隊列之中。

·proxy_send_timeout nginx轉發請求到後端的超時時間,默認為60秒,在這段時間內nginx沒將請求數據發到後端將關閉連接。這個在網站有比較多像提交表單(post)上傳內容之類的需要留意一下.


·keepalive_timout 時間值意味著:一個http產生的tcp連接在傳送完最後一個響應後,還需要等待keepalive_timeout秒後,才開始關閉這個連接。就是會話保持。


·關閉atimevim /etc/fstab裏

在根後面的defaults,後面加noatime,再後面1 1,是開始的時候檢查磁盤,寫成0就是不質檢磁盤

關閉系統日誌,系統日誌warm,debug,info,error,2萬臺機器,ELK日誌搜集平臺

企業運維故障案例