圖解故障服務器下線：關於阿裏雲MongoDB高可用的探秘

服務器容災一直是雲服務運維過程中無法避開的問題，我們常常會討論如何對出現故障的機器進行數據庫方麵的恢複，卻很少考慮到在機器出現故障後，是用一套怎樣的處理流程將三節點副本集恢複如初的。

MongoDB采用的是什麼方法，得以做到在有機器故障的情況下依舊能保證用戶業務的高可用？最近舉行的“MongoDB Sharding杭州用戶交流會”中，針對這一問題，阿裏雲資深研發工程師果實分享了關於MongoDB 故障服務器如何下線方麵的詳盡的技術解密。

對於MongoDB數據庫來說，MongoDB內核就像汽車發動機，是整個數據庫運轉的核心部分，而管控就像拚裝汽車的過程。車子怎麼跑，跑起來的效能如何，運轉是否安全，出現故障如何維修，諸如此類的任務都由管控部門負責處理。而保證用戶的業務能夠達到高可用，則是運維任務的重中之重：

MongoDB服務采用三節點副本集架構，三個數據節點位於不同的物理服務器上，分別自動同步數據。副本集提供三種角色，Primary節點（支持讀寫請求），Secondary節點（支持隻讀請求），Hidden節點（提供備節點的角色，默認不支持訪問）。

而高可用，就是針對這一服務的容災切換和故障轉移的過程。這一過程有很高的自動化程度，通過Primary，Secondary和更多備用節點形成容災，當Primary節點出現故障，係統會自動選舉新的Primary節點。Secondary節點不可用，由備用節點接管並恢複服務，從多個方麵保障服務的可用性。這便是MongoDB自身帶來的高可用。

高可用的最高境界就是：“容災故障關我何事？我隻要業務ok”——從而做到將最穩定的服務提供給用戶。對用戶來說，能夠看到的是Primary和Secondary兩個節點和暴露出的相關訪問鏈接。但在服務器上，同時還存在著另外一個Secondary節點處於Hidden狀態，這個節點通常用於數據備份以及性能優化，在主節點出現故障時頂到前方，切換成Secondary節點繼續承擔用戶的工作。

天有不測風雲，服務器總會出現各式各樣難以排查的硬件故障，極端情況下甚至出現罷工：例如內存ECC異常無法自動修複，硬盤IO異常讀寫失敗，RAID卡狀態有問題，電池斷電，網卡網絡滿載等。麵對這些形形色色的故障類型，阿裏對所有對外服務的服務器都提供了監控，采用監控係統對這些點進行實時采集，一旦發現問題便會及時的進行報警。

此外，諸如服務器到達質保期的換新或者延保，係統升級OS，服務程序漏洞的修複，很多原因都可能導致服務器需要下線。

服務器下線了，用戶服務還要接著用，怎樣在拿掉機器進行線下升級的同時不影響用戶在跑的業務，這就需要交給MongoDB管控團隊去應對。

MongoDB高可用的實現流程分為以下三個部分：

故障檢測：使用多種檢測係統針對各種項目進行檢測，各個係統中存在聯動效應。

故障轉移：發生故障後怎樣將故障機器上的業務從該機器轉移出來。

主機下線：故障機器下線維修以及相應的後續過程。

MongoDB服務集群裏有大量不同型號的機器，例如D13、H43。每個服務器上都有與之對應的檢測程序，通過大量的Monitor進行監控從而獲取信息：無論是內部屬於阿裏雲自己的部分，還是在用戶的業務中由用戶實現的部分，都存在著與之對應的接口。阿裏雲會通過推送或自取的方式獲取實例並了解服務器的狀態，如果獲悉某台機器存在下線的必要，資源管理器就會對這台機器進行打標，確認異常後進入下一個階段。檢測和故障轉移兩個步驟之間並不是直來直去一步到位，其間實際上存在眾多細化的檢查過程。

對阿裏雲提供的三節點副本集架構而言，類似機器達到保修期，浪潮D13 RAID卡故障等許多情況下，都需要對任務的Primary節點機器進行下線維護。麵對這些情況，資源管理器會對需要下線的機器進行打標，打標後的機器會進行實際的下線。而這些需要下線的機器往往還有業務正在運轉。為了保證業務不受影響，MongoDB會借用自身機製，把Secondary節點替換為Primary節點，從而使打標的節點變成Secondary狀態，之後會把打標節點從Secondary變成Hidden，即隱藏服務節點。原有的Hidden節點則作為容災節點被替換上去。

