【世界播資訊】?阿里云回應史上最大規(guī)模宕機故障:存在四大問題!

發(fā)布時間:2022-12-26 10:20:17  |  來源:通信世界全媒體  

(CWW)12月18日,阿里云香港Region可用區(qū)C發(fā)生大規(guī)模服務中斷事件,對很多客戶業(yè)務產(chǎn)生重大影響,影響面擴大到香港可用區(qū)C的EBS、OSS、RDS等更多云服務。


(資料圖)

一般來說,云服務器宕機只需要一個小時左右便能恢復,而阿里云這次宕機從18日早上8點56分首次檢測到故障警告,到次日凌晨0點30分所有服務恢復正常,歷時超過15個半小時

這無疑是阿里云運營十多年來持續(xù)時間最長的一次大規(guī)模故障。

12月18日,阿里云第一時間對客戶進行事件原因分析和維護的進展更新,同時態(tài)度誠懇并明確表態(tài),對于受本次故障影響的產(chǎn)品,阿里云將根據(jù)相關產(chǎn)品的SLA協(xié)議進行賠付。

12月25日,阿里云發(fā)布關于阿里云香港Region可用區(qū)C服務中斷事件的說明,

對故障情況進行了詳細說明,并公布了整個處理過程,對問題進行了詳細分析,還提出了改進措施。聲明中阿里云表示,要向所有受到故障影響的客戶公開致歉,并盡快處理賠償事宜。此次香港Region可用區(qū)C服務中斷事件,對很多客戶的業(yè)務產(chǎn)生重大影響,也是阿里云運營十多年來持續(xù)時間最長的一次大規(guī)模故障。穩(wěn)定性是云服務的生命線,對我們的客戶至關重要。我們將盡一切努力從此次事件中吸取經(jīng)驗教訓,持續(xù)提升云服務的穩(wěn)定性,不辜負客戶所托!

阿里云的公告顯示,冷機系統(tǒng)故障恢復時間過長現(xiàn)場處置不及時導致觸發(fā)消防噴淋、客戶在香港地域新購ECS等管控操作失敗故障信息發(fā)布不夠及時透明是導致此次宕機時間長、規(guī)模大的四大重要原因。

值得注意的是,此次出故障的機房并非阿里云自建數(shù)據(jù)中心,而是租用的香港電訊盈科公司機房。目前,阿里云所租用的香港電訊盈科公司機房已修復制冷設備故障,阿里云香港地域所有可用區(qū)云產(chǎn)品功能已經(jīng)全部恢復正常。對于受本次故障影響的產(chǎn)品,阿里云將根據(jù)相關產(chǎn)品的SLA協(xié)議進行賠付。

【聲明全文如下】

北京時間2022年12月18日,阿里云香港Region可用區(qū)C發(fā)生大規(guī)模服務中斷事件。經(jīng)過復盤,我們在這里向大家進一步說明故障情況、問題分析和改進措施。

處理過程

12月18日08:56,阿里云監(jiān)控到香港Region可用區(qū)C機房包間通道溫控告警,阿里云工程師介入應急處理,通知機房服務商進行現(xiàn)場排查。09:01,阿里云監(jiān)控到該機房多個包間溫升告警,此時工程師排查到冷機異常。09:09,機房服務商按應急預案對異常冷機進行4+4主備切換以及重啟,但操作失敗,冷水機組無法恢復正常。09:17,依照故障處理流程,啟動制冷異常應急預案,進行輔助散熱和應急通風。嘗試對冷機控制系統(tǒng)逐個進行隔離和手工恢復操作,但發(fā)現(xiàn)無法穩(wěn)定運行,聯(lián)系冷機設備供應商到現(xiàn)場排查。此時,由于高溫原因,部分服務器開始受到影響。

自10:30開始,為避免可能出現(xiàn)的高溫消防問題,阿里云工程師陸續(xù)對整個機房計算、存儲、網(wǎng)絡、數(shù)據(jù)庫、大數(shù)據(jù)集群進行降載處理。期間,繼續(xù)多次對冷機設備進行操作,但均不能保持穩(wěn)定運行。

12:30,冷機設備供應商到場,在多方工程師診斷下,對冷塔、冷卻水管路及冷機冷凝器進行手工補水排氣操作,但系統(tǒng)仍然無法保持穩(wěn)定運行。阿里云工程師對部分高溫包間啟動服務器關機操作。14:47,冷機設備供應商對設備問題排查遇到困難,其中一個包間因高溫觸發(fā)了強制消防噴淋。15:20,經(jīng)冷機設備商工程師現(xiàn)場手工調(diào)整配置,冷機群控解鎖完成并獨立運行,第1臺冷機恢復正常,溫度開始下降。工程師隨后繼續(xù)通過相同方法對其他冷機進行操作。18:55,4臺冷機恢復到正常制冷量。19:02,分批啟動服務器,并持續(xù)觀察溫升情況。19:47,機房溫度趨于穩(wěn)定。同時,阿里云工程師開始進行服務啟動恢復,并進行必要的數(shù)據(jù)完整性檢查。

