クラウドネイティブの高性能分散ファイルシステムであるJuiceFSは本当に興味深い

JuiceFS は、Apache 2.0 オープン ソース プロトコルに基づいてリリースされた、クラウド ネイティブ向けに設計された高性能分散ファイル システムです。完全な POSIX 互換性を提供し、ほぼすべてのオブジェクト ストレージをローカル コンピューターに接続して、大規模なローカル ディスクとして使用できます。また、プラットフォームやリージョンをまたいで、異なるホストに同時にマウントして読み取りや書き込みを行うこともできます。

導入

JuiceFS は、ファイル システムの分散設計を実現するために、「データ」と「メタデータ」のストレージを分離するアーキテクチャを採用しています。ファイルデータ自体はセグメント化されてオブジェクトストレージ（Amazon S3など）に保存されますが、メタデータはRedis、MySQL、TiKV、SQLiteなどの複数のデータベースに保存できます。シナリオやパフォーマンス要件に応じて選択できます。

JuiceFS は、さまざまな形式のデータの管理、分析、アーカイブ、バックアップに適した豊富な API セットを提供します。コードを変更することなく、ビッグデータ、機械学習、人工知能などのアプリケーション プラットフォームにシームレスに接続し、大規模で弾力性があり、低コストで高性能なストレージを提供します。運用・保守担当者は、可用性、災害復旧、監視、容量拡張などを気にする必要がなくなり、ビジネス開発に集中して研究開発の効率を向上させることができます。同時に、運用と保守の詳細の簡素化は DevOps に非常に適しています。

コア機能

• POSIX 互換性: ローカル ファイル システムのように使用し、既存のアプリケーションとシームレスに統合し、ビジネスに干渉しません。
• HDFS 互換性: HDFS API と完全に互換性があり、より強力なメタデータ パフォーマンスを提供します。
• S3 互換性: S3 プロトコルと互換性のあるアクセス インターフェイスを実装するための S3 ゲートウェイを提供します。
• クラウド ネイティブ: Kubernetes CSI ドライバーを介して Kubernetes で JuiceFS を簡単に使用できます。
• 分散設計: 同じファイル システムを数千台のサーバーに同時にマウントでき、高性能な同時読み取りと書き込み、およびデータの共有が可能です。
• 強力な一貫性: 確認されたファイルの変更はすべてのサーバー上ですぐに表示され、強力な一貫性が確保されます。
• 強力なパフォーマンス: ミリ秒単位のレイテンシ、ほぼ無制限のスループット (オブジェクト ストレージのサイズによって異なります)、パフォーマンス テストの結果を参照してください。
• データ セキュリティ: 転送中の暗号化と保存中の暗号化をサポートします。詳細をご覧ください。
• ファイルロック: BSD ロック (flock) と POSIX ロック (fcntl) をサポートします。
• データ圧縮: ストレージスペースを節約するために、LZ4 および Zstandard 圧縮アルゴリズムをサポートします。

アプリケーションシナリオ

JuiceFS は大規模なデータ ストレージ用に設計されており、特に次のシナリオでは、多くの分散ファイル システムやネットワーク ファイル システムの代わりとして使用できます。

• ビッグデータ分析: HDFS 互換;主流のコンピューティング エンジン (Spark、Presto、Hive など) とのシームレスな統合。無制限のストレージスペース。運用・保守コストがほぼゼロオブジェクト ストレージに直接接続するよりもはるかに優れたパフォーマンスを実現します。
• 機械学習: POSIX 互換で、すべての機械学習およびディープラーニング フレームワークをサポートできます。便利なファイル共有により、チーム管理とデータ使用効率も向上します。
• Kubernetes: JuiceFS は Kubernetes CSI をサポートします。コンテナに分離されたファイルストレージを提供し、アプリケーション サービスをステートレスにします。コンテナ間のデータ共有を容易にします。
• 共有ワークスペース: 任意のホストにマウントできます。クライアントの同時読み取りおよび書き込み制限はありません。既存のデータ ストリームおよびスクリプト操作と POSIX 互換です。
• データバックアップ：無限にスムーズに拡張できるストレージスペースにさまざまなデータをバックアップします。共有マウント機能と組み合わせることで、複数のホストからのデータを 1 か所に集約し、統合されたバックアップを実現できます。

データプライバシー

JuiceFS はオープンソース ソフトウェアであり、完全なソース コードは GitHub で見つかります。 JuiceFS を使用してデータを保存する場合、データは特定のルールに従ってデータ ブロックに分割され、定義したオブジェクト ストレージまたはその他のストレージ メディアに保存され、データに対応するメタデータは定義したデータベースに保存されます。

建築

