❶ 如何在ubuntu14.0下為WordPress應用伺服器搭建四層負載均衡
當前環境快照
可選：在繼續本教程之前，你可能想為你當前環境創建快照。本教程中快照有兩個目的：
如果發生錯誤可以回滾到可工作環境
對原始伺服器做一次性復制，而不需要再次安裝和配置PHP以及Nginx
注意：為環境創建快照需要短暫的關閉VPS
為wordpress-1和mysql-1兩個VPS做一個快照。
現在有了快照以後，我們就可以准備好繼續搭建環境中其他部分了。
創建第二台web應用伺服器
現在我們需要創建第二個VPS來分擔原始應用伺服器的負載。有兩種選擇：
從之前的快照wordpress-1中創建一個新的VPS
從頭開始重新創建一個VPS並且設置該VPS和wordpress-1有相同的軟體和配置
不論那種方法，如果網路可用，一定要確保勾選個人網路。個人網路是本教程中所有VPS都需要的。
如果沒有個人網路選項，用你的VPS的公開IP來替代內網IP。需要注意的是，當使用公網IP在應用伺服器和資料庫伺服器之間傳輸敏感數據比如非加密的資料庫密碼，並不是一個很好的選擇，因為這些信息需要在互聯網上傳輸。
方式一：使用快照創建新的VPS
創建一個新的VPS，叫做wordpress-2,使用你為wordpress-1做的快照來做。
如果你選擇的這種方式，可以跳過「方式二」直接去看「同步web應用文件」小節。
方式二：從頭創建一個新的VPS
這種方式和「方式一」可二選一。
如果你想從頭設置wordpress-2伺服器，而不是使用wordpress-1的快照，那麼你要確保安裝的軟體相同。如果你忘了如何安裝和設置原始wordpress伺服器，可以參考預備知識章節中如何設置web伺服器小節。
快速參考,這里是一個相關軟體和配置文件的列表,需要你來安裝或復制：
軟體方面：
Mysql客戶端
Nginx
PHP
安裝完這些軟體後，在你的wordpress-2伺服器上運行一下命令：
sudo apt-get update
sudo apt-get install mysql-client
sudo apt-get install nginx php5-fpm php5-mysql
原始應用伺服器上需要創建或編輯的配置文件：
/etc/php5/fpm/php.ini
/etc/php5/fpm/pool.d/www.conf
/etc/nginx/sites-available/example.com
/etc/nginx/sites-enabled/example.com
當你修改完配置文件後，不要忘了沖洗PHP和Nginx，可以使用一下命令：
sudo service php5-fpm restart
sudo service nginx restart
在新伺服器的安裝和配置完成以後，我們需要同步wordpress應用文件。
同步Web應用文件
在應用程序可以進行負載均衡之前，我們需要確保新應用伺服器的應用程序文件和原始wordpress伺服器的文件是同步的。這些文件的位置也就是你安裝wordpress的位置，以及其他的一些文件。除了wordpress運行所需要的配置文件之外，上傳的文件和通過wordpress介面安裝的插件的安裝文件和這些插件上傳的文件都需要去同步。在預備知識文章中，我們將wordpress安裝在/var/www/example.com路徑下--我們將
在所有的例子中都會使用這個路徑，但是你需要將這個路徑替換為你wordpress的實際安裝路徑。
有很多方法在伺服器之間同步文件--NFS或者glusterFS都是不錯的選擇。我們將使用glusterFS來滿足我們所有的同步需求，因為它允許每個應用伺服器來存儲應用程序文件的副本，同時也會保持文件系統的一致性。下圖是我們共享存儲方案的概念圖：
如果你對本小節中使用的glusterFS完全不熟悉，請參考這個GlusterFS教程（https://www.digitalocean.com/community/tutorials/how-to-create-a-rendant-storage-pool-using-glusterfs-on-ubuntu-servers），這是本小節的基礎。
注意：下面的內容將經常在wordpress-1和wordpress-2伺服器之間跳轉，請確保在正確伺服器上運行響應命令，否則你將遇到麻煩。
編輯hosts文件
如果你有一個內部DNS，而且這個DNS記錄了你VPS的內部IP地址，那麼你可以跳過這一步直接配置並執行glusterFS相關命令。
否則，需要在wordpress-1和wordpress-2上編輯/etc/hosts文件：
sudo vi /etc/hosts
增加以下兩行，將紅色字替換為你應用伺服器的各自ip：
wordpress_1_private_IP wordpress-1
wordpress_2_private_IP wordpress-2
保存並退出。
安裝GlusterFS並配置一個冗餘盤
在wordpress-1和wordpress-2上使用apt-get命令安裝glusterFS服務端軟體：
sudo apt-get install glusterfs-server
在wordpress-1上，運行以下命令來和wordpress-2保持對等：
sudo gluster peer probe wordpress-2
在wordpress-2上，運行以下命令來和wordpress-1保持對等：
sudo gluster peer probe wordpress-1
在wordpress-1和wordpress-2上，創建路徑用來存儲glusterFS所管理的文件，運行：
sudo mkdir /gluster-storage
在wordpress-1上，創建glusterFS副本，我們稱作volume1,glusterFS 會將它存放在/gluster-storage中的數據保存在你所有的應用伺服器上，運行：
sudo gluster volume create volume1 replica 2 transport tcp wordpress-1:/gluster-storage wordpress-2:/gluster-storage force
預期輸出以下結果：
volume create: volume1: success: please start the volume to access data
再次在wordpress-1上，運行一下命令來啟動剛剛創建的glusterFS卷，在volume1上運行：
sudo gluster volume start volume1
預期輸出以下結果：
volume start: volume1: success
在wordpress-1上，如果你想查看剛創建和啟動的glusterFS卷的信息，運行：
sudo gluster volume info
你需要明白的是目前有兩個glusterFS「同盟」，每個對應一個wordpress伺服器。
現在我們已經運行了一個glusterFS盤，為了能夠使用它來同步文件，我們需要將該盤掛載。
掛載共享存儲
首先掛載wordpress-1上的文件系統。
在wordpress-1上，修改fstab文件來使共享文件系統可以隨機啟動：
sudo vi /etc/fstab
添加以下行到fstab來將/storage-pool目錄作為掛載點：
wordpress-1:/volume1 /storage-pool glusterfs defaults,_netdev 0 0
保存並退出。
在wordpress-1上，現在將glusterFS盤掛載至/storage_pool文件系統：
sudo mkdir /storage-pool
sudo mount /storage-pool
在wordpress-1上掛載共享盤/storage-pool後，你可以運行df -h命令來列出當前已掛載的文件。接下來，我們將使用類似的流程來掛載wordpress-2上的共享文件系統。
在wordpress-2上，編輯fstab來使共享系統隨機啟動：
sudo vi /etc/fstab
添加以下行到fstab來將/storage-pool目錄作為掛載點：
wordpress-2:/volume1 /storage-pool glusterfs defaults,_netdev 0 0
在wordpress-2上，現在將glusterFS盤掛載至/storage_pool文件系統：
sudo mkdir /storage-pool
sudo mount /storage-pool
現在，所有在/storage-pool文件系統中創建、修改或刪除的文件都會在兩個wordpress伺服器之間同步，即使當其中一個伺服器暫時故障時也會同步。
將wordpress文件移至共享存儲
下一步是將wordpress-1的wordpress文件移動到共享存儲中。請將紅色字體替換為你自己的值。/var/www/example.com表示wordpress文件的位置(nginx也會在這里查找文件)，example.com本身只是根目錄。
在wordpress-1上，運行以下命令來移動wordpress文件至共享文件系統/storage-pool:
sudo mv /var/www/example.com /storage-pool/
sudo chown www-data:www-data /storage-pool/example.com
接下來，你可能想創建一個符號鏈接來指向wordpress在共享文件中位置：
sudo ln -s /storage-pool/example.com /var/www/example.com
目前wordpress文件放在共享文件系統/storage-pool中，這些文件接受Nginx訪問他們的原始路徑/var/www/example.com。
將新的應用伺服器指向共享存儲區
下一步是我們在新web應用程序伺服器上創建一個符號鏈接指向WordPress文件共享文件系統。
如果你選擇使用快照創建wordpress-2，在wordpress-2上運行以下命令：
sudo rm /var/www/example.com
sudo ln -s /storage-pool/example.com /var/www/example.com
如果你從頭創建wordpress-2伺服器，在wordpress-2上運行以下命令：
sudo mkdir -p/var/www
sudo ln -s/storage-pool/example.com /var/www/example.com
這就是wordpress應用的文件同步。接下來是使新伺服器wordpress-2連接資料庫。
創建一個新的資料庫用戶
由於Mysql使用用戶名和源主機來區別用戶，我們需要創建一個新的wordpress用戶來連接新的伺服器wordpress-2。
在資料庫伺服器（mysql-1）上連接至MYSQL控制台：
mysql -u root -p
在一下mysql語句中，將紅色字體替換為你真實環境的參數：
wordpress用戶：Mysql中wordpress用戶。確保和已經存在的用戶名保持一致。
wordpress2private_IP：wordpress-2伺服器的內部ip。
密碼：wordpress用戶的Mysql資料庫密碼。去報和已經存在的用戶名密碼保持一致。
在wordpress-2上mysql控制台中運行以下命令：
CREATE USER 'wordpressuser'@'wordpress_2_private_IP' IDENTIFIED BY 'password';
GRANT SELECT,DELETE,INSERT,UPDATE ON wordpress.* TO 'wordpressuser'@'wordpress_2_private_IP';
FLUSH PRIVILEGES;
現在第二台伺服器wordpress-2就可以登錄mysql伺服器mysql-1了。
還沒負載均衡
注意，有兩個應用伺服器在運行但是他們並沒有被負載均衡，因為每個伺服器必須通過他們的外網IP來訪問。而我們希望能夠通過相同的URL訪問該應用程序，如http://example.com/，以及在兩台伺服器之間做流量分配。
安裝HAProxy
在內網中創建一個新的VPS，在本教程中，我們叫做haproxy-www。
在haproxy-www伺服器上使用apt-get命令來安裝HAProxy:
sudo apt-get update
sudo apt-get install haproxy
我們需要使用HAProxy初始化腳本來啟動和停止HAProxy：
sudo vi /etc/default/haproxy
將ENABLED值改為1來開啟初始化腳本：
ENABLED=1
保存並退出。
現在HAProxy可以在伺服器上被啟動和停止。當然，你現在可以使用命令來控制HAProxy了。讓我們來檢查下它是否運行：
/etc/init.d$ sudo service haproxy status
輸出結果：
haproxy not running
HAProxy沒有運行。這是對的，因為它首先需要配置。接下來，讓我們來配置HAProxy。
HAProxy配置
HAProxy的配置文件主要分為以下兩部分：
Global:設置進程級參數
Proxies:包括默認、監聽、前端、後端參數
Global配置
所有的HAProxy配置都需要在HAProxy伺服器haproxy-www上進行。
首先，復制一份默認的haproxy.cfg文件：
cd /etc/haproxy; sudo cp haproxy.cfg haproxy.cfg.orig
現在，使用文本編輯器打開haproxy.cfg文件：
sudo vi /etc/haproxy/haproxy.cfg
你將看到有兩部分已經被定義：global和defaults。首先,我們將對一些默認參數做一些修改。
在默認情況下，找到一下兩行：
mode http
option httplog
將其中http替換為tcp,結果如下：
mode tcp
option tcplog
選擇tcp作為HAProxy執行第4層負載平衡模式配置。在我們的例子中,這意味著一個特定的IP地址和埠中所有傳入的流量將被轉發到同一後端。如果你不熟悉這一概念,請閱讀在HAProxy介紹中的負載均衡小節。
先不要關閉配置文件，我們將加上proxy配置。
代理配置（Proxyies）
我們首先要做的事情是增加前端。對一個基本的4層負載均衡設置，前端監聽一個特定的IP地址和埠的流量，並將傳入流量轉發到一個指定的後端。
在配置文件的末尾，讓我們添加上我們的前端：www。請將haproxy_www_public_IP替換為你自己的haproxy-www伺服器IP地址：
frontend www
bind haproxy_www_public_IP:80
default_backend wordpress-backend
以下是對上面的前端配置代碼片段中的每一行是什麼意思做出解釋：
frontend www：指定了一個名為「www」的前端,我們將用它來處理傳入www的流量
bind haproxywwwpublic_IP:80：將haproxywwwpublic_IP替換為你haproxy-www伺服器的外網ip。這是告訴haproxy這個前端將處理這個ip和埠上的流量。
default_backend wordpress-backend：這指定所有這些前端的流量將會轉發到wordpress-backend,這在下一步我們將定義
配置完前端後，繼續將以下後端配置加入文件末尾：
backend wordpress-backend
balance roundrobin
mode tcp
server wordpress-1 wordpress_1_private_IP:80 check
server wordpress-2 wordpress_2_private_IP:80 check
以下是對上面每行配置的解釋：
backend wordpress-backend：指定了一個名為「wordpress-backend」的後端
balance roundrobin：指定該後端將使用「輪循」的負載均衡演算法
server wordpress-1 ...：指定了一個名為「wordpress-1」的後端伺服器,內外nagIP(你必須替換為你自己伺服器ip)和埠監聽,在這個例子中為80埠。「check」選項表示使負載均衡器對這個伺服器定期進行健康檢查
server wordpress-2 ...：指定了一個名為「wordpress-2」的後端
保存並退出。
現在HAProxy可以啟動了，但是讓我們先開啟日誌功能。
開始HAProxy日誌功能
啟用HAproxy日誌功能非常簡單，首先編輯rsyslog.conf文件：
sudo vi /etc/rsyslog.conf
接著找到一下兩行，取消這兩行注釋來開啟UDP日誌功能：
$ModLoad imudp
$UDPServerRun 514
$UDPServerAddress 127.0.0.1
現在重啟rsyslog來使新配置生效：
sudo service rsyslog restart
HAProxy日誌功能現在已經開啟了！日誌文件將在HAProxy啟動後被放在/var/log/haproxy.log。
啟動HAProxy和PHP/Nginx
在haproxy-www伺服器上，啟動HAProxy來使配置生效：
sudo service haproxy restart
取決於你如何設置您的新應用程序伺服器,您可能需要重新啟動你的WordPress應用程序通過重啟PHP和Nginx。
在wordpress-2伺服器上，重啟PHP和Nginx：
sudo service php5-fpm restart
sudo service nginx restart
現在WordPress應該運行在兩個應用程序伺服器,它們是負載均衡的。但仍有最後一個配置需要更改。
更新WordPress配置
現在你的WordPress應用程序的URL已經改變,我們必須在WordPress更新幾個設置。
在wordpress伺服器,編輯你的wp-config.php文件。它位於WordPress的安裝位置(在本教程中,它是安裝在/var/www/example.com但你安裝可能會有所不同)：
cd /var/www/example.com; sudo vi wp-config.php
找到"DB_NAME"所在行；增加以下配置在該行之上，並且替換紅色的值：
define('WP_SITEURL', 'http://haproxy_www_public_IP');
define('WP_HOME', 'http://haproxy_www_public_IP');
保存並退出。
現在WordPress url配置為指向您的負載平衡器,而不是只有最初的WordPress伺服器,而且在當你試著訪問wp-admin控制台時發揮作用。
負載均衡完成
您的web應用程序伺服器現在是負載均衡的。你的負載平衡WordPress現在可以訪問您的用戶通過負載均衡器haproxy-www的外網IP地址或域名訪問!
❷ 負載均衡是怎麼做的~
1、服務直接返回：這種安裝方式負載均衡的LAN口不使用，WAN口與伺服器在同一個網路中，互聯網的客戶端訪問負載均衡的虛IP（VIP），虛IP對應負載均衡機的WAN口，負載均衡根據策略將流量分發到伺服器上，伺服器直接響應客戶端的請求。
2、橋接模式：橋接模式配置簡單，不改變現有網路。負載均衡的WAN口和LAN口分別連接上行設備和下行伺服器。LAN口不需要配置IP（WAN口與LAN口是橋連接），所有的伺服器與負載均衡均在同一邏輯網路中。
3、路由模式：路由模式的部署方式，伺服器的網關必須設置成負載均衡機的LAN口地址，且與WAN口分署不同的邏輯網路。因此所有返回的流量也都經過負載均衡。這種方式對網路的改動小，能均衡任何下行流量。
(2)負載均衡四層怎麼配置擴展閱讀
負載均衡的演算法:
1、隨機演算法：Random隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。
2、哈希演算法：一致性哈希一致性Hash，相同參數的請求總是發到同一提供者。當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
3、URL散列：通過管理客戶端請求URL信息的散列，將發送至相同URL的請求轉發至同一伺服器的演算法。
參考資料
網路-負載均衡
❸ 如何配置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 已經在正常工作了。
❹ 負載均衡四層和七層的區別
簡單理解四層和七層負載均衡:
① 所謂四層就是基於IP+埠的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；四層通過虛擬IP+埠接收請求，然後再分配到真實的伺服器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的伺服器。
② 所謂的四到七層負載均衡，就是在對後台的伺服器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。 比如四層的負載均衡，就是通過發布三層的IP地址（VIP），然後加四層的埠號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至後台伺服器，並記錄下這個TCP或者UDP的流量是由哪台伺服器處理的，後續這個連接的所有流量都同樣轉發到同一台伺服器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web伺服器的負載均衡，除了根據VIP加80埠辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web伺服器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然後選擇對應的語言伺服器組進行負載均衡處理。
③ 負載均衡器通常稱為四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
1、負載均衡分為L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
2、另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balancer能理解應用協議。例子： haproxy，MySQL Proxy。
注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。
❺ 如何配置nginx四層負載均衡
網路下教程很多，推薦去51CTO看看有沒有老師講的視頻
❻ 怎樣配置負載均衡
可以用軟體或加台磁碟陣列櫃，主要還要看你跑的是什麼任務，是WEB還是資料庫
❼ 四層負載均衡和七層負載均衡的區別
（一）
簡單理解四層和七層負載均衡:
① 所謂四層就是基於IP+埠的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；四層通過虛擬IP+埠接收請求，然後再分配到真實的伺服器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的伺服器。
② 所謂的四到七層負載均衡，就是在對後台的伺服器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。 比如四層的負載均衡，就是通過發布三層的IP地址（VIP），然後加四層的埠號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至後台伺服器，並記錄下這個TCP或者UDP的流量是由哪台伺服器處理的，後續這個連接的所有流量都同樣轉發到同一台伺服器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web伺服器的負載均衡，除了根據VIP加80埠辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web伺服器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然後選擇對應的語言伺服器組進行負載均衡處理。
③ 負載均衡器通常稱為四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
1、負載均衡分為L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
2、另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balancer能理解應用協議。例子： haproxy，MySQL Proxy。
注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。
（二）
負載均衡設備也常被稱為"四到七層交換機"，那麼四層和七層兩者到底區別在哪裡？
第一，技術原理上的區別。
所謂四層負載均衡，也就是主要通過報文中的目標地址和埠，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的伺服器，並對報文中目標IP地址進行修改(改為後端伺服器IP），直接轉發給該伺服器。TCP的連接建立，即三次握手是客戶端和伺服器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，為保證伺服器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。
所謂七層負載均衡，也稱為「內容交換」，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備如果要根據真正的應用層內容再選擇伺服器，只能先代理最終的伺服器和客戶端建立連接(三次握手)後，才可能接受到客戶端發送的真正應用層內容的報文，然後再根據該報文中的特定欄位，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。負載均衡設備在這種情況下，更類似於一個代理伺服器。負載均衡和前端的客戶端以及後端的伺服器會分別建立TCP連接。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。
第二，應用場景的需求。
七層應用負載的好處，是使得整個網路更"智能化"。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片伺服器並可以使用緩存技術；將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性。很多在後台，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫，伺服器響應中的關鍵字過濾或者內容插入等功能。
另外一個常常被提到功能就是安全性。網路中最常見的SYN Flood攻擊，即黑客控制眾多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，通常這種攻擊會大量發送SYN報文，耗盡伺服器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而七層模式下這些SYN攻擊自然在負載均衡設備上就截止，不會影響後台伺服器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。
現在的7層負載均衡，主要還是著重於應用HTTP協議，所以其應用范圍主要是眾多的網站或者內部信息平台等基於B/S開發的系統。 4層負載均衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。
第三，七層應用需要考慮的問題。
1：是否真的必要，七層應用的確可以提高流量智能化，同時必不可免的帶來設備配置復雜，負載均衡壓力增高以及故障排查上的復雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
2：是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的確將這些流量從伺服器屏蔽，但負載均衡設備本身要有強大的抗DDoS能力，否則即使伺服器正常而作為中樞調度的負載均衡設備故障也會導致整個應用的崩潰。
3：是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智能化，但是負載均衡設備需要提供完善的七層功能，滿足客戶根據不同情況的基於應用的調度。最簡單的一個考核就是能否取代後台Nginx或者Apache等伺服器上的調度功能。能夠提供一個七層應用開發介面的負載均衡設備，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。
（三）
負載均衡四七層介紹:
負載均衡（Load Balance）建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性。
負載均衡有兩方面的含義：首先，大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。
本文所要介紹的負載均衡技術主要是指在均衡伺服器群中所有伺服器和應用程序之間流量負載的應用，目前負載均衡技術大多數是用於提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程序的可用性和可伸縮性。
負載均衡技術分類
目前有許多不同的負載均衡技術用以滿足不同的應用需求，下面從負載均衡所採用的設備對象、應用的網路層次（指OSI參考模型）及應用的地理結構等來分類。
軟/硬體負載均衡
軟體負載均衡解決方案是指在一台或多台伺服器相應的操作系統上安裝一個或多個附加軟體來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
軟體解決方案缺點也較多，因為每台伺服器上安裝額外的軟體運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，所以當連接請求特別大的時候，軟體本身會成為伺服器工作成敗的一個關鍵；軟體可擴展性並不是很好，受到操作系統的限制；由於操作系統本身的Bug，往往會引起安全問題。
硬體負載均衡解決方案是直接在伺服器和外部網路間安裝負載均衡設備，這種設備我們通常稱之為負載均衡器，由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於伺服器與Internet鏈接之間，有些則以兩塊網路適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到後端伺服器群的內部網路上。
一般而言，硬體負載均衡在功能、性能上優於軟體方式，不過成本昂貴。
本地/全局負載均衡
負載均衡從其應用的地理結構上分為本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)，本地負載均衡是指對本地的伺服器群做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網路結構的伺服器群間作負載均衡。
本地負載均衡能有效地解決數據流量過大、網路負荷過重的問題，並且不需花費昂貴開支購置性能卓越的伺服器，充分利用現有設備，避免伺服器單點故障造成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給伺服器群內的伺服器共同負擔。即使是再給現有伺服器擴充升級，也只是簡單地增加一個新的伺服器到服務群中，而不需改變現有網路結構、停止現有的服務。
全局負載均衡主要用於在一個多區域擁有自己伺服器的站點，為了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的伺服器，從而獲得最快的訪問速度，也可用於子公司分散站點分布廣的大公司通過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。
網路層次上的負載均衡
針對網路上負載過重的不同瓶頸所在，從網路的不同層次入手，我們可以採用相應的負載均衡技術來解決現有問題。
隨著帶寬增加，數據流量不斷增大，網路核心部分的數據介面將面臨瓶頸問題，原有的單一線路將很難滿足需求，而且線路的升級又過於昂貴甚至難以實現，這時就可以考慮採用鏈路聚合（Trunking）技術。
鏈路聚合技術（第二層負載均衡）將多條物理鏈路當作一條單一的聚合邏輯鏈路使用，網路數據流量由聚合邏輯鏈路中所有物理鏈路共同承擔，由此在邏輯上增大了鏈路的容量，使其能滿足帶寬增加的需求。
現代負載均衡技術通常操作於網路的第四層或第七層。第四層負載均衡將一個Internet上合法注冊的IP地址映射為多個內部伺服器的IP地址，對每次 TCP連接請求動態使用其中一個內部IP地址，達到負載均衡的目的。在第四層交換機中，此種均衡技術得到廣泛的應用，一個目標地址是伺服器群VIP（虛擬 IP，Virtual IP address）連接請求的數據包流經交換機，交換機根據源端和目的IP地址、TCP或UDP埠號和一定的負載均衡策略，在伺服器IP和VIP間進行映射，選取伺服器群中最好的伺服器來處理連接請求。
第七層負載均衡控制應用層服務的內容，提供了一種對訪問流量的高層控制方式，適合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。
第七層負載均衡優點表現在如下幾個方面：
通過對HTTP報頭的檢查，可以檢測出HTTP400、500和600系列的錯誤信息，因而能透明地將連接請求重新定向到另一台伺服器，避免應用層故障。
可根據流經的數據類型（如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的伺服器來處理，增加系統性能。
能根據連接請求的類型，如是普通文本、圖象等靜態文檔請求，還是asp、cgi等的動態文檔請求，把相應的請求引向相應的伺服器來處理，提高系統的性能及安全性。
第七層負載均衡受到其所支持的協議限制（一般只有HTTP），這樣就限制了它應用的廣泛性，並且檢查HTTP報頭會佔用大量的系統資源，勢必會影響到系統的性能，在大量連接請求的情況下，負載均衡設備自身容易成為網路整體性能的瓶頸。
負載均衡策略
在實際應用中，我們可能不想僅僅是把客戶端的服務請求平均地分配給內部伺服器，而不管伺服器是否宕機。而是想使Pentium III伺服器比Pentium II能接受更多的服務請求，一台處理服務請求較少的伺服器能分配到更多的服務請求，出現故障的伺服器將不再接受服務請求直至故障恢復等等。
選擇合適的負載均衡策略，使多個設備能很好的共同完成任務，消除或避免現有網路負載分布不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不同的應用需求，在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡策略。
負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡演算法，二、對網路系統狀況的檢測方式和能力。
考慮到服務請求的不同類型、伺服器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題，為了更加合理的把負載分配給內部的多個伺服器，就需要應用相應的能夠正確反映各個伺服器處理能力及網路狀態的負載均衡演算法：
輪循均衡（Round Robin）：每一次來自網路的請求輪流分配給內部中的伺服器，從1至N然後重新開始。此種均衡演算法適合於伺服器組中的所有伺服器都有相同的軟硬體配置並且平均服務請求相對均衡的情況。
權重輪循均衡（Weighted Round Robin）：根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：伺服器A的權值被設計成1，B的權值是 3，C的權值是6，則伺服器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡演算法能確保高性能的伺服器得到更多的使用率，避免低性能的伺服器負載過重。
隨機均衡（Random）：把來自網路的請求隨機分配給內部中的多個伺服器。
權重隨機均衡（Weighted Random）：此種均衡演算法類似於權重輪循演算法，不過在處理請求分擔時是個隨機選擇的過程。
響應速度均衡（Response Time）：負載均衡設備對內部各伺服器發出一個探測請求（例如Ping），然後根據內部中各伺服器對探測請求的最快響應時間來決定哪一台伺服器來響應客戶端的服務請求。此種均衡演算法能較好的反映伺服器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與伺服器間的最快響應時間，而不是客戶端與伺服器間的最快響應時間。
最少連接數均衡（Least Connection）：客戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異，隨著工作時間加長，如果採用簡單的輪循或隨機均衡演算法，每一台伺服器上的連接進程可能會產生極大的不同，並沒有達到真正的負載均衡。最少連接數均衡演算法對內部中需負載的每一台伺服器都有一個數據記錄，記錄當前該伺服器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的伺服器，使均衡更加符合實際情況，負載更加均衡。此種均衡演算法適合長時處理的請求服務，如FTP。
處理能力均衡：此種均衡演算法將把服務請求分配給內部中處理負荷（根據伺服器CPU型號、CPU數量、內存大小及當前連接數等換算而成）最輕的伺服器，由於考慮到了內部伺服器的處理能力及當前網路運行狀況，所以此種均衡演算法相對來說更加精確，尤其適合運用到第七層（應用層）負載均衡的情況下。
DNS響應均衡（Flash DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到伺服器確切的IP地址的。在此均衡演算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應伺服器的IP地址（即與此負載均衡設備在同一位地理位置的伺服器的IP地址）並返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。
盡管有多種的負載均衡演算法可以較好的把數據流量分配給伺服器去負載，但如果負載均衡策略沒有對網路系統狀況的檢測方式和能力，一旦在某台伺服器或某段負載均衡設備與伺服器網路間出現故障的情況下，負載均衡設備依然把一部分數據流量引向那台伺服器，這勢必造成大量的服務請求被丟失，達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網路故障、伺服器系統故障、應用服務故障的檢測方式和能力：
Ping偵測：通過ping的方式檢測伺服器及網路系統狀況，此種方式簡單快速，但只能大致檢測出網路及伺服器上的操作系統是否正常，對伺服器上的應用服務檢測就無能為力了。
TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測伺服器上某個TCP埠（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。
HTTP URL偵測：比如向HTTP伺服器發出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為伺服器出現故障。
負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要將來自同一客戶端的所有請求都分配給同一台伺服器去負擔，例如伺服器將客戶端注冊、購物等服務請求信息保存的本地資料庫的情況下，把客戶端的子請求分配給同一台伺服器來處理就顯的至關重要了。有兩種方式可以解決此問題，一是根據IP地址把來自同一客戶端的多次請求分配給同一台伺服器處理，客戶端IP地址與伺服器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器 cookie內做獨一無二的標識來把多次請求分配給同一台伺服器處理，適合通過代理伺服器上網的客戶端。
還有一種路徑外返回模式（Out of Path Return），當客戶端連接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個伺服器，伺服器的回應請求不再返回給中心負載均衡設備，即繞過流量分配器，直接返回給客戶端，因此中心負載均衡設備只負責接受並轉發請求，其網路負擔就減少了很多，並且給客戶端提供了更快的響應時間。此種模式一般用於HTTP伺服器群，在各伺服器上要安裝一塊虛擬網路適配器，並將其IP地址設為伺服器群的VIP，這樣才能在伺服器直接回應客戶端請求時順利的達成三次握手。
負載均衡實施要素
負載均衡方案應是在網站建設初期就應考慮的問題，不過有時隨著訪問流量的爆炸性增長，超出決策者的意料，這也就成為不得不面對的問題。當我們在引入某種負載均衡方案乃至具體實施時，像其他的許多方案一樣，首先是確定當前及將來的應用需求，然後在代價與收效之間做出權衡。
針對當前及將來的應用需求，分析網路瓶頸的不同所在，我們就需要確立是採用哪一類的負載均衡技術，採用什麼樣的均衡策略，在可用性、兼容性、安全性等等方面要滿足多大的需求，如此等等。
不管負載均衡方案是採用花費較少的軟體方式，還是購買代價高昂在性能功能上更強的第四層交換機、負載均衡器等硬體方式來實現，亦或其他種類不同的均衡技術，下面這幾項都是我們在引入均衡方案時可能要考慮的問題：
性能：性能是我們在引入均衡方案時需要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鍾通過網路的數據包數目做為一個參數，另一個參數是均衡方案中伺服器群所能處理的最大並發連接數目，但是，假設一個均衡系統能處理百萬計的並發連接數，可是卻只能以每秒2個包的速率轉發，這顯然是沒有任何作用的。性能的優劣與負載均衡設備的處理能力、採用的均衡策略息息相關，並且有兩點需要注意：一、均衡方案對伺服器群整體的性能，這是響應客戶端連接請求速度的關鍵；二、負載均衡設備自身的性能，避免有大量連接請求時自身性能不足而成為服務瓶頸。有時我們也可以考慮採用混合型負載均衡策略來提升伺服器群的總體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜態文檔請求的站點，也可以考慮採用高速緩存技術，相對來說更節省費用，更能提高響應性能；對有大量ssl/xml內容傳輸的站點，更應考慮採用ssl/xml加速技術。
可擴展性：IT技術日新月異，一年以前最新的產品，現在或許已是網路中性能最低的產品；業務量的急速上升，一年前的網路，現在需要新一輪的擴展。合適的均衡解決方案應能滿足這些需求，能均衡不同操作系統和硬體平台之間的負載，能均衡HTTP、郵件、新聞、代理、資料庫、防火牆和 Cache等不同伺服器的負載，並且能以對客戶端完全透明的方式動態增加或刪除某些資源。
靈活性：均衡解決方案應能靈活地提供不同的應用需求，滿足應用需求的不斷變化。在不同的伺服器群有不同的應用需求時，應有多樣的均衡策略提供更廣泛的選擇。
可靠性：在對服務質量要求較高的站點，負載均衡解決方案應能為伺服器群提供完全的容錯性和高可用性。但在負載均衡設備自身出現故障時，應該有良好的冗餘解決方案，提高可靠性。使用冗餘時，處於同一個冗餘單元的多個負載均衡設備必須具有有效的方式以便互相進行監控，保護系統盡可能地避免遭受到重大故障的損失。
易管理性：不管是通過軟體還是硬體方式的均衡解決方案，我們都希望它有靈活、直觀和安全的管理方式，這樣便於安裝、配置、維護和監控，提高工作效率，避免差錯。在硬體負載均衡設備上，目前主要有三種管理方式可供選擇：一、命令行介面（CLI：Command Line Interface），可通過超級終端連接負載均衡設備串列介面來管理，也能telnet遠程登錄管理，在初始化配置時，往往要用到前者；二、圖形用戶介面（GUI：Graphical User Interfaces），有基於普通web頁的管理，也有通過Java Applet 進行安全管理，一般都需要管理端安裝有某個版本的瀏覽器；三、SNMP（Simple Network Management Protocol，簡單網路管理協議）支持，通過第三方網路管理軟體對符合SNMP標準的設備進行管理。
❽ 如何分清負載均衡四，七層應用場景需求
在網路優化的主流設備中，負載均衡常被稱為是"四七層交換機"，擔當著重要使命。盡管，負載均衡設備對於很多企業IT管理人員來說已經非常熟悉，但是在具體使用過程中，例如針對四層和七層應用等技術疑問，依然會誤+導部分用戶並產生應用誤區。 那麼，四層和七層兩者到底區別在哪裡？在應用中如何讓負載均衡設備更好地滿足應用場景的需求呢？對此，國內知名應用交付廠商太一星晨給予了詳細解讀。 第一.技術原理上的區別。 四層負載均衡，也就是主要通過報文中的目標地址和埠，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。 以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的伺服器，並對報文中目標IP地址改為後端伺服器IP，直接轉發給該伺服器。TCP的連接建立，即三次握手是客戶端和伺服器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。 七層負載均衡：也稱為「內容交換」，主要通過報文中真正有意義的應用層內容，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。 以常見的HTTP為例，負載均衡設備要根據真正的應用層內容再選擇伺服器，必須先代理實際伺服器和客戶端建立連接（三次握手）後，才可能接受到客戶端發送的真正應用層內容的報文，然後再根據該報文中的特定欄位，加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。 在這種情況下，負載類似於一個代理伺服器與前端的客戶端以及後端的伺服器會分別建立TCP連接。所以，從技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，設備性能消耗也更大。 太一星晨：如何分清負載均衡四、七層應用場景需求 第二.應用場景的需求。 七層應用負載的優勢是使整個網路更"智能"。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片伺服器並可以使用緩存技術；將對文字類的請求轉發到特定的文字伺服器並可以使用壓縮技術。 在技術原理上，這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大提升了應用系統在網路層的靈活性。很多在後台，例如Nginx或者Apache上部署的功能都前移到負載均衡設備上。 對於網路中最常見的SYN Flood攻擊，七層負載則提供了更好的安全性： 1.四層模式下：這些SYN攻擊都會被轉發到後端的伺服器上。 2.七層模式下：這些SYN攻擊自然在負載均衡設備上就截止，不會影響後台伺服器的正常運營。 另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQLInjection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。 現在的7層負載均衡，主要還是著重於應用HTTP協議，所以其應用范圍主要是眾多的網站或者各種基於B/S開發的應用系統。 4層負載均衡則對應其他TCP/UDP應用，經常用於C/S開發的系統。 四層負載工作模式簡單，負載性能高，後台伺服器都必須承載相同的業務， 七層負載工作模式復雜，性能消耗高，但帶來了更好的靈活度，更有效的利用資源，加速對資源的使用。 那麼，對於很多用戶關心的鏈路負載是在第幾層呢？通過上面的分析答案顯然已經出來了——鏈路當然是工作在四層模式以下啦！
❾ 怎麼實現伺服器的負載均衡
負載均衡有分硬體負載和軟體。
1.
硬體方面，可以用F5做負載，內置幾十種演算法。
2.
軟體方面，可以使用反向代理伺服器，例如apache,Nginx等高可用反向代理伺服器。
利用DNSPOD智能解析的功能,就可以實現多台機器負載均衡.
首先你用一台高配置的機器來當資料庫伺服器.然後把網站的前端頁面復製成多份,分別放在其他的幾台機器上面.再用DNSPOD做智能解析,把域名解析指向多個伺服器的IP,DNSPOD默認就有智能分流的作用,也就是說當有一台機器的資源不夠用時會自動引導用戶訪問其他機器上.這是相對來講比較簡單的實現負載均衡的方法.
❿ server2008負載均衡怎麼配置
安裝服務
分別在伺服器(11.1.6.11, 11.1.6.12) 上安裝此服務,以其中一台伺服器為例在開始=>伺服器管理器如下圖
可以在兩台分別服務部署測試網面分別在兩台不同的電腦上打開就可以看到連接不同的伺服器