伺服器容災一直是雲服務運維過程中無法避開的問題，我們常常會讨論如何對出現故障的機器進行資料庫方面的恢複，卻很少考慮到在機器出現故障後，是用一套怎樣的處理流程将三節點副本集恢複如初的。
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高可用的實作流程分為以下三個部分：
故障檢測：使用多種檢測系統針對各種項目進行檢測，各個系統中存在關聯效應。
故障轉移：發生故障後怎樣将故障機器上的業務從該機器轉移出來。
主機下線：故障機器下線維修以及相應的後續過程。
故障檢測：
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吧。