距離今年9月份在兩天內(nèi)兩次宕機(jī)僅間隔3個(gè)月。12月22日，全球知名的開(kāi)源托管服務(wù)GitHub意外遭遇了歷史上最嚴(yán)重的一次宕機(jī)事件。GitHub官方確認(rèn)了本次宕機(jī)是在例行的軟件升級(jí)過(guò)程中發(fā)生的，本文將帶領(lǐng)大家回顧一下宕機(jī)事故。

　　背景

　　周六上午我們按計(jì)劃要做一次例行維護(hù)，以確保軟件在聚合交換機(jī)上的順利升級(jí)。這次升級(jí)是在網(wǎng)絡(luò)供應(yīng)商建議下進(jìn)行的，目的是為了解決早些時(shí)候發(fā)生的宕機(jī)事故。在此之前，我們已經(jīng)在類(lèi)似設(shè)備上做過(guò)多次測(cè)試都沒(méi)有出現(xiàn)任何意外，我們對(duì)本次升級(jí)也充滿(mǎn)了信心。然而，即便準(zhǔn)備充分，軟件升級(jí)仍然總是伴隨著風(fēng)險(xiǎn)，為此，我們預(yù)留了維護(hù)窗口期和技術(shù)支持人員提供電話(huà)服務(wù)，以防意外事件的發(fā)生。

　　問(wèn)題出在哪里？

　　在GitHub的網(wǎng)絡(luò)中，每一臺(tái)接入交換機(jī)，也就是每一臺(tái)服務(wù)器都連接著一對(duì)聚合交換機(jī)。這些聚合交換機(jī)成對(duì)安裝并通過(guò)一種叫做MLAG的功能來(lái)偽裝成一個(gè)單線(xiàn)路由，因?yàn)閘ink aggregation,spanning tree和其他layer 2協(xié)議希望有一個(gè)單獨(dú)的主設(shè)備。這使得我們能夠在一個(gè)聚合交換機(jī)上進(jìn)行升級(jí)，而不會(huì)影響其他合作伙伴交換機(jī)或其他接入連接的交換機(jī)。值得一提的是，我們之前已多次成功運(yùn)行過(guò)(MLAG)功能。

　　我們打算每次升級(jí)一臺(tái)聚合交換機(jī)，這一過(guò)程被稱(chēng)作在服務(wù)中軟件升級(jí)(in-service software upgrade)。即首先上傳新的軟件到一臺(tái)交換機(jī)，配置交換機(jī)后，在新版本上重新啟動(dòng)，并發(fā)出reload命令。余下的交換機(jī)探測(cè)到不能連接到它，就將開(kāi)始一個(gè)故障轉(zhuǎn)移過(guò)程接管原來(lái)由MLAG共同管理的資源。

　　在開(kāi)始升級(jí)后，我們遇到了一些預(yù)料外的故障，這些故障引起了20-30分鐘的網(wǎng)絡(luò)不穩(wěn)定，隨后我們嘗試在維護(hù)窗口期處理這些問(wèn)題。我們?yōu)榇岁P(guān)閉了一半的聚合交換機(jī)和接入交換機(jī)的鏈路，這樣做能夠緩和一些問(wèn)題，然后我們繼續(xù)與網(wǎng)絡(luò)供應(yīng)商協(xié)作，試圖找到讓網(wǎng)絡(luò)不穩(wěn)定的深層原因。這仍然沒(méi)有起到作用，受累于冗余的制度，我們只能操作一半的上路鏈接，我們的流量是比較低的，這在當(dāng)時(shí)并沒(méi)有導(dǎo)致真正的問(wèn)題。在太平洋時(shí)間11:00，根據(jù)我們以往的經(jīng)驗(yàn)，如果我們對(duì)于這個(gè)新版本問(wèn)題還不能有一個(gè)好的解決辦法，我們打算回滾本次軟件升級(jí)，并且在13:00 PST的時(shí)候開(kāi)始回滾升級(jí)，恢復(fù)充分冗余的狀態(tài)。

