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

　　背景

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

　　問題出在哪里？

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

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

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

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

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

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

　　當(dāng)***個交換機上的代理被終止時，這一對路由器之間的鏈接并未被中斷，因為代理無法操作硬件去中斷鏈接。只有當(dāng)代理程序重新啟動后才可能發(fā)送命令操作底層 硬件。當(dāng)時間非常不巧，且路由器還需要更多額外時間由代理程序為分析而記錄運行狀態(tài)時，這一對路由器之間的鏈接保持了足夠長時間的活躍狀態(tài)，最終使得對端 路由器發(fā)現(xiàn)了在活躍線路上心跳消息的缺失，因此進行了后面這種有著更強破壞性的故障轉(zhuǎn)移操作。

　　這個過程帶來了網(wǎng)絡(luò)內(nèi)部的巨大波動，因為所有的聚合鏈路要重新建立、spanning-tree協(xié)議中要求的***選舉過程必須完成，而且網(wǎng)絡(luò)中的所有鏈路都必須重新進行spanning-tree的收斂過程。這一切直接導(dǎo)致了接入層交換機的流量被阻塞了1.5分鐘。

　　文件服務(wù)器影響

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

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

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

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

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

恢復(fù)

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

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

　　從宕機事故中獲得的五點重要反省

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