LizardFS-クラスターファイルシステムの簡単な概要

興味深いクラスターファイルシステム。 それほど大きくないプロジェクトの1つに実装しましたが、一般的なGlusterFSまたはNFSソリューションよりもうまく機能します。 クライアント側で接続するときにFUSEを使用します。 これは他のクラスターFSよりもうまくいくとは思いませんでしたが、実際にはすべてが非常にポジティブであることが判明しました。




UPD：

しばらくして、すでに平均的なプロジェクトにLizardFSを実装しました。実際、この記事の発行のほぼ直後に、更新記事を書く前に負荷を調べる時間が必要でした。

3か月後、マスターサーバーの再起動さえ行われました。FS自体とは無関係の理由で、利用できる最高のクラスターFSであり、多少複雑です。 バグではありません。データストレージとして機能するだけでなく、ほぼ毎分データが常に更新され、多数のファイルが上書きされるなど、問題なく平均データ量を保持します（この場合、1TBおよび大小のファイル）。

一般に、LizardFSまたはMooseFS（商用）は、少なくともペタバイトの情報用に設計されています。

自宅で使用する人には微妙な違いがあります。 このファイルシステムは、ファイルの行ごとの書き込みを目的としていません。つまり、ループから行をアンロードしてPHPからディスクに直接ファイルを書き込むと、各変更を常に同期しようとするため、明らかな理由でFSの速度が大幅に低下し始めます。

したがって、行ごとの記録を作成するには、単にtmpfsフォルダーをどこかにマウントし、このフォルダーでファイルを1行ずつ生成し、そこから完成したファイルのmvをクラスターFSに作成するか、インタープリターで直接RAMにデータの配列を作成し、一度にファイルにマージします。 つまり、アトミック操作、ファイルのコピー、ファイルの移動、ファイルの読み取りに最適ですが、最も重要なのはファイル全体の完成であり、問​​題はありません。 forおよびループの助けを借りてのみ、ファイルを1行ずつファイルに書き込む必要はありません。

フォルダ内のレプリカの数を設定する機能は素晴らしいです。

この記事には、cronにインストールするのに十分な単純な監視スクリプトマスターとシャドウサーバーウィザードを追加します。

#!/bin/bash #Variables SRV="172.24.1.1" #Every 15 minutes repeat alert if have troubles test -f /tmp/$SRV.lizardfs && find /tmp/$SRV.lizardfs -mmin +15 -delete #Check if no have previous alert flag file if [ ! -e /tmp/$SRV.lizardfs ]; then #Check command CHECK_LIZ=`lizardfs-probe metadataserver-status $SRV 9421 | grep "running\|connected" | awk '{print $3}' | sed '/^$/d' | tr -d ' '` #Send Alert if have troubles if [[ "$CHECK_LIZ" != "running" && "$CHECK_LIZ" != "connected" ]] ; then echo "$CHECK_LIZ" > /tmp/$SRV.lizardfs #Send Alert /home/scripts/telegram/telegram.sh --service "$SRV LizardFS" --event "Status: $CHECK_LIZ" ; /home/scripts/sms/msms.sh --service "$SRV LizardFS" --event "Status: $CHECK_LIZ" ; fi fi 

telegram.shおよびmsms.shスクリプトがスクリプトです。

元の記事：

LizardFSの利点：

小さなファイルを読み取るモードでの非常に高速な作業。 GlusterFSを使用した多くの人は、これらのサイトを返すためにクラスターFSを使用すると、操作が非常に遅くなるという問題に直面しました。

非常に良いレベルでの大きなファイルの読み取り速度。

大きなファイルの書き込み速度はネイティブファイルシステムと大差ありません。特に、クラスターの下部にSSDディスクがあり、クラスター内のサーバー間に1〜10ギガビットの接続がある場合はそうです。

Chown / ls -la操作はネイティブFSの場合よりも遅くなりますが、それほど遅くはありません
GlusterFSの場合のように。

再帰的な削除操作-非常に高速。

mfsmountユーティリティの非常に柔軟な接続オプション。

メタデータの複製は簡単かつ簡単に設定でき、複数のシャドウシャドウマスターサーバーとメタロガーサーバーを同時に使用できます。

