吳 璨 王小寧 肖海力 和 榮 趙一寧 遲學(xué)斌

(*中國科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心 北京 100190) (**中國科學(xué)院大學(xué) 北京 100049)

0 引 言

國家高性能計(jì)算基礎(chǔ)設(shè)施建設(shè)自1998年以來，先后得到“863計(jì)劃”、“國家重點(diǎn)研發(fā)計(jì)劃”的持續(xù)支持[1]。歷經(jīng)20多年的發(fā)展，我國在高性能計(jì)算機(jī)領(lǐng)域已走在世界前列。由我國自主研發(fā)制造的高性能計(jì)算機(jī)“天河二號(hào)”[2]、“神威·太湖之光”[3]連續(xù)5年10屆(2013年-2017年)位居全球超級(jí)計(jì)算機(jī)TOP500[4]排行榜榜首；由中國科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心牽頭建設(shè)的國家高性能計(jì)算環(huán)境(原名中國國家網(wǎng)格)[5]整體技術(shù)水平處于世界領(lǐng)先行列。截至目前，根據(jù)國家高性能計(jì)算環(huán)境運(yùn)行管理中心的統(tǒng)計(jì)數(shù)據(jù)[6]，國家高性能計(jì)算環(huán)境已接入來自國家超級(jí)計(jì)算中心、科研機(jī)構(gòu)和重點(diǎn)高校的19家中國國家網(wǎng)格結(jié)點(diǎn)單位，聚合了“神威·太湖之光”、“神威·藍(lán)光”、“天河二號(hào)”、“天河一號(hào)”等國際頂級(jí)高性能計(jì)算資源，聚合計(jì)算資源超過200PFLOPS，總存儲(chǔ)資源超過167 PB，總內(nèi)存資源超過104 TB。

國家高性能計(jì)算環(huán)境的核心軟件是由中國科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心自主研發(fā)的超級(jí)計(jì)算環(huán)境中間件(super computing environment，SCE)[7,8]。SCE屏蔽了作業(yè)管理系統(tǒng)、接入方式、管理制度等的異構(gòu)性，面向用戶提供具有統(tǒng)一訪問入口、使用方法和用戶技術(shù)支持的高性能計(jì)算服務(wù)[9]。目前所使用的SCE是1.0版本，SCE1.0使用單個(gè)數(shù)據(jù)中心集中處理資源信息，來自全國各地的高性能計(jì)算機(jī)的資源信息匯報(bào)至位于北京的數(shù)據(jù)中心進(jìn)行統(tǒng)一管理。雖然SCE1.0已穩(wěn)定運(yùn)行多年，為用戶提供持續(xù)的、便捷的高性能計(jì)算服務(wù)，但是步入大數(shù)據(jù)時(shí)代之后，單個(gè)數(shù)據(jù)中心的系統(tǒng)軟件結(jié)構(gòu)遇到了性能瓶頸。SCE1.0在處理大量資源信息時(shí)，時(shí)間開銷較大、系統(tǒng)負(fù)載較高。

隨著更多高性能計(jì)算資源的接入，高性能計(jì)算環(huán)境中的用戶量不斷增加、作業(yè)量不斷增大，資源信息也越來越多。據(jù)國家各超級(jí)計(jì)算中心統(tǒng)計(jì)數(shù)據(jù)顯示，廣州超級(jí)計(jì)算中心“天河二號(hào)”的累計(jì)用戶數(shù)已經(jīng)達(dá)到2 700家，天津超級(jí)計(jì)算中心的用戶數(shù)已超過1 600家，無錫超級(jí)計(jì)算中心的“神威·太湖之光”年有效工作機(jī)時(shí)達(dá)到8 760 h，與日俱增的用戶信息、作業(yè)信息等大量資源信息傳輸對(duì)高性能計(jì)算環(huán)境的系統(tǒng)軟件提出以下挑戰(zhàn)：

(1)高性能計(jì)算環(huán)境系統(tǒng)軟件應(yīng)具備更好的性能、更高的吞吐量，具有E級(jí)(百億億次級(jí))承載能力；

(2)高性能計(jì)算環(huán)境系統(tǒng)軟件在處理分布式環(huán)境下的大量資源信息傳輸時(shí)，應(yīng)具有更小的時(shí)間開銷、更低的系統(tǒng)負(fù)載；

(3)在單個(gè)數(shù)據(jù)中心出現(xiàn)服務(wù)器故障、停電、機(jī)房搬遷等情況時(shí)，高性能計(jì)算環(huán)境系統(tǒng)軟件應(yīng)該可以正常提供服務(wù)。

為了迎接新形勢(shì)下的更多挑戰(zhàn)，滿足大數(shù)據(jù)環(huán)境下的更多需求，本文提出基于消息總線的、支持多數(shù)據(jù)中心的國家高性能計(jì)算環(huán)境系統(tǒng)軟件的優(yōu)化設(shè)計(jì)。本文首先介紹了高性能計(jì)算環(huán)境系統(tǒng)軟件優(yōu)化設(shè)計(jì)的總體結(jié)構(gòu)；然后對(duì)消息總線及基于消息總線開發(fā)的資源信息服務(wù)的詳細(xì)設(shè)計(jì)和具體實(shí)現(xiàn)進(jìn)行介紹；并且從多維度對(duì)資源信息服務(wù)進(jìn)行性能評(píng)估；最后總結(jié)了本文工作，并提出下一步工作的研究方向。

