賀宗平， 張曉東， 劉 玉

1(南京審計(jì)大學(xué) 信息化辦公室，南京 211815)

2(南京審計(jì)大學(xué) 信息工程學(xué)院，南京 211815)

3(南京審計(jì)大學(xué) 實(shí)驗(yàn)中心，南京 211815)

1 引言

Jupyter Notebook是當(dāng)前在數(shù)據(jù)科學(xué)領(lǐng)域非常受歡迎的交互式分析軟件，支持Python、R、Julia、Scala、SQL等多種編程語言內(nèi)核，具備即時(shí)編譯、可視化和markdown語法編輯等功能[1]，為數(shù)據(jù)分析、數(shù)值計(jì)算、統(tǒng)計(jì)建模、機(jī)器學(xué)習(xí)等方面提供了便捷. 盡管基于web的設(shè)計(jì)實(shí)現(xiàn)方式有許多局限性，Jupyter Notebook在數(shù)據(jù)科學(xué)領(lǐng)域得到了極為廣泛應(yīng)用，主要原因就在于其能夠進(jìn)行交互式、可視化的數(shù)據(jù)探索性分析，從最簡(jiǎn)單的點(diǎn)線圖、地圖以及復(fù)雜的D3.js可視化等，甚至可以在某些場(chǎng)景中替代BI工具的功能，這些特點(diǎn)相對(duì)于傳統(tǒng)IDE編輯器具有顛覆性優(yōu)勢(shì). 但是Jupyter Notebook是傳統(tǒng)的單體服務(wù)架構(gòu)模式，缺少多用戶管理和訪問認(rèn)證等方面的功能，無法直接部署于計(jì)算集群上，難以充分利用和調(diào)度計(jì)算中心的計(jì)算資源.

當(dāng)今的科研學(xué)術(shù)論文向著越來越復(fù)雜的方式演變，各個(gè)研究領(lǐng)域和研究?jī)?nèi)容對(duì)程序依賴度高，需要通過編程來處理數(shù)據(jù)、繪制圖表以及統(tǒng)計(jì)分析等. 研究中的程序代碼繁瑣復(fù)雜，直接導(dǎo)致了研究結(jié)論難以被他人重復(fù)實(shí)現(xiàn)，科研的真正價(jià)值無法得到交流傳播[2].Jupyter Notebook提供了一種混合的編輯方式，將程序代碼運(yùn)行、文字圖表編輯等功能糅合在同一電子筆記中，打破了兩者之間的隔離界限，將研究中的論述表達(dá)和實(shí)驗(yàn)分析等過程有機(jī)結(jié)合起來. 對(duì)于科研結(jié)論的交流、分享和傳播的形式方法上，具有里程碑式的重要意義.

目前，國(guó)外一些大型研究機(jī)構(gòu)、實(shí)驗(yàn)室以及超算中心開始提供面向多用戶的Jupyter Notebook服務(wù)[3]，目的就是將高性能計(jì)算集群資源充分利用起來，為研究人員提供一個(gè)性能優(yōu)異、操作便捷的工具[4-6].

美國(guó)國(guó)家能源研究科學(xué)計(jì)算中心(NERSC)在其Cori超算集群上部署Jupyter，為其6000多用戶提供了更便捷化的計(jì)算資源訪問方式，NERSC在“Science Gateway”節(jié)點(diǎn)設(shè)置多用戶管理環(huán)境，當(dāng)用戶登錄后可以啟動(dòng)一個(gè)專屬的項(xiàng)目環(huán)境，并且能夠訪問計(jì)算中心其他服務(wù)、文件和作業(yè)，直接訪問大規(guī)模數(shù)據(jù)集、作業(yè)隊(duì)列系統(tǒng)，允許用戶提交作業(yè)，查詢作業(yè)批處理運(yùn)行情況. OpenMSI[7]是NERSC目前正在運(yùn)行的基于云計(jì)算平臺(tái)和Jupyter的質(zhì)譜成像項(xiàng)目，研究人員可以在web瀏覽器中對(duì)質(zhì)譜成像數(shù)據(jù)進(jìn)行分析、展示和操作.