JuiceFS 全体は主に 3 つの部分で構成されています。

建築

• クライアント: すべてのファイルの読み取りと書き込み、およびフラグメントの結合やごみ箱内の期限切れファイルの削除などのバックグラウンド タスクは、クライアントで実行されます。したがって、クライアントはオブジェクト ストレージとメタデータ エンジンの両方と対話する必要があります。クライアントは複数のアクセス方法をサポートしています:

• FUSE を使用すると、JuiceFS ファイル システムを POSIX 互換の方法でサーバーにマウントできるため、大規模なクラウド ストレージをローカル ストレージとして直接使用できるようになります。
• Hadoop Java SDK を通じて、JuiceFS ファイル システムは HDFS を直接置き換え、Hadoop に低コストの大規模ストレージを提供できます。
• Kubernetes CSI ドライバーを通じて、JuiceFS ファイル システムは Kubernetes に大規模なストレージを直接提供できます。
• S3 ゲートウェイを介して、S3 をストレージ層として使用するアプリケーションに直接アクセスできるほか、AWS CLI、s3cmd、MinIO クライアントなどのツールを使用して JuiceFS ファイル システムにアクセスすることもできます。
• WebDAV サービスを通じて、JuiceFS にアクセスし、HTTP プロトコルを使用して RESTful API のような方法で JuiceFS 内のファイルを直接操作できます。

• データ ストレージ: ファイルはセグメント化され、オブジェクト ストレージ サービスにアップロードされます。パブリック クラウド オブジェクト ストレージを使用することも、プライベートに展開された独自構築のオブジェクト ストレージに接続することもできます。 JuiceFS は、OpenStack Swift、Ceph、MinIO などのプライベート オブジェクト ストレージだけでなく、ほぼすべてのパブリック クラウド オブジェクト ストレージもサポートしています。
• メタデータ エンジン: 次のファイル メタデータを保存するために使用されます。

• 通常のファイル システムのメタデータ: ファイル名、ファイル サイズ、権限情報、作成および変更時刻、ディレクトリ構造、ファイル属性、シンボリック リンク、ファイル ロックなど。

• JuiceFS 固有のメタデータ: ファイル チャンクとスライスのマッピング、クライアント セッションなど。

JuiceFS はマルチエンジン設計を採用しており、現在メタデータ サービス エンジンとして Redis、TiKV、MySQL/MariaDB、PostgreSQL、SQLite などをサポートしており、徐々にさらに多くのメタデータ ストレージ エンジンを実装する予定です。

JuiceFSがファイルを保存する方法

データと対応するメタデータを保存するためにローカル ディスクのみを使用できる従来のファイル システムとは異なり、JuiceFS はデータをフォーマットしてオブジェクト ストレージに保存し、ファイルのメタデータを専用のメタデータ サービスに保存します。このアーキテクチャにより、JuiceFS は一貫性が高く、高性能な分散ファイルシステムになります。

JuiceFS に保存されるファイルは、1 つ以上の「チャンク」(最大 64 MiB) に分割されます。各チャンクは 1 つ以上の「スライス」で構成されます。チャンクはファイルをセグメント化して大きなファイルのパフォーマンスを最適化するために存在し、スライスはさまざまなファイル書き込み操作をさらに最適化するために存在します。どちらもファイル システム内の論理的な概念です。スライスの長さは固定されておらず、ファイルの書き込み方法によって異なります。各スライスはさらに「ブロック」に分割され (デフォルトのサイズ制限は 4 MiB)、これが最終的にオブジェクト ストレージにアップロードされる最小のストレージ ユニットになります。

JuiceFS ファイル

したがって、オブジェクト ストレージ プラットフォームのファイル ブラウザーでは、JuiceFS に保存されているソース ファイルを見つけることができません。バケット内には、チャンク ディレクトリと、番号が付けられた一連のディレクトリとファイルのみがあります。これらは、JuiceFS によって分割され、保存されるデータ ブロックです。同時に、ファイルとチャンク、スライス、ブロックの対応関係などのメタデータ情報がメタデータ エンジンに保存されます。この分離設計により、JuiceFS ファイルシステムは高いパフォーマンスで動作できるようになります。

JuiceFS メタデータ

JuiceFS のストレージ設計には、次の技術的特徴もあります。

• JuiceFS は、パフォーマンスを考慮し、読み取り増幅を回避するために、保存時に任意のサイズのファイルをマージしません。
• 強力な一貫性保証を提供しますが、シナリオのニーズに応じてキャッシュ機能と一緒に調整することもできます。たとえば、より積極的なメタデータ キャッシュを設定すると、パフォーマンスを向上させる代わりに、ある程度の一貫性が犠牲になる可能性があります。 。
• 「ごみ箱」機能はサポートされており、デフォルトで有効になっています。ファイルを削除した後、誤ってファイルを削除することで発生する事故を最小限に抑えるために、ファイルは完全にクリーンアップされるまで一定期間保持されます。