此時的Hidden（打標）節點上依舊存留著實例的數據，不能輕易下掉機器，這裏會進入節點重搭的步驟——從資源池裏額外再選一台機器生產一個Hidden節點，等新的節點加入副本集後，並且完成三節點同步的情況下，被打標的機器才會被摘下，從而正式進入下線流程，這個過程往往需要一段時間才能完成。況且被打標的機器上麵很可能存在多個實例，這台機器上可能不隻是某個實例的Primary節點，可能還存在其他實例的Secondary或者Hidden節點，但主體流程是類似的，打標機器上的所有節點最終都會替換成Hidden狀態，直到這台機器達到沒有任何用戶訪問請求的效果。

為了不影響用戶對雲服務的正常使用，整個切換過程都會在用戶提供的運維時間窗口裏進行。

麵對被下線的機器，係統並不會直接草率的將其置於主機資源池中，而是會有24H的滯留期，在滯留期內，監測係統會檢測滯留機器上是否還有其它訪問請求或IO讀寫操作。檢測結束，確定機器可以下線時才會將其放入主機資源池。資源池裏的機器將進入另外一套係統進行後續操作，此時和MongoDB業務已經關聯不大。阿裏雲會通過專用的IDCfree係統對機器進行恢複，待到確定機器沒問題後，我們才會重新將其放入資源池內，通過自動上線係統重新加入MongoDB集群，這部分內容由自動資源控製平台來負責。接下來，我們就以實際的故障轉移業務場景為例子，闡釋關於高可用實現更具體的過程。

故障機器打標確認進入轉移流程後，名為Robot的自動運維係統會先獲取機器上的實例信息，然後在用戶設定的可運維時間內開始正式轉移（即使不在用戶設定的使用時間內，阿裏雲依舊會通過短信對用戶進行告知）。在判定Role是Primary節點的情況下，先把Primary和Secondary節點進行置換，如果發現已經是Secondary節點，那就進行Secondary和Hidden節點之間的的角色切換。這一步驟通過下發任務流的方式完成，後端完成置換的速度很快，對用戶的影響可以忽略不計。當確定故障機器全部變成Hidden節點時，開始觸發重搭Hidden流程，將新建的節點加入副本集。此時，有故障的節點已經沒有任何實例存在，自動運維平台會將這一空閑的問題機器置於可下線列表中，不再繼續進行即時的實例檢查。

故障遷移的時候存在一種獨特的說法：防風暴，波瀾不驚。例如對於阿裏雲K級別的服務器集群，重搭Hidden的過程中要新生產實例，這其中就很可能牽扯到一些數據恢複和同步的工作，在集群量較小，自建主機機房不夠情況下，實例將麵臨批量的操作。因為每台主機上都存在眾多實例，實例的恢複以及備節點的恢複往往會在另外一台主機上完成。由於實際負荷量巨大，此時目標機器便可能存在網絡滿載，IO調用巨大的情況。

為了平衡這一點，能夠讓恢複盡可能平緩的進行，阿裏雲極大的擴充了主機資源池的總量，同時在資源調度的分配上盡可能使每台機器做到均衡。例如，遷移時優先選擇負荷低的機器新建Hidden節點，同時將多個任務盡量打散到不同機器上；通過應用資源管理平台進行分析，在資源池水位無法達到預留期望的時候及時補充所需的機器資源——從而盡可能滿足資源池每時每刻都能接受更多運維服務和新建實例上雲的需要，達到一種整體上低負荷平穩運行的狀態。

如果有兩台以上的副本集同時出現問題，則通常不是由硬件故障導致，但在機器集中升級時也存在出現的可能。如果需要下線的機器數量較少，阿裏雲會優先采用一台台分別下線的方式以減少異常情況發生的概率，但一旦出現必須批量操作的情況，則會跳出原本Switch Role的算法。資源管理器會對所有需要下線的機器統一進行打標，用Transfer流程加以處理。

在該流程中，阿裏雲會生產一批目標實例（同樣規格，用戶在使用的實例），把這些實例以Secondary節點的狀態加入副本集當中，再將新生產目標實例的Hidden節點和原始實例中的Hidden節點做替換(這一過程對用戶是沒有影響的)。排除原實例中的Hidden機器後，因為服務中心會提供兩個VIP，首先更換Secondary節點提供服務的VIP，將其切換到目標實例的Secondary節點上，再把Secondary節點在副本集的層麵進行互換，由原實例的副本集換成新實例的Secondary節點，這時再進行Primary節點的VIP互換，使原實例兩個VIP均切換到目標實例上，最後再進行兩個Primary節點之間的互換，達到目標實例上的節點變成Primary的效果，從而完整的實現由原實例到目標實例的過渡。此時便可以釋放原來的實例，三台機器上所有的實例完成遷移後，共同進入機器下線流程。

