《OpenStack高可用集群（上冊）：原理與架構》—1.4 業務系統高可用性概述

1.4　業務系統高可用性概述

對于企業級用戶而言，業務系統的高可用性（High Availability，HA）和容災恢復（Disaster Recovery，DR），即通常所說的HADR是必須的，也是任何需要進入企業級應用的IT架構無法回避的問題，不管是傳統IT架構，還是新型的云計算架構，都要面臨如何實現HADR的過程。

圖1-17　云計算進階路線

1.4.1　業務系統高可用性

高可用性是確保企業重要業務系統持續性和非中斷性運行的關鍵，高可用性是指本地系統在某個軟硬件模塊出現計劃內停止運行或非計劃內故障的情況下，基于本地系統的應用仍能繼續提供訪問的能力，并且這種非計劃內的故障是隨機的，可能是業務流程、物理設施或者IT軟/硬件的故障。關于高可用性，最簡單的描述就是企業某一臺或幾臺服務器宕機了，但是企業用戶卻完全感覺不到應用訪問上有何異常。通常，關鍵業務系統的高可用性需要由多臺物理服務器提供的集群構成，一旦其中某臺服務器宕機了，則在該服務器上運行的服務就會啟動故障切換（Failover）。業界最常見的雙機故障切換便是IBM的PowerHA，HA集群節點之間通過以太網絡或者SAN網絡（不是必須的）以及磁盤心跳進行彼此通信，一旦集群管理軟件檢測到某臺服務器出現了網絡或系統層面的故障，就會觸發集群的Failover操作，將故障節點上的應用切至正常節點運行。在HA故障切換過程中，有兩個切換成本維度是在設計高可用時必須考慮的：

RTO。RTO（Recovery Time Objective）是指故障恢復的時間，衡量的是故障恢復時間的快慢維度。RTO的最佳值是0，即故障被立即恢復，中間沒有任何中斷的時間；最壞情況便是無窮大，即故障后的服務永遠恢復不了。通常RTO值為0和無窮大的情況都極少出現，RTO正常值的單位一般為秒和分鐘，從幾秒到幾分鐘不等，主要根據業務系統的軟硬件和集群架構設計來決定。

RPO。RPO是指數據恢復的程度，衡量的是故障后數據恢復的完整性維度，數據恢復涉及企業的備份恢復及容災策略，理想情況下，RPO的值為0，即沒有任何數據丟失，恢復后使用的是同步的數據，如果RPO大于0，則意味著恢復后有數據丟失，例如RPO＝1，則意味著恢復后將會丟失一天的數據。

對于RTO和RPO而言，最理想的情況就是RTO＝RPO＝0，但是這幾乎無法實現，或者說實現成本相當巨大，幾乎很少有企業能夠實現這類理想情況。從設計上來說，要保證RPO＝0，最簡單的實現方式便是數據實時同步，即存儲的數據對多個節點的讀寫來說都是完全一致的，不存在任意兩個節點讀取到不同數據的情況，具體的實現可以是共享存儲，如開源的NFS或者IBM GPFS等都是這類共享存儲的實現，另外一種實現方式就是存儲硬件層面的實時同步，即不同節點可以讀寫不同存儲，但是后端多臺存儲之間的數據一定是同步的，目前很多商業存儲都能實現這點，如EMC的VPLEX Metro和IBM的SVC等產品。而對于RTO為0的實現，則是采用雙活集群（Active/Active）和負載均衡的方式，多個節點上的應用隨時都在對外服務，任何一個節點的故障都不會出現訪問中斷，而如果采用主備（Active/Passive）模式的HA集群，則需要謹慎考慮RTO的值，原則上是越小越好。關于業務系統的高可用性，一般通過全年的運行時間和宕機時間來計算，也即我們經常在各種公有云運營商SLA上面看到的幾個9的可用性，高可用性的計算公式為：[1―（宕機時間）/（宕機時間＋運行時間）]，常見的主要有以下幾個值：

1個9。即全年90.0%的可用性，全年365天的宕機時間即為36天12小時。

2個9。即全年99.0%的可用性，全年365天的宕機時間即為87小時36分鐘。

3個9。即全年99.9%的可用性，全年365天的宕機時間即為8小時46分鐘。

4個9。即全年99.99%的可用性，全年365天的宕機時間即為52分鐘33秒。

5個9。即全年99.999%的可用性，全年365天的宕機時間即為5分鐘35秒。

11個9。這個幾乎是幾年才宕機一次了，目前很少有云服務商能夠做到這點，更不用說傳統的IT架構了，當然IBM的z系列大型機例外。

OpenStack 存儲

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。