科羅拉多大學(xué)波爾得分校(CU-Boulder)計(jì)算研究中心為研究人員提供了大規(guī)模計(jì)算資源、海量存儲(chǔ)等服務(wù)，此外還提供計(jì)算科學(xué)和數(shù)據(jù)管理方面的咨詢服務(wù). 為了更好地提供優(yōu)質(zhì)服務(wù)，CU-Boulder計(jì)算研究中心在其HPC集群上部署了支持并行計(jì)算的Jupyter環(huán)境，能夠支持ipyparallel和MPI for Python.

歐洲原子能研究機(jī)構(gòu)(CERN)開發(fā)了SWAN[8](Service for Web based ANalysis)交互式數(shù)據(jù)分析平臺(tái)，在集群中通過Docker鏡像構(gòu)建Jupyter Notebook應(yīng)用，并且支持其內(nèi)部開發(fā)的CERNBox數(shù)據(jù)云存儲(chǔ)服務(wù)，使得代碼、數(shù)據(jù)集、文檔在其組織內(nèi)部安全無縫地實(shí)現(xiàn)同步和共享，如圖1.

圖1 SWAN體系架構(gòu)示意

本文研究的重心關(guān)注Jupyter體系的架構(gòu)優(yōu)化與拓展，通過容器和微服務(wù)化改造Jupyter體系架構(gòu)，研究基于Kubernetes集群構(gòu)建面向多用戶的交互式數(shù)據(jù)分析平臺(tái).

2 Jupyter體系架構(gòu)

2.1 Jupyter Notebook架構(gòu)特點(diǎn)

Jupyter Notebook是一個(gè)典型Web架構(gòu)的應(yīng)用，客戶端部分負(fù)責(zé)筆記代碼的運(yùn)行、存儲(chǔ)和輸出等功能，并通過markdown語法進(jìn)行標(biāo)記，以JSON格式發(fā)送給服務(wù)器端存儲(chǔ)，服務(wù)器端負(fù)責(zé)存取筆記代碼、調(diào)用編譯內(nèi)核等功能.

Jupyter Notebook (如圖2)作為最基本的交互式分析程序，缺少平臺(tái)級(jí)的資源調(diào)度與管理的能力，不具備面向多用戶的服務(wù)管理功能，后臺(tái)運(yùn)行環(huán)境無法做到隔離. 這種狀況限制了Jupyter Notebook在計(jì)算集群上的部署應(yīng)用.

圖2 Jupyter Notebook架構(gòu)示意

2.2 Jupyter Hub的改進(jìn)與局限

Jupyter Hub在Jupyter Notebook基礎(chǔ)上實(shí)現(xiàn)了多用戶的管理，用于創(chuàng)建、管理、代理多個(gè)Jupyter Notebook實(shí)例. Jupyter Hub包含3個(gè)組件：多用戶的Hub管理器、可配置的http代理、多個(gè)單用戶Jupyter Notebook服務(wù)器. Jupyter Hub架構(gòu)如圖3所示.

圖3 Jupyter Hub架構(gòu)示意

Jupyter Hub的功能流程[9]包括：首先，Hub服務(wù)啟動(dòng)一個(gè)代理; 然后，代理默認(rèn)將所有訪問請(qǐng)求轉(zhuǎn)發(fā)給Hub; Hub處理用戶登錄認(rèn)證并根據(jù)需求啟動(dòng)一個(gè)單用戶的Jupyter Notebook服務(wù)器; 最后，Hub配置代理將URL前綴轉(zhuǎn)發(fā)給單用戶的Jupyter Notebook服務(wù)器.Jupyter Hub實(shí)現(xiàn)多用戶的服務(wù)管理、具備訪問認(rèn)證機(jī)制，但仍然無法實(shí)現(xiàn)集群調(diào)度、分布式計(jì)算、彈性擴(kuò)容等功能，特別是無法直接部署在大型計(jì)算集群. 對(duì)應(yīng)用系統(tǒng)進(jìn)行微服務(wù)化改造、運(yùn)用分布式架構(gòu)是解決問題的根本途徑.

2.3 Jupyter微服務(wù)化重構(gòu)

