CMG Brasil

Pomegranate es un novedoso sistema de archivos distribuidos construido sobre almacenamiento tabular distribuido que actúa de forma muy parecida a un sistema NoSQL. Su objetivo es aumentar el rendimiento del acceso a objetos diminutos para soportar aplicaciones como los servicios de fotos y microblogs en línea, que requieren una alta concurrencia, un alto rendimiento y una baja latencia. Sus pruebas parecen indicar que funciona:

Hemos demostrado que el sistema de archivos sobre almacenamiento tabular funciona bien para el acceso altamente concurrente. En nuestro clúster de prueba, observamos un aumento lineal de más de 100.000 peticiones agregadas de lectura y escritura servidas por segundo (RPS).

En lugar de situarse encima del sistema de archivos, como casi todos los demás almacenes K-V, Pomegranate está integrado en el sistema de archivos. La idea es que la API del sistema de archivos es común a todas las plataformas, por lo que no requeriría una API separada para su uso. Cada aplicación podría usarlo fuera de la caja.

Las características de Pomegranate son:

• Maneja miles de millones de archivos pequeños de manera eficiente, incluso en un directorio;
• Proporciona una capa de caché separada y escalable, que puede ser snapshot-able;
• La capa de almacenamiento utiliza logs estructurados para absorber las escrituras de archivos pequeños para utilizar el ancho de banda del disco;
• Construye un espacio de nombres global tanto para archivos pequeños como para archivos grandes;
• Almacenamiento en columnas para explotar la localidad temporal y espacial;
• Hash extensible distribuido para indexar metadatos;
• Almacenamiento en caché reconfigurable para aumentar el paralelismo y la tolerancia a fallos;
• Pomegranate debería ser el primer sistema de archivos que se construye sobre almacenamiento tabular, y la experiencia de construcción debería ser digna para la comunidad de sistemas de archivos.

Can Ma, que dirige la investigación sobre Pomegranate, tuvo la amabilidad de acceder a una breve entrevista.

¿Puede darnos una visión general de la arquitectura y de lo que estáis haciendo que es genial y diferente?

Básicamente, no hay ningún sistema de archivos distribuido o paralelo que pueda manejar miles de millones de archivos pequeños de manera eficiente. Sin embargo, podemos prever que las aplicaciones web (como el correo electrónico, las fotos e incluso el vídeo) y la bioinformática (la secuenciación de genes) necesitan accesos masivos a archivos pequeños. Mientras tanto, la API del sistema de archivos es lo suficientemente general y bien entendida por la mayoría de los programadores.

Por lo tanto, queremos construir un sistema de archivos para gestionar miles de millones de archivos pequeños, y proporcionar un alto rendimiento de los accesos concurrentes. Aunque Pomegranate está diseñado para accesos a archivos pequeños, también soporta archivos grandes. Está construido sobre otros sistemas de archivos distribuidos, como Lustre, y sólo gestiona el espacio de nombres y los archivos pequeños. Sólo queremos estar sobre «los hombros de los gigantes». Ver la figura de abajo:

Pomegranate tiene muchos Servidores de Metadatos y Servidores de Almacenamiento de Metadatos para servir las peticiones de metadatos y las peticiones de lectura/escritura de archivos pequeños. Los MDS no son más que una capa de almacenamiento en caché, que cargan los metadatos desde el almacenamiento y consignan las instantáneas de memoria en el almacenamiento. El núcleo de Pomegranate es un sistema de almacenamiento tabular distribuido llamado xTable. Soporta búsquedas de múltiples columnas indexadas por clave. Utilizamos el hash extensible distribuido para localizar el servidor a partir de la clave, porque el hash extensible es más adaptable para escalar hacia arriba y hacia abajo.

En los sistemas de archivos, la tabla de directorios y la tabla de inodos están siempre separadas para soportar dos tipos diferentes de búsqueda. Las búsquedas por nombre de ruta son manejadas por la tabla de directorios, mientras que las búsquedas por número de nodo son manejadas por la tabla de nodo. No es trivial actualizar estos dos índices de forma consistente, especialmente en un sistema de archivos distribuido. Además, el uso de dos índices aumenta la latencia de las búsquedas, lo que es inaceptable para acceder a archivos pequeños. Normalmente, hay cachés en memoria para la dentadura y el inodo, sin embargo, las cachés no pueden ampliarse fácilmente. La modificación de los metadatos tiene que actualizar varias ubicaciones. Para mantener la consistencia, se introduce el registro de operaciones. Mientras, el registro de operaciones es siempre un punto de serie para los flujos de peticiones.

Pomegranate utiliza una estructura de directorio tipo tabla para fusionar la tabla de directorios y la tabla de inodos. Dos tipos diferentes de búsqueda se unifican en búsquedas por clave. Para el sistema de archivos, la clave es el valor hash del nombre del directorio. Los conflictos de hash se resuelven mediante un identificador único global para cada archivo. Para cada actualización, sólo hay que buscar y actualizar una tabla. Para eliminar el registro de operaciones, diseñamos y apoyamos las instantáneas de memoria para obtener una imagen consistente. Las regiones sucias de cada instantánea se pueden escribir en el almacenamiento de forma segura sin considerar las modificaciones concurrentes (las actualizaciones concurrentes son COWed.)

Sin embargo, hay algunas operaciones complejas del sistema de archivos como mkdir, rmdir, hard link y rename que deben ser consideradas. Estas operaciones tienen que actualizar al menos dos tablas. Implementamos un servicio de actualización multisitio fiable para propagar los deltas de una tabla a otra. Por ejemplo, en mkdir, propagamos el delta(«nlink +1») a la tabla padre.

