É verdade que é possível montar um volume GlusterFS em qualquer tijolo e o cliente FUSE descobrirá automaticamente os outros tijolos e se conectará a eles também. Se o tijolo inicial falhar, o cliente falhará em um dos outros tijolos. Portanto, após o bootstrap inicial, o sistema de arquivos está altamente disponível.
No entanto, quando você reinicializa um host cliente e o tijolo que você definiu para inicializar (por exemplo, em /etc/fstab) está inativo, o cliente não se conectará, até que você o aponte manualmente para outro tijolo para inicializá-lo.
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 replicantes em zonas de disponibilidade separadas. Quando o AZ que contém o seu 'principal' falha ou perde a conectividade, há uma boa chance de você dimensionar automaticamente servidores adicionais no outro AZ para lidar com o aumento da carga ali. Como o 'primário' está inacessível, esses servidores não podem montar o sistema de arquivos, até que você os configure para montar o outro bloco.
Como posso garantir que os clientes (novos ou reinicializando) tentem 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.
documentos glusterfs