均衡負載伺服器部署什麼地方

⑴ 如何配置Web伺服器實現負載均衡

網路的負載均衡是一種動態均衡技術，通過一些工具實時地分析數據包，掌握網路中的數據流量狀況，把任務合理均衡地分配出去。這種技術基於現有網路結構，提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法，加強了網路數據處理能力，提高了網路的靈活性和可用性。

以四台伺服器為例實現負載均衡：

安裝配置LVS

1. 安裝前准備：

(1)首先說明，LVS並不要求集群中的伺服器規格劃一，相反，可以根據伺服器的不同配置和負載狀況，調整負載分配策略，充分利用集群環境中的每一台伺服器。如下表：

Srv Eth0 Eth0：0 Eth1 Eth1：0

vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254

vsbak 10.0.0.3 192.168.10.102

real1 192.168.10.100

real2 192.168.10.101

其中，10.0.0.2是允許用戶訪問的IP。

(2)這4台伺服器中，vs1作為虛擬伺服器(即負載平衡伺服器)，負責將用戶的訪問請求轉發到集群內部的real1，real2，然後由real1，real2分別處理。
Client為客戶端測試機器，可以為任意操作系統。

(3)所有OS為redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch過ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 網段是24 位。

2.理解LVS中的相關術語

(1) ipvsadm ：ipvsadm是LVS的一個用戶界面。在負載均衡器上編譯、安裝ipvsadm。

(2) 調度演算法： LVS的負載均衡器有以下幾種調度規則：Round-robin，簡稱rr;weighted
Round-robin，簡稱wrr;每個新的連接被輪流指派到每個物理伺服器。Least-connected，簡稱lc;weighted
Least-connected，簡稱wlc，每個新的連接被分配到負擔最小的伺服器。

(3) Persistent client
connection，簡稱pcc，(持續的客戶端連接，內核2.2.10版以後才支持)。所有來自同一個IP的客戶端將一直連接到同一個物理伺服器。超時時間被設置為360秒。Pcc是為https和cookie服務設置的。在這處調度規則下，第一次連接後，所有以後來自相同客戶端的連接(包括來自其它埠)將會發送到相同的物理伺服器。但這也會帶來一個問題，因為大約有25%的Internet
可能具有相同的IP地址。

(4) Persistent port
connection調度演算法：在內核2.2.12版以後，pcc功能已從一個調度演算法(你可以選擇不同的調度演算法：rr、wrr、lc、wlc、pcc)演變成為了一個開關選項(你可以讓rr、
wrr、lc、wlc具備pcc的屬性)。在設置時，如果你沒有選擇調度演算法時，ipvsadm將默認為wlc演算法。 在Persistent port
connection(ppc)演算法下，連接的指派是基於埠的，例如，來自相同終端的80埠與443埠的請求，將被分配到不同的物理伺服器上。不幸的是，如果你需要在的網站上採用cookies時將出問題，因為http是使用80埠，然而cookies需要使用443埠，這種方法下，很可能會出現cookies不正常的情況。

(5)Load Node Feature of Linux Director：讓Load balancer 也可以處理users 請求。

(6)IPVS connection synchronization。

(7)ARP Problem of LVS/TUN and LVS/DR：這個問題只在LVS/DR，LVS/TUN 時存在。

3. 配置實例

(1) 需要的軟體包和包的安裝：

I. piranha-gui-0.4.12-2*.rpm (GUI介面cluster設定工具);

II. piranha-0.4.12-2*.rpm;

III. ipchains-1.3.9-6lp*.rpm (架設NAT)。

取得套件或mount到光碟，進入RPMS目錄進行安裝:

# rpm -Uvh piranha*

# rpm -Uvh ipchains*

(2) real server群：

真正提供服務的server(如web
server)，在NAT形式下是以內部虛擬網域的形式，設定如同一般虛擬網域中Client端使用網域：192.168.10.0/24
架設方式同一般使用虛擬IP之區域網絡。

a. 設網卡IP

