真正零停機(jī) HAProxy 重載

Patagonia

　　
   
        
            
            Yelp 礎(chǔ)設(shè)施團(tuán)隊(duì)的主要目標(biāo)之一就是為了盡可能接近零停機(jī)時(shí)間。那也就是說(shuō)當(dāng)用戶訪問(wèn)www.yelp.com 作出動(dòng)作的時(shí)候，網(wǎng)站的響應(yīng)速度必須盡可能的快。一種方法是使用 HAProxy 負(fù)載均衡能夠保持 www.yelp.com 網(wǎng)站的響應(yīng)速度。通常我們?cè)谌魏蔚胤蕉际褂?HAProxy 來(lái)保持網(wǎng)站的外部負(fù)載均衡、內(nèi)部負(fù)載均衡，甚至運(yùn)用到構(gòu)建面向服務(wù)的架構(gòu)中。我們發(fā)現(xiàn)在 Yelp 的每臺(tái)機(jī)器上運(yùn)行 HAProxy，均可作為 SmartStack 的一部分。
            
            我們喜歡在發(fā)展 SOA 的時(shí)候使用 SmartStack 給我們帶來(lái)的靈活性，但這種靈活性是有代價(jià)的。通常當(dāng)服務(wù)或在服務(wù)后端執(zhí)行增加或永久刪除命令的的時(shí)候，整個(gè)基礎(chǔ)設(shè)施不得不重新加載 HAProxy 。這種重載方式會(huì)導(dǎo)致可靠性問(wèn)題，因?yàn)?HAProxy 一旦運(yùn)轉(zhuǎn)起來(lái)就一直保持在工作狀態(tài)且不會(huì)中斷流量，但在重載的時(shí)候它會(huì)中斷流量。
            
            
            
            
            
        
   
   
        
            
            
            HAProxy 重載丟流量
            HAProxy 的 1.5.11 版本不支持重啟或重新加載配置時(shí)的零停機(jī)時(shí)間。相反，它支持快速重載——當(dāng)一個(gè)新的 HAProxy 實(shí)例啟動(dòng)時(shí)，它嘗試使用
SO_REUSEPORT
去綁定老 HAProxy 監(jiān)聽的相同端口并給老 HAProxy 實(shí)例發(fā)送信號(hào)去關(guān)閉。這種技術(shù)非常接近現(xiàn)代 Linux 內(nèi)核的零停機(jī)時(shí)間，但這仍舊會(huì)經(jīng)歷一個(gè)短暫的時(shí)隙——當(dāng)兩個(gè)進(jìn)程都綁定到端口時(shí)。在這個(gè)關(guān)鍵的時(shí)隙中，由于Linux內(nèi)核自身
（丟棄）處理
多個(gè)接受進(jìn)程的方式可能有流量會(huì)被丟掉。特別要提出來(lái)的，這個(gè)問(wèn)題會(huì)潛在導(dǎo)致從 HAProxy 過(guò)來(lái)的新連接有一個(gè) RST。這個(gè)問(wèn)題是 SYN 包在老 HAProxy 被調(diào)用關(guān)閉前會(huì)被先放進(jìn)其套接字隊(duì)列中，這導(dǎo)致了這些連接的 RST。
            這個(gè)問(wèn)題有許多解決辦法。例如，Willy Tarreau，HAProxy 的主要維護(hù)者，建議用戶在重啟 HAProxy 時(shí)