1 總體結(jié)構(gòu)設(shè)計(jì)

本文提出基于消息總線的、支持多中心的高性能計(jì)算環(huán)境系統(tǒng)軟件優(yōu)化設(shè)計(jì)(SCE2.0)。SCE2.0的層次架構(gòu)如圖1所示，是由應(yīng)用層、服務(wù)層、消息總線和資源層組成的4層架構(gòu)。

圖1 SCE2.0層次架構(gòu)

客戶端(User-Client和Admin-Client)、應(yīng)用編程接口(application programming interface，API)和數(shù)據(jù)中心位于應(yīng)用層?？蛻舳嗣嫦蛴脩籼峁┙y(tǒng)一的訪問入口，用戶可以通過命令行或Web Portal使用高性能計(jì)算服務(wù)。API面向開發(fā)人員提供了訪問高性能計(jì)算環(huán)境的統(tǒng)一訪問接口，降低了開發(fā)復(fù)雜性，縮短了系統(tǒng)開發(fā)周期。數(shù)據(jù)中心存儲(chǔ)環(huán)境資源信息，為整體環(huán)境提供全局的作業(yè)視圖、信息服務(wù)和元調(diào)度等。

服務(wù)層使用從消息總線獲取的資源信息，為應(yīng)用層提供個(gè)性化服務(wù)，例如管理資源信息、處理服務(wù)請(qǐng)求、作業(yè)調(diào)度、管理總線等。

消息總線用于分布式環(huán)境下的資源信息傳輸與管理，是支持多個(gè)數(shù)據(jù)中心同時(shí)提供服務(wù)的核心模塊。消息總線將消息中間件Kafka[10-12]作為消息傳輸工具，使用ZooKeeper[13-15]管理消息主題(topic)和分布式集群。消息總線使用負(fù)載均衡器分配服務(wù)請(qǐng)求至不同的數(shù)據(jù)中心，提高系統(tǒng)的可擴(kuò)展性；提供異步編程接口，提高信息服務(wù)的效率；使用可靠傳輸機(jī)制，對(duì)客戶端進(jìn)行權(quán)限管理和身份驗(yàn)證，將數(shù)據(jù)進(jìn)行異地備份，提高系統(tǒng)的可靠性。

資源層位于最底層，由分布在全國各地的、異構(gòu)的高性能計(jì)算機(jī)組成。高性能計(jì)算機(jī)(high performance computer，HPC)上部署了編譯、調(diào)試工具及各領(lǐng)域應(yīng)用軟件，所有作業(yè)均提交到高性能計(jì)算機(jī)上執(zhí)行。

SCE2.0的資源層和應(yīng)用層與SCE1.0結(jié)構(gòu)相同，本文的工作重點(diǎn)是消息總線和服務(wù)層的設(shè)計(jì)與實(shí)現(xiàn)。服務(wù)層的各服務(wù)設(shè)計(jì)和實(shí)現(xiàn)流程具有相似性，本文僅詳細(xì)介紹資源信息服務(wù)的設(shè)計(jì)和具體實(shí)現(xiàn)。

2 消息總線的設(shè)計(jì)與實(shí)現(xiàn)

2.1 消息主題管理

消息總線以消息主題作為信息處理單元，本文采用樹形結(jié)構(gòu)規(guī)范消息主題名稱。消息主題名稱使用Zookeeper管理，保證消息主題名稱不重復(fù)。

環(huán)境中的信息按照類別進(jìn)行區(qū)分，每一個(gè)類別通過一個(gè)消息主題傳輸數(shù)據(jù)，消息主題名稱存儲(chǔ)結(jié)構(gòu)如圖2所示。環(huán)境中的信息可以分為資源信息(resource)、監(jiān)控信息(monitor)、日志信息(log)和請(qǐng)求信息(request)。每一類信息又可細(xì)分為若干小類。在與消息總線通信時(shí)，可以指明具體的消息主題，如“SCE_resource_site1_hpc1_queue”，即收發(fā)site1的hpc1的queue消息；也可以僅指明父消息主題，如“SCE_resource_site1_hpc1”，即收發(fā)site1的hpc1的所有資源信息，包括queue、job、usermap、app、node、account和disk。消息主題有分區(qū)數(shù)和副本數(shù)2個(gè)屬性，分區(qū)數(shù)表示消息被分為幾部分處理；副本數(shù)表示消息被復(fù)制幾份。分區(qū)數(shù)越多，消息處理效率越高，副本數(shù)越多，消息安全系數(shù)越高，分區(qū)數(shù)和副本數(shù)受集群中服務(wù)器個(gè)數(shù)限制。

圖2 消息主題名稱存儲(chǔ)結(jié)構(gòu)

