基于消息總線的高性能計算環(huán)境系統(tǒng)軟件優(yōu)化設計與實現(xiàn)①

吳 璨 王小寧 肖海力 和 榮 趙一寧 遲學斌

(*中國科學院計算機網(wǎng)絡信息中心 北京 100190) (**中國科學院大學 北京 100049)

0 引 言

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

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

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

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

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

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

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

1 總體結構設計

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

圖1 SCE2.0層次架構

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

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

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

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

SCE2.0的資源層和應用層與SCE1.0結構相同，本文的工作重點是消息總線和服務層的設計與實現(xiàn)。服務層的各服務設計和實現(xiàn)流程具有相似性，本文僅詳細介紹資源信息服務的設計和具體實現(xiàn)。

2 消息總線的設計與實現(xiàn)

2.1 消息主題管理

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

環(huán)境中的信息按照類別進行區(qū)分，每一個類別通過一個消息主題傳輸數(shù)據(jù)，消息主題名稱存儲結構如圖2所示。環(huán)境中的信息可以分為資源信息(resource)、監(jiān)控信息(monitor)、日志信息(log)和請求信息(request)。每一類信息又可細分為若干小類。在與消息總線通信時，可以指明具體的消息主題，如“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個屬性，分區(qū)數(shù)表示消息被分為幾部分處理；副本數(shù)表示消息被復制幾份。分區(qū)數(shù)越多，消息處理效率越高，副本數(shù)越多，消息安全系數(shù)越高，分區(qū)數(shù)和副本數(shù)受集群中服務器個數(shù)限制。

圖2 消息主題名稱存儲結構

2.2 消息總線接口設計

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

表1 異步編程接口

表1續(xù)

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

2.3 消息總線部署結構

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

圖3 消息總線部署結構

2.4 可擴展性設計

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

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

接入新結點時，只需按照結點配置模板設置結點的配置信息。資源信息服務即可自動檢測新結點的配置信息，將其增添至資源信息數(shù)據(jù)庫。

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

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

消息總線中的負載均衡器是集成不同負載均衡算法的框架，其定義了負載均衡算法接入的輸入/輸出標準，并提供了接入接口。本項目中的另一個團隊正致力于研究負載均衡算法，旨在未來的工作中集成更多高效的負載均衡算法。

圖4 消息總線的負載均衡策略

2.5 可靠性設計

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

圖5 消息總線的可靠性設計

2.5.1 身份認證

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

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

2.5.2 權限管理

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

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

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

2.5.3 雙層異地數(shù)據(jù)備份

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

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

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

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

3 資源信息服務的設計與實現(xiàn)

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

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

圖6 資源信息傳輸結構圖

3.1 聚合資源信息

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

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

表2 資源信息標準化格式

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

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

表3 作業(yè)狀態(tài)標識符

3.2 同步資源信息

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

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

3.3 并行傳輸信息

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

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

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

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

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

4 實驗結果與分析

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

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

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

表4 CSWA工作負載詳細信息

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

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

4.2 實驗結果

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

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

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

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

(a) SCE2.0時間開銷

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

(c) SCE1.0時間開銷

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

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

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

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

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

4.2.2 消息總線的吞吐量

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

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

(a) put吞吐量

(b) get-file吞吐量

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

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

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

4.2.3 消息總線的吞吐量與Kafka的吞吐量對比

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

實驗結果如圖9所示。消息總線的吞吐量和Kafka的吞吐量非常接近，對Kafka的封裝并沒有降低其性能。

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

圖9 消息總線和Kafka的吞吐量對比

5 結 論

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

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