nginx反向代理配置+lnmp优化+七层负载upstream+keepalived
反代服務器取得內容緩存到本地,然后加速返回給客戶端。
緩存命中率高 可以極大的緩解后端服務器壓力。影響nginx
一般nginx作為負載均衡器,不會讓nginx反向代理去緩存。而是讓緩存服務器去緩存。
1.web服務
2.反代
3.偽四層
nat只負責轉發過去
但是代理是轉述 需要修飾的
nginx既要當成服務端接受用戶請求
也要當成客戶端去訪問互聯網
可以理解用戶請求的具體信息
并且可以緩存到本地
代理需要監聽在套接字上,并且理解這個協議。
代理就是雙面人
后端真實主機
nginx代理服務器
這個作為反向代理服務器
自己配置一個虛擬主機
自己不是web服務器 所以不需要root
直接反代到后端主機
直接反代即可
注意:如果后端代理有多個虛擬主機
proxy_pass就基于ip+端口+或者主機名
如果直接訪問Ip就是代理服務器本身的
本機的包是從代理服務器發送過來的
在啟動一個新的后端服務器
默認發布頁面
這個緩存圖片
希望圖片到第二臺服務器
網關聯系不到后端服務器
可能是沒有啟動
有了這個功能 動靜分離就沒問題了
不加/意思是只要訪問/下的比如/index.html就補充到80后面192.16.10.11/index.html
表示只是把/admin/和圖片代理了
后端主機添加目錄/admin/
就是把整個路徑傳到后面去了
添加/
以為訪問/admin/的時候會替換為后端主機/下的內容
這種加不加沒有區別
正則無法替換
如果在80后面加/就會nginx -t語法錯誤
一般用戶訪問后端知識服務器 代理服務器構建后發給后端服務器 后端真實服務器不知道是客戶是誰
所以代理服務器可以修改報文首部 就是發往后端服務端的首部的值 添加客戶首部IP
或者響應報文發給客戶端的首部
后端抓包看包的首部信息
該日志格式
本來時%h也就是代理服務器的IP值
現在更換為上面定義的變量 就是客戶端的IP
可以看到真正的客戶端IP
ngx_http_headers_module模塊
還可以更改代理服務器響應給客戶端的時候
送給客戶端的
代理還可以啟動緩存進行加速哦~~
這個是代理服務器發送客戶端報文允許哪些首部是可以發送過去的
代理還可以啟動緩存進行加速哦~~
到后端取回來后放在本地磁盤
直接兩個網絡IO變成了一個磁盤IO
緩存還是文件路由哈希格式 更快 從右而左截取路由編碼
找文件首先哈希 然后找很快 在內存哈希表
而后端真實的服務器還是遍歷根目錄
緩存空間需要先定義 哪個路徑proxy_pass需要緩存 直接調用即可
只有get,head才需要緩存中查看 Post,put,delete不需要
shift+F5強刷 不讀取緩存
服務器端也可以發送報文說不需要緩存
緩存空間有限
后端服務器宕機 緩存不新鮮了
nginx不是高檔的 只有varnish才可以緩存的很得體 高效的緩存機制
nginx varnish裝載同一臺主機 解決網絡IO延遲
nginx啟動緩存功能
3、proxy_cache_path定義可用于proxy功能的緩存;Context: http proxy_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];4、proxy_cache zone | off;指明要調用的緩存,或關閉緩存機制;Context: http, server, location5、 proxy_cache_key string;緩存中用于“鍵”的內容;默認值:proxy_cache_key $scheme$proxy_host$request_uri;6、proxy_cache_valid [code ...] time;定義對特定響應碼的響應內容的緩存時長;定義在http{...}中;proxy_cache_path /var/cache/nginx/proxy_cache levels=1:1:1 keys_zone=pxycache:20m max_size=1g;定義在需要調用緩存功能的配置段,例如server{...};proxy_cache pxycache;proxy_cache_key $request_uri;proxy_cache_valid 200 302 301 1h;proxy_cache_valid any 1m;
放在http中 在默認配置中寫
定義緩存路徑(磁盤空間) levels頂級子目錄級別 設置三級 每級16個 keys_zone內存分配多大空間 size 10M
max_size磁盤空間最多2g 其他默認
按需創建
調用緩存
調用緩存名字
定義緩存內容類型
以及定義緩存參數
proxy_cache_key定義緩存的Key 有默認的值
對那種方法調用緩存
最少時間緩存項訪問次數
use_stale 對于后端服務器處于什么問題下緩存哪些內容什么情況下還可以使用
網頁訪問主頁
這就是文件路由
可以看到相應信息
nginx也需要處理動態服務請求
nginx無法內建php模塊
處理動態的頁面只有fpm-server
找一臺主機運行fpm nginx反代給后端 基于fastcgi_module反代給后端fastcgi模塊 作為客戶端
而fast_proxy_pass則是作為http客戶端
所以構建lnmp
所以這就是三級結構
本地 只要不是.php結尾
.php就是用fastcg協議i反代給后端 fpm-server
加載完畢運行結果響應給前端主機
需要基于驅動訪問數據 基于mysql協議去訪問Mysql server
lnmp
fcgi server 需要接受請求還要處理并發 還要運行壓力很大
所以不如使用AP 代替 aapche工作模式 event preforx worker
但是Mysql讀取數據很慢
也可以給數據庫緩存 memcache 專門的緩存服務器 內存級別
基于內存緩存 支持的數據結構太簡單 所以被redis碾壓 還支持數據存儲
還可以搞個動靜分離 靜態的專門去處理靜態的頁面
搭建lnmp
一臺主機nginx 處理靜態內容
php內容發送給fpm-server
一臺主機安裝apahce + php
php-fpm server + mysql
但是phpMY 有靜態有動態 所以放在動態的主機也不容易配置
配置fpm-server
不然別的主機連接不進來了
允許所有連接
定義進程數
健康狀態檢測也啟動
因為進程屬組是apache
php需要文件保存會話 用戶信息等
所以該文件用戶也應該是apache
n1主機設置作為前端nginx
前面已經設置了很多
為了避免沖突
新建一個
index設置主頁
需要fastcgi_module作為客戶端進行反代
前面說到作為代理服務器 代理服務器會隱藏很多客戶端信息
但是[php服務器需要用戶信息 生成對應的內容
所以有一文件用來可以展示給php的客戶端信息
定義把什么參數傳輸給后端主機
腳本名稱
當客戶端請求一個腳本時候需要把腳本名稱傳遞到后端
但是用戶訪問的腳本名字 fastcgi如何獲取到該腳本呢 ?
所以需要有絕對路徑 但是一般不在這個 文件中修改
分別是fastcgi自己的主頁
腳本名稱對應再fastcgi服務器下的腳本所在位置
Include表示其他的變量從xx文件獲取
第一個location就是靜態內容
第二個location就是動態內容 表示.php都轉發
fpm主機p
獻給nginx配置靜態頁面
通過php連接mysql
php主機
vim /etc/my.cnf.d/server.cnf
隨機數
不是.php結尾
所以訪問index.php 就是主頁 但是沒有圖片 因為是靜態內容
所以拷貝到nginx主機上
同樣放到默認的根頁面下
所以正常 這也就意味著資源包括靜態和動態的話都需要一份
因為動靜分離了 數據庫用戶root 密碼就是安全設置設置的那個
繼續優化 nginx不處理靜態內容 全部proxy_pass給一個專門處理靜態頁面的服務器
繼續添加主機
更改默認的根
報錯了 查看進程發現httpd服務啟動著
前端主機配置
可以看到請求了各種各樣的圖片文件
當然了fastcgi還可以啟動緩存優化
指定路徑下 幾級優化
客戶端壓測一下 隨便找一個另外的主機 172.16.0.67
壓測非常慢非常慢
因為是動態頁面
所以嘗試fastcgi的緩存功能
在http上下文添加
需要進行調用
先curl生成緩存
查看還是沒有緩存生成內容
可能生成私有信息
先注釋掉緩存
對默認頁面緩存
啟動緩存
速度大大提高
10、fastcgi_keep_conn on | off;
請求的時候保持連接打開
可以發現速度還是提升了
因為http協議和fastcgi協議并不完全兼容,所以很多變量的值向后方傳遞需要重新賦值
都可以實現緩存 1.定義緩存 2.調用緩存
主要就是講解了兩個反代模塊
nginx實現七層負載upstream實戰
nginx工作在strem模塊下就可以負載均衡四層的 其實就是stream下的upstream負載均衡tcp.udp協議請求的
nginx七層是工作在http的upstream模塊 http的upstream負載http請求 上有主機的方式
stream本身是反代 想要負載均衡就需要upsteam
haproxy既可以負載均衡也可以代理
如果后端是兩臺動態服務器
用戶請求分發到另外一臺主機之前的會話也沒有了
所以可以會話粘性:
根據用戶自身瀏覽行為 動態服務器本身可以會話緩存
一旦負載均衡
同一用戶輪詢 之前的會話信息就沒有了
解決
1.會話粘性 lvs: sh算法 或者persistence 基于源地址實現的
2.對應應用層可以基于cookie綁定
但是一臺服務器宕機了,session丟失
3.應該客戶端無狀態請求 會話集群 所有后端主機額外做集群
高性能的存儲專門存儲session 最好是內存級別的(memcache,redis)
連接后端存儲主機實現數據的增刪改查
memcache一旦宕機數據就沒有了
redis可以持久
但是還是單點
nginx是虛擬主機 訪問不同的資源去后端不同的主機 靜態資源去靜態資源服務器 動態資源去動態資源服務器
但是如果后端有2個靜態/動態資源服務器呢???? 可以在nginx的upstream定義為一組服務器
所以反向代理的時候可以指向一組 組自己有自己的挑選算法(類似于lvs)
一個虛擬主機的不同的location對應不同的組
web負載均衡集群
nginx的upstrem模塊自帶健康檢查功能,后端主機故障可以自動摘除~
但是nginx又單點了 所以可以加上keepalibed
server在http中是虛擬主機,在upstream中是后端真實主機
前端主機
先前的配置先備份一下,先配置簡單的
這是虛擬主機
在默認配置頁定義upstream
這就是負載均衡集群
還可以定義權重等等
先輪詢 至少都一邊 然后再加權
意思就是超時1次認為失敗 最多失敗三次就干掉
當兩個服務器都down
設置去訪問默認主頁
兩個都掛了就上
兩臺主機都停止服務
再次開啟服務
還可以偽裝down了實際并沒有 類似于灰度測試下
再次去掉down恢復正常
也支持sh會話粘性
添加ip_hash
下面的backup需要注釋
hash cookie就會把cookie當鍵
haproxy還支持很多種 講haproxy會講
吧來自同一個用戶發往同一個請求
一致性哈希!!
uri一定 適應與反代服務器
用uri的哈希值模2^32次方 范圍就在0~ 2^32-1
同理對服務器ip地址做哈希計算 也取模
順時針找離他近的服務器
當一個服務器宕機了
只影響一小段
但是如果服務器計算哈希離得很近很近
所以虛擬節點解決哈希環偏離
加鹽 一個加五十個鹽 那么3個節點150個點
這個就是自帶虛擬節點的一致性哈希
多生成頁面
分別生成20個頁面
對于同一個uri第一次綁定后面肯定都在一個服務器
前面http服務的負載均衡都在http{}里面寫的 只能用來負載http服務
其余所有四層的代理都應該放在stream模塊中
自己無法處理四層服務 所以server必須都有真實的代理
包括http服務本身也可以在四層調度
舉了例子ssh服務
吧http的都刪除了
監聽ssh服務 首先監聽在22922
監聽用戶發過來的ssh服務
這個時候就是四層反向代理
當然也可以代理web服務
定義負載均衡
web好驗證
輪詢的
只給一個數據庫創建mydb
可以發現也是輪詢的
關閉一個數據庫服務
發現也是有健康檢查功能哦
keepalived
一般需要奇數個 通過選舉選出新的leader
怎么把A干掉
ABC在電源交換機上
這個電源交換機可以通過網絡交換信號
多數的方可以干掉節點
BC選擇誰是Leader 向電源交換機發信號 切斷A的電源 或者閃一下A的電源
讓故障節點不要去訪問資源–FENCE
共享存儲前面添加一個信號 A要是干掉
共享存儲的需要屏蔽A的信號 不讓A去訪問資源
只有一方才可以代表集群工作稱為quorum機制
投票選舉是否大于半數
N個節點 M個服務
每個資源的傾向不同 x資源首先傾向于A。y資源傾向于B
在資源節點定義
A服務出問題優先到C
以上是heartbeat
和keepalived不同
每個內網主機網關都指向虛擬VIP
多個路由器虛擬為一個虛擬路由器,通過VIP向外提供服務
這就是vrrp協議
路由網卡有優先級高低,誰高Vip就在誰身上的
keepalived實現了軟件上就可以支持vrrp協議
vip配置在優先級高的主機上
keepalied進程在用戶空間上,有幾個主機就有幾個keepalived進程。還支持健康檢查
IPVS wrapper生成規則 刪除宕掉的機器
核心組件:vrrp stack 實現vrrp協議的ipvs wrapper 生成ipvs規則的checkers 健康狀態檢測工具控制組件:配置文件分析器IO復用器內存管理組件keepalived監控進程狀態 但是萬一自己的vrrp stack進程和checkers進程都掛了 所以有watchdog 用來監控進程的進程 通常是個硬件設備 在主板上 內核驅動這個設備金控內核級進程真正的通信是mac地址
VIP飄逸了 客戶端緩存的都是已經宕機的mac
所以不會再次發起解析請求 還是發給原來的主機
所以就需要虛擬MAC地址
再次廣播 自己問VIP的MAC地址是什么
免費ARP
其他主機自動更新本地MAC 就是新的路由!!!!
優先級高的如果正常了 是否需要搶回VIP
可以配置不同的虛擬路由支持不同的服務的優先級主機不同
如果又來了一個keepalive說自己是最高優先級
但是不可信的
所以需要認證 組播的
關閉iptabels
關閉firewalld服務
放行多播信息即可
多播功能需要打開
分別是全局配置
VRRP配置
LVS配置
組播地址
默認smtp是開啟的
配置語法:配置虛擬路由器:vrrp_instance <STRING> {....}專用參數:state MASTER|BACKUP:當前節點在此虛擬路由器上的初始狀態;只能有一個是MASTER,余下的都應該為BACKUP;interface IFACE_NAME:綁定為當前虛擬路由器使用的物理接口;virtual_router_id VRID:當前虛擬路由器的惟一標識,范圍是0-255;priority 100:當前主機在此虛擬路徑器中的優先級;范圍1-254;advert_int 1:vrrp通告的時間間隔;authentication {auth_type AH|PASSauth_pass <PASSWORD>}virtual_ipaddress {<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL>192.168.200.17/24 dev eth1192.168.200.18/24 dev eth2 label eth2:1}track_interface {eth0eth1...}配置要監控的網絡接口,一旦接口出現故障,則轉為FAULT狀態;nopreempt:定義工作模式為非搶占模式;preempt_delay 300:搶占式模式下,節點上線后觸發新選舉操作的延遲時長;VIP 配置綁定在哪個接口上interface
同一個虛擬路由器的id需要一樣
默認1秒向外通告一次 自己的優先級和心跳信息等
pass只要是一樣的即可
虛擬VIP格式
ip 指明在eno16xxx設備上 別名
多個地址的多播地址一樣 就在一個域內
只要一樣的即可
默認搶占式
node1優先級高 所以會搶占
同理 主節點關閉服務 VIP又飄逸回去
可以看到多播信息 一秒鐘發送一個
通過查看多播地址的信息查看抓包情況
1秒一個 host指定主機地址
備用節點也可以收到
關閉node1
node2自己通告 可以看到優先級
再次開啟node1 的服務
這就是vRRp
雙主模型—主備和備主
再高一個虛擬路由器
不同的密碼
這個虛擬路由器配置node2的優先級高,優先級低
給node2復制
可以看到兩組都在通報
都變成優先級高的了
man keepalived.conf
配置和演練
通知腳本的使用方式:示例通知腳本:#!/bin/bash#contact='root@localhost'notify() {local mailsubject="$(hostname) to be $1, vip floating"local mailbody="$(date +'%F %T'): vrrp transition, $(hostname) changed to be $1"echo "$mailbody" | mail -s "$mailsubject" $contact}case $1 inmaster)notify master;;backup)notify backup;;fault)notify fault;;*)echo "Usage: $(basename $0) {master|backup|fault}"exit 1;;esac 腳本的調用方法:notify_master "/etc/keepalived/notify.sh master"notify_backup "/etc/keepalived/notify.sh backup"notify_fault "/etc/keepalived/notify.sh fault"文本粘貼進去
-p保留權限
Node1 和node2都先保留一份keepalved雙主模型的
然后把keepalived只保留一個虛擬路由
:.,$d
man keepalived.conf
添加幾條新參數
腳本的調用方法:notify_master "/etc/keepalived/notify.sh master"notify_backup "/etc/keepalived/notify.sh backup"notify_fault "/etc/keepalived/notify.sh fault"
開啟一個節點
發現沒有發送郵件
node1搶占
但是納悶的是郵件沒有發送出來
都加上雙引號
停止服務 開啟服務(node2)
node1開啟
就是因為引號的問題 沒有把后面的參數識別 所以需要加上
后續可以把這個通知腳本 使用python寫等等 網上有多種
默認keepalived是為lvs設計的
lvs規則在兩個keepalived上都有
再次開啟兩個RS 172.16.0.6 和172.16.0.7
時間同步
都開啟
定義虛擬服務器
配置后端主機都down了訪問頁面
判斷后端主頁校驗碼是否一樣 這種要求更嚴格
nb_get_retry 3 重試3次
delay_before_retry :重試之前的延遲時長;
connect_timeout :連接請求的超時時長;
node2配置也是一樣的
兩邊都先關閉服務
ipvs規則兩邊都有
只是誰有VIP誰提供服務
curl就是默認主頁了
服務都開啟就又成功了
都關閉keepalived服務 配置雙主模型
之前備份的文件
.,$ w >> /etc/xx
成功追加了
node2同樣追加進去
沒有98是因為98沒有使用別名
是nginx主頁
因為沒有定義98是VIP 也沒有定義98 是集群服務
后端RS需要給lo:1上添加98為vip
配置文件再添加一組98
比較麻煩 先不定義了
使用TCP檢測
開啟服務
0.7主機是TCP檢測方式
健康狀態檢測成功
TCP方法也很簡單
real_server可以通過notify_up 或者down發郵件去檢測
當然可以使用zabbix監控更好
keepalived與nginx實現高可用故障轉移實戰
使用keepalived高可用nginx
lvs比較麻煩
所以多使用Nginx或者haproxy工作在四層代理
nginx代理
外部網卡做成流動地址,通過VIP接受用戶請求
后端請求也只響應給nginx的內網地址即可
后端主機使用私網地址
nginx兩個接口
keepalived在Nginx主機做
重新開始配置
兩臺nginx主機 都是 一個對外接口 一個對內Ip
內部的RS 使用一臺主機即可 虛擬為多臺
所以需要添加多個IP
編輯默認主頁
三個一樣
測試虛擬主機
只要確保倆個nginx服務啟動著(類似于lvs的規則) VIP飄逸過來即可使用
檢測腳本檢測
如果檢測失敗了 立刻減去權重
通過腳本監控完成資源轉移
主不下線 降權 就可以把VIP給備節點了
兩個節點都安裝
嫌麻煩,可以把上面的keepalived文件復制過來
把地址修改下
腳本也復制過去
期待通過腳本完成VIP轉移 而不是直接停掉服務 比如生產中主節點需要更新臨時下線
腳本先定義后調用
調用在vrrp_instance里面
判斷down文件是否存在 存在錯誤退出 不存在正確退出
腳本失敗了 降權 -10 小于備用節點即可
1秒檢測一次
跟蹤腳本結果 tract_script
刪除腳本又回來了
可以借助腳本監控Nginx服務
nginx做反代服務
先手動測試下能否成功
現在定義誰是主節點誰就開啟nginx服務
備用節點就把Nginx服務關閉
就在notify.sh腳本中添加
現在查看Ip發現Node1 是keepalived節點 VIP在
所以通過外部的通知腳本完成輔助功能
刪除down
所以這個就是通知腳本的作用
通過通知腳本的建立來降低優先級權重實現VIP漂移到備節點
備節點成為主節點后執行notify master 激活 開啟nginx服務 并且發送郵件
但是一般別讓nginx服務停掉
nginx會自動狀態檢測
添加腳本監控Nginx進程完成降級
干掉nginx 或者開啟http沖突
看能否轉走VIP
兩邊都修改
多失敗幾次
都停掉keepalived服務
地址轉移
nginx
可以發現啟動不起來nginx服務
因為轉成備用節點 已經觸發了
需要手動開啟
先關閉 確保80端口沒有倍監聽
優先級也降低了
刪除down也回不來 因為自己是96 對方是100了
高可用nginx
雙主模型
node1拿到77的地址 node2拿到78的地址
嘗試dns主機名解析到這兩個VIP即可
檢測健康
這就是keepalived高可用Nginx 生產中常用
還可以高可用haproxy哦
或者mysql的高可用
總結
以上是生活随笔為你收集整理的nginx反向代理配置+lnmp优化+七层负载upstream+keepalived的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Java练手小项目——BMI计算器
- 下一篇: android ‘低’仿支付宝我的应用功