enric - videos de angeles wolder

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

Question

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

Tengo muchos archivos de video enormes (de 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 ahora me dice:

• Lustre : solución comprobada y madura, utilizada por muchas grandes empresas, la mejor con archivos> 10G es un controlador de kernel.
• Gluster : nuevo, menos maduro, basado en FUSE que significa fácil de instalar pero quizás más lento debido a la sobrecarga de FUSE. 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, Lustre parece el ganador, pero me gustaría escuchar 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 una experiencia real, esto es lo que aprendí:

• Lustre:
  • Rendimiento: ¡Increíblemente rápido! Puedo afirmar que Lustre puede servir para muchas transmisiones 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 equilibrar la carga de replicación y fallar, necesitamos confiar en otro software como IP virtuales y DRDB.
  • Instalación: ¡lo peor !. Imposible de instalar por meros mortales. Requiere una combinación muy específica de kernel, parches de brillo y ajustes para que funcione. Y los parches de brillo actuales generalmente funcionan con núcleos viejos que son incompatibles con el nuevo hardware / software.
• MogileFS:
  • Rendimiento: bueno para archivos pequeños pero no utilizables para archivos medianos a grandes. Esto se debe principalmente a la sobrecarga HTTP, ya que todos los archivos se envían / ​​reciben a través de solicitudes HTTP que codifican todos los datos en base64 agregando una sobrecarga del 33% a cada archivo.
  • La compatibilidad con POXIX no existe. Todas las aplicaciones requieren modificaciones 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.
  • La replicación y la conmutación por error fuera de la caja y el equilibrio de carga se pueden implementar en la aplicación accediendo a más de un rastreador a la vez.
  • La instalación es relativamente fácil y existen paquetes listos para usar en la mayoría de las distribuciones. La única dificultad que encontré fue establecer la base de datos maestro-esclavo para eliminar el único punto 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 que 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 establecer volúmenes duplicados, distribuidos y replicados entre varios servidores no puede ser más fácil.

Conclusión final:

Lamentablemente, 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 en 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

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

Answer 2

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

Pero quizás puedas salir sin ningún sistema especial. Supongamos que tiene 4 servidores AdobeFMS:

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

Puede distribuir todos sus videos entre esos 4 servidores usando un 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 videos, su aplicación

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

los clientes 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 realmente lo que deberías estar buscando. Lustre FS es más maduro, pero los desarrolladores le piden que trate los archivos en dichos FS como "caché", es decir, que se pueden perder en cualquier momento.

Lustre / Gluster están destinados para su uso en HPC para permitir un acceso rápido para grandes cantidades de datos sin que el único servidor de almacenamiento sea el cuello de botella de rendimiento. Otro punto para esos sistemas es que son una queja de 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 3

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 4

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 para las que también debería trabajar. Si no sube a las tarifas de 4K, Gluster puede resolver los problemas de almacenamiento. Si hay una gran demanda de velocidad, Infiniband puede entrar para jugar.

Answer 5

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 esto en realidad. ¿Quién no tiene un cliente HTTP eficiente y rico en características?