云計算底層架構(gòu)挑戰(zhàn)（二）

時間：2023-03-13 05:26:01 | 來源：電子商務(wù)

時間：2023-03-13 05:26:01 來源：電子商務(wù)

3 云場景的底層軟硬件挑戰(zhàn)

3.1 業(yè)務(wù)異構(gòu)加速

我們分析一下用戶業(yè)務(wù)從無到有再到大規(guī)模發(fā)展的過程中對云主機的需求。一開始的時候，可能并不清楚要運行的業(yè)務(wù)具有什么樣的特征，這樣通用的以CPU為計算核心的通用云主機會是比較合適的選擇。隨著業(yè)務(wù)的進一步開展，業(yè)務(wù)場景相對穩(wěn)定以后，用戶對自己的業(yè)務(wù)也非常熟悉了之后，用戶可能會傾向于針對不同的業(yè)務(wù)選擇不同的主機類型，例如針對HPC選擇計算優(yōu)化型，針對大型數(shù)據(jù)集處理選擇內(nèi)存優(yōu)化型等等。進一步的，不僅僅業(yè)務(wù)場景固定，并且計算資源的規(guī)模足夠大，就有了進一步通過硬件加速來提升性能并且降低成本的訴求。

隨著人工智能技術(shù)的蓬勃發(fā)展，基于GPU加速的機器學習訓練及推理得到大規(guī)模應(yīng)用。GPU加速當前主要應(yīng)用的領(lǐng)域有機器/深度學習、高性能計算、計算流體動力學、計算金融學、地震分析、語音識別、無人駕駛汽車、藥物發(fā)現(xiàn)、推薦引擎、預(yù)測、圖像和視頻分析、高級文本分析、文檔分析、語音、對話式代理、翻譯、轉(zhuǎn)錄和欺詐檢測等。

基于FPGA的加速，因為能夠定制加速核心的設(shè)計，一般相對GPU來說，具有更高的加速效率，缺點在于硬件編程的技術(shù)難度和工作量。因此，基于FPGA的加速主要是以FaaS（FPGA as a Service）平臺的模式出現(xiàn)，由Xilinx、Intel或其他供應(yīng)商提供底層的FPGA軟硬件支持，把FPGA封裝成標準的平臺，一些第三方ISV基于標準的平臺開發(fā)針對一些主流應(yīng)用場景的特定的加速核心。在云計算數(shù)據(jù)中心大規(guī)模服務(wù)的支持下，F(xiàn)aaS既有了硬件加速的高效，又有了云計算的彈性特征，因此在一些特定領(lǐng)域得到廣泛的應(yīng)用。

異構(gòu)加速的實現(xiàn)架構(gòu)是CPU+GPU/FPGA，主要由CPU完成不可加速部分的計算以及整個系統(tǒng)的控制調(diào)度，由GPU/FPGA完成特定任務(wù)的加速。這種架構(gòu)面臨一些挑戰(zhàn)：

l 可加速部分占整個系統(tǒng)的比例有限；

l 因為數(shù)據(jù)來回搬運的影響，很多場景整體加速效率不明顯；

l 額外的GPU/FPGA加速卡導致成本增加；

l 異構(gòu)加速引入新的實體，計算由一個實體完成變成兩個或多個實體協(xié)作完成，這導致整個系統(tǒng)復(fù)雜度增加；

l GPU、FPGA都有很多種不同的平臺，例如NVIDIA GPU的CUDA、Xilinx FPGA的SDAccel、Intel的Accelerator Stack等，這對云計算的硬件成本及運維管理形成挑戰(zhàn)；

l 雖然底層軟硬件供應(yīng)商已經(jīng)為自己硬件平臺封裝了非常強大并且用戶友好的開發(fā)和應(yīng)用框架，但當面對一個新領(lǐng)域的時候，底層距離業(yè)務(wù)級的用戶還是太遠，用戶自己開發(fā)底層軟硬件的難度依然很大。

3.2 工作任務(wù)卸載

在虛擬化的架構(gòu)里，系統(tǒng)簡單的可以分為兩層，Guest層和Host層，Guest層是用戶業(yè)務(wù)層，Host層是后臺管理層。Host層的主要工作任務(wù)是虛擬化管理、IO的后臺處理以及相關(guān)的監(jiān)控、操作和管理等。

