Lustre, Gluster o MogileFS ?? para el almacenamiento, la codificación y la transmisión de video

Question

Tantas opciones y tan poco tiempo para probarlas todas ... Me pregunto si alguien tiene experiencia con los sistemas de archivos distribuidos para transmisión de video y almacenamiento/codificación.

Tengo una gran cantidad de archivos de video de gran tamaño (50GB a 250GB) que necesito almacenar en alguna parte, ser capaz de codificarlos en mp4 y transmitirlos desde varios servidores de Adobe FMS. La única forma de manejar todo esto es con un sistema de archivos distribuidos, pero ahora la pregunta es ¿cuál?

Mi investigación hasta el momento me dice:

• Lustre: madura solución probada y utilizada por una gran cantidad de grandes empresas, mejor con archivos> 10G es un controlador del núcleo.
• Gluster: nuevo, menos maduro, basado en FUSE que significa fácil de instalar pero quizás más lento debido a la sobrecarga FUSE. Es mejor manejar una gran cantidad de archivos más pequeños ~ 1GB
• MogileFS: parece ser solo para archivos pequeños ~ MB, usa HTTP para acceder? posible unión FUSE en el futuro.

Hasta ahora parece Lustre el ganador pero le gustaría conocer experiencias reales para la aplicación particular que tengo.

También Hadoop, Redhat GFS, Coda y Windows DFS suenan como opciones para que cualquier experiencia sea bienvenida. Si alguien tiene puntos de referencia, por favor comparte.

Después de un poco de experiencia real, esto es lo que he aprendido:

• Lustre:
  • Rendimiento: Increíblemente rápido! Puedo afirmar que Lustre puede servir muchas corrientes y que la velocidad de codificación no se ve afectada al acceder a los archivos a través de Lustre.
  • Compatibilidad con POXIS: ¡Muy bien !. No es necesario modificar las aplicaciones para usar brillo.
  • Replicación, Equilibrio de carga y falla: Muy mal !. Para la carga de replicación equilibrándonos y fallando, debemos confiar en otro software como las direcciones IP virtuales y DRDB.
  • Instalación: ¡Lo peor !. Imposible de instalar por meros mortales. Requiere una combinación muy específica de núcleo, parches de brillo y ajustes para que funcione. Y los parches de brillo actuales generalmente funcionan con kernels viejos que son incompatibles con el nuevo hardware/software .
• MogileFS:
  • Rendimiento: Bueno para archivos pequeños, pero no se puede utilizar para medianas y grandes archivos. Esto es principalmente debido a la sobrecarga de HTTP ya que todos los archivos son enviados/recibidos a través de solicitudes HTTP que codifican todos los datos en base64 agregando un 33% de sobrecarga a cada archivo.
  • La compatibilidad con POXIX no existe. Todas las aplicaciones requieren ser modificadas para usar mogilefs que lo vuelven inútil para la transmisión/codificación ya que la mayoría de los servidores de transmisión y las herramientas de codificación no entienden el protocolo MogileFS.
  • Replicación y conmutación por error fuera de la caja y el equilibrio de carga se puede implementar en la aplicación accediendo a más de un rastreador a la vez.
  • La instalación es relativamente fácil y los paquetes listos para usar existen en la mayoría de las distribuciones. La única dificultad que encontré fue establecer la base de datos maestro-esclavo para eliminar el punto único de falla.
    • Gluster:
  • Rendimiento: Muy malo para la transmisión. No puedo alcanzar más de unos pocos Mbps en una red de 10 Gbps . Los clientes y la CPU del servidor se disparan en las grabaciones pesadas. Para la codificación funciona porque la CPU está saturada antes de la red y las E/S.
  • POXIS: Casi compatible. Las herramientas que uso pueden acceder a montajes de atenuador como carpetas normales en el disco pero en algunos casos extremos las cosas comienzan a causar problemas. Verifique las listas de correo de gluster y verá que hay muchos problemas.
  • Replicación, conmutación por error y equilibrio de carga: ¡lo mejor! si realmente funcionaron Gluster es muy nuevo y tiene muchos errores y problemas de rendimiento.
  • La instalación es muy fácil. La línea de comandos de administración es increíble y la configuración replicada, distribuidos y divididos entre varios servidores no pueden ser más fáciles.

