《承載新美大3萬臺服務器的云計算基礎運維》要點：
本文介紹了承載新美大3萬臺服務器的云計算基礎運維，希望對您有用。如果有疑問，可以聯系我們。

作者介紹

胡湘濤,美團云基礎運維負責人,曾先后在愛奇藝、百度軟件研究院負責系統和基礎服務運維工作,主持開發愛奇藝CDN網絡監控系統、愛奇藝CDN部署自動化系統建設.2014年加入美團云,帶領基礎設施運維團隊,主要負責整體網絡架構設計、基礎設施、監控系統標準化、主導運維自動化平臺建設等.

演講大綱：

1. 基礎平臺服務
2. 高可用基礎服務
3. 基礎網絡質量監控
4. 多維資源數據運營

1.基礎平臺服務

非常感謝大家遠道而來,我之前一直在CDN,一直從事基礎設施的運維和運維自動化的開發工作.今天給大家分享一下承載新美大的云計算基礎設施.

提到基礎設施,可能更多的認為是服務器、IDC,還有網絡這一塊.其實在這里面為了承載整個新美大的電商平臺,我們在基礎設施方面,穩定性、可靠性方面做了非常多的工作.

基礎設施這一塊除了我們的設施以外,還有一個基礎的服務平臺,這樣才能非常高效地將我們的業務傳遞給客戶.現在新美大所有的業務都承載在美團云上面,像外賣、美團、點評等.

這是大概的一個基礎平臺結構,下面是物理層,包括服務器、網絡、動力環境.動力環境大家可能相對比較陌生,其實在整個平臺的穩定性方面還是發揮了非常重要的作用.之前我們看到經常有某個網站在年會時還在處理這個問題,其實更多的是跟動力環境相關.上面一層主要是我們IP的控制層,比如說網絡、路由表、路由協議之類的.那么,如何把我們的服務穩定地交付給客戶?更多的是在TCP/UDP這一層的負載均衡層和DNS上面來做,我們做了非常多有關穩定性的工作.講基礎設施,一個是基礎,再一個是平臺,我們首先從基礎來介紹.

首先我們在IDC選用方面做了非常多的工作.在機房選型上,我們選用符合T3及以上標準IDC.什么是T3?T3是國際上針對IDC的標準,T3簡而言之可以進行在線的維護工作,現在我們絕大多數的機房都是按照T3的標準來建,部分老的離線機房使用T3的標準,其它會使用T3+,甚至于T4.T4主要是給銀行和金融業務服務,它所有的低壓配電、空調、動力環境都是有2N或者2(N+1)冗余,當一路或者部分設備斷掉的時候,都不會影響到IDC服務器工作.

我們在T3選型的時候,除了選用T3及以上的IDC外,還需要有獨立的低壓配電系統,比如說低壓的配電機,UPS、UPS電池,還有柴油發電機,這個都需要針對我們自己的模塊給到一個獨立的系統,這樣才能夠對機房的穩定性做一個把握.同時空調制冷方面一般選用2N或者N+1系統,任何單臺機組出現問題的情況下不會對機房產生影響.同時在物理空間方面,我們選用獨立的物理空間,機房可以按照實際需求進行定制.

是不是有了高標準的基礎設施以后就很穩定了呢?那也不一定.像之前出現過的友商整個機房中斷,就是因為在運維的過程當中UPS出現了問題,在維護的過程將點切換到另一路,而另一路無法完全承載整個機房的負荷,最終導致機房癱掉,所以在這個過程當中運維是影響穩定的最重要因素.

1、首先我們在運維方面有完善的SOP.必須是標準性的操作,所有非標準性的操作都可能會給機房帶來災難性后果.比如說我們做電力維護的時候、機房機架電源標簽,標簽和實際不一樣,可能出現操作和預期不一致情況.同時我們對IDC風險評估做了大量的工作.