微服務(wù)將單體應(yīng)用(Monolithic)先拆分成多個(gè)單元應(yīng)用，服務(wù)間通過HTTP API或消息中間件進(jìn)行通信，再聚合組成實(shí)際應(yīng)用，這個(gè)過程顯著改善了系統(tǒng)架構(gòu)的彈性，同時(shí)通過容器技術(shù)可以降低系統(tǒng)持續(xù)集成與持續(xù)部署(CI/CD)的復(fù)雜度. 容器作為微服務(wù)的一種基礎(chǔ)運(yùn)行方式，具備成熟和強(qiáng)大的工具、平臺(tái)以及開發(fā)生態(tài)圈. Jupyter 微服務(wù)化重構(gòu)示意圖如圖4.

圖4 Jupyter微服務(wù)化重構(gòu)示意

2.3.1 微服務(wù)架構(gòu)特點(diǎn)

微服務(wù)之父Martin Fowler總結(jié)微服務(wù)具有3個(gè)典型特征[10]：微小化(small)，獨(dú)立化(independently deployable)和自動(dòng)化(automated deployment). “微小化”是“獨(dú)立化”的基礎(chǔ)，“微小化”代表微服務(wù)的設(shè)計(jì)應(yīng)當(dāng)遵循“高內(nèi)聚、低耦合”的原則，功能邊界定義清晰無重疊，“自動(dòng)化”代表系統(tǒng)組裝、部署和運(yùn)維可以通過工具實(shí)現(xiàn)高度的自動(dòng)化.

康威定律[9](Conway's Law)認(rèn)為組織結(jié)構(gòu)決定系統(tǒng)結(jié)構(gòu). 隨著組織規(guī)模的不斷擴(kuò)大，必然會(huì)演化出更多的小型組織. 從這個(gè)角度來看，傳統(tǒng)單體應(yīng)用拆分轉(zhuǎn)換為微服務(wù)的過程，是系統(tǒng)結(jié)構(gòu)適應(yīng)平臺(tái)功能擴(kuò)展的演變. 微服務(wù)降低了系統(tǒng)架構(gòu)的復(fù)雜性，通過將單體應(yīng)用分解為一組服務(wù)，在保持功能不變的條件下，強(qiáng)化了系統(tǒng)模塊化的組織水平，使得開發(fā)更易于維護(hù).

2.3.2 Jupyter的微服務(wù)拆分

單體應(yīng)用的主要架構(gòu)特征是系統(tǒng)模塊間的“緊耦合”，模塊運(yùn)行在同一進(jìn)程中. 在系統(tǒng)部分模塊更新升級(jí)、故障掉線等情況下，需要重新啟動(dòng)整個(gè)應(yīng)用進(jìn)程，導(dǎo)致系統(tǒng)可靠性和可維護(hù)性水平低下. 微服務(wù)架構(gòu)通過對(duì)單體應(yīng)用的不同功能模塊進(jìn)行拆分重構(gòu)，轉(zhuǎn)換為多個(gè)獨(dú)立的微服務(wù)，運(yùn)行為多個(gè)獨(dú)立的進(jìn)程，微服務(wù)間通過REST、RPC等遠(yuǎn)程接口通信，實(shí)現(xiàn)分布式架構(gòu)部署[11].

微服務(wù)架構(gòu)包括了無狀態(tài)化和容器化兩個(gè)前提準(zhǔn)備環(huán)節(jié)，從架構(gòu)角度來看，單體架構(gòu)對(duì)狀態(tài)信息的讀寫在本地的內(nèi)存或存儲(chǔ)中，從而導(dǎo)致難以進(jìn)行橫向擴(kuò)展.無狀態(tài)化的過程是將業(yè)務(wù)邏輯無狀態(tài)部分與數(shù)據(jù)讀寫存儲(chǔ)的有狀態(tài)部分做分離，業(yè)務(wù)邏輯經(jīng)過無狀態(tài)化處理能夠?qū)崿F(xiàn)橫向擴(kuò)展，狀態(tài)部分則通過中間件、分布式數(shù)據(jù)庫等進(jìn)行存儲(chǔ)，從而實(shí)現(xiàn)單體架構(gòu)向分布式架構(gòu)的轉(zhuǎn)化改造. Jupyter Hub的3個(gè)主要組成部分：Configurable HTTP Proxy、Hub、Notebook，3個(gè)模塊間功能界限清晰，完全可以做到微服務(wù)化拆分，符合能夠獨(dú)立運(yùn)行的標(biāo)準(zhǔn)，其中的Hub和Notebook模塊需要進(jìn)行無狀態(tài)化(stateless)處理. Configurable HTTP Proxy是可配置的訪問代理模塊，負(fù)責(zé)代理轉(zhuǎn)發(fā)用戶的訪問請(qǐng)求; Hub中主要包括了認(rèn)證功能模塊(Authenticator)和Notebook生成模塊(Spawner)，Authenticator提供web安全訪問認(rèn)證的接口，Spawner負(fù)責(zé)生成和啟動(dòng)各個(gè)隔離的Notebook容器.

