ByteFUSE 分散ファイルシステムの進化と実装

元のリンク: ByteFUSE 分散ファイルシステムの進化と実装

はじめに: ByteFUSE は ByteNAS チームと STE チームによって共同開発されたプロジェクトであり、その高い信頼性、優れたパフォーマンス、Posix セマンティクスとの互換性、および豊富な使用シナリオのサポートにより、企業で広く使用されています。現在、オンライン事業ES、AIトレーニング事業、システムディスク事業、データベースバックアップ事業、メッセージキュー事業、シンボルテーブル事業、コンパイル事業等を手掛けており、Byteの社内導入マシンとデイリーマウントポイントは10,000規模に達しており、総スループットはほぼ 100 GB/秒、容量は 10 PB 以上で、そのパフォーマンスと安定性はビジネスニーズを満たすことができます。

背景

ByteNAS は、完全に自社開発された、高性能、高スケーラビリティ、マルチ書き込み、マルチ読み取り、低遅延の分散ファイルシステムで、Posix セマンティクスと完全に互換性があり、現在 Byte の内部 AI トレーニング、データベースバックアップ、オンラインをサポートしています。 ESなど、将来的にはクラウド上でのNASが主な製品形態となるのも主要なビジネスだ。初期の ByteNAS は、NFS プロトコルを使用して外部サービスを提供しました。TTGW 4 層ロードバランサを利用して、TCP 接続の粒度で複数の接続されたプロキシへの外部トラフィックのバランスをとりました。ユーザーは、TTGW が提供する VIP を使用して、それを複数のプロキシと通信し、そのうちの 1 つのプロキシが通信します。現在通信中のプロキシがマシンのダウンタイムなどによりハングアップした場合、TTGW の内部検出ハートビートタイムアウトがフェイルオーバーメカニズムをトリガーし、クライアントからのリクエストを新しい稼働中のプロキシに自動的にリダイレクトします。このメカニズムはクライアントに対して完全に透過的です。ただし、TTGW の使用には次のような欠点があります。

大スループットのシナリオをサポートできない: ユーザーのスループットは、TTGW クラスター自体のスループットによって制限されるだけでなく、NFS プロトコルの 1 MB の単一読み取りおよび書き込み制限によっても制限されます。さらに、NFS は単一の TCP 接続であり、カーネルスロットの同時リクエストも制限されているため、スループットが制限され、メタデータとデータ間の相互影響が生じます。
追加のネットワーク遅延: ユーザーが ByteNAS にアクセスするためにさらに 2 つのネットワークホップ (ユーザー側 NFS クライアント -> TTGW -> プロキシ -> ByteNAS)
追加のマシンコスト: TTGW やプロキシなどのマシンリソースが必要です
ビジネス要件のカスタマイズとパフォーマンスの最適化が困難: カーネル NFS クライアント、NFS プロトコル、TTGW の影響により制限され、要件のカスタマイズとパフォーマンスの最適化が困難

上記の問題を解決するために、ByteFUSE が登場しました。ByteFUSE は、ByteNAS に接続するためのユーザーモードファイルシステム (FUSE) フレームワークに基づくソリューションであり、ByteNAS SDK は ByteNAS クラスターに直接接続されており、低遅延の目標を達成するだけでなく、プロトコルスループットの制限の問題も解決します。また、ファイルシステムの一部が論理的にユーザーモードに移行されるため、トラブルシューティング、機能拡張、パフォーマンスの最適化に非常に便利です。ByteFUSE および NFS プロトコルを使用して ByteNAS にアクセスするユーザーのフローを次の図に示します。

目標

高性能、低遅延、ビジネス向けの建築モデル設計
Posix セマンティクスと完全に互換性があります
ライトワンスリードメニー/ライトメニーリードをサポート
自己開発および保守可能で、カスタマイズされた機能サポートを提供します

進化ルート

1. ByteFUSE 1.0 — 完全な基本機能、クラウドネイティブ展開のサポート

ネイティブ FUSE 経由で ByteNAS にアクセス

ネイティブ FUSE ドッキング ByteNAS の全体的なアーキテクチャ図は次のとおりです。

