狡兔務(wù)必三窟：阿里云香港可用區(qū)C宕機(jī)的教訓(xùn)

時間：2023-07-12 12:30:01 | 來源：網(wǎng)站運(yùn)營

時間：2023-07-12 12:30:01 來源：網(wǎng)站運(yùn)營

狡兔務(wù)必三窟：阿里云香港可用區(qū)C宕機(jī)的教訓(xùn)：自12月18日阿里云香港可用區(qū)C因?yàn)闄C(jī)房水冷機(jī)組出現(xiàn)故障，導(dǎo)致一次阿里云歷史上最長的宕機(jī)后，官方終于在圣誕節(jié)那天，出具了一份非常翔實(shí)的調(diào)查報(bào)告《關(guān)于阿里云香港Region可用區(qū)C服務(wù)中斷事件的說明》，稱得上是實(shí)事求是面對問題了。


我從業(yè)十五年，參與建設(shè)過4000個節(jié)點(diǎn)的私有云，也搞過機(jī)房裝修和上架，還有一點(diǎn)運(yùn)維經(jīng)驗(yàn)，算是有相關(guān)經(jīng)驗(yàn)，跟大家討論一下以后自家單位的容災(zāi)應(yīng)該怎么做吧。



大家先看這次阿里云宕機(jī)事故的重點(diǎn)時間線，8點(diǎn)56就發(fā)現(xiàn)機(jī)房溫控告警了，然后9點(diǎn)01就正確定位到制冷異常了。這個問題阿里云沒有隱瞞的必要，因?yàn)闄C(jī)房突然升溫，只能是空調(diào)（冷機(jī)）故障了。

這個事故的主要原因，就是因?yàn)橹评湓O(shè)備整整10個小時不能恢復(fù)工作，機(jī)房升溫太快，工程師為了保護(hù)數(shù)據(jù)，只能逐步關(guān)機(jī)。



次要原因是，在關(guān)機(jī)后還是有某個包間因?yàn)闇囟冗^高導(dǎo)致噴淋裝置啟動。手機(jī)和電腦不能進(jìn)水都已經(jīng)是常識了，服務(wù)器上淋了水那還得了？



再次原因，就是阿里云香港Reigon的架構(gòu)設(shè)計(jì)，同樣沒有遵循自己提到的「全鏈路多可用區(qū)的業(yè)務(wù)架構(gòu)設(shè)計(jì)」，新擴(kuò)容的ECS管控系統(tǒng)啟動時依賴的中間件服務(wù)部署在可用區(qū)C機(jī)房，導(dǎo)致可用區(qū)C一旦宕機(jī)，擴(kuò)容服務(wù)也啟動不了。相信后續(xù)阿里云一定會全網(wǎng)巡檢，整體優(yōu)化多可用區(qū)高可用設(shè)計(jì)，避免制造單點(diǎn)故障，類似依賴OSS單AZ和中間件單AZ的問題，再次出現(xiàn)就說不過去了。





第四個原因，是對于云服務(wù)來說，高可用架構(gòu)能夠保障是某幾臺物理服務(wù)器（ECS、OSS、RDS）因?yàn)楣收襄礄C(jī)時，原來的應(yīng)用可以漂移到同一個AZ（可用區(qū)）的其他服務(wù)器上，保證服務(wù)的連續(xù)性和數(shù)據(jù)的可用性。但是原有復(fù)雜的分布式架構(gòu)在一個AZ（可用區(qū)）整體出現(xiàn)網(wǎng)絡(luò)、服務(wù)器、存儲全部下線的時候，國內(nèi)沒有廠家敢于承諾100%實(shí)現(xiàn)全量無傷漂移到其他可用區(qū)，或者其他機(jī)房的。

打個比方，如果把中國大陸看成一個CN可用區(qū)，那么當(dāng)杭州或者杭州出現(xiàn)疫情的時候，是能夠把病人疏散到其他城市去治療，緩解自身醫(yī)療壓力的。但是當(dāng)舉國上下都遭遇新冠的時候，病人還能往哪送？阿里云這次遭遇的是一個AZ（可用區(qū)）整體下線，里面近千個機(jī)柜、上萬臺設(shè)備的數(shù)據(jù)，又能切換到哪里？

