控制服務容量的製作方法

2023-06-02 00:33:41 2

專利名稱：控制服務容量的製作方法
技術領域：
這裡公開的本發明涉及資源管理，尤其涉及在共享計算環境中管 理信息技術資源。
背景技術：
許多年來，網絡技術使得能夠全世界共享計算資源，並且使得能 夠全世界遠程訪問計算資源。 一 臺計算機可以輕易地與廳裡或另 一個 國家的計算機交換數據。當然，商業界不用太長時間就利用全球網絡 的能力，並且網絡技術加強了側重於通過這些網絡傳送服務的整個新 行業的成長。
這個新行業必須能夠在客戶的需求增長時預料和滿足他們的處 理需要，同時最大化現有的資源。最大化資源的一種方法是允許客戶 共享計算和網絡資源。在這個方法的一個實現中，服務提供方在主處
理單元(一般被稱為"主機"計算機)上創建計算資源的"邏輯"分區。通 常，服務提供方與若干客戶締結合同以向每個客戶提供某個等級的服 務，並且創建或指定每個客戶的資源的邏輯分區以履行其義務。於是， 一或多個合同可以允許在高峰值使用的情況下有增加的餘量。於是， 在一個客戶的高使用的情況下，服務提供方必須能夠向該客戶提供附
加資源而不消極地影響任何其它客戶的資源使用。為了提供這些附加 資源，服務提供方可以在各種邏輯分區中重新分配計算資源，直到客 戶的使用回到正常。允許客戶共享資源，但是需要服務提供方謹慎地 平衡和監視所共享的資源，使得提供方可以履行所有服務義務。
若干現有技術方法以一種或另一種形式獲得預測的資源分配。例
如，授權給McGovern等人的美國專利5，918，207公開了允許服務提供 方滿足客戶對有技能工作人員的預測需求的預測資源規划過程和系 統。McGovern等人公開了評估服務提供方的現有工作人員庫，推斷客戶的技術方向以預測客戶的需求，並且根據需要創建單獨開發計劃
以便應對所預測的需要的過程。然而，McGovern等人的申請通常限 於管理人工資源，並且未解決計算資源特有的資源分配的各方面問題。 此外，McGovern等人未解決共享資源的問題，並且需要重新分配資 源以滿足特別需求。類似地，授權給Jameson的美國專利6，625，577Bl 公開了初始分配資源的方法，但是未提供適於響應客戶對共享計算環 境中附加資源的需要的方法。
因而，需要一種分配可用資源，預料對附加資源的需要，以及響 應客戶對附加資源的需要的詳細規划過程。

發明內容
在下面公開了被稱作"控制服務容量"的本發明，其提供了允許服 務提供方履行對具有不同需求的多個客戶的當前以及未來義務、管理 計算資源的過程以及設備。具體地，本發明涵蓋產生和維護分配共享 計算環境中的容量資源的容量規劃，處理附加容量資源的請求，並且 分析附加容量資源的請求以識別出應當在未來的分配中解決的問題的 過程。如下面更詳細地描述的，這個過程通常由"容量規劃人員，，執行。
該產生以及維護容量規劃的過程包括收集容量數據，分析容量數 據以確定對附加容量資源的需要，分配容量資源以便可以履行現有以 及未來服務義務，獲得分配的批准，以及把分配通知給服務提供方和 客戶。通過從資料庫中提取服務義務，識別履行服務義務所需的資源， 並且比較所需資源和現有資源以識別需要附加容量資源的任何服務義 務，來分析容量數據。
通過從資料庫中提取請求者的權限和標準數據，確定請求者是否 有權使請求得到滿足，並且如果是，則獲得滿足請求所需的任何數據， 參照實際使用數據分析容量規劃，並且更新容量規劃以反映附加容量 資源的請求結果，來處理附加容量資源的請求。
下面詳細描述的本發明使容量規劃人員能夠預測客戶資源需求 的類型和數量，並且預測這些客戶資源需求的定時。容量規劃人員考慮多個因素以開發解決方案，並且根據其總體影響來對每個因素進行 加權。
控制服務容量的發明(l)使得能夠成本低廉並且高效地使用現有
資源；(2)輸入例如趨勢數據以規劃新和/或現有客戶的未來平臺/軟體 獲得；以及(3)基於趨勢和客戶對服務的需要主動規劃。