在這些Host層的工作任務(wù)里，最消耗CPU資源的是IO后臺工作任務(wù)的處理，如網(wǎng)絡(luò)的VPC、分布式存儲等。Intel在Xeon CPU上做過網(wǎng)絡(luò)OVS的性能測試：64字節(jié)數(shù)據(jù)包流，消耗四個CPU內(nèi)核，通過DPDK加速的OVS，最佳性能是8-9 Mpps，帶寬為4.6Gbps。隨著網(wǎng)絡(luò)帶寬逐漸升級到25G、50G甚至100G，DPDK加速OVS的CPU開銷將無法承受。將10-15個甚至更多的CPU核專門用于數(shù)據(jù)包處理，意味著沒有多少剩余的CPU核可以用于用戶的業(yè)務(wù)。在服務(wù)器上運行的VM或容器越多，CSP賺到的錢就越多。如果為DPDK-OVS分配大量CPU核，那么在服務(wù)器上啟動的VM數(shù)量將減少，從而降低收入。

Host的其他的工作任務(wù)，或多或少也都會占用CPU資源，存在跟用戶業(yè)務(wù)爭搶資源的問題，最好都能夠卸載到硬件設(shè)備。把盡可能多的CPU資源出售給用戶業(yè)務(wù)，來賺取更多的收入。虛擬化Hypervisor包括vCPU的調(diào)度、虛擬設(shè)備模擬、熱遷移、虛擬機管理等，虛擬化的卸載比較復(fù)雜，因為涉及到云計算底層軟硬件架構(gòu)的重構(gòu)。

工作任務(wù)卸載跟業(yè)務(wù)異構(gòu)加速有很多異同點。相同點在于本質(zhì)都是通過硬件加速來提升性能，并且都需要軟件的協(xié)同工作。區(qū)別在于工作任務(wù)卸載不是局部算法加速，是整體卸載，把所有的處理都放在硬件中實現(xiàn)。

工作任務(wù)卸載一般不希望改變現(xiàn)有云計算軟件，希望做到跟現(xiàn)有軟件系統(tǒng)兼容。工作任務(wù)卸載最大的挑戰(zhàn)在于如何做好軟硬件分離，如何更好的把軟硬件功能和接口劃分清楚，能夠做到在不修改硬件數(shù)據(jù)面處理的情況下，軟件依然能夠快速迭代升級。工作任務(wù)卸載由硬件負責數(shù)據(jù)面，軟件負責控制面，達到硬件的高效和軟件的靈活相統(tǒng)一。

3.3 軟硬件接口的標準化和彈性

何謂軟硬件接口？就是我們通常所說的IO設(shè)備接口。我們通過IO設(shè)備接口在軟件和硬件之間傳輸數(shù)據(jù)，這些數(shù)據(jù)會在軟件中處理，也會在硬件中處理，而IO設(shè)備接口就承擔了軟件和硬件之間的通信接口的角色，因此我們也稱之為軟硬件接口。

軟硬件接口的標準化

數(shù)據(jù)中心大規(guī)模管理以及業(yè)務(wù)遷移的需要，為了降低復(fù)雜度和提高穩(wěn)定性，云計算平臺的一個重要要求就是基于“無差別的一致性的硬件平臺”。通常是通過虛擬化技術(shù)把底層有差別的不一致的硬件的特性給抹平，給VM提供一個無差別的一致的虛擬硬件服務(wù)器。

完全硬件虛擬化技術(shù)導致這一要求非常難以滿足。我們通過硬件虛擬化技術(shù)把CPU里的處理器和內(nèi)存訪問直接暴露給VM，因為主流的服務(wù)器都是x86架構(gòu)的關(guān)系，我們依然可以說是無差別的一致性的CPU處理器和內(nèi)存。但是，讓我們通過Pass Through和SR-IOV等技術(shù)把硬件設(shè)備完全暴露給VM的時候，問題出現(xiàn)了。同一類設(shè)備，不同的供應(yīng)商的接口完全不同，需要加載不同的驅(qū)動。即使是同一個供應(yīng)商，也可能因為產(chǎn)品升級換代的原因，不同的兩代產(chǎn)品之間接口無法完全兼容。

所有，當前云計算場景的IO虛擬化技術(shù)依然是以類虛擬化技術(shù)為主，這不可避免的會影響到IO的性能。隨著網(wǎng)絡(luò)、存儲等大帶寬、高性能的發(fā)展趨勢，類虛擬化技術(shù)越來越成為影響IO性能的瓶頸。

為了既支持標準化的接口，又能夠保證完全硬件虛擬化的IO設(shè)備性能，云計算廠家更傾向于公開的、高效的、標準的，并且過去、現(xiàn)在和未來都會廣泛使用的設(shè)備接口。例如，AWS的網(wǎng)絡(luò)設(shè)備接口選擇了ENA、存儲選擇了NVMe。

