歡迎您光臨本站 註冊首頁

負載平衡與CPU使用率

←手機掃碼閱讀     火星人 @ 2014-03-04 , reply:0

負載平衡與CPU使用率

我的問題是:
    現在有一個集群,8台相同配置的機器,但是同時有多個後台用戶在使用,8台機器的CPU佔用情況因而不一致。為了實現并行程序的負載平衡,是不是在編程的時候就應該考慮到讀取CPU的使用率,並據此分配任務呢?這種方式可以實現嗎?
《解決方案》

http://blog.chinaunix.net/u/31692/showart_403163.html

常見的負載平衡方法

1、DNS負載平衡的方法
RR-DNS(Round-Robin Domain Name System) 輪流排程的方式是:在DNS伺服器中,可以為多個不同的IP地址配置同一個名稱,當客戶端查詢這個名字時將在解析這個名稱時得到其中的一個地址。因此,對於同一個名字,不同的客戶端會得到不同的地址,他們也就連結不同地址上的Web伺服器,從而達到負載平衡的目的。例如 : 當客戶端連結 www.muti-ip.com.tw這名稱時,DNS 有能力依序將名稱解析到 202.1.1.1 、 202.1.1.2 、202.1.1.3和 202.1.1.4等不同的網路地址,而這些是提供相同服務的主機,讓客戶端不自覺有不同

2、服務端應用層和IP層的負載平衡方法
EDDIE、 Reverse-Proxy和SWEB 都使用屬於應用層負載平衡的方法將到達的HTTP請求轉發到不同的Web 伺服器,取得結果后,再返回給用戶。Berkeley的MagicRouter、Cisco的LocalDirector、Altheon 的ACEDirector和F5的Big/IP等都是使用網路地址轉換NAT的方法,目前在Linux 上Cluster的方式也是用這種方法達成的。

3、集群( Cluster )Server 達成負載平衡的方法

集群能達到的機制
a. 分身服務 將兩個以上的伺服器連貫成伺服器群,每台提供相同服務
b. 不疑有他 客戶端感覺只有一台機器在提供服務
c. 備份能力 也就是當其中有某台伺服器出問題時,不會有服務中斷的情形
d. 可擴充性 當客戶數量增加時,可在不中止服務的情形下擴充伺服器
e. 負載平衡 將客戶端的要求科學的分配給伺服器,不致讓主機負載過量

在Linux Cluster 實現負載平衡的軟體 ----LVS( Linux Virtual Server )
Linux上集群的達成是實施 Linux Virtual Server ( LVS ) 的架設

LVS可稱為Linux虛擬伺服器,它具備高可用性、可擴充性和科學性的數學運算,而這些也就是集群系統 (Cluster System)的應用。

高可用性High-Availability (HA) 不允許有服務中斷的情形發生時。由兩台以上的計算機通過一定方式互相*,當主要伺服器主機出現問題而無預警的停止服務時,備份伺服器能夠自動立即接替工作,使客戶端感覺不出有異。
可擴充性 (Scalability) 應用在web 、ftp server上為多。當用戶連結一個地址,但實際上是有若干台伺服器在提供服務。而當服務請求達到飽和時,還可以很容易地再添加新的節點而不用停掉整個 cluster,實現所謂的"熱插拔",這也就是Cluster中的一個概念-Scalability (易擴展性)。而且,cluster還會查詢真實節點的情況,當某台真實節點沒有響應時,就不再把任務分配到那裡,直到這台節點恢復正常。
科學的數學運算 (Scientific) 用於效能、圖像處理等計算
Cluster已經發展多年,也比較成熟了。之前需要專業的軟/硬設備才能實現。所以只有少數公司才有能力用的起。現在Linux上的LVS就可以讓你在PC上架設Cluster的解決方案,使更多的人有機會構建自己的cluster。

LVS提供了三種轉發機制(Traffic Forward Mechanism)、四種分配方法(Load-balancing Methods),以下詳述
三轉發機制(Traffic Forward Mechanism)
三種不同的轉發機制分別將LVS主機建構成

NAT虛擬主機 Virtual Server via Network Address Translation

IP Tunneling虛擬主機 Virtual Server via IP Tunneling

Direct Routing虛擬主機 Virtual Server via Direct Routing

負載平衡主機可稱為Virtual Server ( 虛擬主機 )、Load Balancer (負載平衡器)、Linux Director (導引主機),以下簡稱為LVS主機
NAT虛擬主機 Virtual Server via Network Address Translation ( VS/NAT )