同時升級多台機器對用戶的正常使用可能會存在影響，因為是遷移而不是角色互換的緣故，VIP切換過程中對用戶的影響難以避免。因此，即使這個過程中在運維窗口期完成，阿裏雲依舊會用短信的方式對用戶進行及時的告知。

在Sharding版本中同樣存在有三個節點。對於CS和Shard來說，遷移和切換和副本集差不多，整體步驟類似，除了因為沒有VIP所以省略切換VIP的步驟。而在Mongos一處則略有不同，因為Mongos是一個相當輕量的實例，不存在大量的數據緩存，至多就是本信息或者一些VIP的掛載，在它出現故障時，係統首先會嚐試能不能拉起一個新的實例，如果機器被打標下掉，它就會直接到另一台可用機器上創建一個新的Mongos，把VIP切換過來。將新的Mongos節點加入到整個Sharding的副本集中，把原本出現問題的Mongos實例下掉，把故障機器上的Mongos都清空後進入機器下線的流程。

在上文中，我們已經闡述了很多具體的Mongo實例切換與遷移流程，而實際上，這類流程在管控中是用一套比較成熟的分布式任務流來實現的。

任務流有幾個角色，每個切換和遷移都相當於一個task（任務），由自動管控平台收到後下發，由Task Master（任務調度端）進行整體調度和分發，Pengine Master負責任務步驟調度，Pengine（每一台具體DB節點）完成節點主機操作。

如圖所示，Task Master會周期性的獲取遷移實例的任務，同時進行最大容量限製與流控相關處理。例如一台機器需要下線，那麼機器上運轉的數百個實例都要進行調節，此時Task Master並不會即刻切掉所有任務。例如程序不穩定，或者有誤操作行為存在時，要下線的實例數目超過了其設定的批量操作閾值，Task Master會立刻向運維人員報警，考慮是否存在人為或誤操作的可能，從而達到流控的效果。

經過取舍和排序後，運維任務便會在接下來流入到Pengine Master端，在相關調度下由空閑的Pengine Master接收。Pengine Master會對收到的任務進行基本初始化與步驟調度，考慮是在本地處理還是交給下一層的DB節點。超時機製和監控巡檢兩大功能可以保證任務正常進行。

作為第三層級，Pengine接受操作命令後，會通過處理任務隊列的方式進行具體操作，操作結束後返回對應的Pengine Master，再由Pengine Master根據結果來決定是繼續操作任務還是返回給Task Master，以這樣的流程來進行不同任務的並發和分布處理。

確定機器不存在實例並可以下線後，後續的過程一般分L1，L2兩個階段完成：

L1階段中，管控人員會對撤下的機器進行徹底的排查，並出具報告，確定是否能夠修複，可修的機器送進維修係統，不可修的機器通過iclone係統洗白，防止保留曆史數據。

L2階段中，機器會被置入恢複係統（實際的資源機器上線係統），重新安裝基礎OS模塊和引擎基礎模板後進行驗證，如果驗證通過，便將機器重新加入資源池內通過上線係統加入MongoDB集群，如果機器難以修複或過保，則對其進行報銷處理，宣布其完成使命。

針對MongoDB或者MongoDB Sharding集群，idc係統會定期針對機器是否可用並進行打標，將打標後的主機放在大盤資源池內。係統會從資源池裏檢查機器是否應當維修或進行其他處理，如需克隆則交付iclone模塊來完成。克隆完畢並確定無異常後，主機會被發送到資源池內部進行服務準備。由部署係統將可上線的機器自動加入Sharding集群，並做好相應的性能監控和配置，再由資源管理器將新機器納入資源調度係統，重新開始工作。

最後，讓我們來總覽一下阿裏雲對故障機器維護的流程：

運維人員發現機器出現問題或需要檢測，通過運維控製台人工操作進行打標，同時可進行批量管理，將所得內容發送給已經work的移山係統，通過用戶設定的運維時間進行通盤考慮生成下線計劃，同時對破壞性實例進行監控並及時將其遷移。

接下來，自動檢測係統（idc，天象係統）會對問題主機進行打標與故障原因篩查，並提供對應的解決方案，將記錄置於數據庫內，通過自動化運維係統對用戶進行及時有效的通知。到達運維時間時，運維係統下發任務，再由資源池控製係統接納清空的主機進行維修或者克隆，而後完成整套維護流程。這其中最重要的目標，就是在用戶體驗上的無感知或者無影響。

而阿裏雲做到的正是對用戶安全；性能和可用性方麵的多重保證，對用戶用戶，關心自己的業務發展和業務功能就足夠了，一切就是這麼簡單。

喂，所以說，沒事兒來玩玩MongoDB吧。