軟硬件接口的彈性

IO硬件虛擬化，希望很多虛擬的設(shè)備共享一個物理的設(shè)備。這些設(shè)備既可以是同類型的，也可以是不同類型的。物理的硬件接口可以根據(jù)實際的需求彈性的配置，這些彈性體現(xiàn)在：

l 接口的類型彈性。我們可以根據(jù)不同的場景，配置每個物理接口上需要虛擬的多個不同類型的接口。比如既可以是網(wǎng)絡(luò)類型的接口，也可以是存儲類型的接口，也可以是網(wǎng)絡(luò)類型和存儲類型共存的接口。當然了，也可以是很多其他不同接口類型或接口類型集合。

l 并且每一種類型，還可以再靈活的配置同類型虛擬設(shè)備的數(shù)量；

l 接口的性能彈性。比如是網(wǎng)絡(luò)接口，我們可以靈活配置不同的網(wǎng)絡(luò)的最大帶寬、網(wǎng)絡(luò)包處理的最大PPS值等。而如果是存儲接口的話，我們可以靈活配置不同的最大存儲吞吐量和IOPS等。

3.4 硬件處理的虛擬化和個性化

云計算場景很大的一個挑戰(zhàn)是多租戶，當我們把Host層的工作任務(wù)從軟件轉(zhuǎn)移到硬件處理，就意味著硬件需要實現(xiàn)虛擬化功能來支持多租戶。通過PCIe SR-IOV以及多隊列（Multi-Queue）技術(shù)實現(xiàn)了更細粒度的接口完全硬件虛擬化，在硬件內(nèi)部，同樣需要支持完全硬件虛擬化的“多隊列”，實現(xiàn)邏輯上分離的硬件處理引擎，一一對應(yīng)于每一個隊列的處理。

很多硬件里支持多通道（Multi-Channel）技術(shù)，硬件處理的虛擬化跟多通道有點類似，但又不完全相同。就像我們服務(wù)器虛擬化可以虛擬出各種不同資源配置不同工作處理的虛擬機一樣，硬件處理的虛擬化同樣需要在隊列粒度的層級上實現(xiàn)不同隊列的個性化處理。例如塊存儲場景可能會有數(shù)據(jù)壓縮、加密、備份等需求，網(wǎng)絡(luò)場景有IPSec、新的網(wǎng)絡(luò)轉(zhuǎn)發(fā)協(xié)議的需求，但并不是所有的用戶都有同樣的訴求，不同的用戶的需求可能千差萬別，甚至同一個用戶的不同實例，需求也不一樣。這意味著要實現(xiàn)隊列粒度的、有狀態(tài)的、虛擬化、個性化的硬件處理。

3.5 業(yè)務(wù)和管理物理分離

后臺管理層的工作任務(wù)卸載，一般只是卸載部分后臺任務(wù)；即使卸載的工作任務(wù)，也主要是卸載數(shù)據(jù)面的處理，以此來減少絕大部分的CPU資源消耗，控制面的處理依然還是要運行在后臺Host層。而業(yè)務(wù)和管理物理分離則更加徹底，完全的把后臺管理轉(zhuǎn)移到了新的硬件設(shè)備，把CPU完全的交付給用戶業(yè)務(wù)使用。業(yè)務(wù)和管理分離的訴求一方面來自于后端管理和用戶業(yè)務(wù)之間的相互影響，另一方面來自于安全管理，還有一方面來自于用戶獨占物理服務(wù)器的需求。

云計算基于虛擬化的多租戶環(huán)境下，用戶業(yè)務(wù)和后臺的管理共存于一個服務(wù)器軟件系統(tǒng)里。不僅僅是用戶之間可能會因為資源搶占而相互影響，后端管理和用戶業(yè)務(wù)之間也會形成影響。這種影響體現(xiàn)在兩方面：

l 虛擬化管理可能對共存于同一個硬件服務(wù)器的業(yè)務(wù)實例造成影響。例如熱遷移，如果我們不想讓熱遷移影響到業(yè)務(wù)實例的性能，勢必增加整體遷移持續(xù)的時間，但這樣會降低熱遷移的效率，并且影響到了業(yè)務(wù)實例高可用的體驗；如果盡可能的減少整體遷移持續(xù)時間，勢必對其他業(yè)務(wù)實例性能產(chǎn)生影響。

l 前面我們講到了后臺工作負載會占用CPU資源。例如網(wǎng)絡(luò)VPC，當某個業(yè)務(wù)有突發(fā)的大流量網(wǎng)絡(luò)訪問的時候，因為后臺網(wǎng)絡(luò)VPC工作負載本質(zhì)是數(shù)據(jù)面的處理，因此也會等比例的增加CPU資源消耗。這也會對業(yè)務(wù)實例性能造成影響。

