在缺乏合適的工具的前提下，實施IT服務優化將會是相當棘手的。

商品化服務器的服務器虛擬化一直是最為被企業組織所迅速采用的技術之一。現如今，傳統且低效的“一臺物理服務器搭配一種應用程序”的模式正在迅速的讓位于虛擬服務器之間共享資源池。這不僅可以幫助企業組織節省數據中心的電源、冷卻和占地空間等資源，還可以幫助企業通過避免對某些物理服務器實施過度配置來節省資金。虛擬化技術提供了一種更為靈活的解決方案，使得企業可以根據不斷變化的實際需求來重新分配資源。

[[216735]]

服務器虛擬化的概念固然有諸多顯著的優勢。但是，與生活中的許多事物一樣，其不僅僅只有一面。資源的虛擬化為基礎架構堆棧添加了一個新的抽象層。這一層應該使虛擬化解決方案變得更加靈活和高效，但同時也使得IT服務優化變得更為復雜。對于要求苛刻且性能至關重要的應用程序而言，這可能會導致服務等級協議的中斷和違規。在實施或更新虛擬化策略時，記住這一點非常重要。

在本文中，我們將與廣大讀者朋友們共同討論如何在復雜的虛擬環境中優化IT服務。

在討論服務器虛擬化對容量管理和IT服務優化方面所帶來的挑戰時，我們需要對構成靈活虛擬化環境的機制有一個共同的理解。從概念上講，其使用的是三種機制：

1、資源虛擬化：將分組資源集中到池中，由一款虛擬管理程序分配給不同的虛擬機。

2、動態資源調度：虛擬機管理程序具備根據當前需求自動分配資源，并將資源引導到相應虛擬機的能力。

3、無縫遷移：具備跨不同物理服務器進行資源調度的能力，使服務器集群或服務器場成為一個大型資源池。

通過使用這些機制，可以幫助企業解決計算環境中的一些傳統的容量管理的難題。在“一款應用程序搭配一臺物理服務器”的商品化平臺時代，企業通常不得不為高峰時期的應用程序需求進行配置。而如果一般正常的需求水平比高峰期低得多，則大部分資源在大部分時間都沒有使用。更糟的是，根據事件的周期性，高峰可能是數周或數月才有一次。在虛擬化環境中，可以在多個不同的虛擬機之間以及在多臺物理主機之間共享需要用于峰值使用的額外動態空間，這一切對虛擬機中運行的應用程序都是完全透明的。結合旨在優化峰值時間需求的管理活動，動態的資源調度可以特別有效地防止過度配置。

但是，服務器虛擬化和動態資源是否能夠徹底消除對容量管理的需求呢?顯然不是，如下我們將做詳細討論。

挑戰難題

一個典型的服務器虛擬化項目首先挑選從易于上手的地方開始，先易后難。從持續活動水平較低的商品化應用程序遷移到虛擬環境中開始著手。由于這些商品化工作負載通常運行在較老的基礎設施上，性能較差，而且由于大多數資源對資源的要求可能不是特別高，所以在性能和服務質量方面有了初步的提升。這肯定了將工作負載遷移到虛擬服務器的決定，重點在于減少了物理主機的數量。

最終，當所有的較為容易的工作都已經被完成后，繼續這個過程并且涉及更復雜的工作負載便是很自然的了。盡管服務器虛擬化從長遠來看應該是為了節省資金，但實施虛擬化戰略通常需要在新的基礎架構上進行一些初步的前期投資。在許多情況下，企業IT部門所面臨的情況是，為了實現合理和及時的投資回報，這些前期投資需要在大量的應用程序和服務之間共享。這將導致更多的工作負載，如電子郵件、數據庫和ERP系統。他們在資源消耗方面要求更高，而且關鍵性要求也更高。這種應用程序的可用性和吞吐量都非常重要。他們可能會支持企業的核心流程，或直接面對客戶。這意味著您企業需要特別小心如何操作和管理這些服務。確保您企業現在和可預見的將來有足夠的容量能力。

容量管理的一個重要方面是對每項工作負載或應用程序進行恰當的描述，在分析一項工作負載時，有些方面非常重要：

資源的利用——該工作負載將使用什么資源，以及對資源的使用程度如何?

在線還是批量——該工作負載是否是在線情況下使用(在這種情況下，單個交易的響應時間便至關重要);抑或還是批量情況下使用(在這種情況下，總吞吐量則更為重要)

