摘要:在全球軟件大會上,華為雲工程師深度分析了網站在各類極端重大災難場景下,如何快速恢複的高可用保障方案和工程化實踐。
最近,某CDN服務故障,導緻海外大批知名新聞網站無法正常訪問或加載,一石激起千層浪。确實,随着越來越多的業務上雲,一個網站或者某個業務能否保證持續的在線,非常考驗背後的高可用、高可靠方案設計。
在第七屆全球軟件大會上,華為軟件工程師杜志剛,就為廣大開發者分享了華為雲官網的高可用保障方案,深度分析了網站在各類極端重大災難場景下,如何快速恢複的方案和工程化實踐。
網站不靠譜,損失不可估量從網站所有者角度來看:網站不可用直接導緻的是經濟收入方面的影響,特别對于電商類網站,每分每秒都在産生交易,一旦訪問中斷,經濟損失的影響顯而易見。除此之外,從客戶角度來看,面對網站不可訪問,最直觀的感受是不靠譜,對網站以及網站背後的企業品牌産生不可挽回的口碑及信任度方面的負面影響。
從近十年的互聯網重大故障事件來看,DNS、CDN導緻的大範圍影響曆曆在目,其他IT基礎設施導緻的區域型及全局型故障也影響甚大。
業界廣泛使用的網站可用性指标包括網站不可用時間及網站年度可用率,不同類型的網站和應用對可用性的要求也不盡相同。
其中網站不可用時間(故障時間)=故障恢複時間點-故障發生時間點。網站年度可用率(Yearly Uptime Percentage)=(1-網站不可用時間/年度總時間)*100%。
華為雲官網作為雲基礎設施提供商的互聯網訪問入口,對可用性有着極高的要求,面向最終用戶的核心頁面要做到7*24小時在線,如果出現重大故障,如雲服務區級别,或基礎設施導緻的單雲全局故障,5分鐘内告警通知到相關責任人,15分鐘内完成故障切換。
網站訪問出現故障,背後發生了什麼?下面結合圖例分析一下網站頁面訪問的整體流程及關鍵故障點:
在①處,DNS故障會通常會導緻網站整體不可訪問,到了②是CDN故障會讓部分地理區域用戶不可訪問,③是單雲全局故障會導緻網站整體不可訪問,④是雲服務區級别故障會導緻分流到該區域的用戶不可訪問,⑤是雲服務可用區級别故障會導緻路由到故障AZ的用戶不可訪問,⑥是容器集群故障導緻路由到對應容器服務的用戶不可訪問,⑦是服務節點故障會導緻路由到故障服務節點的用戶不可訪問。
綜上,雲化場景下,頁面訪問面臨諸多的關鍵技術挑戰,包括:
- 單個DNS服務商整體故障如何應對?
- 單個CDN廠商整體或多個區域故障如何應對?
- 基礎設施故障導緻的單雲整體故障如何保證頁面還可以正常訪問?
- 單個雲服務區級别故障如何對用戶訪問影響時間降到最小?
- 頁面訪問依賴的後端服務衆多,如何最大限度較少故障點,降低方案整體複雜度及成本,保證方案通用可行?
針對以上關鍵挑戰,通過華為雲官網近幾年的實踐,總結了4個方案分享給大家,我們将一一拆解,為大家展示這些方案的實際效果。
1、單個DNS服務商整體故障:雙DNS服務商解析DNS是相對來說非常重要但卻沒有得到應有重視的薄弱環節,對于可用性要求極高的商業門戶網站,将DNS依托于一家服務商,不出問題風平浪靜,一旦發生全局性故障,導緻的影響可能是災難性的。
我們當前的策略是:采用雙DNS廠商域名解析方案,在一家服務商發生部分或整體故障時,可以在短時間内自動實現故障切換,将域名解析工作交給其他服務商完成。此外,我們還構建了統一運維平台實現多廠商域名解析的統一配置,以及DNS可用性監控、故障服務的快速剔除能力。
雙廠商DNS配置如圖所示:
這個配置的前提是域名注冊商及域名解析商支持多廠商Name Server配置。具體配置方面,首先将域名注冊托管遷移到支持多廠商NS配置的注冊商,然後同步DNS廠商配置的解析記錄到新廠商,最後域名注冊服務及解析服務同時配置NS記錄指向雙廠商Name Server(0~72小時生效)。
這樣配置可以在單個廠商Name Server發生故障時,ISP Local DNS自動将故障Name Server降低選擇優先級(BIND SRTT算法,失敗懲罰),使用優選的Name Server進行A記錄或CNAME域名解析。
演練步驟可以拆解為:
第一步:雙廠商NS記錄配置。
第二步:通過浏覽器檢查服務可正常訪問。
第三步:撥測Name Server可用性,驗證不同地域ISP是否使用了不同廠商的Name Server進行域名解析。
第四步:關停Bind模拟單個廠商DNS故障。
最後,通過HTTP從多個地域撥測服務是否可以正常訪問。
2、單個CDN廠商區域性故障:多CDN服務商方案
下面介紹一下多CDN廠商的配置與切換,如圖所示:
使用這個方案的限制條件有三個:DNS協議不支持多廠商CDN的CNAME解析配置;DNS智能解析支持不同地域或網絡配置不同的CNAME解析記錄;CDN出現整體故障概率較低,更多是區域性故障。
多CDN廠商的配置要先對國内及海外訪問分别做主備CDN加速,然後CDN CNAME解析TTL設置為60s,讓單CDN廠商服務不可用時,故障切換生效時間更短;最後是構建CDN管理平台,對接多廠商DNS管理API,預先配置切換和回切策略,出現故障一鍵切換。
最後的配置效果也很明顯,CDN告警廠商A大面積故障後,可通過CDN運維管理平台,将對應區域的CNAME解析Failover到廠商B提供服務,生效時間1分鐘。
下圖是我們運維平台的切換界面示例,可按不同二級域名分國内及海外用戶訪問場景分别切換。
在2020年和2021年我們遇到了實際的現網故障,CDN的故障切換功能得到了有效應用,讓頁面訪問實現了快速故障恢複。
3、區域性地理災難場景:頁面訪問異地多活方案這裡介紹了我們中國站和國際站雙站異地多活的組網策略,如圖所示:
如果發生區域性地理災難場景,我們使用站點多Region多活部署,使用這個解決方案要保證内容管理服務發布的頁面内容在多雲服務區保持同步。同時,LB及網關路由配置多活雲服務區保持一緻。
具體配置時,先将國内及海外用戶CDN回源流量按比例分流至不同雲服務區;随後配置健康檢查策略,當出現雲服務區級别故障時告警,便于自動或手動切換回源流量至健康的雲服務區;如果海外與國内服務存在差異時,通過雲廠商内部專線在LB或網關進行跨雲服務區路由。
這樣,在非容災場景下,多雲服務區同時提供頁面訪問服務,降低單雲服務區回源壓力。即便出現雲服務區級别故障時,也可通過CDN Admin API實現一鍵故障切換,CDN回源快速回到可用狀态。
如圖所示,通過我們的運維平台,在單個雲服務區故障場景下,可實現故障雲服務區的快速剔除,這個過程主要通過批量切換二級域名Region級别回源DNS A記錄實現的。
4、單雲全局故障場景:網站備份與切換方案
最後介紹一下整個高可用方案的最底層的保底方案:網站備份與故障切換,首先來看一下網站的備份流程,如圖所示:
運維人員先配置站點元數據及配置備份策略,站點管理根據備份策略下發備份任務到調度服務,然後調度服務再定時調用備份服務執行備份任務。
采集的話是由備份服務啟動Headless Browser加載入口頁,再加載靜态頁面資源,執行頁面腳本加載動态頁面資源,然後執行預置腳本加載動态頁面資源,最後識别頁面跳轉URL,包括HTML标記及腳本觸發的動态跳轉點,啟動新Headless Browser實例,實現級聯爬取。
采集完是存儲,頁面主文檔及相關頁面資源加載完成後通過OBS接口轉儲到對象存儲服務,再通過雲廠商提供的對象存儲跨Region同步能力實現頁面内容異地容災。跨雲複制則通過跨雲同步工具将備份站點頁面内容,同步到其他雲廠商對象存儲服務,實現跨雲容災。
備份結束後,再看一下故障切換流程。當基礎設施問題等原因導緻的單雲多Region故障使得Web服務整體不可用時,開始故障檢測,頁面可用性撥測服務監測到雲服務區A、B不可用,在5分鐘内發出告警。
往下是故障轉移,成立重大問題應急處理作戰小組,同時打開運維容災管理平台,查看不可用區域、備份站點撥測是否正常。如果同雲備份站點可用,優先切換同雲備份站點;如果不可用,第三方雲廠商備份站點可用,切換到備份站點。整個切換通過更新回源域名A記錄解析地址指向OBS公網訪問地址實現。
最後是故障修複階段,先定位解決問題,撥測Web Server可用,再手動執行故障回切,然後用戶回歸正常訪問。
總結以上是在各種極端場景下如何保證網站持續在線的一些實踐經驗的總結,相關方案已經在實際場景下驗證有效,并且做到持續的例行化演練。
另外,對于不同類型或規模的網站,高可用并沒有具體量化的标準,可以給幾個比較粗的級别供參考:最基礎的保證功能可用,不考慮網元的單點問題。要求再高一點,考慮應用服務集群化部署、DB、緩存等中間件進行相應的高可用部署,确保沒有基本的單點問題。再往上考慮多數據中心部署,解決單數據中心不可用問題。最後是考慮異地多活或容災,應對某一地理區域災難的場景。
除了以上傳統套路外,随着越來越多的企業都在上雲,還要考慮單個雲廠商基礎設施發生整體故障時如何快速替換及逃生的問題,例如CDN,DNS等,這些都是網站訪問基礎場景要重點考慮的故障點。
,