通過進一步抽象化計算基礎設施，可以使開發(fā)人員的工作變得更輕松，而與此同時，軟件容器化也被認為可以更有效地利用數(shù)據(jù)中心中的處理能力的驅動程序。當人們從服務器中獲得更多收益之前，容納這些服務器的數(shù)據(jù)中心的規(guī)模能夠變得更小嗎?能否采用電力容量為40MW的數(shù)據(jù)中心來代替電力容量為100MW的綜合數(shù)據(jù)中心設施，而在這一過程中節(jié)省數(shù)億美元的成本?

 

盡管現(xiàn)在由Kubernetes領導的容器化軟件運動只有不到6年的歷史，但對于這樣一種模式的出現(xiàn)在時間方面已經(jīng)足夠了，那么容器化是否帶來了更節(jié)能的數(shù)據(jù)中心?

 

OpenStack基金會執(zhí)行董事Jonathan Bryce表示：“目前我們在這方面還沒有真正詳盡的定量數(shù)據(jù)。”

 

自從OpenStack基金會在2012年成立以來，Bryce一直是軟件開放基礎設施運動的代言人。OpenStack基金會的最初目標是建立一個易于部署的框架，用于構建數(shù)據(jù)中心(不是建筑物和基礎設施，而是數(shù)據(jù)中心的IT系統(tǒng))，可以像公共云一樣進行配置。管理員應該能夠像在Rackspace、GoGrid或AWS云平臺一樣在自己的服務器上部署虛擬機。Bryce表示，服務器虛擬化提高了處理器的利用率和效率，這種趨勢主要是由于很多企業(yè)希望在其自己的數(shù)據(jù)中心中復制公共云的易用性。

 

Bryce表示看到了一些數(shù)據(jù)中心的規(guī)模在縮減。據(jù)他估計，處理相同工作負載量，如今的數(shù)據(jù)中心空間只是2005年運營的數(shù)據(jù)中心的五分之一到十分之一。凈占用空間的減少還影響了其他因素，其中包括數(shù)據(jù)存儲密度的增加、處理能力的小型化(直到摩爾定律失效)，以及在高性能計算中引入加速器。

 

Bryce說：“虛擬化的最初實現(xiàn)方式是作為IT部門的一種高效工具。如果想要一臺服務器，就需要提交票據(jù)，這指的并不是進入物理數(shù)據(jù)中心、連接機架服務器和電纜……而是IT管理員進入VMware，通過軟件進行處理，然后就會很快地擁有一臺虛擬服務器。而其效率是針對IT人員，而不是開發(fā)人員或最終用戶。”

 

虛擬化只是在軟件級別上采用相同資源的自動報價過程代替了新硬件的請求過程。除了自動化之外，還需要采用基礎設施遙測技術。軟件和系統(tǒng)越來越多地提供其狀態(tài)和運營歷史記錄，而不僅僅是專用日志，而是通過日志工具所聯(lián)系的API來提供。電源管理軟件利用了由服務器內部管理功能打開的新興API庫。

 

Bryce解釋說，“如果用戶的應用程序性能受到影響，API的作用是使其能夠迅速獲取這些資源，然后迅速進行更改。一旦人們開始看到實際的云原生環(huán)境，就會為數(shù)據(jù)中心提供該API。這使用戶有能力要求獲得認為自己需要的資源，然后發(fā)現(xiàn)需要不同的資源時進行調整。”

 

這項創(chuàng)新是平均CPU利用率從15%躍升至80%的時期進行的。從理論上講，容器化可以進一步提高利用率。

 

在過去的五年中，自從容器化革命開始以來，David Kramer一直是數(shù)據(jù)中心客戶轉型的解決方案架構師。Kramer先后入職Red Hat公司和Docker公司，最終入職Mirantis公司工作，Mirantis公司在2019年收購了Docker Enterprise投資組合。他的工作是為客戶數(shù)據(jù)中心設計議程，使客戶數(shù)據(jù)中心從虛擬機轉向容器化軟件基礎設施。

 

Kramer說：“我們在白板上制定典型的數(shù)據(jù)中心部署，描述出當服務器進入生產(chǎn)環(huán)境并成為工作負載的主機時會發(fā)生什么。通常的步驟是：訂購服務器，評估各種機架方案，選擇其中一種方案，配置服務器的裸機，添加虛擬機監(jiān)控程序，以及將虛擬機工作負載的映像放置在虛擬機監(jiān)控程序上。在那里，IT人員將服務器交給開發(fā)人員，該開發(fā)人員負責提供和安裝工作負載。第二個問題是，‘工作負載的實際CPU使用率是多少?’”通常大約在30%左右。

 

