摘要：的運行狀態(tài)是指什么運行是指整個負載均衡的狀態(tài)，只要后端服務(wù)器有一臺存活，負載均衡還是運行狀態(tài)。需注意的是，后端狀態(tài)由負載均衡健康檢查確定。輪詢算法能否使所有服務(wù)節(jié)點請求數(shù)均衡負載均衡的輪詢算法是針對連接的。

ULB的會話保持是如何實現(xiàn)的？

請求代理

請求代理模式下（HTTP、HTTPS），會話保持功能是利用cookie實現(xiàn)的。ULB會向源端寫cookie，并根據(jù)請求帶有的cookie信息，直接將請求送給對應(yīng)的后端主機。

• 自動生成KEY：選擇自動生成key，客戶端的cookie插入操作都由ULB來分配和管理。
• 用戶自定義KEY：用戶自定義key，ULB使用客戶的key來分配和管理對客戶端進行的Cookie插入操作

TCP協(xié)議的請求代理模式，不支持會話保持。

報文轉(zhuǎn)發(fā)

報文轉(zhuǎn)發(fā)模式下（TCP、UDP），會話保持功能是基于IP地址的會話保持。ULB會將來自同一IP地址的訪問請求轉(zhuǎn)發(fā)到同一臺后端云服務(wù)器進行處理。

VServer的運行狀態(tài)是指什么？

"運行"是指整個負載均衡的狀態(tài)，只要后端服務(wù)器有一臺存活，負載均衡還是運行狀態(tài)。

后端服務(wù)器的狀態(tài)通過綠色/紅色指示燈表示。

需注意的是，后端狀態(tài)由負載均衡健康檢查確定。如果健康檢查失敗，即使服務(wù)器還能ping通，也認為是宕機。

VServer的運行狀態(tài)是指什么？

"運行"是指整個負載均衡的狀態(tài)，只要后端服務(wù)器有一臺存活，負載均衡還是運行狀態(tài)。

后端服務(wù)器的狀態(tài)通過綠色/紅色指示燈表示。

需注意的是，后端狀態(tài)由負載均衡健康檢查確定。如果健康檢查失敗，即使服務(wù)器還能ping通，也認為是宕機。

ULB健康檢查機制是如何工作的？

健康檢查

ULB健康檢查可判斷后端服務(wù)器是否正常，對于異常的后端服務(wù)器，ULB將其從后端服務(wù)器池中移除，客戶端請求將會在其他服務(wù)器之間進行分發(fā)。對于處于異常狀態(tài)的服務(wù)器恢復(fù)正常時，會被ULB恢復(fù)至后端服務(wù)器池中。

端口檢查

ULB在每個可用區(qū)內(nèi)部署專用服務(wù)器對會探測后端節(jié)點的IP+端口是否正常。探測頻率為2s，連續(xù)三次探測失敗后端服務(wù)器狀態(tài)異常，連續(xù)三次探測正常，則后端服務(wù)器狀態(tài)正常。注意：數(shù)據(jù)更新有6s延遲，故健康檢查狀態(tài)或有6s延遲。

所有協(xié)議均支持端口檢查。但檢測狀態(tài)略有不同：HTTP、HTTPS以及TCP的請求代理模式的端口檢查是用TCP進行探測。而TCP的報文轉(zhuǎn)發(fā)模式及UDP協(xié)議則是使用選擇的四層協(xié)議做端口探測。

HTTP檢查

通過HTTP HEAD請求檢查后端服務(wù)器上的應(yīng)用是否可用。要求后端服務(wù)器支持HEAD請求。

用戶使用HTTP健康檢查，需要配置HTTP檢查路徑（如果有必要的話，也可以配置HTTP的檢查域名，一般不需要填寫），兩者拼接組成了HTTP檢查的URL，ULB會對此URL發(fā)起HTTP HEAD請求，請求響應(yīng)碼為2xx或3xx則認為后端服務(wù)器正常。健康檢查探測周期為2s，連續(xù)3次探測失敗后端節(jié)點變更為不健康，連續(xù)兩次正常變更為健康。

