sistema de archivos reflejado en algunos servidores


13

Estoy buscando una solución para duplicar o replicar un directorio (o un sistema de archivos) en algunos servidores Linux. La solución ideal sería una, que permita el acceso de lectura y escritura a todos los servidores. También quiero que sea resistente, si uno de los servidores se cae, el resto debería funcionar sin perder ningún dato.

He estado buscando algunas soluciones:

  • DRBD : replicaciones a nivel de bloque, parece un poco exagerado;
  • lsyncd : parece muy simple, pero tengo dudas sobre el rendimiento;
  • GlusterFS : parece que sería una buena combinación, aún no he descubierto cómo funciona exactamente el modo de replicación. ¿Tendrá las características que requiero?

Cualquier otra sugerencia es bienvenida.


¿Está buscando una configuración de nada compartido o conectará todos los servidores a la misma SAN de back-end?
HampusLi

lógicamente no compartió nada (físicamente es EC2 con EBS).
vartec

Respuestas:


6

La primera pregunta que haría es si desea replicar esto en dos servidores o más de dos servidores. Para dos servidores iría con DRDB, para tres o más iría con gluster.

Si la latencia de E / S no es una preocupación crítica, iría con gluster. Es bastante fácil de configurar y claramente puede hacer lo que necesita. Todo lo que necesita hacer es crear un servidor Gluster que sirva los archivos en los tres cuadros y luego también hacer que cada cuadro actúe como un cliente Gluster que monta los archivos.

DRDB va a ser complicado trabajar en un modo maestro <-> maestro con 3 o más servidores. Tiene que configurar una configuración basada en anillo y no la recomendaría. Sin embargo, para dos servidores DRDB es fantástico. Master <-> El modo Master no es complicado de configurar y no tiene que aprender nada del sistema de archivos.

lsycd es ideal para una configuración maestro / esclavo, pero no parece querer eso.

Ceph todavía es bastante nuevo, la última vez que lo verifiqué ni siquiera tenía soporte para fsck. Prefiero basar mi infraestructura en algo más estable.

Lustre es un producto fantástico para implementaciones a gran escala, pero necesita configurar latidos y failover para el servidor mds o tendrá un único punto de falla. Dado el número limitado de servidores de los que habla, sospecho que es excesivo en este caso.


Inicialmente comenzaré con solo 2 servidores por clúster, pero quiero tener la opción de tener más de 2 servidores para escalamiento horizontal; La configuración de Gluster que está describiendo, ¿manejaría la falla de uno de los servidores? ¿Sería fácil agregar un servidor adicional?
vartec

2

¿Qué tal Ceph o Lustre ?


¿Lustre es compatible con Ubuntu Server? Estoy revisando a Ceph ahora, gracias por su sugerencia.
vartec

De la wiki de ceph: "Ceph está bajo un fuerte desarrollo y aún no es adecuado para otros usos que no sean la evaluación comparativa y la revisión". Ceph.newdream.net/wiki
Jeff Busby

2

Debería buscar en OpenAFS : es un sistema de archivos distribuido principalmente que permite que existan múltiples copias de datos distribuidas en el clúster y todos pueden leer / escribir en el FS al mismo tiempo.

También tiene un montón de otras características útiles (buena autenticación, cifrado en el cable, almacenamiento en caché local integrado en clientes, cliente nativo de Windows, portátil en muchas versiones de Unix, etc.)

Sin embargo, es un poco pesado levantarlo.


misma pregunta que con NFS: "permite múltiples copias". OK, pero ¿se encarga de sincronizar estas copias?
vartec

Sí. Y es posible, aunque molesto, recuperarse de la pérdida del maestro primario. Pero es trivial tener múltiples escritores y los bloques resultantes almacenados en múltiples hosts.
Chris

La clave para comprender OpenAFS es que es un sistema de administración de caché: hay un espacio de nombres (es decir, solo existe un "archivo") pero hay copias en caché del archivo en todas partes y un protocolo para asegurarse de que todas las copias en caché sean consistentes . Si pierde el maestro, puede convertir una de las copias en caché en el maestro, pero no es ideal estar en esa situación.
Chris

1

NFS también podría funcionar bien, dependiendo de sus necesidades.


AFAIK, NFS no proporciona forma de montar servidores replicados, pero no la replicación en sí. Pero no he estado usando NFS durante mucho tiempo, así que tal vez eso ha cambiado. ¿Podría vincular a los documentos de NFS que describen dicha configuración?
vartec

Un camino fuera de mi alcance sería replicar los directorios a varios servidores nfs, uno de los cuales tiene un vip primario, y migrar el vip a través de los servidores si uno falla. O round robin dns tal vez. NFS en sí mismo puede no hacer todo lo que necesita, pero en conjunto con los servicios de clúster heartbeat o red hat, puede ser lo que necesita. No estoy seguro de que la pregunta original tuviera todos los requisitos. Incluso podría hacer rsync en un grupo de servidores, digamos cada hora, para una solución realmente rápida y fácil.
LSD

Omita la parte sobre rsync. Haría la replicación, pero es principalmente para configuraciones de solo lectura, que no se ajustan a sus requisitos. Tenía la intención de editar mi comentario anterior, pero no me lo permitió.
LSD

1

Hacer que esto funcione con DRBD va a ser realmente difícil: el problema no es que n8whnp parezca pensar un problema con respecto a la replicación multidireccional (solo haces todas las franjas de nodos en un conjunto espejo), sino que es de control de concurrencia d necesitaría ejecutar un sistema de archivos en clúster encima de la duplicación en la parte superior de DRBD.

lsyncd es aún peor ya que no hay una solución práctica para el control de concurrencia.

Recomiendo una solución de tipo AFS (AFS, OpenAFS) como una solución madura, estable y abierta. Me mantendría libre de brillo desde que Oracle lo cerró. No estoy demasiado familiarizado con los glusterfs, pero como se basa en un almacenamiento distribuido en lugar de replicado, le recomiendo que analice detenidamente cómo se comportará en la operación de cerebro dividido (AFS OTOH está diseñado para funcionar en modo desconectado).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.