丟掉 SYN 包
，利用 TCP 的自動(dòng)修復(fù)。不幸的是，
RFC 6298
規(guī)定的初始 SYN 的超時(shí)時(shí)間是1s，Linux 內(nèi)核
堅(jiān)守此規(guī)定
。因此，丟棄 SYN 意味著任何試圖在 HAProxy 加載的 20-50ms 之間重建的連接將會(huì)遭受一個(gè)額外的秒級(jí)或更長(zhǎng)的延遲。確切的時(shí)間依賴于客戶端的 TCP 實(shí)現(xiàn)，而一些移動(dòng)設(shè)備重試時(shí)間為 200ms，很多設(shè)備只在 3S 后重試。鑒于 HAProxy 重載的次數(shù)和和 Yelp 的流量，這成為了我們服務(wù)可靠性的一個(gè)障礙。
            
            
        
   
   
        
            
            
            讓HAProxy重載不丟包
            
            為了避免延遲，我們采用了Willy提議的方案。他的方案實(shí)際上在不丟棄數(shù)據(jù)包上表現(xiàn)很好，但是額外的一秒延時(shí)是個(gè)問(wèn)題。我們更好的解決方案是延遲SYN包直到重載已經(jīng)完成，因?yàn)檫@樣做只會(huì)對(duì)新的連接產(chǎn)生HAProxy重載所需要的延遲。 為了實(shí)現(xiàn)這種方案，我們求助于Linux隊(duì)列原則 (qdiscs)。Linux隊(duì)列原則是用來(lái)管理Linux內(nèi)核處理網(wǎng)絡(luò)數(shù)據(jù)包的方式。具體地說(shuō)就是你可以控制數(shù)據(jù)包是如何入隊(duì)和出隊(duì)，這提供了速率限制，優(yōu)先或指定輸出數(shù)據(jù)包的能力。有關(guān)更多qdiscs的詳情， 我極力推薦
lartc howto
以及相關(guān)的man頁(yè)面。
            我們的一個(gè)SRE（網(wǎng)站可靠性工程師），Josh Snyder花了一些晚上的時(shí)間閱讀了Linux內(nèi)核源代碼，發(fā)現(xiàn)了一個(gè)文檔記錄很少的工具：plug排隊(duì)原則(qdisc)，qdisc是從Linux 3.4以來(lái)就存在了。使用plug qdisc和以下標(biāo)準(zhǔn)Linux技術(shù)， 我們可以實(shí)現(xiàn)HAProxy重載零宕機(jī)：
            

               
• 
                 
  tc
  :Linux流量控制。這使我們能夠建立基于過(guò)濾器路由連接的排隊(duì)規(guī)則。在最新的Linux版本上自帶libnlutils，它提供了一些較新的qdiscs接口（如plug qdisc）。
                 
                 
• 
                 
  iptables
  :用于包過(guò)濾和NAT（網(wǎng)絡(luò)地址轉(zhuǎn)換）的Linux工具。這個(gè)工具允許我們標(biāo)識(shí)進(jìn)入的SYN包。
                   
                 
              

            SmartStack客戶端連接到loopback接口向HAProxy請(qǐng)求，HAProxy幸好將進(jìn)入的包變成為輸出包。這意味著我們可以在loopback接口上建立如圖1的隊(duì)列原則。
            
            
            

             Figure 1: Queueing Discipline
            
            
        
   
   
        
            
            
            該設(shè)置的一個(gè)分類實(shí)現(xiàn)了使用 prio qdisc 隊(duì)列規(guī)定的標(biāo)準(zhǔn)
pfifo_fast
，但只是使用了第四個(gè)“plug“通道。plug qdisc 并沒(méi)有使他們退出隊(duì)列，而是擁有隊(duì)列數(shù)據(jù)包的性能。與一個(gè) iptables 命令相結(jié)合的性能來(lái)允許我們?cè)谡麄�(gè) HAProxy 重載期間重新定向，然后拔掉后重載的 SYN 插頭的數(shù)據(jù)包。該控鍵（‘1:1’, ‘30:’等等）是允許我們一起連接 qdiscs，并且使用過(guò)濾器發(fā)送特定 qdiscs 的數(shù)據(jù)包。有關(guān)更多的信息，請(qǐng)查閱 lartc howto上面所引用的。
            然后，我們把我們調(diào)用 qdisc_tool 的這個(gè)功能編進(jìn)腳本。該工具允許我們的基礎(chǔ)設(shè)施“保護(hù)”HAProxy 重載我們 plug 流量，重啟haproxy,然后松開這個(gè)插頭，交付延遲所有的 SYN 數(shù)據(jù)包。這個(gè)調(diào)用看起來(lái)像：
            qdisc_tool protect
            由
