AWS Disaster Recovery Whitepaper

最近在做一個容災方案，瞭解到AWS有一個容災的白皮書。
於是，今天粗略把 AWS 的容災白皮書 讀了一遍 [1] ，白皮書中介紹了基於 AWS 的幾種容災方案。這些方案不僅僅適用於基於 AWS 的系統，也適用於通用系統。現將其關鍵點摘要下來，感興趣的同學可以讀一遍原文。

容災兩個術語

白皮書中提到了兩個關於容災的術語( industry terms)[2]

• Recovery Time Objective [3]
• Recovery Point Objective [4]

恕我孤陋寡聞，之前也參與過容災的設計，但是關於這兩個術語還是第一次知道。
這兩個術語在維基百科有定義，不確定是 AWS 開發者新增的詞條還是很早就存在。話說我司每個產品也都有容災方案，但是還沒有人能總結出這麼精準的 industry terms。所以說亞馬遜作為這個領域的leader還是有道理的。

1. RTO 恢復耗時

主站點故障後，備站點恢復到達到OLA(operational level agreement )所耗費的時間。
用另外一句話就是主站點故障後，備站點恢復到正常提供服務狀態所需要的時間。
站在使用者視角，RTO是系統服務中斷時間。

舉個例子，如果主站點在12:00 故障了，系統容災的RTO時8小時，那麼系統必須在20:00前恢復並正常提供服務。

2. RPO 恢復時間點

主站點故障後，備站點能夠恢復到過去哪個時間點的資料。
換句話說，備站點恢復後，與主站點相比，有多少資料丟失。
站在使用者視角，RPO時資料丟失的量。

舉個例子，如果主站點在12:00故障了，系統容災的RPO是1小時，那麼系統恢復後，其資料必須是到11:00的。也就是說允許丟失12:00～11:00 之間的資料。

所以以後在評判或設計一個容災方案時候，先問這兩個問題：

• RTO 值是多少
• RPO 值是多少

如果回答不上來，那麼這個方案肯定是沒想明白的。

容災方案

白皮書中將容災方案按照RTO以及成本排序，稱為容災方案圖譜。

Backup and Restore

備份恢復是最常見的一種容災手段，將主站點資料備份到與主站點隔離的儲存裝置。當生產環境故障後，能夠在備站點將資料恢復。

AWS提供了一系列的高可靠儲存服務：

• Amazon S3，簡單物件儲存，11個9可靠性
• Amazon Glacier，如果覺得S3太貴的話
• Amazon VTS，虛擬磁帶儲存，如果要儲存巨大且時間長的資料的話

使用Amazon的這些儲存服務，加上備份恢復工具，就可以實現一個容災系統。

備份示意圖

恢復示意圖

Pilot Light

Pilot Light 是一個裝置，這個是一個類似點火器的裝置，如煤氣灶的點火器，通過點火器可以把煤氣灶點燃，然後就可以做飯了：）

Pilot Light用到容災系統中，要表達的意思是，在備站點部署一個服務，通過這個服務可以將整個系統執行起來。

準備

• 備站點安裝資料庫服務，並建立與主站點之間的資料複製關係
• 主站點的作業系統或檔案做成 AMI ，在備站點恢復時候直接載入為EC2
• 定期測試備站點的恢復[5]
  

恢復

• 使用 AMI 建立 EC2
• 根據情況加大資料伺服器的配置
• 增加額外的資料伺服器（如果有需要）
• 配置系統（一些配置不是通過 AMI 匯入就可以生效的）
• 將 DNS 對映為備站點IP地址 [6]
  

Warm Standby

Warm Standby 是在備站點複製了主站點，但是它們還是有差別的：

• 備站點服務執行但是不對外提供服務
• 備站點的伺服器配置是最小配置(These servers can be running on a minimum-sized fleet of Amazon EC2 instances on the smallest sizes possible) (fleet of Amazon EC2 好霸氣～～)

準備

• 備站點安裝資料庫服務並同步資料
• 備站點申請最小配置的EC2安裝並app
• 定時執行app的升級和補丁，保持與主站點一致
  

恢復

• 增加EC2數量（橫向擴充套件）（擴成與主站點一致）
• 增加EC2配置（縱向擴充套件）（擴成與主站點一致）
• 增加資料庫例項數（擴成與主站點一致）
• 切換 DNS 對映到備站點
  

Multi Site

Multi Site 指的是 active-active 的容災方案。
主備站點同時對外提供服務，由DNS根據負載決定將請求轉發到哪個站點。

準備

• 將主站點系統複製到備站點，伺服器和配置都相同
• 在DNS上配置路由策略
  

恢復

• 手動切換（DNS上切換）
• 或者配置DNS failover
  

Fail Back

當主站點故障修復後，我們還需要將服務切換到主站點，這個過程稱為 fail back。
不同的容災方案，fail back的方法不一樣。

Backup and Restore

• 凍結備站點的修改操作
• 備份資料
• 恢復到主站點
• 切換DNS指向主站點
• 解凍

Pilot light, warm standby, and multi-site

• 凍結備站點的修改操作
• 將資料複製方向改為從主向備
• 切換DNS指向主站點
• 解凍

1. AWS 容災白皮書 https://media.amazonwebservices.com/AWS_Disaster_Recovery.pdf  ↩
2. 在白皮書中成為術語，實際上是兩個評判容災方案的兩個指標  ↩
3. https://en.wikipedia.org/wiki/Recovery_time_objective  ↩
4. https://en.wikipedia.org/wiki/Recovery_point_objective  ↩
5. 前段時間發生的支付寶不可用事件，阿里官方申明是光纖被挖斷，所以前面文章也有提到，阿里現在就有了一個 光纖日  ↩
6. 在備站點接管業務後，備站點需要定時備份，防止備站點故障後資料丟失  ↩