2、機房動力監控.除了能夠看到的UPS負載、電力負載、機房的溫度濕度以外,我們還做了人工24小時動環的巡檢,機房的冷風道溫度是否正常,是否有局部的過熱,這些都是需要考慮的問題.

3、同時因為我們的空間是物理獨立的空間,所以每個Q要定期和運營的IDC進行模擬的演練.比如說機房的一臺空調宕機,會不會對我們造成影響.如果造成影響,怎樣通過風險預案來保障整個IDC的穩定.

做電商的朋友可能都會面臨這樣的問題,開始可能只有一個IDC,但這個IDC不一定能給我們預留足夠的機柜.我們業務在高速擴展的過程中,如何做到在既保證數據中心擴展,同時又能保證我的網絡穩定性?

我們采用雙超核的架構.我們機房主要在北京、上海,北京是一個IDC的集群,上海也是一樣的,同時我們內網使用的是雙超,每個IDC在建設的時候都會通過兩條異路由光纖分別連到兩個超核,這樣讓我們從容地應對市政施工、來自于藍翔挖掘機的挑戰,經常一鏟子下去光纖中斷,這是經常出現的情況.所以我們通過雙線路OLP保護,主線路中斷實行20毫秒的切換備用鏈路,在單條線路出現問題并不會對我們任何業務造成影響,甚至一個單超核故障都不會對我們業務造成影響,是因為我們實現了雙超核互聯.然后每條裸光纖上,使用波分系統進擴展帶寬.每個機房的出口,按照業務需求在80G到320G之間,根據我們業務模塊和業務需求靈活擴展.單條線路利用率一旦到了50%,會對這個進行擴容.所以這個架構充分體現了雞蛋不放在一個籃子里面,通過冗余來提升基礎網絡穩定性.

一般的業務發展軌跡,會從單個IDC到同城容災然后異地容災,我們現在通過北京、上海兩個region,為業務提供異地容災的支持.我們北京—上海專線利用率即將達到50%的時候,我們會提發起專線擴容,保障整體的IDC群之間的互聯帶寬.以上是我們針對內網的網絡建設情況.

其次,如何快速、穩定地把業務和服務交付我們的用戶?我們在北京、上海自建了BGP平臺,接入了教育網、三大運營商、以及大部分小運營商.這樣也給基礎設施帶來了充足的資源.BGP平臺和IDC也具備非常靈活的擴展方式,我們BGP平臺基本都是采用雙路容災.我們之前剛剛提到的這個系統里面進行雙線路,這樣在任何一個網絡設施出現了問題或者線路出現問題的情況下能夠實現業務無感知切換.

我們在整體網絡的架構和設計的時候,非常強調的是網絡架構的自愈能力.任何單一線路出現了問題,第一不能對業務造成任何的干擾；第二業務恢復的時候,實現平滑恢復,這是我們在基礎設施架構的設計和運維過程當中遵循最重要原則.

2.高可用基礎服務

除了有這么多基礎設施,剛剛我也提到怎么樣把數據交付給客戶、傳遞給客戶?首先肯定是要有高效、高可用的基礎服務.

基礎服務網絡拓撲

這是我們整個基礎服務的拓撲圖,首先圖中ISP是我剛剛提到的BGP平臺,在這邊是IDC,這是外網,下面是MGW,作為負載均衡的產品.左邊是NAT集群負責將內網地址轉換成公網地址,為內網的機器提供internet訪問,所有的MGW、NAT都以集群方式的部署,集群可以靈活地橫向擴張,避免單點問題.后面我介紹一下MGW的性能包括容災切換時候的情況.

MGW是自研的產品,也是我們云平臺的一個模塊,為用戶提供高效穩定的負載均衡服務.同時對外提供API方便地跟我們運維自動化系統集成,業務關系系統可以通過接口調用的方式,快速進行部署.

MGW Session同步

現在單臺服務器只是1200萬Session.在一臺MGW出現故障的時候,Session可以無縫地遷移到同集群其他機器,為用戶提供穩定的負載均衡服務.Session同步機制我們采用二層同步,在百萬級Session切換miss率為零.在大量連接的時候,采用增量同步策略,保障新增的Session能夠快速地同步到集群內部.

