Tenemos un clúster GlusterFS que utilizamos para nuestra función de procesamiento. Queremos integrar Windows en él, pero estamos teniendo problemas para descubrir cómo evitar el punto único de falla que es un servidor Samba que sirve un volumen GlusterFS.
Nuestro flujo de archivos funciona así:
- Los archivos son leídos por un nodo de procesamiento de Linux.
- Los archivos son procesados.
- Los resultados (pueden ser pequeños, pueden ser bastante grandes) se vuelven a escribir en el volumen de GlusterFS a medida que se realizan.
- Los resultados pueden escribirse en una base de datos, o pueden incluir varios archivos de varios tamaños.
- El nodo de procesamiento recoge otro trabajo de la cola y GOTO 1.
Gluster es excelente ya que proporciona un volumen distribuido, así como una replicación instantánea. ¡La resiliencia ante desastres es agradable! Nos gusta.
Sin embargo, como Windows no tiene un cliente GlusterFS nativo, necesitamos alguna forma para que nuestros nodos de procesamiento basados en Windows interactúen con el almacén de archivos de una manera resistente. La documentación de GlusterFS establece que la forma de proporcionar acceso a Windows es configurar un servidor Samba encima de un volumen GlusterFS montado. Eso llevaría a un flujo de archivos como este:
Eso me parece un solo punto de falla.
Una opción es agrupar Samba , pero parece estar basado en un código inestable en este momento y, por lo tanto, fuera de la ejecución.
Entonces estoy buscando otro método.
Algunos detalles clave sobre los tipos de datos que arrojamos:
- Los tamaños de archivo originales pueden ser desde unos pocos KB hasta decenas de GB.
- Los tamaños de archivo procesados pueden ser desde unos pocos KB a un GB o dos.
- Ciertos procesos, como excavar en un archivo comprimido como .zip o .tar, pueden causar MUCHAS escrituras adicionales a medida que los archivos contenidos se importan al almacén de archivos.
- Los recuentos de archivos pueden llegar a los 10 de millones.
Esta carga de trabajo no funciona con una configuración de Hadoop de "tamaño de unidad de trabajo estática". Del mismo modo, hemos evaluado los almacenes de objetos de estilo S3, pero los encontramos insuficientes.
Nuestra aplicación está escrita a medida en Ruby, y tenemos un entorno Cygwin en los nodos de Windows. Esto puede ayudarnos.
Una opción que estoy considerando es un servicio HTTP simple en un grupo de servidores que tienen montado el volumen GlusterFS. Dado que todo lo que estamos haciendo con Gluster es esencialmente operaciones GET / PUT, eso parece fácilmente transferible a un método de transferencia de archivos basado en HTTP. Póngalos detrás de un par de equilibrador de carga y los nodos de Windows pueden PONER HTTP al contenido de su pequeño corazón azul.
Lo que no sé es cómo se mantendría la coherencia de GlusterFS . La capa de proxy HTTP introduce suficiente latencia entre cuando el nodo de procesamiento informa que ha terminado con la escritura y cuando es realmente visible en el volumen de GlusterFS, que me preocupa que las etapas de procesamiento posteriores que intenten recoger el archivo no Encuéntralo. Estoy bastante seguro de que usar la direct-io-mode=enableopción de montaje ayudará, pero no estoy seguro de si eso es suficiente . ¿Qué más debo hacer para mejorar la coherencia?
¿O debería seguir otro método por completo?
Como Tom señaló a continuación, NFS es otra opción. Entonces hice una prueba. Dado que los archivos mencionados anteriormente tienen nombres proporcionados por el cliente que debemos mantener, y pueden venir en cualquier idioma, necesitamos preservar los nombres de los archivos. Así que construí un directorio con estos archivos:
Cuando lo monte desde un sistema Server 2008 R2 con el Cliente NFS instalado, obtengo una lista de directorios como esta:
Claramente, Unicode no se conserva. Entonces, NFS no va a funcionar para mí.
ctdbestable y listo para su uso en producción y la primera oración en el enlace que proporcionó invalida la segunda porque nunca se actualizó. Estaba planeando establecer esto, pero antes de llegar a esto cambié los trabajos a un entorno casi libre de ventanas.