2.2 消息總線接口設(shè)計(jì)

消息總線提供統(tǒng)一的、簡單的異步編程接口，有效地提高了信息服務(wù)效率。異步編程接口實(shí)現(xiàn)了事件驅(qū)動(dòng)架構(gòu)(event-driven architecture，EDA)[16]，采用“發(fā)布-訂閱”模式[17]解除服務(wù)邏輯與消息內(nèi)容的緊耦合關(guān)系，使各服務(wù)可以異步處理消息。接口設(shè)計(jì)如表1所示。

表1 異步編程接口

表1續(xù)

由于接口隱藏了訪問的復(fù)雜性，因此開發(fā)新的服務(wù)和應(yīng)用程序更加方便；由于事件屏蔽了消息的細(xì)節(jié)，開發(fā)服務(wù)只需針對(duì)事件編程，因此開發(fā)過程更加快捷。異步編程接口的使用，使新結(jié)點(diǎn)、新服務(wù)接入國家高性能計(jì)算環(huán)境時(shí)，不需要修改任何程序代碼或停止現(xiàn)有的服務(wù)，使系統(tǒng)更加高效可用。

2.3 消息總線部署結(jié)構(gòu)

消息總線采用集群部署方式，其部署結(jié)構(gòu)如圖3所示。部署的ZooKeeper數(shù)量、Kafka數(shù)量由集群規(guī)模決定，一般情況下，ZooKeeper數(shù)量為奇數(shù)。本文共部署了3個(gè)ZooKeeper和3個(gè)Kafka，構(gòu)成消息總線集群。ZooKeeper內(nèi)部通信使用2888端口和3888端口，對(duì)外通信使用2181端口。Kafka對(duì)外通信使用9092端口。客戶端通過訪問2181端口和9092端口與消息總線進(jìn)行信息傳輸。

圖3 消息總線部署結(jié)構(gòu)

2.4 可擴(kuò)展性設(shè)計(jì)

消息總線的可擴(kuò)展性包括數(shù)據(jù)中心可擴(kuò)展、結(jié)點(diǎn)可擴(kuò)展和服務(wù)可擴(kuò)展。在增加數(shù)據(jù)中心、接入新結(jié)點(diǎn)、開發(fā)新服務(wù)時(shí)，無需修改已有代碼或終止當(dāng)前服務(wù)，使用消息總線提供的編程接口和已定義的編程框架即可快速實(shí)現(xiàn)。

增加數(shù)據(jù)中心時(shí)，新的數(shù)據(jù)中心從現(xiàn)有的數(shù)據(jù)中心獲取基礎(chǔ)資源信息。新的數(shù)據(jù)中心隨即訂閱現(xiàn)有數(shù)據(jù)中心所訂閱的消息主題，以獲得相同的消息，保持各數(shù)據(jù)中心信息一致。

接入新結(jié)點(diǎn)時(shí)，只需按照結(jié)點(diǎn)配置模板設(shè)置結(jié)點(diǎn)的配置信息。資源信息服務(wù)即可自動(dòng)檢測新結(jié)點(diǎn)的配置信息，將其增添至資源信息數(shù)據(jù)庫。

開發(fā)新服務(wù)時(shí)，使用消息總線提供的異步編程接口，根據(jù)需求從消息總線中獲取所需信息。將新服務(wù)接入消息總線時(shí)，在消息總線中創(chuàng)建新的消息主題即可。由于消息總線異步處理消息，不會(huì)影響當(dāng)前服務(wù)。

消息總線的負(fù)載均衡策略如圖4所示。本文在消息總線中構(gòu)建了負(fù)載均衡器來均衡用戶請(qǐng)求。用戶將作業(yè)請(qǐng)求提交到消息總線，并創(chuàng)建一個(gè)名為作業(yè)ID的消息主題，以接收來自數(shù)據(jù)中心的響應(yīng)。根據(jù)負(fù)載均衡算法，所有用戶請(qǐng)求都通過負(fù)載均衡器分配給不同的數(shù)據(jù)中心。數(shù)據(jù)中心接收請(qǐng)求并通過名為作業(yè)ID的消息主題直接響應(yīng)用戶。用于傳輸作業(yè)請(qǐng)求的消息主題是臨時(shí)主題。收到響應(yīng)后，用戶客戶端將刪除消息主題。每個(gè)數(shù)據(jù)中心都可以處理用戶請(qǐng)求，因此響應(yīng)時(shí)間將隨著數(shù)據(jù)中心的增加而減少。

消息總線中的負(fù)載均衡器是集成不同負(fù)載均衡算法的框架，其定義了負(fù)載均衡算法接入的輸入/輸出標(biāo)準(zhǔn)，并提供了接入接口。本項(xiàng)目中的另一個(gè)團(tuán)隊(duì)正致力于研究負(fù)載均衡算法，旨在未來的工作中集成更多高效的負(fù)載均衡算法。

圖4 消息總線的負(fù)載均衡策略

2.5 可靠性設(shè)計(jì)

