If backupvolfile-server option is added while mounting fuse client, when the first volfile server fails, then the server specified in backupvolfile-server option is used as volfile server to mount the client.
É verdade que é possível montar um volume GlusterFS em qualquer bloco e o cliente FUSE descobrirá automaticamente os outros blocos e também se conectará a eles. Se o bloco inicial falhar, o cliente fará o failover para um dos outros tijolos. Então, após o bootstrap inicial, o sistema de arquivos está altamente disponível.
No entanto, quando você reinicializa um host do cliente e o bloco para o qual foi inicializado (por exemplo, em /etc/fstab ) está inativo, o cliente não se conectará, até que você o aponte manualmente para outro bloco. para fazer o bootstrap.
Isso pode ser um problema em um cenário em que os clientes são reinicializados ou adicionados enquanto o bloco 'principal' está inativo. Por exemplo, no Amazon AWS, suponha que você tenha dois tijolos GlusterFS replicadores em zonas de disponibilidade separadas. Quando o AZ que contém seu 'primário' falha ou perde a conectividade, há uma boa chance de você escalonar automaticamente servidores adicionais no outro AZ para lidar com o aumento da carga lá. Como o 'primário' é inacessível, esses servidores não podem montar o sistema de arquivos, até você configurá-los para montar o outro bloco.
Como posso ter certeza de que os clientes (novos ou reinicializados) tentarão se conectar a qualquer bloco disponível?
Usamos o Puppet para gerenciar todos os nós, incluindo o conteúdo de /etc/fstab , e estamos usando o GlusterFS 3.9.
If backupvolfile-server option is added while mounting fuse client, when the first volfile server fails, then the server specified in backupvolfile-server option is used as volfile server to mount the client.