Whitepaper - Using AWS for Disaster Recovery


以下這張照片是 Jan, 2015 在 AWS Virginia Data Center 火災的照片:

圖片來源: Amazon data center on fire in Virginia - CNN

其實災難,不管是個人還是在企業,隨時隨地都有可能發生。當企業成長到一定的規模,災難還原計畫,就越來越重要。但是做災難還原準備工作,本身在公司裡面不是所謂的 產出 任務,他屬於 備援 計畫,而且災難復原在傳統的 IT 架構裡,所需要的預算、人力、資源、時間是相當龐大的,大部份的老闆,對於這件事情是不會支持,或者也不太願意投資的。最多做所謂的 異地備援 就算是很不錯的了。

以下整理 Whitepaper - Using AWS for Disaster Recovery (Oct, 2014) 內容。大部份的圖檔都是文件裡擷取出來。


Introduction

Disaster Recovery (中文翻譯 災難還原, 簡稱 DR) 主要是災難發生前的準備到,災難發生後還原系統的過程。

RTO and RPO

  • RTO (Recovery Time Objective): 能夠完成系統還原的最大時間
  • RPO (Recovery Point Objective): 能夠還原的資料時間點


圖片來源:AWS Summit Series 2016 | Chicago - Deploying a Disaster Recovery Site on AWS

Strategies

執行 DR 本身是一件耗成本、需要動用大量資源的任務。如何選擇正確的策略是非常重要的,下圖是四種常見的策略:

底下的圖,摘錄自:AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications

Backup and Restore

下圖表示的是最基本的,即時沒有要做 DR 也應該要做的。一般要備份的有以下幾種:

  1. DB: 不管是透過批次、還是 Replication 機制。MySQL 使用 Replication、SQL Server 使用 Always On
  2. Data: 使用者資料,通常會儲存在 S3,然後透過 Cross-Replcation 備份。

Pilot Light

Pilot Light 除了第一個備份之外,另外也把 AP 的 Artifact / Configuration 部署過去了,包含以下:

  1. Artifacts: 應用程式的映像檔 (Image)、Package (maven, npm, nuget, docker)、虛擬機映像檔 (AMI) … 等
  2. Configuration: 應用程式的配置檔


Warm Standby

Warm Standby 要一個整個 Stack 的做小集合都可以跑了,換言之他只是比較小的 Production Set,所以除了前述的藥丸被,另外要完備的就是:

  1. Infra Config: 其他基礎設施的設定,像是 Networking, Managed Services … etc.

這些都完備了,其實代表的就是隨時可以把新的版本,部署到這個 DR Site。


Multi-Sites

完整的 Production Set,除了前述的準備,可能連 AutoScaling 之類的也都已經完成。

Cost and Strategies

這四種策略不難懂,但是他其實跟 成本 有息息相關,我畫了一張圖表達 策略的選擇成本結構 的關係:

如果是自建機房,那麼成本以及執行的項目,會更加可觀。而使用雲端機房,則最多的就是管理成本,另外很容易被忽視的就是:資料傳輸的成本。


FAQ

  • DR 和 HA 一樣?

Q: HA 指的是用冗余 (redundant) 增加可用性,DR 指的是在不同資料中心還原服務能力。

  • 怎樣的情境需要啟動 DR Plan?

Q: 哥吉拉登入日本東京,AWS 東京機房毀了。

  • BCP 和 DRP 有什麼不一樣?

Q: BCP (Business Continuity Planning) 包含幾個面向:

  1. 高可用 (High Availability): 高可用的解決方法就是增加服務的 冗余 (redundant)
  2. 持續維運 (Continuous Operations):設備故障時,要能夠確保業務能夠持續運作的能力。
  3. 災難復原 (Disaster Recovery): 只發生異常的時候,在不同資料中心還原服務能力。

所以 DR 只是 BCP 的其中一個項目而已。

  • Service Catalog 跟 DR 的關係?

Q: 參見:Service Catalog

  • 開發業務團隊跟 DR 的關係?他們要知道些什麼?

Q: 大概要知道 Resource Provisioning and DevOpsArtifacts Management怎樣的 CI/CD 才夠 Quality?、Config Management、Pipeline … 大概就是 軟體交付的四大支柱 (Four Pillars of Software Delivery) 提到的東西都要知道。換言之,平常測試階段,如果這四個東西都沒有的話,DR 會很難做。如果有多種業務市場,那麼 Service Catalog 也要考慮。

  • 災難演練的目的是?

Q: 除了確認系統可以正常恢復,另外也可以藉此演練培養團隊的應變能力,從中發現團隊不足的地方。像是 輕鬆聊:系統測試 (SVT) 的三兩事 提到的概念。


後記

這篇草稿原本在 2016 年就寫了,但是一直沒有發佈。今年 (2019) 很多知名的 IT Provider 發生了幾次事件,特別是 AWS:

而我也正在準備年度的演練計畫,因為這些事件堆疊,藉由熱點事件,我也在內部做了教育訓練與宣傳,分享了以下的簡報。

最後引用 Chaos Engineering 裡一段我很喜歡的話結尾:

不是你選擇那一刻,是那一刻選擇你,而你唯一能選擇的就是作好準備。 (You don’t choose the moment, the moment chooses you.)


延伸閱讀

站內資料

參考資料


Comments