インストール

JuiceFS は Go 言語で開発されているため、優れたクロスプラットフォーム機能を備えており、Linux、macOS、Windows などを含むほぼすべての主流のオペレーティング システムでの実行をサポートしています。

JuiceFS クライアントにはバイナリ ファイルが 1 つだけあります。プリコンパイル済みバージョンをダウンロードして直接解凍したり、ソースコードを使用して手動でコンパイルしたり、ワンクリックインストールスクリプト curl -sSL https://d.juicefs.com/install | を使用したりできます。 sh - JuiceFS クライアントの最新バージョンを自動的にダウンロードしてインストールします。

Mac で使用する場合は、macOS がデフォルトで FUSE インターフェースをサポートしていないため、まず macOS 用の FUSE をインストールする必要があります。

 ➜ juicefs --version juicefs version 1.0.4+2023-04-06.f1c475d

スタンドアロンモード

JuiceFS ファイル システムは、「オブジェクト ストレージ」と「データベース」によって駆動されます。オブジェクト ストレージに加えて、基盤となるストレージとしてローカル ディスク、WebDAV、HDFS の使用もサポートします。ここでは、まずローカル ディスクと SQLite データベースを使用してスタンドアロン ファイル システムをすばやく作成し、JuiceFS を理解して体験します。

もちろん、最初に JuiceFS クライアントをインストールする必要があります。その後、juicefs format コマンドを使用して JuiceFS ファイル システムを作成できます。コマンドの形式は次のとおりです。

 juicefs format [command options] META-URL NAME

コマンドから、ファイル システムをフォーマットするには次の 3 種類の情報が必要であることがわかります。

• [コマンド オプション]: ファイル システムのストレージ メディアを設定します。空白のままにすると、デフォルトでローカル ディスクがストレージ メディアとして使用されます。パスは $HOME/.juicefs/local、/var/jfs、または C:/jfs/local です。
• META-URL: メタデータ ストレージ、つまりデータベース関連の情報 (通常はデータベースの URL またはファイル パス) を設定するために使用されます。
• NAME: ファイル システムの名前です。

たとえば、ydzsfs という名前のファイル システムを作成する場合は、次のコマンドを使用できます。

 ➜ juicefs format sqlite3://ydzsfs.db ydzsfs 2023/04/25 15:36:44.287211 juicefs[218656] <INFO>: Meta address: sqlite3://ydzsfs.db [interface.go:401] 2023/04/25 15:36:44.288042 juicefs[218656] <INFO>: Data use file:///home/ubuntu/.juicefs/local/ydzsfs/ [format.go:434] 2023/04/25 15:36:44.400391 juicefs[218656] <INFO>: Volume is formatted as { "Name": "ydzsfs", "UUID": "67a050b2-9a40-4852-882c-24c092c03b4a", "Storage": "file", "Bucket": "/home/ubuntu/.juicefs/local/", "BlockSize": 4096, "Compression": "none", "TrashDays": 1, "MetaVersion": 1 } [format.go:471]

返された情報から、ファイル システムがメタデータ ストレージ エンジンとして SQLite を使用していることがわかります。データベース ファイルは現在のディレクトリにあり、ydzsfs.db という名前が付けられています。 ydzsfs ファイル システムのすべての情報を保存します。完全なテーブル構造を構築し、すべてのデータのメタデータを保存するために使用されます。

SQLite

ストレージ関連のオプションが指定されていないため、クライアントはデフォルトでローカル ディスクをストレージ メディアとして使用します。返された情報によると、ydzsfs のストレージ パスは file:///home/ubuntu/.juicefs/local/ydzsfs/ であり、これは現在のユーザーのホーム ディレクトリ内の .juicefs/local/ydzsfs/ です。

 ➜ ls -la ~/.juicefs/local/ydzsfs total 12 drwxr-xr-x 2 ubuntu ubuntu 4096 Apr 25 15:36 . drwxr-xr-x 3 ubuntu ubuntu 4096 Apr 25 15:36 .. -rw-r--r-- 1 ubuntu ubuntu 36 Apr 25 15:36 juicefs_uuid

これでファイルシステムが正常に作成されました。次に、juicefs mount コマンドを使用してファイル システムをマウントします。コマンドの一般的な形式は次のとおりです。

 juicefs mount [command options] META-URL MOUNTPOINT

