圖解故障伺服器下線：關於阿裡雲MongoDB高可用的探秘
更多深度文章，請關注雲計算頻道：https://yq.aliyun.com/cloud
伺服器容災一直是雲服務運維過程中無法避開的問題，我們常常會討論如何對出現故障的機器進行資料庫方面的恢復，卻很少考慮到在機器出現故障後，
MongoDB採用的是什麼方法，得以做到在有機器故障的情況下依舊能保證使用者業務的高可用？最近舉行的“MongoDB Sharding杭州用戶交流會”中，針對這一問題，阿裡雲資深研發工程師果實分享了關於MongoDB 故障伺服器如何下線方面的詳盡的技術解密。
對於MongoDB資料庫來說，MongoDB內核就像汽車發動機，是整個資料庫運轉的核心部分，
那麼，什麼是高可用？
MongoDB服務採用三節點複本集架構，三個資料節點位於不同的物理伺服器上，分別自動同步資料。複本集提供三種角色，Primary節點（支援讀寫請求），Secondary節點（支援唯讀請求），
而高可用，就是針對這一服務的容災切換和容錯移轉的過程。這一過程有很高的自動化程度，通過Primary，Secondary和更多備用節點形成容災，當Primary節點出現故障，系統會自動選舉新的Primary節點。Secondary節點不可用，由備用節點接管並恢復服務，從多個方面保障服務的可用性。這便是MongoDB自身帶來的高可用。
高可用的最高境界就是：“容災故障關我何事？我只要業務ok”——從而做到將最穩定的服務提供給使用者。
天有不測風雲，伺服器總會出現各式各樣難以排查的硬體故障，極端情況下甚至出現罷工：例如記憶體ECC異常無法自動修復，
此外，諸如伺服器到達質保期的換新或者延保，系統升級OS，服務程式漏洞的修復，很多原因都可能導致伺服器需要下線。
伺服器下線了，使用者服務還要接著用，怎樣在拿掉機器進行線下升級的同時不影響用戶在跑的業務，這就需要交給MongoDB管控團隊去應對。
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版本容錯移轉：
在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，天象系統）會對問題主機進行打標與故障原因篩查，並提供對應的解決方案，將記錄置於資料庫內，通過自動化運維系統對使用者進行及時有效的通知。到達運維時間時，運維系統下發任務，再由資源池控制系統接納清空的主機進行維修或者克隆，而後完成整套維護流程。這其中最重要的目標，就是在使用者體驗上的無感知或者無影響。
或許有一天，我們能夠實現這樣的願景：
A：聽說了嗎？這幾年阿裡雲MongoDB主機下線了幾批故障機器。
B：我擦，我用了N年了，怎麼一點沒感覺呢！
而阿裡雲做到的正是對用戶安全；性能和可用性方面的多重保證，對用戶用戶，關心自己的業務發展和業務功能就足夠了，一切就是這麼簡單。
喂，所以說，沒事兒來玩玩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版本容錯移轉：
在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，天象系統）會對問題主機進行打標與故障原因篩查，並提供對應的解決方案，將記錄置於資料庫內，通過自動化運維系統對使用者進行及時有效的通知。到達運維時間時，運維系統下發任務，再由資源池控制系統接納清空的主機進行維修或者克隆，而後完成整套維護流程。這其中最重要的目標，就是在使用者體驗上的無感知或者無影響。
或許有一天，我們能夠實現這樣的願景：
A：聽說了嗎？這幾年阿裡雲MongoDB主機下線了幾批故障機器。
B：我擦，我用了N年了，怎麼一點沒感覺呢！
而阿裡雲做到的正是對用戶安全；性能和可用性方面的多重保證，對用戶用戶，關心自己的業務發展和業務功能就足夠了，一切就是這麼簡單。
喂，所以說，沒事兒來玩玩MongoDB吧。