什么是基于四層的負載均衡技術 四層負載均衡和七層負載均衡



文章插圖
什么是基于四層的負載均衡技術 四層負載均衡和七層負載均衡

文章插圖
根據規模的提升在不同的階段需要使用不同的技術和架構,具體的需求需要具體分析,如果是中小型的 Web 應用 。
日活躍小于 1000 萬,使用 nginx 就可以完全滿足了;大型網站或重要的服務,并且服務比較多時,就可以考慮使用 LVS 。Nginx
Nginx (“engine x”) 是一個高性能的 HTTP 和 反向代理 服務器,也是一個 IMAP/POP3/SMTP 代理服務器 。
Nginx 特點是占有內存少,并發能力強,nginx 的并發能力在同類型的網頁服務器中表現較好 。
Nginx 的簡單架構:
Nginx 的架構設計
Nginx 的架構設計采用的是模塊化的,基于事件驅動、異步、單線程且非阻塞(epoll 模型)
Nginx 使用多路復用和事件通知,Nginx 啟動后,在后臺以 daemon 的方式在系統中運行,其中會包括一個主(master)進程,n(n≥1)個工作(worker)進程 。
所有的進程都是單線程(即只有一個主線程)的,進程間通信主要使用共享內存的方式 。
其中,master 進程用于接收外部的請求,發送信號給 worker 進程,同時監控 worker 進程的工作狀態 。
worker 進程用來處理外部請求信息,請求只能在一個 worker 進程中被處理,一個 worker 進程只有一個主線程,同時只能處理一個請求 。
Nginx 負載均衡
Nginx 負載均衡是對七層網絡通信模型中的應用層(HTTP,HTTPS)進行的 。
Nginx 是以反向代理的方式進行負載均衡
反向代理:是以代理服務器來接收用戶的請求,然后將請求發給內部網絡上的服務器,并將服務器上的結果返回給請求的客戶端,此時代理服務器就是一個服務器 。負載均衡:就是將這些客戶端的請求按照某種策略分攤到后臺多臺服務器上面,進行處理 。
Nginx 的 upstream 目前支持 6 種算法分配方式:
輪詢
最基本的配置方法,它是 upstream 模塊默認的負載均衡默認策略 。每個請求會按時間順序逐一分配到不同的后端服務器 。
有如下參數:
在 30 秒內錯誤次數超過 2 次,就認為服務器已經不能訪問了,下次就不會訪問該機器
server 10.168.226.1:8080 max_fails=2 fail_timeout=30s;
server 10.168.226.2:8080 max_fails=2 fail_timeout=30s;
weight
權重方式,在輪詢策略的基礎上指定輪詢的幾率
server 10.168.226.1:8080 weight=1 ;
server 10.168.226.2:8080 weight=2;
注意:
權重越高分配到需要處理的請求越多 。此策略比較適合服務器的硬件配置差別比較大的情況 。
ip_hash
指定負載均衡器按照基于客戶端 IP 的分配方式,這個方法確保了相同的客戶端的請求一直發送到相同的服務器,以保證 session 會話 。
這樣每個訪客都固定訪問一個后端服務器,可以解決 session 不能跨服務器的問題 。
【什么是基于四層的負載均衡技術 四層負載均衡和七層負載均衡】ip_hash; # 保證每個訪客固定訪問一個后端服務器
server 10.168.226.1:8080 weight=1 ;
server 10.168.226.2:8080 weight=2;
注意:
ip_hash在nginx1.3版本之后才有的 ip_hash不能與backup同時使用這種策略適合有狀態服務,比如session 當有服務器需要剔除,必須手動down掉 。
least_conn
把請求轉發給連接數較少的后端服務器,輪詢算法是把請求平均的轉發給各個后端服,使它們的負載大致相同 。
但是,有些請求占用的時間很長,會導致所在的后端負載較高,這種情況下,least_conn這種方式就可以達到更好的負載均衡效果least_conn;
server 10.168.226.1:8080 weight=1;
server 10.168.226.2:8080 weight=2;
注意:
這種負載均衡策略適合請求處理時間長短不一致造成服務器過載的情況
第三方策略
第三方的負載均衡策略的實現需要安裝第三方插件(upstream_fair)
fair安裝服務器端響應時間來分配請求,響應時間段的優先分配fair;server 10.168.226.1:8080 weight=1;server 10.168.226.2:8080 weight=2;url_hash按訪問 URL 的 hash 結果來分配請求,是每個 URL 定向知道同一個后端服務器,要配合緩沖命中來使用同一個資源多次求,可能會到達不同的服務器上,導致不必要的多次下載,緩存命中率不高以及一些資源時間的浪費 。而使用 url_hash,可以使得同一個 URL 會到達同一臺服務器,一段緩存了資源,再次請求的時候,就可以從緩存中讀取,需要 hash 軟件包hash $request_uri; # 實現每個 URL 定向到同一個后端服務器server 10.168.226.1:8080 weight=1;server 10.168.226.2:8080 weight=2;Nginx 的優點跨平臺:Nginx 可以在 Linux 上編譯運行,也可以在 window 上運行配置簡單:直接可以通過簡單修改配置文件,容易上手非阻塞、高并發:官網理論可以支持 5 萬并發連接,在實際生產環境也可以跑到 2-3 萬的并發事件驅動:采用 epoll 模型,支持更多的并發連接內存消耗小:內存和 CPU 占用率低 。(為 Apache 的 1/5-1/10)內置健康檢查:Nginx 代理的后端的某臺服務器宕機了,會自動不訪問該機器Nginx 的缺點Nginx 僅能支持 HTTP,HTTPS,tcp,email 等協議不支持直接保存 session,可以通過 ip_hash 來支持LVS
LVS 就是 Linux 虛擬(Virtual Server)服務器 。從 Linux 內核 2.4 之后,內置了 LVS 的各個功能模塊,就可以直接 使用 LVS 提供的功能 。
LVS 的體系架構
LVS 架構 的服務器集群系統有三個部分 組成:
最前端的負載均衡層,用 Load Balancer 表示中間的服務器集群層,用 Server Array 表示最底層的數據共享層,Shard storage 表示負載均衡機制
LVS 是四層負載均衡,建立在 OSI 模型的第四層——傳輸層之上,傳輸層有 TCP/UDP,相對于其它高層負載均衡的方法,比如 DNS 域名輪詢解析,應用層負載的調度,客戶端的調度等,它的效率都非常高 。
四層負載均衡:主要通過報文中的目標地址和端口七層負載均衡:也稱為“內容交換”,主要通過報文中的 真正有意義的應用層內容 。
LVS 的轉發主要通過修改 IP 地址(NAT 模式,分為源地址修改 SNAT 和目標地址修改 DNAT)、修改目標 MAC(DR 模式)來實現 。
LVS 相關術語
DS:Director Server 。指的是前端負載均衡器節點 。
RS:Real Server 。后端真實的工作服務器 。
VIP:向外部直接面向用戶請求,作為用戶請求的目標的 IP 地址 。
DIP:Director Server IP,主要用于和內部主機通訊的 IP 地址 。
RIP:Real Server IP,后端服務器的 IP 地址 。
CIP:Client IP,訪問客戶端的 IP 地址
NAT 模式:網絡地址轉換
NAT(network address transaction)是外網和內網地址映射的技術 。
NAT 模式下,網絡數據的進出都要經過 LVS 處理,LVS 需要作為真實服務器的網關 。
當包請求到 LVS 時,LVS 做目標地址轉換(DNAT),將目標 IP 改為 RS 的 IP 。RS 處理完,返回響應時,源 IP 是 RS IP,目標 IP 是客戶端的 IP 。RS 的包通過網關(LVS)中轉,LVS 做源地址轉換(SNAT),將包的源地址改為 VIP,這樣,這個包對客戶端來說就像是 LVS 直接返回給它的 。DR 模式:直接路由
DR 模式下需要 LVS 和 RS 集群綁定同一個 VIP,與 NAT 的不同點在于:
請求由 LVS 接受,由真實提供服務的服務器(RS)直接發放給用戶,返回的時候不經過 LVS 。
一個請求過程中,LVS 只需要將網絡幀的 Mac 地址修改為某一臺 RS 的 MAC,該請求就去會被轉發到響應的 RS 處理,此時的源 IP 和目標 IP 都沒有變 。
RS 收到 LVS 轉發來的請求時,鏈路層發現 Mac 地址是自己的,當上面的網絡層,也發現 IP 是自己的,于是這個包被合法的接受,RS 感知不到前面有 RS 的存在 。當 RS 返回響應時,只要直接向源 IP 返回即可,不再經過 LVS 。
DR 負載均衡模式數據分發過程中不修改 IP 地址,只修改 Mac 地址,由于實際處理請求的真實物理 IP 地址和 數據請求目的 IP 地址一致,所以不需要通過負載均衡服務器進行地址轉換,就可以將響應數據直接返回給瀏覽器,避免服務器網卡帶寬成為瓶頸 。
DR 模式具有較好的性能,也是目前大型網站使用最廣泛的一種負載均衡 。
LVS 的優點負載能力強,工作在傳輸層上僅作為分發的作用,沒有流量的產生,對內存和 CPU 資源消耗比較低配置簡單,很容易上手工作穩定,有完整的雙機熱備方案,如:LVS+Keepalived無流量,LVS 只分發請求應用范圍比較廣,LVS 工作在傳輸層,幾乎可以對所有應用做負載均衡,包括 HTTP,數據庫LVS 的缺點軟件本身不支持正則表達式,不能做動靜方法分離網站應用比較龐大的話,LVS 實施起來比較復雜