反代服務器取得內容緩存到本地，然后加速返回給客戶端。

緩存命中率高　可以極大的緩解后端服務器壓力。影響ｎｇｉｎｘ

一般ｎｇｉｎｘ作為負載均衡器，不會讓ｎｇｉｎｘ反向代理去緩存。而是讓緩存服務器去緩存。

１.ｗｅｂ服務
２.反代
３.偽四層

ｎａｔ只負責轉發過去

但是代理是轉述　需要修飾的

ｎｇｉｎｘ既要當成服務端接受用戶請求
也要當成客戶端去訪問互聯網

可以理解用戶請求的具體信息
并且可以緩存到本地

代理需要監聽在套接字上，并且理解這個協議。

代理就是雙面人

后端真實主機



ｎｇｉｎｘ代理服務器


這個作為反向代理服務器

自己配置一個虛擬主機

自己不是ｗｅｂ服務器　所以不需要ｒｏｏｔ
直接反代到后端主機

直接反代即可

注意：如果后端代理有多個虛擬主機
ｐｒｏｘｙ＿ｐａｓｓ就基于ｉｐ＋端口＋或者主機名

如果直接訪問Ip就是代理服務器本身的

本機的包是從代理服務器發送過來的

在啟動一個新的后端服務器

默認發布頁面

這個緩存圖片

希望圖片到第二臺服務器

網關聯系不到后端服務器
可能是沒有啟動

有了這個功能　動靜分離就沒問題了

不加／意思是只要訪問／下的比如／ｉｎｄｅｘ．ｈｔｍｌ就補充到８０后面１９２.１６.１０.１１／ｉｎｄｅｘ．ｈｔｍｌ

表示只是把／ａｄｍｉｎ／和圖片代理了

后端主機添加目錄／ａｄｍｉｎ／

就是把整個路徑傳到后面去了

添加／
以為訪問／ａｄｍｉｎ／的時候會替換為后端主機／下的內容

這種加不加沒有區別

正則無法替換
如果在８０后面加／就會ｎｇｉｎｘ　－ｔ語法錯誤