　　在太平洋時(shí)間12:15分，我們的網(wǎng)絡(luò)供應(yīng)商開(kāi)始從交換機(jī)上收集***的取證信息，以便他們嘗試找出本次事故的原因。絕大多數(shù)的信息收集是隔離開(kāi)進(jìn)行的，包括收集日志文件和檢索交換機(jī)各部分的硬件狀態(tài)。作為***一個(gè)步驟，他們嘗試收集一個(gè)運(yùn)行在交換機(jī)上的代理的狀態(tài)。這涉及到停止的過(guò)程和促使它以某種方式寫(xiě)入狀態(tài)，并在稍后進(jìn)行分析。于是我們斷開(kāi)了接入交換機(jī)之間的鏈路，讓它們彼此不相互受影響。這與我們之前以MLAG模式重啟交換機(jī)類(lèi)似，而在此前多次測(cè)試中都是沒(méi)有出過(guò)意外的。

　　這時(shí)候，事情開(kāi)始變得糟糕起來(lái)。一個(gè)部署在交換機(jī)上的代理被終止后，（成對(duì)部署的）另一個(gè)節(jié)點(diǎn)將等待 5 秒鐘窗口期判斷前者是否會(huì)恢復(fù)。如果它無(wú)法收到***個(gè)節(jié)點(diǎn)的響應(yīng)，卻看到兩者之間鏈路處于活躍狀態(tài)，它會(huì)默認(rèn)對(duì)方處于運(yùn)行但狀態(tài)不同步的情況。在這種情況下，它不能安全地接管與另一個(gè)路由器共同管理的資源，因此它會(huì)默認(rèn)回到link aggregation, spanning tree和其他兩層協(xié)議下的獨(dú)立交換機(jī)運(yùn)行狀態(tài)。

　　通常情況下，這并不是一個(gè)問(wèn)題，因?yàn)樵摻粨Q機(jī)在它的對(duì)端失效之前還會(huì)查看這條鏈路的狀態(tài)。當(dāng)鏈路失效時(shí)，交換機(jī)會(huì)等待2秒看看鏈路是否恢復(fù)。如果鏈路沒(méi)有恢復(fù)，交換機(jī)會(huì)假設(shè)對(duì)端完全失效的同時(shí)接管MLAG資源。這一類(lèi)接管并不會(huì)觸發(fā)任何第二層(鏈路層)的變化。

　　當(dāng)***個(gè)交換機(jī)上的代理被終止時(shí)，這一對(duì)路由器之間的鏈接并未被中斷，因?yàn)榇頍o(wú)法操作硬件去中斷鏈接。只有當(dāng)代理程序重新啟動(dòng)后才可能發(fā)送命令操作底層 硬件。當(dāng)時(shí)間非常不巧，且路由器還需要更多額外時(shí)間由代理程序?yàn)榉治龆涗涍\(yùn)行狀態(tài)時(shí)，這一對(duì)路由器之間的鏈接保持了足夠長(zhǎng)時(shí)間的活躍狀態(tài)，最終使得對(duì)端 路由器發(fā)現(xiàn)了在活躍線(xiàn)路上心跳消息的缺失，因此進(jìn)行了后面這種有著更強(qiáng)破壞性的故障轉(zhuǎn)移操作。

　　這個(gè)過(guò)程帶來(lái)了網(wǎng)絡(luò)內(nèi)部的巨大波動(dòng)，因?yàn)樗械木酆湘溌芬匦陆?、spanning-tree協(xié)議中要求的***選舉過(guò)程必須完成，而且網(wǎng)絡(luò)中的所有鏈路都必須重新進(jìn)行spanning-tree的收斂過(guò)程。這一切直接導(dǎo)致了接入層交換機(jī)的流量被阻塞了1.5分鐘。