3 基于Kubernetes微服務(wù)架構(gòu)設(shè)計(jì)

3.1 相關(guān)基本概念

Kubernetes(簡(jiǎn)稱K8S)作為一個(gè)分布式集群管理平臺(tái)，同時(shí)也是一個(gè)容器編排系統(tǒng)，用于在主機(jī)集群之間自動(dòng)部署、擴(kuò)展和運(yùn)行應(yīng)用程序容器，提供以容器為中心的基礎(chǔ)架構(gòu). K8S具有如服務(wù)命名與發(fā)現(xiàn)、負(fù)載均衡、運(yùn)行狀況檢查、橫向彈性伸縮和滾動(dòng)更新等功能[12]，適合在生產(chǎn)環(huán)境中部署應(yīng)用程序. 基于 Kubernetes的Jupyter 微服務(wù)架構(gòu)如圖5所示.

Pod：Pod是Kubernetes的基本單元，由一個(gè)或多個(gè)容器組成，并在同一個(gè)物理主機(jī)內(nèi)，共享相同的資源.在pod內(nèi)部署的所有容器都可以通過localhost看到其他容器. 每個(gè)Pod在集群中具有唯一的IP地址.

Service：Service是一組Pod的邏輯區(qū)分，是Pod在集群內(nèi)部被公開訪問的策略，同時(shí)允許在集群外部IP地址上訪問，主要通過ClusterIP、NodePort、Load Balancer和ExternalName等四種方式進(jìn)行地址暴露.

Replication Controller：Kubernetes的一種控制器，能夠在集群中運(yùn)行指定數(shù)目的Pod副本，實(shí)現(xiàn)Pod的數(shù)量伸縮(scale)操作.

圖5 基于Kubernetes的Jupyter微服務(wù)架構(gòu)

3.2 Jupyter微服務(wù)架構(gòu)要素

3.2.1 訪問認(rèn)證

交互式數(shù)據(jù)分析平臺(tái)通常部署在計(jì)算中心，向組織內(nèi)部提供計(jì)算服務(wù)，其訪問認(rèn)證的形式應(yīng)當(dāng)能夠與組織內(nèi)部現(xiàn)有賬戶信息做到無縫對(duì)接和集成. LDAP是輕量目錄訪問協(xié)議(Lightweight Directory Access Protocol)的縮寫，是從X.500目錄訪問協(xié)議的基礎(chǔ)上發(fā)展而來，是一種集中賬號(hào)管理架構(gòu)的實(shí)現(xiàn)協(xié)議.LDAP通常應(yīng)用于組織內(nèi)部的賬戶密碼管理[13]，構(gòu)建集中的身份驗(yàn)證系統(tǒng)，可以降低管理成本，增強(qiáng)安全性.

Jupyter Hub中訪問認(rèn)證功能可通過插件的方式配置LDAP訪問認(rèn)證功能，與組織內(nèi)部現(xiàn)有用戶訪問認(rèn)證體系完整集成. 這種方式對(duì)于大型科研機(jī)構(gòu)、高校等組織，可以顯著降低用戶管理和安全運(yùn)維成本.

3.2.2 持久化存儲(chǔ)

Kubernetes持久化存儲(chǔ)通過API資源管理，包括PersistentVolume和PersistentVolumeClaim. Kubernetes中的存儲(chǔ)組件支持NFS、EBS等多種后端存儲(chǔ)，存儲(chǔ)具有獨(dú)立于Pod的生命周期. NFS (Network File System)作為FreeBSD支持的網(wǎng)絡(luò)文件系統(tǒng)，NFS節(jié)點(diǎn)之間通過TCP/IP協(xié)議訪問，NFS的客戶端應(yīng)用可以透明地讀寫位于遠(yuǎn)端NFS服務(wù)器上的文件，跟本地文件訪問相同.