線性分布與指數分布——在暴露于強度增加的情況下，工作負載的性能如何?

工作負載的穩定性——工作負載是否始終維持相同的活動水平，還是會偶爾爆發更多的活動?

周期性與隨機性——這些活動高峰是可預測的還是隨機發生的?

綜合所有這些信息的配置文件將為您企業提供關于如何管理特定工作負載以及資源需求的好主意，幫助您了解工作負載的特點。 當您開始在同一個物理資源上混合使用多個工作負載(這可能是您企業首先實施虛擬化的原因之一)，事情會變得更復雜一些。 如前所述，動態資源調度通常被用作解決容量需求變化的單一機制，無論是在一臺物理主機內還是跨多臺主機。但資源調度的效率和實用性在很大程度上取決于工作負載的特點。對于資源需求適中的一組工作負載通常很容易在不同主機之間進行平衡和遷移。但是，如果您開始將它們與更苛刻的工作負載混合在一起，那么您企業的選擇會突然受到嚴格限制。

我曾經在倫敦舉行的Gartner數據中心峰會上提出的一個類比似乎越來越受到人們的青睞，該類比說明了在嘗試混合和匹配各種工作負載時可能出現的問題。在該峰會的演講上，我建議使用類似俄羅斯方塊的Block(塊)來象征不同工作負載之間的不規則性。對資源需求適度的簡單工作負載將由基本的兩件式塊來表示。更高的資源需求和更高的復雜性將導致該區塊向各個方向擴張。

塊越大，對稱越少，將它們整合起來就越困難。無法將塊組合轉換為資源不足的工作負載，但無法遷移到其他主機。突然之間，在虛擬化環境中實現靈活性的兩大關鍵機制變得無法使用。即使您企業能夠將它們結合起來，大的不對稱塊也很可能導致白色空間碎片化和資源利用率低于您企業原先計算和計劃的。

基于動態資源調度和無縫工作負載遷移的虛擬化環境的服務優化策略僅僅假定完全的移動性和工作負載的自由混合。但在許多情況下，事實證明這太簡單了。除了具有不同的“工作負載人員”之外，由技術或商業環境所施加的其他一些限制也會產生影響(專門或專有的硬件配置、合同義務，有關數據分段的安全策略，變更管理程序等)。

總而言之，這表明需要更徹底的方法來實施企業級的虛擬化策略。為了讓更多的要求和重要的工作負載虛擬化，單單依靠被動資源調度和工作負載的遷移機制是不夠的。為確保服務得到***交付，需要在部署工作負載的布局和遷移策略之前進行調查和分析。

有哪些選擇?

預測一項工作負載的容量需求的不同方法及其與其他工作負載共存的方法大致可以分為三類。

評估

這一類的方法嚴重依賴于“常識”和以往的經驗。服務器虛擬化和整合方案的選擇方法通常是將工作負載堆棧在一起，直到達到預定的閾值。但為了在這方面取得成功，您企業需要充分理解如下方面：

哪些指標與評估有關?

這些指標的正確閾值是多少?

企業如何使不同年代或不同指標的平臺標準化?

當工作負載堆疊時，如何解釋非線性的性能變化?

如果您企業對于上述任何信息的理解錯誤，都會導致做出不正確的預測。

評估和質量預測是基于觀點和直覺，而不是硬性的事實。這類的工具集中在使程序更簡單。在一天的工作結束時，對于質量的預測仍然取決于上述問題的答案。在大多數情況下，非線性增長等一些方面甚至沒有得到解決。

分析建模

另一種預測工作負載混合的執行情況的方法是通過使用分析隊列網絡求解器。系統的隊列網絡(Queueing Network)模型便于分析模型求解器可以在數學上計算出排隊延遲將在何處發生以及發生了多少排隊延遲。在模型用于預測目的之前，其是根據服務器如何在實際中使用的經驗研究來校準的。

在描述系統的模型中表示了對服務器性能十分重要的所有對象。

一旦建立了模型，就可以通過改變交易密度或在不同模型之間遷移工作負載來評估不同的場景。預測的交易的響應時間或吞吐量將告訴企業方案是否成功。可以把重點放在花費在排隊上的時間和花費在系統上的時間之間的相對差異來消除對于每種交易類型明確的閾值的需要。這種關系的一個簡單的經驗法則會為企業提供一個關于配置場景狀態的好主意。

