JuiceFS 在多雲端儲存架構中的應用 | 深勢科技分享

2020 年末，谷歌旗下 DeepMind 研發的 AI 程式 AlphaFold2 在國際蛋白質結構預測競賽上取得驚人的準確度，使得 “AI 預測蛋白質結構” 這一領域受到了空前的關注。今天我們邀請到同領域企業，深勢科技為大家分享其搭建基礎平臺時的實踐與思考。AI 場景中的使用的資料有哪些新特點？混合雲架構如何與超算平臺結合？為何會選擇 JuiceFS？

背景

深勢科技成立於 2018 年，是 “AI for Science” 科學研究正規化的先行者，致力於運用人工智慧和分子模擬演算法，結合先進計算手段求解重要科學問題，為人類文明最基礎的生物醫藥、能源、材料和資訊科學與工程研究打造新一代微尺度工業設計和模擬平臺。

新一代分子模擬技術，是深勢科技研究問題的本質方法；高效能運算、機器學習、科學計算方法，這些是研究分子模擬技術的一些工具和手段。

Hermite 和 Bohrium 是針對不同行業領域的解決方案，Hermite 是針對藥物研發領域的一個計算設計平臺， Bohrium 是針對材料和科學領域的微尺度計算設計平臺，Lebesgue 是任務排程和算力編排平臺。

什麼是 AI for Science

一直以來對科學研究有兩大正規化，第一個是以資料驅動的開普勒正規化。第二個是以第一性原理驅動的牛頓正規化。

開普勒正規化是透過觀察、總結的方式，研究事物的規律，開普勒正規化三大定律就是透過不斷的天文觀測，前人積累的天文經驗總結出來的。開普勒正規化屬於資料驅動，透過觀察事物的現象，總結規律，然後拿它解決實際的問題。這種方式解決問題有一個缺點，可能會出現知其然不知所以然的情況，很難泛化。

牛頓正規化是從事物的本質出發，透過第一性原理，發現事物的規律。牛頓正規化屬於模型驅動，模型驅動比較準確，但因為計算的量大，很難用以解決實際的問題。