ngx_http_proxy_module模塊：The ngx_http_proxy_module module allows passing requests to another server.1、proxy_pass URL;Context: location, if in location, limit_except注意：proxy_pass后面的路徑不帶uri時，其會將location的uri傳遞給后端主機；server {...server_name HOSTNAME;location /uri/ {proxy http://hos[:port];}...}http://HOSTNAME/uri --> http://host/uri proxy_pass后面的路徑是一個uri時，其會將location的uri替換為proxy_pass的uri；server {...server_name HOSTNAME;location /uri/ {proxy http://host/new_uri/;}...}http://HOSTNAME/uri/ --> http://host/new_uri/ 如果location定義其uri時使用了正則表達式的模式，或在if語句或limt_execept中使用proxy_pass指令，則proxy_pass之后必須不能使用uri; 用戶請求時傳遞的uri將直接附加代理到的服務的之后；server {...server_name HOSTNAME;location ~|~* /uri/ {proxy http://host;}...}http://HOSTNAME/uri/ --> http://host/uri/； 意思就是請求時什么　后面就必須時補在后面的而不是替換

一般用戶訪問后端知識服務器　　代理服務器構建后發給后端服務器　后端真實服務器不知道是客戶是誰
所以代理服務器可以修改報文首部　就是發往后端服務端的首部的值　　添加客戶首部IP
或者響應報文發給客戶端的首部

2、proxy_set_header field value;設定發往后端主機的請求報文的請求首部的值；Context: http, server, locationproxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 實際用這個

后端抓包看包的首部信息

該日志格式

本來時％ｈ也就是代理服務器的IP值
現在更換為上面定義的變量　就是客戶端的IP

可以看到真正的客戶端IP

ngx_http_headers_module模塊
還可以更改代理服務器響應給客戶端的時候
送給客戶端的

ngx_http_headers_module模塊The ngx_http_headers_module module allows adding the “Expires” and “Cache-Control” header fields, and arbitrary fields, to a response header.向由代理服務器響應給客戶端的響應報文添加自定義首部，或修改指定首部的值；1、add_header name value [always];添加自定義首部；add_header X-Via $server_addr;add_header X-Accel $server_name;

代理還可以啟動緩存進行加速哦~~

這個是代理服務器發送客戶端報文允許哪些首部是可以發送過去的

代理還可以啟動緩存進行加速哦~~

到后端取回來后放在本地磁盤

直接兩個網絡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第一次綁定后面肯定都在一個服務器

ngx_http_upstream_module模塊 The ngx_http_upstream_module module is used to define groups of servers that can be referenced by the proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, and memcached_pass directives.1、upstream name { ... }定義后端服務器組，會引入一個新的上下文；Context: httpupstream httpdsrvs {server ...server......}2、server address [parameters];在upstream上下文中server成員，以及相關的參數；Context: upstreamaddress的表示格式：unix:/PATH/TO/SOME_SOCK_FILEIP[:PORT]HOSTNAME[:PORT]parameters：weight=number權重，默認為1；max_fails=number失敗嘗試最大次數；超出此處指定的次數時，server將被標記為不可用；fail_timeout=time設置將服務器標記為不可用狀態的超時時長；max_conns當前的服務器的最大并發連接數；backup將服務器標記為“備用”，即所有服務器均不可用時此服務器才啟用；down標記為“不可用”；3、least_conn;最少連接調度算法，當server擁有不同的權重時其為wlc;4、 ip_hash;源地址hash調度方法；5、hash key [consistent];基于指定的key的hash表來實現對請求的調度，此處的key可以直接文本、變量或二者的組合；作用：將請求分類，同一類請求將發往同一個upstream server；If the consistent parameter is specified the ketama consistent hashing method will be used instead.示例：hash $request_uri consistent;hash $remote_addr;6、keepalive connections;為每個worker進程保留的空閑的長連接數量；

前面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說自己是最高優先級
但是不可信的
所以需要認證 組播的

keepalived:vrrp協議的軟件實現，原生設計的目的為了高可用ipvs服務：基于vrrp協議完成地址流動；為vip地址集群的節點生成ipvs規則（在配置文件中預先定義）；為ipvs集群的各RS做健康狀態檢測；基于腳本調用接口通過執行腳本完成腳本中定義的功能，進而影響集群事務；（nginx,haproxy等需要）組件：核心組件：vrrp stackipvs wrappercheckers控制組件：配置文件分析器IO復用器內存管理組件 HA Cluster的配置前提：(1) 各節點時間必須同步；ntp, chrony(2) 確保iptables及selinux不會成為阻礙；(3) 各節點之間可通過主機名互相通信（對KA并非必須）；建議使用/etc/hosts文件實現； (4) 確保各節點的用于集群服務的接口支持MULTICAST通信；D類：224-239；

關閉iptabels

關閉firewalld服務

放行多播信息即可

多播功能需要打開

keepalived安裝配置：CentOS 6.4+ 隨base倉庫提供； 程序環境：主配置文件：/etc/keepalived/keepalived.conf主程序文件：/usr/sbin/keepalivedUnit File：keepalived.serviceUnit File的環境配置文件：/etc/sysconfig/keepalived

分別是全局配置
VRRP配置
LVS配置

配置文件組件部分：TOP HIERACHYGLOBAL CONFIGURATIONGlobal definitionsStatic routes/addressesVRRPD CONFIGURATIONVRRP synchronization group(s)：vrrp同步組；確保吧VIP放在同一個節點的主機上VRRP instance(s)：每個vrrp instance即一個vrrp路由器；LVS CONFIGURATIONVirtual server group(s)Virtual server(s)：ipvs集群的vs和rs；

組播地址

默認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了訪問頁面

虛擬服務器：配置參數：virtual_server IP port |virtual_server fwmark int {...real_server {...}...}常用參數：delay_loop <INT>：服務輪詢的時間間隔；lb_algo rr|wrr|lc|wlc|lblc|sh|dh：定義調度方法；lb_kind NAT|DR|TUN：集群的類型；persistence_timeout <INT>：持久連接時長；protocol TCP：服務協議，僅支持TCP；sorry_server <IPADDR> <PORT>：備用服務器地址；real_server <IPADDR> <PORT>{weight <INT>notify_up <STRING>|<QUOTED-STRING>notify_down <STRING>|<QUOTED-STRING>HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }：定義當前主機的健康狀態檢測方法；}

判斷后端主頁校驗碼是否一樣 這種要求更嚴格

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飄逸過來即可使用

keepalived調用外部的輔助腳本進行資源監控，并根據監控的結果狀態能實現優先動態調整；分兩步：(1) 先定義一個腳本；(2) 調用此腳本；vrrp_script <SCRIPT_NAME> {script ""interval INT weight -INT }track_script {SCRIPT_NAME_1SCRIPT_NAME_2...}

檢測腳本檢測
如果檢測失敗了 立刻減去權重

通過腳本監控完成資源轉移

主不下線 降權 就可以把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的高可用

總結

以上是生活随笔為你收集整理的ｎｇｉｎｘ反向代理配置+lnmp优化+七层负载upstream+keepalived的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。