• 
    

    
    

      99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看

      ?

      云環(huán)境下大規(guī)模分布式計(jì)算數(shù)據(jù)感知的調(diào)度系統(tǒng)

      2020-02-08 07:14:00劉汪根鄭淮城榮國平
      大數(shù)據(jù) 2020年1期
      關(guān)鍵詞:容器標(biāo)簽調(diào)度

      劉汪根,鄭淮城,榮國平

      1. 星環(huán)信息科技(上海)有限公司,上海 200233;2. 南京大學(xué)軟件學(xué)院,江蘇 南京 210093

      1 引言

      隨著云計(jì)算、大數(shù)據(jù)與人工智能(artificial intelligence,AI)技術(shù)的發(fā)展以及行業(yè)對這3種技術(shù)的綜合應(yīng)用需求,目前國內(nèi)外出現(xiàn)了大數(shù)據(jù)、云計(jì)算、人工智能三者相互融合的技術(shù)發(fā)展趨勢。中國計(jì)算機(jī)學(xué)會大數(shù)據(jù)專家委員會在2019年大數(shù)據(jù)發(fā)展趨勢調(diào)查報(bào)告中指出:人工智能、大數(shù)據(jù)、云計(jì)算將高度融合為一體化系統(tǒng)[1]。

      2006年Hadoop項(xiàng)目的誕生標(biāo)志著大數(shù)據(jù)技術(shù)時(shí)代的開始,而亞馬遜云計(jì)算服務(wù)(Amazon web services,AWS)商用則標(biāo)志著云計(jì)算正式邁出了改變信息時(shí)代的步伐。自此之后,大數(shù)據(jù)和云計(jì)算成為最近十幾年十分火熱的技術(shù),學(xué)術(shù)界和工業(yè)界都大力投入相關(guān)技術(shù)研發(fā)和落地應(yīng)用中,并且創(chuàng)造了幾個(gè)學(xué)術(shù)界和工業(yè)界協(xié)作的經(jīng)典之作。如2012年加州大學(xué)伯克利分校推出的新型計(jì)算引擎Spark技術(shù)迅速被工業(yè)界接受,并成為新一代的標(biāo)準(zhǔn)計(jì)算引擎。在云計(jì)算領(lǐng)域,更多的是企業(yè)級應(yīng)用推動了技術(shù)的發(fā)展,如2014年開始興起的容器技術(shù)和編排系統(tǒng),最終推進(jìn)了新一代原生云平臺的快速發(fā)展,Docker和Kubernetes[2]技術(shù)則成為新一代原生云的標(biāo)準(zhǔn)。

      基礎(chǔ)軟件的研發(fā)不是簡單的功能堆積,必須經(jīng)過詳細(xì)的架構(gòu)設(shè)計(jì)和功能驗(yàn)證。大數(shù)據(jù)和AI計(jì)算都是典型的分布式計(jì)算模型,是基于有向無環(huán)圖(directed acyclic graph,DAG)[3]或者大規(guī)模并行處理(massive parallel programming,MPP)迭代的計(jì)算模式,意味著計(jì)算任務(wù)都是運(yùn)行時(shí)才能生成的,因而難以進(jìn)行預(yù)先調(diào)度,而分布式的特點(diǎn)又要求調(diào)度系統(tǒng)有更高的靈活性和自適應(yīng)性。目前工業(yè)界在努力嘗試將大數(shù)據(jù)平臺和AI技術(shù)部署在原生云上,以做到更大的彈性和可擴(kuò)展性。但是,目前全球范圍內(nèi)在這個(gè)領(lǐng)域取得的突破性成就還比較少。本文將介紹核心創(chuàng)新:云平臺中的核心調(diào)度系統(tǒng)如何在原生云平臺上管理和調(diào)度大數(shù)據(jù)和AI應(yīng)用。

      2 云原生

      云原生(cloud native)[4]是指在應(yīng)用開發(fā)時(shí),以云作為其生產(chǎn)部署方式,從而充分利用云的彈性、可擴(kuò)展、自愈等核心優(yōu)勢。區(qū)別于傳統(tǒng)的臃腫的單體應(yīng)用開發(fā)模式,云原生應(yīng)用因?yàn)槠溆行У膮f(xié)同開發(fā)、測試和運(yùn)維,極大地提高了軟件開發(fā)效率和質(zhì)量,支持產(chǎn)品快速地上線和迭代,已經(jīng)成為當(dāng)前主流的應(yīng)用開發(fā)模式。

      通常稱能夠有效支撐云原生應(yīng)用的平臺為原生云平臺,其主要特點(diǎn)是容器化的封裝、自動化的管理以及面向微服務(wù)的體系。Docker直接使用Linux Cgroup等技術(shù)提供邏輯上的虛擬化,因其系統(tǒng)開銷小、啟動快、隔離性較好、方便應(yīng)用封裝等特點(diǎn),Docker已經(jīng)成為首選的應(yīng)用容器技術(shù)。此外Docker技術(shù)支持跨平臺部署,能夠?qū)崿F(xiàn)“一次編譯,多次部署”?;谔摂M機(jī)的技術(shù)對高負(fù)載的應(yīng)用可能有30%的性能損耗,而Docker技術(shù)沒有硬件虛擬化,跟裸機(jī)相比幾乎沒有性能損耗,因此也可以用于部署類似大數(shù)據(jù)和AI應(yīng)用的計(jì)算或者I/O資源密集型的應(yīng)用。

      一個(gè)大的云平臺可能需要高效穩(wěn)定地運(yùn)行數(shù)萬個(gè)容器,這就需要非常強(qiáng)大的服務(wù)編排系統(tǒng)。為了滿足日益增多的服務(wù)和任務(wù)的資源需求,Borg[5]、Mesos[6]、Omega[7]等一系列的集群資源調(diào)度系統(tǒng)相繼出現(xiàn)。其中,Borg是集中式調(diào)度器的代表,其作為集群調(diào)度器的鼻祖,在Google公司有超過10年的生產(chǎn)經(jīng)驗(yàn),其上運(yùn)行了GFS[8]、BigTable[9]、Gmail、MapReduce[10]等各種類型的任務(wù)。Mesos是雙層調(diào)度器的代表,可以讓多個(gè)框架公平地共享集群資源。Omega則是共享狀態(tài)調(diào)度器的代表,它的特點(diǎn)是支持使用不同的調(diào)度器調(diào)度不同類型的任務(wù),解決資源請求沖突的問題。

      Kubernetes是Google開源用來管理Docker集群的項(xiàng)目,繼承了Borg的優(yōu)點(diǎn),實(shí)現(xiàn)了編排、部署、運(yùn)行以及管理容器應(yīng)用的目的,Kubernetes的總體架構(gòu)如圖1所示。Kubernetes提供資源池化管理,可以將整個(gè)集群內(nèi)的中央處理器(center processing unit,CPU)、圖形處理器(graphic processing unit,GPU)、內(nèi)存、網(wǎng)絡(luò)和硬盤等資源抽象為一個(gè)資源池,可以根據(jù)應(yīng)用的資源需求、資源池中的實(shí)時(shí)資源情況進(jìn)行靈活調(diào)度;Kubernetes包含一個(gè)統(tǒng)一的調(diào)度框架,最多可以管理數(shù)千個(gè)服務(wù)器和數(shù)萬個(gè)容器,同時(shí)提供插件化的接口,讓第三方來定制和擴(kuò)展新的調(diào)度系統(tǒng);此外Kubernetes支持通過ConfigMap等方式動態(tài)地調(diào)整應(yīng)用配置,從而具備動態(tài)調(diào)配的基礎(chǔ)能力。

      本文基于這些基礎(chǔ)技術(shù)開發(fā)了支持復(fù)雜應(yīng)用平臺的調(diào)度系統(tǒng)。

      3 大數(shù)據(jù)和AI計(jì)算模型

      分布式計(jì)算在復(fù)雜的工業(yè)應(yīng)用需求下快速迭代和發(fā)展,從離線處理的MapReduce[5]計(jì)算模型開始,逐漸發(fā)展出了以Spark為代表的在線計(jì)算(Spark、Tez[11]、Druid[12]等)以及實(shí)時(shí)計(jì)算模型(Flink[13]、Spark Streaming[14]等)。新的分布式計(jì)算模型開拓了新的應(yīng)用領(lǐng)域,同時(shí)也對大規(guī)模系統(tǒng)的管理、調(diào)度和運(yùn)維提出了較大的挑戰(zhàn)。

      3.1 MapReduce

      MapReduce框架是Hadoop技術(shù)的核心,它的出現(xiàn)在計(jì)算模式歷史上是一個(gè)重大事件,在此之前行業(yè)內(nèi)主要通過MPP的方式增強(qiáng)系統(tǒng)的計(jì)算能力,一般是利用復(fù)雜而昂貴的硬件加速計(jì)算,如高性能計(jì)算機(jī)和數(shù)據(jù)庫一體機(jī)等。而MapReduce是通過分布式計(jì)算來提高計(jì)算速度的,并且只需要廉價(jià)的硬件就可以實(shí)現(xiàn)可擴(kuò)展的、高并行的計(jì)算能力。

      3.2 Spark

      隨著大量的企業(yè)開始使用Hadoop構(gòu)建企業(yè)應(yīng)用,MapReduce性能慢的問題逐漸成為研究瓶頸,MapReduce只能用于離線數(shù)據(jù)處理,而不能用于對性能要求高的計(jì)算場景,如在線交互式分析、實(shí)時(shí)分析等。在此背景下,Spark計(jì)算模型誕生了。雖然本質(zhì)上Spark仍然是一個(gè)MapReduce計(jì)算模式,但是幾個(gè)核心的創(chuàng)新使得Spark的性能在迭代計(jì)算應(yīng)用中比MapReduce快一個(gè)數(shù)量級以上:第一,數(shù)據(jù)盡量通過內(nèi)存進(jìn)行交互,相比基于磁盤的交換,能夠避免I/O帶來的性能問題;第二,采用延時(shí)評估(lazy evaluation)的計(jì)算模型和基于DAG的執(zhí)行模式,可以生成更好的執(zhí)行計(jì)劃。此外,通過有效的檢查點(diǎn)(check pointing)機(jī)制可以實(shí)現(xiàn)良好的容錯機(jī)制,避免內(nèi)存失效帶來的計(jì)算問題。

      3.3 TensorFlow

      TensorFlow[15]是Google公司開發(fā)的第二代人工智能學(xué)習(xí)系統(tǒng),它可以將復(fù)雜的數(shù)據(jù)結(jié)構(gòu)傳輸至人工智能神經(jīng)網(wǎng)絡(luò)中進(jìn)行分析和處理,可用于語音識別、圖像識別等多項(xiàng)機(jī)器學(xué)習(xí)和深度學(xué)習(xí)任務(wù),并且完全開源,目前也是開源社區(qū)活躍的開發(fā)項(xiàng)目之一。TensorFlow支持異構(gòu)設(shè)備的分布式計(jì)算,可以在各個(gè)平臺上自動運(yùn)行模型,支持在手機(jī)、單個(gè)CPU/GPU、大型數(shù)據(jù)中心服務(wù)器等各種設(shè)備上運(yùn)行。

      4 原生云與大數(shù)據(jù)、AI融合的技術(shù)難點(diǎn)和解決思路

      4.1 基于容器云開發(fā)大數(shù)據(jù)或AI產(chǎn)品的技術(shù)難點(diǎn)

      原生云平臺的一個(gè)主要特點(diǎn)是面向微服務(wù)設(shè)計(jì),使用容器的方式編排普通的Web應(yīng)用或者微服務(wù)。但是大數(shù)據(jù)或者AI計(jì)算平臺本身并沒有采用微服務(wù)設(shè)計(jì),各個(gè)系統(tǒng)都采用自身的分布式系統(tǒng)設(shè)計(jì)完成服務(wù)的管理和調(diào)度,并且執(zhí)行時(shí)服務(wù)會一直變化。以MapReduce為例,每個(gè)MR程序啟動Map或者Reduce工作任務(wù)的數(shù)量是由應(yīng)用本身來指定的(通過參數(shù)set mapreduce.reduce.tasks=N),調(diào)度器通過解析相關(guān)的參數(shù)來生成給定數(shù)量的工作任務(wù),并在相關(guān)的任務(wù)完成后立即銷毀。

      大數(shù)據(jù)系統(tǒng)內(nèi)的服務(wù)有自己的服務(wù)重啟或者遷移邏輯,并且其配置或參數(shù)可能會隨著應(yīng)用或用戶的輸入而變化,而很多組件之間有很長的依賴鏈,如何及時(shí)地將某個(gè)參數(shù)的變化推送到所有的下游服務(wù)中,是調(diào)度系統(tǒng)的一個(gè)重要挑戰(zhàn)。

      對于沒有數(shù)據(jù)存儲的無狀態(tài)服務(wù),容器有多種編排方式進(jìn)行編排和管理。但是對于有數(shù)據(jù)狀態(tài)的服務(wù),如數(shù)據(jù)庫(MySQL)或者分布式存儲服務(wù)(Hadoop distributed file system,HDFS),由于容器內(nèi)的數(shù)據(jù)會隨著容器的銷毀而銷毀,因此采用傳統(tǒng)的編排方式無法保證數(shù)據(jù)狀態(tài)的一致性和數(shù)據(jù)持久化。

      大數(shù)據(jù)和AI計(jì)算都涉及大量的數(shù)據(jù)和復(fù)雜的迭代運(yùn)算,為了達(dá)到更好的性能,MapReduce、Spark和TensorFlow在架構(gòu)中都特別注重“計(jì)算貼近數(shù)據(jù)”設(shè)計(jì),一般會根據(jù)數(shù)據(jù)的位置選擇啟動相應(yīng)的計(jì)算服務(wù),盡量讓計(jì)算任務(wù)和數(shù)據(jù)節(jié)點(diǎn)在同一個(gè)節(jié)點(diǎn)上,這樣就可以避免網(wǎng)絡(luò)帶寬帶來的性能損失。而在容器模式下,不同的服務(wù)封裝在不同的容器內(nèi),并且使用容器自身的網(wǎng)絡(luò);而容器網(wǎng)絡(luò)一般采用重疊網(wǎng)絡(luò)(overlay network)模式,因此容器內(nèi)的應(yīng)用并不能感知調(diào)度容器的機(jī)器的物理拓?fù)?,因此也就無法確定從哪個(gè)節(jié)點(diǎn)調(diào)度計(jì)算任務(wù)所在的容器。為此,重新設(shè)計(jì)了云網(wǎng)絡(luò)服務(wù),以有效解決相應(yīng)的調(diào)度信息缺失問題。

      另外,大數(shù)據(jù)或者AI應(yīng)用都是資源密集型應(yīng)用,在運(yùn)行時(shí)會對CPU、GPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等資源進(jìn)行動態(tài)申請和釋放。如某個(gè)應(yīng)用可能會根據(jù)用戶的輸入生成一個(gè)Spark的機(jī)器學(xué)習(xí)任務(wù),在大數(shù)據(jù)平臺上生成若干個(gè)執(zhí)行任務(wù)(executor),并申請一定的CPU和內(nèi)存資源。及時(shí)地響應(yīng)這些短生命周期服務(wù)的資源需求,是當(dāng)前各種原生云的調(diào)度系統(tǒng)無法有效支持的功能。

      4.2 融合大數(shù)據(jù)和AI的云調(diào)度系統(tǒng)的設(shè)計(jì)考量

      為了有效解決各種實(shí)際技術(shù)難題,重新設(shè)計(jì)云平臺的調(diào)度系統(tǒng)成為必須考慮和完成的工作。相較于原生的Kubernetes調(diào)度系統(tǒng),云平臺的調(diào)度系統(tǒng)需要從以下方面重新設(shè)計(jì)。

      (1)基于資源需求的調(diào)度能力

      整個(gè)云平臺的資源從邏輯上被抽象為一個(gè)大的資源池,按照CPU、GPU、內(nèi)存、存儲和網(wǎng)絡(luò)進(jìn)行分類管理。一個(gè)容器在被調(diào)度的時(shí)候,通過編排文件或者配置來描述相應(yīng)的資源需求。調(diào)度器需要根據(jù)資源池的實(shí)際資源情況和各個(gè)主機(jī)的物理資源情況,在毫秒級時(shí)延內(nèi)找到合適的物理節(jié)點(diǎn)來調(diào)度當(dāng)前容器。在超大規(guī)模的云集群里,調(diào)度器的效率、性能和負(fù)載均衡是重要的技術(shù)指標(biāo),最終會影響云平臺的資源使用率。

      (2)支持本地存儲并基于存儲感知的容器調(diào)度

      為了有效支持有狀態(tài)的服務(wù),如數(shù)據(jù)庫服務(wù)(MySQL)、分布式存儲服務(wù),本文設(shè)計(jì)了基于本地存儲的存儲服務(wù)。云儲存將所有的存儲資源抽象為一個(gè)存儲池,每個(gè)節(jié)點(diǎn)的本地存儲抽象為若干持久化存儲池(persistence volume group),而單個(gè)可以被容器申請的存儲資源定義為存儲卷(persistence volume,PV)。每個(gè)PV只能被一個(gè)容器掛載,可以是任意大小,支持硬盤驅(qū)動器(hard disk drive,HDD)或固態(tài)硬盤(solid state drive,SSD),也支持HDD與SSD組成的分層式存儲。有狀態(tài)的容器服務(wù)在啟動時(shí)會申請需要的PV資源(如大小、IOPS要求、SSD或HDD),調(diào)度器需要在毫秒內(nèi)從平臺內(nèi)找到合適的機(jī)器,從而將容器調(diào)度起來;如果容器因?yàn)楦鞣N原因不能正常工作,調(diào)度器能夠檢測到不健康的狀態(tài),同時(shí)根據(jù)數(shù)據(jù)的物理拓?fù)淝闆r,選擇合適的機(jī)器重啟相應(yīng)的容器。

      (3)網(wǎng)絡(luò)物理拓?fù)涞母兄c實(shí)時(shí)調(diào)度能力

      為了支持靈活彈性的調(diào)度,一般情況下云原生平臺為容器設(shè)計(jì)專門的網(wǎng)絡(luò)空間,并且一般與主機(jī)網(wǎng)絡(luò)保持透明。通常一個(gè)服務(wù)器節(jié)點(diǎn)上會有多個(gè)容器服務(wù),因此主機(jī)IP的數(shù)量遠(yuǎn)小于容器IP的數(shù)量。在MapReduce、Spark和TensorFlow的設(shè)計(jì)中,在啟動計(jì)算任務(wù)時(shí),會根據(jù)數(shù)據(jù)存儲的物理拓?fù)錄Q定最終服務(wù)啟動在哪個(gè)服務(wù)器上。但是在容器平臺上,所有的任務(wù)都只能感知容器網(wǎng)絡(luò),而不能感知物理機(jī)器的IP,無法了解數(shù)據(jù)分布的物理拓?fù)洌虼艘簿蜔o法保證計(jì)算和數(shù)據(jù)的局部性。為了解決這個(gè)問題,在調(diào)度系統(tǒng)內(nèi)增加了網(wǎng)絡(luò)物理拓?fù)淠K,實(shí)時(shí)地維護(hù)物理IP和容器IP的映射關(guān)系表。當(dāng)有狀態(tài)服務(wù)在申請調(diào)度的時(shí)候,可以通過IP映射表找到可用于最終調(diào)度的物理機(jī)器。

      (4)動態(tài)標(biāo)簽?zāi)芰εc基于標(biāo)簽的調(diào)度能力

      復(fù)雜的應(yīng)用系統(tǒng)對調(diào)度系統(tǒng)有更多細(xì)節(jié)的要求,如多租戶業(yè)務(wù)系統(tǒng)往往要求一個(gè)租戶的所有服務(wù)盡量調(diào)度在同一批物理機(jī)器中;支持高可用的服務(wù)往往要求調(diào)度系統(tǒng)有反親和性(anti-affinity)要求,即將一個(gè)服務(wù)的多個(gè)實(shí)例調(diào)度到不同的物理機(jī)器上,這樣就不會發(fā)生一個(gè)物理機(jī)器宕機(jī)后影響多個(gè)高可用實(shí)例,進(jìn)而導(dǎo)致服務(wù)不可用的情況。因此在調(diào)度系統(tǒng)中增加了動態(tài)標(biāo)簽?zāi)芰突跇?biāo)簽的調(diào)度能力,調(diào)度模塊可以根據(jù)運(yùn)行時(shí)的數(shù)據(jù)給物理機(jī)器和容器應(yīng)用動態(tài)增加或刪除標(biāo)簽,而調(diào)度系統(tǒng)根據(jù)標(biāo)簽的匹配度選擇更合適的調(diào)度策略。

      (5)應(yīng)用依賴運(yùn)行參數(shù)的感知以及基于參數(shù)的調(diào)度能力

      分布式應(yīng)用在微服務(wù)拆分后,每個(gè)服務(wù)都有比較復(fù)雜的依賴服務(wù)鏈以及影響的服務(wù)鏈,而每個(gè)微服務(wù)在運(yùn)行時(shí)都可能發(fā)生運(yùn)行參數(shù)變化、服務(wù)啟停、重新調(diào)度等操作,這些變化不僅影響當(dāng)前的微服務(wù),還可能影響所有的依賴鏈的服務(wù)。因此調(diào)度系統(tǒng)中增加了應(yīng)用配置感知模塊,通過與全局的配置中心的數(shù)據(jù)交互,調(diào)度系統(tǒng)能夠?qū)崟r(shí)地感知一個(gè)應(yīng)用變化的事件的所有影響情況,并根據(jù)多個(gè)可能的狀態(tài)遷移圖選擇最合適的調(diào)度策略。

      (6)不同優(yōu)先級下基于搶占的調(diào)度能力

      在業(yè)務(wù)負(fù)載比較重并可能超過云系統(tǒng)內(nèi)資源總量的時(shí)候,需要有機(jī)制保證高優(yōu)先級的服務(wù)正常運(yùn)行,犧牲低優(yōu)先級應(yīng)用的服務(wù)質(zhì)量,也就是服務(wù)質(zhì)量等級保證(service level agreement,SLA),這是云平臺的一個(gè)重要特性。在調(diào)度系統(tǒng)內(nèi)增加了基于搶占的調(diào)度模式,將服務(wù)和資源按照優(yōu)先級進(jìn)行區(qū)分,如果出現(xiàn)資源不足以調(diào)度高優(yōu)先級應(yīng)用的情況,則通過搶占的方式調(diào)度低優(yōu)先級應(yīng)用的資源。

      5 融合大數(shù)據(jù)和AI的云調(diào)度系統(tǒng)的實(shí)現(xiàn)

      類似于操作系統(tǒng)的調(diào)度模塊,云平臺的調(diào)度是整個(gè)云平臺能夠有效運(yùn)行的關(guān)鍵技術(shù)。云平臺的總體架構(gòu)如圖2所示,最底層是Kubernetes服務(wù),其上層運(yùn)行著自研的幾個(gè)產(chǎn)品或服務(wù)。其中,配置中心用于實(shí)時(shí)地收集和管理云平臺內(nèi)運(yùn)行的所有服務(wù)的配置參數(shù),支持運(yùn)維人員手動地對一些服務(wù)進(jìn)行參數(shù)設(shè)置或管理;物理資源池是通過各個(gè)服務(wù)進(jìn)行池化后的邏輯資源,應(yīng)用申請的物理資源都會從這個(gè)資源池中邏輯地劃分出去,在應(yīng)用使用完結(jié)后再返還給資源池,平臺會給不同的租戶做資源配額限制;云存儲服務(wù)是基于本地存儲開發(fā)的分布式存儲服務(wù),會保留狀態(tài)服務(wù)的數(shù)據(jù),保證應(yīng)用數(shù)據(jù)的最終持久化和災(zāi)備能力;云網(wǎng)絡(luò)服務(wù)是自研的網(wǎng)絡(luò)服務(wù),提供應(yīng)用和租戶類似虛擬私有云(virtual private cloud,VPC)的網(wǎng)絡(luò)能力,可以做到完整的資源隔離和服務(wù)等級協(xié)議(service level agreement,SLA)管控;標(biāo)簽中心用于實(shí)時(shí)地收集和管理各個(gè)應(yīng)用、主機(jī)、資源的標(biāo)簽,支持動態(tài)的標(biāo)簽修改與實(shí)時(shí)調(diào)度觸發(fā)。

      在此之上是云調(diào)度系統(tǒng),它接收應(yīng)用的輸入,從配置中心、標(biāo)簽中心、云存儲服務(wù)和云網(wǎng)絡(luò)服務(wù)中實(shí)時(shí)獲取平臺運(yùn)行指標(biāo),并從物理資源池中獲取資源的使用情況,從而根據(jù)運(yùn)行時(shí)的信息進(jìn)行精確的調(diào)度決策。云調(diào)度系統(tǒng)之上是各類應(yīng)用服務(wù),包括大數(shù)據(jù)、AI、數(shù)據(jù)庫類以及各種微服務(wù)。

      5.1 調(diào)度系統(tǒng)架構(gòu)

      本文設(shè)計(jì)的云平臺的調(diào)度系統(tǒng)的內(nèi)部架構(gòu)如圖3所示,包含元信息模塊、對外服務(wù)模塊以及調(diào)度決策模塊。當(dāng)一個(gè)應(yīng)用通過Kubernetes API或者命令行(基于Kubectl)的方式啟動時(shí),它會傳入一個(gè)指定服務(wù)編排方式的yaml文件以及啟動應(yīng)用需要的容器鏡像(docker image)。在yaml文件中會指定當(dāng)前應(yīng)用需要的資源、與調(diào)度相關(guān)的標(biāo)注信息(或標(biāo)簽信息)以及對其他應(yīng)用的依賴關(guān)系。

      對外服務(wù)模塊負(fù)責(zé)解析編排文件,同時(shí)負(fù)責(zé)完成應(yīng)用的依賴解析和管理,生成對服務(wù)的依賴圖;參數(shù)計(jì)算模塊負(fù)責(zé)編排文件中與配置變量相關(guān)的計(jì)算,并生成最終的資源需求;實(shí)例渲染模塊最終生成一個(gè)完整的應(yīng)用描述,并將這個(gè)描述文件提交給調(diào)度決策模塊。

      元信息模塊負(fù)責(zé)與Kubernetes平臺交互,實(shí)時(shí)地維護(hù)用于調(diào)度的各種元數(shù)據(jù)。資源池?cái)?shù)據(jù)主要包括當(dāng)前集群的各種資源總量以及當(dāng)前的使用情況,并可以精細(xì)到各個(gè)節(jié)點(diǎn)和硬盤級別;網(wǎng)絡(luò)拓?fù)淠K負(fù)責(zé)與容器網(wǎng)絡(luò)進(jìn)行交互,實(shí)時(shí)地維護(hù)當(dāng)前容器網(wǎng)絡(luò)與主機(jī)網(wǎng)絡(luò)的拓?fù)?;存儲拓?fù)淠K負(fù)責(zé)與云存儲服務(wù)交互,實(shí)時(shí)記錄當(dāng)前存儲池的各個(gè)存儲卷(PV)的容量使用情況和每秒進(jìn)行讀寫操作的次數(shù)(input/output operations per second,IOPS);服務(wù)運(yùn)行指標(biāo)主要同步當(dāng)前集群各個(gè)物理節(jié)點(diǎn)上各個(gè)容器的運(yùn)行指標(biāo)以及各個(gè)物理機(jī)的各項(xiàng)資源的使用指標(biāo);配置元數(shù)據(jù)模塊主要協(xié)助配置中心維護(hù)各個(gè)應(yīng)用的實(shí)時(shí)配置參數(shù)。因此,通過元信息模塊,調(diào)度器能夠維護(hù)當(dāng)前云平臺的各種調(diào)度決策數(shù)據(jù),從而實(shí)時(shí)地根據(jù)運(yùn)行數(shù)據(jù)進(jìn)行最優(yōu)化調(diào)度。

      在對外服務(wù)模塊提交了實(shí)時(shí)渲染的應(yīng)用描述請求后,調(diào)度決策模塊會根據(jù)請求中的資源大小,通過內(nèi)部的6個(gè)調(diào)度器進(jìn)行調(diào)度目標(biāo)的選擇。依賴調(diào)度器會解析應(yīng)用的需求,同時(shí)遍歷當(dāng)前的服務(wù)元數(shù)據(jù),查找是否有已經(jīng)運(yùn)行的可以給當(dāng)前應(yīng)用依賴的微服務(wù)。如果有,則直接使用該服務(wù),并更新相應(yīng)的配置參數(shù);如果沒有,則解析被依賴的服務(wù)的參數(shù),同時(shí)選擇運(yùn)行一遍完整的調(diào)度流程。如果有嵌套服務(wù)依賴,則遞歸調(diào)用相關(guān)的調(diào)度邏輯,直至所有依賴鏈的服務(wù)都處于運(yùn)行狀態(tài)。存儲調(diào)度器提供基于存儲感知的容器調(diào)度能力,它會解析應(yīng)用是否有明確的本地?cái)?shù)據(jù)的要求,如果有,則從存儲拓?fù)渲姓业胶线m的物理節(jié)點(diǎn)組,并將其他節(jié)點(diǎn)標(biāo)記為此次調(diào)度無效;資源調(diào)度器負(fù)責(zé)找到有足夠資源啟動應(yīng)用或者容器的物理節(jié)點(diǎn)組;網(wǎng)絡(luò)調(diào)度器負(fù)責(zé)根據(jù)應(yīng)用的網(wǎng)絡(luò)IP要求選擇滿足網(wǎng)絡(luò)規(guī)則的物理節(jié)點(diǎn)組;標(biāo)簽調(diào)度器負(fù)責(zé)選擇滿足各種標(biāo)簽規(guī)則的物理節(jié)點(diǎn)組。通過這5個(gè)調(diào)度器選擇的物理節(jié)點(diǎn)如果有多個(gè),調(diào)度器則根據(jù)負(fù)載均衡的原則選擇合適的物理節(jié)點(diǎn),從而啟動這個(gè)容器;如果沒有任何節(jié)點(diǎn)有足夠的資源,SLA調(diào)度器會遍歷被選擇指定節(jié)點(diǎn)上已經(jīng)在運(yùn)行的所有容器,找到當(dāng)前被優(yōu)先級更低的應(yīng)用占用的容器,并選擇kill等機(jī)制,循環(huán)此操作,直到資源滿足本次調(diào)度為止,從而實(shí)現(xiàn)高優(yōu)先級應(yīng)用的搶占式調(diào)度策略。

      5.2 服務(wù)的編排系統(tǒng)

      應(yīng)用服務(wù)的調(diào)度需求包含依賴的服務(wù)、服務(wù)自身的Docker鏡像、資源需求、網(wǎng)絡(luò)與存儲需求、配置參數(shù)等各個(gè)方面的屬性,因此選擇Jsonnet語言進(jìn)行應(yīng)用的資源描述文件。Jsonnet是Google公司開源的新一代JSON協(xié)議,支持引用、算術(shù)運(yùn)算、條件操作符、函數(shù)、變量、繼承等強(qiáng)大的計(jì)算能力,可以描述多樣化的需求。

      一個(gè)簡單的基于Jsonnet的資源編排文件示例如圖4所示。其中app.yaml 描述依賴關(guān)系和依賴變量,config.jsonnet描述配置參數(shù)和定義輸入,而customizemain.jsonnet 定義模板入口和輸出變量。在運(yùn)行時(shí),通過服務(wù)模塊的實(shí)例渲染組件即可將這些編排文件和當(dāng)前平臺內(nèi)的運(yùn)行參數(shù)進(jìn)行實(shí)例化,渲染出一個(gè)可以被Kubernetes調(diào)度的service/replication controller或者deployment的描述文件。

      5.3 配置標(biāo)簽中心

      由于每個(gè)服務(wù)運(yùn)行時(shí)都可能發(fā)生重啟或者遷移,且API網(wǎng)關(guān)等可能會動態(tài)地設(shè)置運(yùn)行參數(shù),為了讓服務(wù)能夠及時(shí)地感知各種運(yùn)行參數(shù),創(chuàng)建了一個(gè)統(tǒng)一的配置標(biāo)簽中心作為中心化的服務(wù),提供配置和標(biāo)簽元數(shù)據(jù)的管理和查詢。應(yīng)用程序使用的配置基于Kubernetes ConfigMap的方式來實(shí)現(xiàn)配置與容器鏡像的解耦。ConfigMap的示例如圖5所示,包含了標(biāo)簽和數(shù)據(jù)屬性,都是以鍵-值數(shù)據(jù)對的方式來保存的。容器可以直接引用相應(yīng)的ConfigMap中的數(shù)據(jù),而這些配置數(shù)據(jù)則存儲在配置標(biāo)簽中心服務(wù)中。用戶可以通過界面或者命令行的方式修改配置的數(shù)值或者增加新的鍵-值對,并且當(dāng)有任何配置數(shù)據(jù)修改后,Kubernetes會動態(tài)地修改每個(gè)節(jié)點(diǎn)的ConfigMap文件,并在短時(shí)間內(nèi)讓容器知曉相應(yīng)的數(shù)據(jù)變化,從而實(shí)現(xiàn)中心化的動態(tài)配置和標(biāo)簽修改。

      由于配置和標(biāo)簽中心服務(wù)中包含了運(yùn)行時(shí)的各種配置和標(biāo)簽數(shù)據(jù),因此調(diào)度器通過與配置標(biāo)簽中心交互就可以獲取整個(gè)云平臺的標(biāo)簽和配置元數(shù)據(jù),從而可以支持基于標(biāo)簽的調(diào)度能力。

      5.4 云存儲服務(wù)

      云平臺中的存儲服務(wù)Warpdrive提供一個(gè)中心化的RESTful服務(wù),可以支持外部服務(wù)對存儲卷的實(shí)際使用情況的實(shí)時(shí)查詢,因此調(diào)度器通過監(jiān)聽相關(guān)的接口來實(shí)時(shí)感知每個(gè)主機(jī)的存儲卷使用情況以及每個(gè)容器與物理節(jié)點(diǎn)的綁定關(guān)系。

      5.5 云網(wǎng)絡(luò)服務(wù)

      網(wǎng)絡(luò)服務(wù)也同樣提供RESTful API查詢服務(wù),使得調(diào)度器可以知曉各個(gè)容器IP和物理IP的使用情況以及各個(gè)容器的網(wǎng)絡(luò)防火墻規(guī)則等實(shí)時(shí)數(shù)據(jù),因此調(diào)度器能夠?qū)崟r(shí)地感知云平臺內(nèi)的網(wǎng)絡(luò)和存儲實(shí)際運(yùn)行情況。

      5.6 計(jì)算調(diào)度過程中的數(shù)據(jù)拓?fù)涓兄?/h3>

      在容器云計(jì)算環(huán)境下,分布式網(wǎng)絡(luò)中的各個(gè)主機(jī)可以是一個(gè)或多個(gè)獨(dú)立的網(wǎng)絡(luò),每個(gè)網(wǎng)絡(luò)都可以包括一個(gè)或多個(gè)子網(wǎng)絡(luò),網(wǎng)絡(luò)地址從該主機(jī)上的子網(wǎng)絡(luò)中獲得。當(dāng)容器銷毀時(shí),容器的網(wǎng)絡(luò)地址被回收,等待下次使用。

      應(yīng)用感知數(shù)據(jù)拓?fù)涞姆绞饺鐖D6所示,當(dāng)容器中的數(shù)據(jù)應(yīng)用(如Spark應(yīng)用)需要啟動計(jì)算任務(wù)時(shí),調(diào)度器首先根據(jù)該服務(wù)的依賴關(guān)系找到其需要的數(shù)據(jù)應(yīng)用的容器(如HDFS數(shù)據(jù)節(jié)點(diǎn)),然后通過元信息模塊查詢其所在的物理節(jié)點(diǎn)的網(wǎng)絡(luò)和存儲信息。元信息模塊通過對存儲服務(wù)和網(wǎng)絡(luò)服務(wù)的實(shí)時(shí)查詢來獲取和維護(hù)最新的元數(shù)據(jù)。一般情況下,分布式存儲有多個(gè)存儲副本,會通過調(diào)度器的反親和性保證調(diào)度在不同的物理節(jié)點(diǎn)上,因此調(diào)度器會得到一個(gè)物理節(jié)點(diǎn)的列表。然后根據(jù)這幾個(gè)節(jié)點(diǎn)的實(shí)際資源使用負(fù)載情況,選擇當(dāng)前資源負(fù)載最低的節(jié)點(diǎn)來啟動對應(yīng)的計(jì)算服務(wù)容器。由于兩個(gè)容器都在一個(gè)主機(jī)上,計(jì)算服務(wù)可以與存儲服務(wù)通過本地網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳輸,或者創(chuàng)建域套接字(domain socket)等機(jī)制來提高數(shù)據(jù)讀取速度,增強(qiáng)性能。

      在云平臺集群規(guī)模比較大的情況下,網(wǎng)絡(luò)IP數(shù)量和網(wǎng)段數(shù)量都比較大,而應(yīng)用查詢的請求也有很高的并發(fā)度。為了保證高速的網(wǎng)絡(luò)檢索能力,使用基數(shù)樹(radix tree)對各個(gè)應(yīng)用的網(wǎng)絡(luò)配置信息進(jìn)行緩存,基于基數(shù)樹的快速匹配方法如圖7所示。查詢網(wǎng)絡(luò)地址172.16.1.23,對應(yīng)的二進(jìn)制是10101100000100000000000100 010111,在基數(shù)樹中可以很快匹配到對應(yīng)的子網(wǎng)為172.16.1.0/24,并從該子網(wǎng)獲取所有必需的網(wǎng)絡(luò)信息,包括容器網(wǎng)段、主機(jī)信息、交換機(jī)號以及機(jī)架位等。

      5.7 調(diào)度的總體流程

      對于調(diào)度策略模塊,它的輸入是應(yīng)用的資源需求、標(biāo)簽屬性、依賴關(guān)系和輸入輸出參數(shù)等信息,輸出是選定的物理節(jié)點(diǎn)或者節(jié)點(diǎn)組以及對應(yīng)的容器的優(yōu)先級信息,同時(shí),依賴元數(shù)據(jù)模塊提供的平臺運(yùn)行數(shù)據(jù)進(jìn)行調(diào)度決策支撐。調(diào)度器的決策流程如圖8所示。

      調(diào)度器從任務(wù)調(diào)度隊(duì)列獲取待調(diào)度的任務(wù),形成節(jié)點(diǎn)-任務(wù)映射表。其中,調(diào)度器持續(xù)對API服務(wù)器中創(chuàng)建的任務(wù)進(jìn)行監(jiān)聽,并讀取新的任務(wù)形成任務(wù)調(diào)度隊(duì)列。

      (1)篩選階段

      調(diào)度器根據(jù)映射表以及預(yù)設(shè)篩選條件確定一組符合條件的目標(biāo)物理節(jié)點(diǎn)。其中,預(yù)設(shè)篩選條件可以是當(dāng)前任務(wù)所需的資源與物理節(jié)點(diǎn)上的剩余資源之間的匹配條件、當(dāng)前任務(wù)所需的端口與物理節(jié)點(diǎn)上的端口之間的匹配條件以及是否帶有特殊標(biāo)簽等。如果當(dāng)前任務(wù)配置了對持久化存儲的需求或者對數(shù)據(jù)拓?fù)涞母兄?,調(diào)度器也會考慮滿足這些條件的節(jié)點(diǎn)。最終調(diào)度器會將滿足上述所有篩選條件的節(jié)點(diǎn)整理出來進(jìn)行下一步處理。

      (2)優(yōu)選階段

      調(diào)度器根據(jù)篩選階段拿到的節(jié)點(diǎn)以及預(yù)設(shè)優(yōu)選條件對各個(gè)物理節(jié)點(diǎn)進(jìn)行評分,最終選擇分?jǐn)?shù)最高的作為目標(biāo)物理節(jié)點(diǎn)。其中優(yōu)選條件包括:節(jié)點(diǎn)空閑資源越多,評分越高;節(jié)點(diǎn)保存的任務(wù)鏡像越多,評分越高;任務(wù)親和性/反親和性越匹配,評分越高;同類任務(wù)分布越均勻,評分越高等。

      通過上述兩次篩選,選擇出一個(gè)分?jǐn)?shù)最高的物理節(jié)點(diǎn)。調(diào)度器將當(dāng)前任務(wù)與目標(biāo)物理節(jié)點(diǎn)綁定,并將綁定的信息發(fā)送到API服務(wù)器。

      5.8 基于優(yōu)先級的搶占式調(diào)度方法

      在平臺的資源不足而有更高優(yōu)先級的服務(wù)需要被調(diào)度的情況下,調(diào)度器就需要進(jìn)行搶占式調(diào)度。在目前的實(shí)現(xiàn)中,搶占式調(diào)度提供了2種方式:調(diào)度階段的資源搶占和運(yùn)行階段的資源搶占。

      調(diào)度階段的資源搶占即在調(diào)度器篩選節(jié)點(diǎn)階段,如果發(fā)現(xiàn)集群中所有節(jié)點(diǎn)都無法滿足當(dāng)前任務(wù)的資源需求,調(diào)度器會在集群中選擇節(jié)點(diǎn),并試圖搶占其中正在運(yùn)行的低優(yōu)先級的任務(wù)的節(jié)點(diǎn)。搶占完成后,調(diào)度器會再次嘗試調(diào)度當(dāng)前任務(wù)到目標(biāo)節(jié)點(diǎn)上。調(diào)度階段的資源搶占策略如圖9所示。

      調(diào)度階段的資源搶占實(shí)際上是一種邏輯層面的搶占,依據(jù)是任務(wù)在啟動時(shí)聲明的資源請求,它可以幫助系統(tǒng)避免任何資源超配的現(xiàn)象,但同時(shí)也會造成一定程度的資源浪費(fèi)。比如一個(gè)聲明了10 core CPU的任務(wù)可能當(dāng)前只消耗了2 core CPU,此時(shí)完全不需要搶占掉,它也可以讓別的任務(wù)運(yùn)行起來?;诖朔N考慮,又引入了運(yùn)行階段的資源搶占算法,如圖10所示。運(yùn)行階段的資源搶占的主線程邏輯如圖11所示。

      運(yùn)行階段的資源搶占會忽略優(yōu)先級低于當(dāng)前任務(wù)的任務(wù),即如果有必要,可以完全搶占這些低優(yōu)先級的任務(wù),因此它們不在節(jié)點(diǎn)資源消耗的統(tǒng)計(jì)范圍內(nèi)。搶占階段發(fā)生在物理節(jié)點(diǎn)上,當(dāng)物理節(jié)點(diǎn)發(fā)現(xiàn)某種資源剩余小于預(yù)期值時(shí),會對其上低優(yōu)先級的任務(wù)進(jìn)行清除,直到物理節(jié)點(diǎn)狀態(tài)恢復(fù)正常。此種搶占方式基于物理節(jié)點(diǎn)的資源真實(shí)使用情況,可以保證集群資源利用最大化。

      6 實(shí)驗(yàn)評估

      為了驗(yàn)證數(shù)據(jù)應(yīng)用尤其是大數(shù)據(jù)計(jì)算在云平臺上有良好的性能表現(xiàn),選擇了3個(gè)基準(zhǔn)測試程序來驗(yàn)證所設(shè)計(jì)實(shí)現(xiàn)的系統(tǒng)的性能。

      ● TestDFSIO是Hadoop自帶的性能測試工具,主要為了測試Apache HDFS的I/O性能,采用MapReduce程序進(jìn)行并發(fā)讀寫并做結(jié)果統(tǒng)計(jì),主要涉及讀、隨機(jī)讀、追加寫、寫等業(yè)務(wù)行為。

      ● HBase Performance Evaluation[16]是Apache HBase自帶的性能測試工具,提供了順序讀寫、隨機(jī)讀寫、掃描等性能測試。

      ● TPC-DS[17]是事物處理性能委員會(Transaction Processing Performance Council,TPC)推出的用于數(shù)據(jù)決策支持系統(tǒng)的基準(zhǔn)測試,包含對大數(shù)據(jù)集的統(tǒng)計(jì)、報(bào)表生成、聯(lián)機(jī)查詢、數(shù)據(jù)挖掘等復(fù)雜應(yīng)用,包含了7張事實(shí)表、17張維度表和99個(gè)復(fù)雜SQL,是一個(gè)典型的數(shù)據(jù)倉庫的測試場景,可以用于衡量大數(shù)據(jù)分析數(shù)據(jù)庫的性能和魯棒性。

      選定好基準(zhǔn)測試后,在50臺x86服務(wù)器上部署了云平臺,并且創(chuàng)建了3個(gè)不同的租戶用于測試,每個(gè)租戶都將部署Hadoop服務(wù)以及分析數(shù)據(jù)庫Inceptor,HBase分片服務(wù)器、HDFS數(shù)據(jù)節(jié)點(diǎn)和Inceptor任務(wù)執(zhí)行節(jié)點(diǎn)都有8個(gè)實(shí)例。本次測試的設(shè)計(jì)目標(biāo)和期望結(jié)果見表1。

      ● 第一個(gè)租戶:通過修改標(biāo)簽中心的配置參數(shù)讓其所有的服務(wù)只能在節(jié)點(diǎn)1~10上調(diào)度。

      ● 第二個(gè)租戶:通過修改標(biāo)簽中心的配置參數(shù)讓其可以在平臺的50臺機(jī)器上調(diào)度,同時(shí)設(shè)置其優(yōu)先級比其他微服務(wù)的優(yōu)先級高。

      ● 第三個(gè)租戶和第二個(gè)租戶配置相同,也可以在50臺機(jī)器上調(diào)度,但是通過修改云平臺的調(diào)度測試,讓其使用Kubernetes原生的調(diào)度系統(tǒng),為了解決開源Kubernetes平臺沒有本地存儲的問題,在所有的節(jié)點(diǎn)上都部署了同樣的數(shù)據(jù),保證任何調(diào)度到其他節(jié)點(diǎn)機(jī)器上的服務(wù)都能讀到數(shù)據(jù),從而確保測試可以正常運(yùn)行。

      ● 在8個(gè)節(jié)點(diǎn)的裸機(jī)上部署了Hadoop服務(wù)和Inceptor,采用主機(jī)的方式部署,每個(gè)節(jié)點(diǎn)上部署數(shù)據(jù)節(jié)點(diǎn)、HBase分片服務(wù)器和Inceptor任務(wù)執(zhí)行節(jié)點(diǎn),所有的數(shù)據(jù)和計(jì)算服務(wù)都預(yù)先按照物理拓?fù)鋭澏ê?,因此沒有其他的調(diào)度開銷。

      本文沒有單獨(dú)針對調(diào)度系統(tǒng)的每個(gè)設(shè)計(jì)指標(biāo)進(jìn)行測試,這些設(shè)計(jì)能力都會在這個(gè)綜合的性能測試?yán)锉或?yàn)證,如基于資源需求的調(diào)度能力、應(yīng)用依賴和運(yùn)行參數(shù)感知能力,因?yàn)榇髷?shù)據(jù)平臺本身是分布式系統(tǒng),多個(gè)服務(wù)之間存在互相依賴(如HDFS依賴ZooKeeper)的關(guān)系,每個(gè)服務(wù)通過自己的編排文件指定自己需要的硬件資源以及依賴的服務(wù),如果不具備這方面的能力,大數(shù)據(jù)服務(wù)就無法在平臺上運(yùn)行起來?;诰W(wǎng)絡(luò)拓?fù)浜臀锢泶鎯Φ恼{(diào)度能力以及不同優(yōu)先級的搶占能力會比較多地在性能測試結(jié)果中反映出來。

      表1 測試項(xiàng)的設(shè)計(jì)原則與期望結(jié)果

      按照預(yù)期,主機(jī)部署的模式應(yīng)該是性能最好的方式,其次是租戶1,因?yàn)樗荒茉谳^少的節(jié)點(diǎn)內(nèi)調(diào)度,發(fā)生計(jì)算數(shù)據(jù)分離的概率比較??;租戶2和租戶3在50個(gè)節(jié)點(diǎn)內(nèi)有8個(gè)數(shù)據(jù)節(jié)點(diǎn),如果不用新的調(diào)度算法,發(fā)生計(jì)算和數(shù)據(jù)偏離的可能性比較大,但是期望租戶2的性能比較好,可以接近租戶1,因?yàn)檎{(diào)度系統(tǒng)可以支持計(jì)算來感知數(shù)據(jù),而租戶3的性能會比較差,因?yàn)闆]有數(shù)據(jù)本地性的保證。

      最終的測試結(jié)果如圖12所示,基本符合預(yù)期。在裸機(jī)上部署的集群在3個(gè)測試?yán)锏男阅芏际亲罴训模蛔鈶?和租戶2的3個(gè)測試的性能數(shù)據(jù)不相上下(差異可以認(rèn)為是數(shù)據(jù)波動),說明本文的調(diào)度算法有很好的可擴(kuò)展性,在集群規(guī)模擴(kuò)大5倍后可以保證性能沒有損失;租戶3的性能要差很多,因?yàn)橛?jì)算任務(wù)和數(shù)據(jù)分布是無序的,所以有很多遠(yuǎn)程讀寫帶來的性能損失。實(shí)驗(yàn)證明,有效的調(diào)度系統(tǒng)可以在保證云平臺的靈活性和彈性的同時(shí),提供和物理平臺部署一樣的性能。

      7 結(jié)束語

      目前工業(yè)界在如何解決大數(shù)據(jù)和AI應(yīng)用在云上的開發(fā)和部署問題上,基本分為3種。

      第一種是采用應(yīng)用或者服務(wù)內(nèi)多租戶的方式提供云服務(wù),即一個(gè)數(shù)據(jù)庫或者AI服務(wù)的實(shí)例給用戶提供服務(wù),用戶之間的隔離由數(shù)據(jù)庫或者AI平臺來提供,而不是由云平臺提供。比較典型的有AWS Aurora或者Google Cloud AutoML等產(chǎn)品。這類解決方案靈活性不高,而且由于本身計(jì)算復(fù)雜度不高或者通過SaaS服務(wù)的方式規(guī)避了復(fù)雜業(yè)務(wù)的提交,因此也可以適應(yīng)業(yè)務(wù)的需求。但是這兩類產(chǎn)品更偏向于一類應(yīng)用,而不是通用的大數(shù)據(jù)或者數(shù)據(jù)庫平臺,因此這種方式雖然解決了部署的問題,但是不通用,只能由云服務(wù)的運(yùn)營商來提供相應(yīng)的解決方案。

      第二種是在云平臺中使用單獨(dú)的裸金屬機(jī)器提供大數(shù)據(jù)或者AI服務(wù),這樣可以保證大數(shù)據(jù)或者AI平臺的性能,但是同時(shí)放棄了對彈性或者靈活性的要求,因此這部分裸金屬機(jī)器并不能實(shí)現(xiàn)良好的彈性調(diào)度和高效的運(yùn)維能力。

      第三種是容器平臺只負(fù)責(zé)調(diào)度微服務(wù)等無狀態(tài)類應(yīng)用,而大數(shù)據(jù)、AI平臺運(yùn)行在傳統(tǒng)的基于虛擬化的云上。這樣可以保證良好的調(diào)度能力,但是犧牲了大數(shù)據(jù)或者AI平臺的穩(wěn)定性。這個(gè)方法最簡單,但是在現(xiàn)實(shí)案例中也發(fā)現(xiàn)這個(gè)方法因?yàn)榉€(wěn)定性等問題,幾乎沒有成功的落地案例。

      本文討論了與以上3種云調(diào)度方案完全不同的全新的方式,即如何在容器云平臺上實(shí)現(xiàn)一個(gè)支持復(fù)雜的大數(shù)據(jù)和AI平臺服務(wù)的調(diào)度系統(tǒng),既能保證復(fù)雜的平臺應(yīng)用的性能,又能夠有很好的調(diào)度靈活性和運(yùn)維便利性。從實(shí)驗(yàn)結(jié)果來看,本文的設(shè)計(jì)最終在生產(chǎn)平臺上取得了符合預(yù)期的業(yè)務(wù)性能數(shù)據(jù),也證明了這個(gè)調(diào)度方法的有效性。不過受限于本系統(tǒng)的工程背景,本文是在實(shí)踐中逐步優(yōu)化了本調(diào)度系統(tǒng),而不是從理論上根據(jù)調(diào)度系統(tǒng)的各個(gè)指標(biāo)來設(shè)計(jì)系統(tǒng)。另外由于業(yè)務(wù)需求的驅(qū)動,本文的設(shè)計(jì)強(qiáng)調(diào)數(shù)據(jù)的局部性和決策的實(shí)時(shí)性,要求所有的調(diào)度決策在毫秒級完成,弱化了調(diào)度的公平性設(shè)計(jì),而另外一些調(diào)度算法更側(cè)重公平性[18]。

      從另外一個(gè)維度,本文提出的調(diào)度系統(tǒng)的設(shè)計(jì)目標(biāo)是給應(yīng)用提供更好的性能,因此會犧牲一些其他的指標(biāo),如低優(yōu)先級任務(wù)的可靠性。如為了在有數(shù)據(jù)節(jié)點(diǎn)的服務(wù)器上調(diào)度計(jì)算任務(wù),會增加搶占對應(yīng)節(jié)點(diǎn)上其他低優(yōu)先級服務(wù)的概率,因而需要云平臺上的微服務(wù)有更好的容錯能力??紤]到計(jì)算任務(wù)也會有一些數(shù)據(jù)的操作,根據(jù)HDFS的特性,一般情況下在有更多計(jì)算任務(wù)的節(jié)點(diǎn)上就可能有更多的數(shù)據(jù)寫入,這就要求平臺對數(shù)據(jù)的生命周期有良好的管理能力,否則可能會有部分節(jié)點(diǎn)數(shù)據(jù)量越積越多,從而使得整個(gè)云平臺出現(xiàn)數(shù)據(jù)分布不均衡的情況,需要定期進(jìn)行人為觸發(fā)的重新平衡行為。

      本文主要描述了一個(gè)適用于容器云平臺的調(diào)度系統(tǒng),它通過實(shí)時(shí)獲取Kubernetes集群的各種資源數(shù)據(jù),結(jié)合數(shù)據(jù)和計(jì)算的拓?fù)涮匦?,可以在容器平臺上有效地支持大數(shù)據(jù)與人工智能的應(yīng)用和服務(wù),在帶來彈性和靈活性的同時(shí),提供了與裸機(jī)部署相同的性能,能夠同時(shí)提供云計(jì)算的彈性和大數(shù)據(jù)的計(jì)算能力。通過有效的調(diào)度設(shè)計(jì),基于容器的云平臺不僅可以用于微服務(wù)類應(yīng)用的DevOps支持,還可以用于大數(shù)據(jù)平臺以及應(yīng)用的開發(fā)和部署,支持大規(guī)模數(shù)據(jù)服務(wù)和AI服務(wù)的自動化部署和靈活調(diào)度。云計(jì)算提供基礎(chǔ),大數(shù)據(jù)提供生產(chǎn)資料,AI提供價(jià)值輸出,因此,能夠同時(shí)支持大數(shù)據(jù)+AI的云平臺是未來的趨勢,也是下一代數(shù)據(jù)中心的技術(shù)基礎(chǔ)平臺。

      大規(guī)模的云平臺調(diào)度是一個(gè)非常復(fù)雜的技術(shù)問題,需要反復(fù)的基于經(jīng)驗(yàn)的調(diào)優(yōu)和迭代才能夠達(dá)到比較好的效果。本文的方法和實(shí)驗(yàn)是對多個(gè)實(shí)際運(yùn)行項(xiàng)目中積累的觀測數(shù)據(jù)和性能指標(biāo)進(jìn)行迭代而最終成型的,目前本文的調(diào)度系統(tǒng)主要調(diào)優(yōu)的場景是大數(shù)據(jù)平臺服務(wù)(如Spark、Hadoop、TensorFlow等)以及數(shù)據(jù)分析類微服務(wù)(如各種分析類報(bào)表、實(shí)時(shí)事件分析、在線模型等)在云平臺上的混合部署場景,而沒有考慮更多的復(fù)雜的服務(wù)混合場景(如復(fù)雜的OLTP數(shù)據(jù)庫業(yè)務(wù)),因此在其他的云業(yè)務(wù)場景下可能還有迭代的過程。希望在下一階段引入更多的負(fù)載場景使得調(diào)度算法更加通用化。

      如何將人工智能應(yīng)用在調(diào)度系統(tǒng)中是另外一個(gè)有價(jià)值的研究方向,調(diào)度系統(tǒng)能夠監(jiān)控當(dāng)前云平臺的各種資源指標(biāo)以及服務(wù)的性能指標(biāo),可以通過對歷史調(diào)度數(shù)據(jù)引入AI分析能力,對各個(gè)服務(wù)進(jìn)行畫像(如其生命周期可以分為活躍時(shí)間段和非活躍時(shí)間段等,不同的時(shí)間段對應(yīng)不同的調(diào)度屬性),從而讓調(diào)度器可以更好地均衡調(diào)度所有的服務(wù);預(yù)測節(jié)點(diǎn)以及平臺在某個(gè)時(shí)間段的負(fù)載分布,并基于這些數(shù)據(jù)進(jìn)行決策,如提供服務(wù)的時(shí)分復(fù)用調(diào)度策略,從而進(jìn)一步提高云平臺的資源使用率,降低企業(yè)的IT成本。

      猜你喜歡
      容器標(biāo)簽調(diào)度
      Different Containers不同的容器
      《調(diào)度集中系統(tǒng)(CTC)/列車調(diào)度指揮系統(tǒng)(TDCS)維護(hù)手冊》正式出版
      難以置信的事情
      一種基于負(fù)載均衡的Kubernetes調(diào)度改進(jìn)算法
      虛擬機(jī)實(shí)時(shí)遷移調(diào)度算法
      無懼標(biāo)簽 Alfa Romeo Giulia 200HP
      車迷(2018年11期)2018-08-30 03:20:32
      不害怕撕掉標(biāo)簽的人,都活出了真正的漂亮
      海峽姐妹(2018年3期)2018-05-09 08:21:02
      標(biāo)簽化傷害了誰
      取米
      基于多進(jìn)制查詢樹的多標(biāo)簽識別方法
      泸西县| 贵州省| 南开区| 鄄城县| 含山县| 阿城市| 新竹市| 青州市| 皮山县| 东阿县| 普洱| 福清市| 张北县| 大渡口区| 永和县| 苍溪县| 神池县| 彭州市| 沽源县| 嵩明县| 曲阳县| 桃江县| 德钦县| 山阴县| 扎鲁特旗| 茶陵县| 丘北县| 房山区| 虎林市| 随州市| 泸州市| 唐山市| 老河口市| 贡觉县| 佛坪县| 文水县| 通化县| 依兰县| 浠水县| 长丰县| 东山县|