21:36,大部分機房包間服務器陸續(xù)啟動并完成檢查,機房溫度穩(wěn)定。其中一個包間因消防噴淋啟動,未進行服務器上電。因為保持數(shù)據(jù)的完整性至關重要,工程師對這個包間的服務器進行了仔細的數(shù)據(jù)安全檢查,這里花費了一些必要的時間。22:50,數(shù)據(jù)檢查以及風險評估完成,最后一個包間依據(jù)安全性逐步進行供電恢復和服務器啟動。

服務影響

12月18日09:23,香港Region可用區(qū)C部分ECS服務器開始出現(xiàn)停機,觸發(fā)同可用區(qū)內(nèi)宕機遷移。隨著溫度繼續(xù)升高,受影響的服務器停機數(shù)量持續(xù)增加,客戶業(yè)務開始受到影響,影響面擴大到香港可用區(qū)C的EBS、OSS、RDS等更多云服務。

阿里云香港可用區(qū)C的故障,沒有直接影響客戶在香港其他可用區(qū)運行的業(yè)務,但影響了香港Region ECS管控服務(Control Plane)的正常使用。因大量可用區(qū)C的客戶在香港其他可用區(qū)新購ECS實例,從12月18日14:49開始,ECS管控服務觸發(fā)限流,可用性最低跌至20%??蛻粼谑褂肦unInstances/CreateInstanceAPI購買新ECS實例時,如果指定了自定義鏡像,部分實例在購買成功之后會出現(xiàn)啟動失敗的現(xiàn)象,由于自定義鏡像數(shù)據(jù)服務依賴可用區(qū)C的單AZ冗余版本的OSS服務,無法通過重試解決。此時,部分Dataworks、k8s用戶控制臺操作也受到了故障影響。API完全恢復可用為當日23:11。

12月18日10:37,阿里云香港可用區(qū)C的部分存儲服務OSS開始受到停機影響,此時客戶暫不會感知,但持續(xù)高溫會導致磁盤壞道,影響數(shù)據(jù)安全,工程師對服務器進行停機操作,從11:07至18:26中斷了服務。阿里云在香港Region可用區(qū)C提供了2種類型的OSS服務,一種是OSS本地冗余LRS服務(通常叫單AZ冗余服務),僅部署在可用區(qū)C;另一種是OSS同城冗余ZRS服務(通常叫3AZ冗余服務),部署在可用區(qū)B、C和D。在此次故障中,OSS同城冗余ZRS服務基本沒有受到影響。可用區(qū)C的OSS本地冗余服務中斷時間較長,因不支持跨可用區(qū)切換,需要依賴故障機房的恢復。從18:26開始,存儲服務器重新分批啟動。其中,單AZ本地冗余LRS服務有部分服務器因消防問題需要做隔離處理?;謴头涨?,我們必須要確保數(shù)據(jù)可靠性,花費了較多的時間進行完整性檢驗工作。直至12月19日00:30,這部分OSS服務(單AZ冗余服務)才恢復了對外服務能力。

阿里云網(wǎng)絡少量單可用區(qū)產(chǎn)品(如:VPN、Privatelink以及少量GA實例)在此次故障中受到影響。12月18日11:21,工程師啟動網(wǎng)絡產(chǎn)品可用區(qū)容災逃逸,12:45完成SLB等大部分網(wǎng)絡產(chǎn)品可用區(qū)容災逃逸,13:47NAT產(chǎn)品完成收尾逃逸。除上述少量單可用區(qū)產(chǎn)品以外,各網(wǎng)絡產(chǎn)品在故障期間保持了業(yè)務連續(xù)性,NAT有分鐘級業(yè)務受損。

12月18日10:17開始,阿里云香港Region可用區(qū)C部分RDS實例出現(xiàn)不可用的報警。隨著該可用區(qū)受故障影響的主機范圍擴大,出現(xiàn)服務異常的實例數(shù)量隨之增加,工程師啟動數(shù)據(jù)庫應急切換預案流程。截至12:30,RDS MySQL與Redis、MongoDB、DTS等跨可用區(qū)實例完成跨可用區(qū)切換。部分單可用區(qū)實例以及單可用區(qū)高可用實例,由于依賴單可用區(qū)的數(shù)據(jù)備份,僅少量實例實現(xiàn)有效遷移。少量支持跨可用區(qū)切換的RDS實例沒有及時完成切換。經(jīng)排查是由于這部分RDS實例依賴了部署在香港Region可用區(qū)C的代理服務,由于代理服務不可用,無法通過代理地址訪問RDS實例。我們協(xié)助相關客戶通過臨時切換到使用RDS主實例的地址訪問來進行恢復。隨著機房制冷設備恢復,21:30左右絕大部分數(shù)據(jù)庫實例恢復正常。對于受故障影響的單機版實例及主備均在香港Region可用區(qū)C的高可用版實例,我們提供了克隆實例、實例遷移等臨時性恢復方案,但由于底層服務資源的限制,部分實例的遷移恢復過程遇到一些異常情況,需要花費較長的時間來處理解決。