メタデータはRAMに保存されます。

LizardFSがローカルサーバーからデータを取得することを好むのは素晴らしいことです。 2つのレプリカの例を使用して読み取りを高速化すると、LizardFSクライアントはローカルサーバーからファイルを自動的に取得し、2番目のサーバーからネットワークを介してファイルを取得しません。

サブフォルダーに目標（レプリカの数）を設定する機能、つまりLizardFS / var / lizardfs / importantに3つのレプリカを作成すること、および/ var / lizardfs / not_importantにレプリカなしで1つのFS内で設定することができます。 それはすべて、チャンクサーバーの数と必要なタスクの実行に依存し、チャンクサーバーごとに複数の個別のディスクを使用することもできます。

EC-Erasure Codingなど、さまざまなデータ複製モードをサポートしています。
このモードでの読み取り速度はそれほど大きくありません。

ファイルシステム自体をマウントするクライアントを除き、すべてがLXCコンテナーで機能します。 ホストマシンにマウントし、マウントポイントをLXCコンテナーに転送することで解決します。
練習できます。

新しいノードを追加するときの自動リバランス。
削除されたノードや不要なノードの非常に簡単な削除。

LizardFSの欠点：

小さなファイルの大きなストリームの書き込み速度は非常に遅いです。 Rsyncはそれをよく示しています。

FS上に多数のキャッシュファイルを生成するサイトエンジンの場合、
キャッシュはクラスターファイルシステムの外部に移動する必要があります。 これに問題があるエンジンの場合、マウントされたLizardFSのサブフォルダーの上にローカルフォルダーをマウントするか、シンボリックリンクを使用できます。

例：

 mount --bind /data/nativefs/cache /var/lizardfs/cache 

動作中のマスターメタデータサーバーは一度に1つしか動作できませんが、バックアップまたはシャドウモードのいくつかは並行して動作できます。 高可用性は、有料コンポーネントLizardFSの助け、およびそのスクリプト+ uCarp / keepalived / PaceMakerなどのソフトウェアの助けを借りて実装できます。 私たちの場合、これは必要ありません。手動制御で十分です。

残念なことに、GlusterFSの箱から出してすぐにできるように、すべては自動です。 長所と柔軟性が短所を上回っています。

RAMを少し要求します。 ただし、たとえば、データが約10〜20 GBでレプリカが2つしかない小規模プロジェクトでは、これは重要ではありません。

 root@172.24.1.1:/# df -h |grep "mfs\|Size" Filesystem Size Used Avail Use% Mounted on mfs#mfsmaster:9421 1.8T 41G 1.8T 3% /var/www ( 2- ) root@172.24.1.1:/# find /var/www -type f -print0 | wc -l --files0-from=- |grep total 185818 total ( ) root@172.24.1.1:/# smem -u -t -k |grep "mfs\|RSS" User Count Swap USS PSS RSS mfs 3 0 170.0M 170.9M 180.9M (3  - master/metalogger/chunkserver) 

平均的なプロジェクトでは、RAMの消費量を後で確認しますが、まだ実装していませんが、すでに準備が整っています。

セットアップ：

Debian 9でLizardFSをすばやく起動する方法に関する短いマニュアルを提供します。

Debian 9がインストールされた4つのサーバーがあり、デフォルトで8番目に既製のlizardfsパッケージが含まれていないとします。

制限を設定します。

/etc/security/limits.confに以下を配置する必要があります。

 * hard nofile 20000 * soft nofile 20000 

root、mfs / lizardfsユーザーに対して個別に登録できます。 すでに制限が解除されている場合、これは必須ではありません。 少なくとも10,000が必要です。

役割を配布します。

172.24.1.1（マスターメタデータ/チャンク）-マスターメタデータ/チャンクストレージ
172.24.1.2（シャドウメタデータ/チャンク）-シャドウマスターメタデータ/チャンクストレージ
172.24.1.3（メタロガー/チャンク）-メタデータのバックアップ/チャンクストレージ
172.24.1.4（メタロガー/チャンク）-メタデータバックアップ/チャンクストレージ

