負載均衡伺服器搭建
① 伺服器做負載均衡
冗餘是針對於伺服器之間的備份的，他高於伺服器負載均衡。負載是指你正在運行的所有提供同一應用的伺服器之間的負載，根據負載的演算法，會均衡你這些提供相同應用的伺服器性能以及運行。而冗餘起到的作用是在你主備伺服器的主機宕機之後，立刻啟動備機防止應用不能訪問，提供24小時不間斷服務。負載是在一個伺服器組中做均衡，提高伺服器組的總體運行安全度。這點負載與冗餘有很大的相似處。
② 怎麼快速搭建一套伺服器負載均衡
使用DNS的負載均衡系統。
把解析平均分配到多台伺服器，每台伺服器存儲一份相同的網站內容。
③ 伺服器負載均衡的幾種部署方式
路由模式部署靈活，約60%的用戶採用這種方式部署；橋接模式不改變現有的網路架構；服務直接返回（DSR）比較適合吞吐量大特別是內容分發的網路應用。約30%的用戶採用這種模式。 1、路由模式（推薦） 路由模式的部署方式如上圖。伺服器的網關必須設置成負載均衡機的LAN口地址，且與WAN口分署不同的邏輯網路。因此所有返回的流量也都經過負載均衡。這種方式對網路的改動小，能均衡任何下行流量。2、橋接模式 橋接模式配置簡單，不改變現有網路。負載均衡的WAN口和LAN口分別連接上行設備和下行伺服器。LAN口不需要配置IP（WAN口與LAN口是橋連接），所有的伺服器與負載均衡均在同一邏輯網路中。 由於這種安裝方式容錯性差，網路架構缺乏彈性，對廣播風暴及其他生成樹協議循環相關聯的錯誤敏感，因此一般不推薦這種安裝架構。 3、服務直接返回模式 這種安裝方式負載均衡的LAN口不使用，WAN口與伺服器在同一個網路中，互聯網的客戶端訪問負載均衡的虛IP（VIP），虛IP對應負載均衡機的WAN口，負載均衡根據策略將流量分發到伺服器上，伺服器直接響應客戶端的請求。因此對於客戶端而言，響應他的IP不是負載均衡機的虛IP（VIP），而是伺服器自身的IP地址。也就是說返回的流量是不經過負載均衡的。
④ 怎麼實現伺服器的負載均衡
負載均衡有分硬體負載和軟體。
1.
硬體方面，可以用F5做負載，內置幾十種演算法。
2.
軟體方面，可以使用反向代理伺服器，例如apache,Nginx等高可用反向代理伺服器。
利用DNSPOD智能解析的功能,就可以實現多台機器負載均衡.
首先你用一台高配置的機器來當資料庫伺服器.然後把網站的前端頁面復製成多份,分別放在其他的幾台機器上面.再用DNSPOD做智能解析,把域名解析指向多個伺服器的IP,DNSPOD默認就有智能分流的作用,也就是說當有一台機器的資源不夠用時會自動引導用戶訪問其他機器上.這是相對來講比較簡單的實現負載均衡的方法.
⑤ 伺服器做負載均衡和冗餘有什麼區別
負載均衡和冗餘，都是伺服器高並發解決方案；
負載均衡可以看著是冗餘解決方案的升級版；
快雲負載均衡是多台伺服器組件資源池，共同承擔資源壓力，冗餘多是以一台高配置伺服器預留資源以預防大流量時候的資源損耗。
⑥ 怎樣配置負載均衡
可以用軟體或加台磁碟陣列櫃，主要還要看你跑的是什麼任務，是WEB還是資料庫
⑦ 怎樣實現伺服器的負載均衡
一兩句話很能說清楚,看下面的專題吧.
http://cisco.chinaitlab.com/special/ServerLoadBalance/
⑧ 多台異地伺服器如何實現負載均衡
一般用的就用簡單的輪詢就好了
調度演算法
靜態方法：僅根據演算法本身實現調度；實現起點公平，不管伺服器當前處理多少請求，分配的數量一致
動態方法：根據演算法及後端RS當前的負載狀況實現調度；不管以前分了多少，只看分配的結果是不是公平
靜態調度演算法(static Sche)（4種）:
(1)rr (Round Robin) :輪叫,輪詢
說明：輪詢調度演算法的原理是每一次把來自用戶的請求輪流分配給內部中的伺服器，從1開始，直到N(內部伺服器個數)，然後重新開始循環。演算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。缺點：是不考慮每台伺服器的處理能力。
(2)wrr (Weight Round Robin) :加權輪詢(以權重之間的比例實現在各主機之間進行調度)
說明：由於每台伺服器的配置、安裝的業務應用等不同，其處理能力會不一樣。所以，我們根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。
(3)sh (Source Hashing) : 源地址hash實現會話綁定sessionaffinity
說明：簡單的說就是有將同一客戶端的請求發給同一個real server,源地址散列調度演算法正好與目標地址散列調度演算法相反，它根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的並且沒有超負荷，將請求發送到該伺服器，否則返回空。它採用的散列函數與目標地址散列調度演算法的相同。它的演算法流程與目標地址散列調度演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址。
(4)dh : (Destination Hashing) : 目標地址hash
說明：將同樣的請求發送給同一個server,一般用於緩存伺服器，簡單的說，LB集群後面又加了一層，在LB與realserver之間加了一層緩存伺服器，當一個客戶端請求一個頁面時,LB發給cache1,當第二個客戶端請求同樣的頁面時，LB還是發給cache1,這就是我們所說的，將同樣的請求發給同一個server,來提高緩存的命中率。目標地址散列調度演算法也是針對目標IP地址的負載均衡，它是一種靜態映射演算法，通過一個散列（Hash）函數將一個目標IP地址映射到一台伺服器。目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
動態調度演算法(dynamic Sche)（6種）:
(1)lc (Least-Connection Scheling): 最少連接
說明：最少連接調度演算法是把新的連接請求分配到當前連接數最小的伺服器，最小連接調度是一種動態調度短演算法，它通過伺服器當前所活躍的連接數來估計伺服器的負載均衡，調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某台伺服器，其連接數加1，當連接中止或超時，其連接數減一，在系統實現時，我們也引入當伺服器的權值為0時，表示該伺服器不可用而不被調度。此演算法忽略了伺服器的性能問題，有的伺服器性能好，有的伺服器性能差，通過加權重來區分性能，所以有了下面演算法wlc。
簡單演算法：active*256+inactive (誰的小，挑誰)
(2)wlc (Weighted Least-Connection Scheling):加權最少連接
加權最小連接調度演算法是最小連接調度的超集，各個伺服器用相應的權值表示其處理性能。伺服器的預設權值為1，系統管理員可以動態地設置伺服器的許可權，加權最小連接調度在調度新連接時盡可能使伺服器的已建立連接數和其權值成比例。由於伺服器的性能不同，我們給性能相對好的伺服器，加大權重，即會接收到更多的請求。
簡單演算法：（active*256+inactive）/weight（誰的小，挑誰）
(3)sed (shortest expected delay scheling):最少期望延遲
說明：不考慮非活動連接，誰的權重大，我們優先選擇權重大的伺服器來接收請求，但會出現問題，就是權重比較大的伺服器會很忙，但權重相對較小的伺服器很閑，甚至會接收不到請求，所以便有了下面的演算法nq。
基於wlc演算法，簡單演算法：（active+1)*256/weight （誰的小選誰）
(4).nq (Never Queue Scheling): 永不排隊
說明：在上面我們說明了，由於某台伺服器的權重較小，比較空閑，甚至接收不到請求，而權重大的伺服器會很忙，所此演算法是sed改進，就是說不管你的權重多大都會被分配到請求。簡單說，無需隊列，如果有台real server的連接數為0就直接分配過去，不需要在進行sed運算。
(5).LBLC(Locality-Based Least Connections) :基於局部性的最少連接
說明：基於局部性的最少連接演算法是針對請求報文的目標IP地址的負載均衡調度，主要用於Cache集群系統，因為Cache集群中客戶請求報文的目標IP地址是變化的，這里假設任何後端伺服器都可以處理任何請求，演算法的設計目標在伺服器的負載基本平衡的情況下，將相同的目標IP地址的請求調度到同一個台伺服器，來提高伺服器的訪問局部性和主存Cache命中率，從而調整整個集群系統的處理能力。
(6).LBLCR(Locality-Based Least Connections with Replication) :基於局部性的帶復制功能的最少連接
說明：基於局部性的帶復制功能的最少連接調度演算法也是針對目標IP地址的負載均衡，該演算法根據請求的目標IP地址找出該目標IP地 址對應的伺服器組，按「最小連接」原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除， 以降低復制的程度。
⑨ 如何配置Web伺服器實現負載均衡
這篇實用文章介紹如何將pfSense 2.0配置成你那些Web伺服器的負載均衡器。這篇實用文章假設你已經安裝了一個pfSense設備和至少兩台Apache伺服器，並且運行在你的網路上；還假設你具備了pfSense方面的一些知識。
要求
一台設備用於安裝pfSense 2.0（如果這是你的邊緣防火牆，我會建議物理機器）。
至少兩台Apache2伺服器（這些可以是虛擬伺服器）。
對Apache伺服器進行了配置，以便以某種方式同步Web文件（rsync/corosync或通過Web伺服器維持文件版本最新的另一個選項）。
配置pfSense
pfSense使用負載均衡器，將某些類型的流量帶來的負載分攤到多台伺服器上；如果你有多台伺服器用於託管運行應用程序，這很好；你可以將負載分攤到所有伺服器上，而不是把負載全扔給一台伺服器、導致不堪重負。
可以入手了，先點擊「Services」（服務），然後點擊「Load Balancers」（負載均衡器），然後點擊「Monitor」（監視器）選項卡。
要添加一個新條目，點擊「Plus」（添加）按鈕，指定「Name」（名稱）和「Description」（描述，在這個示例中，我會使用ApacheClusterMon作為名稱和描述），將類型設成「HTTP」，然後為「Host」（主機）設置一個未使用的IP地址（我們隨後會創建虛擬伺服器的IP，以便分配給故障切換伺服器組），任由「HTTP Code」（HTTP代碼）設成「200 OK」。需要的話，然後點擊「Save」（保存），使更改生效。
現在我們要創建伺服器池。點擊「Pools」（伺服器池）選項卡，點擊「Plus」（添加）按鈕，即可添加新的伺服器池。
指定一個名稱（ApacheSrvPool將用在我的示例中）。將「Mode」（模式）設成「Load Balance」（負載均衡），然後將「Port」（埠）設成「80」（你可以讓pfSense對其他埠上的其他應用程序實現負載均衡），將「Monitor」（監視器）設成你之前創建的監視器配置，並且指定你希望在伺服器池中的所有Web伺服器的IP地址，需要的話，點擊「Save」（保存），使更改生效。
接下來點擊「Virtual Servers」（虛擬伺服器）選項卡，點擊「Plus」（添加）按鈕，添加一個新條目。指定「Name」（名稱）和「Description」（描述），然後用你之前選擇的未使用IP地址來設置「IP Address」（IP地址），將「Port」（埠）設成「80」，然後將「Virtual Server Pool」（虛擬伺服器池）設成你之前創建的伺服器池，點擊「Submit」（提交），使更改生效。
就這樣，你剛配置好了pfSense，對你的Web伺服器之間的網路流量實現負載均衡。
順便提一下，如果任何一台伺服器沒有給出200 OK狀態這樣的回應（pfSense定期向你的Web伺服器發送請求，以確定它們是否正常運行），伺服器池就會處於離線停運狀態。要避免出現停運，最好的辦法就是配置故障切換系統（下一篇文章會有介紹）。
⑩ SQLSERVER怎麼搭建伺服器集群實現負載均衡
很多組織機構慢慢的在不同的伺服器和地點部署SQL Server資料庫——為各種應用和目的——開始考慮通過SQL Server集群的方式來合並。
將SQL Server實例和資料庫合並到一個中心的地點可以減低成本，尤其是維護和軟硬體許可證。此外，在合並之後，可以減低所需機器的數量，這些機器就可以用於備用。
當尋找一個備用，比如高可用性的環境，企業常常決定部署Microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)SQL Server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後，我讓你們自己做決定。
什麼是Microsoft集群伺服器
MSCS是一個Windows Server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」，來獲得更高的可用性和對數據和應用更簡便的管理。MSCS可以自動的檢查到伺服器或者應用的失效，並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。
這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中，它會自動將資源(比如磁碟和IP地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性，比如站點全面失效的情況下。
MSCS不要求在客戶計算機上安裝任何特殊軟體，因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的，因為MSCS在相同的IP地址上重啟應用、文件共享等等。進一步，為了災難恢復，集群的節點可以處於分離的、遙遠的地點。
在集群伺服器上的SQL Server
SQL Server 2000可以配置為最多4個節點的集群，而SQL Server 2005可以配置為最多8個節點的集群。當一個SQL Server實例被配置為集群之後，它的磁碟資源、IP地址和服務就形成了集群組來實現災難恢復。
SQL Server 2000允許在一個集群上安裝16個實例。根據在線幫助，「SQL Server 2005在一個伺服器或者處理器上可以支持最多50個SQL Server實例，」但是，「只能使用25個硬碟驅動器符，因此如果你需要更多的實例，那麼需要預先規劃。」
注意SQL Server實例的災難恢復階段是指SQL Server服務開始所需要的時間，這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性，考慮使用其他的方法，比如log shipping和資料庫鏡像。
單個的大的SQL Server集群還是小的集群
下面是大的、由更多的節點組成的集群的優點：
◆更高的可用新(更多的節點來災難恢復)。
◆更多的負載均衡選擇(更多的節點)。
◆更低廉的維護成本。
◆增長的敏捷性。多達4個或者8個節點，依賴於SQL版本。
◆增強的管理性和簡化環境(需要管理的少了)。
◆更少的停機時間(災難恢復更多的選擇)。
◆災難恢復性能不受集群中的節點數目影響。
下面是單個大的集群的缺點：
◆集群節點數目有限(如果需要第9個節點怎麼辦)。
◆在集群中SQL實例數目有限。
◆沒有對失效的防護——如果磁碟陣列失效了，就不會發生災難恢復。
◆使用災難恢復集群，無法在資料庫級別或者資料庫對象級別，比如表，創建災難恢復集群。
虛擬化和集群
虛擬機也可以參與到集群中，虛擬和物理機器可以集群在一起，不會發生問題。SQL Server實例可以在虛擬機上，但是性能可能會受用影響，這依賴於實例所消耗的資源。在虛擬機上安裝SQL Server實例之前，你需要進行壓力測試來驗證它是否可以承受必要的負載。
在這種靈活的架構中，如果虛擬機和物理機器集群在一起，你可以在虛擬機和物理機器之間對SQL Server進行負載均衡。比如，使用虛擬機上的SQL Server實例開發應用。然後在你需要對開發實例進行壓力測試的時候，將它災難恢復到集群中更強的物理機器上。
集群伺服器可以用於SQL Server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境，為了負載均衡和維護，實例可以從一個節點移動到另外的節點。