¿Qué protocolo de uso compartido de archivos de red tiene el mejor rendimiento y fiabilidad? [cerrado]

Tenemos una configuración con algunos servidores web con equilibrio de carga. Queremos tener algún tipo de almacenamiento compartido de red al que puedan acceder todos los servidores web. Se utilizará como un lugar para almacenar archivos cargados por los usuarios. Todo está ejecutando Linux.

¿Deberíamos usar NFS, CIFS, SMB, fusible + sftp, fusible + ftp? Hay tantas opciones para los protocolos de red para compartir archivos, es muy difícil elegir una. Básicamente, solo queremos montar este recurso compartido de forma permanente en varias máquinas. Las características de seguridad son menos preocupantes porque no se podrá acceder a la red desde otro lugar que no sea el servidor que lo monta. Solo queremos que funcione de manera confiable y rápida.

¿Cuál deberíamos usar?

Yo voto por NFS.

NFSv4.1 agregó la capacidad Parallel NFS pNFS, que hace posible el acceso a datos en paralelo. Me pregunto qué tipo de clientes están utilizando el almacenamiento si solo fuera como Unix, entonces elegiría NFS según las cifras de rendimiento.

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 clúster FS 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 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 de redhat hace un buen trabajo enumerando los pros y los contras de un clúster 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 buscar en Jumbo Frames, y si la integridad de los datos es crítica, use la suma de comprobación CRC32 si usa iSCSI con Jumbo Frames.

Tenemos un clúster web de carga 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 recurso compartido CIFS central (SAMBA) a ambos servidores
• Un recurso compartido NFS central para ambos servidores
• Una unidad SAN compartida que ejecuta OCFS2 montó ambos servidores

La solución RSYNC fue la más simple, pero los cambios tardaron 10 minutos en aparecer y RSYNC puso tanta carga en los servidores que tuvimos que estrangularlo con un script personalizado para pausarlo cada segundo. También estábamos limitados a escribir solo en la unidad fuente.

La unidad compartida de rendimiento más rápido fue la unidad en clúster OCFS2 hasta que se volvió loca y se bloqueó 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 el techo y los servidores comienzan a reiniciarse. Esto puede ser un fracaso de capacitación de nuestra parte.

El siguiente mejor fue NFS . Ha sido extremadamente estable y tolerante a fallas. Esta es nuestra configuración actual.

SMB (CIFS) tuvo algunos problemas de bloqueo. En particular, los servidores web no estaban viendo cambios en los archivos del servidor SMB. SMB también tendía a bloquearse cuando fallaba 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 servidores NFS con Heartbeat para la conmutación por error.

Te sugiero POHMELFS: fue creado por el programador ruso Evgeniy Polyakov y es muy, muy rápido.

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 completamente sus datos valiosos a cualquier otra máquina en la red ;-)

No insulto a las cosas de FUSE, pero todavía parece ... fresco, si sabes a lo que me refiero. No sé si todavía confío en él, pero eso podría ser solo yo siendo un viejo nebuloso, pero a veces se justifica el viejo fogeyism cuando se trata de datos empresariales valiosos.

Si desea montar permanentemente un recurso compartido en varias máquinas, y puede jugar junto con algunas de las rarezas (principalmente problemas de UID / GID), entonces use NFS. Lo uso y lo tengo por muchos años.

NFS Está probado y es cierto, y puede tener una configuración sólida como una roca. El rendimiento de GFS es generalmente horrible, especialmente en sistemas de archivos con grandes cantidades de archivos pequeños. No he usado OCFS, pero generalmente frunzo el ceño ante el concepto de sistema de archivos del clúster. Luego está Lustre, pero esa es otra lata de gusanos ...

Aconsejaría contra NFS. En pocas palabras: teníamos una granja de servidores web, con JBoss, Apache, Tomcat y Oracle, todos con recursos compartidos NFS para archivos de configuración comunes y registro.

Cuando el recurso compartido NFS desapareció (es cierto que es una ocurrencia rara) todo se derrumbó (realmente predecible, y aconsejé a los 'devlopers' contra este atajo de tiempo de configuración).

Parece que hay un problema con la versión de NFS que estábamos usando que, si el objetivo desaparecía durante una escritura, el cliente caería en un ciclo de espera interminable, esperando que el objetivo NFS regrese. Incluso si el cuadro NFS se vuelve a unir, el ciclo aún no termina.

Estábamos usando una mezcla de RHEL 3,4,5. El almacenamiento estaba en RHEL4, los servidores estaban en RHEL5, la red de almacenamiento era una LAN separada y no se ejecutaba en vlans.

Si hay un extremo frontal de carga equilibrada, que verifica el almacenamiento individual, ¿no sería un cuello de botella para su sistema?

¿Ha considerado una conexión iSCSI de solo lectura a su almacenamiento, con un script controlado por eventos para mover el archivo cargado al almacenamiento a través de ftp / scp cuando se carga un archivo?

