本文描述來自雲計算用例組的 「雲計算用例白皮書」 版本 4.0 —— 由開放 web 社區的 1,400 多位參與者(在版本 3.0 時為 900)所創建的資訊倉庫。 它最初是由一組開放雲宣言的支援者所創建,後來參與者增長到包括大小公司的代表、政府機構、諮詢機構、以及供應商。
「雲計算用例白皮書」 的範圍非常全面,因此,我們沒必要一次讀完整個文檔。 在本回顧中,我們重點關注組織對雲中服務等級管理問題的評價,這點很重要,因為 SLAs 描述了雲提供者和雲客戶之間的關係,從本質上定義了,可信雲服務客戶的基礎是具有雲服務提供者交付基礎設施服務的能力。
什麼是 SLA?
作者同意 SLA 應當包含:
提供者所提供服務的清單,以及每個服務的完整描述。
確定提供者正提供其所承諾服務的度量標準,以及用於監控服務的審計機制。
供應者與消費者各自的職責,以及如果未達到 SLA 條款時,針對各方的補救措施。
有關 SLA 隨時間變化的描述。
作者討論了兩類 SLAs —— off-the-shelf 協定和定制,協商協定。 注明了具有關鍵資料需求的客戶不適合採用 off-the-shelf 協定,因此,遷移到雲之前的第一步是確定您的資料及應用有多重要。
公共雲經常提供非協商 SLA ,這是要徑任務應用或資料無法接受的。
什麼是 SLO?
SLA 包含服務等級目標(SLOs),其客觀定義了服務的可測量條件;一些例子包括有關輸送量的參數以及資料流程的頻率和時間,VMs 以及其他資源和實例的可用百分比,或者用於 SLOs 重要性分級的緊迫性評價(比如 「 可用性比回應時間更重要」)。
SLO 期望應當依據應用及應用所訪問的資料是否位於相同的雲而不同。
監測與測量
服務等級管理,基於 SLOs,是如何搜集和處理雲的性能資訊。 其使用方式為:
雲提供者利用服務等級管理來進行基礎設施方面的決策;例如,如果輸送量無法持續滿足客戶需求,提供者可以重新分配頻寬或者增加更多硬體。 或者決定通過犧牲其他客戶來取悅這一客戶。 對於提供者,SLM 設計用於基於業務目標和先進技術,來輔助最優決策。
雲客戶利用 SLM 來決定如何使用雲服務;比如是否在該價位增加更多虛擬機器,因為價格太高而不划算。 有時候還涉及如何自動化這些決策。
關於 SLA 條款,應考慮哪些要素?
作者提出在定義 SLA 條款時需要考慮的 10 個要素:
業務級別目標:組織在準確定義需要哪些服務之前必須先確定為何 要採用雲服務。 這一點不是技術問題,而是組織策略問題:一些組織將會削減經費或者放鬆對基礎設施的控制。
雙方的職責:平衡提供者與客戶的職責很重要。 例如,提供者將對 Software-as-a-Service 方面負責,但是,客戶主要對其採用授權軟體及處理敏感性資料的 VM 負責。
業務連續性/災害復原:客戶要確保提供者維持著足夠的災害復原能力。 有兩個相關的例子:在雲中存儲有價值資料用於備份和雲爆破 (當 in-house 資料中心無法處理進程負載時,進行切換)。
冗余:考慮提供者如何實現系統冗余。
維護:採用雲的最大好處之一是,由提供者進行維護。 但是,客戶應當知道,提供者何時處理維護任務:
在這期間服務是否可用?
是否服務可用,但是提供較低輸送量?
客戶是否有機會針對升級的服務進行應用測試?
資料位置:依照規則,不同類型的資料只能存儲到特定的物理位置。 提供者可通過一個保證來回應這些需求,該保證是,客戶的資料將只存儲在特定位置,並具有對該情況的審計能力。
資料索取:如果法律要求提供者的設備要能夠捕獲屬於特定客戶的資料和應用,該獲取可能影響採用同一提供者的客戶。 考慮通過協力廠商來提供附加備份。
提供者失敗:考慮提供者的財務狀況,制定應變計劃。
區域:再次強調,理解管理供應商以及管理客戶的本地法律。
代理商和轉銷商:如果供應者是雲服務的代理商或轉銷商,需要理解提供者的策略和實際提供者。
SLA 要求
作者提出在考慮 SLA 時,需要關注的 14 個職責:
安全:客戶必須瞭解其安全需求,以及需要什麼控制與聯合模式來滿足這些要求。 提供者必須瞭解,他們需要向客戶交付哪些內容,來確保相應的控制與聯合模式。
資料加密:資料在活動以及閒置時必須進行加密。 必須指定加密演算法的細節以及存取控制策略。
隱私:基本隱私問題包括資料加密、保持、以及刪除。 SLA 要說清雲提供者如何在多企業架構環境中隔離資料和應用。
資料保持、刪除:提供者如何遵守保持規則和刪除策略?
硬體擦除、銷毀:與 #4. 同。
政府監管:如果由於資料類型的原因,必須執行法規,雲提供者必須能夠證明其對法規的遵守。
透明度:對於關鍵資料和應用,當違反了 SLA 條款時,提供者必須主動通知客戶。 這包括類似停電和性能問題之類的基礎架構問題,以及安全事件。
證明:提供者應當負責所需的證明並保持其目前狀態。
性能定義:執行時間 意味著什麼?每個洲上的所有伺服器是否可用?或者只有一個可用?有必要確定這些定義。 (本文章的作者建議標準化性能術語,來方便使用。 )
監測:對於潛在違反問題,您可能希望指定中立的協力廠商組織來檢測供應者的表現。
可審計性:由於消費者負責任何導致資料或可用性缺失的違背,重要的是,消費者能夠審計提供者的系統和程式。 SLA 應當明確如何以及何時進行審計。 這將給提供者帶來破壞性和成本。
度量標準:這些是在事中可監測,事後可審計的有形事務。 SLA 的度量標準必須進行客觀而毫不含糊的定義。 接下來是一列公共度量標準。
提供機器可讀的 SLA:這允許自動、動態選擇雲代理商。 換句話說,SLA 可能需要代理商為一些任務採用最廉價的可用提供者,而為另一些選擇最安全的提供者,這一類自動化是可能的。 (然而此類服務並不真實可用,而是在討論雲 SLA 標準化時要牢記在心的。 )
人機交互:按需自服務是雲計算的基本特性之一,但是 SLA 應當考慮在需要人員時,就有可用的人。
一些公共的性能度量標準(關注 #12)包括
輸送量:系統回應速度。
可靠性:系統可用性。
負載均衡:有關彈性問題。
耐久性:資料丟失的可能性如何。
伸縮性:資源能增長多少。
線性:系統性能隨著負載的增加而增長。
敏捷性:提供者回應負載變化的速度。
自動化:不需人工干預的請求處理百分比。
客戶服務回應時間。