您的位置:首頁>科技>正文

企業在雲計算中遇到的三種負載均衡

負載均衡幾乎與全球互聯網同時出現。 傳入的資料包、連接和請求從網路層到TCP到HTTP, 通常在資源之間分佈, 以確保應用性能和可用性。

這些差異可能看起來微不足道, 但實際上它們非常重要, 因為這些將直接影響企業可以實現的部署模式類型。 畢竟, 如果企業對於HTTP沒有可見性, 就不能採用更多依賴於URI或內容類別型的高級模式。

所有的負載均衡都需要決定轉發分組/請求的位置, 這就是網路、連接和應用程式負載均衡之間的區別變得重要的地方。 每個人都根據可能導致或阻礙企業實施特定類型的部署模式的特徵做出決策。

適當的網路負載均衡依賴於網路層資訊。 而源端和目標端IP以及TCP埠(在某些情況下)構成決策的基礎。

當網路負載均衡服務收到請求時, 它通常會散列源端IP和目標端IP(以及TCP埠), 然後選擇目標資源。 這個請求然後被發送到資源。

網路負載均衡具有作為所有負載均衡演算法中最快決策者的優勢, 但它具有不能平衡流量的缺點。 這意味著網路負載均衡(NLB)更關心路由流量, 而不是跨資源平衡流量。 它會進行嘗試, 但有些情況下會因為“超級代理”問題而失敗。

當大量流量來自同一範圍的網路位址時, 就會出現超級代理問題。 這會導致所有流量發送到相同的資源, 因為散列變數之間沒有足夠的分化來分配多個資源。 精明的開發人員會認識到這是一個衝突, 這是基於雜湊演算法的常見問題。 由於性能受到目標資源負載的影響, 其衝突問題更加惡化。 隨著負載的增加(在任何系統上), 其性能會下降。

所以, 如果企業打算使用這種消費, 可能會經歷糟糕的分佈,

並因此表現不佳。 這是因為大多數企業流量都來自同一個範圍的IP位址。 然而, 對於消費者來說, 這不應該是一個問題。

企業也無法根據應用程式(或API)版本引導流量, 也無法使用它來分割跨多個服務的API流量, 因為它無法考慮基於HTTP的變數(如URI或Cookie)。

簡單舊式負載均衡(POLB)是負載均衡的原始形式, 其中企業所熟悉的實際負載均衡演算法發揮作用。 輪詢調度(Round Robin)、最少連接(Least Connections)、最快回應(Fastest Response)都是至今仍在使用的大規模演算法。

POLB是基於協定的, 支援UDP(用於資料流)和TCP(連線導向)。 它的決定基於所選擇的演算法, 僅此而已。

簡單舊式負載均衡(POLB)接收請求, 並根據演算法從資源池(有時稱為伺服器場或集群)中選擇資源。 然後, 它轉發請求,

然後退出。

這種負載均衡的好處是速度相對較快, 並有多種演算法選項可供選擇。 如果性能至關重要, 請選擇最快回應(Fastest Response)。 如果企業只想快速輕鬆地進行擴展, 請選擇輪詢調度(Round Robin)。

簡單舊式負載均衡(POLB)的缺點是, 如果決策基於HTTP標頭中的某些內容(如cookie或URI), 則只能實現部署模式。 根據負載均衡服務, 企業可以使用諸如時間或計數器之類的變數來實現A/B測試等模式, 以確定選擇哪個資源。 它不一定像使用HTTP負載均衡一樣簡易, 但仍然可以獲得相同的結果。

簡單舊式負載均衡(POLB)可能是透明的, 也可能是不透明的, 具體取決於配置。 使用網路負載均衡(NLB), 企業可以確信其應用程式接收的用戶端(使用者和設備)的IP位址是用戶端的實際IP位址。

使用POLB的一些配置, 企業的應用程式收到的IP位址實際上是提供負載均衡服務的代理的IP位址。 這意味著其應用程式需要更多的工作來挖掘真實的用戶端IP位址。 所以如果企業需要這些資訊, 應該知道它可能需要在HTTP標題中挖掘才能找到它。

HTTP負載均衡需要HTTP請求, 並且在大多數實踐中實際上做出兩個不同的決定:第一個基於HTTP變數, 第二個基於演算法。

為了準確, HTTP負載均衡實際上是路由和轉發的組合。 也就是說, 它首先路由請求, 然後根據資源的演算法選擇轉發請求。 這就是像Canary和Blue/Green Deployments這樣的部署模式以及更強大的A/B測試。

這種類型的負載均衡問題在於它增加了等式的延遲。 對HTTP請求越深入, 延遲越多。 一些負載均衡器具有“快速”模式, 只允許基於HTTP標頭進行負載均衡,以糾正此問題,但請注意,如果試圖根據某個POST變數做出決定,該變數隱藏在HTTP負載的深處,這需要更多時間做決定。

另一個問題與簡單舊式負載均衡(POLB)分享,即透明度。企業可能會也有可能不會收到每個請求的用戶端的實際IP位址,因此請務必檢查其應用中是否需要該資訊。

選擇企業的負載均衡,以便在規模和速度方面與其應用架構和特定目標相匹配。選擇錯誤的負載均衡和演算法可能會對企業實現這些目標的能力產生重大影響。(來自:企業網D1Net)

只允許基於HTTP標頭進行負載均衡,以糾正此問題,但請注意,如果試圖根據某個POST變數做出決定,該變數隱藏在HTTP負載的深處,這需要更多時間做決定。

另一個問題與簡單舊式負載均衡(POLB)分享,即透明度。企業可能會也有可能不會收到每個請求的用戶端的實際IP位址,因此請務必檢查其應用中是否需要該資訊。

選擇企業的負載均衡,以便在規模和速度方面與其應用架構和特定目標相匹配。選擇錯誤的負載均衡和演算法可能會對企業實現這些目標的能力產生重大影響。(來自:企業網D1Net)

Next Article
喜欢就按个赞吧!!!
点击关闭提示