云計算和容器如何重寫監(jiān)視和管理規(guī)則手冊

西部數(shù)碼
西部數(shù)碼
在獲得數(shù)據中心轉型的一些成功之后,很多過于心急的企業(yè)在實施中希望盡可能多地消除IT數(shù)據中心成本。這可能會需要采用多種云服務、實驗融合基礎架構和軟件堆棧,以及采用DevOps友好型技術,例如容器化。這些技術都可...

在獲得數(shù)據中心轉型的一些成功之后,很多過于心急的企業(yè)在實施中希望盡可能多地消除IT數(shù)據中心成本。這可能會需要采用多種云服務、實驗融合基礎架構和軟件堆棧,以及采用DevOps友好型技術,例如容器化。這些技術都可以幫助減少日益繁瑣的資本支出,并提高敏捷性。

盡管如此,在這種數(shù)據中心整合的過程中,人們可能會忽略一些重要的事情。云計算和容器的應用規(guī)模非常巨大,并且具有更加廣闊的前途,但通常他們根本沒有通過完整的企業(yè)管理和經過考驗的安全性,或者正如專家所述,其不能保證服務水平。

融合、云計算和容器都是熱門技術。它們提供的價值是增加工作負載和基礎設施之間的抽象。對于新的分布式的、面向DevOps的世界而言,有更多的抽象是有用的,但它也往往會掩蓋對提高IT性能的最終可見性。

有很多方法可以衡量性能,而將工作負載響應時間作為衡量最終用戶對IT體驗的滿意程度的重要指標之一。想象一下,圖表中的CPU利用率在X軸上從0%線性增加到100%。如果在Y軸上繪制該CPU的平均交互式交易性能,最終會得到一個指數(shù)曲線,從合理的服務時間的0%開始,但是在100%的利用率下,將向無窮大發(fā)展。(注意:對于數(shù)學上的思考,可以使用排隊理論對響應時間曲線進行建模,以計算日益繁忙的資源的概率等待時間。)

通過增加負載來盡可能提高基礎設施資源的利用率,最終會在IT績效管理方面產生相反的效果。

確實,批量工作負載更多地是通過吞吐量來衡量的,吞吐量可以達到最大利用率。但是,響應時間對任何交互式工作負載都至關重要。在當今的快速數(shù)據世界中,通過交互式操作和應用程序近乎實時地處理更多的數(shù)據源和數(shù)據流。如今的大數(shù)據是盡可能收集數(shù)據帶來盡可能多的信息。

云計算和容器各自以不同的方式改變IT性能管理,雖然變化可能很顯著,但IT管理人員可以通過多種方式確保性能保持在可接受的范圍內。

云計算應用程序設計人員傾向于將關鍵代碼的某些部分視為可替代的實例,而不像他們過去在傳統(tǒng)數(shù)據中心基礎設施孤島中的歷史實例。用戶需要仔細監(jiān)控和管理任務關鍵型應用程序及其資源,任何偏離正常的情況都會立即進行分類。對于當今的許多云計算應用程序,性能偏差將導致應用程序重新配置更好的新的云計算實例。

要理解這一點,需要了解虛擬化,它帶來了許多好處,但并不總是更好的性能。在虛擬化主機中,保證實際響應時間性能一直是一個問題。

雖然虛擬管理員可以將主機資源配額(就利用率而言)分配給給定虛擬機,但是根據定義,每個主機資源可以同時由多個虛擬機共享。一旦了解響應時間性能相對于系統(tǒng)總利用率是非線性的,就可以立即看到如何在頻繁使用的虛擬服務器上出現(xiàn)嘈雜鄰居問題,即使關鍵虛擬機具有有保證的利用率。

例如,考慮給定主機服務器上的所有虛擬機如何具有有保證的容量片段。如果足夠的虛擬機同時使用其容量來將服務器的總利用率提高到50%-60%以上,則響應時間將因所有這些而降低。在一定的利用率閾值遠低于100%的情況下,底層服務器資源仍然具有剩余容量,但經驗豐富的性能可能會降低一半。隨著利用率接近100%,響應性可能降低到甚至很少有實際工作通過系統(tǒng)的程度。

如果人們將云計算(公共云或私有云)視為大型虛擬服務器場,就可以看到為什么云計算機器實例可能無法始終提供應得的性能。當用戶支付費用采用云計算服務器時,云計算服務提供商承諾提供一定的資源利用率。但是,云計算提供商通常不會證明用戶的特定計算機實例不會與許多其他競爭實例共存。這意味著在繁忙時段,許多托管計算機實例將無法提供與其底層云計算基礎設施不到一半空閑時相同的性能級別。

從根本上說,云計算是經濟高效的,因為它們盡可能廣泛地共享基礎設施。用戶在經濟上鼓勵云計算服務提供商,將盡可能多的虛擬實例填充到給定的云計算基礎設施的足跡中。實際上,云計算提供商的利潤率的關鍵領域之一是能夠在多個租戶中盡可能多地超額預訂真實的基礎設施,許多機器實例在很多時候都沒有得到充分利用。

因此,Web應用程序管理員和明智的DevOps管理人員謹慎地對待他們的云計算應用程序。他們跨多個機器實例以分布式方式構建其Web應用程序,這樣如果該池中的任何一個機器實例的性能受到影響,那么它們只會將其終止,并重新啟動它。當企業(yè)的服務提供商規(guī)模足夠大時,重啟操作幾乎可以保證新實例將在云計算基礎架構的不同區(qū)域生成,遠離嘈雜的鄰居。值得注意的是,這種方法在應用不太廣泛的私有云上可能效果不佳。

容器的可見度

對于容器化來說,微服務大量應用的性能可能更不透明。原始定義的單個微服務即使其性能很糟糕,但不會持續(xù)很長時間。對于大規(guī)模容器化的應用程序來說,可能只看到總體最終結果的性能不佳。而且由于微服務可能是短暫的,無法更好地進行管理。

當將微服務分配到他們自己的隔離基礎設施時,端到端基礎設施性能管理工具使IT管理員能夠識別并糾正明顯的性能問題。雖然虛擬化開始使IT性能管理變得混亂,但仍然存在將應用程序性能與虛擬化基礎設施相關聯(lián)的有效方法。但是,一旦我們將應用程序遷移到公共云,管理頂級性能就變得更像一種貓捉老鼠的游戲?,F(xiàn)在隨著容器的興起,管理績效是一個更大的挑戰(zhàn)。

而好消息是,通過容器架構,可以在應用程序中輕松地在非常精細的級別上添加性能檢測。鑒于新一批高度可擴展且響應迅速的管理工具,應該可以使用智能的IT操作自動化(可能基于有效使用機器學習)將大量的容器遷移到性能更好的服務器中。

對于技術組織而言,真正的訣竅是,如果不是可預測并持續(xù)存在,需要在實施選擇成本支出政策的同時,實現(xiàn)更高的性能。在某些方面,云計算和容器的這種平衡行為變得更加困難,這是因為增加了不透明性和可擴展性,但是采用分布式數(shù)據和處理技術將會使其更容易實施。

THEEND