云計算多租戶復(fù)雜的環(huán)境都共同運行于一個環(huán)境里，勢必增加比較大的安全風險。一方面是操作系統(tǒng)或虛擬化管理潛在的漏洞，可能會被別有用心之人利用；另一方面，云計算運營管理存在人為失誤的可能，這樣就會影響到用戶實例。

有一些客戶有物理機實例的需求，例如一些HPC的場景，性能敏感，即使非常少量的性能損耗也不可接受；例如一些企業(yè)用戶，之前已經(jīng)有自己的一套企業(yè)級的虛擬化環(huán)境，大量的虛機運行于這些企業(yè)級的虛擬化環(huán)境，用戶遷移到云的時候，考慮更多的兼容性的問題，希望是物理機的服務(wù)器，不改動底層的虛擬化環(huán)境，整體遷移到云計算環(huán)境。物理機實例的需求對云計算運行環(huán)境提出了非常大的挑戰(zhàn)，例如：

l 我們很難把網(wǎng)絡(luò)VPC、分布式存儲等后臺IO工作負載添加到用戶的業(yè)務(wù)實例里；

l 無法實現(xiàn)物理機實例的高可用，因為物理機無法遷移；

l 面臨很多IO接口不一致的問題。

3.6 硬件的功能擴展

通過軟件處理一個任務(wù)，相對硬件會具有非常好的靈活性；而硬件處理通常具有更好的處理性能，與此同時靈活性會變差。當硬件處理一旦確定，就很難再更改，也意味著很難再加入新的功能。

傳統(tǒng)的SOC芯片里，通常會集成參與數(shù)據(jù)面處理的高性能處理器，這樣，可以通過加入軟件處理的方式實現(xiàn)功能擴展。但這樣的方式會存在性能瓶頸問題，云計算場景對處理的帶寬、延遲、OPS（Operations per Second）等非常敏感，基于軟件的性能擴展并不是很好的解決辦法。

硬件處理加入的延遲非常有限，幾乎可以忽略，而帶寬、OPS還能夠保持一致。因此，加入獨立的擴展硬件處理來進行功能的擴展會是一個比較好的辦法。而硬件功能擴展面臨如下一些挑戰(zhàn)：

l 硬件部分可編程。通過FPGA可以支持硬件可編程，但如果完全的基于FPGA實現(xiàn)所有的硬件處理，勢必又得不償失。因為同樣的硬件邏輯基于FPGA的實現(xiàn)比基于ASIC的實現(xiàn)性能更差，成本更高。因此必然是ASIC和FPGA一起的混合體。比如我們把80%的功能ASIC實現(xiàn)，把20%的功能FPGA實現(xiàn)。

l 接口標準化。固定的硬件處理需要給擴展的硬件處理提供標準的數(shù)據(jù)輸入輸出接口，擴展的硬件處理需要有標準的配置接口等。

l 功能擴展平臺化。與基于FPGA的硬件加速平臺類似，需要把支持擴展的整個架構(gòu)平臺化，這樣才能比較方便高效的加入擴展的功能。

3.7 讓硬件快速迭代

Tick-Tock是英特爾的芯片技術(shù)發(fā)展的戰(zhàn)略模式，也稱為嘀嗒模式。在Tick年，設(shè)計微架構(gòu)不變，通過改進制造工藝來提升CPU的性能；而在Tock年，則相反，是制造工藝不變，通過設(shè)計全新的處理器微架構(gòu)來提升CPU性能。通過這種方式，既能穩(wěn)妥的讓制造工藝和微架構(gòu)設(shè)計相互印證，又能夠把兩年迭代一代處理器變成一年迭代一次。

我們常見的5層網(wǎng)絡(luò)模型，在一般情況下網(wǎng)絡(luò)協(xié)議棧各層分別實現(xiàn)在硬件、內(nèi)核態(tài)軟件和用戶態(tài)軟件。物理層和網(wǎng)絡(luò)鏈路層是由以太網(wǎng)和802.11標準所定義的，比較穩(wěn)定，因此物理層和網(wǎng)絡(luò)鏈路層一般實現(xiàn)在硬件里；網(wǎng)絡(luò)層和傳輸層作為系統(tǒng)共用的組件，一般是作TCP/IP協(xié)議棧集成在操作系統(tǒng)內(nèi)核里；而應(yīng)用層的任務(wù)則一般交給用戶態(tài)的程序去實現(xiàn)。

