當前， AI、大資料、雲計算等技術逐漸成熟，5G 網路大規模建設等各種趨勢共同推動了通訊網路的代際演進。與此同時，企業通訊網路數字化轉型也面臨著一些挑戰：業務越來越複雜、基礎網路越來越繁瑣、連線數的增加和頻寬的快速增長問題等。
焱融科技以自動駕駛行業為例，分析近年來各家自動駕駛企業發展受限的因素。在上一篇《精選案例 | YRCloudFile 引領自動駕駛儲存技術新趨勢》中，基本已經覆蓋了自動駕駛企業目前所遇到的問題，但是還有一個核心限制發展因素，我們還沒有探討，那就是萬兆網路已經不足以匹配當今主流的算力及 NVMe 效能。
自動駕駛訓練對網路環境要求極高，然而很多自動駕駛廠商現有的萬兆網路在頻寬和延遲上無法滿足高速的自動駕駛需求。因此，焱融科技針對自動駕駛廠商的網路頻寬問題方面，提出了相應的解決方案。
焱融科技將分享基於國內無人駕駛商用、集裝箱物流人工智慧全域性化等領域領跑市場，業務已遍佈海內外 80 餘個節點的的某全棧式人工智慧創新公司的產品落地案例。本次分享集中在“網路頻寬受限”這一行業焦點，從“挑戰分析、解決方案和行業案例”三個方面提出觀點和建議，希望能為更多關注自動駕駛，以及相關從業者提供破解思路。
自動駕駛的網路頻寬挑戰
此前，國內某國內全棧式人工智慧創新公司在自動駕駛車輛訓練過程中，隨著訓練時間逐漸增多，出現網路資料量暴漲、應用程式激增等情況，致使該公司對網路頻寬和儲存效能的需求變得越來越高，原有的網路頻寬和儲存方式已經不適配於當前場景。主要原因有以下：
1. 萬兆網路似“小水管”，傳輸過程易擁堵
該公司使用的萬兆網路頻寬成訓練瓶頸，導致底層堆砌再多磁碟，儲存效能也無法得到提升，從而使得上層 GPU 伺服器效能無法得到充分發揮。同時，隨著業務量的提升，原有儲存網路無法很好的支撐大規模併發訪問，致使頻繁出現效能問題。
2. 海量檔案需儲存，效能衰減超乎想象
在自動駕駛訓練過程中，資料呈現出幾何式增長。小資料集達到十萬級別，大資料集達到百萬、千萬甚至上億級別。而且資料型別繁多、資料大小變化大，往往極易產生上億級的海量小檔案，給元資料管理、儲存效率和訪問效能等方面帶來巨大挑戰。
3. 難以解決儲存產品與容器平臺對接問題
儲存產品對容器平臺的相容性差，塊儲存掛載操作複雜，NAS 儲存無法細粒度管理儲存等等，無法適應上層敏捷的應用需求。除此以外，還會面臨對接容器編排管理平臺後，儲存維護複雜，流程繁瑣，導致容器業務中斷等問題。
YRCloudFile 助力自動駕駛衝刺“最後100米”
為了解決該公司在自動駕駛訓練場景所面臨的問題，焱融科技進行了一些系列的分析，並從網路改造、儲存部署、容器化支援、智慧分層等方面提供了一整套高效能、高可用、高擴充套件的方案。
1. 全面升級網路頻寬，邁向自動駕駛下一個臺階
在正式改造以前，焱融科技深度研究了該公司的網路架構和原有儲存體系，發現原有網路頻寬成為影響儲存效能提升的關鍵之一。
網路拓撲圖
焱融科技推薦新增 25Gb 交換機的方式，讓該公司做到儲存內部資料互動，克服網路頻寬限制帶來的儲存效能瓶頸，充分發揮 GPU 伺服器的效能，達到訓練效率翻倍提升的要求。
在儲存改造升級完畢後，焱融科技還發現，該公司現有叢集的效能雖然已經超過原有儲存系統，但卻沒有達到預期的數值。因此，焱融科技再次針對現場環境進行分析，提出以下幾點最佳化措施：
- 增大節點上的 socks 數量，獲得更大的連線數；
- 調整執行緒數 workers，以匹配訪問的數量；
透過上述兩個步驟，調整以後的 YRCloudFile 效能得到了大幅的提升，在一定程度上保證了儲存效能，減少了網路頻寬對儲存帶來的影響。
2. 海量小檔案場景下，元資料處理能力是關鍵
針對客戶海量小檔案效能問題，焱融科技透過可水平擴充套件設計的 MDS 架構，實現 MDS 叢集化。這主要考慮到以下三方面：
- MDS 叢集化有利於緩解 CPU，降低記憶體壓力；
- 多個 MDS 有利於企業儲存更多元的資料資訊；
- 在實現元資料處理能力水平擴充套件的同時，提升海量檔案併發訪問的效能。
目前，焱融 YRCloudFile 主要採用靜態子樹 + 目錄Hash兩者結合的方式搭建可水平擴充套件設計的 MDS 架構。此種架構方式有兩種好處，首先元資料的分佈儲存，透過擴充套件元資料節點，即可支援百億級別的檔案數量；其次，保證了元資料的檢索效能，減少在多個節點上進行元資料檢索和操作。
3. 整合 K8S 平臺，為容器化訓練無縫提供資料支援
該人工智慧創新公司在車輛測試過程中，選擇了以容器為應用執行載體的 K8S 平臺，執行 AI 訓練和推理任務。然而，在儲存系統在對接容器場景時，遇到了以下難題：
- 採用 in-tree 型別的儲存程式碼，使得 K8S 和儲存廠商的程式碼緊耦合；
- in-tree 儲存程式碼中的 BUG 會引發 K8S 元件不穩定；
- in-tree 儲存外掛享有與 K8S 核心元件同等的特權，存在安全隱患；
- 僅支援部分 AccessModes、PV 管理、故障等方面的特性。
焱融 YRCloudFile 針對容器化場景的功能進行了最佳化：
- 企業級功能：透過 YRCloudFile 管理介面對 PV 進行讀寫頻寬、IOPS 等效能分析，實現 PV 熱點定位功能。同時，支援 PV Quota、Resize、QoS 等功能；
- 多種讀寫模式：YRCloudFile 支援 ROX、RWO、RWX 等多種讀寫模式；
- 有狀態容器的跨節點重建：資料在整個 K8S 平臺各個計算節點上，都隨時可用，重建過程無需人工干預，實現數秒內完成；
- 實現 CSI 對 PV 的智慧排程: YRCloudFile 具有 CSI 故障智慧感知功能，K8S 建立需要持久化儲存的 Pod 時，CSI plugin 容器異常，以及與儲存叢集連線異常的節點會被自動過濾；
YRCloudFile 容器儲存
4. 客戶端多級智慧快取，提升訓練整體效能
自動駕駛訓練資料有很多型別，例如影片、圖片等。針對於資料的格式也很多，例如：json、txt、jpg 等等。不同的資料資訊相應的儲存資料量也是不一樣的，所以普通檔案快取容易出現只提供記憶體快取的情況，導致容量有限，通常一臺 GPU 伺服器可用的記憶體快取數僅 10GB。
因此，YRCloudFile 透過私有客戶端，可以提供多級智慧快取：
- 記憶體快取 + GPU 伺服器 SSD 快取：在 GPU 伺服器上，YRCloudFile 可配置一定容量的 SSD 快取，實現訓練程式優先從客戶端記憶體快取中載入；
- 對訓練框架、應用程式完全透明；
- 在整個訓練中，資料集載入速度實測提升幅度超過 500%。
YRCloudFile 多級智慧快取
YRCloudFile 全面解決自動駕駛儲存問題
對於大多數自動駕駛企業而言，資料具有階段性熱點訪問的特點，超過一定時間後，80% 以上的資料逐步轉冷。熱資料的訪問效能要求較高，經過一定時間週期之後，熱資料逐漸變冷，應用訪問這些冷資料的頻率會變得很低。因此，自動駕駛企業在整個冷熱資料分層的過程之中，常常遇到以下問題：
- 在對接物件儲存過程中，如若進行冷熱資料分層，容易面臨上層業務介面是否改變，以及資料訪問路徑是否改變的問題；
- 針對不同業務型別是否可以區別定義；
- 冷資料下刷以後，效能是否存在下降；
針對上述問題，YRCloudFile 檔案儲存系統提供了智慧分層功能，實現根據使用者需求，自定義冷熱資料策略，冷資料自動流動至低成本的公有云物件儲存，並完成壓縮。向上仍然為業務提供標準的檔案訪問介面，並保持目錄結構不變，實現資料在冷熱資料層之間流動對業務完全透明，有效針對成本和效能平衡問題。主要最佳化方式如下：
（1） 標準檔案介面，資料訪問路徑不改變
上層應用無需任何改造，焱融儲存對外提供標準的檔案介面。冷熱資料自動分層無需管理員進行干預，實現按照自定義策略下刷至物件儲存，對外仍然暴露統一的檔案系統名稱空間。使用者在使用過程中，並不會受到物件儲存層影響，訪問路徑仍舊符合使用者儲存習慣。
（2） 目錄級智慧分層
YRCloudFile 可以自定義不同業務、不同資料型別的冷資料。對於資料中心而言，不同的應用，對冷資料的定義是不同的，對資料存放的要求也不同。例如資料安全要求高的冷資料需要存放在本地；資料安全要求低的資料可以存放在公有云。或者訓練資料在被頻繁的訓練 2 周之後就不再訪問，而訓練結果資料則會在很長的時間段內一直需要頻繁訪問。
（3） 冷資料效能不降級
高效讀寫，保證冷資料讀寫效能。可配合各類排程策略，實現資料的預熱，進一步減少計算時的 IO 等待時間。
（4） 分層映象雙活
- 資料冗餘保證資料安全；
- 優先本地讀保證讀寫效能；
- 物件儲存故障保證業務連續性；
- 物件儲存故障自動恢復；
- 優先本地讀減少公有云物件呼叫費用。
透過冷、熱資料智慧分層的方式，YRCloudFile 可以滿足絕對大多數企業在自動駕駛訓練過程中，對於儲存高效能和資料長期儲存的需求。
YRCloudFile 分散式檔案儲存架構圖
目前，在 YRCloudFile 的幫助下，該人工智慧創新公司順利解決了儲存網路頻寬成為效能瓶頸的問題，並且儲存平臺與上層容器進行無縫整合，實現資源平臺的統一排程與管理。
