303
負載均衡進階：SLB常見問題解決方法
摘要：在由雲棲社區和阿裏雲網絡團隊聯合主辦的2017阿裏雲網絡技術在線高峰論壇上，阿裏雲技術專家添毅分享了網絡產品部根據客戶和阿裏雲運維的反饋提煉出的幾大最主要和最常見的在使用SLB產品中發生的問題，並為大家介紹了針對這些常見問題的相應處理方法。想知道如何借助SLB構建高可用係統以及健康檢查是如何實現的，本文不容錯過！本文內容根據演講嘉賓分享視頻以及PPT整理而成。
本次的分享將會主要圍繞以下5個部分
- 基本概念回顧
- 如何構建高可用係統
- 選擇性能共享型還是性能保障型實例
- 為什麼健康檢查異常
- 為什麼負載不均衡
一、基本概念回顧
SLB是什麼
SLB基本組件
二、如何構建高可用係統
多層次的高可用
如下圖所示，阿裏雲的負載均衡是從四個層麵上去構建高可用的。從底層往上層看，分別是應用級別的高可用、集群級別的高可用、可用區級別(AZ)的高可用以及地域級別(Region)的高可用。
細說可用區級別容災
- 首先，建議用戶在SLB實例的後端盡可能地去掛載多個可用區的ECS實例。SLB能夠支持跨可用區地掛載ECS雲服務器，這樣可以避免某個可用區的ECS都出現故障的情況下，還有其他可用區的ECS能夠接替工作，雖然跨可用區掛在ECS會存在大約2毫秒左右的延遲，但是卻能夠大大地提升服務的可用性。
- 第二步就是針對於一些特別重要的業務，建議在不同的可用區分別地去購買SLB的實例。比如在可用區A和可用區B各自購買一個SLB實例，在此基礎之上再使用全球負載均衡GSLB來進行實例間的調度。
跨地域容災的實現
三、選擇性能共享型還是性能保障型實例
共享型vs保障型-WHY保障型
- 早晚高峰叫不到車？雨雪天氣路邊凍成狗？還大幅提價？
- 假期想遠離塵囂，找個僻靜曠野放空自我，叫個滴滴？也許有去，但保證無回！
所以說共享和保障都是客戶的需求。出於對於類似需求的考慮，阿裏雲的負載均衡也推出了性能保障型實例。以前所推出的SLB共享型實例是因為性能指標沒有辦法實現隔離，因為所有的共享型實例都處於同一個大共享資源池中，所以在高峰期的時候就會出現資源的爭搶，這樣就無法滿足對於性能具有剛性需求的大客戶的訴求。除此之外，還有一些體量特別大的超級用戶，他們對於性能的要求會是非常高的，但是由於共享型實例無法做到性能隔離，也支持不了大顆粒度的性能指標，所以也無法完成這樣的工作。因此，阿裏雲推出了性能保障型的負載均衡實例。
超強性能
- 超強HTTPS性能。性能保障型實例針對於七層係統，特別是HTTPS的業務進行了優化，實現了高性能硬加解卡，並且能夠實現使HTTPS的業務單實例可達10萬QPS。
- 超大並發連接數。性能保障型實例的單實例的並發連接數可達500萬，所以其可承載物聯網場景的下海量連接，可以支撐共享自行車、智能手表等存在特別大量長連接的場景。
- 共享型實例平滑升級。原有的共享型實例可以平滑升級至性能保障型實例，而無需更換VIP。
- 完善的業務監控係統。在推出性能保障型實例之後，因為每個實例都有相應的性能規格和性能指標，所以阿裏雲也為用戶提供了完整的業務指標監控係統，並支持電話、短信、釘釘企業群等方式的告警。
性能規格
如何選擇規格
- 最大連接數：一個實例可承載的最大連接數。
- 新建連接數：CPS表示一個實例每秒可以新建的鏈接數。
- 每秒查詢數：QPS表示一個實例7層的像HTTP或者HTTPS係統的吞吐量。
通常一個4層SLB的性能好壞由最大連接數和新建連接數來衡量，它們表示了一個SLB係統的並發能力和處理突發連接的能力。通常一個7層SLB的性能好壞主要由QPS決定，QPS表示了一個7層係統的吞吐量。這裏需要注意的是QPS是7層獨有概念。雖然每個規格都定義了三個性能指標，但是這並不代表這三個性能指標在任何一個性能場景下或者任何一個時刻都能夠同時達到最大值，這裏存在一個性能指標的短木板原則。比如在某一個應用係統中，QPS已經達到指標上限，但最大連接數還遠遠沒有達到上限，這時不論怎樣加大客戶端數量，最大連接數都會因為QPS達到上限，而無法達到最大值。
對於規格的選擇而言，需要通過之前提到的業務監控係統來獲取相關指標。如果用戶十分了解自己業務的相關指標，也就是對於高峰期的並發連接數會達到多少以及QPS會達到多少都有非常清晰的了解，也可以直接在控製台上選購。但是如果用戶並不清楚自己的相關業務指標，可以在初期選購按量付費的較高規格的實例，並且在一個業務周期內監控流量的峰值，在峰值確定好之後再通過變配的方式改變到比較合適的實例規格。目前性能保障型實例還處於公測階段，所以現在還沒有對於實例收取規格費用，也就是說在這個階段無論用戶選擇最小規格還是最大規格，實際上都隻需要花費IP配置費和帶寬費就可以了，這樣也比較便於用戶去熟悉和使用阿裏雲的性能保障型實例。
監控和告警
四、為什麼健康檢查異常
健康檢查機製
接下來分享在負載均衡的日常使用中出現的問題，特別是很多用戶都存在疑問的健康檢查部分的問題。
阿裏雲的負載均衡一共可以支持四種協議，四層的負載均衡係統主要包括了TCP、HTTP以及UDP協議，而七層的係統則包括了HTTP和HTTPS，而由於目前HTTP和HTTPS都是使用的普通的HTTP方式，所以其實也可以歸結為三類協議。對於TCP而言，健康檢查的過程是通過發送ACK這種TCP的探測報文去探測端口是否仍然存活；對於HTTP而言，則主要使用的是HEAD的請求方式來檢查目標的頁麵是否正常；UDP部分則主要借鑒了SMP協議的原理。
為啥會失敗(TCP)
TCP的健康檢查也經常會出現一些失敗的情況，這裏也為大家提供了簡單的故障排查順序供參考。當出現健康檢查失敗的時候，首先可以檢查一下後端的服務器是否已經啟動。如果後端服務器的負載是比較高的，也可能會因為沒有CPU時間去處理健檢查的回應，這樣就有可能導致健康檢查失敗。除此之外，因為對於阿裏雲的負載均衡而言，健康檢查使用的都是私網地址實現的，所以如果根本沒有監聽到私網地址或者私網地址本身存在故障也會導致健康檢查的失敗。還有服務器上可能存在防火牆，將監聽端口屏蔽掉了，導致健康檢查並未通過。此外還可能存在一些配置方麵的問題，比如提供服務的端口和做健康檢查的端口不一致也可能存在健康檢查失敗。
為啥會失敗(HTTP)
為啥會失敗(UDP)
這裏介紹一下UDP健康檢查的原理。首先，健康檢查通過SLB向後端發送UDP報文探測來獲取狀態信息。SLB會周期性地給後端ECS發送UDP報文，如果UDP端口的業務處於正常情況，則沒有任何回應。而當服務出現問題，比如指定的UDP服務端口處於不可達的情況或者無服務的狀態的時候，會回複ICMP的不可達報文。這裏也會存在一個問題就是如果後端服務器已經變成了網絡中的孤島，比如出現了整個服務器的掉電、關機情況這樣完全不能工作的狀態，這時候的ICMP不可達報文是永遠不可能收到的，因為後端的服務器無法收到SLB發來的UDP探測報文，那麼在這種情況下，可能會出現誤認為後端健康的情況，但是實際上這個服務可能已經宕掉了。為了應對這種情況，健康檢查還提供用戶自定義UDP應答報文來實現精確的UDP健康檢查，也就是由用戶自定義指定一個字符串，當後端的雲服務器收到UDP健康檢查的探測的時候，也回應指定的字符串，之後SLB對於這個字符串進行對比和校驗，如果匹配成功則認為服務一定是健康的，這樣就可以實現非常精確的健康檢查。
其他問題
健康檢查時好時壞的可能原因如下：
- HTTP類型健康檢查目標URI響應慢。比如本身是動態頁麵，會涉及到大量的計算才能夠渲染完成並返回到前端，這樣肯定就會導致健康檢查響應比較慢。如果服務器負載過高同樣也會出現這樣的問題。
- 未全部放開對SLB健康檢查源地址的限製導致分布式健康檢查失敗。因為阿裏雲的服務器都是分布式的部署，健康檢查也會是分布式的探測，LVS等機器在後端有不同的源去針對某一個雲服務器進行探測的，所以如果沒有將這些源地址都放開，實際上也會影響健康檢查的效率，因為對於這麼多機器而言，隻要有一台機器檢測到是正常的那麼就是正常的。
還可能出現直接訪問正常，但是健康檢查失敗的情況。造成這樣情況的可能原因如下：
- 防火牆限製。
- 目的端口不一致。
- 檢查方法不同，可能使用瀏覽器看頁麵是沒問題的，但是健康檢查卻不行，這就是因為剛才所提到的HEAD方法沒有開啟。或者七層的健康檢查配置了URL按照域名轉發，但是在瀏覽器上直接訪問則是使用域名去做的，而健康檢查是使用IP地址做的，這樣也可能出現轉發和預期結果的不同。
- 檢查頻率不同，ICMP限速。
五、為什麼負載不均衡
調度算法與會話保持
首先介紹一下負載均衡的調度算法。阿裏雲的負載均衡支持三種算法，第一種算法是單純的輪詢(RR)，也就是將業務的請求依次地分發到後端的服務器。第二種算法是加權輪詢(WRR)，也就是在處理調度的時候會根據針對於每一台後端服務器設置權重來進行轉發。這裏之所以設置權重是因為後端服務器的處理能力可能是不同的，如果使用相同的權重進行輪詢可能就會把後端處理能力比較弱的服務器擠爆，所以需要針對於服務器的處理能力設置一些權重。第三種算法是針對於加權最小連接數的輪詢(WLC)，也就是除了根據每台後端服務器設定的權重值來進行輪詢，同時還考慮後端服務器的實際負載，也就是連接數。當權重值相同時，當前連接數越小的後端服務器被輪詢到的次數也越高，這樣就能夠保證負載盡量地均衡。如果不考慮這一點就會造成某些服務器連接數已經很高了但是流量依然還往上麵分發，而另外一些服務器卻一直處於空閑狀態。
為何不均衡
最後分享一下不均衡的常見情況。有時候會需要新加一個服務器進來，這時候往往到新加進來的服務器上的連接會很少，這是因為可能會存在以下原因：
- 存在會話保持的情況下，會話保持會讓請求停留在原有的服務器上，這樣到新加進來的服務器上的連接自然會少一些。
- 權重設置不一致，如果在權重的設置上存在區別，而新加進來的服務器的權重如果很低，連接也過不去。
- 應用屬於長連接類型，因為需要在TCP上複用，如果客戶端不主動斷開連接，後續所有的請求都會繼續複用當前服務器上的連接，隻有新建連接才有可能到新的服務器上。
而有時候在業務量或者新建連接較少時，也會出現負載不均衡的問題。這是因為每個Core都是獨立的調度單元，因此可能存在將某個Client的多條業務經過不同core的調度後全部轉發到一台ECS上的情況，同時由於業務量較少，因此出現了不均衡。建議使用輪詢算法解決，在RR輪詢算法中加入了擾亂因子，可以更加有效的打散SLB到後端的轉發路徑。
如何使用性能保障型實例：https://help.aliyun.com/document_detail/57737.html
健康檢查相關文檔：https://help.aliyun.com/knowledge_detail/39455.html
會話保持常見問題：https://help.aliyun.com/knowledge_detail/55202.html
最後更新：2017-10-09 22:35:10