web-dev-qa-db-ja.com

glusterボリュームをボリューム自体と同じマシンにマウントするのは良い考えですか？

私は以下のglusterボリュームを持っています、詳細は以下の通りです

Volume Name: geo-vol
Type: Distribute
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: bst:/backup
Options Reconfigured:
geo-replication.indexing: on

このボリュームをnfsmountと同じマシンにマウントしており、brick1も同じマシンにあり、ジオレプリケーションを使用してバックアップサーバーにミラーリングしています。

私のセットアップからわかるように、私はほぼリアルタイムのバックアップにglusterfsを使用しています。

データをセカンダリサーバーにバックアップするための信頼できる方法が必要です。以前はrsyncを使用していましたが、ファイル数が増えると大量のメモリを消費し始めたため、glusterに切り替えました。リアルタイムレプリケーションを試したところ、サーバーのパフォーマンスが低下していました。 、最後の手段としてge-replicationを使用しましたが、現在直面している問題の1つは、glusterのcpu消費量が非常に多いことです。この質問をglusterメーリングリストに送信しましたが、更新はありません。

linuxbackupglusterfs
5
vishy

http://community.gluster.org/q/running-client-server-on-the-same-set-of-nodes/ ：

クライアントとサーバーのプロセスを同じノードのセットで実行することはかなり一般的です。実際、GlusterFSサーバーは、特定の操作を実行するためにクライアントとしてボリュームをマウントします。一般に、これはうまく機能しますが、サーバープロセスとクライアントプロセスの間でさまざまな形式の競合が発生する可能性があります。

3
S19N