我們分別做了單臺機器和多臺機器的故障模擬測試.

 

MGW Session同步：故障驗證

這邊是剛剛提到的MGW.我們用了十個不同的機器通過MGW請求后端的服務來進行.我們把第一臺MGW在23:37左右的時候,把一臺MGW模擬故障機器進行了關閉,從監控上卡37分這個時間點,模擬故障的機器流量為零了,十個請求進程業務監控沒有波動.同時我們會面臨多臺機器同時發生故障,或者多臺機器陸續發生故障的情況,那么多臺機器發生故障的時候是否影響業務交付的持續性呢?

我們在23:43先關掉了第一臺的MGW,從監控上一臺的MGW上的業務大多數遷移到第二臺上面,我們在這個時間點把監控藍色這臺MGW模擬的故障把它關閉了,大家能夠看到第四臺的連接數和流量進行有徒增的情況,關閉機器的業務進行了切換,在23:55的時候第三臺進行關閉,所有的流量都是遷移到最后一臺.在切換的時間點上面,十個壓測進程在整體監控曲線上面是非常平緩,說明Session切換過程非常平滑.

出現了故障修復了機器之后,重新上線或者業務增長需要擴容.上線和擴容時,是否也能一如既往保持平滑切換呢?

MGW Session同步：故障恢復/無感擴容

這是我們故障恢復和擴容的場景.像前面剛剛提到的這些時間段我們分別演練了三臺機器一次發生故障,這個時間點先恢復了第一臺MGW,從業務來看基本是沒有任何波動的.在1:03左右的時間點剩余兩臺也進行了恢復和擴容,并發上面來看1:02到1:03是相對平緩的過程,特別需要說明的是,監控圖上有紅框框起來的,因為我們壓測的時候是做文件的下載完成,所以進程求情帶寬降為零了,并不是異常情況.

記得我剛剛入行的時候,領導跟我說過一句話,印象特別深刻——讓一個網站在地球上消失最好的辦法就是干掉它的DNS,可見DNS作為基礎服務的重要性.如果一個機房掛掉了可以通過同城跨機房容災解決,區域掛掉了可以做跨區域的容災,DNS故障了就別無他法了.DNS是我們的基礎服務,通常怎樣部署呢?在一個IDC里面部署至少會部署兩臺DNS做互備,我們的服務器就會在文件里面配上這兩個DNS IP.當遷移到另外一個IDC的時候,由于機房IP地址的唯一性,另外一個機房如果增加DNS,肯定服務器所在機房的IP.如果還使用原來的DNS,那么網絡一旦有問題整個機房就沒有辦法進行域名解析.傳統業務,通過自動化的發布流程,業務遷移換通過checklist和流程可以解決.

Traditional DNS Structure

在云計算平臺的時候,這種場景就不一定適合了,因為機器在做跨IDC層面的漂移,漂移的過程當中還需要給客戶改一個DNS,這種用戶體驗是不好的,會成為運維過程中的一個坑.

那怎么做呢?我們采用了基于AnyCast架構.大家對這個架構可能覺得陌生,但是實際大家經常使用類似方案的DNS服務,例如著名的8.8.8.8.在任何地方都使用一個DNS IP,為你提供DNS解析服務器的是網絡路由選錄最優的集群.

AnyCast?DNS Structure

如何實現的呢?

Bind服務器還是使用經典的master-slave架構主從同步,每臺bind server都有自己的內網IP,在bind server上和內網核心跑路由協議,所有的bind server都發給內網核心交換機同樣的IP地址,如8.8.8.8或者10.10.10.10. 所有的DNS解析請求發到交換機的時候,通過網絡就能實現最佳選路.機器擴容也非常的容易,這樣方便整個基礎設施架構的部署,包括簡化了我們運維流程.

以上是我們的基礎設施技術方案.