ファイル システムを作成するコマンドと同様に、ファイル システムをマウントするには次の情報が必要です。

• [コマンド オプション]: ファイル システム関連のオプションを指定するために使用されます。たとえば、-d はバックグラウンド マウントを実現します。
• META-URL: メタデータ ストレージ、つまりデータベース関連の情報 (通常はデータベースの URL またはファイル パス) を設定するために使用されます。
• MOUNTPOINT: ファイル システムのマウント ポイントを指定します。

SQLite は単一ファイル データベースであるため、マウントするときにデータベース ファイルのパスに注意する必要があります。 JuiceFS は相対パスと絶対パスの両方をサポートします。たとえば、次のコマンドを使用して、ydzsfs ファイル システムを ./jfs フォルダーにマウントできます。

 ➜ juicefs mount sqlite3://ydzsfs.db ./jfs 2023/04/25 15:39:52.365555 juicefs[220965] <INFO>: Meta address: sqlite3://ydzsfs.db [interface.go:401] 2023/04/25 15:39:52.366833 juicefs[220965] <INFO>: Data use file:///home/ubuntu/.juicefs/local/ydzsfs/ [mount.go:431] 2023/04/25 15:39:52.367117 juicefs[220965] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/67a050b2-9a40-4852-882c-24c092c03b4a/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94] 2023/04/25 15:39:52.378120 juicefs[220965] <INFO>: Create session 1 OK with version: 1.0.4+2023-04-06.f1c475d [base.go:289] 2023/04/25 15:39:52.378749 juicefs[220965] <INFO>: Prometheus metrics listening on 127.0.0.1:9567 [mount.go:161] 2023/04/25 15:39:52.378819 juicefs[220965] <INFO>: Mounting volume ydzsfs at ./jfs ... [mount_unix.go:181] 2023/04/25 15:39:52.378851 juicefs[220965] <WARNING>: setpriority: permission denied [fuse.go:427] 2023/04/25 15:39:52.868233 juicefs[220965] <INFO>: OK, ydzsfs is ready at ./jfs [mount_unix.go:45]

デフォルトでは、クライアントはファイル システムをフォアグラウンドでマウントし、プログラムは常に現在のターミナル プロセスで実行されます。ファイル システムをアンマウントするには、Ctrl + C キーの組み合わせを使用するか、ターミナル ウィンドウを閉じます。

ファイルシステムをバックグラウンドでマウントしたままにするには、マウント時に -d または --background オプションを指定します。これにより、クライアントはデーモンプロセスでファイルシステムをマウントするように指示されます。

 ➜ juicefs mount sqlite3://ydzsfs.db ~/jfs -d 2023/04/25 15:41:15.438132 juicefs[222009] <INFO>: Meta address: sqlite3://ydzsfs.db [interface.go:401] 2023/04/25 15:41:15.439334 juicefs[222009] <INFO>: Data use file:///home/ubuntu/.juicefs/local/ydzsfs/ [mount.go:431] 2023/04/25 15:41:15.439513 juicefs[222009] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/67a050b2-9a40-4852-882c-24c092c03b4a/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94] 2023/04/25 15:41:15.941069 juicefs[222009] <INFO>: OK, ydzsfs is ready at /home/ubuntu/jfs [mount_unix.go:45]

次に、マウント ポイント ~/jfs に保存されているすべてのファイルは、JuiceFS ファイル保存形式に従って特定の「データ ブロック」に分割され、$HOME/.juicefs/local/ydzsfs ディレクトリに保存され、対応する「メタデータ」はすべて ydzsfs.db データベースに保存されます。

最後に、次のコマンドを実行してマウント ポイント ~/jfs をアンマウントします。

 ➜ juicefs umount ~/jfs

もちろん、データのセキュリティを確保できる場合は、アンインストール コマンドに --force または -f パラメータを追加して、ファイル システムを強制的にアンインストールすることもできます。

オブジェクトストレージの使用

これまでの基本的な紹介を通じて、JuiceFS がどのように動作するかについての基本的な理解が得られます。次に、メタデータの保存には引き続き SQLite を使用しますが、より実用的なソリューションを作成するために、ローカル ストレージを「オブジェクト ストレージ」に置き換えます。

ほとんどすべての主流のクラウド コンピューティング プラットフォームは、Amazon S3、Alibaba Cloud OSS などのオブジェクト ストレージ サービスを提供しています。JuiceFS は、ほぼすべてのオブジェクト ストレージ サービスをサポートしています。一般的に、オブジェクト ストレージを作成するには、次の 2 つの手順だけが必要です。

• Bucket ストレージ バケットを作成し、エンドポイント アドレスを取得します。
• Object Storage API のアクセス キーであるアクセス キー ID とアクセス キー シークレットを作成します。

