重新審視 CXL 時代下的分佈式內存

消息傳遞與分佈式共享內存

隨着摩爾定律增長的逐漸減緩,系統規模的水平擴展已經成爲提升系統性能的關鍵策略。然而,這種擴展依賴於分佈式系統架構的支持,而分佈式編程的固有複雜性給構建高效、可靠及彈性的系統帶來了嚴峻挑戰。因此,簡化分佈式編程依舊是分佈式編程框架追求的核心目標。

 

如圖所示,在分佈式編程領域,目前主流的編程範式主要分爲兩類:消息傳遞(Message Passing,MP)和分佈式共享內存(Distributed Shared Memory,DSM)。DSM 範式因其提供一致的內存空間視圖和抽象化的數據通信複雜性而更易於使用,這樣的設計讓分佈式應用程序的能夠直接編程就像在單機上進行多線程編程一樣簡單。然而,在實際應用中,較爲直接但不太直觀的 MP 模型卻更爲普遍。開發者對 MP 的偏好很大程度上基於這樣一個假設:遠程通信的高昂開銷顯著影響了 DSM 系統的性能。

但是隨着網絡和互聯技術的飛速發展,研究者在逐漸改變對於該領域的看法,特別是隨着 Compute Express Link(CXL)技術的推出,我們站在了一個重新思考傳統分佈式編程範式的新起點。這個技術突破促使我們必須重新評估 DSM 在現代分佈式系統中的應用潛力。

從以太網到 RDMA 再到 CXL

 

從工業界將重心從以太網轉移到遠程直接內存訪問(RDMA),再到當前對Compute Express Link(CXL)的關注,這一連串變遷標誌着互連技術領域的一系列重大突破。RDMA 的廣泛採用極大地革新了現代數據中心的構架,並對衆多流行的分佈式系統設計產生了深遠影響,其中包括許多影響深遠的數據庫和存儲項目。通過利用 RDMA,我們能夠將遠程數據訪問的延遲從 100 多毫秒顯著降低到微秒量級,同時提供類似本機內存的讀/寫接口,極大地減少了遠程操作的成本。作爲最前沿的互聯協議,CXL 旨在提供高速且具備緩存一致性的跨物理節點數據傳輸。例如,DirectCXL[1] 將主機處理器與遠程內存資源連接,支持加載/存儲指令,其遠程 CXL內存訪問的延遲大約爲 300 納秒,與訪問遠程 NUMA 節點的延遲相媲美。CXL 2.0 的一個關鍵進步在於引入了內存池化功能,該功能可以構建全局內存資源池,以此優化內存的總體利用率。內存池化可以通過 CXL 交換機和內存控制器實現,便於內存資源的動態分配與回收。Pond 作爲第一個滿足雲服務提供商需求的全棧內存池[2],其基於 CXL 的內存池系統已在 Microsoft Azure 雲平臺上進行了小範圍部署。至今,大部分主流雲服務提供商都相繼宣佈了支持並研發基於 CXL 內存池的計劃。

進一步地,已公佈的 CXL 3.0/3.1 等規範版本,承諾將支持內存共享功能[3]。共享內存允許在多臺機器間映射同一內存區域,在這樣的配置下,硬件會自動管理不同機器併發訪問產生的緩存一致性問題,從本質上實現了基於硬件的分佈式共享內存模型。這一革命性的新功能爲分佈式計算的未來奠定了充滿無限可能性的基石。

重溫 CXL 時代 DSM 範式下的分佈式應用

儘管 Compute Express Link(CXL)的規範版本已經發展至 3.1,實際的硬件實現卻遠未跟上規範的快速進步。但這正是一個在即將來臨的 CXL 時代背景下,對消息傳遞(MP)和分佈式共享內存(DSM)之間區別重新審視的絕佳時機,關鍵在於理解它們的差異性,並識別最適合它們的應用場景。這兩種範式的主要區別在於它們所採用的接口:MP 依靠傳統的發送/接收接口,而 CXL 通過提供更細粒度的遠程 LOAD/STORE 指令集與 DSM 實現更緊密的一致性。然而,我們認爲計算與內存關係的根本假設纔是更關鍵的考量因素。

 

首先,消息傳遞範式傾向於採取緊密耦合的架構,每個節點僅能訪問其本地內存。而支持 CXL 的 DSM 系統則自然傾向於解耦架構,將計算和內存資源分散到不同的資源池中[4],這樣做能夠實現資源的更靈活、更高效利用。其次,就數據通信而言,消息傳遞通常涉及將數據有效負載從一個節點複製到另一個節點,這是一種按值傳遞(pass-by-value)的方法。另一方面 DSM 使用了引用傳遞的方法,只需要交換對於對象的引用使用了引用傳遞(pass-by-reference)方法。這有助於僅訪問必要的數據部分,並實現就地更新,爲一些特性的場景帶來顯著的性能提升。例如,我們開發了一個基於 CXL 的 RPC 系統POC,用於驗證引用傳遞的優勢。它避免了數據複製和網絡棧的開銷,因此吞吐量比傳統的基於 RDMA 的 RPC 系統高出 4 倍以上

 

最後,DSM 提供了全局內存空間的可訪問性,這意味着所有數據和狀態都是共享的。這一特性有利於工作負載的快速遷移。例如,在“share-nothing”架構中解決負載不均衡問題通常需要數據的大量重新分區,而在“share-everything”模式下,只需交換代表數據分區所有權的元數據即可。

 