3.基礎網絡質量監控

有了良好的架構和方案,接下來制約系統穩定的就是運維.我一直堅定地認為運維決定整個平臺的穩定性關鍵,如何快速發現異常,定位問題的root case,需要依賴完善的監控體系和直觀的可視化交付.

因為我們的體量相對比較大,三萬+的服務器,幾千個機柜,上千臺TOR,這種情況下如何做到對所有整體的網絡一目了然,快速發現問題和響應解決?

 

內網質量監控一期：全網ICMP質量

這是我剛剛提到的內網超核,所有跨IDC的網絡流量都通過超核進行轉發,這上面分別在三個不同的IDC每個IDC有兩組內網核心.

我們會在每一組TOR下面的物理機上面布一個Agent,通過Agent監控到全網其它的TOR的網絡情況.在這樣一個體量的基礎設施中,如果實現?依靠人工增加顯然不現實.我們開發了一叫sysop的基礎設施自動化平臺,里面記錄了基礎設施所有資源信息,通過自動化校驗我們信息的準確性.通過這個平臺可以獲取到IDC、交換機、服務器所有信息,例如監控所需的服務器SN、主機名、IP地址、上聯TOR等信息.

最右邊是消息告警的平臺,根據我們的一些策略配置一些消息告警,比如說兩臺機器之間,有丟包、延時增大等情況,匹配我們的告警策略之后,通過短信、大象(內部IM)、電話通知到對應人員.下面是我們的監控數據存儲和展示模塊,通過InfluxDB存儲監控數據,Grafana進行畫圖展示.中間是我們內網質量監控的核心管理和調度模塊Manager.首先,我們每臺服務器部署的時候會部署這個Agent堆,Agent啟動會自動給管理和調度模塊發請求,獲取到需要監控的列表,然后監控的頻率,上報信息字段.Agent監控生成的數據會上報到Manager模塊,通過模塊處理后存入InfluxDB.

內網質量監控一期：全網ICMP質量

我們知道現在整個網絡架構當中監控南北向的流向是非常容易實現的,因為每個服務器到TOR,TOR到核心,再到外網,這是現在最基本的網絡監控.但是內部業務調用都是東西向流量,尤其是電商行業.兩個業務之間的請求,一旦出現異常大家可能第一反應是網絡的問題,我想在場的網絡工程師一定深有感觸.如何避免這樣的問題,如何快速為我們業務定位?可以在內網質量監控平臺,把出現問題的源目主機名輸入進去以后,通過sysop平臺查詢到這臺機器在哪一個物理機上面的,通過物理機的agent監控.在內網質量監控平臺查詢這兩臺物理機之間的網絡質量.

圖示的兩個VM分別是我們北京上海機房的機器,北京–上海長傳的網絡延時在27到30毫秒之間.大家知道光纖的長距離傳輸,基本一百公里ping的往返是約一毫秒,從監控來看過去一個小時延時沒有波動,所以異常并不是網絡原因.這里面可以看到過去任意時間段網絡質量,相當于為網絡質量做了快照.

網絡是動態的,經常出現間歇性的丟包或者中斷,網絡工程師判斷問題需要抓住現場,否則很難快速定位問題.所以我們通過這樣的平臺給到業務也好,我們自己也好,讓我們快速地判斷網絡是否有問題,或者當服務端出現報錯的時候,到底第一時間排查網絡還是DNS,或者是業務服務本身的問題,這樣縮小了問題點,讓業務快速的定位.因為電商一旦出現問題,影響的時間越長,其實都是交易金額.所以在這一塊我們投入了很多的精力來做這一塊的工作.沒有人能說自己的基礎設施永遠不出故障,我們所能做的是最大程度避免故障,出現故障時能快速發現、快速定位、快速解決.

內網質量監控二期：全網路由質量