Tencent Cloud COS を例にとると、作成されるリソースはおおよそ次のようになります。

• バケットエンドポイント: https://myjfs-1304979731.cos.ap-shanghai.myqcloud.com。
• アクセスキーID :ABCDEFGHIJKLMNopqXYZ。
• アクセス キー シークレット: ZYXwvutsrqpoNMLkJiHgfeDCBA。

ここでは、Tencent Cloud COS サービスを例として説明します。まず、myjfs という名前のバケットを作成し、次に juicefs という名前のサブアカウントを作成し、次の図に示すように、そのサブアカウントの API キーを作成します。

 # 使用你自己所使用的对象存储信息替换下方相关参数➜ juicefs format --storage cos \ --bucket https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com \ --access-key xxxx \ --secret-key xxx \ sqlite3://myjfs.db myjfs 2023/04/25 15:56:18.198284 juicefs[233378] <INFO>: Meta address: sqlite3://myjfs.db [interface.go:401] 2023/04/25 15:56:18.198941 juicefs[233378] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [format.go:434] 2023/04/25 15:56:18.740526 juicefs[233378] <INFO>: Volume is formatted as { "Name": "myjfs", "UUID": "720c4b39-547e-43d8-8b22-02229f443194", "Storage": "cos", "Bucket": "https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com", "AccessKey": "xxxx", "SecretKey": "removed", "BlockSize": 4096, "Compression": "none", "KeyEncrypted": true, "TrashDays": 1, "MetaVersion": 1 } [format.go:471]

上記のコマンドでは、オブジェクト ストレージの関連する構成情報を指定します。

• --storage: cos、oss、s3 などのストレージ タイプを設定します。
• --bucket: オブジェクト ストレージのエンドポイント アドレスを設定します。
• --access-key: オブジェクト ストレージ API アクセス キーのアクセス キー ID を設定します。
• --secret-key: オブジェクト ストレージ API アクセス キーのアクセス キー シークレットを設定します。

作成が完了したら、マウントできます。

 ➜ juicefs mount sqlite3://myjfs.db ~/jfs -d 2023/04/25 16:01:40.718645 juicefs[237796] <INFO>: Meta address: sqlite3://myjfs.db [interface.go:401] 2023/04/25 16:01:40.719901 juicefs[237796] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [mount.go:431] 2023/04/25 16:01:40.720136 juicefs[237796] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/720c4b39-547e-43d8-8b22-02229f443194/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94] 2023/04/25 16:01:41.221218 juicefs[237796] <INFO>: OK, myjfs is ready at /home/ubuntu/jfs [mount_unix.go:45]

マウント コマンドは、ローカル ストレージを使用する場合とまったく同じです。これは、ファイル システムが作成されたときに、オブジェクト ストレージ関連の情報が myjfs.db データベースに書き込まれているためです。したがって、クライアントは追加のオブジェクト ストレージ認証情報を提供する必要がなく、ローカル構成ファイルもありません。

SQLite とオブジェクト ストレージの組み合わせは、ローカル ディスクを使用するよりも実用的です。アプリケーションの観点から見ると、この形式は、ほぼ無制限の容量を持つオブジェクト ストレージをローカル コンピューターに接続するのと同じであり、クラウド ストレージをローカル ディスクのように使用できるようになります。

さらに、ファイル システムのすべてのデータはクラウド オブジェクト ストレージに保存されるため、myjfs.db データベースは、JuiceFS クライアントがインストールされている他のコンピューターにコピーしてマウントし、読み取りと書き込みを行うことができます。つまり、メタデータを格納するデータベースを読み取ることができるコンピューターであれば、ファイル システムをマウントして読み書きすることができます。

たとえば、~/jfs ディレクトリの下に任意のファイルをいくつか作成します。

 ➜ echo "Hello JuiceFS" > hello.txt

通常の作成が完了すると、ファイルは JuiceFS ファイル ストレージ形式に従って特定の「データ ブロック」に分割され、オブジェクト ストレージにアップロードされます。対応する「メタデータ」はすべて myjfs.db データベースに保存されます。

オブジェクトストレージ

明らかに、SQLite のような単一ファイルのデータベースに複数のコンピューターが同時にアクセスするのは困難です。 SQLite を、ネットワーク経由で複数のコンピューターが同時に読み書きできる Redis、PostgreSQL、MySQL などのデータベースに変更すると、JuiceFS ファイル システムの分散マウントと読み書きが可能になります。

分散モード

