雲區域（region)，可用區（AZ），跨區域數據複製（Cross-region replication）與災備（Disaster Recovery）（部分2）

 本文分兩部分：部分1 和 部分2。部分1 介紹 AWS，部分2 介紹阿里雲和OpenStack雲。

2. 阿里雲

2.1 阿里雲各產品的HA和DR能力

地域：是指物理的數據中心。資源建立成功後不能更換地域。

可用區：是指在同一地域內，電力和網絡互相獨立的物理區域。同一可用區內實例之間的網絡延時更小。

阿里云爲全世界多個地域提供雲計算服務，每一個地域(Region)都包含多個可用區(Avzone)。 同一個地域下的可用區都被設計爲相互之間網絡延遲很小(3ms 之內)以及故障隔離的單元。 

雲服務器ECS：只能在一個AZ 內，跨region的 ECS 內網不通。不一樣地域的雲服務器 ECS、關係型數據庫 RDS、對象存儲服務 OSS 內網不互通。不一樣地域之間的雲服務器 ECS 不能跨地域部署負載均衡，即在不一樣的地域購買的 ECS 實例不支持跨地域部署在同一負載均衡實例下。ECS自己沒有高可用性和容災，須要經過架構來實現。

 

SLB： 當前提供的負載均衡實例大可能是多可用區實例，主備實例在同城不一樣可用區機房，當主實例機房出現故障，能及時進行切換，來實現容災和服務的高可用性。

RDS：

• 雙機高可用版RDS：也就是RDS單可用區版本，是指RDS實例的主備節點處於相同的可用區。若是ECS和RDS部署在相同的可用區，網絡延時更小。在主實例出現故障時候能夠進行主備切換，具備高可用和容災特性。兩個實例運行在同一個可用區下的兩臺物理服務器上,可用區內機櫃、空調、 電路、網絡都有冗餘。經過半同步的數據複製方式和高效的 HA 切換機制，RDS 爲用戶提供了高於物理服務器極限的數據庫可用性。

 

• 多可用區RDS：

爲了提供比單可用區實例更高的可用性，RDS 支持多可用區實例(也叫作同城雙機房或者同城容災實例 )。多可用區實例將主備實例部署在不一樣的可用區，當一個可用區(A) 出現故障時流量能夠在短期內切換到另外一個可用區(B)。 整個切換過程對用戶透明，應 用代碼無需變動。

注意:發生容災切換時應用到數據庫的鏈接會斷開，須要應用從新鏈接 RDS。只有部分地域有多可用區RDS。

 

 

 

 

• 跨域容災實例：RDS 多可用區實例的容災能力侷限在同地域的不一樣可用區之間。爲了提供更高的可用性， RDS 還支持跨地域的數據容災。 用戶能夠將地域 A 的 RDS 實例 A’經過數據傳輸(Data Transmission)異步複製到地域 B 的 RDS 實例 B’(實例 B’是一個完整獨立的 RDS 實 例，擁有獨 立 的鏈接地址、帳號和權限)。

  配置了跨域容災實例後，當實例 A’所在地域發生短時間不可恢復的重大故障時，用戶在另一個地域的實例 B’隨時能夠進行容災切換。切換完成後，用戶經過修改應用程序中的數 據庫鏈接配置，能夠將應用請求轉到實例 B’上，進而得到高於地域極限的數據庫可用性。

  所以，爲了支持跨域容災，RDS之間還能夠用DTS同步和遷移數據，即分別在可用區A和B購買雙機高可用RDS，而後建立DTS同步。

 

RDS 數據複製方式有如下三種方式：

• 異步複製（Async）：應用發起更新（含增長、刪除、修改操做）請求，Master 完成相應操做後當即 響應應用，Master 向 Slave 異步複製數據。所以異步複製方式下， Slave 不可用不影響主庫上的操 做，而 Master 不可用有較小几率會引發數據不一致。
• 強同步複製（Sync）：應用發起更新（含增長、刪除、修改操做）請求，Master 完成操做後向 Slave 複製數據，Slave 接收到數據後向 Master 返回成功信息，Master 接到 Slave 的反饋後再響應 應用。Master 向 Slave 複製數據是同步進行的，所以 Slave 不可用會影響 Master 上的操做，而 Master 不可用不會引發數據不一致。
• 半同步複製（Semi-Sync）：正常狀況下數據複製方式採用強同步複製方式，當 Master 向 Slave 復 制數據出現異常的時候（Slave 不可用或者雙節點間的網絡異常），Master 會暫停對應用的響應，直 到複製方式超時退化成異步複製。若是容許應用在此時更新數據，則 Master 不可用會引發數據不一 致。當雙節點間的數據複製恢復正常（Slave 恢復或者網絡恢復），異步複製會恢復成強同步複製。 恢復成強同步複製的時間取決於半同步複製的實現方式，阿里雲數據庫 MySQL5.5 版和 MySQL5.6 版有所不一樣。

