ZFS + GlusterFS + NFSスタックがクライアントに誤ったファイルを返す(異常な動作)

ZFS + GlusterFS + NFSスタックがクライアントに誤ったファイルを返す(異常な動作)

複数のアプリケーションサーバーにファイルを提供するために、ミラー化されたZFSプールの上に複製されたGlusterFSボリュームの上にNFSサーバーを設定しました。

ZFS+GlusterFS+NFSクラスタアーキテクチャ

NFS共有に保存されているファイルを検索する2つのアプリケーションサーバーがあります。仕事量はほぼ似ています。一度書く/時々読む:ファイルはリポジトリに書き込まれ、ほとんど変更されず、時には要求を満たすために読み込まれます。

要求クライアントにデータを返す前に、アプリケーションはファイルSHA256ハッシュを計算し、それをデータベースに格納されているハッシュと比較します。

アプリケーションがファイルのフルパスを使用していても、ノードが完全に異なる(誤った)ファイルコンテンツを取得することがあります。たとえば、アプリケーションはファイルを要求し、/data/storage_archive/20220802/filenameファイルからデータを取得します/data/storage_archive/RANDOM_DATE_HERE/RANDOM_FILENAME

これが発生した場合(幸いにもこれまで数回)、アプリケーションサーバーにログインして追加の分析のために(正しい)パスからローカルリポジトリに(間違った)ファイルをコピーできますが、ファイルの内容はまだ間違っています。ファイル名に加えて、他のメタデータ(ファイルサイズ、ファイル作成日など)は正確であり、実際の(間違った)ファイルを反映しています。

そして間違ったこれは、完全で完全なファイル(ビットの破損やその他の破損なし)を意味します。たとえば、PDFファイルではなく完全なXMLファイルです。

同じNFS共有にマウントされている別のアプリケーションサーバーから同じファイルにアクセスしようとすると、正しいファイルが得られます。

私が作成したレイヤーを見てみましょう。

  • 両方のGlusterFSノードにあるファイルのSHA256が正しいことを確認してください。
  • ZFSデータセットのマウントポイントにあるファイルのSHA256が正しいことを確認してください。

クライアントから NFS 共有をアンマウントして再マウントすると、状況が再び正常に戻ることがあります。

チェーンのどこかでキャッシュ破損が発生したようですが、どこにあるのかわかりません。 NFS? GlusterFS?ゼブス?関連するレイヤーを考えると、ZFSは間違ったデータに最初に応答できるプレーヤーなので、主犯のように見えますが、同時にほぼ防弾レイヤーである必要があります。エラーが発生したときに実行中の集中的なタスク(バックアップ、rsync、大規模ディレクトリナビゲーションなど)がありませんでした。

以下で、ZFS および GlusterFS 構成の詳細を確認できます。

 pool: testdata
 state: ONLINE
  scan: scrub repaired 0B in 19h4m with 0 errors on Sun Jul 10 19:28:54 2022
 config:

        NAME                                   STATE     READ WRITE CKSUM
        testdata                               ONLINE       0     0     0
          mirror-0                             ONLINE       0     0     0
            ata-ST16000NM001G-2KK103_ZL2JSCGA  ONLINE       0     0     0
            ata-ST16000NM001G-2KK103_ZL2JS4SB  ONLINE       0     0     0

errors: No known data errors

Gluster ボリューム情報の例:

gluster volume info test_volume

Volume Name: test_volume
Type: Replicate
Volume ID: 2ca11c4a-442f-4887-b65f-f02a34b14b03
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: gluster01-10gbe:/data/testdata/test_volume/data
Brick2: gluster02-10gbe:/data/testdata/test_volume/data
Options Reconfigured:
server.event-threads: 2
performance.parallel-readdir: on
performance.readdir-ahead: off
network.inode-lru-limit: 50000
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet
storage.fips-mode-rchecksum: on
cluster.granular-entry-heal: on
cluster.enable-shared-storage: enable

GlusterFS がクラスターにマウントされました。

gluster01-10gbe:/test_volume /mnt/testdata/test_volume/data/ glusterfs defaults 0 0

クラスタからNFSをエクスポートする:

/mnt/testdata/test_volume/data/    10.1.1.2(rw,fsid=1,sync,no_subtree_check,no_root_squash) 10.1.1.3(rw,fsid=1,sync,no_subtree_check,no_root_squash)

アプリケーションサーバーへのNFSマウント:

10.1.1.1:/mnt/testdata/test_volume/data/        /data  nfs     proto=udp,nfsvers=3,rsize=8192,wsize=8192,timeo=14,intr,soft  0   0

機密情報の漏洩リスクを防ぐため、IPアドレス、ボリューム名、プール名などを置き換えました。

ストレージサーバーに関するいくつかの詳細:

  • HP ProLiant DL380e Gen8には以下が含まれます。
  • デュアルインテル(R)Xeon(R)CPU E5-2450L @ 1.80GHz
  • 64GBメモリ
  • Dell Perc H200(ITモード)
  • 10GbEネットワーク
  • Ubuntu 18.04.6 LTS
  • LinuxのOpenZFS 0.7.5-1ubuntu16.12

ベストアンサー1

おすすめ記事