以前、「オブジェクト ストレージ」と「SQLite」データベースを組み合わせて、任意のホストにマウントできるファイル システムを実装しました。オブジェクト ストレージはネットワーク上の許可された任意のコンピューターからアクセスできるため、ストレージにアクセスする任意のコンピューターに SQLite データベース ファイルをコピーするだけで、異なるコンピューターから同じ JuiceFS ファイル システムにアクセスできます。

もちろん、SQLite データベースをコンピュータ間でコピーしてファイル システムを共有することは可能ですが、ファイルのリアルタイム パフォーマンスは保証されません。 SQLite などの単一ファイル データベースは複数のコンピューターで同時に読み書きできないという制限があるため、分散環境でファイル システムをマウントし、複数のコンピューターで同時に読み書きできるようにするには、Redis、PostgreSQL、MySQL などのネットワーク アクセスをサポートするデータベースを使用する必要があります。

次に、SQLite データベースをネットワークベースのデータベースに置き換えて、JuiceFS ファイル システムの分散マウント、読み取り、書き込みを実現します。 JuiceFS で現在サポートされているネットワークベースのデータベースは次のとおりです。

• キーバリューデータベース: Redis、TiKV。
• リレーショナル データベース: PostgreSQL、MySQL、MariaDB。

データベースによってパフォーマンスと安定性が異なります。たとえば、Redis はパフォーマンスに優れていますが、信頼性は比較的弱いインメモリのキー値データベースです。 PostgreSQL はリレーショナル データベースです。パフォーマンスはインメモリ データベースほど強力ではありませんが、信頼性ははるかに強力です。

ここでは、分散モードの使用方法を説明するために、Redis を例に挙げます。次のことを説明するため、K8s クラスターにシンプルな Redis サービスを直接デプロイします。

 apiVersion: apps/v1 kind: Deployment metadata: name: redis spec: selector: matchLabels: app: redis template: metadata: labels: app: redis spec: containers: image: redis/redis-stack-server:6.2.6-v6 imagePullPolicy: IfNotPresent name: redis ports: - containerPort: 6379 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: redis spec: ports: - name: redis-port port: 6379 targetPort: 6379 selector: app: redis type: NodePort

次のリソース リストを適用するだけです。

 ➜ kubectl apply -f redis.yaml ➜ kubectl get svc redis -n kube-gpt NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE redis NodePort 10.103.134.144 <none> 6379:32199/TCP 19d

次に、以前のオブジェクト ストレージと Redis を使用して、次のコマンドで分散 JuiceFS ファイル システムを作成します。

 ➜ juicefs format --storage cos \ --bucket https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com \ --access-key xxxx \ --secret-key xxxx \ redis://10.103.134.144:6379/1 myjfs 2023/04/25 16:21:41.847487 juicefs[252491] <INFO>: Meta address: redis://10.103.134.144:6379/1 [interface.go:401] 2023/04/25 16:21:41.849176 juicefs[252491] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly. [info.go:83] 2023/04/25 16:21:41.849459 juicefs[252491] <INFO>: Ping redis: 217.108µs [redis.go:2904] 2023/04/25 16:21:41.850047 juicefs[252491] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [format.go:434] 2023/04/25 16:21:42.263986 juicefs[252491] <INFO>: Volume is formatted as { "Name": "myjfs", "UUID": "6fb832cc-06a1-4b18-b9fc-087dbf67a105", "Storage": "cos", "Bucket": "https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com", "AccessKey": "xxxxxxxx", "SecretKey": "removed", "BlockSize": 4096, "Compression": "none", "KeyEncrypted": true, "TrashDays": 1, "MetaVersion": 1 } [format.go:471]

ファイルシステムが作成されると、オブジェクトストレージキーを含む情報がすべてデータベースに記録されます。 JuiceFS クライアントはデータベース アドレス、ユーザー名、パスワード情報を持っている限り、ファイル システムをマウントして読み書きできるため、ローカル構成ファイルは必要ありません。

このファイル システムの「データ」と「メタデータ」は両方ともネットワーク ベースのサービスに保存されるため、JuiceFS クライアントがインストールされている任意のコンピューターに同時にファイル システムをマウントして、共有読み取りおよび書き込みを行うことができます。次に例を示します。

 ➜ juicefs mount redis://10.103.134.144:6379/1 ~/jfs -d 2023/04/25 16:25:40.254487 juicefs[255369] <INFO>: Meta address: redis://10.103.134.144:6379/1 [interface.go:401] 2023/04/25 16:25:40.255762 juicefs[255369] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly. [info.go:83] 2023/04/25 16:25:40.255971 juicefs[255369] <INFO>: Ping redis: 164.248µs [redis.go:2904] 2023/04/25 16:25:40.256553 juicefs[255369] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [mount.go:431] 2023/04/25 16:25:40.256743 juicefs[255369] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/6fb832cc-06a1-4b18-b9fc-087dbf67a105/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94] 2023/04/25 16:25:40.757806 juicefs[255369] <INFO>: OK, myjfs is ready at /home/ubuntu/jfs [mount_unix.go:45]