總而言之,在那些需要高度靈活性的應用場景中,基於 CXL 的 DSM 表現出色。CXL 架構自然支持這種靈活性,它提供了動態且高效的方式來分配和訪問遠程內存資源,這對於需要能夠快速、高效擴展的系統來說至關重要。

基於 CXL 的 DSM 面臨的挑戰

然而,過渡到基於 CXL 的 DSM 範式不僅僅只是享受硬件進步的紅利。DSM 範式通過使用同一地址內存空間來維護共享狀態,從而實現更快的數據傳輸和遷移,同時將計算與內存解耦以增強可擴展性。然而,考慮到併發訪問的情況以及可能出現的部分故障(partial failure),管理這些共享狀態會比傳統的 share-nothing 架構更加複雜。

本質上,我們面臨的挑戰源於共享分佈式對象和引用它們的客戶端分別有單獨的故障域。具有這種單獨的故障域,能夠允許客戶端在執行任務期間自由加入、離開系統甚至宕機,因爲它們創建、釋放和交換對遠程內存的引用。雖然這種靈活性是用戶友好的,但它給內存管理帶來了巨大的挑戰。我們將其稱爲部分故障彈性 DSM (RDSM),以將其與所有客戶端同時失敗的情況區分開來。我們認爲,有效處理部分故障對於擴大 DSM 的使用至關重要。

爲了應對這些挑戰,我們在 SOSP 23 上的論文“Partial Failure Resilient Memory Management System for (CXL-based) Distributed Shared Memory”[5] 提出了一種採用引用計數來減少回收遠程內存所涉及的手動工作量的方法。然而,標準引用計數系統對於系統故障而言魯棒性並不強。我們將維護自動引用計數的過程分爲兩個不同的操作。當客戶端想要創建引用時,第一步是增加引用計數。接下來,我們通過將引用的值賦爲被引用空間的地址來鏈接該引用。而回收引用是一個類似的兩步過程:遞減引用計數,然後將引用設置爲 NULL。雖然只有兩個簡單的步驟,但它們的順序至關重要。如果這兩個步驟之間發生系統崩潰,就會出現問題。

例如,如果我們增加引用計數但由於崩潰而未能設置引用,則可能會導致內存泄漏。一個簡單的解決方案是使用鎖來確保引用計數的修改是冪等的,並記錄此更改以用於後續出現錯誤之後的恢復。然而這種方法僅在所有客戶端同時失敗的情況下才有效。在部分失敗的情況下,客戶端可能在獲取鎖後崩潰,這可能會導致我們方案進一步的複雜化。爲了解決這個問題,我們改變了原始算法中使用鎖的方式,轉而使用了分佈式矢量時鐘來做非阻塞更新。這一調整使我們能夠保持全局一致的時間表,而不需要鎖機制。有關該方法的更多詳細信息請參見論文。

未來方向:基於 CXL 的 DSM 商業化策略

除了探究基於 CXL 的部分故障容錯 DSM 架構的技術細節,我們還發現這種範式與雲計算的發展方向不謀而合;雲計算本質上追求的是極致的彈性。雲基礎架構的演進帶來了更細膩的計費模式,促使用戶和提供方都能實現更高層次的資源使用效率。然而,由於傳統應用程序固有的缺乏彈性,尤其是它們對內存狀態的本地化處理,常常未能充分利用這些技術進步帶來的潛在優勢。突破這一侷限,將是 CXL 研究領域面臨的重要機會和挑戰。

後記

受到 ACM SIGOPS(美國計算機協會操作系統興趣組)邀請,本文英文版發表在該協會的博客上(https://www.sigops.org/2024/revisiting-distributed-memory-in-the-cxl-era/)。本文的相關工作 CXL-SHM 則發表在操作系統頂級會議 SOSP 23 上。

作者:阿里巴巴技術專家馬騰 、清華大學助理教授章明星

引用

  • [1] Donghyun Gouk, Sangwon Lee, Miryeong Kwon, and Myoungsoo Jung. 2022. Direct Access High-Performance Memory Disaggregation with DirectCXL. In 2022 USENIX Annual Technical Conference (USENIX ATC 22). 287–294.
  • [2] LI, H., BERGER, D. S., HSU, L., ERNST, D., ZARDOSHTI, P., NOVAKOVIC, S., SHAH, M., RAJADNYA, S.,LEE, S., AGARWAL, I., ET AL. Pond: Cxl-based memory pooling systems for cloud platforms. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (2023), pp. 574–587.
  • [3] 2022. Compute Express Link 3.0. https://www.computeexpresslink.org/_files/ugd/0c1418_a8713008916044ae9604405d10a7773b.pdf.
    [4] 2022. Compute Express Link CXL 3.0 is the Exciting Building Block for Disaggregation. https://www.servethehome.com/compute-expresslink-cxl-3-0-is-the-exciting-building-block-for-disaggregation/
  • [5] ZHANG, M., MA, T., HUA, J., LIU, Z., CHEN, K., DING, N., DU, F., JIANG, J., MA, T., AND WU, Y. Partial failure resilient memory management system for (cxl-based) distributed shared memory. In Proceedings of the 29th Symposium on Operating Systems Principles (2023), pp. 658–674.

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章