Jupyter Hub配置Kubernetes中使用NFS，文件系統(tǒng)將被掛載在Pod中. NFS允許多個(gè)Pod同時(shí)進(jìn)行寫操作，這些Pod使用相同的PersistentVolumeClaim. 通過使用NFS卷，相同的數(shù)據(jù)可以在多個(gè)Pod之間共享.

3.2.3 用戶資源分配

Jupyter Hub用戶資源分配內(nèi)容一般包括了CPU、內(nèi)存和存儲(chǔ)，對(duì)于高性能計(jì)算還需要重點(diǎn)關(guān)注GPU資源的分配. CPU、內(nèi)存和存儲(chǔ)等資源可以直接在Kubernetes中彈性配置，對(duì)于GPU資源需要通過驅(qū)動(dòng)掛載的方式，將宿主機(jī)上的GPU資源提供給容器使用. Jupyter Hub的資源定制化配置能力，關(guān)系到滿足不同用戶群體的不同層次需求，以及用戶體驗(yàn)的改進(jìn). 用戶資源分配主要有兩種方式：資源保證(resource guarantees)和資源限制(resource limits).

資源保證的方式是確保所有用戶在任何情況下至少可以使用的資源量，如果有多余的資源仍然可以在加配. 例如，如果一個(gè)用戶得到了1 GB內(nèi)存的資源保證，如果系統(tǒng)存在閑置多余的內(nèi)存資源，此用戶可以分配到高于1 GB的內(nèi)存量.

資源限制的方式設(shè)置了用戶可用資源的上限，如果一個(gè)用戶只給了1 GB內(nèi)存的資源限制，那么此用戶在任何時(shí)間、任何系統(tǒng)資源富余的情況下，都不能使用超過1 GB內(nèi)存的資源量.

3.3 集群資源調(diào)度

資源調(diào)度是Jupyter Hub充分利用計(jì)算集群資源和具備面向多用戶開放的關(guān)鍵. Kubernetes內(nèi)置了默認(rèn)的調(diào)度規(guī)則為Pod分配運(yùn)行主機(jī)，并且開放自定義編寫調(diào)度算法. 調(diào)度規(guī)則區(qū)分為預(yù)選(predicates)和優(yōu)選(priorities)兩個(gè)階段規(guī)則. 系統(tǒng)首先通過預(yù)選初步排除不符合Pod運(yùn)行要求的主機(jī)，然后再對(duì)預(yù)選后的主機(jī)進(jìn)行量化評(píng)分，分值高低代表主機(jī)狀態(tài)優(yōu)劣，最后將分值最高的主機(jī)調(diào)度為Pod的運(yùn)行主機(jī).

3.3.1 預(yù)選規(guī)則與節(jié)點(diǎn)篩選

預(yù)選規(guī)則是在集群節(jié)點(diǎn)中排除不滿足基本運(yùn)行條件主機(jī)的規(guī)則集，Kubernetes集群排除不符合預(yù)定條件的節(jié)點(diǎn). Kubernetes 默認(rèn)預(yù)選規(guī)則集見表1.

定義Kubernetes集群的工作節(jié)點(diǎn)集合為：

預(yù)選算法的規(guī)則集合為：

定義規(guī)則的運(yùn)算結(jié)果：

當(dāng)節(jié)點(diǎn)不滿足預(yù)選算法規(guī)則集合中的任一規(guī)則，則節(jié)點(diǎn)被篩選掉，最終通過預(yù)選規(guī)則過濾得到的集合為：

表1 Kubernetes默認(rèn)預(yù)選規(guī)則集

3.3.2 優(yōu)選算法與節(jié)點(diǎn)評(píng)分

