Tenho o seguinte volume de brilho, os detalhes são os seguintes
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
Estou montando esse volume na mesma máquina que nfs mount e brick1 também está na mesma máquina e usando a replicação geográfica para espelhá-lo no servidor de backup.
Como você pode ver na minha configuração, estou usando o glusterfs para backup quase em tempo real.
Eu só preciso de maneira confiável para fazer backup dos meus dados no servidor secundário, antes eu estava usando o rsync mas ele começou a ter muita memória conforme os arquivos de números aumentavam, então mudamos para gluster, quando tentamos replicação em tempo real estava prejudicando o desempenho do servidor, por isso, em último recurso, fomos com ge-replicação, um problema que estamos enfrentando agora é o consumo de cpu de gluster é muito alto, eu fiz esta pergunta para gluster mailing list, mas sem atualização.
De acordo com o link :
It's fairly common to run client and server processes on the same set of nodes. In fact, GlusterFS servers will mount a volume as a client to perform certain operations. In general this works well, but it is possible to run into various forms of contention between the server and client processes.