GitHub
托管的
qdisc 命令
            我們可以輕易地在諸如 Ubuntu Trusty 的 linux 發(fā)行版本上使用標(biāo)準(zhǔn)的用戶空間實(shí)用工具來(lái)復(fù)制該技術(shù)。如果你的設(shè)置并沒(méi)有 nl-qdisc-add，但有3.4+ Linux 內(nèi)核，那么你可以通過(guò)
netlink
來(lái)手動(dòng)地操縱該插頭。
            ，
            
            
        
   
   
        
            
            
            設(shè)置隊(duì)列規(guī)則
            在我們優(yōu)雅重載HAProxy之前，我們必須先使用tc和nl-qdisc-add設(shè)置上面提到的隊(duì)列規(guī)則。注意下面的每個(gè)命令必須以root運(yùn)行。
            
            
            
               
                    
                        
                        
                        # Set up the queuing discipline
                        tc qdisc add dev lo root handle 1: prio bands 4
                        tc qdisc add dev lo parent 1:1 handle 10: pfifo limit 1000
                        tc qdisc add dev lo parent 1:2 handle 20: pfifo limit 1000
                        tc qdisc add dev lo parent 1:3 handle 30: pfifo limit 1000
                        # Create a plug qdisc with 1 meg of buffer
                        nl-qdisc-add --dev=lo --parent=1:4 --id=40: plug --limit 1048576
                        # Release the plug
                        nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug --release-indefinite
                        # Set up the filter, any packet marked with “1” will be
                        # directed to the plug
                        tc filter add dev lo protocol ip parent 1:0 prio 1 handle 1 fw classid 1:4
                        
                        
                    
               
            
            
            
            
setup_qdisc.sh   
在
GitHub
上
            生成 SYN 包
            我們希望所有的 SYN 包被路由到塞入通道，這我們可以通過(guò) iptables 實(shí)現(xiàn)。我們使用一個(gè)本地鏈路地址，以便我們?cè)谥剌d時(shí)重定向我們想要的流量，客戶如果希望避免塞入可以生成一個(gè)請(qǐng)求到127.0.0.1，這是一直可用的一個(gè)選項(xiàng)。請(qǐng)注意，這是假設(shè)你已經(jīng)建立了一個(gè)連接到 169.254.255.254的本地鏈路。
            
            
            
               
                    
                        
                        
                        iptables -t mangle -I OUTPUT -p tcp -s 169.254.255.254 --syn -j MARK --set-mark 1
                        
                        
                    
               
            
            
            
            
setup_iptables.sh
在
GitHub
上
            
            重載時(shí)觸發(fā)塞入
            一旦一切都成立，我們優(yōu)雅重載 HAProxy 所需要做的是：在重載前緩存 SYN，重載，然后在重載后釋放所有 SYN。這將導(dǎo)致任何嘗試在重啟過(guò)程中嘗試建立的連接經(jīng)歷一個(gè)延遲，這個(gè)延遲等于 HAProxy 重啟時(shí)間。              
            
            
            
               
                    
                        
                        
                        nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug --buffer
                        service haproxy reload
                        nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug --release-indefinite
                        
                        
                    
               
            
            
            
            