real1 ：192.168.10.100/24

real2 ：192.168.10.101/24

b.每台server均將default gateway指向192.168.10.254。
192.168.10.254為該網域唯一對外之信道，設定在virtual server上，使該網域進出均需通過virtual server 。

c.每台server均開啟httpd功能供web server服務，可以在各real server上放置不同內容之網頁，可由瀏覽器觀察其對各real
server讀取網頁的情形。

d.每台server都開啟rstatd、sshd、rwalld、ruser、rsh、rsync，並且從Vserver上面拿到相同的lvs.conf文件。

(3) virtual server：

作用在導引封包的對外主機，專職負責封包的轉送，不提供服務，但因為在NAT型式下必須對進出封包進行改寫，所以負擔亦重。

a.IP設置：

對外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2

對內eth1：192.168.10.1 eth1：0 ：192.168.10.254

NAT形式下僅virtual server有真實IP，real server群則為透過virtual server.

b.設定NAT功能

# echo 1 >; /proc/sys/net/ipv4/ip_forward

# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag

# ipchains -P forward MASQ

c.設定piranha 進入X-window中 (也可以直接編輯/etc/lvs.cf )

a).執行面板系統piranha

b).設定「整體配置」(Global Settings) 主LVS伺服器主機IP：10.0.0.2， 選定網路地址翻譯(預設) NAT路徑名稱：
192.168.10.254， NAT 路徑裝置： eth1：0

c).設定虛擬伺服器(Virtual Servers) 添加編輯虛擬伺服器部分：(Virtual
Server)名稱：(任意取名);應用：http;協議： tcp;連接：80;地址：10.0..0.2;裝置：eth0：0; 重入時間：180
(預設);服務延時：10 (預設);載入監控工具：ruptime (預設);調度策略：Weighted least-connections; 持續性：0
(預設); 持續性屏蔽： 255.255.255.255 (預設); 按下激活：實時伺服器部分：(Real Servers); 添加編輯：名字：(任意取名);
地址： 192.168.10.100; 權重：1 (預設) 按下激活

另一架real server同上，地址：192.168.10.101。

d). 控制/監控(Controls/Monitoring)
控制：piranha功能的激活與停止，上述內容設定完成後即可按開始鍵激活piranha.監控器：顯示ipvsadm設定之routing table內容
可立即更新或定時更新。

(4)備援主機的設定(HA)

單一virtual server的cluster架構virtual server 負擔較大，提供另一主機擔任備援，可避免virtual
server的故障而使對外服務工作終止;備份主機隨時處於預備狀態與virtual server相互偵測

a.備份主機：

eth0： IP 10.0.0.3

eth1： IP 192.168.10.102 同樣需安裝piranha，ipvsadm，ipchains等套件

b.開啟NAT功能(同上面所述)。

c.在virtual server(10.0.0.2)主機上設定。

a).執行piranha冗餘度 ;

b).按下「激活冗餘度」;

冗餘LVS伺服器IP： 10.0.0.3;HEARTBEAT間隔(秒數)： 2 (預設)

假定在…秒後進入DEAD狀態： 5 (預設);HEARTBEAT連接埠： 539 (預設)

c).按下「套用」;

d).至「控制/監控」頁，按下「在當前執行層添加PULSE DEAMON」 ，按下「開始」;

e).在監控器按下「自動更新」，這樣可由窗口中看到ipvsadm所設定的routing table，並且動態顯示real
server聯機情形，若real server故障，該主機亦會從監視窗口中消失。

