為了降低成本和提高效率，越來越多的企業(yè)把基礎(chǔ)設(shè)施遷移到云端，不管是以公有云還是私有云的形式。

云計(jì)算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費(fèi)。這是因?yàn)橛脩魞A向于高估 (overestimate) 對(duì)資源的需求，并且在申請(qǐng)資源之后會(huì)低效的使用資源 (underutilize)。各種分析表明業(yè)界的云計(jì)算 CPU 使用率只有 6% 到 12%[1]。

eBay 有著巨大規(guī)模的云計(jì)算基礎(chǔ)設(shè)施，任何一點(diǎn)微小的改善都將顯著地為數(shù)據(jù)中心節(jié)省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 云計(jì)算 CPU 的超售比例達(dá)到 295%，內(nèi)存達(dá)到 118%，最終為標(biāo)準(zhǔn)型物理服務(wù)器貢獻(xiàn)出額外的超過 300TB 的內(nèi)存容量。這相當(dāng)于 1000 多臺(tái)最新型的標(biāo)準(zhǔn)服務(wù)器。

本文將分享我們?nèi)绾瓮ㄟ^如下步驟為 eBay 數(shù)據(jù)中心節(jié)省資源，旨在為同行帶來思考和借鑒：

一、監(jiān)控和分析物理服務(wù)器的性能指標(biāo)
二、改進(jìn) openstack 的資源調(diào)度器
三、建立動(dòng)態(tài)再平衡系統(tǒng)
四、灰度策略發(fā)布

一、監(jiān)控和分析物理服務(wù)器的性能指標(biāo)

eBay 私有云現(xiàn)在正在使用的 openstack 的計(jì)算模塊 Nova，本身并沒有記錄實(shí)際的計(jì)算資源使用情況。

所以我們的第一步是改進(jìn)分布在宿主機(jī)上的 Nova-Compute，從而保證可以收集并匯報(bào)實(shí)際的計(jì)算資源使用情況，特別是 CPU 和內(nèi)存。

Nova 收集并匯報(bào)的計(jì)算資源使用情況，只能服務(wù)于 Nova 相關(guān)的子模塊，比如資源調(diào)度器。但是我們還需要有計(jì)算資源使用情況的全局視角，所以我們采用了基于 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務(wù)器的性能數(shù)據(jù)，同時(shí)也可以按需去做各種各樣的聚合方便我們?nèi)グl(fā)現(xiàn)計(jì)算資源的使用特性。

二、改進(jìn) openstack 的資源調(diào)度器

安全的內(nèi)存超售

集群資源管理系統(tǒng)的資源調(diào)度器一般是基于裝箱的。

比如，如果一個(gè)物理服務(wù)器有 300G 的內(nèi)存，而一個(gè)虛擬機(jī)實(shí)例需要 10G 的內(nèi)存，資源調(diào)度器將最多只會(huì)調(diào)度 30 個(gè)實(shí)例到這臺(tái)物理機(jī)上。當(dāng)然，為了簡化說明問題，我們這里忽略了給物理機(jī)預(yù)留的內(nèi)存，并且實(shí)際調(diào)度中會(huì)有更多維度的資源限制。

當(dāng)我們有了足夠多的性能指標(biāo)和裝箱數(shù)據(jù)后，我們發(fā)現(xiàn)物理服務(wù)器有著大量的可用內(nèi)存資源，即使從裝箱角度來看他們已經(jīng)接近飽和，因此我們針對(duì)內(nèi)存引入了實(shí)際使用率 (AllocationRatio)的概念。

實(shí)際使用率 = 實(shí)際使用的內(nèi)存 / 裝箱內(nèi)存

eBay 私有云的物理服務(wù)器分為三種類型：標(biāo)準(zhǔn) (Standard)、高內(nèi)存性能 (High memory) 和大數(shù)據(jù)類型 (Big Data)。

標(biāo)準(zhǔn)機(jī)型主要運(yùn)行著 Web 相關(guān)應(yīng)用。以生產(chǎn)環(huán)境中運(yùn)行的第五代物理服務(wù)器為例，實(shí)際使用率 (AllocationRatio) 的分布如下圖所示，樣本總數(shù)約為 4000 臺(tái)，可以發(fā)現(xiàn)大多數(shù)服務(wù)器的實(shí)際使用率 (AllocationRatio) 主要分布在 60% 到 90% 區(qū)間。

 

 