第五個原因，是對極小概率事件的應(yīng)急預(yù)案，是沒法考慮得那么周詳?shù)?，甚至完全考慮不到。比如誰能提前考慮服務(wù)器被噴淋裝置噴水導(dǎo)致?lián)p壞的場景？誰能考慮一個主備配置4+4的水冷機(jī)組，能夠同時出現(xiàn)故障，修好卻需要10個小時？

第六個原因，是對于一個巨型系統(tǒng)來說，有能力搞清楚里面所有的細(xì)節(jié)的總工程師，一定在新項(xiàng)目上，絕不是去搞運(yùn)維浪費(fèi)人才。其他的成員都是分模塊承擔(dān)任務(wù)的，他們只能選擇信任其他模塊。例如搞數(shù)據(jù)庫（RDS）的同學(xué)關(guān)注的是支持跨區(qū)遷移，誰能考慮到跨區(qū)遷移依賴的反向代理竟然不是跨區(qū)高可用的，結(jié)果大部分?jǐn)?shù)據(jù)庫成功遷移了，但是香港可用區(qū)C一旦宕機(jī)，依賴這個反向代理的的數(shù)據(jù)庫就遷移不了。



所以，我來點(diǎn)評一下。

1、假的主備冷機(jī)系統(tǒng)

阿里云宕機(jī)的主要原因是機(jī)房主備水冷機(jī)組共用了同一個水路循環(huán)系統(tǒng)，存在單點(diǎn)故障，修這個就用了10個小時。然而這個機(jī)房還只是阿里云租的。查了一下阿里云香港C區(qū)所在的機(jī)房，應(yīng)該是下圖的香港粉嶺安匯中心/安樂電話機(jī)房。（來自本站@香港sim精神小伙）



