標籤:jvm dnv rac bsh wp7 cdp margin pop avr
??
眼下國內非常多使用者對於雲端服務的可用性存在誤解,什麼樣子的誤解呢?比方某雲端服務商,在華南某地有一個機房,在華東有一個機房。
這個客戶就提到一個需求,你提供的99%可用性的概念是什麼意思呢?是不是我的機器在南方機房出了問題。我的機器就自己主動的轉到華東機房嗎?
從眼下在和客戶的溝通與交流來看,貌似大部分使用者都有這樣的想法。覺得雲端服務應該從跨地區和跨網站的方向進行高可用,殊不知這個是一個非常難達到的目標。
在金融行業常常存在兩地三中心的概念,在兩地三中心的概念中。我們常常可以看到例如以下定義的描寫敘述:
主要資料中心
全部業務和資料的承載中心,為了保證較可靠的資料訪問和較高的可用性。一般來說資料中心距離我們的辦公地點距離一公裡以內。
資料中心內承載了全部的資料、資料庫、訪問層的應用
輔助資料中心
輔助資料中心的業務相當於全部主承載資料中心的副本。為了保障資料的整體安全,我們的資料中心距離我們的主要資料中心大概40公裡左右,防止主要資料中心發生了相似火災和水淹等地區小規模災害。
輔助資料中心在主要資料中心出現相似小規模災難後進行資料切換。大部分企業都是將輔助資料中心作為備用網站,也有非常多企業將同城的輔助資料中心作為他們的備用網站。
當啟用了備用網站後,企業的業務資料中心大部分使用者可以利用輔助資料中心的辦公設施進行辦公。
第三地的輔助資料中心
通常第三地的資料中心是作為同城資料中心由於大規模天災造成無法短期內恢複業務。那麼就必須啟用第三地的資料中心來啟動業務。保證業務的持續執行。通常異地的資料中心恢複執行須要做一些網路、業務和資料的切換須要時間,因此切換第三地的資料中心須要4個小時左右的時間,切換後,關鍵業務人員可以通過飛機的方式到異地辦公,保證關鍵業務資料可以持續執行。
因此多數情況我們提到的SLA的 99%以上在多數情況下提到的是都是本地的高可用狀況。
而基於兩地三中心的模式我們相對來說投入也是非常巨大的,由於必須考慮到達到對應層級的SLA須要我們必須投入對應的硬體和軟體成本,對於兩地來說,要達到等同的應用等級,我們要保證至少我們的硬體投入是 2倍以上。而第三中心啟用後。我們的成本也是對應的硬體成本至少是3倍或者數十倍以上。
而眼下大多數雲提供的高可用性也不意味著提高高可用的SLA層級可以實現跨地區轉移,而多數情況下也是本地應用的高可用性,而遠程高可用則意味著不是採用單一實例架構來實現的。
眼下微軟雲在華東和華北擁有兩個不同的資料中心。眼下提供了99.95%的高可用。當然我們也必須設計出高可用的架構來保證我們的真箇資料營運的正常。
這裡面有個問題,當資料和應用出現故障了。我們怎麼保證資料正常呢?這就要靠我們關鍵的Azure 提供的一個功能:
TrafficManager
Traffic Manager 中文翻譯為流量控制。這個讓非常多人會覺得是控制流程量大小,事實上Traffic Manger 一個非常重要的功能就是控制我們的流量走向。
眼下Traffic 支援三種流量走向模式:
容錯移轉
他的工作模式是通過別名方式進行工作,將2個雲端服務或者多個雲端服務實現容錯移轉,系統內建的自己主動檢測方式可以檢測出相對應的網站和檔案夾是否出現狀況,一旦出現故障,他通過自己主動檢測的機制來講流量導向到訪問正常的網站。
基於效能
若要對分布在全球不同資料中心的終結點進行Server Load Balancer,可以將傳入的流量定向到最靠近的終結點,由於發出請求的client與該終結點之間的延遲最低。
通常,"最靠近的"終結點對應於地理距離最短的終結點。使用"效能"Server Load Balancer方法可以基於位置和延遲進行分發,但無法考慮網路設定或負載中的即時變化。
流量管理員定期產生"Internet 延遲表"。流量管理員基礎結構執行測試來確定全球不同點與託管著終結點的 Azure 資料中心之間的往返時間。
DNSRR
這樣的方式會將使用者訪問依據訪問的應用的權重來分配使用者訪問,或者在相同的權重以下實現使用者的隨機訪問,也就是基於DNS Round Robin 方式進行訪問的負載。
我們接下來的目的是實現應用訪問的容錯移轉。我們接下來分別依據應用的簡單複雜度來實現應用和訪問的負載平衡。
我們接下來的範例會以簡單的靜態頁面,基於SQL Azure 和SQL 虛擬機器。還有Mysql 和Mysql虛擬機器的多網站同步來完畢資料的多網站訪問和複製技術。
我們下一篇文章將會以拿到訂閱後簡單配置為操作方式,而且依據不同需求配置容錯移轉的模型。
Windows Azure 容錯移轉模式及高可用個模式探討!