¿Existen puntos únicos de fallo?

No hay SPOF en el diseño. Utilizamos un cluster de MDSs para servir las peticiones de metadatos. Si un MDS se bloquea, las peticiones son redirigidas a otros MDSs (se utilizan hash consistentes y heartbeats). Los metadatos y los archivos pequeños se replican en varios nodos. Sin embargo, esta replicación se activa mediante herramientas de sincronización externas que son asíncronas a las escrituras.

Los archivos pequeños han sido normalmente la muerte de los sistemas de archivos debido al mantenimiento de la estructura de directorios. ¿Cómo se evita eso?

Sí, es mortalmente lento el acceso a los archivos pequeños en los sistemas de archivos tradicionales. Reemplazamos la tabla de directorios tradicional (árbol B+ o árbol hash) por una tabla hash extensible distribuida. El nombre del directorio y los metadatos del inodo son tratados como columnas de la tabla. Las búsquedas de los clientes se envían (o se enrutan si es necesario) al MDS correcto. Así, para acceder a un archivo pequeño, sólo tenemos que acceder a una fila de la tabla para encontrar la ubicación del archivo. Mantenemos cada archivo pequeño almacenado secuencialmente en el sistema de archivos nativo. Como resultado, un acceso de E/S puede servir para la lectura de un archivo pequeño.

¿Qué apis de posix se soportan? ¿Pueden bloquearse los archivos, mapearse, crear enlaces simbólicos, etc.?

Actualmente, el soporte de POSIX está progresando. Soportamos enlaces simbólicos, acceso mmap. Mientras que, flock no está soportado.

¿Por qué hacer un sistema de archivos a nivel de kernel en lugar de un almacén K-V encima?

Nuestro objetivo inicial es implementar un sistema de archivos para soportar más aplicaciones existentes. Si bien, ahora soportamos la interfaz K/V en la parte superior de xTable. Ver la figura de arquitectura, el cliente AMC es el cliente clave/valor para Pomegranate. Soportamos predicados simples sobre la clave o el valor, por ejemplo soportamos «select * from table where key < 10 and ‘xyz’ in value» para obtener los pares k/v que el valor contiene «xyz» y la clave < 10.

¿Cómo se compara con otros sistemas de archivos distribuidos?

Queremos comparar el rendimiento del archivo pequeño con otros sistemas de archivos. Sin embargo, aún no lo hemos probado. Lo haremos en el próximo mes. Sin embargo, creemos que la mayoría de los sistemas de archivos distribuidos no pueden manejar accesos masivos a archivos pequeños de manera eficiente.

¿Se admiten índices y cualquier tipo de consultas?

Por ahora, estos soportes no se han considerado adecuadamente todavía. Tenemos previsto considerar las consultas de rango a continuación.

¿Funciona a través de los centros de datos, es decir, cómo trata la latencia?

Pomegranate sólo funciona en un centro de datos. Todavía no se ha considerado el soporte de la WAN.

Parece que utilizáis una arquitectura en memoria para la velocidad. ¿Puede hablar de ello?

Utilizamos una capa de caché de memoria dedicada para la velocidad. Las filas de la tabla se agrupan como rebanadas de la tabla. En la memoria, los sl
ices de la tabla se agrupan en una tabla hash local extensible tanto por rendimiento como por consumo de espacio. Como se muestra en la siguiente figura,

Los clientes emiten una solicitud mediante el hash del nombre del archivo y la búsqueda en el mapa de bits. A continuación, utilizan un anillo de hash consistente para localizar el servidor de caché (MDS) o el servidor de almacenamiento (MDSL). Cada actualización obtiene en primer lugar el grupo de transacciones *abierto*, y sólo puede aplicarse a la fila de la tabla en memoria. Cada cambio de grupo de transacciones es atómico. Una vez finalizadas todas las actualizaciones pendientes, el grupo de transacciones puede ser consignado al almacenamiento de forma segura. Este enfoque es similar al ZFS de Sun.

¿Cómo se maneja la alta disponibilidad?

Bueno, el servidor central para la gestión consistente del anillo de hash y el coordinador de fallos debe ser replicado por el algoritmo Paxos. Planeamos usar ZooKeeper para un servicio central de alta disponibilidad.
Otros componentes están diseñados para ser tolerantes a fallos. Las caídas de MDS y MDSL pueden configurarse como recuperadas inmediatamente enrutando las peticiones a nuevos servidores (seleccionando el siguiente punto en el anillo de hash consistente).

Operacionalmente, ¿cómo funciona? ¿Cómo se añaden los nodos al sistema?

Añadir nodos a la capa de caché es sencillo. El servidor central (R2) añade el nuevo nodo al anillo de hash consistente. Todos los servidores de caché deben actuar ante este cambio y simplemente invalidar sus trozos de tabla de caché si van a ser gestionados por el nuevo nodo. Las solicitudes de los clientes se enrutan al nuevo servidor, y una notificación de cambio de anillo CH piggyback al cliente para extraer el nuevo anillo del servidor central.

¿Cómo maneja los archivos grandes? ¿Es adecuado para la transmisión de vídeo?

Como se ha descrito anteriormente, los archivos grandes se transmiten a otros sistemas de archivos distribuidos. Nuestra capa de caché no se verá contaminada por los datos de vídeo en streaming.

¿Algo más que quiera añadir?

Otra figura para la interacción de los componentes de Pomegranate.