La única vez que implementé un almacenamiento centralizado exitoso para múltiples cabezales de lectura fue en una matriz de almacenamiento de EMC ... Todos los demás intentos rentables tuvieron sus inconvenientes.

Considerado GFS? GFS es un sistema de archivos en clúster y, en mi experiencia, es bastante confiable. Puede tener más de un diario, se escala bastante bien

Pero necesitaría instalar algunos servicios de clúster y GFS no es exactamente conocido por su rapidez. Otoh, siempre ha sido lo suficientemente rápido para mí, pero mmm.

Estaría loco para considerar un FS distribuido como GFS, e iSCSI es excesivo.

Si quieres simple ve con NFS. Es simple y rápido, y con monturas suaves bastante robustas. También considere deshabilitar toda la basura de bloqueo que la acompaña. Tengo escritorios Linux que toman todo su directorio de inicio y aplicaciones de NFS, funciona bien.

Si desea una velocidad escandalosa, vaya con Lustre, que es significativamente más fácil de configurar que GFS y se parece mucho a RAID NFS. Usamos Lustre para nuestros grupos.

Puede que llegue un poco tarde. Usamos un MD3220 Dell Storage que tiene un puerto dual de clúster. Nuestra unidad tiene 2 controladores en caso de que uno se caiga en segundo lugar, lo mantendremos en funcionamiento hasta que solucionemos el problema. Dado que HDD, FAN, fuente de alimentación y controlador son todos Hotswap, reemplazamos las piezas dentro y fuera. A partir del formato usamos NFS.

Si ya tiene servidores web en todas partes y es bueno para ejecutarlos, ¿por qué no considerar WebDAV?

Respuesta simple +1 para NFS. Tengo recursos compartidos de NFS que se han montado durante años sin problemas.

Si está buscando una súper confiabilidad, considere incluir DRBD en la mezcla también para un sistema de archivos NFS de conmutación por error automático distribuido.

La única otra opción (con la que estoy familiarizado) es iSCSI, pero puede ser un problema en la parte trasera para configurar ...

Tiene muchas opciones, con una variedad de costos. SAN compartido con FC, iSCSI o una de las adiciones más recientes. En cualquier caso, pueden ser costosos de configurar y aún necesita ejecutar un sistema de archivos compatible con el clúster. Los sistemas de archivos agrupados son un mundo de dolor. Para cualquier esperanza de éxito, necesita redes separadas de alta velocidad y baja latencia para la comunicación y los datos del clúster. Incluso con eso, es probable que obtenga fallas que resulten en un nodo cercado y asesinado.

El único sistema de archivos de clúster que he encontrado que simplemente funciona sin problemas es VMFS. Pero eso es tan especializado que no serviría de nada, incluso si estuviera disponible para uso general.

NFS es probablemente el camino a seguir para su configuración. Si le preocupa la resistencia, necesita obtener una caja NFS agrupada adecuada. Puede hacer una configuración homebrew, pero daría con el problema anterior. La mejor apuesta (si tiene el dinero), son los archivadores agrupados de NetApp. Es una opción costosa, pero la agrupación realmente funciona sin problemas. No solo eso, son muy rápidos.

Me gustaría hacer eco de la advertencia que algunos han dado contra NFS, aunque NFS es probablemente su mejor opción (por extraño que parezca).

Tenía un cliente NFS que tuve que desconectar de AC para apagarlo porque el servidor NFS había desaparecido y el cliente se negó (en el núcleo) a desbloquear o apagar porque el servidor NFS se había ido.

Para hacerlo bien, insistiría en NFSv4 en todo momento, seguir con las conexiones TCP, usar marcos jumbo y usar un clúster NFS. No puede permitirse que su servidor NFS desaparezca.

GFS es un vudú realmente negro. La cantidad de trabajo requerida para que funcione un clúster simple de dos clientes es asombrosa en comparación con las alternativas. OCFS2 es mucho más simple de implementar, pero es muy exigente cuando se trata de las versiones del módulo del kernel involucradas en todos los servidores conectados, y eso es solo el comienzo.

A menos que realmente necesite el tipo de acceso de bajo nivel que ofrece un sistema de archivos de clúster, NFS o CIFS es probablemente todo lo que necesita.

En una gran granja de servidores, tuvimos varios millones de páginas html creadas por los usuarios. NFS no funcionó tan bien, así que terminamos colocándolos en una tabla mysql. La sobrecarga en comparación con atravesar un árbol de directorios era casi la misma.

Utilicé SFTP y funcionó bien para mis propósitos: NFS fue mi primer recurso, pero la funcionalidad de las ID de usuario / grupo me hizo abandonarlo bastante rápido.

Simplemente configure publickey auth y estará configurado en gran medida. Puede haber una sobrecarga de CPU algo más pesada para el cifrado SSH, pero por el lado positivo, nunca he tenido ningún problema con la corrupción de datos.

Sin embargo, FTP podría adaptarse a sus propósitos, ya que es más liviano. Presumiblemente quiere que sus servidores web estén haciendo el servicio web, no el trabajo ssh.