Yunzhisheng は、音声および言語処理に重点を置いたテクノロジ企業から、テクノロジ スタックを開発して、画像、自然言語処理、信号などのフルスタック AI 機能を備えた、中国の主要な人工知能ユニコーン企業です。同社はクラウド コンピューティングを採用し、スマート ヘルスケア、スマート ホテル、スマート教育に対応するソリューションを提供しています。
Atlas は Unisound の基盤となるテクノロジー プラットフォームであり、すべての Unisound モデルの反復をサポートします。
1層目はビジネス層で、主に音声処理、画像処理、自然言語処理などの自社のビジネスです。
2層目はコントロールセンターで、データ制作、データアクセスからモデルリリースまでワンストップで完結できます。
3 番目のレイヤーは、主にディープ ラーニングとデータの前処理をサポートするコア コンピューティング レイヤーです。
最下層はインフラストラクチャ層で、主に GPU クラスター、CPU クラスター、分散ストレージで構成され、すべてのマシンは 100Gbps の InfiniBand 高速ネットワークで接続されています。
ストレージのシナリオと要件
Unisound の最初の構築目標は、AI モデルの作成、データの前処理、モデル開発、モデルのトレーニング、最終的なモデルの立ち上げを含む、ワンストップの AI プラットフォームを構築することです。
上の図に示すように、各ステップはデータとやり取りする必要があり、データの前処理とモデルのトレーニングには比較的大きな IO が必要です。
• データの前処理、主に音声処理は音声特徴を抽出し、音声特徴を numpy 形式のファイルに変換します; 画像処理の過程で、画像は前処理され、トレーニング データの形式変換が行われます; • モデル開発、主にアルゴリズムですコードを編集し、モデルのアルゴリズムをデバッグするエンジニア; • モデルのトレーニングでは、途中で複数回のデータ読み取りが必要になり、モデルは対応するストレージに出力されます. このステップに必要な IO は非常に大きい; ,サービスは、ストレージ システム内のモデル ファイルを読み取ります。ストレージ要件を要約すると、次のようになります。
- モデル開発全体に接続できる完全なリンクは、いくつかのコア機能ブロックでサポートされている必要があります。
- CPU、GPU データ読み取りタスクをサポートします。
- 私たちのシナリオは主に音声、テキスト、および画像データであり、これらのシナリオは比較的ファイル サイズが小さいという特徴があるため、小さなファイル シナリオでの高性能処理をサポートする必要があります。
- 私たちのビジネス シナリオは主に読み取りを増やし、書き込みを減らすことです. モデルのトレーニング中は、ほとんどのデータが読み取られ、基本的にデータは書き込まれません。上記の要件に基づいて、高性能で信頼性の高い分散ストレージ システムが必要です。
Unisound Storage 建設履歴
初期の頃、GPU は十数個しかなく、NFS を使用して小規模なクラスターを構築しました。同時に、CephFS テスト環境が 2016 年に導入されました。当時、CephFS のそのバージョンのパフォーマンスは小さなファイルのシナリオではあまり良くなかったため、CephFS は本番環境に持ち込まれませんでした。
その後も調査を続けた結果、Lustre が HPC 分野で最も一般的に使用されている高性能ファイル システムであることがわかりました。テストでは、Lustre が大規模な構築とパフォーマンスの点で優れていることが示されているため、2017 年から 2022 年まで、Lustre を使用してすべてのデータ サービスを実行します。
しかし、ますます多くの GPU が使用され、現在では約 570 エクサフロップス/秒の浮動小数点処理能力を備えているため、基盤となるストレージの IO は、上位層のコンピューティング能力に追いつくことができなくなりました。そのため、新しいストレージとその後のストレージ拡張のためのアップグレードを検討し始めましたが、同時に、Lustre を使用する過程でいくつかの問題にも遭遇しました。
まず、運用と保守の方法. Lustre は主にカーネルに基づいており、カーネルに直接組み込まれています. 場合によっては、配置の問題には、マシンの再起動などの操作が含まれます。
2 つ目: テクノロジー スタック。クラウド プラットフォームの開発は主に golang に基づいているため、開発言語との互換性が高いストレージを使用することを好みます。Lustre は C 言語を使用しており、カスタマイズと最適化の点でより多くの人手を必要とします。
第三: データの信頼性. Lustre は主にハードウェアの信頼性 (RAID テクノロジなど) に依存し、ソフトウェア層は主にメタデータ ノードとオブジェクトおよびデータ ノードの HA ソリューションを実装します。これらと比較して、3 つのコピーや消去コードなど、より信頼性の高いソフトウェア ソリューションを使用することを依然として好みます。
4番目: マルチレベル キャッシングの機能要件. 2021 年には、Fluid + Alluxio を Lustre の分散アクセラレーションとして使用します. Alluxio は、クラスターの計算をより高速化し、基盤となるストレージへの圧力を軽減できます. ただし、ストレージ システムからクライアント側のキャッシュを直接実行する可能性を探っています。これにより、操作がユーザーにとってより透過的になります。
JuiceFS が 2021 年に初めてオープンソース化されたとき、私たちはその機能に関する調査を行いました。
まず、製品の特徴: JuiceFS は POSIX インターフェースをサポートし、HostPath の形式でマウントできます. この方法は、NAS を使用する方法とまったく同じであり、ユーザーは基本的に使用時に変更を加える必要はありません. JuiceFS メタデータとオブジェクトstorage には、Redis や TiKV などの多くの代替手段があり、AI の分野により適しています。基礎となる Ceph、MinIO、および一部のパブリック クラウド オブジェクト ストレージのユーザーは、自分で選択できます。
第二に、上位層のスケジューリング: JuiceFS は HostPath をサポートするだけでなく、CSI ドライブ モードもサポートします。これにより、ユーザーは、よりクラウドネイティブな方法で対応するストレージにアクセスできます。
第三に、ビジネス フレームワークの適応: POSIX インターフェースをディープ ラーニング フレームワークに適応させます。第四に、運用と保守: メタデータ エンジンとオブジェクト ストレージは業界で比較的成熟しており、多くの選択肢があり、JuiceFS には自動メタデータ バックアップとごみ箱機能があります。JuiceFS はビジネスに適しているため、POC テストを実施しました。
テスト環境は上図の通りですが、JuiceFSと比較すると、JuiceFSはカーネルページキャッシュを直接利用しており、Lustreが直接機械ディスクにアクセスした場合と比較すると、パフォーマンスが大幅に向上していることがわかります（下図のように、小さいほど良い）。
POC テストの後、JuiceFS を本番環境に導入することにしました。現在、Atlas クラスター全体のすべての GPU コンピューティング ノード、およびすべての開発ノードとデバッグ ノードに JuiceFS クライアントがインストールされています。
JuiceFS は redis クラスターと ceph に直接接続し、ほとんどのコンピューティング ノードは HostPath を使用してアクセスします。同時に、JuiceFS CSI ドライバーも Atlas クラスターにデプロイされ、ユーザーはクラウドネイティブな方法でアクセスできます。
Atlas での JuiceFS の使用方法
データのセキュリティを確保するために、スーパーコンピューティング プラットフォーム上の各グループは異なるディレクトリに属し、各ディレクトリはそれぞれのグループまたは部門のメンバーであり、異なるグループ間のディレクトリは非表示になっています。
ディレクトリのアクセス許可は、Linux のアクセス許可制御メカニズムに基づいています。ユーザーが Atlas クラスターでトレーニング タスクを送信すると、クラスターのタスク送信ツールがシステム上のユーザーの UID と GID 情報を自動的に読み取り、それをユーザーが送信したタスク Pod の SecurityContext フィールドに挿入し、次にコンテナーAtlas クラスターで実行されている Pod は、すべてのコンテナーの実行中のプロセスの UID がストレージ システムの情報と一致し、権限が境界を越えないようにします。
ノードは JuiceFS にアクセスして、マルチレベル キャッシングを実装します。
-
最初のレベル: キャッシュはメモリのページ キャッシュです。
-
レベル 2: すべてのコンピューティング ノード上の複数の SSD は、レベル 2 の高速化機能を提供します。
-
第 3 レベル: Ceph を使用します。それでも 3 つの 1t SSD がユーザー データをサポートできない場合は、Ceph から読み取られます。
2021 年の初めに、Unisound と JuiceFS チームは JuiceFSRuntime を Fluid に統合します。キャッシュがベアメタルで使われているため、キャッシュの可視性がユーザーにとって良くないことがわかりました.システムは自動的にキャッシュをクリーンアップし、ユーザーの制御性はあまり高くありません.そこでJuiceFSを統合しました.流体に。
Fluid は、FUSE や Worker Pod などの JuiceFS 関連のコンポーネントを起動します。そのうち、FUSE Pod は JuiceFS クライアントのキャッシュ機能を提供し、Worker Pod はキャッシュのライフ サイクルの管理を実現します. Atlas プラットフォームの AI オフライン トレーニング タスクは、FUSE Pod クライアントとやり取りして AI トレーニング データを読み取ります。 .
Fluid が提供するキャッシュ スケジューリング機能とデータ セットの可観測性により、プラットフォームのユーザーは、アフィニティ スケジューリングによって特定のコンピューティング ノードにキャッシュを展開できます。同時に、ユーザーはキャッシュの使用状況 (キャッシュされたデータなど) を直感的に確認できます。セット) サイズ、キャッシュのパーセンテージ、キャッシュの容量など)。
JuiceFS の構築実習
現在、Atlas はパブリック ネットワークにアクセスできず、専用の隔離されたネットワーク内にあるため、すべてのデプロイはプライベート化されています。
実稼働環境のメタデータ エンジンは Redis を使用しています. 2020 年には、TiKV と JuiceFS 間の接続はあまり成熟していません. 最初に移行に Redis を使用し、オブジェクト ストレージに Ceph を使用する予定です. Redis ノードのシステム ディスクは RAID1 で構成され、Redis の永続データは定期的に別のバックアップ ノードに同期されます。Redis データの永続化には、AOF + RDB ソリューションを使用して毎秒データを永続化します。
オブジェクトストレージは自作のCephクラスターを使用しており、CephクラスターはCephadmを使用してデプロイされており、現在の本番環境はOctopusバージョンを使用しています。当時、私たちは業界から多くのソリューションを借りて、メモリ レベルでメモリを最適化し、ソフトウェア レベルで対応する調整を行いました。主に次のとおりです。
サーバーレベル (参照) : • 42 コア 256GB 24 18T HDD • システムディスク: 2 960G SAS SSD • BlueStore • NUMA を無効にします • カーネルをアップグレードします: 5.4.146 io_uring を有効にします • カーネル pid max、/proc/sys/kernel/pid_max を変更します
Ceph 設定: • Ceph RADOS: librados インターフェースを直接呼び出します。S3 プロトコルは使用しません。 • バケット シャード • pg の自動調整機能を無効にします。 : block.wal = 100:1:1、後者2つはSSDまたはNVMe SSDを推奨) • 3部
パフォーマンスが大幅に向上するように、Ceph クラスターのカーネルを新しいバージョンにアップグレードしてから、io_uring 関数を有効にする必要があることに注意してください。ソフトウェア面では、S3 プロトコルを使用する代わりに rados インターフェースを直接呼び出すため、効率がわずかに高くなります.すべてのノードは 100G InfiniBand 高速ネットワークで相互接続されています.
Yunzhisheng 環境で JuiceFS に接続されているオブジェクト ストレージは Ceph RADOS です. JuiceFS は librados を使用して Ceph と対話するため、JuiceFS クライアントを再コンパイルする必要があります. librados のバージョンは Ceph のバージョンに対応することをお勧めします. これに注意してください.点。CSI Driver を使用すると PV/PVC の作成時に読み込まれますが、バージョン対応に/etc/ceph/ceph.confも。
完璧な監視システム
リンク全体が比較的長くなりました. 最下層にはメタデータ エンジン クラスタ, Ceph オブジェクト ストレージ クラスタ, 上位層のクライアントとサービスがあります. 各層には対応する監視ソリューションが必要です.
クライアントノードについては、主にログを収集しますが、各マウントポイントのJuiceFSクライアントログを集約する必要があり、ログがシステムディスクを爆破したり、ノードに書き込みができなくなったりするのを防ぐために、エラーアラームが必要であることに注意してください。
各 JuiceFS クライアントには、各マウント ポイントの .stat ファイルとログ監視インジケーターが正常かどうかを確認し、Redis と Ceph クラスターの IO とログを確認して、リンク全体が制御可能であることを確認するなど、対応する監視方法も必要です。 、この方法で問題を特定する方が便利です。
上記の画像は Ceph の監視画像です。クライアント ノードは SSD キャッシュを使用しており、現在は基本的にデータは Ceph に読み込まれておらず、ほとんどのデータはキャッシュから読み取られているため、Ceph のトラフィックは大きくありません。
上の写真は、JuiceFS モニタリングによってインターセプトされたデータです.ノードの 100% から 90% がヒットできることがわかります.キャッシュ ヒット率はまだ比較的高く、ほとんどのデータはまだキャッシュにあります.
JuiceFS コミュニティ構築に参加する
UniSound は、JuiceFS Community Edition を使用する過程でコミュニティの構築に積極的に参加しています。2021 年には、JuiceData チームと協力して、前述の Fluid JuiceFS ランタイムを開発しました。最近、コミュニティ バージョンのディレクトリ ベースのクォータがまだ開発されていないことが判明したため、数か月前に、ディレクトリ内のファイル数とファイル サイズを制限するバージョンを開発しました.PR が提出され、現在、JuiceFS コミュニティと協力してマージ作業を行っています。
Atlas での JuiceFS の使用シナリオと利点
JuiceFS クライアントのマルチレベル キャッシュは、現在、主にテキスト認識、スピーチ ノイズ リダクション、およびスピーチ認識のシナリオで使用されています。AI モデル トレーニングのデータ読み取りは、読み取りが多く、書き込みが少ないという特徴があるため、JuiceFS クライアントのキャッシュを最大限に活用して、IO 読み取りの高速化の利点をもたらします。
メリット 1: AI モデルのトレーニングを加速する
1) 音声ノイズ低減テスト
分散ファイルは、ノイズ削減シーン モデルのテストで使用されます. 各データは wav 形式で、100k 未満の小さな音声ファイルです. ノイズ削減シーンでは、データ ロード段階で I/O データをテストし、 JuiceFS クライアント ノードのメモリ キャッシュは 512G で、テストは 500h スケールのデータでバッチ サイズ 40 で実行されます。
テスト結果から、データの読み込み効率だけでも小さなwavファイルでみると、JuiceFSは6.45 it/sに対し、Lustreは5.15 it/sと25%性能が向上しています。JuiceFS は、エンド ツー エンドのモデル トレーニングを効果的に加速し、全体的なモデル出力時間を短縮しました。
2) テキスト認識シーン
テキスト認識シナリオでは、モデルは CRNN バックボーンと MobileNet v2 であり、テスト環境は次のとおりです。
LMDB の大きなデータ ファイルが生成されますが、このとき、IO には小さなファイルのパフォーマンス要件ではなく、比較的高い帯域幅要件があります。200G メモリ キャッシュはデータ全体をサポートできるため、基盤となるストレージを使用する代わりに、クライアントから直接読み取ることができ、全体的なパフォーマンスも大幅に改善されました。
このテストでは、主に JuiceFS と Lustre の速度比較が行われ、実験結果によると、Lustre からの各バッチの読み取りには 1.5 秒、JuiceFS からの各バッチの読み取りには 1.1 秒かかり、36% の増加が見られました。モデルの収束時間の観点から、Lustre の 96 時間から JuiceFS の 86 時間に対して、JuiceFS を使用すると CRNN モデルの出力時間を 10 時間短縮できます。
モデルのデバッグとデータ処理
コードのデバッグを行う場合、複数のユーザーが 1 つのデバッグ マシンでモデル テストとコード トラバーサルを同時に実行します. その際、ほとんどのユーザーはいくつかのリモート IDE を使用し、デバッグ ノードに接続してから、独自の仮想環境を構築し、インストールします。事前に Lustre に多数のインストール パッケージを用意します。
それらのほとんどは数十 k または数百 k の小さなファイルであり、これらのパッケージをメモリにインポートする必要があります。以前 Lustre を使用していたときは、ユーザーが多すぎるため、必要なスループットが高くなりました. 同時に、小さなファイルのパフォーマンス要件は比較的高くなりました. 効果はあまり良くないことがわかりました. パッケージをインポートするときは、その結果、コードのデバッグが遅くなり、全体的な効率が比較的低くなります。
その後、JuiceFS クライアントのキャッシュを利用し、1 回目のコンパイルも比較的遅かったのですが、2 回目のコンパイルではすべてのデータがキャッシュに置かれていたため、速度と効率が向上し、コードのジャンプも速くなりました。ヒントのインポートも高速です。ユーザーテストの後、約 2~4 倍の速度増加があります。
エピローグ
光沢から JuiceFS へ
2017 年から 2021 年にかけて、Lustre を使用した場合も比較的安定しており、クラスタのストレージ容量が 50% 未満の場合、ソフトウェアの安定性は比較的高くなります。
ベテラン HPC 分野のストレージ システムとして、Lustre は世界最大のスーパーコンピューティング システムの多くを動かしており、実稼働環境での長年の経験を持っています。POSIX標準に準拠し、さまざまな高性能で低遅延のネットワークをサポートし、RDMAアクセスを許可するという利点があり、従来のHPC分野での高性能コンピューティングに適しており、ディープラーニングのインターフェースと互換性があります。すべてのビジネスでコードの変更を行う必要はありません。しかし、いくつかの欠点もあります。
まず、Lustre はクラウドネイティブの CSI ドライバーをサポートできません。
第 2 に、Lustre はすべて C 言語で記述されているため、運用および保守要員に対する要件が比較的高く、一部のバグはすぐに解決できない場合があり、コミュニティ全体はあまりオープンで活発ではありません。
JuiceFS には次のような機能があります。
まず、JuiceFS はクラウド ネイティブ分野の分散ストレージ システム製品であり、Kubernetes との統合を改善するための CSI ドライバーと Fluid を提供します。
Second, the deployment scheme of JuiceFS is比較的柔軟, and the metadata engine is very optional. ユーザーネットワークでオブジェクトストレージが許可されている場合は、パブリッククラウドのオブジェクトストレージに接続する方が実際には優れています.
第 3 に、ストレージ拡張の運用と保守が比較的簡単です。POSIX 標準と完全に互換性があり、ディープ ラーニングのアプリケーションをシームレスに移行できますが、バックエンド オブジェクト ストレージの特性により、JuiceFS はランダム書き込みで大きな遅延が発生します。
第 4 に、JuiceFS はローカル キャッシュとカーネル ページ キャッシュをサポートし、ホット データとコールド データの階層化と高速化を実現します。これは私たちがより重視するものであり、ビジネス シナリオには適していますが、ランダムな書き込みには適していません。コミュニティ版の分散キャッシュ機能はまだ利用できません。
その後の計画
• メタデータ エンジンのアップグレード、TiKV は 1 億を超えるファイル (最大 100 億のファイルをサポート可能) のシナリオに適しており、パフォーマンスとデータ セキュリティの要件が高く、現在、TiKV の内部テストを完了しており、積極的に取り組んでいます。コミュニティの進行状況をフォローアップするために、メタデータ エンジンは将来的に TiKV に移行されます。• ディレクトリ クォータの最適化. 現在、基本バージョンの機能は JuiceFS コミュニティ バージョンに統合されています. JuiceFS コミュニティとの議論も行われています. いくつかのシナリオでは、いくつかのパフォーマンスを最適化する必要があります. • いくつかの非ルート機能を実行したい. すべてのノードがすべてのデータにアクセスするためのルート権限を持っている. 権限が大きすぎる. 特定のノードでのみルート権限を開くことを望んでいる. • 最後に、UID または GID に基づく速度制限など、コミュニティに QoS ソリューションがあるかどうかを確認します。
お役に立てれば、私たちのプロジェクトJuicedata/JuiceFSに注目してください! (0ᴗ0✿)