這個機(jī)房原來是PCCW電訊盈科的，然后Vantage(數(shù)據(jù)中心園區(qū)提供商，其母公司是紐交所上市公司，代碼DBRG）在2021年剛剛收購了電訊盈科的數(shù)據(jù)中心。

《Vantage Data Centers 完成對 PCCW DC 的收購，將其一流的超大規(guī)模數(shù)據(jù)中心平臺帶到香港和吉隆坡 - Vantage Data Centers》

這兩棟機(jī)房同屬Vantage的HKG1園區(qū)，大概機(jī)房參數(shù)如下：

所以阿里云也是倒霉，租了個機(jī)房還換了東家。換了東家之后，最了解情況的中基層領(lǐng)導(dǎo)很可能已經(jīng)被掃地出門了，Twitter不就是這樣么？所以故障響應(yīng)就會不及時。

修個水冷機(jī)組還要用10個小時，其中真正有效的時間就是排水補(bǔ)氣的3小時，除此之外，定位原因怎么要用3個半小時的？這個水冷機(jī)組的服務(wù)商也挺廢物的。

定位原因的3個半小時，就是設(shè)備維護(hù)商趕到現(xiàn)場的時間。一個重要數(shù)據(jù)中心的冷機(jī)壞了，香港的設(shè)備維護(hù)上用了3個半小時才到達(dá)現(xiàn)場，這種服務(wù)水平和響應(yīng)速度極不可靠，從杭州到杭州也用不了三個小時吧。

另外，解鎖群控邏輯，手動啟動4臺冷機(jī)，竟然要用3小時32分，也說明服務(wù)商的工程師對這個系統(tǒng)根本都不熟，大概率是照著操作手冊現(xiàn)學(xué)現(xiàn)賣的。



2020年，微軟Azure位于美國東部的數(shù)據(jù)中心發(fā)生服務(wù)中斷，持續(xù)六小時。微軟披露說，冷卻系統(tǒng)故障是導(dǎo)致這次停機(jī)的原因，發(fā)生故障的樓宇自動化控制導(dǎo)致氣流減少，隨后整個數(shù)據(jù)中心的溫度峰值阻礙了網(wǎng)絡(luò)設(shè)備的性能，使計(jì)算和存儲實(shí)例無法訪問。但是微軟的信息披露沒有阿里云這一次這么翔實(shí)，這一點(diǎn)還是要給阿里云的實(shí)事求是點(diǎn)個贊。

2021年11月，網(wǎng)易游戲機(jī)房大規(guī)模服務(wù)器宕機(jī)，原因同事是機(jī)房過熱，空調(diào)重新開機(jī)也沒有解決問題。但幸好這只是游戲服務(wù)器，玩家是可以接受的。但是大陸的服務(wù)更到位，網(wǎng)易的宕機(jī)只用了3小時就恢復(fù)了。

2022年夏天，倫敦的谷歌云及甲骨文數(shù)據(jù)中心出現(xiàn)制冷系統(tǒng)故障，導(dǎo)致數(shù)據(jù)中心氣溫升高，產(chǎn)生宕機(jī)。甲骨文的是系統(tǒng)自動采取保護(hù)措施關(guān)閉作業(yè)，于是業(yè)務(wù)宕機(jī)；谷歌的是溫度過高導(dǎo)致存儲故障，引起虛擬機(jī)宕機(jī)，然后谷歌也關(guān)閉了一部分機(jī)器。

2、數(shù)據(jù)中心機(jī)房用噴淋

所以根據(jù)《建筑設(shè)計(jì)防火規(guī)范》GB50016規(guī)定，重要機(jī)房、配電房是需要做氣體自動滅火，這是中國大陸的規(guī)定。



但是我國的國標(biāo)之間也有沖突，比如根據(jù)《《數(shù)據(jù)中心設(shè)計(jì)規(guī)范》GB 50174-2017》，只要數(shù)據(jù)中心的系統(tǒng)在其他數(shù)據(jù)中心內(nèi)有承擔(dān)相同功能的備份系統(tǒng)時，也可以設(shè)置自動噴水滅火系統(tǒng)。這個規(guī)范的主編單位是中國電子工程設(shè)計(jì)院。



我在2010年參與了杭州國科數(shù)據(jù)中心Tier-IV機(jī)房項(xiàng)目，當(dāng)時是東北亞最高端的機(jī)房，那時候我們用的就是七氟丙烷氣體滅火。參見《運(yùn)營環(huán)境 杭州國科數(shù)據(jù)中心》



為什么要用對人體有微毒性的七氟丙烷滅火，而不是用干粉、氣水霧或者噴淋方式滅火呢？因?yàn)殡娮釉O(shè)備就沒有不怕水的，干粉也會對設(shè)備造成傷害。順口再說一句，國外聲稱他們重視員工生命，所以建議少用這種有毒的氣體滅火方式。這方面很多公司都參考了美國消防協(xié)會NFPA的標(biāo)準(zhǔn)，國際某個頭部的云廠商也有不少這類設(shè)計(jì)。

我參與的項(xiàng)目還是經(jīng)受住了考驗(yàn)，2022年10月13日，杭州國科數(shù)據(jù)中心A2棟建筑屋頂備用冷卻塔起火，半小時后撲滅，但是建筑內(nèi)的杭州超算中心數(shù)據(jù)機(jī)房安然無恙，數(shù)據(jù)沒受影響，說明氣體滅火還是極有必要的，要不然超算中心就無了。



當(dāng)然，氣體滅火也有弊端，比如對空間有要求，大于3600平方就達(dá)不到消防效果，這些在國標(biāo)里都有提及。此外氣體的儲備量也是有限制的。

這個機(jī)房原來是PCCW電訊盈科的，也是資深數(shù)據(jù)中心運(yùn)營商，真的會這么離譜么？《電訊盈科PowerBase方案》里面也寫的非常清楚，數(shù)據(jù)中心對制冷機(jī)組、供電機(jī)組全年無休監(jiān)控。現(xiàn)在看來，制冷機(jī)組的監(jiān)控明顯失靈，反而是機(jī)房先升溫告警，然后才找到了制冷機(jī)組的問題。