d.激活備份主機之pulse daemon (執行# /etc/rc.d/init.d/pulse start)。

至此，HA功能已經激活，備份主機及virtual server由pulse daemon定時相互探詢，一但virtual
server故障，備份主機立刻激活代替;至virtual server 正常上線後隨即將工作交還virtual server。

LVS測試

經過了上面的配置步驟，現在可以測試LVS了，步驟如下：

1. 分別在vs1，real1，real2上運行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目錄是vs2輸出的。如果您的NFS配置沒有成功，也可以把vs1上/etc/lvs/rc.lvs_dr復制到real1，real2上，然後分別運行。確保real1，real2上面的apache已經啟動並且允許telnet。

2. 測試Telnet：從client運行telnet 10.0.0.2，
如果登錄後看到如下輸出就說明集群已經開始工作了：(假設以guest用戶身份登錄)

[guest@real1 guest]$——說明已經登錄到伺服器real1上。

再開啟一個telnet窗口，登錄後會發現系統提示變為：

[guest@real2 guest]$——說明已經登錄到伺服器real2上。

3. 測試http：從client運行iexplore http://10.0.0.2

因為在real1 和real2 上面的測試頁不同，所以登錄幾次之後，顯示出的頁面也會有所不同，這樣說明real server 已經在正常工作了。

⑵ 怎麼實現伺服器的負載均衡

負載均衡有兩種含義：第一種，單個負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給用戶，系統處理能力得到大幅度提高，也就是常說的集群（clustering）技術。第二種，大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間，這主要針對Web伺服器、FTP伺服器、企業關鍵應用伺服器等網路應用。通常，負載均衡會根據網路的不同層次（網路七層）來劃分。其中，第二層的負載均衡指將多條物理鏈路當作一條單一的聚合邏輯鏈路使用，這就是鏈路聚合（Trunking）技術，它不是一種獨立的設備，而是交換機等網路設備的常用技術。現代負載均衡技術通常操作於網路的第四層或第七層，這是針對網路應用的負載均衡技術，它完全脫離於交換機、伺服器而成為獨立的技術設備。
伺服器實現負載均衡有軟體和硬體兩種方式
軟體負載均衡的方式是在一台或多台伺服器相應的操作系統上安裝一個或多個應用軟體來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。缺點就是伺服器上的軟體本身就會消耗伺服器系統不定量的資源，同時操作系統本身的原因，安全方面會有影響
硬體負載均衡的方法就是直接在伺服器和外部網路間安裝負載均衡設備，專由門的設備完成專門的任務，獨立於操作系統，整體性能得到提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到負載均衡需求。
負載均衡具體有三種部署方式：路由模式、橋接模式、服務直接返回模式。
路由模式部署靈活，伺服器的網關設置成負載均衡機的LAN口地址，且與WAN口分署不同的邏輯網路。因此所有返回的流量也都經過負載均衡。這種方式對網路的改動小，能均衡任何下行流量。
橋接模式配置簡單，不改變現有網路。負載均衡的WAN口和LAN口分別連接上行設備和下行伺服器。LAN口
不需要配置IP（WAN口與LAN口是橋連接），所有的伺服器與負載均衡均在同一邏輯網路中。這種安裝方式容錯性差，網路架構缺乏彈性，對廣播風暴及其他生成樹協議循環相關聯的錯誤敏感。
服務直接返回模式這種安裝方式負載均衡的LAN口不使用，WAN口與伺服器在同一個網路中，互聯網的客戶端訪問負載均衡的虛IP（VIP），虛IP對應負載均衡機的WAN口，負載均衡根據策略將流量分發到伺服器上，伺服器直接響應客戶端的請求。因此對於客戶端而言，響應他的IP不是負載均衡機的虛IP（VIP），而是伺服器自身的IP地址。也就是說返回的流量是不經過負載均衡的。因此這種方式適用大流量高帶寬要求的服務。

⑶ 負載均衡是怎麼做的~

1、服務直接返回：這種安裝方式負載均衡的LAN口不使用，WAN口與伺服器在同一個網路中，互聯網的客戶端訪問負載均衡的虛IP（VIP），虛IP對應負載均衡機的WAN口，負載均衡根據策略將流量分發到伺服器上，伺服器直接響應客戶端的請求。

2、橋接模式：橋接模式配置簡單，不改變現有網路。負載均衡的WAN口和LAN口分別連接上行設備和下行伺服器。LAN口不需要配置IP（WAN口與LAN口是橋連接），所有的伺服器與負載均衡均在同一邏輯網路中。

3、路由模式：路由模式的部署方式，伺服器的網關必須設置成負載均衡機的LAN口地址，且與WAN口分署不同的邏輯網路。因此所有返回的流量也都經過負載均衡。這種方式對網路的改動小，能均衡任何下行流量。

(3)均衡負載伺服器部署什麼地方擴展閱讀

負載均衡的演算法:

1、隨機演算法：Random隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

2、哈希演算法：一致性哈希一致性Hash，相同參數的請求總是發到同一提供者。當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

3、URL散列：通過管理客戶端請求URL信息的散列，將發送至相同URL的請求轉發至同一伺服器的演算法。

參考資料

網路-負載均衡

⑷ 如何安裝nginx負載均衡配置詳解

負載均衡
先來簡單了解一下什麼是負載均衡，單從字面上的意思來理解就可以解釋N台伺服器平均分擔負載，不會因為某台伺服器負載高宕機而某台伺服器閑置的情況。那麼負載均衡的前提就是要有多台伺服器才能實現，也就是兩台以上即可。
測試環境
由於沒有伺服器，所以本次測試直接host指定域名，然後在VMware里安裝了三台CentOS。
測試域名 ：a.com
A伺服器IP ：192.168.5.149 （主）
B伺服器IP ：192.168.5.27
C伺服器IP ：192.168.5.126
部署思路
A伺服器做為主伺服器，域名直接解析到A伺服器（192.168.5.149）上，由A伺服器負載均衡到B伺服器（192.168.5.27）與C伺服器（192.168.5.126）上。

域名解析
由於不是真實環境，域名就隨便使用一個a.com用作測試，所以a.com的解析只能在hosts文件設置。
打開：C:
在末尾添加
192.168.5.149 a.com
保存退出，然後啟動命令模式ping下看看是否已設置成功

從截圖上看已成功將a.com解析到192.168.5.149IP
A伺服器nginx.conf設置
打開nginx.conf，文件位置在nginx安裝目錄的conf目錄下。
在http段加入以下代碼
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
}