消息總線從2個(gè)方面考慮系統(tǒng)的可靠性：系統(tǒng)應(yīng)足夠安全，不允許沒有注冊(cè)的用戶非法訪問；當(dāng)服務(wù)器發(fā)生故障時(shí)，數(shù)據(jù)不會(huì)丟失。針對(duì)上述2種情況，本文提出了可靠傳輸機(jī)制，即身份認(rèn)證、權(quán)限控制和雙層異地?cái)?shù)據(jù)備份，其結(jié)構(gòu)設(shè)計(jì)如圖5所示。

圖5 消息總線的可靠性設(shè)計(jì)

2.5.1 身份認(rèn)證

消息總線為每個(gè)客戶端設(shè)置一組用戶名和密碼，密碼由12位數(shù)字和字母組合構(gòu)成，存儲(chǔ)在客戶端的配置文件中。當(dāng)客戶端訪問消息總線時(shí)，消息總線先驗(yàn)證客戶端的身份。如果客戶端提供的用戶和密碼正確，則驗(yàn)證通過；否則，消息總線將拒絕該訪問請(qǐng)求。若一個(gè)客戶端連續(xù)提供了5次錯(cuò)誤的用戶名或密碼，系統(tǒng)將凍結(jié)該賬戶并向系統(tǒng)管理員發(fā)出報(bào)警。

身份驗(yàn)證有效地阻止了非法客戶端的惡意連接，從而提高了系統(tǒng)的可靠性。

2.5.2 權(quán)限管理

消息總線可以為不同的客戶端分配不同的消息主題的權(quán)限。消息主題的權(quán)限包括READ、WRITE、DELETE、CREATE、ALTER、DESCRIBE和Cluster Action[18]。不同的客戶端功能不同，因此為其分配不同的權(quán)限，以防止普通客戶端更改系統(tǒng)重要信息。消息總線為數(shù)據(jù)中心分配READ、WRITE、DELETE、CREATE和ALTER權(quán)限，為普通客戶端僅分配READ和WRITE權(quán)限。

本文在國家高性能計(jì)算環(huán)境中定義了一個(gè)新角色，稱為消息總線管理員。消息總線管理員可以添加、刪除消息主題，修改消息主題的分區(qū)數(shù)、副本數(shù)，為客戶端分配消息主題的權(quán)限等。

消息總線的權(quán)限控制限制了普通客戶端的權(quán)限，減少了普通客戶端的誤操作對(duì)系統(tǒng)產(chǎn)生的影響。

2.5.3 雙層異地?cái)?shù)據(jù)備份

在分布式環(huán)境中，有時(shí)網(wǎng)絡(luò)會(huì)發(fā)生中斷或變得不穩(wěn)定，從而導(dǎo)致高性能計(jì)算機(jī)、消息總線和數(shù)據(jù)中心之間的信息傳輸中斷。本文提出了雙層異地?cái)?shù)據(jù)備份機(jī)制以應(yīng)對(duì)此類情況，提高系統(tǒng)數(shù)據(jù)可靠性。

在資源層，使用名為msg-file的備份文件來記錄需要傳輸至消息總線的信息。如圖5所示，從HPC提取的資源信息被寫入msg-file文件中。每個(gè)msg-file文件有一個(gè)pub-point屬性，用于記錄msg-file文件中已經(jīng)發(fā)布的最后一條信息的位置。正常情況下，pub-point會(huì)在信息發(fā)布完成后更新到msg-file文件的最后一行。但是當(dāng)網(wǎng)絡(luò)中斷或不穩(wěn)定而導(dǎo)致信息無法成功發(fā)布時(shí)，pub-point不更新，新提取的消息寫在pub-point之后的位置。當(dāng)網(wǎng)絡(luò)連接恢復(fù)穩(wěn)定后，pub-point后面的信息將繼續(xù)被發(fā)送至消息總線。

在消息總線層，使用消息總線的日志(log)來備份數(shù)據(jù)。設(shè)置消息總線的配置，使數(shù)據(jù)在日志中保存若干天。在此期間，可以根據(jù)時(shí)間從日志中恢復(fù)數(shù)據(jù)。若出現(xiàn)系統(tǒng)異常，也可以在日志中追溯消息軌跡。消息總線管理員可以通過設(shè)置消息主題的副本數(shù)來控制數(shù)據(jù)的異地備份數(shù)；可以修改消息總線的配置，設(shè)置日志保存的天數(shù)。

消息總線的雙層異地?cái)?shù)據(jù)備份機(jī)制極大地提高了消息總線的容錯(cuò)能力，當(dāng)發(fā)生網(wǎng)絡(luò)中斷時(shí)，數(shù)據(jù)可在網(wǎng)絡(luò)連接恢復(fù)后自動(dòng)傳輸；當(dāng)數(shù)據(jù)由于某些客觀因素丟失時(shí)，可以從集群中的其他數(shù)據(jù)中心的備份數(shù)據(jù)中恢復(fù)數(shù)據(jù)。

3 資源信息服務(wù)的設(shè)計(jì)與實(shí)現(xiàn)

