在云環(huán)境中，閾值策略是必要的重要特性 — 當工作負載需求在達到一個預先確定的閾值水平后需要動態(tài)平衡時，就可以使用閾值策略來檢查和管理資源。根據(jù)工作負載需求超出閾值水平的量，閾值策略指示系統(tǒng)創(chuàng)建必要資源的實例。
在詳細講解創(chuàng)建和使用一個閾值策略，通過自動創(chuàng)建和釋放資源實例來動態(tài)平衡工作負載需求的有關(guān)事項之前，我們在這里首先定義閾值策略。
我們看看閾值策略的幾個關(guān)鍵屬性。
系統(tǒng)檢測到工作負載需求達到閾值水平的時間與系統(tǒng)創(chuàng)建額外資源實例的時間之間的時間段必須近乎瞬時。當工作負載需求返回閾值水平之下時，系統(tǒng)將取消上述資源分配并將其分配給其他用途。
閾值策略中應該包含的信息受到下列因素影響：
- 用戶租用的云服務類型。
- 用戶對操作系統(tǒng)和軟硬件的控制權(quán)有多大。
- 用戶所在的行業(yè)類型（例如：零售、能源和公共事業(yè)、金融市場、醫(yī)療保健、石油化工）
云服務提供者可以位于組織內(nèi)部控制的數(shù)據(jù)中心，也可以由組織外部的一個電信行業(yè)成員（比如 IBM®）托管。提供者必須確保與后端（back-office）系統(tǒng)集成，以便預訂、配給、計量、估價和收費、計費和其他功能支持用戶活動和事務。
舉例說明，一個零售業(yè)云服務用戶的數(shù)據(jù)中心有一個大型應用程序，當工作負載需求低于閾值水平時，該應用程序在云中執(zhí)行信用卡驗證。當圣誕節(jié)高峰來臨時，系統(tǒng)檢測到工作負載需求超過了閾值水平。系統(tǒng)快速做出響應，額外創(chuàng)建了一些資源實例來動態(tài)平衡工作負載需求。
當這個零售商渡過購物高峰后，工作負載需求降到了閾值水平以下，此前在云中創(chuàng)建的資源實例現(xiàn)在被釋放。由于組織對硬件有一些控制權(quán)，它們能與云服務提供者協(xié)商閾值策略中設(shè)置的條款。（在購物高峰來臨之前協(xié)商策略參數(shù)總是個好主意。）
本文余下部分將介紹一些云服務類型相關(guān)背景知識，并展示一種云類型的閾值策略與另一種云類型的閾值策略如何不同。本文還將討論為進行應用程序測試、生產(chǎn)和容量規(guī)劃而進行的資源管理中使用的閾值策略，檢查一些需要考慮的重要問題，比如閾值策略對服務水平協(xié)議（SLA）的影響。
首先考慮以下三種云服務類型中的哪一種符合您的需求：
- 軟件即服務（Software as a Service，SaaS）
- 平臺即服務（Platform as a Service，PaaS）
- 基礎(chǔ)架構(gòu)即服務（Infrastructure as a Service，IaaS）
我們還將討論，運營規(guī)模如何影響您的最佳云服務類型選擇 —— 公共云還是私有云。
假定您是一個零售業(yè)用戶，您的公司從一個 SaaS 供應商處獲取了一個許可，可以根據(jù)需要將一個用于 web 用途的應用程序用作一個服務。您選擇了一種訂閱或即付即用（pay-as-you-go）方法，因此不需要購買、安裝和維護軟硬件，也不必升級應用程序。
您擁有的惟一控制權(quán)就是從一臺桌面機或移動設(shè)備使用這個供應商的應用程序來處理一些業(yè)務任務，比如計算賬單和發(fā)票、人力資源管理。
盡管您不必控制已部署的應用程序、操作系統(tǒng)、存儲器和網(wǎng)絡(luò)，但您需要查看供應商關(guān)于資源管理的閾值策略，以防工作負載需求出現(xiàn)計劃內(nèi)或計劃外激增：
- 您想知道供應商如何設(shè)置閾值水平來確保 SaaS 的持續(xù)運營可用性。
- 您想了解供應商的 SLA 條款和備份策略。
- 如果由于供應商未能動態(tài)處理需求激增而導致服務失敗，您想知道是否可以獲得信用、補償、免費月份，或者根據(jù) SLA 中的條款終止 SaaS。
使用 PaaS，您想從創(chuàng)建到部署開發(fā)零售應用程序，以便進行應用程序測試（或生產(chǎn)即服務）。
與 SaaS 不同，您能夠控制一個完整的業(yè)務生命周期中所有針對該平臺的應用程序（例如，電子表格、字處理、備份、賬單、工資處理和發(fā)票）。
供應商控制其上運行應用程序的操作系統(tǒng)、硬件和網(wǎng)絡(luò)基礎(chǔ)架構(gòu)。供應商能夠構(gòu)建、部署、運行和管理一個零售管理應用程序的所有功能的更新和補丁。
當然，您需要一個來自 PaaS 供應商的閾值策略：
- 您想知道供應商如何設(shè)置閾值水平以確保 PaaS 持續(xù)可用。
- 如果由于供應商未能動態(tài)處理需求激增而導致服務失敗，您想得到信用、補償、免費月份，或者終止服務。
使用 IaaS，您可以在虛擬機級別控制操作系統(tǒng)、網(wǎng)絡(luò)設(shè)備和已部署應用程序：
- 您可以上下縮放虛擬服務器數(shù)量或存儲區(qū)域塊。
- 您可以根據(jù)使用情況支付云環(huán)境中的這些傳統(tǒng)計算資源的基礎(chǔ)架構(gòu)的費用。
您需要查看來自 IaaS 供應商的基礎(chǔ)架構(gòu)閾值策略：
- 您想知道供應商如何設(shè)置閾值水平來確保工作負載需求激增時 IaaS 持續(xù)可用。
- 您想能夠與 IaaS 供應商協(xié)商閾值策略中的條款和您公司適用的 SLA。
- 如果由于計算資源的基礎(chǔ)架構(gòu)未能動態(tài)處理需求激增，導致響應時間變慢，進而導致服務失敗，您想獲取信用、補償、免費月份，或者終止服務。
舉例說明，假如我的公司實現(xiàn)的銷售收入超過 10 億美元，我們發(fā)現(xiàn)私有云可能比公共云更劃算。私有內(nèi)部云與公共云有許多相同的業(yè)務特征，但與小公司（比如銷售收入低于 100 萬美元）相比，私有云擁有更高水平的治理、安全性、可用性和可恢復能力。
使用公共云，數(shù)據(jù)可能會存儲在未知位置，不容易檢索。私有云則不同，允許用戶從某個特定行政區(qū)劃（比如美國）中的已知位置檢索數(shù)據(jù)。未知位置不適合存儲依從性、隱私和敏感測試數(shù)據(jù)。這些未知位置可能位于某些地理區(qū)域中，其中一個國家的隱私和依從性法規(guī)與另一個國家可能不同。各個國家之間的數(shù)據(jù)出口控制相關(guān)法律也可能不同。
創(chuàng)建閾值策略時，我的公司需要在云環(huán)境中擁有最高水平的工作負載需求動態(tài)平衡。當工作負載超過閾值水平時，系統(tǒng)必須能夠快速創(chuàng)建額外的資源實例。
由于我的公司的經(jīng)營規(guī)模較大，面向事務的工作負載要比小公司更高，事務類型的范圍比小公司更大，數(shù)量也更多。由于事務類型由兩位或三位數(shù)值或字母代碼標識，因此大公司或小公司需要關(guān)聯(lián)每種類型的業(yè)務事務類別。適用大公司的業(yè)務事務類別（比如金融租賃）可能不適用小公司。
對于每種云服務類型，閾值策略在各個行業(yè)之間也各不相同。影響策略的因素包括組織類型、組織大小、市場條件、季節(jié)性工作負載需求、經(jīng)濟、變化的要求、新興技術(shù)以及極端天氣條件出現(xiàn)的頻率。
數(shù)據(jù)中心的數(shù)量也取決于行業(yè)；例如，政府需要大量數(shù)據(jù)中心，一直在尋找通過租用隨需所用服務節(jié)約成本、確保云環(huán)境中的運營可用性和安全性的方法。
我前面提到過 6 個行業(yè)示例 — 零售業(yè)、能源和公共事業(yè)、金融市場、醫(yī)療保健、電信和石油化工；還有其他行業(yè)。
- 航空和國防
- 汽車
- 建筑
- 消費品
- 教育
- 電子
- 森林和紙張
- 政府保險
- 生命科學
- 媒體和娛樂
- 金屬和采礦
- 旅游和運輸
- 制造和裝配
- 工業(yè)品
- 造船
- 批發(fā)和服務
比較和對比零售業(yè)和石油/化工業(yè)關(guān)于閾值策略的注意事項。當每個行業(yè)的系統(tǒng)檢測到工作負載需求超過閾值水平時，系統(tǒng)迅速創(chuàng)建額外的資源實例來動態(tài)平衡工作負載需求。當工作負載需求降到閾值水平之下時，此前分配的資源實例將被釋放。
零售業(yè)包括許多大大小小的公司，它們致力于將產(chǎn)成品銷售給終端用戶消費者。石油/化工業(yè)包括許多工業(yè)工廠、大公司和小公司，它們投資石油、天然氣和化工產(chǎn)品并將其銷售給工業(yè)消費者。
零售業(yè)的工作負載需求激增通常是可預測的（比如圣誕節(jié)購物高峰）。而石油化工業(yè)的工作負載需求變化通常基于不同的因素，這些因素不容易預測，因此通常需要進行跟蹤：經(jīng)濟、供應鏈優(yōu)化的推動力、深度石油鉆探投資、以及不可預測的極端天氣條件（比如某年出現(xiàn)暖冬，下一年卻是暴風雪）。
事務類型的區(qū)別（工業(yè) vs. 零售業(yè)）和公共云、私有云或混合云的選擇都影響閾值策略的創(chuàng)建。事務類型用于根據(jù)業(yè)務或產(chǎn)品組分組收入和費用項目。
良好的資源管理對于云環(huán)境中的資源使用平衡很重要。閾值策略確保資源使用被動態(tài)平衡，以便進行應用程序測試和生產(chǎn)。應用程序測試和產(chǎn)品測試相比可能有不同的閾值需求。預先使用容量規(guī)劃來準備您的系統(tǒng)，以便當工作負載需求到達閾值水平時分配額外的資源實例。
盡管 IT 專業(yè)人員習慣于用抽象術(shù)語進行思考，但開始處理閾值策略創(chuàng)建的一個關(guān)鍵方面是記住工作負載需求的一個關(guān)鍵組件是物理的：您正在依賴一些物理組件的可靠性等級，即使您使用的是無線設(shè)備。
閾值策略應該設(shè)置為閾值水平應該具有的內(nèi)容，比如將一個閾值水平設(shè)置為一個或多個磁盤的 75% 或 85% 的容量。閾值策略還應該包含記錄日志和監(jiān)控資源使用情況的機制。
除容量外，當閾值水平達到時，分配的資源實例的數(shù)量和分配實例所需的響應時間都應該位于日志中。另外，日志還應該包括：
- 應用程序的有狀態(tài)性
- 恢復點
- 故障轉(zhuǎn)移機制
- 云服務安全性
有狀態(tài)性（statefulness）是指在云環(huán)境中，應用程序的一個狀態(tài)是否能充分響應應用程序功能的后續(xù)狀態(tài)。例如，在下面這個經(jīng)過極度簡化的場景中，一個狀態(tài)應該轉(zhuǎn)到流程后面的一個功能狀態(tài)：
- 消費者在線選擇了一個零售項目
- 零售商將選中的項目放到購物車中
- 消費者提供信用卡信息
- 消費者提交訂單
- 零售商驗證信用卡信息
- 零售商提供一個訂單編號和預計交付時間
- 零售商感謝消費者下訂單
- 消費者收到一封訂單確認電子郵件
- 消費者收到一封電子郵件，被告知訂單正在運輸途中
如果步驟 2 的功能狀態(tài)沒有轉(zhuǎn)到步驟 3，問題的原因可能是什么呢？
- 應用程序中的新構(gòu)建破壞了邏輯嗎？
- 當系統(tǒng)檢測到閾值水平超出工作負載需求時，是閾值水平設(shè)置得太高，剩余的資源不足以繼續(xù)操作嗎？
- 如果閾值水平適當，云中有足夠的額外資源實例來確保一個步驟的狀態(tài)轉(zhuǎn)到下一個步驟嗎？
日志應該顯示應用程序處于什么狀態(tài)，以及狀態(tài)完成是否成功。
在系統(tǒng)出現(xiàn)問題之前，系統(tǒng)應該在不同的時間點創(chuàng)建一個恢復點（有計劃、手動和安裝三類）。
包含恢復點的磁盤的快照應該同時備份到本地系統(tǒng)中的磁盤和位于一個不同的遠程位置的另一個磁盤。日志應該表明恢復點創(chuàng)建的時間和用于恢復系統(tǒng)的恢復點。
系統(tǒng)還應該能夠啟動故障轉(zhuǎn)移機制來繼續(xù)運營可用性。
故障轉(zhuǎn)移機制應該包含備用有線或無線連接，以防電信運營商意外切斷連接到用戶物理設(shè)施的光纖電纜或無線網(wǎng)絡(luò)。日志應該表明故障轉(zhuǎn)移中使用的設(shè)備類型和位置。
下面有一些故障轉(zhuǎn)移機制示例：
- 負載共享冗余。 兩個或多個系統(tǒng)，每個系統(tǒng)的負載不超過總負載的 50%。當一個設(shè)備失敗時，其他設(shè)備將接管其負載，中斷時間很少甚至沒有。
- 實例資源冗余。 兩個或多個資源實例，每個實例的負載不超過總負載的 50%。當一個資源實例失敗時，其他資源實例將接管其負載。
- 備用連接重試。 如果網(wǎng)絡(luò)中斷超過兩分鐘，即嘗試通過備用連接重新連接另一個服務器。
遠程管理中的劣質(zhì)憑證、協(xié)議暴露和實現(xiàn)缺陷都可能會威脅云服務安全性。重用 IP 地址可能會導致意外的 Denial of Service attack (DoS)。
黑客可能會蓄意使用導致 DoS 的病毒來攻擊 SaaS。黑客將 PaaS 和 IaaS 平臺作為 Command and Control centers (CnC)，指揮 botnet（自動計算機網(wǎng)絡(luò)）的操作以用于分布式拒絕服務（Distributed Denial of Service，DDoS）并在云中安裝惡意軟件。
日志應該顯示一個云服務類型擁有何種類型的安全問題，以及該問題是在何時和如何修復的。
盡管您的服務供應商通常負責底層云計算系統(tǒng)，您仍舊對確保以下幾點負有法律責任：它們的系統(tǒng)滿足您的法規(guī)要求，它們的實踐比較安全，它們的管理員沒有授權(quán)無法訪問您的數(shù)據(jù)，以及有一個 SLA 存在。
確保您理解 SLA 如何運行、閾值策略如何影響 SLA、以及有些什么流程和預期，以防您的服務供應商使您失望。
重要的 SLA 組件有正常使用時間可用性、性能標準、緊急響應時間、違約補救措施和安全性。
查明閾值水平與 SLA 中作為正常使用時間可用性的性能標準規(guī)定的那些閾值水平有什么不同。它們不應該設(shè)置為等于或高于這些可用性標準。選擇最適合您的業(yè)務需求和預算的正常使用時間可用性（97% 或 99.9%）和閾值水平。
如果出現(xiàn) SLA 違約，應該提供補救措施。例如，如果您的服務供應商違反了一個 SLA（在云中創(chuàng)建額外資源實例時響應過慢），那么該供應商應該發(fā)放一個免費信用或一個補償。如果供應商在 3 個月時間內(nèi)多次違反 SLA，則您應該有權(quán)終止服務。確認 SLA 中包含終止條款并仔細閱讀相關(guān)條款。
如果您和您的供應商不同意一次停用的長度，SLA 是否規(guī)定誰和哪里將是權(quán)威來源？您需要知道發(fā)生一個事件之后應該等待多久才發(fā)出一個索賠請求？檢查解決 SLA 中沒有涉及的事項的保險策略，這些事項包括收入損失、信譽受損、數(shù)據(jù)泄露等。
設(shè)置一個閾值策略來動態(tài)平衡工作負載需求需要預先計劃以解決在云環(huán)境中創(chuàng)建額外資源實例的問題。開發(fā)人員應該與云服務使用者和供應商溝通經(jīng)濟規(guī)模（公共云對私有云）和開發(fā)閾值策略以進行應用程序測試和生產(chǎn)等相關(guān)問題。預先使用容量規(guī)劃來準備您的系統(tǒng)，以便在工作負載需求達到閾值水平時分配額外資源實例。
學習
- 本文作者在文章 “云計算與網(wǎng)格計算：服務類型，異同點及有關(guān)問題” 中討論了閾值策略。
- 在 developerWorks 云開發(fā)人員資源 中，發(fā)現(xiàn)和共享應用程序和服務開發(fā)人員為云部署構(gòu)建項目的知識和經(jīng)驗。
- developerWorks 上的 SOA 和 web 服務專區(qū) 和 行業(yè)專區(qū) 包含更多關(guān)于本文主題的資源。
- 后續(xù)步驟：了解如何 訪問 IBM Smart Business Development and Test on the IBM Cloud。
獲得產(chǎn)品和技術(shù)
- 查看 IBM Smart Business Development and Test on the IBM Cloud 上提供的 產(chǎn)品映像。
討論
- 加入 developerWorks 上的一個 云計算小組。
- 閱讀 developerWorks 上所有不錯的 云計算博客。
- 加入 developerWorks 中文社區(qū)。