我們注意到,同時在多個可用區(qū)運行業(yè)務的客戶,在這次事件中依然可以維持業(yè)務運行。對于業(yè)務需要絕對高可用的客戶,我們持續(xù)建議您采用全鏈路多可用區(qū)的業(yè)務架構設計,以應對各種可能的意外事件。

問題分析與改進措施

1、冷機系統(tǒng)故障恢復時間過長

原因分析:機房冷卻系統(tǒng)缺水進氣形成氣阻,影響水路循環(huán)導致4臺主冷機服務異常,啟動4臺備冷機時因主備共用的水路循環(huán)系統(tǒng)氣阻導致啟動失敗。水盤補水后,因機房冷卻系統(tǒng)的群控邏輯,無法單臺獨立啟動冷機,手工修改冷機配置,將冷機從群控調(diào)整為獨立運行后,陸續(xù)啟動冷機,影響了冷卻系統(tǒng)的恢復時長。整個過程中,原因定位耗時3小時34分鐘,補水排氣耗時2小時57分鐘,解鎖群控邏輯啟動4臺冷機耗時3小時32分鐘。

改進措施:全面檢查機房基礎設施管控系統(tǒng),在監(jiān)控數(shù)據(jù)采集層面,擴大覆蓋度,提升精細度,提高對故障的排查和定位速度;在設施管控邏輯層面,確保系統(tǒng)自動切換邏輯符合預期,同時保證手工切換的準確性,防止內(nèi)部狀態(tài)死鎖從而影響故障的恢復。

2、現(xiàn)場處置不及時導致觸發(fā)消防噴淋

原因分析:隨著機房冷卻系統(tǒng)失效,包間溫度逐漸升高,導致一機房包間溫度達到臨界值觸發(fā)消防系統(tǒng)噴淋,電源柜和多列機柜進水,部分機器硬件損壞,增加了后續(xù)恢復難度和時長。

改進措施:加強機房服務商管理,梳理機房溫升預案及標準化執(zhí)行動作,明確溫升場景下的業(yè)務側(cè)關機和機房強制關電的預案,力求更簡單有效,并通過常態(tài)化演練強化執(zhí)行。

3.客戶在香港地域新購ECS等管控操作失敗

原因分析:ECS管控系統(tǒng)為B、C可用區(qū)雙機房容災,C可用區(qū)故障后由B可用區(qū)對外提供服務,由于大量可用區(qū)C的客戶在香港其他可用區(qū)新購實例,同時可用區(qū)C的ECS實例拉起恢復動作引入的流量,導致可用區(qū) B 管控服務資源不足。新擴容的ECS管控系統(tǒng)啟動時依賴的中間件服務部署在可用區(qū)C機房,導致較長時間內(nèi)無法擴容。ECS管控依賴的自定義鏡像數(shù)據(jù)服務,依賴可用區(qū)C的單AZ冗余版本的OSS服務,導致客戶新購實例后出現(xiàn)啟動失敗的現(xiàn)象。

改進措施:全網(wǎng)巡檢,整體優(yōu)化多AZ產(chǎn)品高可用設計,避免出現(xiàn)依賴OSS單AZ和中間件單AZ的問題。加強阿里云管控平面的容災演練,進一步提升云產(chǎn)品高可用容災逃逸能力。

4、故障信息發(fā)布不夠及時透明

原因分析:故障發(fā)生后阿里云啟動對客釘群、公告等通知手段,由于現(xiàn)場冷機處理進展緩慢,有效信息不夠。Status Page頁面信息更新不及時引發(fā)客戶困惑。

改進措施:提升故障影響和客戶影響的快速評估和識別拉取能力。盡快上線新版的阿里云服務健康狀態(tài)頁面(Status Page),提高信息發(fā)布的速度,讓客戶可以更便捷地了解故障事件對各類產(chǎn)品服務的影響。

總結(jié)

最后,我們要向所有受到故障影響的客戶公開致歉,并盡快處理賠償事宜。此次香港Region可用區(qū)C服務中斷事件,對很多客戶的業(yè)務產(chǎn)生重大影響,也是阿里云運營十多年來持續(xù)時間最長的一次大規(guī)模故障。穩(wěn)定性是云服務的生命線,對我們的客戶至關重要。我們將盡一切努力從此次事件中吸取經(jīng)驗教訓,持續(xù)提升云服務的穩(wěn)定性,不辜負客戶所托!

阿里云

2022年12月25日


關鍵詞: ?阿里云 大規(guī)模故障 制冷設備故障

 

網(wǎng)站介紹  |  版權說明  |  聯(lián)系我們  |  網(wǎng)站地圖 

星際派備案號:京ICP備2022016840號-16 營業(yè)執(zhí)照公示信息版權所有 郵箱聯(lián)系:920 891 263@qq.com