雖然這次故障的源起是機(jī)房。但硬件設(shè)備的能力和可靠性是有限的，這就是為什么有云計(jì)算的原因。我認(rèn)為，我們需要提升數(shù)據(jù)中心設(shè)施的可靠性，但不應(yīng)該只專注于此。云計(jì)算不應(yīng)當(dāng)如此嚴(yán)重的依賴于單個機(jī)房，阿里云更應(yīng)該做的是提升云產(chǎn)品的穩(wěn)定性，加強(qiáng)整個AZ層面的災(zāi)備演練。

我們該怎么自保？

IDC圈盤點(diǎn)了近幾年的前十大數(shù)據(jù)中心災(zāi)難事故，《盤點(diǎn)：近年數(shù)據(jù)中心十大災(zāi)難事件_機(jī)房_火災(zāi)_服務(wù)器》，包括2020年韓國SK公司數(shù)據(jù)中心火災(zāi)，影響了3.2萬個服務(wù)器；2021年3月，歐洲云計(jì)算巨頭OVH在法國的數(shù)據(jù)中心嚴(yán)重火災(zāi)，一共4座數(shù)據(jù)中心，有一座被完全燒毀。導(dǎo)致法國360個政府、企業(yè)與公共事業(yè)網(wǎng)站直接癱瘓。



2021年，浙江多機(jī)房因汛情斷電，還有位于浙江的數(shù)據(jù)中心出現(xiàn)機(jī)房進(jìn)水情況；2022年谷歌數(shù)據(jù)中心電氣爆炸，影響了40多個國家的1338臺服務(wù)器。這種事一篇稿子都寫不下。



所以，重要應(yīng)用和數(shù)據(jù)，請務(wù)必做到狡兔三窟，一定要充分考慮云主機(jī)的單點(diǎn)故障，做好多可用區(qū)的高可用，做好數(shù)據(jù)的容災(zāi)和備份；千萬不要全盤相信連鎖型的自動化操作。

在極端情況下，全自動化操作容易導(dǎo)致出現(xiàn)多米諾骨牌一樣的連鎖反應(yīng)。比如這次阿里云香港機(jī)房的冷機(jī)就是群控啟動的，死活就啟動不起來。因?yàn)樵偻陚?、再安全、再可靠的自動化方案，哪怕平時運(yùn)轉(zhuǎn)非常正常，趕上寸勁和巧合，總會出現(xiàn)無法預(yù)計(jì)的問題。

人體的設(shè)計(jì)也有這種Bug，當(dāng)免疫系統(tǒng)在體內(nèi)殺新冠病毒殺瘋了的時候，他才不會管人體是否受得了，直接燒到42度，或者免疫風(fēng)暴走起。反正新冠病毒總得死，但是人會不會死，免疫系統(tǒng)不在乎。

自動噴淋滅火系統(tǒng)也是，反正只要溫度過高我就要噴水，我的任務(wù)是保證火被撲滅了，但是物理服務(wù)器進(jìn)水會不會損壞，自動噴淋滅火系統(tǒng)不在乎。特斯拉也是，他的自動控制系統(tǒng)只負(fù)責(zé)接管車輛駕駛，至于是不是剎車失敗，會不會造成人員傷亡，自動控制系統(tǒng)不在乎。

我的群暉NAS有100T的容量，其中有5T工作文檔數(shù)據(jù)，算是我十五年來攢下的命根子。兩個月之前，我在三天里連續(xù)壞了兩塊硬盤，真的是嚇出一身冷汗；我做了Raid5，如果只壞一塊盤，數(shù)據(jù)是可以恢復(fù)的；但是如果同時壞了兩塊盤，那我事務(wù)的數(shù)據(jù)就全game over了。



在這件事情之后，我直接搞了個同城災(zāi)備和異地容災(zāi)。同城災(zāi)備是我買了一塊16T的硬盤，接在群暉NAS上，把我的重要數(shù)據(jù)每日備份；異地容災(zāi)就是一年幾百塊買了阿里云盤，映射成WebDAV，也是每天備份我的重要數(shù)據(jù)，這樣才能保證數(shù)據(jù)可靠性。