由於IPv4中IP地址空間的日益不足和安全方面的原因,很多網路使用Internet上未被分配的私有IP地址(10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0 和192.168.0.0/255.255.0.0)。
當內部網路中的主機要連結Internet或被Internet連結時,就需要採用網路地址轉換(Network Address Translation, 以下簡稱NAT),可以用NAT方法將不同IP地址的并行網路服務變成在一個IP 地址上的一個虛擬服務。

VS/NAT的體系結構
在一組伺服器前有一個LVS主機,用戶通過Virtual IP Address(即LVS主機的外部地址)連結服務時,請求到達LVS主機,LVS主機以負載平衡方法從一組真實伺服器選出一個,將目標地址 Virtual IP Address重新指向內部實際提供服務伺服器的地址。同時,LVS主機記錄這個連接,當這個連接的真實伺服器的響應經過LVS主機時,LVS主機將來源地址和來源埠改?Virtual IP Address和相應的埠,再把響應發給用戶。當連接終止或逾時,LVS主機將這個連接從紀錄中刪除。這樣,用戶所看到的只是在Virtual IP Address 上提供的服務。

IP Tunneling 虛擬主機 Virtual Server via IP Tunneling (VS/TUN)

在 VS/NAT的集群系統中,請求和應答的封包都需要通過LVS主機,當實際伺服器的數量超過20時,LVS主機將成為集群系統的新瓶頸。利用IP隧道技術將請求封包封裝轉發給後端伺服器,響應封包能從後端伺服器直接返回給客戶。但在這裡,後端伺服器有一組而非一個,所以我們不可能靜態地建立一一對應的隧道,而是動態地選擇一台伺服器,將請求封包封裝和轉發給選出的伺服器。這樣,我們可以利用IP隧道的原理將一組伺服器上的網路服務組成在一個IP地址上的虛擬網路服務。

VS/TUN的體系結構
如上圖所示,各個伺服器將 VIP地址配置在自己的IP隧道設備上。

VS/TUN 的連接分配和管理與VS/NAT中的一樣,只是它的封包轉發方法不同。負載平衡主機根據各個伺服器的負載情況,動態地選擇一台伺服器,將請求封包封裝在另一個IP封包中,再將封裝后的IP封包轉發給選出的伺服器;那台伺服器收到封包后,先將封包解封獲得原來目標地址為VIP的封包,伺服器發現VIP地址被配置在本地的IP隧道設備上,所以就處理這個請求,然後根據路由表將響應封包直接返回給客戶。

Direct Routing 虛擬主機 Virtual Server via Direct Routing (VS/DR)

這種IP層負載平衡方法與IBM的NetDispatcher中的方法類似。它的體系結構如下圖所示:

VS/DR的體系結構
LVS 主機和伺服器組都必須在同一網路區域中,如通過交換機或者高速的HUB相連。VIP地址為LVS主機和伺服器組共享,LVS主機配置的VIP地址是對外可連結的,用於接收虛擬服務的請求封包;所有的伺服器把VIP地址配置在各自的Non-ARP網路設備上,它對外面是不可見的,只是用於處理目標地址?VIP的網路請求。

VS/DR的連接分配和管理與VS/NAT和VS/TUN中的一樣,它的封包轉發方法又有不同,將封包直接路由給目標伺服器。在VS/DR中,LVS主機根據各個伺服器的負載情況,動態地選擇一台伺服器,不修改也不封裝IP封包,而是將資料封包的MAC地址改為選出伺服器的MAC地址,再將修改後的資料封包在與伺服器組的區域網上發送;因為資料封包的MAC地址是選出的伺服器,所以伺服器肯定可以收到該封包,發現VIP地址被配置在本地的網路設備上,所以就處理這個請求,然後根據路由表將響應封包直接返回給客戶。

三種轉發機制的優缺點

歸納在下表中:
● Virtual Server via NAT
VS/NAT 的優點是伺服器可以運行任何支持TCP/IP的操作系統,它只需要一個IP地址配置在LVS主機上,伺服器組可以用私有的IP地址。缺點是它的擴充能力有限,當伺服器結點數目升到20時,LVS主機本身有可能成為系統的新瓶頸,因為在VS/NAT中請求和響應封包都需要通過負載LVS主機。在 Pentium 166主機上測得重寫封包的平均延時為60us,假設TCP封包的平均長度為536 Bytes,則LVS主機的最大吞吐量為8.93 MBytes/s。再假設每台伺服器的吞吐量為600KBytes/s,這樣一個LVS主機可以帶動16台伺服器。