ByteFUSE デーモン: FUSE デーモンは ByteNAS SDK と統合されており、ユーザーのファイルシステムリクエストは FUSE プロトコルを通じて ByteFUSE デーモンに転送され、その後 ByteNAS SDK を通じてバックエンドストレージクラスターに転送されます。

クラウドネイティブの導入サポート

ByteFUSE は、K8S クラスタで ByteNAS クラスタにアクセスするための ByteFUSE の使用をサポートするために、K8S CSI インターフェイス仕様 [1] に基づいて CSI プラグインを開発しました。そのアーキテクチャは次の図に示されています。

CSI-Driver: ByteFUSE のクラウドネイティブアーキテクチャは現在、静的ボリュームのみをサポートしています。マウント/アンマウント操作により、CSI-Driver 内の FUSE クライアントが開始/破棄されます。CSI-Driver は各マウントポイントのステータスを記録します。CSI-Drvier が異常終了した場合再起動すると、高可用性を確保するためにすべてのマウントポイントが回復されます。
FUSE クライアント: 前述の ByteFUSE デーモンです。1.0 アーキテクチャでは、マウントポイントごとに、CSI ドライバーが FUSE クライアントを起動してサービスを提供します。

2. ByteFUSE 2.0 — クラウドネイティブアーキテクチャのアップグレード、一貫性、可用性、操作性の向上

ビジネスのニーズと課題

FUSE クライアントのリソース占有は制御できず、再利用できません。マルチ FUSE クライアントモードでは、マウントポイントは FUSE クライアントプロセスに対応し、FUSE クライアントのリソース占有はマウントポイントの数に強く関係しているため、リソース占有が行われます。 FUSE クライアントの制御不能。
FUSE クライアントと CSI ドライバー間の強力な結合により、CSI ドライバーのスムーズなアップグレードが妨げられます。FUSE クライアントプロセスのライフサイクルは CSI ドライバーに関連付けられています。CSI をアップグレードする必要がある場合、FUSE クライアントもまた、再構築する必要があるため、ビジネス I/O にも影響が生じますが、同時に、この影響期間は CSI ドライバーのアップグレード期間 (秒) に強く関連しています。
一部の企業は、Kata コンテナシナリオで ByteFUSE にアクセスすることを希望しています: クラウドネイティブシナリオでは、一部の企業は Kata コンテナの形式で実行されます。ByteFUSE にアクセスするこれらの企業のニーズを満たすために、CSI-Driver はKata のコンテナランタイム、つまり、Kata 仮想マシンの ByteFUSE を介して ByteNAS サービスにアクセスできます。
ネイティブ FUSE 整合性モデルは一部のビジネス要件を満たすことができません: 一部のビジネスは、読み取りおよび書き込みのスループット、データの可視性、およびテール遅延に対して非常に高い要件を必要とする、典型的な 1 回だけ読み取りのシナリオです。ただし、ネイティブ FUSE カーネルキャッシュが有効な場合、CTO (Close-to-Open) のような一貫性モデルを提供できません。
ネイティブ FUSE のユーザビリティ/操作性が弱く、大規模な本番環境には適用できない: ネイティブ FUSE は高可用性、ホットアップグレードなどの機能のサポートが弱い FUSE プロセスのクラッシュやカーネルのバグが発生した場合多くの場合、Pod を再起動するか、さらには物理ノード全体を再起動するように企業に通知する必要がありますが、これはほとんどの企業にとって受け入れられません。

クラウドネイティブアーキテクチャのアップグレード

FUSE クライアントアーキテクチャのアップグレード: 単一のデーモン化

上記のビジネスニーズと課題に応えて、私たちはアーキテクチャをアップグレードし、制御不能なリソースと再利用できないリソースの問題を解決するために単一の FUSE デーモンモードをサポートし、CSI の問題を解決するために FUSE デーモンと CSI ドライバーの分離を採用しました。 -ドライバーをスムーズにアップグレードできない問題。そのアーキテクチャを次の図に示します。

AdminServer: マウントポイント/FUSE デーモンのステータスを監視し、FUSE デーモンをアップグレードし、クラスター情報を収集します。