在篩選出符合基本要求的候選節(jié)點(diǎn)后，通過優(yōu)選算法的節(jié)點(diǎn)評(píng)分決定Pod容器具體調(diào)度運(yùn)行的集群宿主機(jī). 優(yōu)選算法通過不同的評(píng)分函數(shù)以及其權(quán)重，得出候選節(jié)點(diǎn)的綜合分值為評(píng)分函數(shù)加權(quán)求和，最后根據(jù)得分情況，將容器運(yùn)行在最佳節(jié)點(diǎn)上.其中，s(k)為優(yōu)選算法的節(jié)點(diǎn)綜合評(píng)分; wi為權(quán)重系數(shù)，權(quán)重系數(shù)一般為均勻等比例分配，也可以由用戶根據(jù)主觀情況進(jìn)行自定義分配調(diào)整，pj(k)為評(píng)分函數(shù).

Kubernetes中默認(rèn)內(nèi)置了幾種典型評(píng)分函數(shù)：

(1) LeastRequestedPriority，當(dāng)新的Pod被調(diào)度到節(jié)點(diǎn)上，節(jié)點(diǎn)的優(yōu)先級(jí)取決于節(jié)點(diǎn)空閑資源與節(jié)點(diǎn)總?cè)萘康谋戎担戎翟礁叩墓?jié)點(diǎn)得分越高，CPU和內(nèi)存的權(quán)重相同，具有參照資源消耗跨節(jié)點(diǎn)調(diào)度Pod的作用.

(2) BalancedResourceAllocation，嘗試分析部署Pod后集群節(jié)點(diǎn)的CPU和內(nèi)存利用率，以達(dá)到集群均衡狀態(tài)為目標(biāo)，可以避免出現(xiàn)CPU、內(nèi)存負(fù)載不均衡的情況.

(3) SelectorSpreadPriority，主要針對(duì)多實(shí)例的場(chǎng)景下使用，將優(yōu)先級(jí)交給運(yùn)行Pod實(shí)例數(shù)量少的節(jié)點(diǎn).

4 性能測(cè)試

為了對(duì)比Jupyter“微服務(wù)化”分布式架構(gòu)改進(jìn)性能，將Jupyter單體服務(wù)架構(gòu)應(yīng)用與基于Kubernetes集群架構(gòu)的兩種不同部署方式進(jìn)行測(cè)試，測(cè)試內(nèi)容包括了兩個(gè)部分：并發(fā)訪問負(fù)載測(cè)試、Pod運(yùn)行數(shù)量負(fù)載均衡測(cè)試. 其中，訪問負(fù)載測(cè)試的是為了對(duì)比兩種架構(gòu)方式下后臺(tái)服務(wù)的響應(yīng)能力; Pod運(yùn)行數(shù)量負(fù)載均衡測(cè)試是通過觀察集群中Pod運(yùn)行數(shù)量變化與節(jié)點(diǎn)計(jì)算資源使用率間的變化關(guān)系，分析驗(yàn)證集群計(jì)算資源調(diào)度分配的有效性.

4.1 測(cè)試條件

本文研究重點(diǎn)關(guān)注資源調(diào)度和橫向擴(kuò)容測(cè)試，為了方便實(shí)驗(yàn)，可以控制測(cè)試節(jié)點(diǎn)規(guī)模，本實(shí)驗(yàn)中搭建了3個(gè)節(jié)點(diǎn)(節(jié)點(diǎn)配置如表2所示)的Kubernetes集群，其中1個(gè)master集群控制節(jié)點(diǎn)、2個(gè)Node工作節(jié)點(diǎn).

表2 節(jié)點(diǎn)配置

4.2 訪問負(fù)載測(cè)試

Apache Bench (AB)是一種簡(jiǎn)單有效的壓力負(fù)載測(cè)試工具包，通常用于對(duì)服務(wù)器的HTTP請(qǐng)求性能測(cè)試. 本研究通過AB工具分別對(duì)基于Kubernetes微服務(wù)架構(gòu)和單體架構(gòu)的Jupyter負(fù)載能力進(jìn)行測(cè)試，測(cè)試模擬100個(gè)用戶共20 000次服務(wù)請(qǐng)求的響應(yīng)情況，測(cè)試結(jié)果主要關(guān)注“平均響應(yīng)時(shí)間(time per request)”[13，14]指標(biāo)，其計(jì)算公式如下：

其中，T代表請(qǐng)求測(cè)試花費(fèi)的總時(shí)間，N代表總請(qǐng)求數(shù)量，C代表并發(fā)用戶數(shù).