plug_manipulation.sh
在
GitHub
上
            在生產(chǎn)中我們觀察到這項(xiàng)技術(shù)對(duì)重啟過(guò)程中的新進(jìn)連接增加了約 20ms 的延遲，但沒(méi)有請(qǐng)求被丟棄。
            
            
        
   
   
        
            
            
            設(shè)計(jì)的權(quán)衡
            這個(gè)設(shè)計(jì)具有一定的優(yōu)點(diǎn)和缺點(diǎn)。最大的缺點(diǎn)是其只針對(duì)傳出連接而不針對(duì)傳入的流量。其原因是隊(duì)列規(guī)則在 Linux 上的工作方式，既你只能對(duì)傳出的流量整形。而對(duì)于傳入的流量，首先必須重定向到一個(gè)中介接口，然后再對(duì)中介接口的傳出流量進(jìn)行整形。我們正在研究類似的集成解決方案以應(yīng)用在我們外部的負(fù)載均衡器中，但尚未投入生產(chǎn)環(huán)境。
            此外，qdiscs 也應(yīng)該調(diào)整地更有效。例如，我們以第一優(yōu)先級(jí)將 qdisc 塞入，并調(diào)整 priomap 從而確保 SYN 包總是先于其他包被處理，或者調(diào)整 pfifo/qdiscs 的緩沖器大小。我認(rèn)為這些可以在非環(huán)回口的接口上應(yīng)用，塞入插件必須在第一優(yōu)先級(jí)以確保 SYN 的輸送能力。
            
            
        
   
   
        
            
            
            我們決定采用這種解決方案而不是
huptime
，修改傳遞到 HAProxy 的文件描述符，或在多個(gè)本地HAProxy 實(shí)例之間跳轉(zhuǎn)的原因是因?yàn)槲覀冋J(rèn)為采用 qdisc 方案的風(fēng)險(xiǎn)是最低的。huptime 被很快地排除，因?yàn)橛捎谝粋�(gè)老的 libc 版本，我們無(wú)法讓它在我們的機(jī)器上運(yùn)行正常，并且我們也不確定LD_PRELOAD 機(jī)制是否會(huì)在一些復(fù)雜如 HAProxy 上工作。一個(gè)工程師在一個(gè)黑客馬拉松上概念驗(yàn)證式地實(shí)施了文件描述符補(bǔ)丁，但是補(bǔ)丁的復(fù)雜性以及有可能引入大量分叉促使我們放棄了這個(gè)想法。它表明合理地文件描述符傳遞真的是困難的。 在這三種方案里面，我們最嚴(yán)肅地考慮過(guò)在同一臺(tái)機(jī)器上運(yùn)行多個(gè) HAProxy 實(shí)例，使用 NAT,nginx 或另一個(gè) HAProxy 實(shí)例來(lái)做切換。最終我們否決了這種方案因?yàn)橛性S多的實(shí)施不確定因素，以及基礎(chǔ)架構(gòu)的維護(hù)等級(jí)。
            
            使用我們的解決方案，我們基本保持零基礎(chǔ)設(shè)施，相信 Linux 內(nèi)核和 HAProxy 可以處理。這幾個(gè)月里， 這個(gè)方案一直在生產(chǎn)環(huán)境運(yùn)行，我們沒(méi)有發(fā)現(xiàn)任何問(wèn)題，這種方案沒(méi)有辜負(fù)我們的信任。
            
            
        
   
   
        
            
            
            實(shí)驗(yàn)性安裝
            為了證明這個(gè)解決方案確實(shí)有效，我們可以啟動(dòng)一個(gè)nginx HTTP后端，與此同時(shí)HAProxy作為前端，Apache Benchmark產(chǎn)生很多流量，當(dāng)我們重啟HAProxy的時(shí)候，我們來(lái)看看發(fā)生了什么。我們可以用這種方式評(píng)估不同的解決方案。
            所有的測(cè)試都是在一個(gè)新的c3.large AWS機(jī)器上用Ubuntu Trusty和3.13 Linux內(nèi)核進(jìn)行的。HAProxy 1.5.11被編譯在本地，用TARGET=linux2628（編譯命令）。Nginx使用默認(rèn)配置方式啟動(dòng)，并在8001端口進(jìn)行監(jiān)聽，服務(wù)器發(fā)送一個(gè)簡(jiǎn)單的“pong”回答用來(lái)代替默認(rèn)的html。我們編譯HAProxy的
