私は現在、レプリケーション モードで Gluster 3.5 を使用した 2 ノード クラスターで遊んでいます。これは、実際の 3 ノード クラスタをサーバー ハードウェアに実装する前に、システムについてある程度理解するためです。
テスト用ハードウェアは決してハイエンドなものではありません。Intel Atom D2550 と Intel i5 がギガビット ポートのイーサネット クロスケーブルを介して接続されています。
Gluster ファイル システムには約 20,000 のほとんど小さなファイル (基本的には Debian インストール) があり、これは後で (別のハードウェアで) 処理する必要がある実際の使用状況と似ています。
一部の古いソフトウェアはブリック上で実行されるため、残念ながらこれらのファイルのほとんどを定期的にポーリングする必要があるため、ファイル統計をポーリングする際の遅延が要因になります。
簡単なテストを行いました (Gluster ノード自体にマウントされた GlusterFS):
# time find | wc -l
22174
real 0m18.542s
user 0m0.224s
sys 0m0.789s
私が知っていることから、GlusterFS はそれぞれの他のノードをポーリングする必要があるため、これはおそらく非常に遅いですstat。
ブリック ストレージ ディレクトリを直接ポーリングすると、2 回目の試行から開始して、0.16 秒の範囲のタイミングが得られます (予想どおり、おそらくすべてがキャッシュから読み取られます)。
ただし、残りのノードが1 つだけになるように他のノードをシャットダウンすると、かなり似たような結果が得られます。
# time find | wc -l
22174
real 0m16.445s
user 0m0.213s
sys 0m0.702s
それはどうしてですか？この場合、何が Gluster を遅くしているのでしょうか?
一般に、GlusterFS 冗長セットアップで読み取りレイテンシーを最小限に抑えるにはどうすればよいですか? ファイルシステムのディレクトリリストのポーリングが、クラッシュ後のリカバリ中に一時的に実際の状況より遅れても、ディレクトリリストのパフォーマンスが向上する場合は問題ありません..