FUSE デーモン: ByteNAS クラスターのすべてのマウントポイントを管理し、読み取りおよび書き込みリクエストを処理し、再起動後にすべてのマウントポイントを回復します。回復時間はミリ秒レベルです。

Kata コンテナーのシーンのサポート

Kata シナリオのサポートを提供し、同時にネイティブ FUSE の高可用性とパフォーマンススケーラビリティの問題を解決するために、ByteFUSE デーモンを実装するために Byte が独自に開発した技術フレームワークである VDUSE[2] を 2.0 アーキテクチャに導入しました。VDUSE は、virtio の成熟したソフトウェアフレームワークを利用し、ByteFUSE Daemon が仮想マシンまたはホストマシン (コンテナ) からのマウントを同時にサポートできるようにします。同時に、従来の FUSE フレームワークと比較して、VDUSE に基づいて実装された FUSE デーモンは /dev/fuse キャラクターデバイスに依存せず、共有メモリメカニズムを通じてカーネルと通信するため、この方法は後続のシステムに大きなメリットをもたらします。パフォーマンスの最適化を実現する一方で、クラッシュリカバリの問題も非常にうまく解決します。

一貫性、可用性、操作性の向上

一貫性モデルの強化

パフォーマンスと一貫性は分散システム設計における根本的な矛盾です。一貫性を維持すると通信するノードが増えることを意味し、通信するノードが増えるとパフォーマンスが低下することを意味します。関連するビジネスニーズを満たすために、FUSE ネイティブキャッシュモードに基づいてパフォーマンスと一貫性を継続的にトレードオフし、FUSE CTO (Close-to-Open) 一貫性モデル [4] を実装しました。次の 5 つのタイプに抽象化されます。

デーモンの高可用性

ByteFUSE 2.0 アーキテクチャは VDUSE [2] の技術フレームワークを導入しているため、トランスポート層として共有メモリに基づく Virtio プロトコルの使用をサポートしています。Virtio プロトコルの組み込みのインフライト I/O 追跡機能により、リクエストを永続化できます。リアルタイムで ByteFUSE によって処理され、ByteFUSE は再開時に未処理のリクエストを再処理します。これにより、キャラクターデバイス /dev/fuse をネイティブ libfuse のトランスポート層として使用する場合の状態保存の欠如が補われます。ByteFUSE は、インフライト I/O トラッキング機能に基づいて、リカバリ前後のファイルシステム状態の一貫性と冪等性をさらに考慮し、ユーザーが意識することなくクラッシュリカバリを実現し [3]、クラッシュリカバリに基づいた Daeamon のホットアップグレードを実現します。

カーネルモジュールのホットアップグレード

ByteFUSE はカスタマイズされたカーネルモジュールを使用してパフォーマンス、可用性、一貫性を向上させますが、これらのカスタマイズされたカーネルモジュールのアップグレードとメンテナンスにも課題があります。バイナリカーネルモジュールをカーネルでアップグレードできない問題を解決するために、DKMS を介してカスタマイズされたカーネルモジュールを展開し、カーネルアップグレードでカーネルモジュールが自動的に再コンパイルされ、展開されるようにします。カーネルモジュール自体のホットアップグレードの問題を解決するために、カーネルモジュールがエクスポートしたシンボル名やデバイス番号をバージョン番号にバインドすることで、同一カーネルモジュールの複数バージョンの共存を実現します。新しい ByteFUSE マウントは新しいカーネルモジュールを自動的に使用し、古い ByteFUSE マウントは引き続き古いカーネルモジュールを使用します。

現在、上記の DKMS 技術と「マルチバージョン共存」技術により、ByteFUSE カーネルモジュールのアップグレードをカーネルと ByteFUSE デーモンから分離していますが、将来的には、ByteFUSE カーネルモジュールのホットアップグレード機能をさらに実現する予定です。 ByteFUSE カーネルモジュールは、既存の ByteFUSE ボリュームのオンライン実行ホットアップグレード機能をサポートします。