本文對(duì)基于消息總線開發(fā)的資源信息服務(wù)的設(shè)計(jì)與實(shí)現(xiàn)進(jìn)行詳細(xì)介紹。多個(gè)數(shù)據(jù)中心的資源信息服務(wù)由聚合信息模塊和同步信息模塊2部分構(gòu)成。所有數(shù)據(jù)中心通過聚合信息模塊獲取從HPC提取的資源信息；當(dāng)一個(gè)數(shù)據(jù)中心的資源信息發(fā)生變化時(shí)，通過同步信息模塊同步到其他數(shù)據(jù)中心。

資源信息服務(wù)的信息傳輸結(jié)構(gòu)如圖6所示，由聚合信息模塊和同步信息模塊組成。聚合信息模塊和同步信息模塊分別有自己的消息主題“request_informationservice_gathered”和“request_informationservice_synched”，用于傳輸不同模塊的信息。

圖6 資源信息傳輸結(jié)構(gòu)圖

3.1 聚合資源信息

各數(shù)據(jù)中心通過聚合信息模塊從資源層的高性能計(jì)算機(jī)上收集資源信息，包括作業(yè)信息、隊(duì)列信息、用戶信息和應(yīng)用信息。聚合信息模塊信息傳輸過程如圖6中“聚合信息”所示。所有數(shù)據(jù)中心同時(shí)獲取消息總線中消息主題名為“request_informationservice_gathered”的信息，因此所有數(shù)據(jù)中心獲得的信息是相同的。由于傳輸時(shí)間開銷的差異，資源信息到達(dá)各數(shù)據(jù)中心的時(shí)間不完全相同，但是，經(jīng)過一段時(shí)間后，各數(shù)據(jù)中心的數(shù)據(jù)終會(huì)保持一致。

聚合信息模塊定期從高性能計(jì)算機(jī)上提取資源信息。由于高性能計(jì)算環(huán)境中的資源信息量復(fù)雜且龐大，所以從高性能計(jì)算機(jī)中提取的信息含有大量的冗余信息。為了降低信息傳輸?shù)臅r(shí)間開銷，減少不必要的網(wǎng)絡(luò)資源浪費(fèi)，本文定義了各類資源信息的標(biāo)準(zhǔn)格式。聚合信息模塊在傳輸信息之前，將資源信息轉(zhuǎn)換為簡單的、標(biāo)準(zhǔn)的信息格式。各類資源信息的標(biāo)準(zhǔn)格式如表2所示。

表2 資源信息標(biāo)準(zhǔn)化格式

此外，高性能計(jì)算機(jī)上部署的作業(yè)管理系統(tǒng)各異，不同的作業(yè)管理系統(tǒng)中的作業(yè)狀態(tài)標(biāo)識(shí)符不同。為了將作業(yè)狀態(tài)統(tǒng)一，本文定義了6個(gè)作業(yè)狀態(tài)標(biāo)識(shí)符：PEND、RUN、DONE、EXIT、ERROR和HOLD，將LSF[19]、PBS[20]和SLURM[21]作業(yè)管理系統(tǒng)中的作業(yè)狀態(tài)標(biāo)準(zhǔn)化。不同作業(yè)管理系統(tǒng)中的作業(yè)狀態(tài)與定義的標(biāo)識(shí)符的對(duì)應(yīng)關(guān)系如表3所示。

聚合信息模塊從高性能計(jì)算機(jī)上提取資源信息后，與緩存中的歷史信息對(duì)比，將發(fā)生變化的資源信息發(fā)送至消息總線中名為“request_informationservice_gathered”的消息主題中。所有數(shù)據(jù)中心從消息總線中獲取資源信息，并存儲(chǔ)至本地?cái)?shù)據(jù)庫或文件。聚合信息模塊可以確保所有數(shù)據(jù)中心以高效率、低系統(tǒng)負(fù)載獲得相同的資源信息。

表3 作業(yè)狀態(tài)標(biāo)識(shí)符

3.2 同步資源信息

同步信息模塊用于將一個(gè)數(shù)據(jù)中心更改后的信息同步到其他數(shù)據(jù)中心。同步信息模塊傳輸過程如圖6中“同步信息”所示。當(dāng)任務(wù)請(qǐng)求提交到某一個(gè)數(shù)據(jù)中心時(shí)，此數(shù)據(jù)中心的資源信息將發(fā)生變化，變化的信息應(yīng)該及時(shí)同步至其他數(shù)據(jù)中心。同步信息模塊提取發(fā)生變化的資源信息，并將其發(fā)送至消息總線中名為“request_informationservice_synched”的消息主題中。其他數(shù)據(jù)中心從該消息主題中獲取信息，并更新本地?cái)?shù)據(jù)庫或文件。資源信息的標(biāo)準(zhǔn)格式與聚合信息模塊中的格式相同。

每個(gè)數(shù)據(jù)中心維護(hù)一個(gè)“data-point”，用于記錄已經(jīng)獲得的消息的位置。如果某個(gè)數(shù)據(jù)中心與消息總線在一段時(shí)間內(nèi)斷開連接，“data-point”將不會(huì)更改。網(wǎng)絡(luò)服務(wù)恢復(fù)正常后，數(shù)據(jù)中心可以根據(jù)“data-point”繼續(xù)從消息總線上獲取數(shù)據(jù)。雖然數(shù)據(jù)一致在時(shí)間上有所差異，但是所有數(shù)據(jù)中心最終會(huì)具有相同的資源信息。