上述這些范例給我們提供了一些思路。如果我們把系統(tǒng)實現(xiàn)按照硬件ASIC、可編程FPGA、底層系統(tǒng)棧、上層應(yīng)用四類。在硬件這里，我們用硬件ASIC實現(xiàn)一些基礎(chǔ)架構(gòu)和路徑，ASIC可以2年左右周期一次迭代；FPGA大概可以半年左右一次迭代，那么在以ASIC為基礎(chǔ)的硬件整個生命周期里，我們可以迭代大概4版硬件。通過快速的硬件迭代，可以最大限度的發(fā)揮硬件的價值。并且，在下一版本的ASIC迭代里，我們會把一些成熟的硬件邏輯從FPGA卸載到ASIC里，實現(xiàn)硬件里的“卸載”。

硬件快速迭代最大的挑戰(zhàn)在于，如何能夠像軟件系統(tǒng)分層那樣，構(gòu)建分層的硬件系統(tǒng)架構(gòu)，設(shè)計好各個分層的功能，并且定義好標準的、清晰的、簡潔的層間接口。

3.8 硬件高可用

對于云計算服務(wù)來說，可用性是非常重要的指標。例如AWS的SLA保證在一個區(qū)域內(nèi)，EC2和EBS的月度正常運行時間百分比至少達到99.99%。前面提到了，因為規(guī)模的影響，單點的故障在規(guī)模的影響下，每天都會發(fā)生數(shù)百起。主流的互聯(lián)網(wǎng)系統(tǒng)都是基于大規(guī)模服務(wù)器集群構(gòu)建，單點的故障會導致非常嚴重的問題。軟件層面通過非常復(fù)雜的技術(shù)去保證高可用，例如虛擬機Live Migration、主備切換、負載均衡、分布式存儲等。而更直接的做法，還是要想辦法在硬件層面實現(xiàn)高可用：

l 提升硬件穩(wěn)定性。ASIC芯片的初始成本很高，芯片公司只有大規(guī)模提升單款芯片的銷售數(shù)量，才能最大限度的實現(xiàn)銷售收入。為了提升數(shù)量，就需要讓產(chǎn)品適應(yīng)盡可能多的場景。這是一個非常有挑戰(zhàn)的事情，即使芯片經(jīng)過充分的驗證測試，卻依然很難保證能夠完全適應(yīng)千奇百怪的各種應(yīng)用場景。而現(xiàn)在很多互聯(lián)網(wǎng)公司自己做硬件，不但不需要應(yīng)付各種各樣的應(yīng)用場景，還能夠用實際的業(yè)務(wù)環(huán)境的灰度機制來做好壓力測試，效果會好很多。

l 多路獨立硬件資源。我們可以通過一定的機制，把多路硬件資源當做一個整體，共同服務(wù)于上層軟件，當其中有部分資源故障的時候，依然可以為上層軟件提供一定程度的可用性。

l 快速故障檢測和自重啟恢復(fù)。因為多租戶的影響，需要構(gòu)建基于硬件虛擬化粒度的故障檢測和恢復(fù)機制。

l 硬件可在線可升級。我們可以通過FPGA的可現(xiàn)場編程特性，不斷的優(yōu)化硬件設(shè)計，提高硬件的穩(wěn)定性。

3.9 系統(tǒng)整合

前面我們提到了云場景面臨的這么多的底層軟硬件挑戰(zhàn)，其實最大的挑戰(zhàn)是如何把應(yīng)對這些挑戰(zhàn)的解決方案整合到一起。我們希望盡可能在不改變上層軟件訪問方式和風格的基礎(chǔ)上，潤物細無聲的優(yōu)化底層軟硬件架構(gòu)，來達到性能、成本、管理和用戶易用性等方面的統(tǒng)一。我們希望這些方案能夠跟云計算，特別是IaaS層，的服務(wù)結(jié)合起來，通過一些具體的底層軟硬件優(yōu)化來實現(xiàn)價值的快速落地。我們需要在底層軟件棧、芯片、板卡、服務(wù)器、交換機和基礎(chǔ)的物理/虛擬網(wǎng)絡(luò)架構(gòu)，以及IaaS/PaaS/Saas層云服務(wù)和云計算系統(tǒng)運行管理，甚至機柜、電源、散熱、DC管理等基礎(chǔ)設(shè)施層面，統(tǒng)籌的考慮這些挑戰(zhàn)。我們需要更多的底層軟硬件創(chuàng)新，來迎接互聯(lián)網(wǎng)未來快速發(fā)展的挑戰(zhàn)。