HTTP檢查路徑，最多為227個字符，直接填寫域名或IP地址后的相對路徑文件。可以選擇首頁、出現(xiàn)異常概率較小的頁面、專門為健康檢查準備的空文件（HTTP HEAD請求可以獲得200的響應(yīng)碼即可），選擇首頁可能會加大服務(wù)器壓力，不建議選擇首頁作為HTTP健康檢查的域名和路徑。

HTTP檢查域名，不建議填寫"http:"或"https:"，直接填寫域名或IP地址即可。支持主域名、二級域名等多級域名。

HTTP檢查支持的協(xié)議:HTTP協(xié)議、HTTPS協(xié)議（七層服務(wù)）。

ULB如何獲取客戶端的源地址？

ULB支持報文轉(zhuǎn)發(fā)、請求代理兩種類型。報文轉(zhuǎn)發(fā)型支持TCP、UDP等協(xié)議，請求代理型支持HTTP、HTTPS、TCP等協(xié)議。

報文轉(zhuǎn)發(fā)模式下，后端服務(wù)節(jié)點收到的請求的源地址就是實際的源地址。

請求代理模式下，HTTP協(xié)議中，ULB已經(jīng)默認開啟了x-Forwarded-For選項，可以從HTTP報頭中的X-Forward-For字段中獲取客戶端的源地址。TCP協(xié)議無法返回源地址。

Nginx示例
log_format  upstream  $time_iso8601 $http_x_forwarded_for $host $upstream_response_time $request $status $upstream_addr;

Apache示例
SetEnvIf REMOTE_ADDR "(.+)" CLIENTIP=$1
SetEnvIf X-Forwarded-For "^([0-9.]+)" CLIENTIP=$1
LogFormat "%{CLIENTIP}e %D %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" trueip_combined
CustomLog logs/access_log trueip_combined

tomcat 的server.xml文件修改如下參數(shù)：
    se="webapps" 
        unpackWARs="true" autoDeploy="true"> 
         

服務(wù)節(jié)點收到大量內(nèi)網(wǎng)IP的訪問是否正常？

收到的大量內(nèi)網(wǎng)IP的訪問是正常的。 ULB在請求代理模式下，對后端服務(wù)節(jié)點轉(zhuǎn)發(fā)請求時，使用的是 ULB的內(nèi)網(wǎng)代理IP。

例如，用戶在北京二的后端云主機訪問日志中發(fā)現(xiàn)大量來自 10.10.251.0/24 網(wǎng)段的訪問，即為北京二 ULB 的內(nèi)網(wǎng)代理 IP。

ULB 在各個區(qū)域的代理IP網(wǎng)段見公共服務(wù)網(wǎng)段。

如何禁止某些源地址訪問后端服務(wù)節(jié)點？

ULB支持防火墻功能，使用方式如下：

• 創(chuàng)建負載均衡的時候綁定防火墻，或在ULB的詳情頁中，進入“外網(wǎng)防火墻”tab頁面進行防火墻的綁定。

注意：

• 防火墻僅對請求代理型、外網(wǎng)模式下的ULB實例生效。
• 在配置防火墻的過程中，如果需要對某個請求代理模式的VServer進行白名單/黑名單限制，需配置防火墻中VServer對應(yīng)端口的允許/拒絕策略。由于防火墻的默認行為是拒絕，因此配置防火墻的時候請務(wù)必添加VServer相應(yīng)端口的相應(yīng)源地址放行規(guī)則，避免影響業(yè)務(wù)。

輪詢算法能否使所有服務(wù)節(jié)點請求數(shù)均衡？

負載均衡的輪詢算法是針對連接的。同一個TCP連接，不會被同時負載到兩臺后端服務(wù)器。若同一個連接上會發(fā)送數(shù)量不確定的多個請求，則可能會導(dǎo)致后端服務(wù)器上統(tǒng)計到的請求數(shù)不同。

ULB服務(wù)器是否會宕機？

