Subir fotos en Facebook en una de las funcionalidades más utilizadas por los usuarios, los mismos que a la fecha han “subido” al rededor de 15 mil millones de fotos en sus álbumes, adicionalmente facebook genera y almacena cuatro imágenes de distintos tamaños por cada foto lo que se traduce en un total de 60 mil millones de fotos y 1.5 PB (Petabytes) de almacenamiento. La tasa actual de crecimiento es de 220 millones de fotos nuevas y 25 TB adicionales de almacenamiento cada semana. Con estos números y con picos de 550 mil fotos entregadas por segundo, la infraestructura de gestión de fotos de facebook se convierte en todo un reto.

Esta gigantesca cantidad de información supone un gran esfuerzo económico, por este motivo han cambiado el sistema de almacenamiento actual basado en NetApp por un modelo desarrollado a medida por un antiguo ingeniero de NetApp Jason Sobel, mejorando la relación coste-efectividad con un sistema de alto rendimiento demominado Haystack, en el cual  llevaban dos años en fase piloto hasta su impantación hace unos meses.

La infraestructura antigua estaba basada en CDN de Akamai y Limelight como cache para reducir el número de lecturas en los sistemas físicos de almacemamiento basados en la tecnología de NetApp y como servidor http lighttpd.

Esquema del Sistema Antiguo de Almacenamiento:

Infraestructura Nueva - Haystack

Esta infraestructura integra la entrega y el almacenamiento de las fotos en una sola capa física, implementa un servidor de fotos basado en HTTP el cual almacena las fotos en un almacén genérico de objetos (Generic Object Store) llamado Haystack. El principal requerimiento de esta solución es eliminar cualquier sobrecarga innecesaria de metadatos por cada operación de lectura de fotos. El Haystack se puede descomponer en las siguientes capas funcionales:

• HTTP Server
• Photo Store
• Haystack Object Store
• Filesystem
• Storage

Esquema de la Nueva Infraestructura:

A continuación ampliaremos cada una de las capas funcionales empezando desde las más bajas.

Storage

Haystack es desplegado sobre blades simples de almacenamiento. La configuración típica de cada blade (2U) de almacenamiento es:

• 2 x quad-core CPUs
• 16GB – 32GB de memoria
• Controladora RAID  con 256MB – 512MB de NVRAM cache
• 12+ 1TB SATA drives

Cada blade de almacenamiento proporciona al rededor de 10TB de espacio utilizable, configurado como un RAID-6 . RAID-6 ofrece una redundancia adecuada y  un excelente performance de lectura mientras mantiene bajos los costos de almacenamiento. El bajo performance en escritura es parcialmente mitigado por el NVRAM write-back cache de  la controladora RAID. Como la lectura es mayormente aleatoria, el NVRAM cache es totalmente reservado para escritura. El cache de los discos es deshabilitado para garantizar la consistencia de datos en el caso de un daño o falla eléctrica.

Filesystem

El almacén de objetos es implementado sobre archivos guardados en un sólo sistema de archivos creado sobre un volumen de 10TB.

Cada petición de lectura de fotos ejecuta en el sistema la operación read() sobre los offset (desplazamientos) conocidos en estos archivos, pero para poder ejecutar las lecturas el sistema de archivos debe localizar los datos en el volumen físico actual. Cada archivo en el sistema de archivos es representado por una estructura llamada inode el cual contiene un mapa de bloque (block map) que mapea el desplazamiento (offset) lógico del archivo con el bloque físico del desplazamiento en el volumen físico.

Actualmente el sistema de archivos seleccionado es el XFS.

Haystack Object Store

Haystack es un registro (log) simple estructurado (append-only) de un almacén de objetos que contiene needles que representan los objetos almacenados. Un Haystack consiste en dos archivos, el almacén Haystack que contiene los needles y un archivo de índice:

Los primeros 8KB del almacén Haystack es ocupado por un superblock. Inmediatamente después del superblock vienen los needles y cada needle consiste en un header (cabecera), los datos y un footer:

El identificador único de cada needle esta conformado por:  Key, Alternate Key, Flags, Offset y Size, donde el offset es el desplazamiento de needle dentro del almacén. El Haystack no restringe ningún valor para los keys, y por lo tanto es posible que existan needles con keys duplicados.

A cada needle en el almacén Haystack le corresponde un registro en el índice, de igual forma que su orden. El archivo de índice proporciona los mínimos metadatos requeridos para ubicar un needle en el almacén. Cargar y organizar los datos del indice en una forma que permita su búsqueda es responsabilidad de la aplicación Haystack (Photo Store en este caso). El indice no es un archivo critico y puede ser reconstruido desde el almacén de ser requerido. El principal propósito del indice es permitir rapidamente la carga de los metadatos del almacen en memoria sin recorrer todo el archivo del almacen Haystack, además el tamaño del indice es usualmente menor al 1% del tamaño del almacen.

Haystack Write Operation

La operación de escritura sobre el Haystack es sincrona, pero la de su indice es asincrona (no es critico) para mejorar el performance. El archivo de indice es periodicamente volcado al disco para limitar la fragmentación de las operaciones de recuperación causadas por fallas de hardware. Durante el proceso de recuperación el Haystack desecha cualquier needle parcial y reduce el archivo del almacen hasta el último needle valido. Finalmente escribe los datos perdidos del indice de los needles huerfanos al final del archivo del almacen Haystack.

Haystack no permite la sobreescritura, por lo tanto si se desea modificar la información de un needle, se debe crear una nueva versión del needle (con el mismo identificador) . Las aplicaciones pueden asumir que de los needles con identificadores duplicados el que tenga el mayor desplazamiento (offset) es el más actualizado.

Haystack Read Operation

Los parametros pasados al Haystack para ejecutar la operación de lectura incluyen: needle offset, key, alternate key, cookie y el tamaño de los datos. El Haystack adiciona el tamaño del header y footer al tamaño de datos y lee el needle completo desde el archivo.

Haystack Delete Operation

La operación de borrado es simple, se marca el needle asignando el bit “deleted” en los campos flag del needle. Sin embargo el indice asociado no es modificado y la aplicación puede seguir referenciando el needle eliminado.

Photo Store Server

El Photo Store Server es el responsable de aceptar las peticiones HTTP y convertirlas en las operaciones correspondientes en el almacén Haystack. Para minimizar el numero de I/Os requridos para obtener las fotos, el servidor mantiene un indice de todos los offset del almacen Haystack.

Cuando un usuario ingresa una foto, se le asigna un identificador unico de 64bit. La foto es escalada en 4 diferentes tamaños, cada foto escalada tiene el mismo cookie aleatorio e identificador de 64bit, y el tamaño logico de la imagen (large, medium, small, thumbnail) es guardado como alternate key. El servidor se encarga de almacenar las 4 imagenes en el Haystack.

El indice en memoria almacena la siguiente información por cada foto:

Haystack usa el proyecto de codigo abierto Google sparce (una estructura de datos hash), para mantener el indice en memoria pequeño, dado que sólo adiciona 2bit a cada Entry  del hash.

Es una operación en linea que permite reclamar el espacio utilizado por los needles eliminados y duplicados. Crea un nuevo Haystack copiando los needles mientras ignora los needles eliminados y duplicados, una vez termina la operación se intercambian las estructuras de archivos y memoria.

HTTP Server

Se utiliza el servidor HTTP simple evhttp server que provee la biblioteca de codigo abierto libevent. Se utilizan multiples hilos y cada hilo puede atender una peticion HTTP a la vez. Dado que la mayor carga de trabajo la ocasiona mayormente las operaciones I/O, el performance del servidor HTTP no es critico.

En Resumen: El nuevo almacenamiento Haystack elimina los metadatos generales agregando cientos de miles de imágenes en un único almacén de archivo. Esto mantiene los metadatos generales muy pequeños y permite almacenar la ubicación de cada needle en el almacén de archivos en un índice de memoria; permitiendo a recuperación de los datos de una imagen en un número mínimo de operaciones de E / S.

Fuente: abcdev