AI 企業多雲存儲架構實踐 | 深勢科技分享
- 2022 年 7 月 6 日
- 筆記
2020 年末，Google旗下 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 步在超頻上算的，會牽涉到數據的整合，日誌的整合，監控的整合。
最後，存算分離是必然，如果機器資源和存儲是綁定的，是沒法去做調度的。早期，我們的存儲和機器算力是綁定的，機器上掛載了本地盤，當把計算任務調過去之後，存儲是調不過去的，所以說存算分離是必然。
如有幫助的話歡迎關注我們項目 Juicedata/JuiceFS 喲！ (0ᴗ0✿)
