理解高可用和災備
1.高可用 （High Availability，簡稱 HA）
高可用性是指提供在本地系統單個組件故障情況下，能繼續訪問應用的能力，無論這個故障是業務流程、物理設施、IT軟/硬件的故障。最好的可用性， 就是你的一臺機器宕機了，但是使用你的服務的用戶完全感覺不到。你的機器宕機了，在該機器上運行的服務肯定得做故障切換（failover），切換有兩個維度的成本：RTO （Recovery Time Objective）和 RPO（Recovery Point Objective）。RTO 是服務恢復的時間，最佳的情況是 0，這意味著服務立即恢復；最壞是無窮大意味著服務永遠恢復不了；RPO 是切換時向前恢復的數據的時間長度，0 意味著使用同步的數據，大於 0 意味著有數據丟失，比如 ” RPO = 1 天“ 意味著恢復時使用一天前的數據，那麽一天之內的數據就丟失了。因此，恢復的最佳結果是 RTO = RPO = 0，但是這個太理想，或者要實現的話成本太高，全球估計 Visa 等少數幾個公司能實現，或者幾乎實現。
對 HA 來說，往往使用共享存儲，這樣的話，RPO =0 ；同時往往使用 Active/Active （雙活集群） HA 模式來使得 RTO 幾乎0，如果使用 Active/Passive 模式的 HA 的話，則需要將 RTO 減少到最小限度。HA 的計算公式是[ 1 - (宕機時間)/（宕機時間 + 運行時間）]，我們常常用幾個 9 表示可用性：
- 2 個9：99% = 1% * 365 = 3.65 * 24 小時/年 = 87.6 小時/年的宕機時間
- 4 個9: 99.99% = 0.01% * 365 * 24 * 60 = 52.56 分鐘/年
- 5 個9：99.999% = 0.001% * 365 = 5.265 分鐘/年的宕機時間，也就意味著每次停機時間在一到兩分鐘。
- 11 個 9：幾乎就是幾年才宕機幾分鐘。 據說 AWS S3 的設計高可用性就是 11 個 9。
服務的分類
HA 將服務分為兩類：
- 有狀態服務：後續對服務的請求依賴於之前對服務的請求。
- 無狀態服務：對服務的請求之間沒有依賴關系，是完全獨立的。
HA 的種類
HA 需要使用冗余的服務器組成集群來運行負載，包括應用和服務。這種冗余性也可以將 HA 分為兩類：
- Active/Passive HA：集群只包括兩個節點簡稱主備。在這種配置下，系統采用主和備用機器來提供服務，系統只在主設備上提供服務。在主設備故障時，備設備上的服務被啟動來替代主設備提供的服務。典型地，可以采用 CRM 軟件比如 Pacemaker 來控制主備設備之間的切換，並提供一個虛機 IP 來提供服務。
- Active/Active HA：集群只包括兩個節點時簡稱雙活，包括多節點時成為多主（Multi-master）。在這種配置下，系統在集群內所有服務器上運行同樣的負載。以數據庫為例，對一個實例的更新，會被同步到所有實例上。這種配置下往往采用負載均衡軟件比如 HAProxy 來提供服務的虛擬 IP。
2.災難恢復 （Disaster Recovery）
幾個概念：
- 災難（Disaster）是由於人為或自然的原因，造成一個數據中心內的信息系統運行嚴重故障或癱瘓，使信息系統支持的業務功能停頓或服務水平不可接受、達到特定的時間的突發性事件，通常導致信息系統需要切換到備用場地運行。
- 災難恢復（Diaster Recovery）是指當災難破壞生產中心時在不同地點的數據中心內恢復數據、應用或者業務的能力。
- 容災是指，除了生產站點以外，用戶另外建立的冗余站點，當災難發生，生產站點受到破壞時，冗余站點可以接管用戶正常的業務，達到業務不間斷的目的。為了達到更高的可用性，許多用戶甚至建立多個冗余站點。
- 衡量容災系統有兩個主要指標：RPO（Recovery Point Objective）和 RTO（Recovery Time Object），其中 RPO代表 了當災難發生時允許丟失的數據量，而 RTO 則代表了系統恢復的時間。RPO 與 RTO 越小，系統的可用性就越高，當然用戶需要的投資也越大。
大體上講，容災可以分為3個級別：數據級別、應用級別以及業務級別。
| 級別 | 定義 | RTO | CTO |
| 數據級 |
指通過建立異地容災中心，做數據的遠程備份，在災難發生之後要確保原有的數據不會丟失或者遭到破壞。但在數據級容災這個級別，發生災難時應用是會中斷的。 在數據級容災方式下，所建立的異地容災中心可以簡單地把它理解成一個遠程的數據備份中心。數據級容災的恢復時間比較長，但是相比其他容災級別來講它的費用比較低，而且構建實施也相對簡單。 但是，“數據源是一切關鍵性業務系統的生命源泉”，因此數據級容災必不可少。 |
RTO 最長(若幹天) ，因為災難發生時，需要重新部署機器，利用備份數據恢復業務。 | 最低 |
| 應用級 | 在數據級容災的基礎之上，在備份站點同樣構建一套相同的應用系統，通過同步或異步復制技術，這樣可以保證關鍵應用在允許的時間範圍內恢復運行，盡可能減少災難帶來的損失，讓用戶基本感受不到災難的發生，這樣就使系統所提供的服務是完整的、可靠的和安全的。 | RTO 中等（若幹小時） | 中等。異地可以搭建一樣的系統，或者小些的系統。 |
| 業務級 | 全業務的災備，除了必要的 IT 相關技術，還要求具備全部的基礎設施。其大部分內容是非IT系統（如電話、辦公地點等），當大災難發生後，原有的辦公場所都會受到破壞，除了數據和應用的恢復，更需要一個備份的工作場所能夠正常的開展業務。 | RTO 最小（若幹分鐘或者秒） | 最高 |
3.HA 和 DR 的關系
兩者相互關聯，互相補充，互有交叉，同時又有顯著的區別：
- HA 往往指本地的高可用系統，表示在多個服務器運行一個或多種應用的情況下，應確保任意服務器出現任何故障時，其運行的應用不能中斷，應用程序和系統應能迅速切換到其它服務器上運行，即本地系統集群和熱備份。HA 往往是用共享存儲，因此往往不會有數據丟失（RPO = 0），更多的是切換時間長度考慮即 RTO。
- DR 是指異地（同城或者異地）的高可用系統，表示在災害發生時，數據、應用以及業務的恢復能力。異地災備的數據災備部分是使用數據復制，根據使用的不同數據復制技術（同步、異步、Strectched Cluster 等），數據往往有損失導致 RPO >0；而異地的應用切換往往需要更長的時間，這樣 RT0 >0。 因此，需要結合特定的業務需求，來定制所需要的 RTO 和 RPO，以實現最優的 CTO。
也可以從別的角度上看待兩者的區別：
- 從故障角度，HA 主要處理單組件的故障導致負載在集群內的服務器之間的切換，DR 則是應對大規模的故障導致負載在數據中心之間做切換。
- 從網絡角度，LAN 尺度的任務是 HA 的範疇，WAN 尺度的任務是 DR 的範圍。
- 從雲的角度看，HA 是一個雲環境內保障業務持續性的機制，DR 是多個雲環境間保障業務持續性的機制。
- 從目標角度，HA 主要是保證業務高可用，DR 是保證數據可靠的基礎上的業務可用。
一個異地容災系統，往往包括本地的 HA 集群和異地的 DR 數據中心。一個示例如下：
aster SQL Server 發生故障時，切換到 Standby SQL Server，繼續提供數據庫服務：
在主機房中心發生災難時，切換到備份機房（總公司機房中心）上，恢復應用和服務：
4.現有系統的災備架構
現有一個完整的應用災備架構如圖：
正常狀況下，大家都聯同一個區域的數據庫
區域1應用當機情況：
應用及數據庫當機情況：
現有架構問題：
- 應用需要在兩個區域分別發版本
- 在Kubernetes架構下，容器無法停止，只能基於helm進行刪除，這導致再次切回來時需要重新發版本，存在風險
- 持久化數據通過nas進行不同區域間的拷貝，在非計劃當機中，需要規劃備份的時間
- 數據庫和Redis域名同樣基於域名切換，而不是VIP切換，易於出錯
優化方案：
- 嘗試Kubernetes Federation,解決多次發版本問題
- Zone1能否在出現問題時不再運行？有待探討。
理解高可用和災備