openstack負載均衡的現狀與發展以及lvs，Nginx，Haproxy三種負載均衡機制的基本架構和對比
【負載均衡】
大量用戶發起請求的情況下，服務器負載過高，導致部分請求無法被響應或者及時響應。
負載均衡根據一定的算法將請求分發到不同的后端，保證所有的請求都可以被正常的下發並返回。
【主流實現-LVS】
LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬服務器，已經是 Linux 標准內核的一部分。
采用IP負載均衡技術和基於內容請求分發。
調度器具有很好的吞吐率，將請求均衡得轉移到不同的服務器上執行，且調度器可以自動屏蔽掉故障的服務器，從而將一組服務器構成一個高可用，高性能的服務器集群。
*負載均衡機制
1. LVS是四層負載均衡，也就是說在傳輸層上，LVS支持TCP/UDP。由於是四層負載均衡，所以相對於其他的高層負載均衡而言，對於DNS域名輪流解析，應用層負載的調度，客戶端的調度等，它的效率是相對較高的。
2. 四層負載均衡，主要通過報文的目標地址和端口。（七層負載均衡又稱為"內容交換"，主要是通過報文中真正有意義的應用層內容）
3. LVS的轉發主要通過修改IP地址（NAT模式，包括SNAT和DNAT），修改目標MAC（DR模式）來實現。
*負載均衡模式-NAT模式
NAT（Network Address Translation）是一種外網和內網地址映射的技術。
NAT模式下，網絡數據包的進出都要經過LVS的處理。LVS需要作為RS（真實服務器）的網關。
當包從Client到達LVS時，LVS做DNAT（目標地址轉換），將D-IP（目的地址）改變為RS的IP。
RS處理完成，將包返回的時候，S-IP（源地址）是RS，D-IP是Client的IP。
到達LVS做網關中轉時，LVS會做SNAT（源地址轉換），將包的S-IP改為VIP。
*負載均衡模式-DR模式
DR（直接路由）模式下需要LVS和RS綁定同一個集群（RS通過將VIP綁定在loopback實現）。
請求由LVS接受，返回的時候由RS直接返回給Client。
當包到LVS的時候，LVS將網絡幀的MAC地址修改為某台RS的MAC，此包會被轉發到對應的RS上面進行處理。
此時S-IP和D-IP都沒有發生改變。
RS收到LVS轉發的包時，鏈路層發現MAC地址是自己的，網絡層發現IP地址也是自己的，於是包被合法接受，RS不感知LVS。
當包返回時，RS直接返回給Client，不再經過LVS。
它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一台服務器的映射。
在LBLC算法里面，某些熱門站點報文較多，可能服務器很快會達到飽和，然后切換到第二台又會很快達到飽和，然后后端服務器就一直在切換，造成資源不必要的浪費。
LCLBR里面，單個服務器變成了一組服務器，就會有效避免這種情況。
7. 目標地址散列
8. 源地址散列
*LVS的優點
1. 抗負載能力強，由於工作在傳輸層上，只做分發，無流量產生，所以它在所有的負載均衡里面性能是最強的，對內存和CPU的消耗也比較低。
2. 配置性較低，減少人為出錯的概率，但是也相應減少了人為自主性。
3. 工作穩定，自身有完整的雙機熱備方案，如：LVS + Keepalived
4. 無流量，保證IO不會受到影響。
*LVS的缺點
1. 軟件本身不支持正則表達式處理，不能做動靜分離。
2. 網站應用比較龐大的時候，LVS/DR+Keepalive實施較為復雜。
【主流實現-Nginx】
Nginx是一個很強大的高性能Web和反向代理服務器。
最大的優勢在於高負載情況下對內存和CPU的低消耗。
在高並發的情況下，Nginx是Apache服務器不錯的替代品。
*傳統基於進程或線程的模型
傳統基於進程或線程的模型（如Apache）在處理並發時會為每一個連接建立一個單獨的進程或線程。這種方法會在網絡傳輸或者I/O操作上阻塞。
對於應用來講，在內存和CPU的使用上效率都是非常低的。
而且，生成一個單獨的進程/線程還需要為其准備新的運行環境（主要包括分配堆棧內存），以及上下文執行環境。
創建這些都消耗額外的CPU時間，這最終也會因為線程上下文來回切換導致性能非常差。
*Nginx架構設計
Nginx的架構設計是采用模塊化的，基於事件驅動，異步，單線程且非阻塞。
Nginx大量使用多路復用和事件通知，nginx啟動之后，會在系統中以 daemon（守護進程） 的方式在后台運行，包括一個master進程和多個worker進程。
所有的進程都是單線程的，進程間通信主要通過共享內存的方式。
多個連接，是通過worker進程中高效回環（run-loop）機制來處理的。對於每個worker進程來說，每秒鍾可以處理上千個請求和連接。
*Nginx負載均衡
Nginx 負載均衡主要針對七層的http和https，當然，四層Nginx后來也支持了（1.9.0版本增加stream模塊，用來實現四層協議）。
Nginx主要是通過反向代理的方式進行負載均衡的，所謂反向代理（Reverse Proxy），指的是以代理服務器來接收 Client 請求，然后將請求轉發到內部服務器，並將內部服務器處理完成的結果返回給 Client ，對外，代理服務器就是真正的服務器，內部服務器外部不感知。
Nginx支持以下幾種策略：
輪詢·default
weight （權重）
ip_hash （可用於解決會話保持的問題）
fair·第三方 （按后端服務器的響應時間來分配請求，響應時間短的優先分配）
url_hash·第三方 （相同的url定位到相同的服務器）
*Nginx的優勢
1. 跨平台，配置簡單
2. 非阻塞，高並發（官方測試可以支撐5萬並發數）
3. 事件驅動，通信機制采用 epoll 模型，支持更大的並發連接
4. 內存消耗小。（3萬並發數下，10個Nginx進程只需要150M內存）
5. 內置的健康檢查功能。 （一台后端服務器宕機了，不會影響前端訪問）
6. 節省帶寬。 （支持GZIP壓縮，可以添加瀏覽器緩存的header）
7. 穩定性高。 （反向代理，宕機的概率很小）
*Nginx的缺點
1. 對后端服務器的健康檢查，只支持通過端口檢測，不支持url檢測。
2. 不支持Session的直接保持。（通過ip_hash可解決）
【主流實現-Haproxy】
Haproxy提供高可用性，負載均衡以及基於TCP和HTTP的代理。
特別適用於那些負載特大的Web站點，這些站點通常需要會話保持或七層處理。
Haproxy支持四層和七層兩種負載模式。
Haproxy有一些Nginx不具有的優點，比如支持Session的保持，Cookie的引導；同時支持通過獲取指定的URL來檢測后端服務器的狀態。
Haproxy和LVS類似，本身就只是一款負載均衡軟件；單純從效率上來講，比Nginx有更好的負載均衡速度，在並發處理上也優於Nginx。
Haproxy支持的負載均衡策略也比較多：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）。
【三種負載均衡的比較】
| 比較 |
HAProxy |
Nginx |
LVS |
|
優點 |
支持session保持，Cookie引導。
可通過url檢測后端服務器健康狀態。
也可做MySQL、Email等負載均衡。
支持通過指定的URL對后端服務器健康檢查。 |
http、https、Emai協議功能較好，處理相應請求快。
Web能力強，配置簡單，支持緩存功能、適用動靜分離，低內存消耗。
支持WebSocket協議。
支持強大的正則匹配規則 。 |
通過vrrp轉發（僅分發）效率高，流量通過內核處理，沒有流量產生。（理論）
相當穩定可靠。
|
| 缺點 |
一般不做Web服務器的Cache。 |
不支持session直接保持，但可通過ip_hash解決。 只能通過端口對后端服務器健康檢查。 |
不支持正則，不能做動靜分離，配置略復雜，需要IP略多。 沒有后端主機健康狀態檢查。 |
|
支持算法 |
目標uri hash(uri) url參數 (url_params) 請求頭信息調度(hdr(name)) cookie (rdp-cookie) |
最小響應時間 自定義hash內容(hash key [consistent]) url hash 最短時間和最少連接 |
最短期望延遲(Shortest Expected Delay) 不排隊(Never Queue) 基於局部性的最少連接(LBLC) 帶復制的基於局部性最少鏈接(LCLBR) |
| 官網 |
|
||
| 虛擬主機 |
支持 |
支持 |
不支持 |
| 適用性 |
四層，七層（常用） |
四層，七層（常用） |
四層 |
| 量級 |
七層重量級，四層輕量級 |
七層重量級，四層輕量級 |
四層重量級 |
| 常用熱備 |
Keepalived+其它 |
Keepalived+其它 |
Keepalived+其它 |
*補充區別
HAProxy對於后端服務器會一直做健康檢測（就算請求沒過來的時候也會做健康檢查）
后端機器故障發生在請求還沒到來的時候，haproxy會將這台故障機切掉，但如果后端機器故障發生在請求到達期間，那么前端訪問會有異常。
也就是說HAProxy會把請求轉到后端的這台故障機上，並經過多次探測后才會把這台機器切掉，並把請求發給其他正常的后端機，這勢必會造成一小段時間內前端訪問失敗。
Nginx對於后端的服務器不會一直做健康檢測
后端機器發生故障，在請求過來的時候，分發還是會正常進行分發，只是請求不到數據的時候，它會再轉向好的后端機器進行請求，直到請求正常為止。
也就是說Nginx請求轉到后端一台不成功的機器的話，還會再轉向另外一台服務器，這對前端訪問沒有什么影響。
因此，如果有用HAProxy做為前端負載均衡的話 ，如果后端服務器要維護，在高並發的情況，肯定是會影響用戶的。
但如果是Nginx做為前端負載均衡的話，只要並發撐得住，后端切掉幾台不會影響到用戶。
【Openstack LBaaS的現狀】
Neutron中的loadbalance服務lbaas，可以將來自公網或內部網絡的訪問流量，分發到雲資源中的雲主機上，可以隨時添加或者減少后端雲主機的數量，而不影響業務。
lbaas在Grizzly版本集成到Neutron中。
現在社區最新的API版本為V2，在Kilo中發布，包含以下概念：
Lbaas V1與V2的區別如下：
| 功能 |
lbaas |
lbaasV2 |
| 最大連接數 |
Y |
Y |
| TCP負載均衡 |
Y |
Y |
| HTTP負載均衡 |
Y |
Y |
| HTTPS負載均衡 |
Y |
Y |
| TERMINATED_HTTPS負載均衡 |
X |
Y |
| 基於hostname的url轉發 |
X |
Y |
| 基於path的url轉發 |
X |
Y |
| 基於filename的url轉發 |
X |
Y |
| 基於header的url轉發 |
X |
Y |
| 基於cookie的url轉發 |
X |
Y |
| 一個vip支持多種協議和端口 |
X |
Y |
LBaaS（Load Balancer as a Service）是 OpenStack 的網絡負載均衡服務，為用戶提供應用集群負載均衡解決方案。LBaaS 支持將來自公網或內部網絡的應用服務訪問流量按照指定的均衡策略分發到資源池內的雲主機，允許用戶隨時增加、減少提供應用服務的雲主機而不影響業務可用性，有效保障了應用服務的響應速度和高可用。
以往，LBaaS 基於 Neutron 實現，LBaaS V1 API 在 Grizzly 版本被集成到 Neutron，功能模塊的代碼實現在 openstack/neutron-lbaas repo，支持 Plug-In 模式，提供了 HAProxy、F5 等多種 Driver 對接底層負載均衡器。LBaaS V2 API 在 Kilo 版本發布，Liberty 版本正式支持，同期發布的還有 Octavia Plugin。歷經幾個版本的迭代，Octavia 在 Pike 版本成為了需要在 Keystone 上注冊 endpoint 的獨立項目而不再是 Neutron 的一個服務插件。現在社區也正逐漸將 openstack/neutron-lbaas repo 實現的 Driver 遷移到 openstack/octavia repo，在 Queens 版本中 neutron-lbaas 正式被標記為廢棄「Neutron-lbaas is now deprecated」。
為什么廢棄 neutron-lbaas 擴展項目？社區給出了詳盡的說明，簡單總結一下有兩點原因：
neutron-lbaas 與 Neutron 項目的耦合度太高，前者會直接使用 Neutron 的代碼和 DB 從而導致 LBaaS API 的性能和擴展性不佳，而且 HAProxy Plugin 的實現也不具有高可用特性。總的來說，neutron-lbaas 不適用於大規模部署場景。
Ocatvia 項目已經成熟，可以向外提供穩定的 REST API，允許用戶跨版本集成和遷移。同時，完全獨立的狀態會使 Ocatvia 發展得更加迅速。
項目組織的變化：
| items | Old | New |
|---|---|---|
| Repo | openstack/neutron-lbaas | openstack/octavia |
| CLI | neutronclient | octaviaclient (openstackclient 的擴展) |
| Horizon panels | neutron-lbaas-dashboard | octavia-dashboard (Queens 開始支持) |
【Octavia 介紹】
Octavia當前作為lbaasV2的一個driver存在，完全兼容lbaasV2的接口，最終的發展趨勢會作為一個獨立的項目代替lbaasV2。
架構圖如下：
網絡結構如下：
參考：https://www.cnblogs.com/liuxia912/p/11143447.html
https://blog.csdn.net/jmilk/article/details/81279795