基本配置
，它有一個(gè)單獨(dú)的后端，端口是8001，與之對(duì)應(yīng)的前端端口是16000。
            僅重新加載HAProxy
            在這個(gè)實(shí)驗(yàn)里，我們僅僅重啟HAProxy，使用‘-sf’選項(xiàng)，它會(huì)以最快速度進(jìn)行重啟處理。這是一個(gè)不那么真實(shí)的測(cè)試，因?yàn)槲覀兠?00ms重啟一次HAProxy，但是這個(gè)實(shí)驗(yàn)可以說(shuō)明這一點(diǎn)（解決方案是否有效）。
            
            
        
        
        
   
   
        
            
            
            實(shí)驗(yàn)
            
            
            
               
                    
                        
                        
                        # Restart haproxy every 100ms
                        while [ 1 ]; do
                           ./haproxy -f /tmp/haproxy.cfg -p /tmp/haproxy.pid -sf $(cat /tmp/haproxy.pid)
                           sleep 0.1
                        done
                        
                        
                    
               
            
            
            
            
reload_experiment.sh
在
GitHub
上
            結(jié)果            
            
            
            
            
               
                    
                        
                        
                        $ ab -c 10 -n 10000 169.254.255.254:16000/
                        Benchmarking 169.254.255.254 (be patient)
                        ...
                        apr_socket_recv: Connection reset by peer (104)
                        Total of 3652 requests completed
                        
                        
                    
               
            
            
            
            
重加載結(jié)果
托管在
GitHub
上
            socket 重置了！重啟HAProxy已經(jīng)導(dǎo)致了失敗請(qǐng)求，即便我們的后端是正常的。下面讓我們告訴Apache基準(zhǔn)測(cè)試器來(lái)繼續(xù)接受錯(cuò)誤并生成更多的請(qǐng)求：
            
            
            
               
                    
                        
                        
                        $ ab -r -c 10 -n 200000 169.254.255.254:16000/
                        Benchmarking 169.254.255.254 (be patient)
                        ...
                        Complete requests:      200000
                        Failed requests:        504
                        ...
                        50%      2
                        95%      2
                        99%      3
                        100%     15 (longest request)
                        
                        
                    
               
            
            
            
            
reload_longer_result
托管在
GitHub
上
            只有 0.25% 的請(qǐng)求失敗。這也不是太壞，但仍高于我們 0 的目標(biāo)。
            
            
        
   
   
        
            
            
            丟掉 SYN 包，讓 TCP 做余下的工作
            現(xiàn)在讓我們嘗試下丟掉 SYN 包的方法。這個(gè)方法可以以高的重啟速率以達(dá)到重試連接的效果，為得到可靠的結(jié)果我每秒重啟一次 HAProxy。
            實(shí)驗(yàn)                           
            
            
            
            
               
                    
                        
                        
                        # Restart haproxy every second
                        while [ 1 ]; do
                          sudo iptables -I INPUT -p tcp --dport 16000 --syn -j DROP
                          sleep 0.2
                          ./haproxy -f /tmp/haproxy.cfg -p /tmp/haproxy.pid -sf $(cat /tmp/haproxy.pid)
                          sudo iptables -D INPUT -p tcp --dport 16000 --syn -j DROP
                          sleep 1
                        done
                        
                        
                    
               
            
            
            
            
iptables_experiment.sh
托管在
GitHub
            結(jié)果               
            
            
            
            
               
                    
                        
                        
                        $ ab -c 10 -n 200000 169.254.255.254:16000/
                        Benchmarking 169.254.255.254 (be patient)
                        ...
                        Complete requests:      200000
                        Failed requests:        0
                        ...
                        50%      2
                        95%      2
                        99%      6
                        100%   1002 (longest request)
                        
                        
                    
               
            
            
            
            
