¿Qué hace exactamente Gluster?

He estado jugando con Gluster durante los últimos 2 días y he estado haciendo preguntas aquí y en su sistema de preguntas. Realmente no entiendo algunas de las cosas. Veo gente que dice cosas como

Configure ladrillos replicados entre los servidores (ya que solo está usando 3, replicado sería más seguro), y cada servidor verá los archivos de todos los demás servidores como 'locales', incluso si un servidor falla, los archivos se han replicado en Los otros servidores.

o

Gluster mantendrá la sincronización de archivos entre volúmenes (ladrillos) y tiene capacidades de 'autocuración' que tratarán cualquier inconsistencia debido a que un servidor está desconectado.

Dado que monte un volumen remoto desde el servidor a los clientes, ¿cómo maneja Gluster la falla del nodo del servidor, desde el que se montan los volúmenes? Por lo que probé, la carpeta en el cliente donde se montó el volumen se vuelve inaccesible y tengo que usar umount para desbloquearlo. Y después de eso no hay contenido del servidor.

Esto es, básicamente, lo que no veo cubierto en ninguna explicación: ¿qué sucede cuando falla el nodo del servidor y si es posible replicar realmente el contenido, como lo hace Unison o rsync?

Recientemente comenzamos a investigar GlusterFS para nuestro propio uso, por lo que esta pregunta me resultó interesante. Gluster usa lo que se llaman 'traductores' en el cliente FUSE para manejar cómo almacena los datos. Hay varios tipos de traductores que se describen a continuación:

http://www.gluster.com/community/documentation/index.php/GlusterFS_Translators_v1.3

El que está preguntando específicamente se llama Traductor automático de replicación de archivos o AFR, y se trata en detalle aquí:

http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator

Mirando el código fuente, parece que los datos se escriben en los nodos simultáneamente, ¡mucho mejor que rsync!

Con respecto a la recuperación de una situación de falla, encontré una nota interesante. El sistema Gluster es diferente de Ceph en que no es consciente de los cambios en el estado de replicación y debe ser 'activado'. Entonces, si pierde un nodo en su clúster, debe buscar cada archivo para que Gluster se asegure de que se replica:

http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

No pude encontrar una buena página que describa los mecanismos del escenario de falla internamente, como cómo el cliente detecta que las cosas están rotas. Sin embargo, al descargar el código fuente y mirar a través del cliente, parece que hay varios tiempos de espera que utiliza para los comandos y una sonda que realiza de vez en cuando en otros sistemas del clúster. Parece que la mayoría de estos tienen marcas TODO y actualmente no son configurables, excepto a través de la modificación del código fuente, lo que puede ser una preocupación para usted si el tiempo de convergencia es crítico.

Con solo 2 nodos replicando, Gluster no es muy diferente a un script rsync automático. Las cosas realmente solo comienzan a ser interesantes una vez que tiene 4 o más nodos de almacenamiento: sus máquinas cliente ven un grupo de espacio, pero los archivos constituyentes se extienden por todos los nodos de almacenamiento (ladrillos). Esto significa que si sus 4 servidores tienen 10 TB de espacio local, sus máquinas cliente pueden ver un solo espacio de nombres de 20 TB (replicado o 40 TB de almacenamiento sin protección).

He visto un breve contratiempo, tal vez 30 segundos más o menos, en una máquina cliente cuando prueba IO después de que un bloque de almacenamiento no esté disponible. Sin embargo, después del problema, IO continuará normalmente siempre que haya servidores en línea que aún contengan un conjunto completo de datos de volumen.

Está describiendo un comportamiento inesperado: consultaría #gluster en irc.freenode.net o gluster-users@gluster.org o http://community.gluster.org/

-John Mark Gluster Miembro de la comunidad

Cuando falla el servidor orientado al cliente (es decir, el servidor cuya IP / DNS fue utilizada por el cliente para montar el sistema de archivos), todo el volumen se desconecta de ese cliente, es decir, no puede leer / escribir en el volumen.

Sin embargo, si el cliente lo montó usando IP / DNS de otro servidor, el volumen seguirá estando en línea para ese cliente. Sin embargo, las lecturas / escrituras no irán a la instancia fallida / bloqueada.