這是我們內網監控的第二期架構,第一期我們完成了東西向流量端到端網絡監控,但是還不能實現快速發現問題.按照圖上網絡加,在WJ和DBA的兩個超核,每個IDC的內網核心有很多線互聯的,之前提到我們跨機房帶寬按照業務不同在80-320G之間,也就在核心層面最多有32條路徑可達.兩臺機器互Ping的時候,出現丟包率.

比如說服務器到TOR,TOR到內網核心可能四條線,到超核是16條、32條線,超核到內網核心又是32條線,可選路徑是指數級上升的.能否將每一條鏈路的狀況在我們內網的網絡拓撲圖上面進行展示,這樣我們能夠第一時間在業務之前發生這個問題.例如兩臺機器又32條路徑的時候,其中一條有問題,按照理想的離散情況,業務訪問受影響個概率是3%.但是我們ping的時候源目地址一定,只能測試到一條路徑,從ping上檢測發現故障的概率只有1/32.

第二期所做的,是能夠監測到這32條路徑的網絡質量.按照路由選路原則,根據廠商不同, Hash策略不一樣,常規監控無法檢測到其中每段線路的網絡質量.我們通過了解廠商的Hash策略,認為構造數據包監控每段鏈路質量,如從TOR到核心這一段一秒一次的頻率檢測丟包率和延時的波動了解到每一段的網絡是否有問題.這樣整個網絡的質量,通過拓撲圖和質量數據結合,讓網絡工程師直觀地了解到整個網絡的情況.

內網質量監控二期：查詢&展示

第二期全路由的質量已近部分完成,我們先上線了同一個IDC內路由質量監控,這是我們的展示.當我們需要查看兩臺機器之間網絡狀況,在這里輸入兩個主機名,同一個IDC可以清晰的知道有四條不同的路由,從這邊到達對方,比如說10.4.29.2.1是網關.

接下來有兩條路徑,第一條10.5.1.9,第二條10.4.1.181,從核心到TOR又有兩種選擇,組合起來就有四種選擇,通常如果僅僅只是用ping或者MTR時只能看到一條路徑是否正常.如果我們需要判斷四條的時候我們需要做大量的工作,這樣判斷問題就會花費大量時間.通過這個我們能夠知道四條鏈路過去其實都是正常的,如：過去五分鐘的平均延時是0.12毫秒,丟包率是零.這樣我們對網絡穩定性的了解,和排查問題的速度都有巨大提升.

說完了在IDC內部的網絡監控,那公網網絡質量如果能夠快遞精確地掌握呢?通常正常情況下是一個黑盒,只有用戶有報障的時候才知道我到這個區域的網絡有問題,我們能不能主動地監控、發現這個網絡是否有問題呢?通過博睿、基調還有17測、阿里測也可以監控,但是成本和時間限制無法讓我們在用戶報障之前就發現問題和解決問題.

全國公網質量監控：直觀展示

我們做了外網網絡質量監控,并通過一個地圖來展示,隨時能夠了解我們出口到全國各地級市網絡丟包和延時.電信、聯通、移動三條線路出口分別進行監控.我們主動以1秒鐘為頻率監控到全國每一個地級市網絡情況.

比如說我們發現西南地區經常出現大范圍的網絡波動,我們發現這一塊區域如果出現紅色,比如說延時大于120毫秒或者出現2%的丟包率,這是有問題的.如圖上這個時間點到廣東省的每個地級市的網絡狀況都很不好,這種情況結合我們業務的DAU比重就能知道這個網絡出現這種情況,業務影響有多大.所以我們的監控系統探測能夠很清晰地知道哪一個區域有問題.電信線路有問題,通過BGP平臺,將這幾個區域的地址或者將這個區域的IP切換到我們聯通線路、切換到移動線路,快速的保障業務可用性和用戶訪問體驗.

平臺發展壯大是源自于用戶的選擇,我們需要給用戶做到更高質量的服務、更好的用戶體驗.同時這些系統其實在公有云和私有云是一樣的保障標準,我們自己用到什么基礎設施、網絡條件,其實給到美團云的客戶也能使用同樣的服務.