3. ByteFUSE 3.0 — 極端なパフォーマンスの最適化により、業界をリードする高性能ファイルストレージシステムを構築

ビジネスのニーズと課題

大規模モデルのトレーニングシナリオにおけるストレージシステムのパフォーマンス要件

大規模なモデルのトレーニングシナリオでは、膨大な数のモデルのトレーニングに膨大なコンピューティング能力が必要ですが、データセットとモデルのサイズが大きくなるにつれて、アプリケーションがデータを読み込むのにかかる時間が長くなり、アプリケーションのパフォーマンスに影響します。 I/O が遅くなると、GPU の強力なコンピューティング能力が著しく妨げられます。同時に、モデルの評価と展開では多数のモデルを並行して読み取る必要があり、超高スループットを提供するストレージが必要になります。

クラウドネイティブの高密度導入シナリオでは、リソース占有のオーバーヘッドをさらに削減する必要があります

クラウドネイティブの高密度導入シナリオでは、ByteFUSE ボリュームの桁違いの増加に伴い、リソース (CPU およびメモリ) の占有と ByteFUSE 単一マシン側の分離に対する新しい要件が提示されます。

究極のパフォーマンスの最適化

ByteFUSE 3.0 は、スレッドモデル、データコピー、カーネル側、プロトコルスタックからリンク全体のパフォーマンスを最適化し、パフォーマンスが 2.5 倍向上し、100 Gb ネットワークカード全体に 2 コアを使用できます。その最適化の方向性は次のとおりです。

実行から完了までのスレッドモデル

バージョン 2.0 の読み取り/書き込みリクエストには 4 つのスレッドスイッチがあり、Run-to-Completion (RTC) にアクセスすると、これら 4 つのスレッドスイッチによって生じるオーバーヘッドを節約できます。Run-to-Completion を実現するために、ByteFUSE および ByteNAS SDK のシェアードナッシング設計とロックのノンブロッキング変換を実行しました。その目的は、RTC スレッドがブロックされず、リクエストに影響を与える遅延を回避することです。

RDMA およびユーザーモードプロトコルスタック

2.0 と比較して、3.0 アーキテクチャではネットワーク伝送も大幅に改善されており、主に従来のカーネル TCP/IP プロトコルスタックに代わる RDMA およびユーザーモードプロトコルスタック (Tarzan) の導入に反映されています。 RDMA/Tarzan スタックを使用すると、ユーザーモードとカーネルモード間の切り替えとデータコピーによって生じる遅延を節約でき、CPU 使用率をさらに削減できます。

フルリンクのゼロコピー

RDMA/Tarzan の導入後、ネットワーク送信における ByteFUSE のコピーは完全に排除されましたが、FUSE のアクセスでは、ページキャッシュからバウンスバッファへ、およびバウンスバッファから RDMA/Tarzan DMA バッファへの 2 つのコピーが依然として存在します。コピーオーバーヘッドのこの部分を削減するために (統計によると、1M データのコピーには約 100us が消費されます)、3.0 アーキテクチャでは VDUSE umem [5] 機能が導入されています。この機能は、RDMA/Tarzan DMA バッファを登録することでコピーを 1 つ削減します。 VDUSE カーネルモジュール。将来的には、フルリンクゼロコピーという最適化目標を達成するために、FUSE PageCache Extension 機能をさらに実装する予定です。

FUSE カーネルの最適化

(1) 複数のキュー

ネイティブ FUSE/viritofs カーネルモジュールには、FUSE リクエストの処理パス用の単一キュー設計が多数あります。たとえば、各 FUSE マウントには IQ (入力キュー)、BGQ (バックグラウンドキュー)、および virtiofs デバイスが 1 つだけあります。シングルキューモデルを使用して FUSE リクエストを送信します。単一キューモデルによって引き起こされるロックの競合を軽減し、スケーラビリティを向上させるために、CPU ごとの FUSE リクエストキューと、FUSE/virtiofs リクエストパス内の構成可能な数の virtiofs virtqueue をサポートします。FUSE のマルチキュー機能のサポートに基づいて、ByteFUSE は、さまざまな導入環境に応じてさまざまな CPU アフィニティポリシーを設定して、コア間通信を削減したり、コア間の負荷のバランスをとることができます。ByteFUSE ワーカースレッドは、FUSE マルチキュー機能によって提供されるロードバランシングスケジューリングを有効にして、不均一なコア間リクエストの場合のローカルリクエストキューイング現象を軽減することもできます。