這種類型的分析建模為優化混合工作負載環境提供了一個具有預測性，快速和可重復的過程。通過分析建模，結果的質量對執行它的個體的依賴性較小。同時也避免了假定性能隨著工作負載堆棧而線性降級的常見錯誤。

綜合負載測試

這里的目標是產生盡可能接近現實場景的綜合交易。為了使事情正確，您企業需要仔細檢查操作環境，以找到正確的事務組合和并發性，根據這些事務開發可重復的測試用例，并對與生產環境相同的設備執行冗長的性能測試(這可能會迫使您企業在并行測試環境中進行投資)。另外，您企業需要根據每種交易類型的響應時間來定義成功標準。

如果執行正確，負載測試能夠提供高度的準確性。但是在大多數情況下，其成本和較長的測試周期是不合理的。在重要的服務上線之前，可能更適合“一生一次”的質量保證活動，而不是重復的IT服務優化練習。

那么您企業究竟應該選擇哪種方法呢?最重要的是至少有一套切實可行的戰略，而不僅僅只是依靠框架的反應機制來進行容量能力管理。在建立之后，***選擇通常是采用不同方法的混合。您企業可能不想花太多時間來分析較不重要的實用程序應用程序，就像您企業無法承擔快速簡單分析關鍵業務服務的風險一樣。有一個全面的工具箱，讓您選擇正確的方法以適合不同的情況是非常重要的。

結論

商品化服務器虛擬化供應商們希望您相信，他們的平臺中內置的反應式性能管理技術是您企業獲得***性能所需的全部。事實上，諸如動態資源調度和遷移等被動技術是有幫助的，但它們并不是一套完整的解決方案，并不一定能夠使IT服務優化變得更加容易。從虛擬化環境中增加的復雜性實際上會使得確保從系統中獲得所有的東西變得更加困難。

一個“足夠大”的虛擬資源池不是輕而易舉就能實現的。如果您企業不注意您所托管的工作負載的特征，那么您可能會過度配置應用程序或使應用程序資源不足。

為了確保工作負載能夠相互高效地運行(或者類似俄羅斯方塊的形狀將能夠彼此貼合)需要進行一些認真的分析。您企業需要了解很多有關底層應用程序的資源需求，才能知道一款工作負載是否會干擾另一款工作負載，進而造成不必要的資源爭用和排隊延遲。因此，特別是對于關鍵工作負載而言，進行一些仔細的前期分析是合理的，而不是簡單地將各種工作負載扔到您企業的系統上，然后寄希望于動態資源調度和遷移能夠快速高效地將所有事情整合在一起。

正如我們前面提到的，通過前期規劃“評估”實現的優化工作負載布置通常需要將工作負載堆棧在一起，直到達到預定的閾值。這是大多數可用于調查數據中心和識別虛擬化可能性的工具所使用的技術。其結果是便宜且容易獲得的，但僅僅只是粗略的估計。該估計本身并不會幫助您企業達到***性能。

“分析建模”并不像預測那樣快速、簡單、成本便宜，但是卻非常接近我們的目的。(通過“分析建模”，我們特別指的是使用分析排隊網絡求解器進行建模，不太復雜的分析數學模型可能更好地被認為是“估計”工具。)建立分析建模比負載測試(或模擬建模)更簡單，而且比估計更準確。

如果綜合負載和底層系統配置是生產環境的代表的話，那么“負載測試”可以非常準確。然而，需要花費更多的時間和費用以便更接近于達到匹配生產負載和基礎設施。在大多數情況下，使用這種技術來優化虛擬化環境中的IT服務是不現實的。然而，如果運行較小的測試，然后使用分析建模來預測在更令人印象深刻的系統配置中更大的負載可能發生的情況，則可能是一個有用的折衷方案。

總之，依靠IT服務優化的被動資源調度和工作負載遷移機制是不夠的。在商品化的服務器虛擬化環境中運行要求苛刻的應用程序時，您企業需要做的工作更多。最明智的解決方案是提前計劃，確保布置和遷移策略的設計能夠保證工作負載能夠高效地一起運行。估算工具對于簡單工作負載的臨時湊合分析是很好的。負載測試可能是非常有價值的，特別是當您企業推出全新的應用程序工作負載時，但是，用于優化在虛擬化環境中運行的關鍵應用程序的***全面技術則是使用排隊網絡解析器的分析建模。