基于如上數(shù)據(jù)，如果我們希望提高物理服務(wù)器的資源使用率，尤其是內(nèi)存資源，就需要進(jìn)行安全的內(nèi)存超售 (Safe Memory Oversubscription)。我們發(fā)現(xiàn)，安全的內(nèi)存超售的理論最大值基本上約等于實(shí)際使用率 (AllocationRatio) 的倒數(shù)。之所以用“約等于” ，是因?yàn)槲覀冃枰�考慮到物理服務(wù)器作為虛擬機(jī)宿主機(jī)的內(nèi)存消耗以及安全的內(nèi)存緩沖 (safety memory buffer)。

比如，如果一個(gè)虛擬機(jī)在創(chuàng)建的時(shí)候申請(qǐng)了 10G 內(nèi)存，但是在整個(gè)生命周期中只使用了 7G 內(nèi)存，我們就可以說這臺(tái)虛擬機(jī)的實(shí)際內(nèi)存使用率為 7/10=0.7。同時(shí)，我們也可以計(jì)算物理服務(wù)器的實(shí)際使用率 (AllocationRation)。

為簡單起見，我們假設(shè)所有的虛擬機(jī)都符合前面提到的情況，并且物理服務(wù)器本身的內(nèi)存使用為 10G，那么物理服務(wù)器的內(nèi)存使用率為 (7*30+10)/300= 73.3%，此時(shí)安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺(tái)物理服務(wù)器上再編排接近 10 個(gè)同樣大小的虛擬機(jī)�？紤]到真實(shí)生產(chǎn)環(huán)境中的風(fēng)險(xiǎn)以及內(nèi)存緩沖 (safety memory buffer), 我們不能做到如此激進(jìn)。

云原生親和性

我們將 eBay 私有云上運(yùn)行的虛擬機(jī)實(shí)例按照是否可以自由遷移以及遷移的時(shí)間成本分為三類：

云原生 (CloudNative) ：可遷移，遷移成本小于 1 小時(shí)
準(zhǔn)云原生 (Quasi-CloudNative) ：可遷移，遷移成本大于一小時(shí)
非云原生 (NonCloudNative)：不可遷移

集群資源管理系統(tǒng)的調(diào)度器在編排資源時(shí)的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應(yīng)用程序?qū)τ谌蒎e(cuò)域 (Fault Domain)的需求從而可以保證應(yīng)用程序的可用性。容錯(cuò)域代表出錯(cuò)的一個(gè)物理單元，在 eBay 內(nèi)部特指共享物理交換機(jī)、電源等設(shè)備的一組物理服務(wù)器，通常是半個(gè)或者整個(gè)機(jī)架。堆疊 (Stack)** 可以提高服務(wù)器的利用率，因?yàn)閷?duì)于新的資源編排請(qǐng)求，堆疊總是優(yōu)先把資源聚集到高負(fù)載的服務(wù)器，而不是那些空閑服務(wù)器。

OpenStack 默認(rèn)采用的是平鋪 (Spread) 策略，本質(zhì)上不利于提高物理服務(wù)器的利用率。我們采取的方法是在不影響上層應(yīng)用程序?qū)τ谌蒎e(cuò)域需求的情況下，將物理服務(wù)器劃分為云原生和非云原生兩類。由于一些特定的原因，我們只能找到很少全是云原生虛擬機(jī)的物理服務(wù)器，所以我們將云原生物理服務(wù)器的標(biāo)準(zhǔn)放寬為其上運(yùn)行的云原生虛擬機(jī)實(shí)例個(gè)數(shù)大于 N, N 值是動(dòng)態(tài)調(diào)整的。在完成物理服務(wù)器的分類和標(biāo)定之后，我們進(jìn)一步改進(jìn)了 Nova-Scheduler 的編排策略，實(shí)現(xiàn)了：

盡量把云原生 (CloudNative) 屬性的虛擬機(jī)編排到云原生物理服務(wù)器上，從而實(shí)現(xiàn)云原生虛擬機(jī)的聚集效應(yīng)，提高云原生物理服務(wù)器的計(jì)算資源利用率 ;

禁止準(zhǔn)云原生 (Quasi-CloudNative) 和非云原生 (NonCloudNative) 屬性的虛擬機(jī)請(qǐng)求編排到云原生物理服務(wù)器上，從而保證下文提到的動(dòng)態(tài)再平衡系統(tǒng)可以在系統(tǒng)有過載傾向時(shí)可以介入并能正常工作。

三、動(dòng)態(tài)再平衡系統(tǒng)

隨著我們通過上述的超售方式把越來越多的虛擬機(jī)實(shí)例放到物理機(jī)上，不可避免地會(huì)出現(xiàn)資源過載情況，可能出現(xiàn)在處理器或者內(nèi)存，也可能兩者兼而有之。

