У меня следующий объем глянца, подробности следующие
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
Я монтирую этот том на том же компьютере, что и nfs mount, и brick1 также находится на том же компьютере, а затем использую георепликацию для его зеркалирования на резервный сервер.
Как видно из моих настроек, я использую glusterfs для резервного копирования почти в реальном времени.
Мне просто нужен надежный способ резервного копирования моих данных на вторичный сервер, раньше я использовал rsync, но он начал занимать много памяти по мере увеличения числа файлов, поэтому мы переключились на gluster, когда мы пробовали репликацию в реальном времени, это снижало производительность сервера , поэтому в крайнем случае мы использовали ge-репликацию, одна проблема, с которой мы сталкиваемся прямо сейчас, - это чрезмерно высокое потребление процессором gluster, я задал этот вопрос списку рассылки gluster, но без обновлений.
Согласно http://community.gluster.org/q/running-client-server-on-the-same-set-of-nodes/ :
Довольно часто клиентские и серверные процессы запускаются на одном наборе узлов. Фактически, серверы GlusterFS будут монтировать том в качестве клиента для выполнения определенных операций. В целом это работает хорошо, но можно столкнуться с различными формами конфликтов между серверным и клиентским процессами.