AWS（亞馬遜網絡服務）網關負載均衡器為第三方虛擬設備提供負載均衡優勢。同時，該服務旨在以最小的管理開銷使這些第三方虛擬設備具有高可用性和可擴展性。本文討論什么是負載平衡、更流行的負載平衡算法、AWS 負載平衡的用例、負載平衡中的問題以及Parallels? RAS如何增強負載平衡。

負載均衡器的定義

高流量網站、Web 應用程序和運行在它們背后的數據庫在高峰時段會收到數百萬個傳入請求和查詢。當圖像、音頻和視頻等大文件在這種時候在用戶和服務器之間傳遞時，降低服務器及其響應時間的風險就變得真實了。為了防止這種情況發生，增加了更多的服務器來容納傳入的請求。

更好地服務傳入流量的另一個選擇是為您的網絡添加負載平衡功能。負載均衡器可以以硬件或軟件的形式出現，并充當用戶和服務器之間的中介，跟蹤服務器負載，以便他們知道哪個服務器可以更好地處理傳入流量。

當傳入請求進入時，負載均衡器知道將其發送到哪個服務器。當服務器不可用時，負載平衡器會知道并相應地繞過該服務器。當服務器再次啟動時，負載均衡器將再次將請求路由到它。它還將知道何時將新服務器添加到您的網絡中，從而允許它在時間到來時將請求路由到該服務器。

流行的負載均衡算法

負載平衡器根據優化網絡流量的算法決定將傳入請求發送到何處。雖然您為網絡選擇的算法取決于您的要求，但您的 IT 團隊必須在設置負載平衡器時選擇要使用的算法。比較流行的負載均衡算法包括：

• 循環：在此設置下，負載均衡器根據網絡中服務器的順序做出決策。因此，服務器 1 是第一個處理請求的，然后是服務器 2 并繼續處理。由于它不考慮服務器負載，因此該算法可能導致某些服務器因請求而過載。這種情況的一種變體是加權循環，它根據服務器的能力為服務器分配權重。
• 最少連接：使用此設置，傳入請求將發送到活動連接數量最少的服務器。因此，它有助于避免服務器過載的潛在問題。
• 最小帶寬：此設置測量傳輸到服務器和從服務器傳輸的流量，具有最少帶寬消耗的服務器最終獲得請求。這類似于最少數據包方法，它基于服務器通過網絡傳輸的數據包數量來做出負載平衡器的轉發決策。
• 最短響應時間：在此設置下，負載均衡器向服務器發送監視請求以確定它們可以多快地處理請求，然后再將實際請求轉發到可以更快處理請求的服務器。
• 散列：使用此設置，負載平衡器依賴來自傳入網絡數據包的散列數據，包括源和目標的 Internet 協議 (IP) 地址。設置起來可能很復雜，比本節討論的其他算法更難。
• 自定義負載：此設置涉及根據 SNMP（簡單網絡管理協議）提供的數據查詢服務器負載，包括內存使用情況、CPU 使用情況和響應時間，負載均衡器依靠數據做出路由決策。

AWS Gateway 負載均衡器的使用案例

與任何其他負載均衡器一樣，AWS Gateway 負載均衡器用于組織您的網絡流量，以便更好、更快地為您的用戶提供服務。其次是它可以讓您的虛擬設備按需擴展。因此，如果您的組織當前使用或計劃使用虛擬設備，則該服務主要面向您。虛擬設備的一些示例包括那些增強網絡安全的設備，包括防火墻和入侵檢測系統。

AWS Gateway 負載均衡器負責將流量路由到網絡中的相應虛擬設備，而不是直接將流量路由到虛擬設備。使用網關負載均衡器，流量被路由到健康的虛擬設備，并從失敗的虛擬設備中重新路由。因此，它可以幫助降低管理成本，因為您可以通過網關集中流量。它還可以確保您的策略在您的設備中得到一致執行。

通過 AWS Marketplace，您的組織還可以訪問可以輕松添加到您的網絡的第三方虛擬設備和解決方案。但是，這些都是有代價的，因此您仍然必須為這些費用分配預算。

由于任何第三方虛擬設備或解決方案都可以按原樣連接到 AWS Gateway 負載均衡器，而無需更改任何其他端點，因此它們是網絡分析的理想選擇，讓您能夠及早發現潛在的網絡問題并構建您的網絡更有彈性。此外，AWS Gateway 負載均衡器還可以與網絡編排工具一起使用。這些工具包括 AWS CloudFormation，它可以簡化您 IT 基礎設施中 AWS 資源的部署和管理。

負載均衡器的問題

盡管負載均衡器有其優勢，但它們也不能免除可能使您的網絡和 IT 團隊工作復雜化的問題。負載平衡器可以使您的網絡比現在更復雜。如果您的負載均衡器出現故障，它也會使您的整個網絡癱瘓。必須實施負載平衡基礎架構的故障轉移機制以防止這種情況發生。

實現這一點的一種方法是通過冗余路由器，在發生故障時可以將流量從一個負載均衡器切換到另一個。有了這樣的機制，當主負載均衡器發生故障時，備用負載均衡器將接管其功能，直到主負載均衡器重新上線。上述故障轉移要求意味著負載平衡器可能會導致您的網絡的運營成本更高。

負載均衡器配置錯誤也會帶來網絡問題。例如，負載均衡器可能會錯誤地檢測健康服務器中的故障并不必要地將流量重新路由到其他服務器。這可能是由于多種因素造成的，包括過于頻繁的運行狀況檢查以及在運行狀況檢查期間預期服務器響應的超時時間太短。調整運行狀況檢查的頻率并延長超時時間有助于解決此問題。