Usando GlusterFS para una replicación simple

Usando GlusterFS para una replicación simple

pregunta de novato. Necesito construir esto:

  • /sharedcarpeta ~500GB de archivos, ~1MB cada uno.
  • Dos cajas (servidor1 y servidor2) conectadas por una LAN de 1Gbs
  • Cada cuadro necesita tener acceso de lectura y escritura a los archivos, por lo que ambos son clientes.
  • Quiero que los archivos se repliquen en ambas cajas, cada vez que se escribe un archivo en un servidor, el mismo archivo debe estar presente en el otro.

Mis preguntas sobre GlusterFS:

  • ¿Duplicará los archivos en la misma caja? Por ejemplo, los archivos están activados /sharedy el montaje en /mnt/shared. ¿Se necesitará 1 GB de espacio en cada servidor?
  • En lugar de eso, ¿debería usar el sistema de archivos directamente, escribiendo localmente en /shared? ¿La replicación funciona de esta manera sin montar un cliente?

Además, si alguien conoce alguna otra forma de realizar esta configuración, estaré muy agradecido. Gracias de antemano.

Respuesta1

En realidad, Gluster es perfecto para este escenario. Obtiene replicación bidireccional y la capacidad de montar el sistema de archivos desde cualquier máquina, lo que le brinda (teóricamente) el doble de capacidad de E/S efectiva que NFS y conmutación por error activa en caso de que una de las cajas falle.

El problema al realizar rsync activo de esta manera es bloquear la E/S debido a bloqueos de archivos. Dependiendo de su aplicación y del cambio en los datos, ¡esto podría ser irrelevante o desastroso! Los sistemas de archivos distribuidos tienen una semántica de bloqueo muy específica que evita que esto suceda. Incluso si inotify tiene un mejor bloqueo (la última vez que lo probé no lo tenía) hoy en día, el acceso a sus archivos puede bloquearse, dependiendo de si su red puede hacer frente a los cambios. Todas estas son advertencias teóricas, pero vale la pena analizarlas dependiendo de lo que haga su aplicación.

Respuesta2

Finalmente logré resolver esto usando GlusterFS en ambos cuadros. Algunas cosas aprendidas en el proceso:

  • Primero probé una configuración RAID 1 genérica. El principal problema con esto es que el cliente siempre usa tcp para contactar con ambos servidores, incluso cuando uno de ellos está en la misma máquina. Entonces tengo que cambiar las configuraciones del cliente para reemplazar el volumen 'local' tpc con un volumen de acceso directo (almacenamiento/posix)
  • Para evitar estresar el enlace de red, cada cliente que lee utiliza el almacenamiento local con directiva option read-subvolume. Por supuesto, para mantener la integridad de RAID1, GlusterFS siempre verifica también otros volúmenes, pero el archivo real se recupera directamente del disco.
  • El rendimiento es bueno, pero el proceso del cliente parece un abrazo de memoria. Creo que está relacionado con el volumen de lectura rápida, necesito investigar más

Configuración de cliente modificada:

# Server1 configuration (RAID 1)
volume server2-tcp
    type protocol/client
    option transport-type tcp
    option remote-host server2
    option transport.socket.nodelay on
    option transport.remote-port 6996
    option remote-subvolume brick1
end-volume

volume posix-local
    type storage/posix
    option directory /shared
end-volume

volume locks-local
    type features/posix-locks
    subvolumes posix-local
end-volume

volume brick-local
    type performance/io-threads
    option thread-count 8
    subvolumes locks-local
end-volume

volume mirror-0
    type cluster/replicate
    option read-subvolume brick-local
    subvolumes brick-local server2-tcp
end-volume

.....

Respondiendo a mis dos preguntas:

¿Duplicará los archivos en el mismo cuadro?

No, el fs se monta usando FUSE. Línea /etc/fstab actual:

/etc/glusterfs/client.vol /mnt/shared glusterfs valores predeterminados 0 0

En lugar de eso, ¿debería usar el sistema de archivos directamente, escribiendo localmente en /shared? ¿La replicación funciona de esta manera sin montar un cliente?

No, utilice siempre volúmenes montados para realizar lecturas/escrituras; utilizar directamente el sistema de archivos puede generar inconsistencias.

Respuesta3

Sería mucho más fácil de configurar.rsync para hacer mirroring activo, o simplemente configurar un recurso compartido nfs y hacer que ambos extraigan del mismo disco real.

información relacionada