對于應(yīng)用服務(wù)來說，一定要考慮好安全性，比如反親和性，兩臺虛擬機(jī)不要放在同一臺物理機(jī)上；比如做好鏡像備份和容器的編排，在異地設(shè)置好備份，保證必要的時候可以快速在異地拉起容器；比如做好數(shù)據(jù)庫的異步同步，基本保證數(shù)據(jù)的一致性，在應(yīng)用里不要直接寫死數(shù)據(jù)庫的IP地址，還是要用域名指向。

比如2019年3月，騰訊云上浙江匯機(jī)房的光纜被施工挖斷，等于所有網(wǎng)絡(luò)都不通了，暖暖、QQ 飛車，王者榮耀，吃雞等 90 多個服務(wù)受到影響，這種問題就屬于意外，也沒法問責(zé)云廠商。

所以，如果老板問為什么要花這么多資金和人力來搞容災(zāi)，那就可以告訴老板，不管是谷歌云、甲骨文、微軟云、阿里云、還是騰訊云，全都出過故障，只要是服務(wù)，就有不可用的時候，所以靠誰不如靠自己。像阿里云這次故障中，在架構(gòu)層面設(shè)計(jì)了多可用區(qū)高可用方案的客戶，就完全沒有受到影響，當(dāng)然，安全是需要額外成本的。

每個公司都是自己業(yè)務(wù)應(yīng)用和數(shù)據(jù)的第一責(zé)任人，不應(yīng)該也不能把希望全部寄托在云廠商身上。

比如2021年3月，云廠商OVH在法國的數(shù)據(jù)中心起火之后，游戲《Rust》表示，25臺歐洲服務(wù)器完全損毀，沒有備份，數(shù)據(jù)無法被修復(fù)。你說這個數(shù)據(jù)丟失的主責(zé)是云廠商OVH，還是游戲運(yùn)營商呢？像阿里云香港機(jī)房本月的可用時間大約是98%左右，也會按照規(guī)則賠償25%的月費(fèi)用，但是用戶的業(yè)務(wù)穩(wěn)定和數(shù)據(jù)安全，能全部依賴于供應(yīng)商么？當(dāng)然不能。

阿里云這一次的信息披露，算是這么多家云廠商中最坦誠、最詳盡的了，也是給各個企業(yè)一個充分的經(jīng)驗(yàn)借鑒，讓大家在容災(zāi)方案設(shè)計(jì)時，除了保證應(yīng)用和數(shù)據(jù)的高可用，還要考慮中間件的高可用；除了考慮自身的架構(gòu)設(shè)計(jì)，也要考慮租賃的數(shù)據(jù)中心的制冷和防火設(shè)計(jì)者有沒有腦血栓

畢竟人生中充滿了黑天鵝事件，我們除了積極應(yīng)對風(fēng)險(xiǎn)，還能怎么辦呢？狡兔務(wù)必三窟就是唯一的答案。

參考資料

[1]

香港sim精神小伙: https://www.zhihu.com/people/15217944045

[2]

Vantage Data Centers 完成對 PCCW DC 的收購，將其一流的超大規(guī)模數(shù)據(jù)中心平臺帶到香港和吉隆坡 - Vantage Data Centers: https://vantage-dc.com/news/vantage-data-centers-finalizes-pccw-dc-acquisition-to-bring-its-best-in-class-hyperscale-data-center-platform-to-hong-kong-and-kuala-lumpur/

[3]運(yùn)營環(huán)境 杭州國科數(shù)據(jù)中心: http://m.sisdc.com.cn/operatingEnvi.html

[4]電訊盈科PowerBase方案: https://www.pccwsolutions.com/getitem.php?id=652543d8-a258-4127-bee4-483bf69054c5

[5]盤點(diǎn)：近年數(shù)據(jù)中心十大災(zāi)難事件_機(jī)房_火災(zāi)_服務(wù)器: https://www.sohu.com/a/609305338_210640