厳密に言えば、メタロガーはマスターとシャドウの両方で並行して動作できます。そこでは、より多くのリソースが安価になります。 これは、実際にはマスター/シャドウサーバーとまったく同じ、メタデータの遅延バックアップです。 また、メインサーバーでメタデータが破損した場合に備えて、メタロガーをマスターサーバーに変えることができます。

つまり、たとえば、このオプションも使用します。

172.24.1.1（マスターメタデータ/メタロガー/チャンク）
172.24.1.2（シャドウメタデータ/メタロガー/チャンク）

4台のサーバーのバージョンの記事をさらに続けます。

アイテム1〜3-4つのサーバーすべてで実行します。

1. LXCコンテナーがある場合、クライアントを除くすべてのサービスの完全なセットをすべてのサーバーにインストールします。 Debianで起動時に/ etc / default /でまだ無効になっているため、すべてのサービスをインストールします。メタロガーを突然マスターに変更する必要がある場合は、すべてが事前にインストールされています。

 apt-get -y install lizardfs-common lizardfs-master lizardfs-chunkserver lizardfs-metalogger lizardfs-client cp /etc/lizardfs/mfsmaster.cfg.dist /etc/lizardfs/mfsmaster.cfg cp /etc/lizardfs/mfsmetalogger.cfg.dist /etc/lizardfs/mfsmetalogger.cfg cp /etc/lizardfs/mfsgoals.cfg.dist /etc/lizardfs/mfsgoals.cfg cp /etc/lizardfs/mfschunkserver.cfg.dist /etc/lizardfs/mfschunkserver.cfg cp /etc/lizardfs/mfshdd.cfg.dist /etc/lizardfs/mfshdd.cfg 

または、Debianではネイティブパッケージで上記のオプションが指定されているため、ソースからインストールするかパッケージをコンパイルすると、ディレクトリが異なります。

 cp /etc/mfs/mfsmaster.cfg.dist /etc/mfs/mfsmaster.cfg cp /etc/mfs/mfsmetalogger.cfg.dist /etc/mfs/mfsmetalogger.cfg cp /etc/mfs/mfsgoals.cfg.dist /etc/mfs/mfsgoals.cfg cp /etc/mfs/mfschunkserver.cfg.dist /etc/mfs/mfschunkserver.cfg cp /etc/mfs/mfshdd.cfg.dist /etc/mfs/mfshdd.cfg 

パッケージによっては、ユーティリティの名前を含めて、mfs * / lizardfs <action>などのように変更することもできます。

マスターサーバーパッケージをインストールせず、メタロガーとチャンクサーバーのみをインストールする場合、デフォルトでは、ユーザーとグループのmfs / lizardfsは/ var / lib / mfsまたは/ var / lib / lizardfsフォルダーに設定されません。

2. LizardFSのデフォルトエントリを/ etc / hostsに追加します。

 echo "172.24.1.1 mfsmaster" >> /etc/hosts 

3.データを保存するためのフォルダーまたは個別のセクション、または少なくとも2つ以上のセクションを選択します。 各サーバーの現在のFSにあるフォルダーを1つだけ検討してください：/ data / lizardfs-chunk

 mkdir -p /var/www (    ) mkdir -p /data/lizardfs-chunk ( LizardFS      ) 

 echo "/data/lizardfs-chunk" > /etc/lizardfs/mfshdd.cfg echo "172.24.1.0/24 / rw,alldirs,maproot=0" > /etc/lizardfs/mfsexports.cfg 

または

 echo "/data/lizardfs-chunk" > /etc/mfs/mfshdd.cfg echo "172.24.1.0/24 . rw,alldirs,maproot=0" > /etc/mfs/mfsexports.cfg echo "172.24.1.0/24 / rw,alldirs,maproot=0" > /etc/mfs/mfsexports.cfg 

ルートの共有-これは、ネイティブFSシステムのルートではなく、LizardFS自体のスペース全体を意味します。

ポイントの共有-ファイルシステムをメタデータに接続することが可能であったことを意味します。 これは、削除されたファイルをクリーンアップするために必要です。 以下で検討します。

4.誰がマスターになり、誰がシャドウになるかを示します