如圖6測(cè)試結(jié)果數(shù)據(jù)統(tǒng)計(jì)分析表明，在相同的訪問量和用戶數(shù)條件下，在訪問請(qǐng)求總數(shù)的各個(gè)百分比分位點(diǎn)上，基于微服務(wù)架構(gòu)的Jupyter在“平均響應(yīng)時(shí)間”指標(biāo)上優(yōu)于單體架構(gòu).

圖6 訪問負(fù)載測(cè)試結(jié)果數(shù)據(jù)統(tǒng)計(jì)分析

4.3 Pod運(yùn)行數(shù)量負(fù)載均衡測(cè)試

基于Kubernetes分布式微服務(wù)架構(gòu)的Jupyter，通過為不同的用戶啟動(dòng)獨(dú)立的Pod提供Notebook服務(wù)，其Pod運(yùn)行數(shù)量即代表用戶運(yùn)行數(shù)量. Pod運(yùn)行數(shù)量負(fù)載均衡測(cè)試模擬隨著用戶運(yùn)行數(shù)量增加，集群節(jié)點(diǎn)的資源使用率變化情況，主要關(guān)注“內(nèi)存使用率(Memory Usage)”和“CPU使用率(CPU Usage)”兩個(gè)指標(biāo)，計(jì)算公式見式(8)和式(9)：

其中，假設(shè)集群節(jié)點(diǎn)node(j)共計(jì)運(yùn)行m 個(gè)容器實(shí)例，代表節(jié)點(diǎn)node(j)序號(hào)為i的容器實(shí)例，memory_container_usage[15]為節(jié)點(diǎn)某個(gè)容器內(nèi)存使用率，cpu_container_usage[15]為節(jié)點(diǎn)某個(gè)容器在Δt時(shí)間間隔內(nèi)的CPU使用率，node_memory為某節(jié)點(diǎn)總計(jì)內(nèi)存資源量，node_cores為某節(jié)點(diǎn)CPU計(jì)算資源總量.

如圖7所示測(cè)試結(jié)果數(shù)據(jù)分析表明，隨著用戶數(shù)量的增加，集群不同節(jié)點(diǎn)的資源使用率呈現(xiàn)總體同步提高的變化趨勢(shì)，證明了計(jì)算資源的負(fù)載被均衡分配到集群各個(gè)宿主節(jié)點(diǎn)上. 通過資源分配算法，Kubernetes在集群上啟動(dòng)Pod單元時(shí)，優(yōu)先考慮宿主機(jī)的剩余計(jì)算資源，將負(fù)載優(yōu)先分配到計(jì)算資源、環(huán)境條件相對(duì)優(yōu)越的節(jié)點(diǎn)上，從而實(shí)現(xiàn)了在整個(gè)集群上的負(fù)載均衡.

圖7 Pod運(yùn)行負(fù)載測(cè)試結(jié)果數(shù)據(jù)分析，node1、node2為測(cè)試集群中的兩個(gè)計(jì)算節(jié)點(diǎn)，為Pod的運(yùn)行宿主機(jī).

5 結(jié)語

Jupyter作為集合了代碼運(yùn)行、數(shù)據(jù)分析、論文編寫等功能為一體的優(yōu)秀平臺(tái)工具，逐漸走向大型計(jì)算中心的后端，向著基于容器技術(shù)的分布式微服務(wù)架構(gòu)方向演進(jìn). 本文研究通過對(duì)Jupyter的微服務(wù)化重構(gòu)，并結(jié)合Kubernetes資源調(diào)度分配算法，實(shí)現(xiàn)了在計(jì)算集群上多用戶資源需求的負(fù)載均衡，能夠充分優(yōu)化利用計(jì)算中心的集群資源[16]，具備了橫向動(dòng)態(tài)擴(kuò)容的能力，為用戶提供更為便捷、高效的計(jì)算資源訪問方式.在下一步的研究中，將重點(diǎn)關(guān)注面向HPC高性能計(jì)算的Jupyter分布式并行架構(gòu)，以優(yōu)化計(jì)算資源利用率為主要目標(biāo)[17]，并融合主流大數(shù)據(jù)存儲(chǔ)計(jì)算框架，為計(jì)算中心和用戶構(gòu)建易于管理操作的交互式分析計(jì)算平臺(tái).