圖l是控制服務容量過程的概述。
圖2圖解了處理控制容量請求的子過程。
圖3圖解了處理服務權限故障的子過程。
圖4圖解了分析承諾和閾值的子過程。
圖5圖解了分析趨勢的子過程。
圖6圖解了參照實際情況分析規劃的子過程。
圖7圖解了調查偏差的子過程。
圖8圖解了為報告而管理容量數據的子過程。
圖9圖解了運行報告的子過程。
圖10圖解了產生/維護容量規劃的子過程。
圖ll圖解了收集數據的子過程。
圖12圖解了預測資源需求的子過程。
圖13圖解了對工作負載進行表徵和確定大小的子過程。
圖14圖解了確定和應用計劃方法的子過程。
具體實施例方式
根據對本發明的如附圖所示的優選實施例的更具體的描述會明 白本發明的上述和其它目的、特徵以及優勢，其中類似附圖標記表示 本發明的類似部分。
在隨後的詳細描述中，發明的控制服務容量過程由容量規劃人員 執行。為了清晰，下面對容量規劃人員的引用假定容量規劃人員是個 人，並且除非另外指出，否則人工地執行容量規劃人員的功能。但是，本領域技術人員會理解，許多容量規劃人員的功能可以應用例程編程 自動進行，並且下面描述中這個命名的使用不應該解釋為對本發明的 範圍的限制。
此外，如這裡所使用的，術語，，容量資源"包含但不限於中央處理
單元(CPU)、存儲設備、存儲器、網絡或電信硬體和外設。"容量規劃
"是主要識別由容量規劃人員定義的對任何周期可用或需要的容量資 源的任何文檔或資料庫，並且主要描述在所定義的周期內可用或所需 的容量資源的分配。"控制容量請求"是容量規劃人員接收的任何通 信，其指示獲得附加容量資源或修改容量資源的現有分配的需要或意圖。
為了基於將來客戶容量需求有效地規劃和管理容量資源，容量規 劃人員必須檢查現有資源和工作負載義務，以及可用資源和使用數據。 本領域技術人員會理解，容量規劃人員在開發這種規劃時還必須考慮 相關策略、標準和合同。
本發明可以在包含軟體、硬體或其任何組合的許多不同配置中實 現。下面對優選實施例和附圖的詳細描述引用容量規劃人員可能用於 實現本發明過程的各種軟體工具。具體地，附解了問題管理軟體
(TPM)、報告軟體(eSMRT或ESM/RT)以及通信軟體(Notes)的使用。 但是，本領域技術人員會理解，容量規劃人員可以使用各種軟體工具 來實現本發明的過程和設備，並且對具體軟體工具的引用不用於限制 本發明的範圍。此外，本領域的技術人員熟悉市場可獲得的具體軟體 工具的各種實施例，並且在這裡不詳細描述它們。
以下討論和附圖還描述了在本發明過程的優選實施例中的數據 庫的使用。本領域的技術人員會理解，資料庫可以以許多形式存在。 如這裡使用的術語，，資料庫"表示存儲在一起並且組織起來以便快速 搜索和檢索的數據的任何集合，包含但不限於平面文件資料庫、欄位 資料庫、全文本資料庫、面向對象資料庫和關係資料庫。
圖l提供控制服務容量過程的概述。通常，控制服務容量過程由 需要支持的外部過程(即，請求附加容量的客戶)調用(101)，但是也可以由內部過程所有者(即，性能管理者或客戶服務代表)調用(102)。如 圖1所示，容量規劃人員最初根據需要選擇過程路徑(103)。容量規劃 人員可用的選擇包含產生或維護容量規劃(104)，處理控制容量請求 (105)，以及執行控制容量請求或問題的分析/審查以確定有關的任何範 圍(106)。容量規劃人員可以根據許多因素進行選擇，但是通常由調用 的性質確定選擇。
圖2圖解了處理控制容量請求的過程。圖10圖解了產生和維護容 量規劃的過程。所有這些任務被圖解為其它附圖中的不同子過程，並 且在下面詳細討論。
如圖2所示，當容量規劃人員接收控制容量請求時，調用處理控 制容量請求的子過程。容量規劃人員首先分析該請求以理解需求 (201)。容量規劃人員接著審查客戶的權限(202)以確定客戶是否有權接 收服務，或最少有權進行請求(203)。容量規劃人員還必須審查請求方 客戶可用的任何標準容量數據。參見圖2，客戶的權限和容量數據通常 被存儲在資料庫中以利於檢索。
如果客戶無權接收所請求的服務，則容量規劃人員對權限故障細 節形成文檔(204)以準備調用圖3所圖解的和下面描述的處理服務權限 故障的子過程(205)。但是，在處理權限故障之後，容量規劃人員確定 是否不管故障而提供服務(206)。如果容量規劃人員確定應當拒絕服務 請求，則容量規劃人員通知客戶協調者，並且客戶協調者通知請求者 不能滿足請求(207)。容量規劃人員接著關閉請求。
如果客戶有權接收服務，則容量規劃人員確定請求是否需要非標 準的數據(208)。通常，標準數據包括但不限於每個客戶申請使用的 CPU分鐘、磁碟存儲、網絡帶寬和存儲器。緩存是解決容量規劃問題 可能需要的非標準數據的例子。如果目前未提供所需數據，則容量規 劃人員向適當數據收集小組提交數據的請求(209)。在獲得所需數據之 後，容量規劃人員從下列選項中選擇適當的操作過程(212): (l)參照實 際情況分析規劃(214); (2)為報告而管理容量數據(216); (3)分析趨勢 (215); (4)提供請求狀態(219&220); (5)分析承諾和閾值(221);或(6)預測資源需求(224)。所有這些選項被圖解為單獨的子過程，並且在下 面詳細討論。
圖3圖解了處理服務權限故障的子過程。這個子過程的目標是排 除所請求的服務的權限故障。由涉及處理服務權限故障的所有本地策 略來控制處理服務權限故障子過程。處理服務權限故障子過程包含下 列活動審查權限故障的細節和相關的權限策略；調查所請求的服務 的任何有資格的候選；由請求者審查所有有資格的候選；以及從請求 者處獲得對有資格的候選的接受，或使請求者從適當的各方獲得對原 始請求的批准。如果請求者未接受有資格的候選，或未獲得對原始請 求的適當批准，則容量規劃人員必須通知請求者請求已經被拒絕，並 且相關的請求記錄會關閉。
如圖3所示，處理服務權限故障子過程需要容量規劃人員確定所 請求的服務是否被服務協議或合同覆蓋(301)。如果請求未被協議覆 蓋，則容量規劃人員應當遵循本地策略建議請求者如何繼續進行請求 (308)。
如果總體服務被協議覆蓋但是具體請求未被覆蓋，則容量規劃人 員確定任何有資格的候選是否可用(302)。如果有資格的候選可用，則 容量規劃人員用請求者審查所請求的服務的所有有資格的候選(304)。 如果請求者接受有資格的候選，則容量規劃人員更新請求記錄以指示 會提供的有資格的候選解決方案的細節(318)。然而，如果請求者未接 受有資格的候選，則容量規劃人員遵循本地策略使請求者獲得對原始 請求的糸l:準(307)。
圖4圖解了分析承諾和閾值的子過程。分析承諾和閾值子過程的 目標是建立閾值並且基於服務協議識別操作的需要。如圖4所示，從處 理控制容量請求子過程調用這個子過程。當調用時，容量規劃人員首 先獲得操作趨勢數據、容量目標、性能目標、服務等級達到情況數據 以及客戶滿意度數據(401至403),操作數據是如上所述的標準數據， 其包含每個客戶使用的CPU分鐘、磁碟存儲等等。容量和性能目標包 含客戶支持目標(例如，所期望的響應時間以及其它服務等級)。目標指導閾值的開發。容量規劃人員接著審查結果(404)並且確定是否未履 行任何承諾(406)。
如果已經未履行承諾，則容量規劃人員確定在未履行承諾時是什 麼使用情況(408)。如果沒有承諾未履行，則容量規劃人員確定會導致 未履行承諾的峰值使用情況(410)。
容量規劃人員接著確定是否存在改變當前閾值的需要(412)。通 常，在未履行客戶目標的情況下或在現有閾值未提供足夠的提前通知 以解決容量問題的情況下，需要改變閾值。例如，如果CPU使用的閾 值被設置成90%，但是在實際使用達到98%之前，容量規劃人員可以 解決問題，則容量規劃人員可以確定閾值應當下移到85%以避免將來 的相同影響。
如果容量規劃人員識別出改變當前閾值的需要，則容量規劃人員 必須識別閾值的所有所需的改變(414)。如果不必改變閾值，則容量規 劃人員確定容量規劃是否需要任何改變(416)。如果需要容量規劃的改 變，則容量規劃人員調用產生/維護容量規划子過程(418)(在下面詳細 描述)。接著，過程流程返回到處理控制容量請求子過程。
圖5圖解了分析趨勢子過程。參見圖5，從處理控制容量請求子過 程調用分析趨勢子過程。分析趨勢子過程的目標是解釋數據以產生有 意義的信息以支持和開發服務提供方的容量決策。除了趨勢之外，注 意可能大大影響當前和將來的資源利用情況的獨特利用率特徵。這是 當使用模式與所計劃的模式相關時確認它們有效的迭代過程。識別偏 差並且採取操作以消除偏差。
分析趨勢子過程需要容量規劃人員分析資源單元的實際使用數 據以理解用於將來容量控制決策的趨勢方向(502)。這個步驟當資源單
元與感興趣的分組相關時確認它們的具體使用的有效性。在分析實際 使用數據之後，容量規劃人員接著從所有可用資源獲得所有歷史容量 數據(504)。
容量規劃人員接著確定是否需要特定分析(506)。響應於標準數據 可能不提供解析所需的信息的系統問題，容量規劃人員通常調用特定分析。容量規劃人員可能調用的特定分析的例子包含但不限於指定用
戶的CPU使用以及個體應用程式的存儲的增長。
如果容量規劃人員根據歷史容量數據確定需要特定分析，則容量
規劃人員向適當的數據收集小組請求所需的容量數據(508和512)。數 據收集小組(513)接著獲得所需的容量數據並且把所需的容量數據返 回給容量規劃人員。容量規劃人員接著審查容量數據的準確性(514)。
在容量規劃人員未確定需要特定分析的情況下，或在容量規劃人 員接收和審查數據收集小組提供的所需的容量數據之後，容量規劃人 員檢查可識別的使用模式的資源類型和工作負栽類型(516, 518和 520)。
如果容量規劃人員識別出任何趨勢，則容量規劃人員必須對趨勢 形成文檔(522)。如果在對趨勢形成文檔的過程期間，容量規劃人員根 據容量規劃識別出任何偏差(524)，則容量規劃人員必須在返回到處理 控制容量請求之前調用調查偏差子過程(526)。在圖7圖解了調查偏差 子過程並且在下面詳細描述。
如果未找到任何趨勢，則過程返回到處理控制容量請求子過程 (528)。
圖6圖解了參照實際情況分析規劃的子過程。參見圖6，由處理控 制容量請求子過程調用參照實際情況分析規划子過程。參照實際情況 分析規划子過程的目標是按照具體的規劃周期內的實際測量的數據分 析容量規劃，並且識別出需要進一步調查的規劃的單元。
還參見圖6，容量規劃人員通過獲得容量規劃(601)和實際數據 (602)開始分析。容量規劃人員接著確定實際數據是否完整(604)。如果 數據不完整，則容量規劃人員必須向適當的數據收集小組609請求錯失 的容量數據(608)。在從數據收集小組609接收到所請求數據時，容量 規劃人員必須審查其準確性(610)。
一旦實際數據完整，則容量規劃人員執行每個規劃項的比較 (606)。容量規劃人員分析和相關涉及性能目標、服務等級達到情況和 客戶滿意度的利用情況數據。容量規劃人員由此實際或通過計算來導出閾值，其中在具體等級上資源利用的增加直接導致未履行的服務等 級承諾。該等級接著被記錄為指定系統環境的"規劃線路"閾值。
如果實際數據遵循規劃，則容量規劃人員報告結果有效(614)，並 且過程繼續處理控制容量請求子過程(618)。
如果實際數據不遵循規劃，則容量規劃人員調用調查偏差子過程 (616)以調查容量規劃的任何偏差。在圖7圖解了調查偏差子過程並且 在下面詳細描述。在調查任何偏差之後，過程繼續處理控制容量請求 子過程(618)。
圖7圖解了調查偏差子過程。參見圖7，由各種其它子過程調用調 查偏差子過程。調查偏差子過程的目標是檢查容量規劃的未確認有效 的那些部分，說明偏差，以及在必要時啟動操作以消除偏差。
在調查偏差子過程中，容量規劃人員必須在採取操作之前確定偏 差的性質(701)。通常，如果偏差不太可能重新出現，則容量規劃人員 分類和報告偏差為異常，並且對偏差形成文檔(但是不釆取進一步操
作)(706， 708和712)。如果偏差是商業周期或季節性趨勢的結果，則對 偏差形成文檔(712)。但是，在某些情況下，偏差可能是不良數據捕獲 的結果。如果容量規劃人員確定偏差實際是不良數據捕獲的結果，則 對不良數據捕獲的細節形成文檔(702)。如果偏差的原因未知，則為根 本原因分析對偏差細節形成文檔(706)，並且容量規劃人員必須確定偏 差是否可能再次出現(708)。如果容量規劃人員確定偏差可能重新出 現，則容量規劃人員對容量規劃消除偏差所需的改變形成文檔(710)。 在對必要變化形成文檔之後，容量規劃人員調用產生/維護容量規划子 過程以更新容量規劃(714)。在圖10圖解了產生/維護容量規划子過程並 且在下面詳細描述。
圖8圖解了為報告而管理容量數據的子過程。參見圖8，由處理控 制容量請求子過程調用為報告而管理容量數據的子過程。為報告而管 理容量數據的子過程的目標是處理對新報告的需要，從請求到怎樣傳 送。
在為報告而管理容量數據子過程中，容量規劃人員首先審查所提交的報告需求(通常基於客戶或多個客戶的限制的服務等級承諾)以確
定請求的最準確報告解決方案(801)。接著，容量規劃人員確定需要什 麼數據以及誰會提供所需的數據(802)。如果需要任何新數據單元以產 生所請求的報告(804)，則容量規劃人員向適當的數據收集小組809請 求所需的附加數據單元(806)。數據收集小組809接著收集所請求數據 並且把它提供給容量規劃人員。容量規劃人員從數據收集小組809接收 所請求的容量數據，並且審查其準確性(810)。
在獲得所有必要數據之後，容量規劃人員基於所需的格式確定和 設置數據和報告格式(812)。容量規劃人員接著確定報告的頻率以及報 告的任何具體日期(814)，以及在哪裡接收輸出(816)。當報告完成時， 容量規劃人員通知請求者(818)並且請求者接收數據(819)。
圖9圖解了運行報告子過程。參見圖9，從處理控制容量請求子過 程調用運行報告子過程。容量規劃人員通過從資料庫或其它存儲介質 檢索容量報告規範(卯l)來啟動運行報告子過程。容量規劃人員接著運 行預定報告(902)並且確定報告的格式和內容是否正確(906)。如果報告 的格式和內容正確，則容量規劃人員分配報告給適當的各方(908)。在 優選實施例中，容量規劃人員使用例如eSMRT的Web式報告工具。例 如eSMRT的報告工具通常包括信息、傳送、資料庫以及表示層，其提 供帳戶管理並且支持分組，以通過操作、儀錶板和服務等級報告來觀 看其企業的狀態。同樣在優選實施例中，容量規劃人員使用例如 LOTUS NOTES的電子消息系統分配報告。如果格式或報告不正確， 則容量規劃人員進行所需的改變(904)並且在分配報告給適當的各方 之前重新運行報告(卯2)。
圖10圖解了產生/維護容量規劃。如上所述，可以通過主要過程 或若干子過程之一來調用產生/維護容量規划子過程。產生/維護容量 規劃的目標是開發、維護、測試和修訂允許服務提供方履行所有當前 和可預知服務義務的容量規劃。
產生/維護容量規劃最初調用收集數據子過程(1001)，其在圖ll中 圖解並且在下面詳細描述。收集數據子過程(1001)產生產生或維護容量規劃所需的數據。容量規劃人員接著確定是否需要附加容量數據分
析(1002)。附加容量數據分析涵蓋了非標準數據(容量規劃中通常不使 用的數據)。例如，容量規劃通常不收集或保存示出任務控制塊與所使 用的系統資源塊時間比較的數據。當把工作負載轉移到較小的CPU引 擎時需要這種數據。
如果容量規劃人員確定需要附加容量數據分析，則容量規劃人員 識別其可以用現有資源履行的需求(如果有)(1004)。為了識別這些 需求，容量規劃人員必須考慮總規劃周期，以及每個資源類型的下列 因素工作負載峰值，所計劃的負栽，工作負載相關性以及可應用的 控制。在識別可以用現有資源履行的需求之後，容量規劃人員必須識 別出附加資源的投資需要(1006)。容量規劃人員還必須把滿足容量需 求所需的任何新或改變的配置的細節形成文檔(1008)。
在一個實施例中，容量規劃人員接著調用外部操作過程以設計和 規劃滿足任何修改的容量需求的配置(1009)。這個外部操作過程的目 的僅僅是從配置立場確認任何新的或改變的配置的工作負載平衡是可 接受的。然而，這個操作過程的細節不是本發明必要的，並且不在這 裡描述。本領域的技術人員會理解，本發明在沒有這個中間步驟的情 況下仍有效行。然而，如果容量規劃人員調用這個外部操作過程，則 容量規劃人員還會確定新的配置規劃是否充分地解決所有容量問題。 如果不是，則容量規劃人員會迭代嘗試解決配置問題，並且調用外部 操作過程直到充分解決所有問題。
類似地， 一個實施例允許容量規劃人員調用另 一個外部過程以從 性能角度評估所提出的容量規劃(1015)。這個外部過程的目的是模擬 所提出的解決方案以在規劃周期內確定解決方案對部件的影響。再次 地，本領域的技術人員會理解，本發明在沒有這個中間步驟的情況下 仍有效。然而，如果使用這個外部過程並且結果指示不滿足某些性能 需求，則容量規劃人員應當對故障形成文檔並且重複如圖10所示的子 過程。
容量規劃人員接著在準備從適當各方(1022和1024)獲得承諾時對提出的容量規劃(1018)形成文檔。如果未從適當各方獲得批准，則容 量規劃人員應當把故障導致的任何問題形成文檔以獲得批准(1028)， 並且重複如圖10所示的過程。另外，容量規劃人員把同意的容量規劃 和任何支持假設形成文檔(1026)。在優選實施例中，同意的容量規劃 具有若干詳細等級。它包含示出在計劃時間段上計劃工作負載對系統 資源的影響的信息。它還包含在證明同意的容量規劃中所需的資源的 正當和對其進行澄清時所考慮的 一 系列因素。在對同意的容量規劃形 成文檔之後，容量規劃人員通知所有適當各方該規劃的細節(1030)。
圖ll圖解了收集數據子過程。如圖ll指示和註解的，由產生/維 護容量規劃調用收集數據子過程。收集數據子過程的目標是收集容量 分析所需的數據，並且保證定期收集標準數據。容量規劃人員通過確 定分析和報告需要什麼數據並且確定最優數據源(1102)來開始收集數 據子過程(1101)。
如果數據已經不可用，則容量規劃人員向數據所有者請求數據訪 問(1106)，並且提供數據的理由(1108)。如果數據可用，或如果數據所 有者提供數據訪問，則容量規劃人員從所有者處獲得數據(1110)。容 量規劃人員接著審查容量數據的準確性和完整性(1114)。如果所需的 數據不完整和不精確，則容量規劃人員聯繫數據提供方以校正錯失或 不準確的數據(1118)並且重複如圖11所示的過程。
如果容量規劃人員確定存在對數據的定期需要(1116)，則容量規 劃人員安排定期收集數據(1122)。否則，容量規劃人員在將來的類似 需求的情況下把容量數據的源形成文檔(1120)。
圖12圖解了預測資源需求子過程。如圖12指示和註解的，由處理 控制容量請求子過程調用預測資源需求子過程。預測資源需求子過程 的目標是基於將來的客戶容量需求計劃系統資源需求。
容量規劃人員通過收集可用的資源和工作負載需求開始預測資 源需求子過程(1202)。信息和數據應當足以允許容量規劃人員預測將 來的工作負載需求的量級和大小，以及在需求隨時間推移出現的周期 和時間段。如這裡使用的，術語"量級"表示基於使用的容量變化率，並且術語'，大小，，表示從當前條件到將來需要的條件的變化差。容量規
劃人員可以採取各種方案收集需求，包含通過帳戶管理者與客戶對 話，歷史趨勢，從其它過程輸入以及從變化或問題記錄輸入。客戶需 求提供了現有或新客戶的資源以及工作負載需求的聲明。這些需求可 以在年度進程期間逐步變為例程業務，或趨勢分析的結果。
在收集資源和工作負載需求之後，容量規劃人員獲得負載需求 (1204)。通過只能由附加容量解決的工作負載增加或減少來識別負載
需求o
在獲得負載需求之後，容量規劃人員獲得歷史趨勢(1206)，包含 表示用於確定趨勢目的的歷史記錄的有用時間段的資源利用情況以及 使用數據；從支持說明未來資源和工作負載需求的客戶代表處獲得的 信息和數據；從現有工作負載或具有與新工作負載需求類似的特性的 應用中顯現的使用信息；反映未來資源和工作負載的系統管理數據需 求的信息和數據；以及在初始測試期間從測試系統提取的使用信息。
如果容量規劃人員識別出新工作負載，則容量規劃人員獲得以及 審查工作負載數據(1208和1210)。在獲得以及審查工作負載數據之後， 或在未識別出新工作負栽的情況下，容量規劃人員確定是否需要冗餘 (1212)。如果容量規劃人員確定需要冗餘，則容量規劃人員獲得以及 審查冗餘數據(1214)。在優選實施例中，冗餘數據包含具有高可用性 需求並且需要冗餘備份性能的系統的數據。必須規劃備份情況以向最 關鍵的工作負載提供足夠的資源。針對備份環境的平衡資源使用進行 規劃的方式與針對常見業務環境的方式大多相同。但是， 一個差異是 使某些工作避開資源的判決過程，以便維護關鍵工作負載的性能。
容量規劃人員接著處理可用的資源和工作負載需求(1216)。本領
域的技術人員會理解，不是所有計算平臺支持詳細的工作負載信息。 本領域的技術人員還會理解，各種方案可用於處理需求以保證所接收 的需求可以成功地和正確地轉換成適當技術資源需求。處理預測需求 的關鍵考慮包含但不限於客戶資源需求的量級和客戶資源需求的定 時。如果在所期望的計算平臺上，工作負載信息可用，則容量規劃人員判定工作作負載需求是否被完全理解和定義(1220)。如果不是，則 容量規劃人員調用對工作負載表徵和確定大小的子過程(1224)以識別 和量化單位工作負載，並且確定這些工作負載使用的資源的量級。在 圖13圖解了對工作負載表徵和確定大小的子過程並且在下面詳細描 述。
如果工作負載需求被完全理解和定義，或可選地不可用，則容量 規劃人員確定是否需要附加幫助以進行計劃(1222)。如果需要附加幫 助，則容量規劃人員調用確定和應用計劃方法子過程(1226)。在圖14 圖解了確定和應用計劃方法子過程並且在下面詳細描述。如果不需要 幫助，或如果已經完成確定和應用計劃方法子過程，則容量規劃人員 對需求的時間段進行預測和大小確定(1228)。
容量規劃人員接著把計劃需求轉換成技術資源需要(1230)。容量 規劃人員還必須確認包含資源需求的量級和定時的需求有效(1232)。 在從客戶收集需求之後，由容量規劃人員審查它們以保證提供所有必 要信息(1234)。如果需要附加信息，或如果需求似乎不實際，則與客 戶代表的會議會確保更好理解客戶的未來工作負載。
一旦容量規劃人員和請求者(客戶或客戶代表)相互對需求的意見 一致，則容量規劃人員繼續開發適當容量規劃和支持假設(1236)。在 這個確認步驟內，適合於形成證明需求正當和進行澄清的一列支持假 設以及任4可相關風險。
圖13圖解了對工作負載進行表徵和確定大小的子過程。如圖13所 示，由預測資源需求子過程調用對工作負載進行表徵和確定大小的子 過程。對工作負載進行表徵和確定大小的子過程的目標是識別和量化 單位工作負載或集合工作負載，以及確定這些工作負載使用的資源的 量級。如這裡所使用的，術語"單位工作負載，，表示可以在特定時間段 執行的工作的量。
如圖13所示，對工作負載進行表徵和確定大小的子過程中的下列 步驟可以並行或按照任何隨機順序執行。為了對工作負載進行表徵和 確定大小的，容量規劃人員必須確定感興趣的適當時間段，例如輪換或業務活動的時間段(1302)。容量規劃人員還必須確定使用的量級以 及時長(1304和1306)，以及識別用於分析的數據(1308)。最後，容量規 劃人員必須確定每單位工作負載使用的資源的量(1310)並且把資源使 用與工作負載單位相關(1312)。
在完成上述步驟之後，容量規劃人員應用最可能來自客戶代表的 有關工作負載時間段、工作負載的想要使用以及用戶訪問的量級的假 設(1314)。容量規劃人員接著應用規格化因子以標準化所有測量單位 (1316)。最後，容量規劃人員使用對等審查來確認結果有效(1318和 1319)。
圖14圖解了確定和應用計劃方法的子過程。如圖14所示，由預測 資源需求子過程調用確定和應用計劃方法的子過程。確定和應用計劃 方法的目標是評估數據的適當性和來源並且選擇計劃資源需求的最適 用的方法。
第一步驟是審查已經收集的數據(1401)，並且接著評估數據的適 當性和來源(1402)。當評估數據的適當性和來源時，容量規劃人員應 當考慮提供容量規劃人員對原始數據的置信度，容量規劃人員對客戶 輸入的置信度，以及容量規劃人員關於所識別的時間段是否精確地反 映計劃的適當規劃時間段的考慮。
在評估數據的適當性和來源之後，容量規劃人員選擇應用最適當 的計劃方法(1404)。常見計劃方法包含但不限於業務驅動器，線性回 歸，線性/非線性，百分比變化，直接客戶輸入以及歷史趨勢數據。" 業務驅動器"將業務要素(例如訂單數量，查詢數量等等)與系統使用相 關起來。用於把業務要素轉換到系統使用的算法由容量規劃人員根據 涉及客戶代表提供的業務要素的信息開發。如果使用這個方法，則需 要定期地跟蹤定義為業務驅動器的要素。所開發的算法還應當被定期 地校準以確保它繼續正確地跟蹤系統使用的業務驅動器。"線性回歸" 是數據點的數學分析，其中數值的量級和出現被用於顯現回歸線。這 種方法在分析似乎非線性的歷史數據時非常有用。"線性/非線性方法" 是基於歷史數據建立預測的最直接方案。線性規劃應當在數據示出一致增加或減少時使用。非線性計劃應當在將來的使用被視作具有特定 非線性使用時使用。當在規劃中使用若干變量時通常如此。"百分比 變化"是使用具體百分比描述許多不同時間點的增加或減少規劃的計
劃方法(例如在lQ中增加-20/。，在4Q中增加5。/o等等)。直接客戶輸入表 示當客戶直接向容量規劃人員提供實際預測時的實例。直接客戶輸入 只在客戶已經證明預測精確地跟蹤其使用時使用。當分析要加入到現 有工作負載中的需求時，相關工作負載的歷史數據也應當在預測中考 慮到。在歷史數據中找到的任何趨勢應當應用於新工作負載。例子是 增加或減少活動，季節性趨勢或商業周期。
最後，在選擇適當計劃方法實現之後，容量規劃人員使用所選擇 的方法並且產生預測計劃和假設(1406和1408)。
本發明可以在硬體、軟體或硬體和軟體的組合中實現。本發明的 方法和系統的實現可以以集中在一個計算機系統中的方式實現，或以 不同單元散布在若干互連的計算機系統中的分布方式實現。任何種類 的計算機系統，或適於執行這裡描述的方法的其它設備適於執行這裡 描述的功能。
硬體和軟體的典型組合可以是具有電腦程式的通用計算機系 統，當加載和執行時，其控制計算機系統使得它執行這裡描述的方法。 本發明也可以嵌入電腦程式產品，其包括實現這裡描述的方法的所 有特徵，並且當在計算機系統中加載時，其能夠執行這些方法。
本領域的技術人員將理解，這種計算機可讀指令可以使用河於許 多計算機體系結構或作業系統的多種程式語言編寫。此外，這種指令 可以使用當前或將來包含但不局限於半導體、磁或光學的任何存儲器 技術存儲，或使用當前或未來包含但不局限於光學、紅外或微波的任 何通信技術發送。考慮這種電腦程式產品可以作為伴隨列印而出現 的可移動介質或電子文檔來發布，例如預先加載在計算機系統的例如 系統ROM或硬碟上的打包軟體，或在例如網際網路或全球資訊網的網絡上從 伺服器或電子公告發布。
顯然，本發明可以在不偏離其宗旨或必要性質的前提下以其它具體形式實現，並且因此，應當參考指示本發明的範圍的以下權利要求 書，而不是參考上述說明書。
權利要求
1. 一種管理共享計算環境中的容量資源的方法，包括步驟產生和維護容量規劃；處理來自請求者的容量請求；對容量請求執行分析審查以識別容量問題；以及執行數據處理系統中的問題管理器程序以解決任何所識別的容量問題，使得服務提供方能夠滿足所有服務義務。
2. 如權利要求1所述的方法，其中產生和維護容量規劃包括步驟 收集容量數據；通過從資料庫提取容量義務，並且比較容量義務和現有資源以識 別能夠用現有資源滿足的容量義務，以及識別需要附加資源的容量義 務，對容量數據進行分析；產生使用所識別的現有資源和所識別的附加資源來滿足容量義 務的容量規劃；從有權確認容量規劃的實現的 一或多個人處獲得容量規劃的批 準；以及把規劃細節通知給容量規劃涉及的任何方。
3. 如權利要求2所述的方法，其中收集容量數據包括步驟 確定容量數據需求；確定容量數據的提供方； 確定容量數據是否已經可用； 從資料庫獲得容量數據； 確認容量數據有效；確定是否存在對該數據的定期需要；以及 更新資料庫和對資料庫形成文檔。
4. 如權利要求2所述的方法，還包括步驟 響應於確定容量數據不是已經可用的，聯繫容量數據的所有者； 請求容量數據；以及向容量數據所有者證明對容量數據的請求正當。
5. 如權利要求2所述的方法，還包括步驟 在獲得容量規劃的批准之前，設計支持容量規劃的配置；以及 測試所設計的配置以確定該配置是否能夠根據需要平衡工作負載以滿足現有和預期的容量義務。
6. 如權利要求2所述的方法，還包括步驟在獲得容量規劃的批准之前，通過在規劃周期期間確定容量規劃 對部件的影響來分析容量規劃的性能影響。
7. 如權利要求1所述的方法，其中處理容量請求包括步驟 使用問題管理程序分析容量請求； 從資料庫提取請求者的權限和標準數據；確定請求者是否有權使容量請求得到滿足；響應於確定請求者有權使容量請求得到滿足，確定是否需要任何 非標準數據以滿足容量請求；響應於確定需要非標準數據以滿足容量請求，向收集小組提交非 標準數據的請求，從收集小組接收非標準數據，並且審查從收集小組 接收的非標準數據；參照實際使用數據分析容量規劃；以及更新容量規劃以反映容量請求的結果。
8. 如權利要求7所述的方法，其中參照實際使用數據分析容量規 劃包括步驟從資料庫獲得規劃數據； 從資料庫獲得實際使用數據； 比較規劃數據和實際使用數據；從比較結果確定實際使用數據是否偏離規劃數據；以及 響應於確定實際使用數據偏離規劃數據，調查偏差。
9. 如權利要求8所述的方法，其中調查偏差包括步驟 確定偏差是否是異常的結果；以及 響應於確定偏差是異常的結果，對偏差形成文檔。
10. 如權利要求8所述的方法，其中調查偏差包括步驟 確定偏差是否是商業周期的結果；以及 響應於確定偏差是商業周期的結果，對偏差形成文檔。
11. 如權利要求8所述的方法，其中調查偏差包括步驟 確定偏差是否是不良數據捕獲的結果；以及 響應於確定偏差是不良數據捕獲的結果，使用問題管理程序對不良數據捕獲細節形成文檔，以及使用問題管理程序對偏差形成文檔。
12. 如權利要求8所述的方法，其中調查偏差包括步驟 確定偏差是否是未知原因的結果；以及響應於確定偏差是未知原因的結果，使用問題管理程序對偏差形 成文檔，確定偏差是否可能重新出現，並且響應於確定偏差可能重新 出現，對所需要的容量規劃變化形成文檔。
13. 如權利要求1所述的方法，其中處理容量請求包括步驟 使用問題管理程序分析容量請求； 從資料庫提取請求者的權限和標準數據；確定請求者是否有權使容量請求得到滿足；響應於確定請求者有權使容量請求得到滿足，確定是否需要任何 非標準數據以滿足容量請求；響應於確定需要非標準數據以滿足容量請求，向收集小組提交非 標準數據的請求，從收集小組接收非標準數據，並且審查從收集小組 接收的非標準教據；為報告而管理容量數據；確定是否需要新或變化的報告；響應於確定需要新或變化的報告，運行報告；以及更新容量規劃以反映容量請求的結果。
14. 如權利要求13所述的方法，其中為報告而管理容量數據包括步驟確定產生報告所需的數據； 確定是否需要附加數據單元以產生報告；響應於確定需要附加數據單元以產生報告，向數據收集小組請求 附加數據單元，並且響應於從數據收集小組接收附加數據單元，確認附加數據單元有效； 確定報告格式； 確定報告的頻率和日期； 確定報告的目的地；以及 當可從資料庫檢索到報告時，通知報告接收方。
15. 如權利要求13所述的方法，其中運行報告包括步驟 從資料庫提取報告規範；使用報告程序創建預定報告； 確定報告格式或報告內容是否需要校正； 響應於確定報告需要校正，對報告進行所需的改變；以及 向一或多個報告接收方分配報告。
16. 如權利要求1所述的方法，其中處理容量請求包括步驟 使用問題管理程序分析容量請求； 從資料庫提取請求者的權限和標準數據；確定請求者是否有權使容量請求得到滿足；響應於確定請求者有權使容量請求得到滿足，確定是否需要任何 非標準數據以滿足容量請求；響應於確定需要非標準數據以滿足容量請求，向收集小組提交非 標準數據的請求，從收集小組接收非標準數據，並且審查從收集小組 接收的非標準數據；分析趨勢；以及更新容量規劃以反映容量請求的結果。
17. 如權利要求16所述的方法，其中分析趨勢包括步驟 識別相關趨勢；從資料庫獲得歷史容量數據； 確定是否需要特定分析；響應於確定需要特定分析，確定附加容量數據是否可用，響應於確定附加容量數據不可用，向收集小組請求附加容量數據； 獲得附加容量數據；選擇資源類型和工作負載類型以識別趨勢； 響應於識別出趨勢，在資料庫中對趨勢形成文檔； 確定任何識別的趨勢是否偏離容量規劃；以及 響應於確定一或多個識別的趨勢偏離容量規劃，調查偏差。
18. 如權利要求17所述的方法，其中調查偏差包括步驟 確定偏差是否是異常的結果；以及 響應於確定偏差是異常的結果，對偏差形成文檔。
19. 如權利要求17所述的方法，其中調查偏差包括步驟 確定偏差是否是商業周期的結果；以及 響應於確定偏差是商業周期的結果，對偏差形成文檔。
20. 如權利要求17所述的方法，其中調查偏差包括步驟 確定偏差是否是不良數據捕獲的結果；以及 響應於確定偏差是不良數據捕獲的結果，使用問題管理程序對不良數據捕獲細節形成文檔，以及使用問題管理程序對偏差形成文檔。
21. 如權利要求17所述的方法，其中調查偏差包括步驟 確定偏差是否是未知原因的結果；以及響應於確定偏差是未知原因的結果，使用問題管理程序對偏差形 成文檔，確定偏差是否可能重新出現，並且響應於確定偏差可能重新 出現，對所需要的容量規劃變化形成文檔。
22. 如權利要求1所述的方法，其中處理容量請求包括步驟 使用問題管理程序分析容量請求； 從資料庫提取請求者的權限和標準數據； 確定請求者是否有權使容量請求得到滿足； 響應於確定請求者有權使容量請求得到滿足，確定是否需要任何非標準數據以滿足容量請求；響應於確定需要非標準數據以滿足容量請求，向收集小組提交非 標準數據的請求，從收集小組接收非標準數據，並且審查從收集小組接收的非標準數據； 分析承諾和閾值； 確定是否需要閾值變化；響應於確定需要閾值變化，使用問題管理器程序確定新閾值；以及更新容量規劃以反映容量請求的結果。
23. 如權利要求22所述的方法，其中分析確認和閾值包括步驟 從資料庫獲得操作趨勢數據； 從資料庫獲得容量和性能目標； 從資料庫獲得服務等級達到情況和客戶滿足度數據； 確定是否已經未履行任何服務承諾；響應於確定已經未履行一或多個服務承諾，確定未履行服務承諾 時的資源使用；參照當前服務承諾審查閾值； 確定是否需要閾值變化；響應於確定需要閾值變化，對所需閾值變化形成文檔； 確定是否需要容量規劃變化；以及響應於確定需要容量規劃變化，更新容量規劃以反映所需的變化。
24. 如權利要求1所迷的方法，其中處理容量請求包括步驟 使用問題管理程序分析容量請求； 從資料庫提取請求者的權限和標準數據； 確定請求者是否有權使容量請求得到滿足；響應於確定請求者有權使容量請求得到滿足，確定是否需要任何 非標準數據以滿足請求；響應於確定需要非標準數據以滿足容量請求，向收集小組提交非 標準數據的請求，從收集小組接收非標準數據，並且審查從收集小組 接收的非標準數據；預測資源需求；以及更新容量規劃以反映容量請求的結果。
25. 如權利要求24所述的方法，其中預測資源需求包括步驟 收集資源和工作負載需求； 從資料庫獲得負載需求；從資料庫獲得歷史趨勢；對工作負載需求進行表徵和確定大小；確定和應用計劃方法；對工作負載需求的周期進行預測和確定大小； 把工作負載需求轉換為技術資源需要；以及 更新容量規劃以反映技術資源需要。
26. 如權利要求25所述的方法，其中對工作負載需求進行表徵和確 定大小包括步驟識別工作負載的單位； 確定感興趣的周期； 確定使用的量； 確定使用的時長；針對感興趣的周期從資料庫提取資源使用數據； 確定每單位工作負載使用的資源； 把該單位的工作負載與資源使用數據相關； 應用假i殳；應用和正規化因子；以及 使用對等審查確認結果有效。
27. 如權利要求25所述的方法，其中確定和應用計劃方法包括步遞.審查可用工作負載數據； 評估工作負載數據的適當性和來源； 選擇最適當的計劃方法； 應用所選擇的計劃方法； 產生預測計劃和假i殳；以及把預測計劃和假設存儲在資料庫中。
28. 如權利要求1所述的方法，其中處理容量請求包括步驟 使用問題管理程序分析容量請求； 從資料庫提取請求者的權限和標準數據； 確定請求者是否有權使容量請求得到滿足； 響應於確定請求者無權使容量請求得到滿足，對權限故障細節形成文檔；處理服務權限故障；以及 通知請求者請求不會被滿足。
29. 如權利要求28所述的方法，其中處理服務權限故障包括步驟 確定合同是否覆蓋容量請求；以及響應於確定合同未覆蓋容量請求，通知請求者容量請求將被取消。
30. 如權利要求28所述的方法，其中處理服務權限故障包括步驟 確定合同是否覆蓋容量請求；響應於確定合同覆蓋容量請求，確定請求者是否有權進行任何可 用選擇；響應於確定請求者有權進行一或多個可用選擇，由請求者對可用 選擇進行審查以獲得對至少一個可用選擇的接受；以及響應於確定獲得對至少一個可用選擇的接受，更新容量規劃以反 映容量請求的結果。
31. 如權利要求28所述的方法，其中處理服務權限故障包括步驟確定合同是否覆蓋容量請求；響應於確定合同覆蓋容量請求，確定請求者是否有權進行任何可 用選擇；響應於確定請求者無權進行任何可用選擇，獲得對原始請求的批 準；以及更新容量規劃以反映容量請求的結果。
32. 如權利要求1所述的方法，其通過電腦程式產品來體現。
33. —種管理共享計算環境中的容量資源的系統，包括 服務提供方；多個服務義務； 多個容量資源；以及容量規劃者，其產生和維護容量規劃，其中容量規劃主要識別當 前和所需容量資源，並且主要描述當前以及所需容量資源的分配，以 及執行容量規劃，使得服務提供方滿足所有服務義務。
34. 如權利要求32所述的系統，其中容量規劃者還處理容量請求。
35. 如權利要求33所述的系統，其中容量規劃者還審查容量請求以 識別在未來容量規劃中應當解決的容量問題。
36. —種管理共享計算環境中的容量資源的系統，包括 服務提供方；多個服務義務；多個容量資源；產生和維護容量規劃的裝置；處理容量請求的裝置；以及審查容量請求以識別容量問題的裝置。
全文摘要
公開了用於管理信息技術資源以向在共享計算環境中具有不同需求的多個客戶提供處理容量的系統和方法。發明的過程包括產生和維護分配容量資源的容量規劃，處理附加容量資源的請求，並且分析附加容量資源的請求以識別出應當在未來的分配中解決的問題。
文檔編號H04L12/24GK101421953SQ200580011230
公開日2009年4月29日 申請日期2005年4月12日 優先權日2004年4月15日
發明者H.·威廉·林克爾, 克裡·安尼·左羅陶, 蘭迪·斯科特·約漢森, 泰德裡克·尼爾·諾斯維, 艾麗斯·艾德華·比肖普, 馬修·D.·肖 申請人:國際商業機器公司