2.2 阿里雲的容災部署架構

2.2.1 基礎容災架構

在阿里雲平臺上，對於中小型企業，業務量不是特別大，對異地容災要求不是特別強烈，則可採用如下高可用方案，能夠在同一地域下選擇購買雲產品。建議在VPC網絡環境下，選擇同一可用區或者同地域不一樣可用區的雲產品。

2.2.2 同城容災架構

對中大型用戶來講，但願業務系統要求具有同城容災的能力，能夠考慮在同城不一樣可用區之間對原有應用架構作一套完整的備份。若是某個能夠去出現像IDC機房斷電或者火災等故障時，能夠經過前端切換DNS來及時恢復業務。

備註：我認爲從Intenet到右邊方框的線條應該爲爲虛線，由於右邊的環境在正常狀況下不提供服務，而只有在左邊環境不可用後切換到右邊環境。

2.2.3 跨城市容災

對於一些大型企業在業務安全全性、服務可用性和數據可靠性方面既要求具有同城容災又要求具有異地容災時，能夠採用這種容災架構方式既能夠解決單機房故障也能夠應對像地震等災難性故障。

不一樣地域之間能夠採用阿里雲的高速通道進行私網通訊，保障數據庫之間的數據實時同步，將數據傳輸延遲降到最低。故障發生時能夠經過前端DNS實現秒級切換，及時恢復業務。

說明：圖上華東的兩個環境能夠同時運行，由於都是採用可用區A裏面的 RDS-Master，當可用區A不可用時，會切換到使用可用區B 中的 RDS-Standy；當華東整個區域不可用時，會切換到華南區域中的環境。

3. OpenStack雲

3.1 OpenStack 中的有關概念

要在OpenStack環境中實現AWS那樣的AZ架構仍是很是不容易的，主要困難包括但不限於：

• 網絡層：AZ IDC之間的大二層物理網絡，SDN 網絡，跨區域網絡等
• 存儲層：對象存儲跨區域複製；數據備份到對象存儲，如今的cinder backup 功能仍是很弱；其它各類備份功能；
• 平臺層：跨IDC的OpenStack部署架構，跨AZ的虛機遷移，大規模節點納管，CMP實現等

在實際實現中，看到較多的案例都是每一個IDC內搭建一個OpenStack region，而後在region 內實現以機架爲單元的可用區。

3.2 容災

3.2.1 容災架構

 

 

3.2.2 容災場景

根據AWS 上容災的四個場景，對OpenStack 雲容災作下總結：

容災場景	OpenStack 雲	不足和問題
備份&恢復	1. 將虛機的系統盤打包爲自有鏡像，保存到對象存儲中 2. 對磁盤作快照 3. 對磁盤作備份	1. 若是對象存儲不能跨區域複製的話，那麼沒法跨區域拷貝自有鏡像 2. 磁盤備份的效率比較低，並且受限於對象存儲的跨區域複製能力
Pilot Light（Cold Standny）	在另外一個region上建立數據庫實例，並設置數據同步機制	1. 數據同步方式是採用同步的仍是異步的，如何處理數據不一致 2. 恢復是須要回復應用環境，但受限於跨區域的應用系統鏡像拷貝能力，不少狀況下須要手工搭建應用環境
溫備 （Warm Standby）	在另外一個region 上建立完整的但規格較小的熱備環境，但不提供服務	1. 跨數據中心的流量切換手段。若是是公網，能夠藉助公有云的智能DNS；若是是內網，則須要搭建跨數據中心的負載均衡。 2. 數據同步問題同上 3. 虛機鏡像問題同上
熱備 （Hot Standby）	在另外一個region 上建立完整但規格較小的運行環境，承擔少部分生產流量	1. 跨region 流量分流手段。若是是公網，能夠藉助公有云的智能DNS；若是是內網，則須要搭建跨數據中心的負載均衡。 2. 數據同步問題同上 3. 虛機鏡像問題同上

 

 

參考連接：

• https://yq.aliyun.com/articles/62430