Conclusión final:

Por desgracia, la conclusión es "No hay una sola bala de plata".

Actualmente tenemos nuestros archivos multimedia en Gluster3.2 en un volumen replicado para almacenamiento y transcodificación. Siempre que no tenga muchos servidores, evite la replicación geográfica y los volúmenes de banda funcionan bien.

Cuando vamos a transmitir los archivos multimedia los copiamos a un volumen de brillo que se replica en un segundo volumen de brillo a través de DR: DB. El servidor wowza luego lee los archivos multimedia de los volúmenes de brillo.

Y finalmente usamos MogileFS para servir las miniaturas en nuestros servidores de aplicaciones web.

Answer 1

De los sistemas nombrados, el más adecuado es MoglieFS.

Pero quizás usted pueda pasar sin ningún sistema especial. Digamos que tiene 4 servidores AdobeFMS:

{video0.exmple.com,video1.exmple.com,video2.exmple.com,video3.exmple.com}. 

Puede distribuir todos sus vídeos entre los 4 servidores utilizando esquema simple, como

/* 
    * pseudo code 
    */ 

    $server_id = get_server_id(filename); 
    ... 
    ... 
    int function get_server_id(filename) 
    { 
     return hash(filename) mod 4; 
    } 

después de codificar vídeos, su aplicación sería

$server_id = get_server_id(file_name) 
copy file_name to /mnt/$server_id/ 

Los clientes de

tendrán acceso a videos usando algo como http://videoN.example.com/filename.mp4, donde N se calcula a partir de nombre de archivo usando get_server_id().

Lustre/Gluster no es lo que realmente debería estar buscando.Lustre FS es más maduro, pero los desarrolladores le piden que trate los archivos de dicho FS como "caché", es decir, que se pueden perder en cualquier momento.

Lustre/Gluster están destinados para su uso en HPC para permitir el acceso rápido para grandes cantidades de datos sin que el servidor de almacenamiento único sea el cuello de botella de rendimiento. Otro punto para esos sistemas es que son una queja POSIX. En el entorno de investigación científica/HPC, normalmente no tiene tiempo para reescribir sus aplicaciones porque instaló un FS nuevo y rápido.

Answer 2

Echa un vistazo al sistema de archivos Hadoop (HDFS). Se centra en archivos de gran tamaño y computación de tareas en paralelo (con mapa/reducir), tiene una alta latencia pero un rendimiento muy alto. Actualmente se utiliza en instalaciones tan grandes como Facebook y amazon.com

Answer 3

MogileFS es ideal para ese tipo de cosas. Las bibliotecas de los clientes varían un poco en calidad, pero me sorprendería que no hubiera sitios de producción a gran escala que utilizaran casi cualquier idioma para acceder a ellos.

HTTP es un buen protocolo para este tipo de cosas en realidad. ¿Quién no tiene un cliente HTTP eficiente y rico en características?

Answer 4

Map-reduce no ayuda en la relación de escritura/lectura de 90/10! El tamaño constante del archivo es bueno y los archivos son pequeños. Por lo tanto, MogileFS suena como una buena alternativa ya que la situación de caché de Luster/Gluster no es apropiada.

Answer 5

GlusterFS se han mejorado mucho hasta la fecha. Ahora están proporcionando "bloqueo granular" para archivos grandes. Vea aquí: http://www.gluster.org/community/documentation/index.php/WhatsNew3.3 También es bastante dependiente de las tasas de cuadros de video que debe trabajar también. Si no sube las tarifas 4K, Gluster puede resolver los problemas de almacenamiento. Si hay una gran demanda de velocidad, Infiniband puede entrar para jugar.