3.3 并行傳輸信息

為了提高消息的發(fā)送、接收效率，本文提出并行傳輸消息的設(shè)計(jì)方案。信息服務(wù)根據(jù)實(shí)時(shí)系統(tǒng)狀態(tài)，計(jì)算可并發(fā)的線程數(shù)目，并行地處理消息。計(jì)算并行發(fā)送消息和并行接收消息的并發(fā)線程數(shù)目的方法是不同的，本文對(duì)此兩種情況分別進(jìn)行考慮。

發(fā)送消息時(shí)，并發(fā)線程的數(shù)目可以根據(jù)系統(tǒng)狀態(tài)計(jì)算。計(jì)算機(jī)存儲(chǔ)設(shè)備的輸入/輸出性能是衡量系統(tǒng)狀態(tài)的考慮因素之一；線程的數(shù)目不應(yīng)超過系統(tǒng)核數(shù)。同時(shí)，時(shí)間開銷與數(shù)據(jù)量也和系統(tǒng)負(fù)載相關(guān)，所以數(shù)據(jù)量和系統(tǒng)負(fù)載也是考慮因素。由此，本文根據(jù)計(jì)算機(jī)存儲(chǔ)設(shè)備的輸入/輸出性能、系統(tǒng)負(fù)載、數(shù)據(jù)量和系統(tǒng)核數(shù)，提出了一個(gè)自動(dòng)計(jì)算并發(fā)線程數(shù)目的公式，公式如下：

其中，x為并發(fā)線程數(shù)目；I是計(jì)算機(jī)存儲(chǔ)設(shè)備的輸入/輸出性能，可以用Linux命令“iostat-x”獲取，其本質(zhì)是輸入/輸出操作的時(shí)間占比，取值范圍在0%和100%之間；S是1 min內(nèi)的系統(tǒng)平均負(fù)載，可以用Linux命令“uptime”獲取，單個(gè)CPU的取值范圍在0到1之間；W為工作負(fù)載，即消息的大小，以兆字節(jié)(MB)為單位；C是系統(tǒng)核數(shù)，可以用Linux命令“iostat”獲??；α是調(diào)節(jié)因子，默認(rèn)值為0.0001。

以40核的服務(wù)器為例，當(dāng)工作負(fù)載為1 000 MB時(shí)，系統(tǒng)1 min內(nèi)的平均負(fù)載為0.1，計(jì)算機(jī)存儲(chǔ)設(shè)備的輸入/輸出操作的時(shí)間占比為10%。所以C是40，S是0.1，I是0.1，W是1000。α取默認(rèn)值0.0001。用上述公式計(jì)算，結(jié)果為36。因此，系統(tǒng)自動(dòng)創(chuàng)建36個(gè)線程發(fā)送信息。

接收消息時(shí)，并發(fā)線程數(shù)目與消息主題的分區(qū)數(shù)有關(guān)。并發(fā)線程數(shù)目不應(yīng)超過消息主題的分區(qū)數(shù)，當(dāng)并發(fā)線程數(shù)目與消息主題的分區(qū)數(shù)相等時(shí)，信息傳輸效率最高。

4 實(shí)驗(yàn)結(jié)果與分析

4.1 實(shí)驗(yàn)數(shù)據(jù)與實(shí)驗(yàn)環(huán)境

本文實(shí)驗(yàn)中所使用的數(shù)據(jù)包括真實(shí)數(shù)據(jù)和測試數(shù)據(jù)。

真實(shí)數(shù)據(jù)是從國家高性能計(jì)算環(huán)境工作負(fù)載庫(Chinese Supercomputer Workloads Archive，CSWA)[22]下載的環(huán)境結(jié)點(diǎn)的公開真實(shí)工作負(fù)載。包括4家單位的工作負(fù)載：中國科學(xué)技術(shù)大學(xué)超級(jí)計(jì)算中心(USTC)的曙光TC4600百萬億次超級(jí)計(jì)算系統(tǒng)的工作負(fù)載；上海超級(jí)計(jì)算中心(SSC)的曙光5000A系統(tǒng)的工作負(fù)載；國家超級(jí)計(jì)算無錫中心(WXSC)的高性能計(jì)算機(jī)“神威·太湖之光”的工作負(fù)載；上海交通大學(xué)高性能計(jì)算中心(SJTU)的高性能計(jì)算機(jī)“π”的工作負(fù)載。各工作負(fù)載的詳細(xì)信息如表4所示。

表4 CSWA工作負(fù)載詳細(xì)信息

因?yàn)镃SWA中目前只公開了4家單位的真實(shí)工作負(fù)載，數(shù)據(jù)規(guī)模不夠大。所以本文在實(shí)驗(yàn)過程中，根據(jù)真實(shí)數(shù)據(jù)的格式，模擬了固定數(shù)據(jù)量的測試數(shù)據(jù)。