172.24.1.1では、mfsmaster.cfg構成でPERSONALITY = masterを指定します
172.24.1.2では、mfsmaster.cfg構成でPERSONALITY = shadowを指定します

5.必要なサービスを含めます。

 172.24.1.1: echo "LIZARDFSMASTER_ENABLE=true" > /etc/default/lizardfs-master echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver systemctl start lizardfs-master systemctl start lizardfs-chunkserver 172.24.1.2: echo "LIZARDFSMASTER_ENABLE=true" > /etc/default/lizardfs-master echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver systemctl start lizardfs-master systemctl start lizardfs-chunkserver 172.24.1.3: echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver echo "LIZARDFSMETALOGGER_ENABLE=true" > /etc/default/lizardfs-metalogger systemctl start lizardfs-metalogger systemctl start lizardfs-chunkserver 172.24.1.4: echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver echo "LIZARDFSMETALOGGER_ENABLE=true" > /etc/default/lizardfs-metalogger systemctl start lizardfs-metalogger systemctl start lizardfs-chunkserver 

次に、クライアントによってマウントします。さまざまなオプションがあり、多くのオプションがあります。

chunkserver`ax上のFS：

ネイティブXFSがある場合は、-o mfssugidclearmode = XFSを追加します
BSDでコンパイルした場合は、-o mfssugidclearmode = BSDを追加します
MAC OSXでビルドした場合：）、-o mfssugidclearmode = OSXを追加する必要があります

クラスター内のチャンクサーバーの下に異なるFSを混在させることはお勧めできませんが、必要な場合は-o mfssugidclearmode = ALWAYSを使用する必要があります。

デフォルトは、btrfs、ext2、ext3、ext4、hfs [+]、jfs、ntfs、およびreiserfsのEXTです。
Linuxでチャンクサーバーにntfsを使用することを考えている人はいないと思います。

 mfsmount -o big_writes,nosuid,nodev,noatime,allow_other /var/www mfsmount -o big_writes,nosuid,nodev,noatime,allow_other -o cacheexpirationtime=500 -o readaheadmaxwindowsize=4096 /var/www 

サポートされるオプションは、LizardFSのバージョンによって異なります。2番目のバージョンでは、読み取り速度がはるかに高速です。 デフォルトでは、mfsmountは/ etc / hostsからIPマスターを取得しますが、すべてのチャンクサーバーに並行して接続します。 big_writesオプションは、新しいFUSEクライアントでは廃止されたと見なされ、デフォルトで有効になっています。古いシステムには指定することをお勧めします。

使用可能なレプリカオプションはmfsgoals.cfgに記述されています

次に、必要なデータレプリカの数を示します。

 mfssetgoal -r 2 /var/www mfsgetgoal /var/www 

それでは、/ var / wwwで使用を開始します

LizardFSバスケットのクリーニングに関するアドオン。 削除されたファイルはデフォルトで復元できますが、スペースを占有します。

私たちはどのマシンでもそれを行います。あなたは誰でもそれを行うことができます。

 mkdir /mnt/lizardfs-meta mfsmount /mnt/lizardfs-meta -o mfsmeta cd /mnt/lizardfs-meta/trash root@172.24.1.1:/mnt/lizardfs-meta/trash# root@172.24.1.1:/mnt/lizardfs-meta/trash# ls -la total 0 drwx------ 3 root root 0 Dec 2 09:36 . dr-xr-xr-x 4 root root 0 Dec 2 09:36 .. -rw-r--r-- 0 root root 0 Dec 2 09:38 00016C88|test.txt dw------- 2 root root 0 Dec 2 09:36 undel 

ファイルがごみ箱に入るデフォルトの時間は、削除後24時間です。

 root@172.24.1.1:/mnt/lizardfs-meta/trash# lizardfs rgettrashtime /var/www/ /var/www/: files with trashtime 86400 : 44220 directories with trashtime 86400 : 2266 

次のようにインスタント削除に変更できます。

 root@172.24.1.1:/mnt/lizardfs-meta/trash# lizardfs rsettrashtime 0 /var/www/ /var/www/: inodes with trashtime changed: 46486 inodes with trashtime not changed: 0 inodes with permission denied: 0 

最終的なファイルの削除：

 root@172.24.1.1:/mnt/lizardfs-meta/trash# find /mnt/lizardfs-meta/trash/ -type f -delete 

削除されたすべてのファイルを回復します。

 root@172.24.1.1:/mnt/lizardfs-meta/trash# find /mnt/lizardfs-meta/trash/ -type f -exec mv {} /mnt/lizardfs-meta/trash/undel/ \; 

デフォルトでは、ごみ箱からファイルを削除した後、実際のファイルはチャンクサーバーから非常にゆっくりと削除されます。 これを加速する方法はあまり明確ではありません。

したがって、バスケット管理はサブディレクトリで個別に実行でき、柔軟性が向上します。 たとえば、キャッシュディレクトリの場合は0を、誤って削除された他のディレクトリの場合は24時間以上置くことができます。

また、例を使用して特定のディレクトリまたはファイルを複製する際の柔軟性を強調します。

 root@172.24.1.1:/# mfssetgoal -r 1 /var/www/test/ /var/www/test/: inodes with goal changed: 1 inodes with goal not changed: 0 inodes with permission denied: 0 root@172.24.1.1:/# mfsgetgoal /var/www /var/www: 2 root@172.24.1.1:/# mfsgetgoal /var/www/test /var/www/test: 1 

つまり、ディレクトリとそのサブディレクトリのレプリカの数をディレクトリ上で直接指定できます。
する。 リバランスは自動的に行われます。 mfssetgoalユーティリティで使用可能なレプリカのタイプは、mfsgoals.cfgで指定されています

たとえば、1秒あたり1ギガバイトを超える同時記録が必要な場合、それは必要ありませんが、このFSでもグーグルで検索できるため、mfsgoals.cfgで消去コーディングを使用する目標を設定し、mfssetgoalを使用してこのタイプのレプリケーションを割り当てる必要があります目的のフォルダ。 このモードでは、クライアントのネットワークが10ギガビット以上であれば、クライアントは並行してデータを書き込みます。 サーバーは劣らないことになっています。

→ レプリケーションモードの詳細

重要：不必要にkillall -9 mfsmasterを実行しないでください。
これを行うことにより、少なくともRAMに残っているデータの一部を失い、少なくともメタデータファイルを破ることができます。mfsfilerepairユーティリティを使用して修復するか、メタルロガーから古いものに完全に置き換える必要があります。当然、データの一部は失われます。 ウィザードの設定に一部依存します。

ダンプからのサーバー上ではなくクラスターFSを実行する必要があるため、これを書き留めませんでした。 サーバーが非常用電源を備えていることがさらに望ましいです。

大規模なシステムでは、設定を有効にすることが重要な場合があります。

 root@172.24.1.1:/# cat /etc/mfs/mfschunkserver.cfg |grep -B3 FACTOR ## If enabled, chunkserver will send periodical reports of its I/O load to master, ## which will be taken into consideration when picking chunkservers for I/O operations. ## (Default : 0) # ENABLE_LOAD_FACTOR = 0 

複数のクライアントを並列および並列の書き込みおよび読み取りで接続するモードですばやく作業するには、これらのデフォルト設定を忘れないでください。

 root@172.24.1.1:/# cat /etc/mfs/mfschunkserver.cfg |grep WORKERS # NR_OF_NETWORK_WORKERS = 1 # NR_OF_HDD_WORKERS_PER_NETWORK_WORKER = 2 # NR_OF_NETWORK_WORKERS = 1 # NR_OF_HDD_WORKERS_PER_NETWORK_WORKER = 20 

そして、mfsmountのオプションについて：

 -o mfswritecachesize=<N> specify write cache size in MiB (in range: 16..2048 - default: 128) -o mfswriteworkers='N' define number of write workers (default: 10) -o mfswritewindowsize='N' define write window size (in blocks) for each chunk (default: 15) 

一般に、このクラスターFSについて十分に理解するには、最初の1日で十分でした。 はい、GlusterFSよりも少し複雑ですが、利点はそれを上回ります。 たくさんの小さなファイルをすばやく読むことは素晴らしいことです。

→ ドキュメント