我們需要一個(gè)再平衡系統(tǒng)去監(jiān)測和發(fā)現(xiàn)高負(fù)荷運(yùn)載的物理機(jī)，在系統(tǒng)資源飽和影響上層應(yīng)用程序性能和業(yè)務(wù)之前遷走上面的工作負(fù)載，從而讓有過熱傾向的物理機(jī)回到正常狀態(tài)。

再平衡系統(tǒng)定義了兩種形式的任務(wù)：被動(dòng)式 (Reactive) 和主動(dòng)式 (Proactive)

被動(dòng)再平衡 (Reactive)

針對(duì)這種任務(wù)，再平衡系統(tǒng)定義了三種形式的報(bào)警策略：

i CPU 過載 — 閾值設(shè)定為范化的 15 分鐘 CPU 負(fù)載 (normalized cpu load15) >= 0.7, 0.7 是基于 eBay 線上大規(guī)模應(yīng)用性能的統(tǒng)計(jì)經(jīng)驗(yàn)值;

ii 內(nèi)存過載— 和 CPU 提供給實(shí)例的是使用時(shí)間不同， 內(nèi)存提供的是使用空間，所以內(nèi)存是計(jì)算資源中最不具有彈性的資源，這意味著內(nèi)存的使用大小基本上是不可壓縮的， 因?yàn)樗�是有狀態(tài)的，申請(qǐng)資源慢，并且基本上不可能被回收。 基于安全原因的考慮， 我們需要保留一定的安全內(nèi)存緩沖 (safety memory buffer), 從而保證任何時(shí)候虛擬機(jī)實(shí)例向物理機(jī)申請(qǐng)內(nèi)存都能夠成功，所以我們用到的最小可用內(nèi)存閾值是物理機(jī)總內(nèi)存的 10%;

iii Swap— swap 的觸發(fā)意味著可能存在內(nèi)存的慢速訪問，極有可能會(huì)影響上層應(yīng)用程序的性能進(jìn)而影響業(yè)務(wù)。

再平衡系統(tǒng)會(huì)周期性地查詢物理服務(wù)器性能指標(biāo)，以檢查是否有過載傾向。如果服務(wù)器有過載的傾向，系統(tǒng)會(huì)產(chǎn)生一個(gè)報(bào)警消息并發(fā)送到消息隊(duì)列里;

多個(gè)工作進(jìn)程會(huì)監(jiān)聽消息隊(duì)列，拿到消息隊(duì)列后會(huì)從其他的配置系統(tǒng)里獲取其他數(shù)據(jù)，包括服務(wù)器具體的性能指標(biāo)，從 KVM 角度觀察到的虛擬機(jī)性能指標(biāo)，虛擬機(jī)、資源池以及應(yīng)用服務(wù)的配置信息;

基于上述收集到的數(shù)據(jù)，再平衡系統(tǒng)會(huì)做出綜合決策，挑選出一個(gè)或者多個(gè)虛擬機(jī)并且通過調(diào)用 PaaS 層的 API 來完成虛擬機(jī)的遷移，從而減輕物理服務(wù)器的工作負(fù)載保證其在安全范圍之內(nèi)。

由于內(nèi)存是最不具彈性的計(jì)算資源，并且我們持續(xù)的優(yōu)化內(nèi)存去提高利用率，在這種情況下，物理服務(wù)器的可用內(nèi)存就成為了一個(gè)關(guān)鍵指標(biāo)，所以我們定義了兩級(jí)內(nèi)存報(bào)警：警告 (warning) 和危險(xiǎn) (Critical)。一旦可用內(nèi)存低于警告 (warning) 閾值， 再平衡系統(tǒng)會(huì)挑選出一個(gè)或者多個(gè)虛擬機(jī)并調(diào)用 PaaS API 來遷移。但是這個(gè)遷移過程需要一定的時(shí)間，如果在此期間可用內(nèi)存持續(xù)快速減少并達(dá)到危險(xiǎn) (Critical) 閾值，再平衡系統(tǒng)會(huì)基于一定的安全策略從中挑選一個(gè)云原生 (CloudNative) 屬性的虛擬機(jī)強(qiáng)制關(guān)機(jī)，從而保證該物理服務(wù)器上的其他虛擬機(jī)性能不受影響。

主動(dòng)再平衡 (Proactive)

