為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
三、動態再平衡系統
隨著我們通過上述的超售方式把越來越多的虛擬機實例放到物理機上，不可避免地會出現資源過載情況，可能出現在處理器或者內存，也可能兩者兼而有之。
我們需要一個再平衡系統去監測和發現高負荷運載的物理機，在系統資源飽和影響上層應用程序性能和業務之前遷走上面的工作負載，從而讓有過熱傾向的物理機回到正常狀態。
再平衡系統定義了兩種形式的任務：被動式 (Reactive) 和主動式 (Proactive)
被動再平衡 (Reactive)
針對這種任務，再平衡系統定義了三種形式的報警策略：
i CPU 過載 — 閾值設定為範化的 15 分鐘 CPU 負載 (normalized cpu load15) >= 0.7, 0.7 是基於 eBay 線上大規模應用性能的統計經驗值;
ii 內存過載— 和 CPU 提供給實例的是使用時間不同， 內存提供的是使用空間，所以內存是計算資源中最不具有彈性的資源，這意味著內存的使用大小基本上是不可壓縮的， 因為它是有狀態的，申請資源慢，並且基本上不可能被回收。 基於安全原因的考慮， 我們需要保留一定的安全內存緩衝 (safety memory buffer), 從而保證任何時候虛擬機實例向物理機申請內存都能夠成功，所以我們用到的最小可用內存閾值是物理機總內存的 10%;
iii Swap— swap 的觸發意味著可能存在內存的慢速訪問，極有可能會影響上層應用程序的性能進而影響業務。
再平衡系統會週期性地查詢物理服務器性能指標，以檢查是否有過載傾向。如果服務器有過載的傾向，系統會產生一個報警消息併發送到消息隊列裡;
多個工作進程會監聽消息隊列，拿到消息隊列後會從其他的配置系統裡獲取其他數據，包括服務器具體的性能指標，從 KVM 角度觀察到的虛擬機性能指標，虛擬機、資源池以及應用服務的配置信息;
基於上述收集到的數據，再平衡系統會做出綜合決策，挑選出一個或者多個虛擬機並且通過調用 PaaS 層的 API 來完成虛擬機的遷移，從而減輕物理服務器的工作負載保證其在安全範圍之內。
由於內存是最不具彈性的計算資源，並且我們持續的優化內存去提高利用率，在這種情況下，物理服務器的可用內存就成為了一個關鍵指標，所以我們定義了兩級內存報警：警告 (warning) 和危險 (Critical)。一旦可用內存低於警告 (warning) 閾值， 再平衡系統會挑選出一個或者多個虛擬機並調用 PaaS API 來遷移。但是這個遷移過程需要一定的時間，如果在此期間可用內存持續快速減少並達到危險 (Critical) 閾值，再平衡系統會基於一定的安全策略從中挑選一個雲原生 (CloudNative) 屬性的虛擬機強制關機，從而保證該物理服務器上的其他虛擬機性能不受影響。
主動再平衡 (Proactive)
基於實際觀測到的數據，當物理服務器規模足夠大時，它們實際的計算資源使用率基本上服從正態分佈，尤其是 CPU 使用率，如下圖所示：
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
三、動態再平衡系統
隨著我們通過上述的超售方式把越來越多的虛擬機實例放到物理機上，不可避免地會出現資源過載情況，可能出現在處理器或者內存，也可能兩者兼而有之。
我們需要一個再平衡系統去監測和發現高負荷運載的物理機，在系統資源飽和影響上層應用程序性能和業務之前遷走上面的工作負載，從而讓有過熱傾向的物理機回到正常狀態。
再平衡系統定義了兩種形式的任務：被動式 (Reactive) 和主動式 (Proactive)
被動再平衡 (Reactive)
針對這種任務，再平衡系統定義了三種形式的報警策略：
i CPU 過載 — 閾值設定為範化的 15 分鐘 CPU 負載 (normalized cpu load15) >= 0.7, 0.7 是基於 eBay 線上大規模應用性能的統計經驗值;
ii 內存過載— 和 CPU 提供給實例的是使用時間不同， 內存提供的是使用空間，所以內存是計算資源中最不具有彈性的資源，這意味著內存的使用大小基本上是不可壓縮的， 因為它是有狀態的，申請資源慢，並且基本上不可能被回收。 基於安全原因的考慮， 我們需要保留一定的安全內存緩衝 (safety memory buffer), 從而保證任何時候虛擬機實例向物理機申請內存都能夠成功，所以我們用到的最小可用內存閾值是物理機總內存的 10%;
iii Swap— swap 的觸發意味著可能存在內存的慢速訪問，極有可能會影響上層應用程序的性能進而影響業務。
再平衡系統會週期性地查詢物理服務器性能指標，以檢查是否有過載傾向。如果服務器有過載的傾向，系統會產生一個報警消息併發送到消息隊列裡;
多個工作進程會監聽消息隊列，拿到消息隊列後會從其他的配置系統裡獲取其他數據，包括服務器具體的性能指標，從 KVM 角度觀察到的虛擬機性能指標，虛擬機、資源池以及應用服務的配置信息;
基於上述收集到的數據，再平衡系統會做出綜合決策，挑選出一個或者多個虛擬機並且通過調用 PaaS 層的 API 來完成虛擬機的遷移，從而減輕物理服務器的工作負載保證其在安全範圍之內。
由於內存是最不具彈性的計算資源，並且我們持續的優化內存去提高利用率，在這種情況下，物理服務器的可用內存就成為了一個關鍵指標，所以我們定義了兩級內存報警：警告 (warning) 和危險 (Critical)。一旦可用內存低於警告 (warning) 閾值， 再平衡系統會挑選出一個或者多個虛擬機並調用 PaaS API 來遷移。但是這個遷移過程需要一定的時間，如果在此期間可用內存持續快速減少並達到危險 (Critical) 閾值，再平衡系統會基於一定的安全策略從中挑選一個雲原生 (CloudNative) 屬性的虛擬機強制關機，從而保證該物理服務器上的其他虛擬機性能不受影響。
主動再平衡 (Proactive)
基於實際觀測到的數據，當物理服務器規模足夠大時，它們實際的計算資源使用率基本上服從正態分佈，尤其是 CPU 使用率，如下圖所示：
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
三、動態再平衡系統
隨著我們通過上述的超售方式把越來越多的虛擬機實例放到物理機上，不可避免地會出現資源過載情況，可能出現在處理器或者內存，也可能兩者兼而有之。
我們需要一個再平衡系統去監測和發現高負荷運載的物理機，在系統資源飽和影響上層應用程序性能和業務之前遷走上面的工作負載，從而讓有過熱傾向的物理機回到正常狀態。
再平衡系統定義了兩種形式的任務：被動式 (Reactive) 和主動式 (Proactive)
被動再平衡 (Reactive)
針對這種任務，再平衡系統定義了三種形式的報警策略：
i CPU 過載 — 閾值設定為範化的 15 分鐘 CPU 負載 (normalized cpu load15) >= 0.7, 0.7 是基於 eBay 線上大規模應用性能的統計經驗值;
ii 內存過載— 和 CPU 提供給實例的是使用時間不同， 內存提供的是使用空間，所以內存是計算資源中最不具有彈性的資源，這意味著內存的使用大小基本上是不可壓縮的， 因為它是有狀態的，申請資源慢，並且基本上不可能被回收。 基於安全原因的考慮， 我們需要保留一定的安全內存緩衝 (safety memory buffer), 從而保證任何時候虛擬機實例向物理機申請內存都能夠成功，所以我們用到的最小可用內存閾值是物理機總內存的 10%;
iii Swap— swap 的觸發意味著可能存在內存的慢速訪問，極有可能會影響上層應用程序的性能進而影響業務。
再平衡系統會週期性地查詢物理服務器性能指標，以檢查是否有過載傾向。如果服務器有過載的傾向，系統會產生一個報警消息併發送到消息隊列裡;
多個工作進程會監聽消息隊列，拿到消息隊列後會從其他的配置系統裡獲取其他數據，包括服務器具體的性能指標，從 KVM 角度觀察到的虛擬機性能指標，虛擬機、資源池以及應用服務的配置信息;
基於上述收集到的數據，再平衡系統會做出綜合決策，挑選出一個或者多個虛擬機並且通過調用 PaaS 層的 API 來完成虛擬機的遷移，從而減輕物理服務器的工作負載保證其在安全範圍之內。
由於內存是最不具彈性的計算資源，並且我們持續的優化內存去提高利用率，在這種情況下，物理服務器的可用內存就成為了一個關鍵指標，所以我們定義了兩級內存報警：警告 (warning) 和危險 (Critical)。一旦可用內存低於警告 (warning) 閾值， 再平衡系統會挑選出一個或者多個虛擬機並調用 PaaS API 來遷移。但是這個遷移過程需要一定的時間，如果在此期間可用內存持續快速減少並達到危險 (Critical) 閾值，再平衡系統會基於一定的安全策略從中挑選一個雲原生 (CloudNative) 屬性的虛擬機強制關機，從而保證該物理服務器上的其他虛擬機性能不受影響。
主動再平衡 (Proactive)
基於實際觀測到的數據，當物理服務器規模足夠大時，它們實際的計算資源使用率基本上服從正態分佈，尤其是 CPU 使用率，如下圖所示：
除了上文中提到的被動再平衡任務，再平衡系統也會週期性地掃描所有的雲原生物理服務器實際的 CPU 和內存使用率，並從中挑選出前 2.5% 的物理服務器遷移上面的雲原生虛擬機，從而做到平衡雲原生物理服務器的負載。其中，2.5% 約等於正態分佈右側二級標準差 [2] 之外的數值。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
三、動態再平衡系統
隨著我們通過上述的超售方式把越來越多的虛擬機實例放到物理機上，不可避免地會出現資源過載情況，可能出現在處理器或者內存，也可能兩者兼而有之。
我們需要一個再平衡系統去監測和發現高負荷運載的物理機，在系統資源飽和影響上層應用程序性能和業務之前遷走上面的工作負載，從而讓有過熱傾向的物理機回到正常狀態。
再平衡系統定義了兩種形式的任務：被動式 (Reactive) 和主動式 (Proactive)
被動再平衡 (Reactive)
針對這種任務，再平衡系統定義了三種形式的報警策略：
i CPU 過載 — 閾值設定為範化的 15 分鐘 CPU 負載 (normalized cpu load15) >= 0.7, 0.7 是基於 eBay 線上大規模應用性能的統計經驗值;
ii 內存過載— 和 CPU 提供給實例的是使用時間不同， 內存提供的是使用空間，所以內存是計算資源中最不具有彈性的資源，這意味著內存的使用大小基本上是不可壓縮的， 因為它是有狀態的，申請資源慢，並且基本上不可能被回收。 基於安全原因的考慮， 我們需要保留一定的安全內存緩衝 (safety memory buffer), 從而保證任何時候虛擬機實例向物理機申請內存都能夠成功，所以我們用到的最小可用內存閾值是物理機總內存的 10%;
iii Swap— swap 的觸發意味著可能存在內存的慢速訪問，極有可能會影響上層應用程序的性能進而影響業務。
再平衡系統會週期性地查詢物理服務器性能指標，以檢查是否有過載傾向。如果服務器有過載的傾向，系統會產生一個報警消息併發送到消息隊列裡;
多個工作進程會監聽消息隊列，拿到消息隊列後會從其他的配置系統裡獲取其他數據，包括服務器具體的性能指標，從 KVM 角度觀察到的虛擬機性能指標，虛擬機、資源池以及應用服務的配置信息;
基於上述收集到的數據，再平衡系統會做出綜合決策，挑選出一個或者多個虛擬機並且通過調用 PaaS 層的 API 來完成虛擬機的遷移，從而減輕物理服務器的工作負載保證其在安全範圍之內。
由於內存是最不具彈性的計算資源，並且我們持續的優化內存去提高利用率，在這種情況下，物理服務器的可用內存就成為了一個關鍵指標，所以我們定義了兩級內存報警：警告 (warning) 和危險 (Critical)。一旦可用內存低於警告 (warning) 閾值， 再平衡系統會挑選出一個或者多個虛擬機並調用 PaaS API 來遷移。但是這個遷移過程需要一定的時間，如果在此期間可用內存持續快速減少並達到危險 (Critical) 閾值，再平衡系統會基於一定的安全策略從中挑選一個雲原生 (CloudNative) 屬性的虛擬機強制關機，從而保證該物理服務器上的其他虛擬機性能不受影響。
主動再平衡 (Proactive)
基於實際觀測到的數據，當物理服務器規模足夠大時，它們實際的計算資源使用率基本上服從正態分佈，尤其是 CPU 使用率，如下圖所示：
除了上文中提到的被動再平衡任務，再平衡系統也會週期性地掃描所有的雲原生物理服務器實際的 CPU 和內存使用率，並從中挑選出前 2.5% 的物理服務器遷移上面的雲原生虛擬機，從而做到平衡雲原生物理服務器的負載。其中，2.5% 約等於正態分佈右側二級標準差 [2] 之外的數值。
四、灰度策略發佈
有云原生屬性的虛擬機實例主要分佈在標準 (Standard) 物理服務器上，我們標定了其中約 5000 臺服務器來實施安全內存優化。通過應用上文提到的改進的資源調度器將更多的虛擬機實例編排到這些物理服務器上並且不斷的將雲原生虛擬機編排到雲原生物理服務器上，同時用再平衡系統來保證應用程序的性能不會因為計算資源的超售受到影響。
在調整 CPU 和內存超售比例的過程中，我們採用灰度發佈和對數增長策略來保證每一步調整足夠的安全可靠，這意味著超售比例的每一次躍遷不會影響應用程序的性能，同時也不會引起再平衡系統的遷移風暴。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
三、動態再平衡系統
隨著我們通過上述的超售方式把越來越多的虛擬機實例放到物理機上，不可避免地會出現資源過載情況，可能出現在處理器或者內存，也可能兩者兼而有之。
我們需要一個再平衡系統去監測和發現高負荷運載的物理機，在系統資源飽和影響上層應用程序性能和業務之前遷走上面的工作負載，從而讓有過熱傾向的物理機回到正常狀態。
再平衡系統定義了兩種形式的任務：被動式 (Reactive) 和主動式 (Proactive)
被動再平衡 (Reactive)
針對這種任務，再平衡系統定義了三種形式的報警策略：
i CPU 過載 — 閾值設定為範化的 15 分鐘 CPU 負載 (normalized cpu load15) >= 0.7, 0.7 是基於 eBay 線上大規模應用性能的統計經驗值;
ii 內存過載— 和 CPU 提供給實例的是使用時間不同， 內存提供的是使用空間，所以內存是計算資源中最不具有彈性的資源，這意味著內存的使用大小基本上是不可壓縮的， 因為它是有狀態的，申請資源慢，並且基本上不可能被回收。 基於安全原因的考慮， 我們需要保留一定的安全內存緩衝 (safety memory buffer), 從而保證任何時候虛擬機實例向物理機申請內存都能夠成功，所以我們用到的最小可用內存閾值是物理機總內存的 10%;
iii Swap— swap 的觸發意味著可能存在內存的慢速訪問，極有可能會影響上層應用程序的性能進而影響業務。
再平衡系統會週期性地查詢物理服務器性能指標，以檢查是否有過載傾向。如果服務器有過載的傾向，系統會產生一個報警消息併發送到消息隊列裡;
多個工作進程會監聽消息隊列，拿到消息隊列後會從其他的配置系統裡獲取其他數據，包括服務器具體的性能指標，從 KVM 角度觀察到的虛擬機性能指標，虛擬機、資源池以及應用服務的配置信息;
基於上述收集到的數據，再平衡系統會做出綜合決策，挑選出一個或者多個虛擬機並且通過調用 PaaS 層的 API 來完成虛擬機的遷移，從而減輕物理服務器的工作負載保證其在安全範圍之內。
由於內存是最不具彈性的計算資源，並且我們持續的優化內存去提高利用率，在這種情況下，物理服務器的可用內存就成為了一個關鍵指標，所以我們定義了兩級內存報警：警告 (warning) 和危險 (Critical)。一旦可用內存低於警告 (warning) 閾值， 再平衡系統會挑選出一個或者多個虛擬機並調用 PaaS API 來遷移。但是這個遷移過程需要一定的時間，如果在此期間可用內存持續快速減少並達到危險 (Critical) 閾值，再平衡系統會基於一定的安全策略從中挑選一個雲原生 (CloudNative) 屬性的虛擬機強制關機，從而保證該物理服務器上的其他虛擬機性能不受影響。
主動再平衡 (Proactive)
基於實際觀測到的數據，當物理服務器規模足夠大時，它們實際的計算資源使用率基本上服從正態分佈，尤其是 CPU 使用率，如下圖所示：
除了上文中提到的被動再平衡任務，再平衡系統也會週期性地掃描所有的雲原生物理服務器實際的 CPU 和內存使用率，並從中挑選出前 2.5% 的物理服務器遷移上面的雲原生虛擬機，從而做到平衡雲原生物理服務器的負載。其中，2.5% 約等於正態分佈右側二級標準差 [2] 之外的數值。
四、灰度策略發佈
有云原生屬性的虛擬機實例主要分佈在標準 (Standard) 物理服務器上，我們標定了其中約 5000 臺服務器來實施安全內存優化。通過應用上文提到的改進的資源調度器將更多的虛擬機實例編排到這些物理服務器上並且不斷的將雲原生虛擬機編排到雲原生物理服務器上，同時用再平衡系統來保證應用程序的性能不會因為計算資源的超售受到影響。
在調整 CPU 和內存超售比例的過程中，我們採用灰度發佈和對數增長策略來保證每一步調整足夠的安全可靠，這意味著超售比例的每一次躍遷不會影響應用程序的性能，同時也不會引起再平衡系統的遷移風暴。
灰度發佈策略：
標定三臺雲原生物理服務器為一級目標機，調整其計算資源超售比例;
當一級目標機上的裝箱接近飽和並穩定運行一段時間後，對物理服務器以及其上運行的虛擬機和相關的應用程序做性能驗證;
如果上一步提到的性能驗證通過，會標定一個機架的物理服務器為二級目標機，調整其超售比例和一級目標機一致;
當二級目標機上的裝箱接近飽和並穩定運行一段時間後，對物理服務器以及其上運行的虛擬機和相關的應用程序做性能驗證;
如果二級目標機上的性能驗證通過，會把同樣的超售比例應用收到所有的 5000 臺雲原生物理服務器上;
進入下一輪超售比例調整。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
三、動態再平衡系統
隨著我們通過上述的超售方式把越來越多的虛擬機實例放到物理機上，不可避免地會出現資源過載情況，可能出現在處理器或者內存，也可能兩者兼而有之。
我們需要一個再平衡系統去監測和發現高負荷運載的物理機，在系統資源飽和影響上層應用程序性能和業務之前遷走上面的工作負載，從而讓有過熱傾向的物理機回到正常狀態。
再平衡系統定義了兩種形式的任務：被動式 (Reactive) 和主動式 (Proactive)
被動再平衡 (Reactive)
針對這種任務，再平衡系統定義了三種形式的報警策略：
i CPU 過載 — 閾值設定為範化的 15 分鐘 CPU 負載 (normalized cpu load15) >= 0.7, 0.7 是基於 eBay 線上大規模應用性能的統計經驗值;
ii 內存過載— 和 CPU 提供給實例的是使用時間不同， 內存提供的是使用空間，所以內存是計算資源中最不具有彈性的資源，這意味著內存的使用大小基本上是不可壓縮的， 因為它是有狀態的，申請資源慢，並且基本上不可能被回收。 基於安全原因的考慮， 我們需要保留一定的安全內存緩衝 (safety memory buffer), 從而保證任何時候虛擬機實例向物理機申請內存都能夠成功，所以我們用到的最小可用內存閾值是物理機總內存的 10%;
iii Swap— swap 的觸發意味著可能存在內存的慢速訪問，極有可能會影響上層應用程序的性能進而影響業務。
再平衡系統會週期性地查詢物理服務器性能指標，以檢查是否有過載傾向。如果服務器有過載的傾向，系統會產生一個報警消息併發送到消息隊列裡;
多個工作進程會監聽消息隊列，拿到消息隊列後會從其他的配置系統裡獲取其他數據，包括服務器具體的性能指標，從 KVM 角度觀察到的虛擬機性能指標，虛擬機、資源池以及應用服務的配置信息;
基於上述收集到的數據，再平衡系統會做出綜合決策，挑選出一個或者多個虛擬機並且通過調用 PaaS 層的 API 來完成虛擬機的遷移，從而減輕物理服務器的工作負載保證其在安全範圍之內。
由於內存是最不具彈性的計算資源，並且我們持續的優化內存去提高利用率，在這種情況下，物理服務器的可用內存就成為了一個關鍵指標，所以我們定義了兩級內存報警：警告 (warning) 和危險 (Critical)。一旦可用內存低於警告 (warning) 閾值， 再平衡系統會挑選出一個或者多個虛擬機並調用 PaaS API 來遷移。但是這個遷移過程需要一定的時間，如果在此期間可用內存持續快速減少並達到危險 (Critical) 閾值，再平衡系統會基於一定的安全策略從中挑選一個雲原生 (CloudNative) 屬性的虛擬機強制關機，從而保證該物理服務器上的其他虛擬機性能不受影響。
主動再平衡 (Proactive)
基於實際觀測到的數據，當物理服務器規模足夠大時，它們實際的計算資源使用率基本上服從正態分佈，尤其是 CPU 使用率，如下圖所示：
除了上文中提到的被動再平衡任務，再平衡系統也會週期性地掃描所有的雲原生物理服務器實際的 CPU 和內存使用率，並從中挑選出前 2.5% 的物理服務器遷移上面的雲原生虛擬機，從而做到平衡雲原生物理服務器的負載。其中，2.5% 約等於正態分佈右側二級標準差 [2] 之外的數值。
四、灰度策略發佈
有云原生屬性的虛擬機實例主要分佈在標準 (Standard) 物理服務器上，我們標定了其中約 5000 臺服務器來實施安全內存優化。通過應用上文提到的改進的資源調度器將更多的虛擬機實例編排到這些物理服務器上並且不斷的將雲原生虛擬機編排到雲原生物理服務器上，同時用再平衡系統來保證應用程序的性能不會因為計算資源的超售受到影響。
在調整 CPU 和內存超售比例的過程中，我們採用灰度發佈和對數增長策略來保證每一步調整足夠的安全可靠，這意味著超售比例的每一次躍遷不會影響應用程序的性能，同時也不會引起再平衡系統的遷移風暴。
灰度發佈策略：
標定三臺雲原生物理服務器為一級目標機，調整其計算資源超售比例;
當一級目標機上的裝箱接近飽和並穩定運行一段時間後，對物理服務器以及其上運行的虛擬機和相關的應用程序做性能驗證;
如果上一步提到的性能驗證通過，會標定一個機架的物理服務器為二級目標機，調整其超售比例和一級目標機一致;
當二級目標機上的裝箱接近飽和並穩定運行一段時間後，對物理服務器以及其上運行的虛擬機和相關的應用程序做性能驗證;
如果二級目標機上的性能驗證通過，會把同樣的超售比例應用收到所有的 5000 臺雲原生物理服務器上;
進入下一輪超售比例調整。
總結
通過一系列的優化和調整，在不影響上層應用程序性能這一絕對安全的前提下，我們持續的提高 CPU 和內存的超售比例。
截止 2018 年底，CPU 的超售比例達到了 295%，內存達到了 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
基於此， 我們下調了 eBay 私有云的 2019 年的容量預算。
為了降低成本和提高效率，越來越多的企業把基礎設施遷移到雲端，不管是以公有云還是私有云的形式。
雲計算可以提供一定的靈活性，然而隨之也帶來了一些資源上的浪費。這是因為用戶傾向於高估 (overestimate) 對資源的需求，並且在申請資源之後會低效的使用資源 (underutilize)。各種分析表明業界的雲計算 CPU 使用率只有 6% 到 12%[1]。
eBay 有著巨大規模的雲計算基礎設施，任何一點微小的改善都將顯著地為數據中心節省成本。從 2018 年起，我們專注提高 eBay 私有云的使用效率。截止 2018 年底，eBay 雲計算 CPU 的超售比例達到 295%，內存達到 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
本文將分享我們如何通過如下步驟為 eBay 數據中心節省資源，旨在為同行帶來思考和借鑑：
一、監控和分析物理服務器的性能指標
二、改進 openstack 的資源調度器
三、建立動態再平衡系統
四、灰度策略發佈
一、監控和分析物理服務器的性能指標
eBay 私有云現在正在使用的 openstack 的計算模塊 Nova，本身並沒有記錄實際的計算資源使用情況。
所以我們的第一步是改進分佈在宿主機上的 Nova-Compute，從而保證可以收集並彙報實際的計算資源使用情況，特別是 CPU 和內存。
Nova 收集並彙報的計算資源使用情況，只能服務於 Nova 相關的子模塊，比如資源調度器。但是我們還需要有計算資源使用情況的全局視角，所以我們採用了基於 Elastic 的 metricbeat 解決方案，保證我們能夠收集到大量物理服務器的性能數據，同時也可以按需去做各種各樣的聚合方便我們去發現計算資源的使用特性。
二、改進 openstack 的資源調度器
安全的內存超售
集群資源管理系統的資源調度器一般是基於裝箱的。
比如，如果一個物理服務器有 300G 的內存，而一個虛擬機實例需要 10G 的內存，資源調度器將最多隻會調度 30 個實例到這臺物理機上。當然，為了簡化說明問題，我們這裡忽略了給物理機預留的內存，並且實際調度中會有更多維度的資源限制。
當我們有了足夠多的性能指標和裝箱數據後，我們發現物理服務器有著大量的可用內存資源，即使從裝箱角度來看他們已經接近飽和，因此我們針對內存引入了實際使用率 (AllocationRatio)的概念。
實際使用率 = 實際使用的內存 / 裝箱內存
eBay 私有云的物理服務器分為三種類型：標準 (Standard)、高內存性能 (High memory) 和大數據類型 (Big Data)。
標準機型主要運行著 Web 相關應用。以生產環境中運行的第五代物理服務器為例，實際使用率 (AllocationRatio) 的分佈如下圖所示，樣本總數約為 4000 臺，可以發現大多數服務器的實際使用率 (AllocationRatio) 主要分佈在 60% 到 90% 區間。
基於如上數據，如果我們希望提高物理服務器的資源使用率，尤其是內存資源，就需要進行安全的內存超售 (Safe Memory Oversubscription)。我們發現，安全的內存超售的理論最大值基本上約等於實際使用率 (AllocationRatio) 的倒數。之所以用“約等於” ，是因為我們需要考慮到物理服務器作為虛擬機宿主機的內存消耗以及安全的內存緩衝 (safety memory buffer)。
比如，如果一個虛擬機在創建的時候申請了 10G 內存，但是在整個生命週期中只使用了 7G 內存，我們就可以說這臺虛擬機的實際內存使用率為 7/10=0.7。同時，我們也可以計算物理服務器的實際使用率 (AllocationRation)。
為簡單起見，我們假設所有的虛擬機都符合前面提到的情況，並且物理服務器本身的內存使用為 10G，那麼物理服務器的內存使用率為 (7*30+10)/300= 73.3%，此時安全超售的理論最大支持為 1/0.73=1.36，也就是說我們還可以在這臺物理服務器上再編排接近 10 個同樣大小的虛擬機。考慮到真實生產環境中的風險以及內存緩衝 (safety memory buffer), 我們不能做到如此激進。
雲原生親和性
我們將 eBay 私有云上運行的虛擬機實例按照是否可以自由遷移以及遷移的時間成本分為三類：
雲原生 (CloudNative) ：可遷移，遷移成本小於 1 小時
準雲原生 (Quasi-CloudNative) ：可遷移，遷移成本大於一小時
非雲原生 (NonCloudNative)：不可遷移
集群資源管理系統的調度器在編排資源時的策略一般可以分為兩種：平鋪 (Spread) 和堆疊 (Stack)。** 平鋪 (Spread)可以滿足上層應用程序對於容錯域 (Fault Domain)的需求從而可以保證應用程序的可用性。容錯域代表出錯的一個物理單元，在 eBay 內部特指共享物理交換機、電源等設備的一組物理服務器，通常是半個或者整個機架。堆疊 (Stack)** 可以提高服務器的利用率，因為對於新的資源編排請求，堆疊總是優先把資源聚集到高負載的服務器，而不是那些空閒服務器。
OpenStack 默認採用的是平鋪 (Spread) 策略，本質上不利於提高物理服務器的利用率。我們採取的方法是在不影響上層應用程序對於容錯域需求的情況下，將物理服務器劃分為雲原生和非雲原生兩類。由於一些特定的原因，我們只能找到很少全是雲原生虛擬機的物理服務器，所以我們將雲原生物理服務器的標準放寬為其上運行的雲原生虛擬機實例個數大於 N, N 值是動態調整的。在完成物理服務器的分類和標定之後，我們進一步改進了 Nova-Scheduler 的編排策略，實現了：
儘量把雲原生 (CloudNative) 屬性的虛擬機編排到雲原生物理服務器上，從而實現雲原生虛擬機的聚集效應，提高雲原生物理服務器的計算資源利用率 ;
禁止準雲原生 (Quasi-CloudNative) 和非雲原生 (NonCloudNative) 屬性的虛擬機請求編排到雲原生物理服務器上，從而保證下文提到的動態再平衡系統可以在系統有過載傾向時可以介入並能正常工作。
三、動態再平衡系統
隨著我們通過上述的超售方式把越來越多的虛擬機實例放到物理機上，不可避免地會出現資源過載情況，可能出現在處理器或者內存，也可能兩者兼而有之。
我們需要一個再平衡系統去監測和發現高負荷運載的物理機，在系統資源飽和影響上層應用程序性能和業務之前遷走上面的工作負載，從而讓有過熱傾向的物理機回到正常狀態。
再平衡系統定義了兩種形式的任務：被動式 (Reactive) 和主動式 (Proactive)
被動再平衡 (Reactive)
針對這種任務，再平衡系統定義了三種形式的報警策略：
i CPU 過載 — 閾值設定為範化的 15 分鐘 CPU 負載 (normalized cpu load15) >= 0.7, 0.7 是基於 eBay 線上大規模應用性能的統計經驗值;
ii 內存過載— 和 CPU 提供給實例的是使用時間不同， 內存提供的是使用空間，所以內存是計算資源中最不具有彈性的資源，這意味著內存的使用大小基本上是不可壓縮的， 因為它是有狀態的，申請資源慢，並且基本上不可能被回收。 基於安全原因的考慮， 我們需要保留一定的安全內存緩衝 (safety memory buffer), 從而保證任何時候虛擬機實例向物理機申請內存都能夠成功，所以我們用到的最小可用內存閾值是物理機總內存的 10%;
iii Swap— swap 的觸發意味著可能存在內存的慢速訪問，極有可能會影響上層應用程序的性能進而影響業務。
再平衡系統會週期性地查詢物理服務器性能指標，以檢查是否有過載傾向。如果服務器有過載的傾向，系統會產生一個報警消息併發送到消息隊列裡;
多個工作進程會監聽消息隊列，拿到消息隊列後會從其他的配置系統裡獲取其他數據，包括服務器具體的性能指標，從 KVM 角度觀察到的虛擬機性能指標，虛擬機、資源池以及應用服務的配置信息;
基於上述收集到的數據，再平衡系統會做出綜合決策，挑選出一個或者多個虛擬機並且通過調用 PaaS 層的 API 來完成虛擬機的遷移，從而減輕物理服務器的工作負載保證其在安全範圍之內。
由於內存是最不具彈性的計算資源，並且我們持續的優化內存去提高利用率，在這種情況下，物理服務器的可用內存就成為了一個關鍵指標，所以我們定義了兩級內存報警：警告 (warning) 和危險 (Critical)。一旦可用內存低於警告 (warning) 閾值， 再平衡系統會挑選出一個或者多個虛擬機並調用 PaaS API 來遷移。但是這個遷移過程需要一定的時間，如果在此期間可用內存持續快速減少並達到危險 (Critical) 閾值，再平衡系統會基於一定的安全策略從中挑選一個雲原生 (CloudNative) 屬性的虛擬機強制關機，從而保證該物理服務器上的其他虛擬機性能不受影響。
主動再平衡 (Proactive)
基於實際觀測到的數據，當物理服務器規模足夠大時，它們實際的計算資源使用率基本上服從正態分佈，尤其是 CPU 使用率，如下圖所示：
除了上文中提到的被動再平衡任務，再平衡系統也會週期性地掃描所有的雲原生物理服務器實際的 CPU 和內存使用率，並從中挑選出前 2.5% 的物理服務器遷移上面的雲原生虛擬機，從而做到平衡雲原生物理服務器的負載。其中，2.5% 約等於正態分佈右側二級標準差 [2] 之外的數值。
四、灰度策略發佈
有云原生屬性的虛擬機實例主要分佈在標準 (Standard) 物理服務器上，我們標定了其中約 5000 臺服務器來實施安全內存優化。通過應用上文提到的改進的資源調度器將更多的虛擬機實例編排到這些物理服務器上並且不斷的將雲原生虛擬機編排到雲原生物理服務器上，同時用再平衡系統來保證應用程序的性能不會因為計算資源的超售受到影響。
在調整 CPU 和內存超售比例的過程中，我們採用灰度發佈和對數增長策略來保證每一步調整足夠的安全可靠，這意味著超售比例的每一次躍遷不會影響應用程序的性能，同時也不會引起再平衡系統的遷移風暴。
灰度發佈策略：
標定三臺雲原生物理服務器為一級目標機，調整其計算資源超售比例;
當一級目標機上的裝箱接近飽和並穩定運行一段時間後，對物理服務器以及其上運行的虛擬機和相關的應用程序做性能驗證;
如果上一步提到的性能驗證通過，會標定一個機架的物理服務器為二級目標機，調整其超售比例和一級目標機一致;
當二級目標機上的裝箱接近飽和並穩定運行一段時間後，對物理服務器以及其上運行的虛擬機和相關的應用程序做性能驗證;
如果二級目標機上的性能驗證通過，會把同樣的超售比例應用收到所有的 5000 臺雲原生物理服務器上;
進入下一輪超售比例調整。
總結
通過一系列的優化和調整，在不影響上層應用程序性能這一絕對安全的前提下，我們持續的提高 CPU 和內存的超售比例。
截止 2018 年底，CPU 的超售比例達到了 295%，內存達到了 118%，最終為標準型物理服務器貢獻出額外的超過 300TB 的內存容量。這相當於 1000 多臺最新型的標準服務器。
基於此， 我們下調了 eBay 私有云的 2019 年的容量預算。
與此同時，我們也大幅提高了計算資源的實際使用率，尤其是 CPU 和內存，如圖所示，從 2018 年 5 月到 2018 年 12 月，實際的內存使用率從48%提高到了68%，增幅約為42%;實際的 CPU 使用率從12%提到了29%，增幅約為142%，其中的峰值數據來自於十一月初的黑五大促前後。