1.? 方案背景
1.1. Kubernetes Service介紹
Kubernetes Service是Kubernetes中的一個(gè)核心概念,它定義了一種抽象,用于表示一組提供相同功能的Pods(容器組)的邏輯集合,并提供了一種方式讓這些Pods能夠被系統(tǒng)內(nèi)的其他組件發(fā)現(xiàn)并訪問(wèn)。簡(jiǎn)單來(lái)說(shuō),Service提供了一種讓客戶(hù)端能夠穩(wěn)定地連接到后端Pods的機(jī)制,即使這些Pods會(huì)動(dòng)態(tài)地創(chuàng)建、銷(xiāo)毀或遷移。
Kubernetes Service主要特性和用途
服務(wù)發(fā)現(xiàn):Service允許客戶(hù)端(如Pods中的應(yīng)用程序)通過(guò)穩(wěn)定的IP地址和端口號(hào)訪問(wèn)后端Pods集合,而無(wú)需關(guān)心實(shí)際Pod的IP地址或端口號(hào),因?yàn)檫@些信息可能會(huì)因?yàn)镻od的重啟或遷移而改變。
負(fù)載均衡:Kubernetes會(huì)自動(dòng)在Service后面創(chuàng)建的Pods之間分配進(jìn)入的流量,實(shí)現(xiàn)了簡(jiǎn)單的負(fù)載均衡。這意味著當(dāng)多個(gè)Pods提供了相同的服務(wù)時(shí),客戶(hù)端的請(qǐng)求可以被均衡地分發(fā)到這些Pods上。
支持DNS:Kubernetes支持基于DNS的服務(wù)發(fā)現(xiàn),允許Pods通過(guò)服務(wù)名(而不是IP地址)來(lái)相互通信。這大大簡(jiǎn)化了服務(wù)之間的調(diào)用和依賴(lài)關(guān)系的管理。
定義服務(wù)類(lèi)型:Service可以有多種類(lèi)型,最常見(jiàn)的是ClusterIP(默認(rèn),僅集群內(nèi)部可訪問(wèn))、NodePort(通過(guò)集群中每個(gè)節(jié)點(diǎn)的靜態(tài)端口暴露服務(wù))、LoadBalancer(在Cloud環(huán)境中,使用云提供商的負(fù)載均衡器暴露服務(wù))和ExternalName(將服務(wù)映射到DNS名稱(chēng),而不是選擇Pods)。
在Kubernetes集群中,kube-proxy作為Service的代理組件,負(fù)責(zé)實(shí)現(xiàn)集群內(nèi)部及外部對(duì)Service的訪問(wèn)。kube-proxy通過(guò)監(jiān)聽(tīng)Kubernetes API Server中的Service和Endpoint資源變化,動(dòng)態(tài)地在每個(gè)節(jié)點(diǎn)上配置網(wǎng)絡(luò)規(guī)則,確保對(duì)Service的請(qǐng)求能夠被正確地路由到后端的Pod實(shí)例上。
在iptables 模式下,kube-proxy會(huì)在每個(gè)節(jié)點(diǎn)上通過(guò)iptables規(guī)則來(lái)實(shí)現(xiàn)請(qǐng)求的轉(zhuǎn)發(fā)。它會(huì)創(chuàng)建一系列的iptables規(guī)則,這些規(guī)則根據(jù)Service的IP和端口,將訪問(wèn)Service的流量重定向到后端的Pod IP和端口上。這種方式簡(jiǎn)單直接,但隨著Service和Pod數(shù)量的增加,iptables規(guī)則會(huì)急劇膨脹,影響性能。
作為iptables的改進(jìn),ipvs(IP Virtual Server)模式提供了更高的性能和更好的擴(kuò)展性。ipvs使用更高效的哈希表來(lái)管理網(wǎng)絡(luò)規(guī)則,可以更快地查找和轉(zhuǎn)發(fā)流量。這使得在大規(guī)模集群中,Service的訪問(wèn)性能得到顯著提升。
1.2. 問(wèn)題與挑戰(zhàn)
盡管kube-proxy在大多數(shù)基礎(chǔ)場(chǎng)景中表現(xiàn)良好,但它也存在一些明顯的局限性:
1、場(chǎng)景簡(jiǎn)單:kube-proxy主要適用于簡(jiǎn)單的網(wǎng)絡(luò)拓?fù)?/a>結(jié)構(gòu),對(duì)于復(fù)雜的IaaS(Infrastructure as a Service)場(chǎng)景,如需要支持VPC(Virtual Private Cloud)網(wǎng)絡(luò)隔離、靈活的EIP(Elastic IP)使用等高級(jí)網(wǎng)絡(luò)功能時(shí),顯得力不從心。
2、性能瓶頸:由于kube-proxy的報(bào)文轉(zhuǎn)發(fā)完全依賴(lài)于軟件實(shí)現(xiàn)(無(wú)論是iptables還是ipvs),這意味著它無(wú)法利用現(xiàn)代硬件(如DPU、SmartNIC)進(jìn)行網(wǎng)絡(luò)加速,在高負(fù)載跨節(jié)點(diǎn)轉(zhuǎn)發(fā)的情況下,這種軟件實(shí)現(xiàn)的性能瓶頸尤為明顯。
3、資源消耗:基于軟件實(shí)現(xiàn)的Kubernetes Service,在高負(fù)載跨節(jié)點(diǎn)轉(zhuǎn)發(fā)的情況下會(huì)導(dǎo)致CPU資源消耗過(guò)高,從而影響整體系統(tǒng)的穩(wěn)定性和性能。
與kube-proxy相似,許多開(kāi)源的容器網(wǎng)絡(luò)接口(CNI)插件,如使用Open vSwitch(OVS)的kube-ovn、Antrea等,通常依賴(lài)于自己的數(shù)據(jù)面處理機(jī)制來(lái)轉(zhuǎn)發(fā)Service網(wǎng)絡(luò)流量,在沒(méi)有硬件加速的情況下,也面臨類(lèi)似的性能瓶頸和資源消耗問(wèn)題。
2. 方案介紹
2.1.?整體架構(gòu)
本方案基于DPU&SmartNIC實(shí)現(xiàn)了Kubernetes Service的解決方案,簡(jiǎn)稱(chēng)“馭云Service”。
馭云Service在馭云SDN的架構(gòu)中實(shí)現(xiàn),其中馭云SDN通過(guò)ovn/ovs機(jī)制將DPU&SmartNIC加入到同一個(gè)ovn集群,對(duì)網(wǎng)絡(luò)進(jìn)行統(tǒng)一的虛擬化,整體物理架構(gòu)圖如所示:
在Pod/裸機(jī)/VM接入DPU卡或SmartNIC卡后,用戶(hù)的請(qǐng)求由Service處理后送往對(duì)應(yīng)的Pod/裸機(jī)/VM。
軟件整體架構(gòu)如下:
如圖所示,馭云Service基于馭云SDN,上圖各個(gè)組件中均會(huì)參與處理Service的邏輯,下面分別進(jìn)行介紹:
ycloud-controller,是SDN系統(tǒng)的控制平面,處理Service的主要邏輯,將用戶(hù)創(chuàng)建的Service數(shù)據(jù)通過(guò)ovn轉(zhuǎn)換成實(shí)際的網(wǎng)絡(luò)拓?fù)洹?/p>
yusurService-controller,處理用戶(hù)創(chuàng)建的YusurService資源,翻譯成內(nèi)置Service資源給ycloud-controller使用。
ycloud-cni,該組件作為一個(gè)DaemonSet運(yùn)行在每個(gè)節(jié)點(diǎn)上,是SDN的CNI接口,同時(shí)也會(huì)負(fù)責(zé)各個(gè)節(jié)點(diǎn)上Service的一些處理邏輯。
注:馭云SDN參見(jiàn)《基于DPU&SmartNIC的云原生SDN解決方案》
2.2.?方案描述
在馭云SDN的概念中,所有后端資源,無(wú)論是Pod、VM還是裸金屬服務(wù)器,都屬于某一個(gè)VPC(虛擬私有云)。VPC實(shí)現(xiàn)了邏輯隔離的網(wǎng)絡(luò)空間,這意味著不同VPC內(nèi)的網(wǎng)絡(luò)流量不會(huì)相互干擾,這提供了重要的安全邊界,同時(shí)也便于多租戶(hù)環(huán)境中的資源管理和隔離。然而,這種隔離也帶來(lái)了一個(gè)挑戰(zhàn):如何允許不同VPC之間或者外部網(wǎng)絡(luò)訪問(wèn)這些VPC內(nèi)的資源。
Service需要解決的就是從不同地方經(jīng)過(guò)Service訪問(wèn)到這些VPC內(nèi)的資源,并且根據(jù)策略進(jìn)行請(qǐng)求的負(fù)載均衡。在馭云Service中,具體包含以下場(chǎng)景:
集群內(nèi)部互通(ClusterIP類(lèi)型Service)
場(chǎng)景①:客戶(hù)端在集群VPC內(nèi),訪問(wèn)同VPC下的后端服務(wù):
在這種情況下,客戶(hù)端可以直接通過(guò)Service的ClusterIP訪問(wèn)后端服務(wù)。ClusterIP是一種虛擬IP地址,由Kubernetes為Service分配,只在集群內(nèi)部可見(jiàn)。流量在VPC內(nèi)直接轉(zhuǎn)發(fā),無(wú)需經(jīng)過(guò)額外的網(wǎng)關(guān)或負(fù)載均衡器。
場(chǎng)景②:客戶(hù)端在集群節(jié)點(diǎn)上,訪問(wèn)默認(rèn)VPC下的一組后端服務(wù):
當(dāng)客戶(hù)端運(yùn)行在集群節(jié)點(diǎn)上時(shí),它同樣可以通過(guò)ClusterIP訪問(wèn)服務(wù)。Kubernetes的網(wǎng)絡(luò)策略確保流量在節(jié)點(diǎn)和后端服務(wù)之間正確路由。這種訪問(wèn)方式同樣限于集群內(nèi)部,不需要EIP。
集群外部訪問(wèn)集群內(nèi)(LoadBalancer類(lèi)型Service)
場(chǎng)景③:客戶(hù)端在集群外部,通過(guò)EIP訪問(wèn)一個(gè)VPC下的一組后端服務(wù):
在此場(chǎng)景下,客戶(hù)端通過(guò)云外訪問(wèn)集群內(nèi)的服務(wù)。LoadBalancer類(lèi)型Service會(huì)分配一個(gè)EIP,此時(shí)外部流量通過(guò)EIP被路由到集群內(nèi)部的Service。
場(chǎng)景④:客戶(hù)端在集群外部,通過(guò)EIP訪問(wèn)多個(gè)VPC下的一組后端服務(wù):
當(dāng)客戶(hù)端需要訪問(wèn)跨多個(gè)VPC的服務(wù)時(shí),情況變得復(fù)雜。在這種情況下,當(dāng)外部流量通過(guò)EIP進(jìn)入集群內(nèi)Service時(shí),Servcie會(huì)同時(shí)充當(dāng)網(wǎng)關(guān),將流量正確地路由到目標(biāo)VPC。
本方案主要從控制面和數(shù)據(jù)面2各方面進(jìn)行介紹。
2.2.1. 控制面
在控制層,我們對(duì)原生Service進(jìn)行了封裝,在Kubernetes基礎(chǔ)上擴(kuò)展了對(duì)Service的管理能力,整體控制面結(jié)構(gòu)如下圖所示:
Service和Endpoint是Kubernetes內(nèi)置資源。資源Service定義了構(gòu)造一個(gè)Service的基本信息。
由于內(nèi)置資源無(wú)法滿(mǎn)足我們需要功能,包括網(wǎng)絡(luò)訪問(wèn)場(chǎng)景,和多種后端,于是馭云Service增加了YusurService與NetworkProbe兩種自定義資源定義(CRDs):
YusurService: 一種擴(kuò)展的Service概念,允許定義更廣泛的后端資源,包括Pod、VM、BM(裸金屬服務(wù)器)、VNicIP(虛擬網(wǎng)絡(luò)接口IP)。通過(guò)使用選擇器(selectors),可以靈活地匹配不同類(lèi)型的后端資源,而不僅僅是Pod。支持定義多種網(wǎng)絡(luò)場(chǎng)景,靈活的指定eip和clusterIP等。
NetworkProbe: 用于健康檢查的新CRD,為每個(gè)后端資源生成相應(yīng)的探針,實(shí)時(shí)監(jiān)控其健康狀態(tài)。這可以確保負(fù)載均衡器只將請(qǐng)求轉(zhuǎn)發(fā)給健康的實(shí)例。
用戶(hù)只需要和YusurService進(jìn)行交互,yusurService-controller會(huì)根據(jù)YusurService的信息創(chuàng)建Networkprobe,Endpoint和Service這3種資源。
Service包含網(wǎng)絡(luò)配置的大多基本信息,Endpoint資源包含本次配置的所有后端;Networkprobe返回后端健康檢查結(jié)果,yusurService-controller會(huì)根據(jù)Networkprobe的返回結(jié)果調(diào)整Endpoint所包含的健康后端。
yscloud-controller則會(huì)根據(jù)Endpoint和Service的信息通過(guò)ovn繪制出整個(gè)網(wǎng)絡(luò)拓?fù)?,打通網(wǎng)絡(luò)通路。
通過(guò)這樣的架構(gòu),系統(tǒng)不僅提供了高級(jí)別的抽象來(lái)簡(jiǎn)化Service管理和后端資源的健康監(jiān)控,還實(shí)現(xiàn)了跨VPC的負(fù)載均衡,增強(qiáng)了Kubernetes集群的網(wǎng)絡(luò)功能。
2.2.2. 數(shù)據(jù)面
Service的數(shù)據(jù)面依賴(lài)OVN和OpenVswitch,根據(jù)不同的訪問(wèn)場(chǎng)景,在不同的地方配置Load_Balancer,Load_Balancer是OVN的邏輯概念,可以應(yīng)用在OVN的邏輯交換機(jī)或者邏輯路由器上面,它將在對(duì)應(yīng)的地方上配置DNAT的規(guī)則,將訪問(wèn)VIP的報(bào)文轉(zhuǎn)到合適的后端上去。
下文分別針對(duì)控制面中所描述的4種Service使用場(chǎng)景進(jìn)行說(shuō)明。
2.2.2.1 同vpc下訪問(wèn)資源
當(dāng)創(chuàng)建了Service之后,LoadBalancer的網(wǎng)絡(luò)策略會(huì)確保應(yīng)用在vpc1內(nèi)的所有Subnet上。當(dāng)subnet3上的client訪問(wèn)10.0.0.100時(shí),其請(qǐng)求將首先被subnet3上的LoadBalancer接收。LoadBalancer會(huì)基于其算法(例如輪詢(xún)、最少連接數(shù)等)選擇一個(gè)后端Pod,并將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址。數(shù)據(jù)包隨后會(huì)通過(guò)vpc1被轉(zhuǎn)發(fā)到選定的Pod所在的Subnet,例如subnet1,最后轉(zhuǎn)發(fā)至Pod1。
2.2.2.2.?從集群節(jié)點(diǎn)上訪問(wèn)vpc內(nèi)資源
當(dāng)集群節(jié)點(diǎn)上的client訪問(wèn)10.0.0.100時(shí),報(bào)文經(jīng)過(guò)node-interface進(jìn)入subnet0,經(jīng)過(guò)LoadBalancer將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址后,通過(guò)ovn-cluster到對(duì)應(yīng)subnet,完成一次轉(zhuǎn)發(fā)。
2.2.2.3.從集群外部訪問(wèn)同一個(gè)vpc內(nèi)資源
當(dāng)創(chuàng)建了Service之后,LoadBalancer的網(wǎng)絡(luò)策略會(huì)應(yīng)用在vpc1上,當(dāng)client訪問(wèn)200.0.0.100時(shí),其請(qǐng)求將首先被這個(gè)EIP子網(wǎng)所屬的eipGateway接收。eipGateway會(huì)將報(bào)文路由到Servic所屬的VPC,vpc1內(nèi),此時(shí)LoadBalancer規(guī)則會(huì)基于其算法(例如輪詢(xún)、最少連接數(shù)等)選擇一個(gè)后端Pod,并將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址。數(shù)據(jù)包隨后會(huì)通過(guò)vpc1被轉(zhuǎn)發(fā)到選定的Pod,完成一次轉(zhuǎn)發(fā)。
2.2.2.4.從集群外部訪問(wèn)多個(gè)vpc內(nèi)資源
當(dāng)創(chuàng)建了Service之后,控制器會(huì)創(chuàng)建一個(gè)service-gateway的邏輯路由器,LoadBalancer的網(wǎng)絡(luò)策略會(huì)應(yīng)用在該路由器上,當(dāng)client訪問(wèn)200.0.0.100時(shí),其請(qǐng)求將首先被這個(gè)eip子網(wǎng)所屬的eipGateway接收。eipGateway會(huì)將報(bào)文路由到service-gateway上,此時(shí)LoadBalancer規(guī)則會(huì)基于其算法(例如輪詢(xún)、最少連接數(shù)等)選擇一個(gè)后端Pod,并將數(shù)據(jù)包的目標(biāo)地址轉(zhuǎn)換為所選Pod的實(shí)際IP地址,源地址轉(zhuǎn)換為所選service-gateway的系統(tǒng)IP地址。數(shù)據(jù)包隨后會(huì)被轉(zhuǎn)發(fā)到選定的Pod的vpc上,然后vpc將數(shù)據(jù)包送到Pod,完成一次轉(zhuǎn)發(fā)。
3. 方案測(cè)試結(jié)果
3.1.?創(chuàng)建Service
創(chuàng)建一個(gè)帶有特定選擇器和端口映射的Service YAML文件ysvc1.yaml,如下:
apiVersion: iaas.yusur.io/v1
kind: YusurService metadata: name: ysvc1 spec: type: ClusterIP scope: vpc vpc: vpc1 ports: - port: 5001 name: iperf protocol: TCP targetPort: 5001 selector: svc: svc1-ep |
使用kubectl apply -f ysvc1.yaml命令創(chuàng)建Service。
使用kubectl get ysvc ysvc1檢查Service,如下:
訪問(wèn)Service clusterIP,訪問(wèn)成功。
圖中的netns為service后端同vpc下的一個(gè)pod,10.233.46.185為service的clusterIP,5001是service暴露的端口。
3.2.?性能對(duì)比
3.2.1 Pod的帶寬
帶寬單位Gbits/s。
測(cè)試用例 | 馭云卸載方案 | 未卸載方案 | |
1 | 物理節(jié)點(diǎn)之間基準(zhǔn)測(cè)試 | 163 | 166 |
2 | 物理節(jié)點(diǎn)訪問(wèn)后端在遠(yuǎn)端的Service | 152 | 130 |
3 | Pod訪問(wèn)后端在遠(yuǎn)端的Service | 151 | 138 |
從上面測(cè)試數(shù)據(jù)得出以下結(jié)論:
1.?????? 卸載模式下,馭云訪問(wèn)遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的帶寬。
2.?????? 卸載模式比非卸載在帶寬上性能提升了20%左右。
3.2.2 Pod的pps
pps單位為Mpps。
測(cè)試用例 | 馭云卸載方案 | 未卸載方案 | |
1 | 物理節(jié)點(diǎn)之間基準(zhǔn)測(cè)試 | 45 | 45 |
2 | 物理節(jié)點(diǎn)訪問(wèn)后端在遠(yuǎn)端的Service | 25.5 | 12.1 |
3 | Pod訪問(wèn)后端在遠(yuǎn)端的Service | 24.5 | 12.2 |
從下面數(shù)據(jù)得出以下結(jié)論:
1.?????? 卸載模式下,馭云訪問(wèn)遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的60%pps。
2.?????? 卸載模式比非卸載在pps上性能提升了2倍以上。
3.2.3 Pod的延時(shí)
延時(shí)單位為us。
測(cè)試用例 | 馭云卸載方案 | 未卸載方案 | |
1 | 物理節(jié)點(diǎn)之間基準(zhǔn)測(cè)試 | 32 | 32 |
2 | 物理節(jié)點(diǎn)訪問(wèn)后端在遠(yuǎn)端的Service | 33 | 48 |
3 | Pod訪問(wèn)后端在遠(yuǎn)端的Service | 33 | 44 |
從上面測(cè)試數(shù)據(jù)得出以下結(jié)論:
1.?????? 卸載模式下,馭云訪問(wèn)遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的延遲。
2.?????? 卸載模式比非卸載在延遲上降低了20%以上。
3.2.4 RPS
單位為Requests/s。
測(cè)試用例 | 馭云卸載方案 | 未卸載方案 | |
1 | 物理節(jié)點(diǎn)之間基準(zhǔn)測(cè)試 | 15999 | |
2 | Pod跨節(jié)點(diǎn)訪問(wèn)Service | 15139 | 11040 |
從上面測(cè)試數(shù)據(jù)得出以下結(jié)論:
1.?????? 卸載模式下,馭云訪問(wèn)遠(yuǎn)端Service能夠達(dá)到接近物理機(jī)的rps。
2.?????? 卸載模式比非卸載在rps上提升了40%左右。
3.2.5 每條request的CPU指令數(shù)以及CPI
每條request的CPU指令數(shù),單位為instructions/request。
測(cè)試用例 | 馭云卸載方案 | 未卸載方案 | |
Pod跨節(jié)點(diǎn)訪問(wèn)Service | 122,613 | 171,405 |
CPI,單位為cycles/instruction。
測(cè)試用例 | 馭云卸載方案 | 未卸載方案 | |
Pod跨節(jié)點(diǎn)訪問(wèn)Service | 1.94 | 1.69 |
從上面測(cè)試數(shù)據(jù)得出以下結(jié)論:
1.?????? 一個(gè)請(qǐng)求消耗的CPU指令數(shù)量,卸載模式比非卸載模式降低30%左右。
2.?????? 在CPI方面,卸載模式比非卸載模式增大了15%左右。
3.?????? 綜合消耗的CPU指令數(shù)量來(lái)看,對(duì)CPU的消耗減少了25%左右。
4. 優(yōu)勢(shì)總結(jié)
基于DPU和SmartNIC的K8s Service解決方案展現(xiàn)出顯著的優(yōu)勢(shì),具體總結(jié)如下:
① 支持復(fù)雜網(wǎng)絡(luò)拓?fù)渑c高級(jí)功能
在復(fù)雜的網(wǎng)絡(luò)拓?fù)湎聦?shí)現(xiàn)K8s Service,支持VPC網(wǎng)絡(luò)隔離和EIP等高級(jí)網(wǎng)絡(luò)功能,大大增強(qiáng)了Kubernetes集群在IaaS環(huán)境中的網(wǎng)絡(luò)靈活性和安全性,滿(mǎn)足復(fù)雜場(chǎng)景下的網(wǎng)絡(luò)需求。
② 顯著提升K8s Service性能
根據(jù)測(cè)試數(shù)據(jù),本方案在帶寬上性能提升了20%左右,pps上性能提升了2倍以上,延遲降低了20%以上。DPU和SmartNIC內(nèi)置了強(qiáng)大的網(wǎng)絡(luò)處理引擎,能夠直接在硬件上完成報(bào)文的解析、轉(zhuǎn)發(fā)和路由決策等任務(wù),這種硬件加速機(jī)制使得在高負(fù)載跨節(jié)點(diǎn)轉(zhuǎn)發(fā)時(shí),仍能保持低延遲和高吞吐量,顯著提升了Kubernetes Service的性能。
③ 降低資源消耗與優(yōu)化系統(tǒng)性能
根據(jù)測(cè)試數(shù)據(jù),本方案對(duì)CPU的消耗減少了25%左右。由于DPU和SmartNIC承擔(dān)了大部分的網(wǎng)絡(luò)處理工作,CPU從繁重的網(wǎng)絡(luò)轉(zhuǎn)發(fā)任務(wù)中解放出來(lái),可以專(zhuān)注于執(zhí)行其他更關(guān)鍵的計(jì)算任務(wù),這不僅降低了CPU的資源消耗,還提升了整體系統(tǒng)的穩(wěn)定性和性能。
綜上所述,基于DPU和SmartNIC的K8s Service解決方案在應(yīng)對(duì)復(fù)雜網(wǎng)絡(luò)拓?fù)洹⑿阅芷款i和資源消耗等方面具有明顯的優(yōu)勢(shì),能夠顯著提升Kubernetes集群在復(fù)雜IaaS環(huán)境中的網(wǎng)絡(luò)性能和整體穩(wěn)定性。
本方案來(lái)自于中科馭數(shù)軟件研發(fā)團(tuán)隊(duì),團(tuán)隊(duì)核心由一群在云計(jì)算、數(shù)據(jù)中心架構(gòu)、高性能計(jì)算領(lǐng)域深耕多年的業(yè)界資深架構(gòu)師和技術(shù)專(zhuān)家組成,不僅擁有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn),還對(duì)行業(yè)趨勢(shì)具備敏銳的洞察力,該團(tuán)隊(duì)致力于探索、設(shè)計(jì)、開(kāi)發(fā)、推廣可落地的高性能云計(jì)算解決方案,幫助最終客戶(hù)加速數(shù)字化轉(zhuǎn)型,提升業(yè)務(wù)效能,同時(shí)降低運(yùn)營(yíng)成本。