(2) 巨大ブロック対応

高スループットシナリオのパフォーマンス要件を満たすために、ByteFUSE バージョン 3.0 は、カスタマイズされた FUSE カーネルモジュールパラメータをサポートしています。Linux カーネルのネイティブ FUSE モジュールには、1 MB の単一最大データ転送単位や 4 KB の単一最大ディレクトリツリー読み取り単位など、いくつかのハードコーディングされたデータ転送があります。ByteFUSE カーネルモジュールでは、単一の最大データ転送を 8 MB に増加し、単一の最大ディレクトリ読み取り単位を 32 KB に増加します。データベースのバックアップシナリオでは、1 回のライトダウンが 8MB に変更されると、1 台のマシンのスループットが約 20% 向上します。

進化の恩恵

特典の概要

1.0 -> 2.0

リソース占有を減らし、リソース制御を容易にする

単一の FUSE デーモンと複数の FUSE クライアントと比較して、スレッド、メモリ、複数のマウントポイント間の接続などのリソースを再利用できるため、リソースの使用量を効果的に削減できます。さらに、FUSE Daemon を Pod 内で単独で実行すると、Kubernetes エコシステムへの適応が向上し、Kubernetes の制御下にあることが保証され、ユーザーはクラスター内の FUSE Daemon の Pod を直接観察できるため、可観測性が高くなります。

CSI ドライバーと FUSE デーモンの分離

CSI-Driver と FUSE Daemon は、2 つの独立して導入されたサービスとして、相互に影響を与えることなく個別に導入およびアップグレードできるため、運用および保守作業がビジネスに与える影響をさらに軽減できます。さらに、POD での FUSE デーモンのホットアップグレードをサポートしており、アップグレード全体はビジネスに無関係です。

カーネルモジュールのホットアップグレードをサポート

ByteFUSE 増分ボリュームのホットアップグレードをサポートし、カーネルモジュールの既知のバグを修正し、ビジネスの意識を持たずにオンラインリスクを軽減できます。

統合された監視および制御プラットフォームをサポートし、視覚的な管理を容易にします。

AdminServer は、リージョン内のすべての FUSE デーモンとマウントポイントのステータスを監視し、異常なマウントポイントのリモート復元をサポートし、ポッド内の FUSE デーモンのホットアップグレードをサポートし、リモートマウントポイントの異常検出とアラームをサポートします。

2.0 -> 3.0

アーキテクチャ全体で Run-to-Complete スレッドモデルが実装されており、ロックやコンテキストの切り替えによって生じるパフォーマンスの損失が軽減されます。さらに、カーネルモード TCP をユーザーモード TCP に置き換え、カーネルをバイパスし、メモリをカーネルに登録してフルリンクゼロコピーを実現し、パフォーマンスをさらに向上させました。1MB の書き込みリクエストの場合、FUSE デーモン側は数百のコストを節約できます。

性能比較

FUSE デーモンマシンの仕様:

CPU: 32 物理コア、64 論理コア
メモリ: 251.27GB
NIC: 100Gbps

メタデータのパフォーマンスの比較

パフォーマンステスト、テストコマンドには mdtest を使用します

mdtest '-d' '/mnt/mdtest/' '-b' '6' '-I' '8' '-z' '4' '-i' '30

、パフォーマンスの違いは次のとおりです。

結論は

3.0 アーキテクチャのメタデータパフォーマンスは、1.0 アーキテクチャよりも約 25% 高くなります。

データパフォーマンスの比較

FIO は 4 つのスレッドを使用し、そのパフォーマンスを次の図に示します。

