1.云計(jì)算

根據(jù)官方提供的資料“云計(jì)算就是指通過互聯(lián)網(wǎng)，以按需服務(wù)的形式提供計(jì)算資源。這樣企業(yè)就無需自行采購、配置或管理資源，而且只需要為實(shí)際使用的資源付費(fèi)?！焙芎美斫??？偨Y(jié)一句話就是說：云服務(wù)商有多種資源，根據(jù)客戶需求，把相應(yīng)資源租給客戶使用。這就是云計(jì)算。

云計(jì)算也包含了很多種：

如果把云服務(wù)商的所有資源比做成一個(gè)資源池，如圖1所示

1.1 公有云

公有云就是將資源池所有的資源都放在一起，一起來給客戶使用。但是客戶和客戶之間和無法感知的?？梢岳斫鉃榉?wù)運(yùn)行在外部（云服務(wù)廠商的公有池子）。

1.2 私有云

私有云就是將資源池分成多部分，也可以看成有多個(gè)資源池，每個(gè)客戶都對應(yīng)不同的資源池。資源池中所有的設(shè)施都只為這個(gè)客戶提供服務(wù)，云服務(wù)商只負(fù)責(zé)提供技術(shù)支持等服務(wù)。私有云對客戶而言可操控性更強(qiáng)?？梢岳斫鉃榉?wù)運(yùn)行在內(nèi)部（云服務(wù)廠商提供給客戶私有的池子）。

下面這張圖可以更明顯的說明公有云和私有云的區(qū)別：

1.3 混合云

顧名思義，混合云融合了至少一個(gè)公有云和一個(gè)私有云。那么為什么會有混合云的出現(xiàn)呢？最本質(zhì)的原因一定是錢！也就是成本控制，其次就是有一些客戶部分服務(wù)數(shù)據(jù)要嚴(yán)格保密但是有些可以公開，同時(shí)混合云的容災(zāi)和業(yè)務(wù)連續(xù)性更強(qiáng)?？梢岳斫鉃橐韵氯c(diǎn)：

成本控制： 組織可以使用混合云模型來優(yōu)化成本。一些工作負(fù)載可能更經(jīng)濟(jì)地在私有云中運(yùn)行，而其他工作負(fù)載則可以通過按需訪問的方式利用公有云的彈性計(jì)算資源。

合規(guī)性和數(shù)據(jù)隱私： 某些行業(yè)或組織可能面臨法規(guī)和合規(guī)性要求，要求敏感數(shù)據(jù)留存在特定的地理位置或基礎(chǔ)設(shè)施中?；旌显圃试S企業(yè)在私有云中處理這些敏感數(shù)據(jù)，同時(shí)利用公有云的靈活性。

容災(zāi)和業(yè)務(wù)連續(xù)性： 混合云模型可以提供更強(qiáng)大的容災(zāi)和業(yè)務(wù)連續(xù)性解決方案。通過將關(guān)鍵工作負(fù)載在本地和云之間分布，組織可以更好地應(yīng)對可能發(fā)生的故障或?yàn)?zāi)難。

所有的私有云和混合云都是根據(jù)客戶需求衍生出來的?？梢钥吹疆a(chǎn)品一定離不開需求。未來的趨勢一定是混合云。

1.4 托管云

托管云實(shí)際上就是：云服務(wù)+托管服務(wù)。主要表現(xiàn)在云計(jì)算中基礎(chǔ)設(shè)施、網(wǎng)絡(luò)、存儲、計(jì)算、安全的運(yùn)維。目前，市面上很多云服務(wù)都具有托管功能。

2.云計(jì)算的交付模式

下面說一下云計(jì)算的三種交付模型：基礎(chǔ)設(shè)施即服務(wù)（Iaas）、平臺即服務(wù)（Paas）、軟件即服務(wù)（Saas）

Iaas

? 基礎(chǔ)設(shè)施即服務(wù)，用戶可以控制操作系統(tǒng)、網(wǎng)絡(luò)、存儲等，是對于硬件和底層系統(tǒng)的管理是由云服務(wù)提供商負(fù)責(zé)的。。也就是說用戶可以控制底層的基礎(chǔ)設(shè)施。 IaaS 適用于那些需要更高級別的靈活性和控制的場景，允許用戶在虛擬環(huán)境中創(chuàng)建、配置和管理自己的應(yīng)用程序。