　　文件服務(wù)器影響

　　我們的文件服務(wù)器是由一些采用高可靠性保障軟件Pacemaker, Heartbeat 和 DRBD管理的主/備服務(wù)節(jié)點(diǎn)對(duì)組成，其中DRBD軟件可以將主節(jié)點(diǎn)上的磁盤(pán)數(shù)據(jù)變更同步到備節(jié)點(diǎn)，而Heartbeat和Pacemaker一起協(xié)同工作，管理主節(jié)點(diǎn)的服務(wù)進(jìn)程和故障恢復(fù)。

　　通過(guò)DRBD，確定數(shù)據(jù)卷是否單獨(dú)掛載在簇中的一個(gè)結(jié)點(diǎn)是非常重要的。DRBD保證數(shù)據(jù)掛載在一個(gè)鏈接的兩端節(jié)點(diǎn)上并且保護(hù)接收端是只讀的。再說(shuō)明一點(diǎn)，我們使用STONITH（Shoot The Other Node In The Head）進(jìn)程在等待失敗或者過(guò)期之前去關(guān)閉活動(dòng)的節(jié)點(diǎn)。我們想確保我們沒(méi)有進(jìn)入“精神分裂”（也就是數(shù)據(jù)被同時(shí)寫(xiě)入兩個(gè)節(jié)點(diǎn)）的狀態(tài)，因?yàn)檫@樣可能導(dǎo)致無(wú)法恢復(fù)的數(shù)據(jù)錯(cuò)誤。

　　當(dāng)網(wǎng)絡(luò)凍結(jié)后，很多為應(yīng)對(duì)冗余而刻意部署在不同機(jī)架上的文件服務(wù)器，超出了他們的heartbeat集群系統(tǒng)的響應(yīng)限時(shí)，而導(dǎo)致它們需要控制文件服務(wù)器資源。它們向合作節(jié)點(diǎn)發(fā)出STONITH命令，試圖去控制(文件服務(wù)器)資源，然而，由于受累于網(wǎng)絡(luò)，這些命令中的相當(dāng)部分并沒(méi)有傳達(dá)出去。當(dāng)網(wǎng)絡(luò)恢復(fù)、節(jié)點(diǎn)之間的消息被送達(dá)之后，許多對(duì)服務(wù)器都處于這樣的狀態(tài)：兩臺(tái)服務(wù)器都認(rèn)為自己應(yīng)該接管共享的資源。這個(gè)競(jìng)爭(zhēng)狀態(tài)導(dǎo)致兩臺(tái)服務(wù)器互相停止了對(duì)端（利用前述STONITH進(jìn)程）。我們有多對(duì)文件服務(wù)器最終都處于全部停止的狀態(tài)。

　　當(dāng)我們發(fā)現(xiàn)了這個(gè)問(wèn)題后，我們立即采取了以下措施：

• 將GitHub.com網(wǎng)站置為維護(hù)模式
• 協(xié)調(diào)整個(gè)運(yùn)維團(tuán)隊(duì)開(kāi)始進(jìn)行恢復(fù)
• 降級(jí)切換到上一個(gè)軟件版本
• 制定恢復(fù)服務(wù)的計(jì)劃
• 嚴(yán)密監(jiān)視網(wǎng)絡(luò)30分鐘，以確保是否穩(wěn)定復(fù)蘇

恢復(fù)