強力なデータ一貫性保証

複数のクライアントが同時に同じファイル システムをマウントし、読み取りと書き込みを行う状況では、JuiceFS は「クローズからオープン」までの一貫性保証を提供します。つまり、2 つ以上のクライアントが同時に同じファイルを読み書きする場合、クライアント A による変更はクライアント B にすぐには表示されない可能性があります。ただし、クライアント A でファイルが書き込まれて閉じられた後、その後どのクライアントでもファイルを再度開くと、同じノード上にあるかどうかに関係なく、最新の書き込みデータへのアクセスが保証されます。

パフォーマンスを向上させるためにキャッシュサイズを増やす

「オブジェクトストレージ」はネットワークベースのストレージサービスであるため、アクセスの遅延は避けられません。この問題を解決するために、JuiceFS はデフォルトでキャッシュ メカニズムを提供して有効にし、ローカル ストレージの一部をデータとオブジェクト ストレージ間のバッファー レイヤーとして割り当てます。ファイルを読み取るとき、データは非同期的にローカル ストレージにキャッシュされます。

キャッシュ メカニズムにより、JuiceFS は大量のデータの読み取りと書き込みを効率的に処理できます。デフォルトでは、JuiceFS は $HOME/.juicefs/cache または /var/jfsCache ディレクトリに 100GiB のキャッシュを設定します。より高速な SSD に大きなキャッシュ スペースを設定すると、JuiceFS の読み取りおよび書き込みパフォーマンスが効果的に向上します。

--cache-dir を使用してキャッシュ ディレクトリの場所を調整し、--cache-size を使用してキャッシュ領域のサイズを調整できます。次に例を示します。

 juicefs mount --background \ --cache-dir /mycache \ --cache-size 512000 \ redis://tom:mypassword@xxxx:6379/1 \ ~/jfs

注意: JuiceFS プロセスには、--cache-dir ディレクトリへの読み取りおよび書き込み権限が必要です。

上記のコマンドは、キャッシュ ディレクトリを /mycache に設定し、キャッシュ領域を 500 GiB に指定します。

ファイルシステムがマウントされたら、juicefs bench コマンドを使用してファイルシステムの基本的なパフォーマンス テストと機能検証を実行し、JuiceFS ファイルシステムに正常にアクセスでき、パフォーマンスが期待どおりであることを確認できます。

 ➜ juicefs bench ~/jfs Cleaning kernel cache, may ask for root privilege... Write big blocks count: 1024 / 1024 [==============================================================] done Read big blocks count: 1024 / 1024 [==============================================================] done Write small blocks count: 100 / 100 [==============================================================] done Read small blocks count: 100 / 100 [==============================================================] done Stat small files count: 100 / 100 [==============================================================] done Benchmark finished! BlockSize: 1 MiB, BigFileSize: 1024 MiB, SmallFileSize: 128 KiB, SmallFileCount: 100, NumThreads: 1 Time used: 16.4 s, CPU: 50.4%, Memory: 432.8 MiB +------------------+------------------+---------------+ | ITEM | VALUE | COST | +------------------+------------------+---------------+ | Write big file | 266.43 MiB/s | 3.84 s/file | | Read big file | 220.25 MiB/s | 4.65 s/file | | Write small file | 14.6 files/s | 68.50 ms/file | | Read small file | 1172.6 files/s | 0.85 ms/file | | Stat file | 4252.0 files/s | 0.24 ms/file | | FUSE operation | 17835 operations | 1.00 ms/op | | Update meta | 326 operations | 2.98 ms/op | | Put object | 356 operations | 214.20 ms/op | | Get object | 256 operations | 116.36 ms/op | | Delete object | 0 operations | 0.00 ms/op | | Write into cache | 356 operations | 2.94 ms/op | | Read from cache | 100 operations | 0.07 ms/op | +------------------+------------------+---------------+

juicefs bench コマンドを実行すると、指定された同時実行数 (デフォルトは 1) に従って、N 個の大きなファイル (デフォルトは 1) と N 個の小さなファイル (デフォルトは 100) を JuiceFS ファイル システムに書き込み、読み取り、単一操作の読み取りおよび書き込みスループットと待ち時間、およびメタデータ エンジンへのアクセスの待ち時間をカウントします。

テスト後、オブジェクト ストレージにアクセスして、さらに多くのデータを表示できます。