實(shí)驗(yàn)環(huán)境由5臺(tái)服務(wù)器搭建，使用3臺(tái)服務(wù)器構(gòu)建消息總線，在其上分別部署ZooKeeper集群和Kafka集群；使用1臺(tái)服務(wù)器作為數(shù)據(jù)中心；另外1臺(tái)服務(wù)器作為高性能計(jì)算機(jī)。用于傳輸消息的消息主題有3個(gè)分區(qū)、3個(gè)副本。

4.2 實(shí)驗(yàn)結(jié)果

4.2.1 資源信息服務(wù)的時(shí)間開銷和系統(tǒng)負(fù)載

資源信息服務(wù)從數(shù)據(jù)傳輸?shù)臅r(shí)間開銷和所產(chǎn)生的系統(tǒng)負(fù)載2個(gè)維度來進(jìn)行性能評(píng)估。實(shí)驗(yàn)中使用數(shù)據(jù)量分別為10 MB，20 MB，30 MB，40 MB，50 MB，60 MB，70 MB，80 MB，90 MB，100 MB。聚合資源信息模塊從高性能計(jì)算機(jī)中提取資源信息并放入消息總線記為“put”操作；數(shù)據(jù)中心從消息總線獲取信息，將其存儲(chǔ)到數(shù)據(jù)庫記為“get-database”操作；存儲(chǔ)至文件記為“get-file”操作。

本實(shí)驗(yàn)評(píng)估了SCE2.0的put、get-file和get-database 3種操作的時(shí)間開銷和系統(tǒng)負(fù)載。此外，本實(shí)驗(yàn)評(píng)估了單個(gè)數(shù)據(jù)中心的SCE1.0的信息服務(wù)的性能，并與其進(jìn)行對(duì)比，分析性能優(yōu)勢(shì)。

SCE2.0中put、get-file和get-database操作的時(shí)間開銷與數(shù)據(jù)量的關(guān)系如圖7(a)所示。put、get-file和get-database操作的時(shí)間開銷均隨著數(shù)據(jù)量的增長而增加。當(dāng)數(shù)據(jù)量達(dá)到100 MB時(shí)，put操作時(shí)間開銷不超過5 s，get-file操作的時(shí)間開銷不超過2 s，這是極其高效的。由于數(shù)據(jù)庫連接操作的時(shí)間開銷較大，get-database操作的時(shí)間開銷要長得多。因此，當(dāng)環(huán)境中資源信息量巨大時(shí)，可以考慮將資源信息存儲(chǔ)到文件。

(a) SCE2.0時(shí)間開銷

(b) SCE2.0系統(tǒng)負(fù)載

(c) SCE1.0時(shí)間開銷

(d) SCE1.0系統(tǒng)負(fù)載

圖7 系統(tǒng)操作的時(shí)間開銷與系統(tǒng)負(fù)載

SCE2.0中put、get-file和get-database操作引起的系統(tǒng)負(fù)載與數(shù)據(jù)量的關(guān)系如圖7(b)所示。系統(tǒng)1 min內(nèi)的平均負(fù)載隨著數(shù)據(jù)量的增加而變化，但不是完全規(guī)則的。整體來看，get-file操作引起的系統(tǒng)負(fù)載是最穩(wěn)定的，并且遠(yuǎn)低于put和get-database操作引起的系統(tǒng)負(fù)載。實(shí)驗(yàn)中所用服務(wù)器有8核，正常的系統(tǒng)平均負(fù)載值不應(yīng)超過8。上述實(shí)驗(yàn)結(jié)果中，put、get-file和get-database操作引起的系統(tǒng)負(fù)載均低于1，遠(yuǎn)遠(yuǎn)低于上限。

圖7(c)和圖7(d)分別展示了SCE1.0中信息傳輸?shù)臅r(shí)間開銷和系統(tǒng)負(fù)載與數(shù)據(jù)量的關(guān)系。當(dāng)消息大小達(dá)到5 MB時(shí)，時(shí)間開銷接近250 s；系統(tǒng)負(fù)載大于90，遠(yuǎn)遠(yuǎn)高于上限。SCE2.0在處理5 MB的消息時(shí)，時(shí)間開銷不超過2 s，系統(tǒng)負(fù)載不高于0.5，性能遠(yuǎn)遠(yuǎn)好于SCE1.0。

綜上所述，單個(gè)數(shù)據(jù)中心的SCE1.0在處理數(shù)據(jù)量較大的資源信息時(shí)，遇到了性能瓶頸。而多個(gè)數(shù)據(jù)中心的SCE2.0比SCE1.0更加高效，能夠輕松處理大量數(shù)據(jù)。SCE2.0資源信息服務(wù)的較小的時(shí)間開銷有利于提升用戶體驗(yàn)，較低的系統(tǒng)負(fù)載可以減輕服務(wù)器的壓力。

4.2.2 消息總線的吞吐量