AI for Science (下文簡稱 AI4S） 就是希望把這兩大正規化結合起來，用 AI 去學習科學原理，然後得到模型，進而去解決實際的問題。

AI for Science 正規化如何解決科學原理工程化問題

藥物研發領域，大家比較熟悉的是明星公司 Deep Mind 開發的一款人工智慧程式 AlphaFold，簡單來說是做蛋白質的結構預測；材料研發主要是做材料的性質研究，新材料發現等。 這兩大領域本質研究的是微觀粒子的相互作用，微觀粒子的運動軌跡。在高中化學的時候，老師講過結構決定性質，性質決定用途。微觀粒子的研究會用到薛定諤方程、密度泛函方程、牛頓力學方程等基本方程，這些都是在不同的尺度下的微觀粒子的運動軌跡、運動狀態的方程。

如果直接用第一性原理去解決問題的話，實際上是比較困難的，會陷入 維數災難問題。 AI4S 新正規化就是用 AI 去學習和表示一系列的物理方程，進而去攻克維數災難，在精度和效率之間取一個平衡。

混合雲架構的選擇與挑戰

為什麼選擇混合雲架構

深勢科技作為一家初創公司，為什麼在開始的時候就選擇了混合雲的架構，總結下來，主要是有三點：

第一點業務算力的需求， AI4S 領域的主戰場是在超算，一些院校和研究所都有自己的超算機器。比較著名的就是天河系列，天河系列在 2014 年的時候拿到過 Top500 的第一名，它對計算的效能和算力的要求是非常高的。

上圖計算任務算力需求： 128 張 A100s 的卡執行 5 天的時間。

下圖是一個訓練任務，分為三步，每一步對資源的需求差別是比較大的。第一步和第三步，對 GPU 的資源要求比較高，第二步它對 CPU 的需求是比較大的，需要 10000+ 核的 CPU 資源。這也是 AI4S 的一個特點，同一任務對資源的需求，在不同階段差異是比較大的。

第二點是 客戶的訴求，一些客戶在使用深勢科技的資源或者產品之前，可能已經是 AWS 、阿里雲或者其他超算的使用者，客戶希望他們的資源能夠最大的程度的複用，從而提升資源的利用效率。

第三點是 資源的可用性，算力平臺負責給 AI4S 領域的工業客戶或者科學研究院校提供算力資源，他們對資源的需求是很大的，在資源使用過程中也會用到一些搶佔式資源和潮汐資源，對資源的可用性或者資源的豐富度要求高。所以選擇混合雲架構，也是比較大的一個優勢。

混合雲架構的挑戰

首先是 基礎設施的差異性，公有云是比較開放的，買了一臺機器之後，就有了這臺機器的 root 賬號，資源在底層做了虛擬化隔離，你可以在這個機器上做任何你想做的事情，不會影響到其他人。但是超算相對是比較封閉的，超算的環境是共用的，使用者之間是邏輯隔離的，超算更多的是把資源拿出來讓你去使用，但是你很難擁有資源的主導權，你在超算機器上安裝一個軟體，這個軟體可能跟別人的軟體是有衝突的，所以不能隨意安裝。

第二個是 執行時環境的差異性，公有云上跑服務的話會打一個映象，把程式依賴的一些作業系統以及依賴的一些軟體都會裝到映象裡面，直接做分發，這樣就能遮蔽執行時環境的差異性。但在超算裡面主要是藉助 module 工具管理環境變數，解釋下，module 是 Linux 下的一個管理環境變數的工具。如果想用一個軟體的話，需要透過 module 的方式把這個軟體增加進來，然後再去使用。

第三點是 使用者體驗的一致性，基於上面兩點，公有云和超算還是有比較大的差異性。這會導致使用者在使用的體驗上會有比較大的差異。如何把差異補齊，讓使用者在日誌、監控的檢視上都有一致性的體驗，對架構上也是一個挑戰。

雲與超算融合的探索

第一點就是 容器化，超算上主要是用的是 Podman 和 Singularity 容器映象，使用 Docker 是比較難的，因為 Docker 需要在主機上啟動一個 daemon 的程式，其次還需要 root 賬號。這兩點在超算上實際上都是不太方便的，所以超算上一般用的比較多的就是 Singularity 映象，Podman 和 Docker 映象有比較好的相容性，也慢慢流行起來。

第二點是  Slurm on K8s ，Slurm 在超算平臺上是常用的一個資源排程的框架，早期安裝 Slurm 是需要在物理機上直接安裝，但是隨著對資源彈性的需求，我們希望 Slurm 能直接裝到 K8s 裡面去。當使用者需要 Slurm 資源的時候，可以基於 K8s 去分配資源，然後在分配的 pod 上安裝 Slurm。

第三點就是  Virtual Kubelet，這是一個虛擬的 kubelet 技術。在阿里雲和 AWS 的彈性資源上也都有一些應用，相當於把一些算力資源透過橋接的方式讓 K8s 能使用起來。在超算上我們也在探索這種方案，讓 K8s 叢集透過 Virtual Kubelet 的方式使用超算的資源。

儲存架構的思考與實踐

舉一個業務場景的儲存例子，在藥物研發場景中，分子對接具有十分重要的應用價值，分子對接就是兩個或多個分子之間相互識別的過程，目的是找到藥物分子與致命靶點的最佳結合模式。一次分子對接的過程中資料的需求如下： 會產生約 6 億的小檔案，檔案壓縮前有 2.3T， 壓縮後有 1.5T，單檔案的大小大約 4k。

檔案比較小的話，資料處理的難度會比較大。比如：在 Linux 上去處理很多的小檔案時，它首先會有 inode 個數的限制，其次小檔案比較多的話，讀取的速度也上不去。

儲存訴求

基於上述的業務場景，我們總結下對儲存的訴求。 第一是 檔案的多樣性，除了小檔案，在實際業務場景中還有中檔案、大檔案，所以多種大小的檔案，都需要有一個比較好的支援。

第二點是 儲存層的抽象與統一，在 AI 領域，很多都是使用 Python 的服務，Python 的服務對 POSIX 介面是比較友好的，如果使用者在使用儲存的時候，需要頻繁地透過 S3 或 OSS 去下載資料的話，會對使用者會有體驗上有影響。

第三點是 方案的通用性，在公有云上會有很多的儲存方案，在一家雲上使用，完全沒問題，非常的好用。但如果想把這種方案放到超算上去，或者放到一些線下的叢集，實際上就不是那麼通用了。

第四點是 資料的分層，我們的資料是有典型的冷熱特性，在一個任務在計算過程中，它用到的資料是熱資料，任務計算之後或者過了幾天之後，這個資料就變成了冷資料，我們對冷資料的讀和操作是比較少的。

最後一點就是安全性的考慮，希望儲存上能有一些業務的隔離，配額、授權以及刪除之後的回收站等，來保障資料的安全性。

方案選型 & JuiceFS 測試

• 第一點是功能滿足度，這個方案肯定要滿足上述我們對儲存上的功能需求。
• 第二點是技術棧，所採用的技術棧最好是能和公司使用的技術棧是匹配的。
• 第三點是可運維性，希望這個方案的運維相對來說比較容易，如果方案本身的複雜度比較高，那麼出了問題之後，解決問題就比較麻煩和複雜。
• 第四點是社群活躍度，調研的時候我們發現 JuiceFS 社群是非常活躍的，在使用過程中，有問題的話，會直接發到 JuiceFS 社群群裡面，不論是晚上還是週末，社群的響應都是非常及時的，包括創始人蘇銳也經常在群裡面回答問題，所以社群的活躍度也是我們在方案選型的時候一個非常重要的考量點。

在做方案選型的時候做了一些測試，供大家參考，主要是以下幾點：

第一點是  POSIX 的相容性，我們對 POSIX 相容性會考慮得比較多，如果 POSIX 相容性不好，這個方案基本上是沒法用的。

第二點是 效能的基準測試，效能測試的資料見下圖。

第三點是  K8s 的 CSI 掛載，我們有一些業務是透過 K8s 排程的，自然是希望儲存對 K8s 比較友好。

第四點是 業務 PoC 驗證，測試的場景還是比較多的，從小檔案中檔案大檔案，還有包括順序讀，順序讀裡面又分為預熱和不預熱。

JuiceFS 有個功能特別好用，就是預熱的功能，當我們需要運算的時候，可以把一些資料提前的去做預熱。這功能對我們來說就非常實用，計算過程中任務依賴昂貴的 GPU 資源，成本是比較高的，一般我們會提前把資料預熱到本地，然後再開啟任務的執行。

上圖是我們整體的儲存架構，底層是基於物件儲存的統一的儲存，然後再往各個地方的計算中心分發資料，不論是超算，還是雲機房也好，都是有一個快取的叢集。當任務開始的時候，會把資料從統一的儲存中拉到計算叢集就近的一個快取叢集裡面去，在計算任務執行的過程中，只需要和本地的儲存叢集做通訊。

JuiceFS 可以把資料快取到本地，當資料比較舊的時候，它就會被淘汰掉。如果沒有用 JuiceFS ，我們需要自己去做快取的淘汰機制，想做好，還是有一定的成本的。但是有了 JuiceFS 之後，我們就不用考慮這個事情了，只需要把 JuiceFS 掛載上去，它就幫我們把這些事情都做了。

深勢科技目前使用的是一個開源版本的 JuiceFS，以 redis 作為後設資料管理，使用 SSD 做資料快取。

深勢科技生產環境使用情況

總結與展望

雲與超算融合是趨勢，現在一些公有云上都有超算服務，或者叫高效能運算服務，高效能運算叢集等。超算也是不斷的在往雲上去靠，超算裡面提到了一些超算雲或者雲超算的概念，就是透過虛擬化的技術，透過雲原生的技術，把超算的資源更好、更方便的提供出去，讓大家使用。

第二點 容器化是關鍵，我們在做雲與超算的融合的過程中，怎麼樣把執行時的環境保持一致，是一個很關鍵的點。如果在雲上用的是容器，但在超算上用的是另一套方案，會出現服務在雲上跑得好好的，但放到超算上之後就跑不起來，所以容器化是一個比較關鍵的點。

第三點 統一儲存是基礎，排程相對來說是比較容易的，把算力從公有云上排程到超算平臺上，其實是比較簡單的，但是將儲存排程過去難度就增加了。

這裡面會有幾個難點，第一點怎麼樣把資料從一個地方傳輸到一個地方。資料量小倒還好，但是資料量比較大就非常困難了。第二點是傳輸的網路，也會影響到資料傳輸的速度。第三點是資料的引用，把資料搬遷過去之後，怎麼樣和原來路徑或結構保持一致，在不改程式的情況，也能繼續執行。最後是資料的整合，比如整個計算過程中分為 5 步，前 2 步是在雲上算的，最後 3 步在超算上算的，會牽涉到資料的整合，日誌的整合，監控的整合。

最後， 存算分離是必然，如果機器資源和儲存是繫結的，是沒法去做排程的。早期，我們的儲存和機器算力是繫結的，機器上掛載了本地盤，當把計算任務調過去之後，儲存是調不過去的，所以說存算分離是必然。