ジュースベンチ

実稼働環境の展開

JuiceFS ファイル システムが実稼働環境の要件を満たすようにするために、ここでは実稼働環境の展開に関する次の提案を示します。

1. モニタリング指標の収集と可視化

必ず JuiceFS クライアントから監視メトリックを収集し、Grafana を通じて視覚化してください。

2. 自動メタデータバックアップ

自動メタデータバックアップは、JuiceFS v1.0.0以降に追加された機能です。

メタデータは JuiceFS ファイル システムにとって重要です。一度紛失または破損すると、多数のファイルまたはファイルシステム全体に影響が及ぶ可能性があります。したがって、メタデータは定期的にバックアップする必要があります。

メタデータの自動バックアップ機能はデフォルトで有効になっており、バックアップ間隔は 1 時間です。バックアップされたメタデータは圧縮され、対応するオブジェクト ストレージ (ファイル システム データとは分離) に保存されます。バックアップは JuiceFS クライアントによって実行されるため、バックアップ中は CPU とメモリの使用量が増加します。デフォルトでは、バックアップ操作を実行するためにすべてのクライアントの中からランダムにクライアントが選択されると考えられます。

デフォルトでは、ファイルシステム内のファイル数が 100 万に達すると、自動メタデータ バックアップ機能が無効になり、再度有効にするには、より長いバックアップ間隔 (--backup-meta オプション) を構成する必要があることに注意してください。バックアップ間隔はクライアントごとに個別に設定されます。 --backup-meta 0 を設定すると、自動メタデータ バックアップ機能がオフになります。

注: メタデータのバックアップに必要な時間は、特定のメタデータ エンジンによって異なります。メタデータ エンジンによってパフォーマンスは異なります。

3. ごみ箱

ごみ箱はJuiceFS v1.0.0以降に追加された機能です。

ごみ箱はデフォルトで有効になっており、削除されたファイルの保存期間はデフォルトで 1 日に設定されているため、誤ってデータを削除することで生じるデータ損失のリスクを効果的に防ぐことができます。

ただし、ごみ箱を有効にすると、いくつかの副作用が生じる可能性もあります。アプリケーションが頻繁にファイルを削除したり、頻繁にファイルを上書きしたりする必要がある場合、オブジェクト ストレージの使用量はファイル システムの使用量よりもはるかに多くなります。これは基本的に、JuiceFS クライアントが、オブジェクト ストレージ上の削除されたファイル、または上書き時にガベージ コレクションを必要とするデータ ブロックを一定期間保持するためです。したがって、JuiceFS を実稼働環境に導入する場合は、適切なごみ箱の構成を考慮する必要があります。ごみ箱の保持期間は、次の方法で設定できます (--trash-days が 0 に設定されている場合、ごみ箱機能は無効になります)。

• 新しいファイル システム: juicefs 形式の --trash-days <value> オプションを使用して設定します。
• 既存のファイルシステム: juicefs config の --trash-days <value> オプションを使用して変更します。

4. クライアントのバックグラウンドタスク

同じ JuiceFS ファイル システムのすべてのクライアントは、操作中に設定されたバックグラウンド タスクを共有します。各タスクは固定の時間に実行され、実行する特定のクライアントはランダムに選択されます。具体的なバックグラウンド タスクは次のとおりです。

• 削除待ちのファイルやオブジェクトをクリーンアップする
• 期限切れのファイルや断片をごみ箱から削除する
• 長時間応答がないクライアントセッションをクリーンアップする
• メタデータを自動的にバックアップする

これらのタスクは実行時に一定のリソースを消費するため、業務量の多いクライアントがバックグラウンド タスクに参加しないように --no-bgjob オプションを設定できます。

注意: 少なくとも 1 つの JuiceFS クライアントがバックグラウンド タスクを実行できることを確認してください。

5. クライアントのログローリング

JuiceFS マウント ポイントをバックグラウンドで実行する場合、クライアントはデフォルトでログをローカル ファイルに出力します。ローカル ログ ファイルへのパスは、ファイル システムがマウントされているときに実行しているユーザーによって若干異なります。 root ユーザーのログ ファイル パスは /var/log/juicefs.log で、非 root ユーザーのログ ファイル パスは $HOME/.juicefs/juicefs.log です。

デフォルトでは、ローカル ログ ファイルはローテーションされません。実稼働環境では、ログ ファイルがディスク領域をあまり占有しないように手動で構成する必要があります。以下はログローリングの構成例です。

 # /etc/logrotate.d/juicefs /var/log/juicefs.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }

構成ファイルの正しさは、logrotate -d /etc/logrotate.d/juicefsコマンドを使用して検証できます。