本實(shí)驗(yàn)對(duì)并行put和get-file操作的吞吐量與線程數(shù)目的關(guān)系進(jìn)行評(píng)估。執(zhí)行put操作的服務(wù)器有40核，并且系統(tǒng)中沒有其他進(jìn)程影響系統(tǒng)狀態(tài)，因此執(zhí)行put操作的最大并發(fā)線程數(shù)目為40。實(shí)驗(yàn)中所用的消息主題的分區(qū)數(shù)為10，因此get-file操作的最大并發(fā)線程數(shù)目為10。實(shí)驗(yàn)使用測試數(shù)據(jù)，數(shù)據(jù)量為1 000 MB。

put和get-file操作的吞吐量和系統(tǒng)負(fù)載隨線程數(shù)目的變化情況如圖8所示。從實(shí)驗(yàn)結(jié)果可以看出，隨著線程數(shù)目的增加，put和get-file操作的吞吐量均線性增加。當(dāng)put操作的并發(fā)線程數(shù)目為40時(shí)，吞吐量可達(dá)51 581條/s信息；當(dāng)get-file操作的并發(fā)線程數(shù)目為10時(shí)，吞吐量可達(dá)51 564條/s信息。執(zhí)行put操作的服務(wù)器有40核，系統(tǒng)負(fù)載上限為40；執(zhí)行g(shù)et-file操作的服務(wù)器有8核，系統(tǒng)負(fù)載上限為8。由put操作引起的系統(tǒng)負(fù)載均小于3，遠(yuǎn)低于上限40；由get-file操作引起的系統(tǒng)負(fù)載均小于2，遠(yuǎn)低于上限8。由此得出結(jié)論，消息總線并行傳輸信息具有較高的吞吐量，且不引起過高的系統(tǒng)負(fù)載。當(dāng)環(huán)境中信息量巨大時(shí)，可以使用多線程并發(fā)地處理資源信息。

(a) put吞吐量

(b) get-file吞吐量

(c) put系統(tǒng)負(fù)載

(d) get-file系統(tǒng)負(fù)載

圖8 put操作和get-file操作的吞吐量與系統(tǒng)負(fù)載

4.2.3 消息總線的吞吐量與Kafka的吞吐量對(duì)比

本實(shí)驗(yàn)使用真實(shí)數(shù)據(jù)進(jìn)行測試，將消息總線的吞吐量和Kafka的吞吐量進(jìn)行對(duì)比。

實(shí)驗(yàn)結(jié)果如圖9所示。消息總線的吞吐量和Kafka的吞吐量非常接近，對(duì)Kafka的封裝并沒有降低其性能。

國家重點(diǎn)研發(fā)計(jì)劃“高性能計(jì)算”重點(diǎn)專項(xiàng)的總體目標(biāo)是突破E級(jí)計(jì)算機(jī)核心技術(shù)，研制滿足應(yīng)用需求的E級(jí)高性能計(jì)算機(jī)系統(tǒng)[1]。本文提出的消息總線及基于消息總線開發(fā)的資源信息服務(wù)具有高吞吐量和低負(fù)載處理能力，可以滿足E級(jí)高性能計(jì)算機(jī)系統(tǒng)對(duì)環(huán)境的高效處理作業(yè)請(qǐng)求、高效傳輸資源信息的需求。

圖9 消息總線和Kafka的吞吐量對(duì)比

5 結(jié) 論

本文提出了基于消息總線的、支持多數(shù)據(jù)中心的高性能計(jì)算環(huán)境系統(tǒng)軟件的優(yōu)化設(shè)計(jì)SCE2.0；實(shí)現(xiàn)了消息總線及基于消息總線開發(fā)的資源信息服務(wù)；提出了根據(jù)實(shí)時(shí)系統(tǒng)狀態(tài)自動(dòng)計(jì)算并行線程數(shù)目的公式，顯著提高了系統(tǒng)的吞吐量；采用“發(fā)布-訂閱”模式，提供異步編程接口，簡化服務(wù)開發(fā)流程；完成了消息總線及資源信息服務(wù)的性能評(píng)估實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果表明，SCE2.0使用多線程并行處理消息時(shí)的吞吐量已達(dá)到51 000條/s，同時(shí)縮短了用戶響應(yīng)時(shí)間，降低了系統(tǒng)負(fù)載。

基于消息總線的、支持多數(shù)據(jù)中心的SCE2.0打破了現(xiàn)有的單個(gè)數(shù)據(jù)中心的SCE1.0的性能瓶頸，實(shí)現(xiàn)了高效、高可擴(kuò)展和高可靠的目標(biāo)。支持多個(gè)數(shù)據(jù)中心同時(shí)提供服務(wù)，某個(gè)中心出現(xiàn)異常，環(huán)境仍可以正常提供服務(wù)，具有高可用性。目前，SCE2.0的資源信息服務(wù)已在測試環(huán)境中上線。在未來的工作中，資源信息服務(wù)將被部署于正式環(huán)境進(jìn)行多個(gè)數(shù)據(jù)中心的測試，測試無誤后正式上線使用。同時(shí)基于消息總線開發(fā)更多服務(wù)，逐步替換SCE1.0。