server{
listen 80;
server_name a.com;
location / {
proxy_pass http://a.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重啟nginx
B、C伺服器nginx.conf設置
打開nginx.confi，在http段加入以下代碼
server{
listen 80;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
保存重啟nginx
測試
當訪問a.com的時候，為了區分是轉向哪台伺服器處理我分別在B、C伺服器下寫一個不同內容的index.html文件，以作區分。
打開瀏覽器訪問a.com結果，刷新會發現所有的請求均分別被主伺服器（192.168.5.149）分配到B伺服器（192.168.5.27）與C伺服器（192.168.5.126）上，實現了負載均衡效果。
B伺服器處理頁面

C伺服器處理頁面

假如其中一台伺服器宕機會怎樣？
當某台伺服器宕機了，是否會影響訪問呢？
我們先來看看實例，根據以上例子，假設C伺服器192.168.5.126這台機子宕機了（由於無法模擬宕機，所以我就把C伺服器關機）然後再來訪問看看。
訪問結果：

我們發現，雖然C伺服器（192.168.5.126）宕機了，但不影響網站訪問。這樣，就不會擔心在負載均衡模式下因為某台機子宕機而拖累整個站點了。
如果b.com也要設置負載均衡怎麼辦？
很簡單，跟a.com設置一樣。如下：
假設b.com的主伺服器IP是192.168.5.149，負載均衡到192.168.5.150和192.168.5.151機器上
現將域名b.com解析到192.168.5.149IP上。
在主伺服器(192.168.5.149)的nginx.conf加入以下代碼：
upstream b.com {
server 192.168.5.150:80;
server 192.168.5.151:80;
}

server{
listen 80;
server_name b.com;
location / {
proxy_pass http://b.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重啟nginx
在192.168.5.150與192.168.5.151機器上設置nginx，打開nginx.conf在末尾添加以下代碼：
server{
listen 80;
server_name b.com;
index index.html;
root /data0/htdocs/www;
}
保存重啟nginx
完成以後步驟後即可實現b.com的負載均衡配置。
主伺服器不能提供服務嗎？
以上例子中，我們都是應用到了主伺服器負載均衡到其它伺服器上，那麼主伺服器本身能不能也加在伺服器列表中，這樣就不會白白浪費拿一台伺服器純當做轉發功能，而是也參與到提供服務中來。
如以上案例三台伺服器：
A伺服器IP ：192.168.5.149 （主）
B伺服器IP ：192.168.5.27
C伺服器IP ：192.168.5.126
我們把域名解析到A伺服器，然後由A伺服器轉發到B伺服器與C伺服器，那麼A伺服器只做一個轉發功能，現在我們讓A伺服器也提供站點服務。
我們先來分析一下，如果添加主伺服器到upstream中，那麼可能會有以下兩種情況發生：
1、主伺服器轉發到了其它IP上，其它IP伺服器正常處理；
2、主伺服器轉發到了自己IP上，然後又進到主伺服器分配IP那裡，假如一直分配到本機，則會造成一個死循環。
怎麼解決這個問題呢？因為80埠已經用來監聽負載均衡的處理，那麼本伺服器上就不能再使用80埠來處理a.com的訪問請求，得用一個新的。於是我們把主伺服器的nginx.conf加入以下一段代碼：
server{
listen 8080;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}

重啟nginx，在瀏覽器輸入a.com:8080試試看能不能訪問。結果可以正常訪問

既然能正常訪問，那麼我們就可以把主伺服器添加到upstream中，但是埠要改一下，如下代碼：
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
server 127.0.0.1:8080;
}
由於這里可以添加主伺服器IP192.168.5.149或者127.0.0.1均可以，都表示訪問自己。
重啟Nginx，然後再來訪問a.com看看會不會分配到主伺服器上。

⑸ 負載均衡基本介紹

【負載均衡架構部分轉自】 58沈劍 [架構師之路]( https://mp.weixin.qq.com/s

負載均衡： 是分布式系統架構設計中必須考慮的因素之一，它通常是指，將請求/數據【均勻】分攤到多個操作單元上執行，負載均衡的關鍵在於【均勻】
常見的負載均衡方案：

【客戶端層】到【反向代理層】的負載均衡，是通過「DNS輪詢」實現的：DNS-server對於一個域名配置了多個解析ip，每次DNS解析請求來訪問DNS-server，會輪詢返回這些ip，保證每個ip的解析概率是相同的。這些ip就是nginx的外網ip，以做到每台nginx的請求分配也是均衡的。

【反向代理層】到【站點層】的負載均衡，是通過「nginx」實現的。通過修改nginx.conf，可以實現多種負載均衡策略：

【站點層】到【服務層】的負載均衡，是通過「服務連接池」實現的。
上游連接池會建立與下游服務多個連接，每次請求會「隨機」選取連接來訪問下游服務。（也即是rpc框架實現的）

在數據量很大的情況下，由於數據層（db，cache）涉及數據的水平切分，所以數據層的負載均衡更為復雜一些，它分為「數據的均衡」，與「請求的均衡」。
數據的均衡是指 ：水平切分後的每個服務（db，cache），數據量是差不多的。
請求的均衡是指 ：水平切分後的每個服務（db，cache），請求量是差不多的。
（1）按照range水平切分

（2）按照id哈希水平切分

[圖片上傳中...(-6b2508-1561902875888-0)]

常見的負載均衡系統包括 3 種：DNS 負載均衡、硬體負載均衡和軟體負載均衡。

硬體負載均衡是通過單獨的硬體設備來實現負載均衡功能，這類設備和路由器、交換機類似，可以理解為一個用於負載均衡的基礎網路設備。比如業界非常出名的F5

缺點：
（1）價格實在非常昂貴
（2）擴展性不強

軟體負載均衡通過負載均衡軟體來實現負載均衡功能，常見的有 Nginx 和 LVS。

nginx和F5： https://blog.csdn.net/chabale/article/details/8956717
nginx和lvs比較： https://blog.51cto.com/hzcto/2086691
lvs： https://www.cnblogs.com/liwei0526vip/p/6370103.html
ELB： https://aws.amazon.com/cn/elasticloadbalancing/
SLB： https://help.aliyun.com/proct/27537.html

題目：日活躍用戶 1000 萬的論壇的負載均衡集群，該如何設計呢？
（1）評估流量
1000萬DAU，換算成秒級（一天12小時），平均約等於232。
考慮每個用戶操作次數，假定10，換算成平均QPS=2320。
考慮峰值是均值倍數，假定5，換算成峰值QPS=11600。
考慮靜態資源、圖片資源、服務拆分等，流量放大效應，假定10，QPS 10=116000。
（2）容量規劃
考慮高可用、異地多活，QPS 2=232000。
考慮未來半年增長，QPS*1.5=348000。
（3）方案設計
可以用三級導流：
第一級，DNS，確定機房，以目前量級，可以不考慮。
第二級，確定集群，擴展優先，則選Haproxy/LVS，穩定優先則選F5。
第三級，Nginx+KeepAlived，確定實例。
（4）架構圖

接入層技術：

缺點：

優點：

缺點：

優點：

缺點：

缺點：

nginx畢竟是軟體，性能比tomcat好，但總有個上限，超出了上限，還是扛不住。lvs就不一樣了，它實施在操作系統層面；f5的性能又更好了，它實施在硬體層面；它們性能比nginx好很多，例如每秒可以抗10w，這樣可以利用他們來擴容。

99.9999%的公司到這一步基本就能解決接入層高可用、擴展性、負載均衡的問題。 假設還扛不住的話，就要考慮使用硬體設備f5等。如果還是扛不住，那麼只有DNS來擴容了。

水平擴展，才是解決性能問題的根本方案，能夠通過加機器擴充性能的方案才具備最好的擴展性。 facebook，google，的PV是不是超過80億呢，它們的域名只對應一個ip么，終點又是起點，還是得通過DNS輪詢來進行擴容：

比如購買了阿里雲或者aws。那麼基本會使用雲廠商提供的負載均衡中間件，比如aws（elb）、阿里雲（slb）。這個負載均衡軟體可以認為是 lvs+keepalived的高可用負載均衡服務

後端的service有可能部署在硬體條件不同的伺服器上：
1）如果對標最低配的伺服器「均勻」分攤負載，高配的伺服器的利用率不足；
2）如果對標最高配的伺服器「均勻」分攤負載，低配的伺服器可能會扛不住；

（1）通過「靜態權重」標識service的處理能力

優點： 簡單，能夠快速的實現異構伺服器的負載均衡。
缺點： 權重是固定的，無法自適應動態調整，而很多時候，伺服器的處理能力是很難用一個固定的數值量化。

（2）通過「動態權重」標識service的處理能力
提問：通過什麼來標識一個service的處理能力呢？
回答：其實一個service能不能處理得過來，能不能響應得過來，應該由調用方說了算。調用服務，快速處理了，處理能力跟得上；調用服務，處理超時了，處理能力很有可能跟不上了。

動態權重設計：

例如：

（1）設置一個閾值，超過閾值直接丟棄

（2）藉助「動態權重」來實施過載保護
案例策略：

1）service的負載均衡、故障轉移、超時處理通常是RPC-client連接池層面來實施的
2）異構伺服器負載均衡，最簡單的方式是靜態權重法，缺點是無法自適應動態調整
3）動態權重法，可以動態的根據service的處理能力來分配負載，需要有連接池層面的微小改動
4）過載保護，是在負載過高時，service為了保護自己，保證一定處理能力的一種自救方法
5）動態權重法，還可以用做service的過載保護