Paas

? 平臺即服務(wù)，提供了一個(gè)應(yīng)用程序開發(fā)和運(yùn)行的平臺，包括開發(fā)工具、數(shù)據(jù)庫、中間件等。它隱藏了底層的基礎(chǔ)設(shè)施，使開發(fā)者能夠?qū)Ｗ⒂趹?yīng)用程序的設(shè)計(jì)和開發(fā)。

Saas

? 用戶直接使用云服務(wù)商提供的軟件，其他什么都不用干。

3.虛擬化與云網(wǎng)絡(luò)

? Iaas基礎(chǔ)架構(gòu)可以看做：計(jì)算機(jī)虛擬化、網(wǎng)絡(luò)虛擬化、存儲*三部分組成。這也是云計(jì)算整體服務(wù)底層的架構(gòu)。

3.1 計(jì)算機(jī)虛擬化

? 計(jì)算機(jī)虛擬化包括：CPU虛擬化、內(nèi)存虛擬化、io虛擬化。實(shí)現(xiàn)CPU虛擬化和內(nèi)存虛擬化的工具就是KVM

3.1.1 什么是kvm？

? KVM 全稱是基于內(nèi)核的虛擬機(jī)（Kernel-based Virtual Machine），它是 Linux 的一個(gè)內(nèi)核模塊，該內(nèi)核模塊使得 Linux 變成了一個(gè) Hypervisor也叫Virtual Machine Monitor（VMM）虛擬機(jī)監(jiān)控器。

3.1.2 為什么會出現(xiàn)KVM？

傳統(tǒng)的虛擬化技術(shù)已經(jīng)很成熟，但是在性能上和物理機(jī)差距很大。說白了，kvm就是為了提高虛擬機(jī)的性能！

3.1.3 kvm虛擬化CPU和內(nèi)存

kvm虛擬化CPU和內(nèi)存

3.2 I/O虛擬化

? IOMMU(I/O Memory Management Unit)是一個(gè)內(nèi)存管理單元，主要針對外設(shè)訪問系統(tǒng)內(nèi)存市進(jìn)行內(nèi)存管理。

IOMMU的兩個(gè)基礎(chǔ)功能：地址重映射和 中斷重映射。

? overlay：Overlay方案便是從事服務(wù)器虛擬化技術(shù)的IT廠商主推的大二層網(wǎng)絡(luò)解決方案。其原理就是通過用隧道封裝的方式，將源主機(jī)發(fā)出的原始二層報(bào)文封裝后，再在現(xiàn)有網(wǎng)絡(luò)中進(jìn)行透傳，到達(dá)目的地之后再解封為原始報(bào)文，轉(zhuǎn)發(fā)給目標(biāo)主機(jī)，從而實(shí)現(xiàn)主機(jī)之間的二層通信。報(bào)文的封裝/解封裝都是在服務(wù)器內(nèi)部的虛擬交換機(jī)vSwitch上進(jìn)行，外部網(wǎng)絡(luò)只對封裝后的報(bào)文進(jìn)行普通的二層交換和三層轉(zhuǎn)發(fā)即可，所以網(wǎng)絡(luò)技術(shù)控制權(quán)就都回到了IT廠商手里。典型技術(shù)實(shí)現(xiàn)包括VXLAN、NVGRE、STT等。

? SDN：軟件定義網(wǎng)絡(luò)（Software Define Network，SDN）技術(shù)是對傳統(tǒng)網(wǎng)絡(luò)架構(gòu)的一次重構(gòu)，其核心思想是通過控制面（Control Plane）與數(shù)據(jù)面（Data Plane）的分離，將網(wǎng)絡(luò)的管理權(quán)限交給控制層的控制器軟件，在通過OpenFlow協(xié)議通道，統(tǒng)一下達(dá)指令給數(shù)據(jù)轉(zhuǎn)發(fā)層設(shè)備，從而實(shí)現(xiàn)網(wǎng)絡(luò)控制與數(shù)據(jù)轉(zhuǎn)發(fā)的充分解耦，一舉破除傳統(tǒng)網(wǎng)絡(luò)設(shè)備的封閉性。

https://developer.huawei.com/consumer/cn/forum/topic/0211128259827674019