さらに、ByteFUSE 3.0 ポーリングスレッドの数がパフォーマンスに与える影響をテストします。書き込みの場合、基本的に 2 つのポーリングスレッドで 100G ネットワークカードがいっぱいになりますが、読み取りの場合は 4 つのポーリングスレッドが必要です (書き込み操作よりも 1 つ多いデータコピー)。将来的には、ユーザーモードプロトコルスタック Tarzan を変換して、読み取り用のデータコピーを保存し、ゼロコピーの読み取りと書き込みを実現する予定です。

ビジネスランディング

ES ストレージとコンピューティングの分離アーキテクチャシナリオの実装

シーンの説明

ES の共有ストレージアーキテクチャでは、ES の複数のシャードコピーが同じデータを使用して、Shared Nothing アーキテクチャでの拡張の遅さ、シャードの移行の遅さ、検索スコアの変動、ストレージコストの高さといった問題を解決できます。基盤となるストレージは ByteNAS を使用してプライマリシャードとセカンダリシャードのデータを共有し、アクセスプロトコルとして ByteFUSE を使用して、高性能、高スループット、低遅延の要件を満たします。

所得

ES ストレージとコンピューティングの分離アーキテクチャの実装により、年間 1,000 万近くのストレージコストが節約されます。

AIトレーニングシーンの上陸

シーンの説明

AI Web IDE シナリオでブロックストレージ + NFS を使用してルートファイルシステムを共有しても、NFS 切断プロセスが D 状態になり、NFS 切断がカーネルバグを引き起こすためにマウント機能が利用できない問題を解決できません。さらに、AI トレーニングシナリオにおける限られたロードバランシングのスループットと NFS プロトコルパフォーマンスの影響では、トレーニングタスクの高スループットと低レイテンシの要件を満たすことができません。一方、ByteNAS は、共有ファイルシステム、大スループット、低レイテンシを提供してモデルトレーニングに対応します。。

所得

AI トレーニングの高スループットと低遅延の要件を満たす

その他のビジネスシナリオの実装

TTGW のスループットと安定性による制限により、データベースバックアップビジネス、メッセージキュービジネス、シンボルテーブルビジネス、およびコンパイルビジネスが NFS から ByteFUSE に切り替えられました。

今後の展望

ByteFUSE 3.0 アーキテクチャはすでにほとんどのビジネスのニーズを満たすことができますが、より究極のパフォーマンスを追求し、より多くのビジネスシナリオに対応するには、今後もやるべきことがまだたくさんあります。

ByteFUSE は ToB シナリオにも拡張され、クラウド上のビジネスの超低遅延と超高スループットのニーズに対応します。
非 Posix セマンティクスをサポートし、カスタマイズされたインターフェースは IO フェンシングセマンティクスなどの上位層アプリケーションのニーズを満たします。
FUSE PageCache 拡張機能。FUSE はページキャッシュユーザーモード拡張機能をサポートし、FUSE デーモンはページキャッシュを直接読み書きできます。
カーネルモジュールのホットアップグレードをサポートし、ユーザーが意識することなくストックおよび増分 ByteFUSE ボリュームのカーネルモジュールのアップグレードをサポートします。
GPU ダイレクトストレージ [6] をサポート。データはホストメモリと CPU を介さず、RDMA ネットワークカードと GPU の間で直接送信されます。

参考文献

[1] https://kubernetes-csi.github.io/docs/

[2] https://www.redhat.com/en/blog/introducing-vduse-software-define-datapath-virtio

[3] https://juejin.cn/post/7171280231238467592

[4] https://lore.kernel.org/lkml/[email protected]/

[5] https://lwn.net/Articles/900178/

[6] https://docs.nvidia.com/gpudirect-storage/overview-guide/index.html

人気の求人

ByteDance STE チームは、皆様の参加を心より歓迎いたします。当チームは以前から募集を行っております北京、上海、深圳、杭州、アメリカ、イギリスにポジションがあります最近の募集情報は以下の通りです興味のある方はポスターのQRコードを直接スキャンして応募してください履歴書、お会いできるのを楽しみにしています、星の海へ行きましょう！ご不明な点がございましたら、アシスタントの WeChat sys_tech にご相談ください。ポジションはたくさんあります。ぜひ履歴書を叩きに来てください!