為解決上述挑戰，我們設計了彈性計算技術架構下圖所示，其中：
➡ 接入層：負責提供服務化介面，包括服務訪問，服務配置，顯像管理等；
➡ 排程層：通過名字服務遮蔽多樣易變資源，實現負載均衡，擴縮容排程，故障排程，錯峰排程，灰度變更等能力；
➡ 節點層：實現資源隔離，衝突檢測，容器管理監控等機制，供上層使用；
下面針對關鍵挑戰詳細描述技術解決方案。
為監控業務計算延時，我們引入了cpi（cycles-per-instruction）監控，簡單來說，cpi = cpu週期數/cpu指令數，cpi放映了業務整體的指令執行延時，如下圖所示，通過歷史資料可提煉合理的cpi標準值及方差值，監控當前實際值，對比模型來判斷業務計算延時是否正常。這個值與業務指令模型（主要是訪存指令的比例等）及cpu型號相關，故需區分業務模組及cpu型號建模。
無共享共享優化前
共享優化後
優化效果
平均延時 ms
1.59
1.65
1.62
1.8%
最大延時 ms
23.85
29.67
23.79
19.8%
毛刺數19768
本節主要從篩選業務提供場景式服務，封裝資源的多樣與易變性及更上層的服務介面三方面闡述。
計算優先順序
場景舉例
資源型別
上傳壓縮
資源規格固定，排程少
資源規格固定，排程較多
離線計算型
ai/日誌計算
資源規格不固定，排程多
cpu效能
intel e3-1230v2
1.00
intel x3440
0.57
intel e5-2680v4
0.92
......
我們採用了cl5名字服務來遮蔽彈性資源的多樣易變性，如下圖所示，使用者只看到服務名字，無須關心背後繫結的資源及權重動態變化，擴縮容，衝突排程，錯峰排程，灰度排程時修改資源的繫結，權重排程修改資源的權重，如下表所示：
權重的設定如下表所示，綜合考慮資源規格（核心數），資源能力（效能基準值），可用配額（quota）等設定總權重，並記錄單核權重作為負載均衡參考。
容器 id
核數效能
quota
單核權重
總權重1
在建設彈性計算平台實踐過程中，我們有一些經驗教訓，在這裡和大家分享下。
➡故事1：a業務利用率擴縮容閾值設定不合理，高峰期保留大量資源沒充分利用；b業務設定很合理，高峰期確沒資源擴容了。---讓使用者自身做策略，難以達到整體最優，造成業務間資源利用不均衡，老實人反而容易吃虧；
➡故事2：平台預設開啟自動擴縮容，自動調配資源；a業務對自動擴縮容機制不知情，發起了版本變更，造成現網多版本共存。---平台來做策略，難以了解完整業務流程，可能影響業務的可用性；
在提供機制或策略的選擇上我們有過反覆，對於平台方，最理想的是將策略控制起來，以達到整體資源排程的最優化，但這裡需要乙個前提，平台能夠收攏所有業務變更入口，如果做不到閉環，只能優先保障業務可用性，平台提供機制，由業務方自身實現策略，平台方通過其它手段，比如定期公布低負載業務，推動業務方主動關注資源高效利用。
擴縮容的目標在於將計算型業務維持在合理的負載，以實現質量和成本的均衡，但如果業務負載不均衡，擴縮容難以達到預期的效果，如下圖所示：
從這個例子，我們得到的經驗是，底層技術要選擇最簡單，主流，被大家廣為認可的，而不是存僥倖心理選擇在當前條件下最容易實現的方案。另外由於底層故障修復代價過大，在規模上線前，最好配備熱補丁修復能力，以在底層故障出現時低成本的修復問題。
ucloud的彈性計算
ucloud的彈性計算現在看基本未成型，但是看現在的資料，也許能實現。ucloud現在主機也可以按小時租用。但是頻寬還不是按流量使用。雖然ucloud支援共享頻寬，但是在彈性計算對頻寬有需求時就麻煩了 ucloud最小頻寬單位是2m，諮詢了一下業務，當核打滿時頻寬可能大於1m單不會超過2m，所以正合...
監控有空閒資源的GPU並傳送郵件
import getpass import re import smtplib import socket import subprocess import time from email.mime.text import mimetext import numpy as np deflogin e...
基於LAN的資源共享
最近在積極思考final year project的內容，一方面想做點和實際相關的內容，一方面又想接觸技術層面多些。這幾周不能說整天查資料在找題目，至少經常brain storm一下。真的把這個題目做好也不錯，不過神經網路不是我的長項，甚至只是耳聞，沒做過一點細緻接觸。所以我又想到另乙個題目。基於l...