3.2.1 openflow協(xié)議

? openflow協(xié)議并非類似于tcp、udp等協(xié)議。openflow協(xié)議而是一種控制層面的協(xié)議。傳統(tǒng)的流量傳輸需要查詢路由表，也就是說路由器的控制層面和數(shù)據(jù)層面沒有分開。但是，SDN所使用的openflow協(xié)議可以理解為將路由表全部結(jié)合到一起放在SDN控制器中，流量的傳輸通過查詢SND控制器的流表即可，這整個(gè)的查詢過程就叫做openflows協(xié)議。

https://chentingz.github.io/2019/12/30/%E3%80%8COpenFlow%E3%80%8D%E5%8D%8F%E8%AE%AE%E5%85%A5%E9%97%A8/#0x02-openflow%E7%AE%80%E4%BB%8B

3.2.2 vhost-net協(xié)議

最經(jīng)典的vhost-net圖

vhost-net執(zhí)行的流程

參考鏈接：https://cloud.tencent.com/developer/article/2030947

3.2.3 vhost-user協(xié)議

vhost-user實(shí)際上就是將vhost-net的virtqueue通過dpdk提取到了物理機(jī)的用戶態(tài)，同時(shí)通過dpdk調(diào)用底層kvm和網(wǎng)卡接口，跳過了之前的linux內(nèi)核部分。也就真正意義上實(shí)現(xiàn)了零拷貝（慢路徑不算）。所以目前主流云計(jì)算網(wǎng)絡(luò)都是基于dpdk+ovs繞過內(nèi)核。但是存在的缺陷：

a.ovs輪詢模式非常占用cpu

b.dpdk雖然NAPI模式，但是大部分都是在輪詢運(yùn)行，依然對資源的消耗很大。

對dpdk的優(yōu)化有：

1）增加內(nèi)核啟動(dòng)參數(shù)：isolcpus=2,3,4,5,6,7,8使處理器上的ID為上述的邏輯和不能陪操作系統(tǒng)調(diào)度。

2）可以修改編譯時(shí)候的參數(shù)：修改編譯參數(shù)來使能“extended tag”， 具體就是修改“config/common_linux”里如下的兩項(xiàng)參數(shù)。 Extended Flag（8位寬） 被打開后， （在一些老的系統(tǒng)上， 默認(rèn)不打開） 只有5位會被有效使用，支持32路并發(fā)， 完全Enable后， 8位同時(shí)使用， 能最大支持256個(gè)并發(fā)請求， 在40Gbit/s或者更高速端口會體現(xiàn)出性能差異。 修改PCIe Extended Tag可能涉及BIOS的配置與升級。CONFIG_RTE_PCI_CONFIG=y CONFIG_RTE_PCI_EXTENDED_TAG=“on”

3）收發(fā)隊(duì)列的長度收隊(duì)列長度dpdk默認(rèn)是128發(fā)包隊(duì)列長度，dpdk默認(rèn)是512。有512個(gè)描述符。 當(dāng)處理更高速率的網(wǎng)卡設(shè)備時(shí)， 或者發(fā)現(xiàn)有丟包的時(shí)候， 就應(yīng)該考慮更長的發(fā)包隊(duì)列，

4）收發(fā)包可釋放描述符數(shù)量閾值（ rx_free_thresh）每讀出一個(gè)包， 與之對應(yīng)的收包描述符就是可以釋放的了， 可以配置好用來后續(xù)收包過程。 由收發(fā)包過程知道， 需要更新表示收包隊(duì)列尾部索引的寄存器來通知硬件。 實(shí)際上， DPDK驅(qū)動(dòng)程序并沒有每次收包都更新收包隊(duì)列尾部索引寄存器， 而是在可釋放的收包描述符數(shù)量達(dá)到一個(gè)閾值（rx_free_thresh） 的時(shí)候才真正更新收包隊(duì)列尾部索引寄存器。 這個(gè)可釋放收包描述符數(shù)量閾值在驅(qū)動(dòng)程序里面的默認(rèn)值一般都是32。

5）**發(fā)包描述符釋放閾值（tx_free_thresh）**只有當(dāng)可以用來重新配置的發(fā)包描述符數(shù)量少于閾值的時(shí)候， 才會啟動(dòng)描述符和Mbuf的釋放動(dòng)作， 而不是每次看到有發(fā)包完成就釋放相應(yīng)的發(fā)包描述符和Mbuf。