● Virtual Server via IP Tunneling
在 VS/TUN的集群系統中,負載LVS主機只將請求分配到不同的實際伺服器,實際伺服器將應答的資料直接返回給用戶。這樣,負載LVS主機就可以處理巨量的請求,而不會成為系統的瓶頸。即使負載LVS主機只有100Mbps的全雙工網卡,虛擬伺服器的最大吞吐量可以達到幾Gbps。所以,VS/TUN可以極大地增加負載LVS主機分配的伺服器數量,它可以用來構建高性能超級伺服器。VS/TUN技術對伺服器的要求是所有的伺服器必須支持"IP Tunneling"或者"IP Encapsulation"協議。目前,VS/TUN 的後端伺服器主要運行Linux操作系統。因為"IP Tunneling"正成為各個操作系統的標準協議,所以VS/TUN也會適用運行其它操作系統的後端伺服器。

● Virtual Server via Direct Routing
同 VS/TUN一樣,VS/DRLVS主機只處理客戶到伺服器端的連接,響應資料可以直接從獨立的網路路由返回給客戶。這可以極大地提高LVS集群系統的伸縮性。同VS/TUN相比,這種方法沒有IP隧道的開銷,但是要求負載LVS主機與實際伺服器都有一塊網卡連在同一物理網段上,伺服器網路設備或者設備別名不作ARP 響應。

四種分配方法(Load-balancing Methods)

不同的分配方法建構LVS主機成四種不同的排程
負載平衡排程是以連接為單位的。在HTTP協議(nowait)中,每個對象從WEB伺服器上獲取都需要建立一個TCP連接,同一用戶的不同請求會被分配到不同的伺服器上,所以這種連接的分配完全避免了用戶連結的突發性引起的負載不平衡。目前有以下4種排程演算法:

輪流排程 Round-Robin Scheduling (RRS)
輪流排程演算法是假設所有伺服器處理性能均相同,依次將請求分配不同的伺服器,演算法簡單,但不適用於伺服器組中處理性能不一致的情況。

加權輪流排程 Weighted Round-Robin Scheduling (WRRS)
為此使用加權輪流排程演算法,用相應的加權值表示伺服器的處理性能,將請求數目按加權值的比例分配到各伺服器。加權值高的伺服器先收到連接,加權值高的伺服器比加權值低的伺服器處理更多的連接,相同權值的伺服器處理相同數目的連接數。

最小連結數排程 Least-Connection Scheduling (LCS)
最小連結數排程是需要記錄各個伺服器已建立TCP連接的數目,把新的連接請求發送當前連接數最小的伺服器。當各個伺服器有相同的處理性能時,最小連結數排程能把負載變化大的請求平均分佈到各個伺服器上,所有處理時間比較長的請求不可能被發送到同一台伺服器上。

加權最小連接數排程 Weighted Least-Connection Scheduling (WLCS)
但是,當各個伺服器的處理能力不同時,該演算法並不理想,因為TCP連接處理請求後會進入TIME_WAIT狀態,TCP的TIME_WAIT 一般為2分鐘,此時連接還佔用伺服器的資源,所以會出現這樣情形,性能高的伺服器已處理所收到的連接,連接處於TIME_WAIT狀態,而性能低的伺服器既要忙於處理所收到的連接,還要收到新的連接請求。加權最小連接分配是最小連接分配的超集,各個伺服器用相應的權值表示其處理性能。假設每台伺服器的權值為Wi(i=1..n),TCP連接數目為 Ti(i=1..n),依次選Ti/Wi為最小者的伺服器為下一個分配到服務的伺服器。

四種分配方法(Load-balancing Methods)

表示如下

名稱 描述

Round robin (RRS)
將工作平均的分配到伺服器 (用於實際服務主機性能一致)
Least-connections (LCS)
向較少連接的伺服器分配較多的工作(IPVS 表存儲了所有的活動的連接。用於實際服務主機性能一致。)
Weighted round robin (WRRS)
向較大容量的伺服器分配較多的工作。可以根據負載信息動態的向上或向下調整。 (用於實際服務主機性能不一致時)
Weighted least-connections (WLC)
考慮它們的容量向較少連接的伺服器分配較多的工作。容量通過用戶指定的砝碼來說明,可以根據裝載信息動態的向上或向下調整。(用於實際服務主機性能不一致時)
《解決方案》

原帖由 unixlinuxsys 於 2009-4-19 08:47 發表 http://linux.chinaunix.net/bbs/images/common/back.gif
http://blog.chinaunix.net/u/31692/showart_403163.html

常見的負載平衡方法

1、DNS負載平衡的方法
RR-DNS(Round-Robin Domain Name System) 輪流排程的方式是:在DNS伺服器中,可以為多個不同的IP地址 ...
一樓提及的問題是并行計算的
而不是目前回答的這個負載均衡實現方式的問題

[火星人 ] 負載平衡與CPU使用率已經有1371次圍觀

http://coctec.com/docs/service/show-post-6500.html