因為時間的關系不能一一給大家講,我們還針對交換機,包括機房溫度、DNS解析,以及整個機房之間的專線帶寬,按照拓撲圖,使用的百分比,有沒有峰值,都有非常完善的監控體系.

全國公網質量監控：詳情&告警

這是我們在全國公網質量的監控和告警,我們發現全國某一些區域出口的時候出現了這種丟包,正常情況會有大量的報警信息,這樣可能因為海量的報警淹沒了核心的內容.

我們需要做的是將報警進行歸并,例如一個省有好多個地級市,通過剛剛提到的報警中心,將信息合并發一條短信內容是這個省的網絡又問題,這樣收到報警的時候信息對我們判斷問題更加有效.

比如說3月23日晚上零點九分的時候,電信出口到江西、廣東、湖北這邊,雖然到了零點,我們還是有客戶的,我們會第一時間拿到這個信息,然后做一個網絡切換.同時我們針對重要報警在非工作時間有電話告警的,核心的業務問題如果發生在夜晚,大家不一定關注短信,會通過電話來通知,這樣讓我們運維人員不會錯過任何一個非常重要的告警.

報警信息除了常規信息還會包含監控URL,點擊URL就能直接查看監控功能,廣東電信正常是這么多毫秒,突然這個時間點突增了,丟包率從0到54%,這對用戶訪問影響是非常大的,我們收到報警需要進行第一時間的切換,通過之前的系統和優化能夠最快的做出判斷,按照操作預案進行操作.

4.多維資源數據運營

剛剛講完了監控,那么是不是只做完監控就高枕無憂了,是否還需要不斷、持續優化運維效率?我們會通過監控系統,結合各項數據匯總的指標,針對性的持續優化,讓基礎設施更加的穩定.

服務器操作流程自動化

比如說這是服務器自動化操作方面,我們申請機器的時候走自動化流程,發起,檢測有沒有系統,我們CMDB的狀況是否正常,如果正常的話,更改為預申請,部署操作系統,部署之后對主機進行Ping檢測,認為OK的,最終交付給業務.機器的序列號,部署系統成功率和耗時,這些后端我們都會把數據進行收集,拿到最近30天,比如說服務器上線、下線流程的總量,成功率、失敗率、正在運行的數量以及平均每個流程的耗時來針對性的優化.

比如說成功率沒有到100%,流程所需的時間是否可以優化?因為服務器的故障還是部署操作系統不完善導致的?每周、每個月,針對性的主題進行優化.比如說平均交付時間過長,申請一個機器等待半個小時,業務方覺得等不及的,我們是不是有辦法縮短這個流程,這是針對我們整個基礎設施層面的數據化運營.

同時我們在成本方面也做了一定的考量,比如說所有機柜的房間有多少服務器,有多少交換機,這里面有效機柜是多少,針對于每個機柜的電力是多少,我們針對這個機柜所承載的業務和服務器的功耗進行匹配,來提高機柜的有效率.機柜的有效率上升了,在IDC平均業務量的租用成本就會降低,這也是數據化運營的方向.一個是提高我們的穩定性,一個需要降低整體的成本.

服務器電力功耗統計分析

包括現在除了有數據以外,我們更多強調監控的可視化.

我們在機房都有類似于探頭來監控我們環境,比如說一些變更.包括除了機房的動力環境以外,我們自己來監控機房的溫度、濕度是否達標.比如說機房一個機器或者空調出現了問題,并不一定會告訴你.真當機房不可靠時,我們再發現,可能整個機房死掉了,所以這邊有一個提前的預警,包括跟機房建立一個長效的機制.我們在IDC層面,每一個Q進行一次巡檢.做一個動力環境的巡檢,看一下基礎設施的利用率是否有超標、是否有風險來完善風險的評估體系.

現場可視化

環境檢測

以上就是我今天的分享,謝謝大家.

文章來自微信公眾號：DBAplus社群

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2364.html