調(diào)試過這些參數(shù)，性能會有所提升。但是時(shí)延和吞吐性能是成反比的，這種情況需要根據(jù)具體業(yè)務(wù)二舍去了。

4.總結(jié)

云計(jì)算真正發(fā)展起來主要還是依賴過剩的硬件資源和SDN（Software Define Network）大二層網(wǎng)絡(luò)的到來。過剩的硬件資源包括CPU、內(nèi)存、網(wǎng)卡等，最近技術(shù)也支持集成式GPU也可以通過類似網(wǎng)卡的SR-IOV技術(shù)進(jìn)行虛擬化，但是筆者并沒用過。今天主要討論的是基于SND控制器大二層網(wǎng)絡(luò)的云網(wǎng)絡(luò)技術(shù)的發(fā)展。

什么是SND控制器？

軟件定義網(wǎng)絡(luò)，顧名思義建立在軟件基礎(chǔ)上。學(xué)過網(wǎng)絡(luò)技術(shù)的都應(yīng)該知道，網(wǎng)絡(luò)分為兩個(gè)層面：控制面和數(shù)據(jù)面。控制面通知數(shù)據(jù)面以什么樣的形式和規(guī)則進(jìn)行傳輸，數(shù)據(jù)面負(fù)責(zé)整體數(shù)據(jù)的傳輸。傳統(tǒng)的網(wǎng)絡(luò)控制面和數(shù)據(jù)面是耦合的。簡單來講：一張網(wǎng)卡干兩個(gè)活，即負(fù)責(zé)調(diào)控?cái)?shù)據(jù)轉(zhuǎn)發(fā)策略，也要進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)。如果我們只操作一張網(wǎng)卡那并沒什么思考的，但是如果我們有多張網(wǎng)卡，每張網(wǎng)卡的業(yè)務(wù)邏輯都不一樣，那么轉(zhuǎn)發(fā)策略就都不同。想要修改網(wǎng)卡的轉(zhuǎn)發(fā)策略只能一個(gè)網(wǎng)卡一個(gè)網(wǎng)卡的修改，重復(fù)工作+浪費(fèi)時(shí)間。這就是傳統(tǒng)網(wǎng)絡(luò)最大的問題。所以SND網(wǎng)絡(luò)應(yīng)運(yùn)而生，SND網(wǎng)路將網(wǎng)卡中的控制面提取出來用軟件實(shí)現(xiàn)，使網(wǎng)卡只負(fù)責(zé)轉(zhuǎn)發(fā)，控制面統(tǒng)一使用SDN調(diào)配。極大簡化了傳統(tǒng)網(wǎng)絡(luò)實(shí)現(xiàn)和運(yùn)維的工作量，同時(shí)使網(wǎng)絡(luò)更加白盒化。

所以說，目前各大云計(jì)算廠商都會有一套自己完整的SND控制器，承載著業(yè)務(wù)和基礎(chǔ)設(shè)施。有了SDN集群化管理，才會使得云計(jì)算的飛速發(fā)展。SDN催化著網(wǎng)絡(luò)技術(shù)的飛速發(fā)展，同時(shí)網(wǎng)絡(luò)虛擬技術(shù)也逐漸成熟。

網(wǎng)絡(luò)虛擬化

網(wǎng)絡(luò)虛擬化離不開網(wǎng)卡的虛擬化。最初網(wǎng)卡的虛擬化是純軟件來實(shí)現(xiàn)的，也稱為全虛擬化，但是全虛擬化的性能很低，主要的原因是客戶虛擬機(jī)產(chǎn)生的IO請求需要經(jīng)過KVM內(nèi)核（可以理解為linux內(nèi)核），在傳到qemu線程中，這就使得傳輸路徑較多，虛擬機(jī)存在頻繁的entry和exit操作。所以，半虛擬化的出現(xiàn)就是為了解決這個(gè)問題。半虛擬化通過前后端的協(xié)商使得傳輸階段省去了kvm內(nèi)核和qemu線程階段，同時(shí)增加了環(huán)形隊(duì)列。這個(gè)環(huán)形隊(duì)列實(shí)際存儲的是消息通知描述符（eventfd），同時(shí)環(huán)形隊(duì)列可以批量存儲后將存儲的消息批量發(fā)送到硬件中。避免了頻繁的IO操作也節(jié)省了部分的性能開銷（雖然吞吐會有所增加，但是如果環(huán)形隊(duì)列每次存儲消息過多會增大傳輸時(shí)延。所以并不是環(huán)形隊(duì)列越大越好）。但是，半虛擬化需要在客戶機(jī)中安裝相應(yīng)的virtio-net、virtio-blk等驅(qū)動(dòng)，在兼容性上存在缺陷。