基于實(shí)際觀測到的數(shù)據(jù)，當(dāng)物理服務(wù)器規(guī)模足夠大時(shí)，它們實(shí)際的計(jì)算資源使用率基本上服從正態(tài)分布，尤其是 CPU 使用率，如下圖所示：

 

 

 

 

除了上文中提到的被動(dòng)再平衡任務(wù)，再平衡系統(tǒng)也會(huì)周期性地掃描所有的云原生物理服務(wù)器實(shí)際的 CPU 和內(nèi)存使用率，并從中挑選出前 2.5% 的物理服務(wù)器遷移上面的云原生虛擬機(jī)，從而做到平衡云原生物理服務(wù)器的負(fù)載。其中，2.5% 約等于正態(tài)分布右側(cè)二級(jí)標(biāo)準(zhǔn)差 [2] 之外的數(shù)值。

四、灰度策略發(fā)布

有云原生屬性的虛擬機(jī)實(shí)例主要分布在標(biāo)準(zhǔn) (Standard) 物理服務(wù)器上，我們標(biāo)定了其中約 5000 臺(tái)服務(wù)器來實(shí)施安全內(nèi)存優(yōu)化。通過應(yīng)用上文提到的改進(jìn)的資源調(diào)度器將更多的虛擬機(jī)實(shí)例編排到這些物理服務(wù)器上并且不斷的將云原生虛擬機(jī)編排到云原生物理服務(wù)器上，同時(shí)用再平衡系統(tǒng)來保證應(yīng)用程序的性能不會(huì)因?yàn)橛?jì)算資源的超售受到影響。

在調(diào)整 CPU 和內(nèi)存超售比例的過程中，我們采用灰度發(fā)布和對(duì)數(shù)增長策略來保證每一步調(diào)整足夠的安全可靠，這意味著超售比例的每一次躍遷不會(huì)影響應(yīng)用程序的性能，同時(shí)也不會(huì)引起再平衡系統(tǒng)的遷移風(fēng)暴。

 

 

灰度發(fā)布策略：

標(biāo)定三臺(tái)云原生物理服務(wù)器為一級(jí)目標(biāo)機(jī)，調(diào)整其計(jì)算資源超售比例;

當(dāng)一級(jí)目標(biāo)機(jī)上的裝箱接近飽和并穩(wěn)定運(yùn)行一段時(shí)間后，對(duì)物理服務(wù)器以及其上運(yùn)行的虛擬機(jī)和相關(guān)的應(yīng)用程序做性能驗(yàn)證;

如果上一步提到的性能驗(yàn)證通過，會(huì)標(biāo)定一個(gè)機(jī)架的物理服務(wù)器為二級(jí)目標(biāo)機(jī)，調(diào)整其超售比例和一級(jí)目標(biāo)機(jī)一致;

當(dāng)二級(jí)目標(biāo)機(jī)上的裝箱接近飽和并穩(wěn)定運(yùn)行一段時(shí)間后，對(duì)物理服務(wù)器以及其上運(yùn)行的虛擬機(jī)和相關(guān)的應(yīng)用程序做性能驗(yàn)證;

如果二級(jí)目標(biāo)機(jī)上的性能驗(yàn)證通過，會(huì)把同樣的超售比例應(yīng)用收到所有的 5000 臺(tái)云原生物理服務(wù)器上;

進(jìn)入下一輪超售比例調(diào)整。

 

 

總結(jié)

通過一系列的優(yōu)化和調(diào)整，在不影響上層應(yīng)用程序性能這一絕對(duì)安全的前提下，我們持續(xù)的提高 CPU 和內(nèi)存的超售比例。

截止 2018 年底，CPU 的超售比例達(dá)到了 295%，內(nèi)存達(dá)到了 118%，最終為標(biāo)準(zhǔn)型物理服務(wù)器貢獻(xiàn)出額外的超過 300TB 的內(nèi)存容量。這相當(dāng)于 1000 多臺(tái)最新型的標(biāo)準(zhǔn)服務(wù)器。

基于此， 我們下調(diào)了 eBay 私有云的 2019 年的容量預(yù)算。

 

 

與此同時(shí)，我們也大幅提高了計(jì)算資源的實(shí)際使用率，尤其是 CPU 和內(nèi)存，如圖所示，從 2018 年 5 月到 2018 年 12 月，實(shí)際的內(nèi)存使用率從48%提高到了68%，增幅約為42%;實(shí)際的 CPU 使用率從12%提到了29%，增幅約為142%，其中的峰值數(shù)據(jù)來自于十一月初的黑五大促前后。

標(biāo)簽： 數(shù)據(jù)中心 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。