但這30%是運行應用程序及其所有依賴項，如代碼庫和操作系統(tǒng)。運行所有這些依賴項當然可以提高利用率。但在某種程度上，這就是問題所在。虛擬機環(huán)境沒有利用這樣一個事實，即駐留在同一服務器上但位于不同虛擬機中的多個應用程序通常具有相同的依賴關系，這意味著要執(zhí)行大量重復代碼，從而耗盡了硬件資源。”

 

Kramer繼續(xù)說道，“有時候，部署在服務器上的依賴關系并不與其他應用程序共存，那么該怎么辦?只能部署另一個虛擬機。而在突然之間，就有了虛擬機堆疊的開銷和計算資源的實際開銷。容器化幾乎顛覆了這一說法。

 

換句話說，一旦容器引擎(如Docker)成為應用程序的支持層，即使安裝在自己的虛擬機中，適當工作負載分配的下一步就是消除冗余依賴的所有開銷。組織使用原有公式確定CPU的繁忙程度，這將降低利用率，同時提高效率。”

 

也許那時，解決方案架構師可以利用機會在每個物理主機上放置更多的應用程序，并且數(shù)據(jù)中心規(guī)模應該變得更小。這是真的嗎?

 

Cloud Foundry Foundation首席技術官Chip Childers回應說，“答案是否定的。從純粹的工程角度來看，它排除了會影響這個答案的其他趨勢和現(xiàn)實。”

 

他繼續(xù)說，“如果使用容器，還會發(fā)生哪些其他事情?組織可能會加快開發(fā)。組織的開發(fā)團隊可能正在開發(fā)更多的分布式架構——開始將純粹在數(shù)據(jù)中心運行的應用程序與在公共云中運行的應用程序混合。也可能會開發(fā)越來越多的軟件。”

 

他指出，“這是杰文斯悖論的一個例子。如果組織提高商品的使用效率，并改善對該商品的使用權限，那么實際上將會使用更多的商品。這個理論適用于云服務的使用，數(shù)據(jù)中心內的云原生架構，以及通常為了更好地利用這些優(yōu)勢而進行的人員和流程更改。我們看到將會開發(fā)更多的應用程序，并且采用更多的技術。”

 

技術設施設計商HDR公司的全球總監(jiān)Robert Sty在2017年撰寫的一份報告指出，數(shù)據(jù)中心基礎設施的完全虛擬化與在大型設施中觀察到的現(xiàn)象之間存在直接的因果關系，尤其是像Facebook公司這樣的超大規(guī)模運營的數(shù)據(jù)中心。

 

Sty寫道：“隨著虛擬化的實施變得越來越普遍，服務器變得更加高效和強大，數(shù)據(jù)中心運營商以更高的功率密度運行IT機柜。超大規(guī)模廠商率先將服務器機架放置在地板上，從而用熱通道氣流遏制系統(tǒng)(可移動的屏障將熱的廢氣流與冷的進氣流隔開)代替了昂貴的高架地板方法。從理論上講，通過在虛擬機之間細分CPU能力的虛擬化系統(tǒng)使服務器密度增加變得可行，這應該會使服務器機架的冷卻散熱問題更加嚴重。但是，由于它們占用的空間更少，因此出現(xiàn)的冷卻解決方案得到了根本簡化，并且成本也更低。

 

有些人認為，如果沒有允許冷卻地板上部署高密度服務器機架的計劃，超大規(guī)模架構將是不可行的。在某些超大規(guī)模設計中，一些可用性服務器部署在單獨的隔間中。這些可能需要留出足夠空間的機架，并且需要備用的冷卻措施。但是，這種劃分假設工作負載通常分為“關鍵需求”池和“一般需求”池。但是，如果在服務器池中將它們全部編排在一起，那么在容器化微服務的海洋中，這種細分可能就沒有意義了。

 

在非容器化的基礎設施中，需要高可用性的工作負載往往會孤立發(fā)展。在那種孤立的環(huán)境中，處理和冷卻功率消耗可能會上升。”

 

Kramer表示，降低服務器成本，通過Swarm提高容器密度和計算效率將會顯著減少未充分利用的服務器。此外，分布式架構減少了對專用高可用性服務器的需求。

 

他說，“組織的應用程序現(xiàn)在在容器中運行。容器的協(xié)調器以一種比傳統(tǒng)方法更有效的方式交付工作負載。”

 

總而言之，將工作負載隔離在容器中，并將它們與內部依賴項分離可以減少開銷，并降低近期的利用率。然后，Kubernetes在整個服務器集群中重新分配工作負載將導致更高的利用率水平，并為減少服務器的數(shù)量創(chuàng)造了機會，也為消除數(shù)據(jù)中心的專用高可用性部分提供了機會，這意味著冷卻基礎設施所需的空間更少。

 

雖然數(shù)據(jù)中心的利用率日前提高，但承載的工作負載將越來越多，這可能是人們還沒有看到數(shù)據(jù)中心規(guī)模由于采用容器化技術而消減的原因。

 

版權聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責任的權利。