同時(shí)，為了解決性能問題，另一種方案也被提出----網(wǎng)卡直通。網(wǎng)卡直通，實(shí)際上就是將物理機(jī)上的物理網(wǎng)卡的控制權(quán)交給了虛擬機(jī)，這就是vfio技術(shù)。雖然在性能上有所提升，但是一個(gè)客戶機(jī)對應(yīng)一張網(wǎng)卡，資源上浪費(fèi)了很多。

SR-IOV技術(shù)解決了這個(gè)問題，sriov可以將物理網(wǎng)卡（并非所有的硬件網(wǎng)卡都支持sriov技術(shù)）虛擬出多個(gè)VF（一般256VF個(gè)最多）然后將VF通過vfio技術(shù)直通到虛擬機(jī)中，在性能上和物理網(wǎng)卡直通相差無幾。但是不支持虛擬機(jī)的熱遷移。（之前的調(diào)研mellanox在qemu基礎(chǔ)上，通過failover技術(shù)支持了這個(gè)熱遷移，但是實(shí)踐的時(shí)候并沒成功。）

為了解決熱遷移問題，近幾年產(chǎn)生了vdpa技術(shù)。主流的vdpa技術(shù)是通過dpdk來實(shí)現(xiàn)的，所以也叫作dpdk-vdpa。目前支持dpdk-vdpa的網(wǎng)卡有intel和NVIDIA-mellanox智能網(wǎng)卡兩種。以mellanox網(wǎng)卡為例，實(shí)際上是再vhost-user協(xié)議基礎(chǔ)上來實(shí)現(xiàn)的vdpa技術(shù)。通過vdpa技術(shù)，將vf包裝成virtio類型網(wǎng)卡傳輸?shù)教摂M機(jī)中，這樣虛擬機(jī)不用安裝相應(yīng)驅(qū)動(dòng)，同時(shí)也支持了熱遷移。智能網(wǎng)卡，并沒有將業(yè)務(wù)全部卸載到網(wǎng)卡上，ovs和dpdk-vdpa線程依然運(yùn)行在主機(jī)上，并且資源消耗也不容忽略。所以mellanox開發(fā)了DPU（data processing unit），將ovs和dpdk在dpu網(wǎng)卡中運(yùn)行，這就做到了主機(jī)資源最大程度的釋放。但是DPU技術(shù)目前來看并不成熟。市面上有多重DPU卡，他們的技術(shù)方案和實(shí)施環(huán)境都差異極大。類似NVIDIA的BF2卡，以一種vfe技術(shù)代替了智能網(wǎng)卡的vdpa，實(shí)際上實(shí)現(xiàn)的效果是一樣的，但是在開發(fā)過程中坑很多，并且性能不經(jīng)過專家調(diào)試根本達(dá)不到POC性能。同時(shí)國內(nèi)代表，華為的SP680的DPU在2024年初可能會推出。小編測試過SP680和CX6卡。他們的性能在X86和ARM架構(gòu)的環(huán)境上表現(xiàn)的天差地別。

上述總結(jié)起來如圖2所示

未來一定是面向全卸載功能，DPU在云計(jì)算和大模型等領(lǐng)域的應(yīng)用是必然的。但是DPU技術(shù)相關(guān)的積累較少，國內(nèi)除了阿里華為等大規(guī)模使用其他云服務(wù)廠商并沒有真正的把DPU業(yè)務(wù)完美落地。真正需要攻關(guān)的依然是DPU的落地方案以及在熱遷移上的兼容性。文章來源地址http://www.zghlxwxcb.cn/news/detail-761664.html

到了這里，關(guān)于什么是云計(jì)算？云網(wǎng)絡(luò)與發(fā)展的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！