Solución 1:
Voto por NFS.
NFSv4.1 agregó la capacidad pNFS de NFS paralelo, que hace posible el acceso a datos paralelos. Me pregunto qué tipo de clientes están usando el almacenamiento si solo es similar a Unix, entonces optaría por NFS según las cifras de rendimiento.
Solución 2:
La respuesta corta es usar NFS. Según este tiroteo y mi propia experiencia, es más rápido.
¡Pero tienes más opciones! Debe considerar un FS de clúster como GFS, que es un sistema de archivos al que pueden acceder varias computadoras a la vez. Básicamente, comparte un dispositivo de bloque a través de iSCSI, que es un sistema de archivos GFS. Todos los clientes (iniciadores en el lenguaje iSCSI) pueden leer y escribir en él. Redhat tiene un libro blanco. También puede usar el clúster FS OCFS de Oracle para administrar lo mismo.
El documento redhat hace un buen trabajo enumerando los pros y los contras de un cluster FS vs NFS. Básicamente, si desea mucho espacio para escalar, GFS probablemente valga la pena. Además, el ejemplo de GFS utiliza una SAN de canal de fibra como ejemplo, pero podría ser fácilmente una SAN RAID, DAS o iSCSI.
Por último, asegúrese de examinar Jumbo Frames y, si la integridad de los datos es fundamental, utilice la suma de comprobación CRC32 si utiliza iSCSI con Jumbo Frames.
Solución 3:
Tenemos un clúster web de limpieza de carga de 2 servidores. Hemos probado los siguientes métodos para sincronizar contenido entre los servidores:
- Unidades locales en cada servidor sincronizadas con RSYNC cada 10 minutos
- Un CIFS (SAMBA) central compartir con ambos servidores
- Un NFS central compartir con ambos servidores
- Una unidad SAN compartida que ejecuta OCFS2 montó ambos servidores
El RSYNC La solución fue la más simple, pero los cambios tardaron 10 minutos en aparecer y RSYNC puso tanta carga en los servidores que tuvimos que acelerarlo con un script personalizado para pausarlo cada segundo. También nos limitamos a escribir solo en la unidad de origen.
La unidad compartida con el rendimiento más rápido fue OCFS2 unidad agrupada hasta que se volvió loca y colapsó el clúster. No hemos podido mantener la estabilidad con OCFS2. Tan pronto como más de un servidor accede a los mismos archivos, la carga sube por las nubes y los servidores comienzan a reiniciarse. Esto puede ser una falla de entrenamiento de nuestra parte.
El siguiente mejor fue NFS . Ha sido extremadamente estable y tolerante a fallas. Esta es nuestra configuración actual.
PYME (CIFS) tenía algunos problemas de bloqueo. En particular, los servidores web no veían los cambios en los archivos del servidor SMB. SMB también tendía a bloquearse cuando se conmutaba por error el servidor SMB
Nuestra conclusión fue que OCFS2 tiene el mayor potencial pero requiere MUCHO análisis antes de usarlo en producción. Si desea algo sencillo y confiable, recomendaría un clúster de servidor NFS con Heartbeat para conmutación por error.
Solución 4:
Te sugiero POHMELFS:fue creado por el programador ruso Evgeniy Polyakov y es muy, muy rápido.
Solución 5:
En términos de confiabilidad y seguridad, probablemente CIFS (también conocido como Samba), pero NFS "parece" mucho más liviano, y con una configuración cuidadosa, es posible no exponer por completo sus datos valiosos a cualquier otra máquina en la red;-)
No es un insulto para el material de FUSE, pero aún parece... fresco, si sabes a lo que me refiero. No sé si confío en él todavía, pero eso podría ser simplemente que soy un viejo anticuado, pero el anticuado a veces está justificado cuando se trata de datos empresariales valiosos.
Si desea montar permanentemente un recurso compartido en varias máquinas, y puede jugar con algunas de las rarezas (en su mayoría problemas de UID/GID), entonces use NFS. Lo uso, y lo tengo desde hace muchos años.