在缺乏合適的工具的前提下，實施IT服務(wù)優(yōu)化將會是相當(dāng)棘手的。

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

[[216735]]

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

在本文中，我們將與廣大讀者朋友們共同討論如何在復(fù)雜的虛擬環(huán)境中優(yōu)化IT服務(wù)。

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

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

2、動態(tài)資源調(diào)度：虛擬機管理程序具備根據(jù)當(dāng)前需求自動分配資源，并將資源引導(dǎo)到相應(yīng)虛擬機的能力。

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

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

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

挑戰(zhàn)難題

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

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

容量管理的一個重要方面是對每項工作負(fù)載或應(yīng)用程序進(jìn)行恰當(dāng)?shù)拿枋?，在分析一項工作?fù)載時，有些方面非常重要：

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

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

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

工作負(fù)載的穩(wěn)定性——工作負(fù)載是否始終維持相同的活動水平，還是會偶爾爆發(fā)更多的活動?

周期性與隨機性——這些活動高峰是可預(yù)測的還是隨機發(fā)生的?

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

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

塊越大，對稱越少，將它們整合起來就越困難。無法將塊組合轉(zhuǎn)換為資源不足的工作負(fù)載，但無法遷移到其他主機。突然之間，在虛擬化環(huán)境中實現(xiàn)靈活性的兩大關(guān)鍵機制變得無法使用。即使您企業(yè)能夠?qū)⑺鼈兘Y(jié)合起來，大的不對稱塊也很可能導(dǎo)致白色空間碎片化和資源利用率低于您企業(yè)原先計算和計劃的。

基于動態(tài)資源調(diào)度和無縫工作負(fù)載遷移的虛擬化環(huán)境的服務(wù)優(yōu)化策略僅僅假定完全的移動性和工作負(fù)載的自由混合。但在許多情況下，事實證明這太簡單了。除了具有不同的“工作負(fù)載人員”之外，由技術(shù)或商業(yè)環(huán)境所施加的其他一些限制也會產(chǎn)生影響(專門或?qū)Ｓ械挠布渲谩⒑贤x務(wù)，有關(guān)數(shù)據(jù)分段的安全策略，變更管理程序等)。

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

有哪些選擇?

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

評估

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

哪些指標(biāo)與評估有關(guān)?

這些指標(biāo)的正確閾值是多少?

企業(yè)如何使不同年代或不同指標(biāo)的平臺標(biāo)準(zhǔn)化?

當(dāng)工作負(fù)載堆疊時，如何解釋非線性的性能變化?

如果您企業(yè)對于上述任何信息的理解錯誤，都會導(dǎo)致做出不正確的預(yù)測。

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

分析建模

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

在描述系統(tǒng)的模型中表示了對服務(wù)器性能十分重要的所有對象。

一旦建立了模型，就可以通過改變交易密度或在不同模型之間遷移工作負(fù)載來評估不同的場景。預(yù)測的交易的響應(yīng)時間或吞吐量將告訴企業(yè)方案是否成功?？梢园阎攸c放在花費在排隊上的時間和花費在系統(tǒng)上的時間之間的相對差異來消除對于每種交易類型明確的閾值的需要。這種關(guān)系的一個簡單的經(jīng)驗法則會為企業(yè)提供一個關(guān)于配置場景狀態(tài)的好主意。

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

綜合負(fù)載測試

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

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

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

結(jié)論

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

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

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

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

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

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

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