GitHub歷史上最糟糕宕機事故回顧和反省
距離今年9月份在兩天內兩次宕機僅間隔3個月。12月22日，全球知名的開源托管服務GitHub意外遭遇了歷史上最嚴重的一次宕機事件。GitHub官方確認了本次宕機是在例行的軟件升級過程中發生的，本文將帶領大家回顧一下宕機事故。
背景
周六上午我們按計劃要做一次例行維護，以確保軟件在聚合交換機上的順利升級。這次升級是在網絡供應商建議下進行的，目的是為了解決早些時候發生的宕機事故。在此之前，我們已經在類似設備上做過多次測試都沒有出現任何意外，我們對本次升級也充滿了信心。然而，即便準備充分，軟件升級仍然總是伴隨著風險，為此，我們預留了維護窗口期和技術支持人員提供電話服務，以防意外事件的發生。
問題出在哪里？
在GitHub的網絡中，每一臺接入交換機，也就是每一臺服務器都連接著一對聚合交換機。這些聚合交換機成對安裝并通過一種叫做MLAG的功能來偽裝成一個單線路由，因為link aggregation,spanning tree和其他layer 2協議希望有一個單獨的主設備。這使得我們能夠在一個聚合交換機上進行升級，而不會影響其他合作伙伴交換機或其他接入連接的交換機。值得一提的是，我們之前已多次成功運行過(MLAG)功能。
我們打算每次升級一臺聚合交換機，這一過程被稱作在服務中軟件升級(in-service software upgrade)。即首先上傳新的軟件到一臺交換機，配置交換機后，在新版本上重新啟動，并發出reload命令。余下的交換機探測到不能連接到它，就將開始一個故障轉移過程接管原來由MLAG共同管理的資源。
在開始升級后，我們遇到了一些預料外的故障，這些故障引起了20-30分鐘的網絡不穩定，隨后我們嘗試在維護窗口期處理這些問題。我們為此關閉了一半的聚合交換機和接入交換機的鏈路，這樣做能夠緩和一些問題，然后我們繼續與網絡供應商協作，試圖找到讓網絡不穩定的深層原因。這仍然沒有起到作用，受累于冗余的制度，我們只能操作一半的上路鏈接，我們的流量是比較低的，這在當時并沒有導致真正的問題。在太平洋時間11:00，根據我們以往的經驗，如果我們對于這個新版本問題還不能有一個好的解決辦法，我們打算回滾本次軟件升級，并且在13:00 PST的時候開始回滾升級，恢復充分冗余的狀態。
在太平洋時間12:15分，我們的網絡供應商開始從交換機上收集***的取證信息，以便他們嘗試找出本次事故的原因。絕大多數的信息收集是隔離開進行的，包括收集日志文件和檢索交換機各部分的硬件狀態。作為***一個步驟，他們嘗試收集一個運行在交換機上的代理的狀態。這涉及到停止的過程和促使它以某種方式寫入狀態，并在稍后進行分析。于是我們斷開了接入交換機之間的鏈路，讓它們彼此不相互受影響。這與我們之前以MLAG模式重啟交換機類似，而在此前多次測試中都是沒有出過意外的。
這時候，事情開始變得糟糕起來。一個部署在交換機上的代理被終止后，（成對部署的）另一個節點將等待 5 秒鐘窗口期判斷前者是否會恢復。如果它無法收到***個節點的響應，卻看到兩者之間鏈路處于活躍狀態，它會默認對方處于運行但狀態不同步的情況。在這種情況下，它不能安全地接管與另一個路由器共同管理的資源，因此它會默認回到link aggregation, spanning tree和其他兩層協議下的獨立交換機運行狀態。
通常情況下，這并不是一個問題，因為該交換機在它的對端失效之前還會查看這條鏈路的狀態。當鏈路失效時，交換機會等待2秒看看鏈路是否恢復。如果鏈路沒有恢復，交換機會假設對端完全失效的同時接管MLAG資源。這一類接管并不會觸發任何第二層(鏈路層)的變化。
當***個交換機上的代理被終止時，這一對路由器之間的鏈接并未被中斷，因為代理無法操作硬件去中斷鏈接。只有當代理程序重新啟動后才可能發送命令操作底層 硬件。當時間非常不巧，且路由器還需要更多額外時間由代理程序為分析而記錄運行狀態時，這一對路由器之間的鏈接保持了足夠長時間的活躍狀態，最終使得對端 路由器發現了在活躍線路上心跳消息的缺失，因此進行了后面這種有著更強破壞性的故障轉移操作。
這個過程帶來了網絡內部的巨大波動，因為所有的聚合鏈路要重新建立、spanning-tree協議中要求的***選舉過程必須完成，而且網絡中的所有鏈路都必須重新進行spanning-tree的收斂過程。這一切直接導致了接入層交換機的流量被阻塞了1.5分鐘。
文件服務器影響
我們的文件服務器是由一些采用高可靠性保障軟件Pacemaker, Heartbeat 和 DRBD管理的主/備服務節點對組成，其中DRBD軟件可以將主節點上的磁盤數據變更同步到備節點，而Heartbeat和Pacemaker一起協同工作，管理主節點的服務進程和故障恢復。
通過DRBD，確定數據卷是否單獨掛載在簇中的一個結點是非常重要的。DRBD保證數據掛載在一個鏈接的兩端節點上并且保護接收端是只讀的。再說明一點，我們使用STONITH（Shoot The Other Node In The Head）進程在等待失敗或者過期之前去關閉活動的節點。我們想確保我們沒有進入“精神分裂”（也就是數據被同時寫入兩個節點）的狀態，因為這樣可能導致無法恢復的數據錯誤。
當網絡凍結后，很多為應對冗余而刻意部署在不同機架上的文件服務器，超出了他們的heartbeat集群系統的響應限時，而導致它們需要控制文件服務器資源。它們向合作節點發出STONITH命令，試圖去控制(文件服務器)資源，然而，由于受累于網絡，這些命令中的相當部分并沒有傳達出去。當網絡恢復、節點之間的消息被送達之后，許多對服務器都處于這樣的狀態：兩臺服務器都認為自己應該接管共享的資源。這個競爭狀態導致兩臺服務器互相停止了對端（利用前述STONITH進程）。我們有多對文件服務器最終都處于全部停止的狀態。
當我們發現了這個問題后，我們立即采取了以下措施：
- 將GitHub.com網站置為維護模式
- 協調整個運維團隊開始進行恢復
- 降級切換到上一個軟件版本
- 制定恢復服務的計劃
- 嚴密監視網絡30分鐘，以確保是否穩定復蘇
恢復
如前述被停止的成對節點在恢復時，重新激活鼓掌之前已被激活運行的節點尤為重要，因為它擁有對于當前文件系統應該所處的正確狀態的***信息。在大多數情況下，當結對的文件服務器在檢查集中式日志數據的過程中出現問題的時候，來確定哪個節點是活躍節點是一件容易的事。然而在某些情形下，依據日志數據尚不能得出***的判斷，我們只好在不開動文件服務器資源的情況下啟動雙節點中的一個，檢查它的本地日志文件，以此來判斷哪個節點才是主節點。
這種恢復是一個非常耗時的過程，我們決定在恢復每個文件服務器之前保持（GitHub.com運行在）維護模式，直到最終恢復每一個文件服務器對。由于問題廣泛存在，這個過程花了五個多小時才完成。我們不得不對整個GitHub文件存儲基礎設施中的絕大比例部分進行重新啟動，驗證它們是否工作正常，并確保所有的對節點正確復制。這個過程中并沒有發生其他的意外，我們在太平洋時間20:23重新上線。
從宕機事故中獲得的五點重要反省
- 我們將和網絡供應商緊密合作來鑒別和搞清楚導致MLAG功能失效以致故障轉移無法如愿進行的原因，按設計的規劃，我們的網絡供應商將重新審查個別延遲時間的狀況，（通過增加路由器超時設置）使路由器有更多時間去檢查判斷鏈路超時，以防止此類事件在此發生。
- 我們已經推遲了所有針對聚合網絡的軟件升級事宜，直到我們在測試環境（Staging）建立起與生產環境功能完全一致的副本用于測試。這項工作已經展開，在此同時，我們會繼續密切留意在此前報告中提到的MAC地址學習的問題，并在必要時適用相應的解決方法。
- 從今往后，我們會在我們實施任何網絡變更前，讓文件服務器的高可靠性保障軟件進入維護模式，不管所作的網絡變更在交換層面是多么簡單。這個措施可以使服務器繼續工作，而不會因為變更操作導致服務器采取任何自動的故障恢復行為。
- 文件服務器節點之間的通信依賴于（其它的）網絡基礎設施是一個長久以來已知的問題。我們正在與主機提供商積極協調、尋找解決這個問題的方法。
- 我們引入了新的人員對我們的高可用性配置環境配置進行重新評估以確保故障遷移行為是合適的。