iptables_result
托管在
GitHub
            

            圖2: Iptables實(shí)驗(yàn)結(jié)果
            正如預(yù)期的那樣，我們沒(méi)有丟棄請(qǐng)求但收到了一個(gè)額外的一秒鐘的延遲。在請(qǐng)求繪制圖圖2中我們可以看到明顯地看到命中重啟時(shí)的兩個(gè)峰值，其需要滿滿的一秒來(lái)完成請(qǐng)求。小于百分之一的測(cè)試請(qǐng)求觀察到了高延遲，但這仍足以成為一個(gè)問(wèn)題。
            
            
        
   
   
        
            
            
            使用我們的平和重啟方法
            在這個(gè)實(shí)驗(yàn)中，我們將使用 ‘-sf’ 選項(xiàng)重啟HAProxy以使用我們的隊(duì)列策略來(lái)延時(shí)傳入的SYN包。為確保我們不是因?yàn)檫\(yùn)氣，我們做了一百萬(wàn)的請(qǐng)求。在本試驗(yàn)中我們對(duì)HAProxy重啟了1500次以上。
            實(shí)驗(yàn)               
            
            
            
            
               
                    
                        
                        
                        # Restart haproxy every 100ms
                        while [ 1 ]; do
                          sudo nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug --buffer &> /dev/null
                          ./haproxy -f /tmp/haproxy.cfg -p /tmp/haproxy.pid -sf $(cat /tmp/haproxy.pid)
                          sudo nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug--release-indefinite &> /dev/nullsleep 0.100
                        done
                        
                        
                    
               
            
            
            
            
tc_experiment.sh
托管在
GitHub
            結(jié)果               
            
            
            
            
               
                    
                        
                        
                        $ ab -c 10 -n 1000000 169.254.255.254:16000/
                        Benchmarking 169.254.255.254 (be patient)
                        ...
                        Complete requests:      1000000
                        Failed requests:        0
                        ...
                        50%      2
                        95%      2
                        99%      8
                        100%     29 (longest request)
                        
                        
                    
               
            
            
            
            
tc_result
托管在
GitHub
            

            圖3: TC實(shí)驗(yàn)結(jié)果
            成功啦！重啟HAProxy已基本對(duì)我們的流量沒(méi)有影響，在圖3中可以看僅造成了輕微的延遲。請(qǐng)注意，該方法主要依賴HAProxy重載配置所花費(fèi)的時(shí)間，由于我們使用了一個(gè)精簡(jiǎn)的配置，結(jié)果好的有點(diǎn)離譜。在我們的生產(chǎn)環(huán)境中，HAProxy重啟時(shí)我們能觀察到一個(gè)20ms的延遲影響。
            結(jié)論
            這項(xiàng)技術(shù)似乎在我們實(shí)現(xiàn)目標(biāo)——為開發(fā)構(gòu)建提供堅(jiān)實(shí)的基礎(chǔ)服務(wù)設(shè)施上運(yùn)行地很好。通過(guò)延遲SYN包進(jìn)入每臺(tái)機(jī)器上運(yùn)行的HAProxy負(fù)載均衡器，我們能夠最小化HAProxy重載所影響到的流量，這允許在達(dá)成我們SOA的情況下添加，刪除和更改服務(wù)后端，而不必恐懼該過(guò)程顯著影響用戶的流量。
            鳴謝
            感謝 Josh Snyder, John Billings 以及 Evan Krall 的優(yōu)秀設(shè)計(jì)及對(duì)討論的實(shí)現(xiàn)。
            
            
        
   
本文轉(zhuǎn)自：開源中國(guó)社區(qū) [http://www.oschina.net]
本文標(biāo)題：真正零停機(jī) HAProxy 重載
本文地址：
http://www.oschina.net/translate/zero-downtime-haproxy-reloads
參與翻譯：
Garfielt
,
吳利明
,
大胖森
,
何傳友
,
無(wú)若
英文原文：
True Zero Downtime HAProxy Reloads
                       
                               
                    
                               
                       
                       
                       
                                時(shí)間:2015-04-27 08:27
來(lái)源:開源中國(guó)社區(qū)
  作者:oschina
  
原文鏈接

本文來(lái)自ChinaUnix新聞?lì)l道，如果查看原文請(qǐng)點(diǎn)：http://news.chinaunix.net/opensource/2015/0427/3243893.shtml