ULB采用集群架構(gòu)，基于跨可用區(qū)的分布式部署，利用BGP+ECMP實現(xiàn)集群的自動容災(zāi)，保證在可用區(qū)級別的災(zāi)難下，依舊可以正常工作。

ULB錯誤碼有哪些？

ULB的錯誤碼基本是遵循HTTP的規(guī)范。

客戶端錯誤，返回4XX

• 400 Bad request：Your browser sent an invalid request.
• 403 Forbidden：Request forbidden by administrative rules.
• 408 Request Time-out：Your browser didnt send a complete request in time.

服務(wù)器錯誤，返回5XX

• 500 Server Error：An internal server error occured.
• 502 Bad Gateway：The server returned an invalid or incomplete response.
• 503 Service Unavailable：No server is available to handle this request.
• 504 Gateway Time-out：The server didnt respond in time.

VServer端口和服務(wù)節(jié)點端口是否必須一致？

不一定要保持一致，如要實現(xiàn)ULB報文轉(zhuǎn)發(fā)監(jiān)聽端口和后端服務(wù)器監(jiān)聽端口不一致，可以通過服務(wù)節(jié)點內(nèi)配置IpTables端口轉(zhuǎn)發(fā)規(guī)則實現(xiàn)，具體步驟如下：

1、修改/etc/sysctl.conf配置文件，設(shè)置 net.ipv4.ip_forward = 1 默認是0。
2、關(guān)閉防火墻 service iptables stop。
3、配置規(guī)則：

iptables -t nat -A PREROUTING –d $vip_ip -p tcp --dport $ulb4_port  -j DNAT --to-destination $vip_ip:$vm_port

其中：$vip\_ip指負載均衡器的內(nèi)網(wǎng)服務(wù)IP地址，$ulb4_port指ulb4的監(jiān)聽端口，$vm_port為后端服務(wù)器的監(jiān)聽端口 例：負載均衡器的內(nèi)網(wǎng)服務(wù)IP地址為：10.10.10.10，ulb_4監(jiān)聽端口為80，后端服務(wù)器監(jiān)聽端口為8101，則規(guī)則為：

iptables -t nat -A PREROUTING -d 10.10.10.10 -p tcp --dport 80 -j DNAT --to-destination 10.10.10.10:8101

4、保存配置：service iptables save
5、啟動iptables ：service iptables start

內(nèi)網(wǎng)ULB的IP地址為何無法ping通？

內(nèi)網(wǎng)ULB僅保證支持同子網(wǎng)能ping通，可通過端口的測試來確認內(nèi)網(wǎng)ULB是否配置和工作正常。

對ULB壓測時為何會出現(xiàn)連接失敗？

通常情況下，在使用Linux操作系統(tǒng)作為壓測模擬客戶端時，當壓測性能達到ULB極限前，不會出現(xiàn)連接失敗的情況。

但對于使用Windows作為壓測的模擬客戶端時，可能會出現(xiàn)TCP連接失敗的問題。這是由于在壓測場景下，Windows系統(tǒng)會快速復(fù)用客戶端IP和端口發(fā)起TCP連接的建立，而在被壓測ULB的后端Linux服務(wù)節(jié)點上TCP協(xié)議棧中，以相同的源地址及端口所建立的TCP連接可能尚未被釋放完畢，若此時如果 "新建連接的序列號" 大于 "已存在連接的序列號"，Linux服務(wù)節(jié)點就會認為新建連接的SYN請求是已存在連接的重傳，從而導(dǎo)致新的TCP連接建立失敗。

所以在對ULB進行壓測時，請盡量使用Linux作為壓測模擬客戶端，如果必須使用Windows系統(tǒng)作為壓測模擬客戶端，則需添加系統(tǒng)注冊表中關(guān)于TCP時間戳的選項，該選項默認在Windows系統(tǒng)中是未激活的，具體配置參見 Windows幫助文檔 。

最新產(chǎn)品文檔請關(guān)注：https://docs.ucloud.cn/ulb/newfunctions