　　如前述被停止的成對(duì)節(jié)點(diǎn)在恢復(fù)時(shí)，重新激活鼓掌之前已被激活運(yùn)行的節(jié)點(diǎn)尤為重要，因?yàn)樗鼡碛袑?duì)于當(dāng)前文件系統(tǒng)應(yīng)該所處的正確狀態(tài)的***信息。在大多數(shù)情況下，當(dāng)結(jié)對(duì)的文件服務(wù)器在檢查集中式日志數(shù)據(jù)的過(guò)程中出現(xiàn)問(wèn)題的時(shí)候，來(lái)確定哪個(gè)節(jié)點(diǎn)是活躍節(jié)點(diǎn)是一件容易的事。然而在某些情形下，依據(jù)日志數(shù)據(jù)尚不能得出***的判斷，我們只好在不開(kāi)動(dòng)文件服務(wù)器資源的情況下啟動(dòng)雙節(jié)點(diǎn)中的一個(gè)，檢查它的本地日志文件，以此來(lái)判斷哪個(gè)節(jié)點(diǎn)才是主節(jié)點(diǎn)。

　　這種恢復(fù)是一個(gè)非常耗時(shí)的過(guò)程，我們決定在恢復(fù)每個(gè)文件服務(wù)器之前保持（GitHub.com運(yùn)行在）維護(hù)模式，直到最終恢復(fù)每一個(gè)文件服務(wù)器對(duì)。由于問(wèn)題廣泛存在，這個(gè)過(guò)程花了五個(gè)多小時(shí)才完成。我們不得不對(duì)整個(gè)GitHub文件存儲(chǔ)基礎(chǔ)設(shè)施中的絕大比例部分進(jìn)行重新啟動(dòng)，驗(yàn)證它們是否工作正常，并確保所有的對(duì)節(jié)點(diǎn)正確復(fù)制。這個(gè)過(guò)程中并沒(méi)有發(fā)生其他的意外，我們?cè)谔窖髸r(shí)間20:23重新上線(xiàn)。

　　從宕機(jī)事故中獲得的五點(diǎn)重要反省

1. 我們將和網(wǎng)絡(luò)供應(yīng)商緊密合作來(lái)鑒別和搞清楚導(dǎo)致MLAG功能失效以致故障轉(zhuǎn)移無(wú)法如愿進(jìn)行的原因，按設(shè)計(jì)的規(guī)劃，我們的網(wǎng)絡(luò)供應(yīng)商將重新審查個(gè)別延遲時(shí)間的狀況，（通過(guò)增加路由器超時(shí)設(shè)置）使路由器有更多時(shí)間去檢查判斷鏈路超時(shí)，以防止此類(lèi)事件在此發(fā)生。
2. 我們已經(jīng)推遲了所有針對(duì)聚合網(wǎng)絡(luò)的軟件升級(jí)事宜，直到我們?cè)跍y(cè)試環(huán)境（Staging）建立起與生產(chǎn)環(huán)境功能完全一致的副本用于測(cè)試。這項(xiàng)工作已經(jīng)展開(kāi)，在此同時(shí)，我們會(huì)繼續(xù)密切留意在此前報(bào)告中提到的MAC地址學(xué)習(xí)的問(wèn)題，并在必要時(shí)適用相應(yīng)的解決方法。
3. 從今往后，我們會(huì)在我們實(shí)施任何網(wǎng)絡(luò)變更前，讓文件服務(wù)器的高可靠性保障軟件進(jìn)入維護(hù)模式，不管所作的網(wǎng)絡(luò)變更在交換層面是多么簡(jiǎn)單。這個(gè)措施可以使服務(wù)器繼續(xù)工作，而不會(huì)因?yàn)樽兏僮鲗?dǎo)致服務(wù)器采取任何自動(dòng)的故障恢復(fù)行為。
4. 文件服務(wù)器節(jié)點(diǎn)之間的通信依賴(lài)于（其它的）網(wǎng)絡(luò)基礎(chǔ)設(shè)施是一個(gè)長(zhǎng)久以來(lái)已知的問(wèn)題。我們正在與主機(jī)提供商積極協(xié)調(diào)、尋找解決這個(gè)問(wèn)題的方法。
5. 我們引入了新的人員對(duì)我們的高可用性配置環(huán)境配置進(jìn)行重新評(píng)估以確保故障遷移行為是合適的。