Introducción

Empecemos, veamos que es esto de GFS y de lo que algunos jamas hemos oído hablar. El sistema de ficheros Google (GFS) se ha diseñado e implementado para satisfacer la creciente demanda de procesamiento de datos de Google. GFS comparte algunos de los objetivos de los sistemas de archivos tradicionales; tales como rendimiento, escalabilidad, fiabilidad y disponibilidad. Su diseño ha estado dirigido por observaciones de la carga de trabajo y entorno tecnológico de Google.

Suposiciones de diseño

• El sistema está formado por muchos componentes que fallan con frecuencia.
• El sistema almacena un número  pequeño de grandes ficheros.
• La carga de trabajo principalmente consta de dos tipos de lecturas: lecturas de grandes flujos de datos y lecturas pequeñas aleatorias.
• La carga de trabajo también incluye muchas escrituras secuenciales y operaciones que añaden datos a ficheros.
• El sistema debe implementar eficientemente un mecanismo para que múltiples clientes puedan añadir concurrentemente datos a un mismo fichero.
• Un ancho de banda grande es más importante que una latencia baja.

Interfaz. La API

GFS proporciona una interfaz para el sistema de archivos, aunque no implementa un API estándar tal como POSIX. Las operaciones más comunes permitirán crear, borrar, abrir, borrar, leer y escribir ficheros. Además, GFS tiene operaciones de duplicación y de adición de información a ficheros.

La Arquitectura del sistema

• Un  cluster GFS consta de un único maestro y varios servidores de bloques a los que acceden múltiples clientes.
• Los ficheros están divididos en bloques de un tamaño fijo. Por fiabilidad, cada bloque esta replicado en varios servidores de bloques. Por defecto, se almacenan tres replicas.
• El servidor maestro mantiene metadatos del sistema de ficheros y controla actividades del sistema.
• El código cliente GFS insertado en cada aplicación utiliza la API del sistema de archivos y se comunica con el servidor maestro y servidores de bloques para leer o escribir datos utilizados en la aplicación.
• Ni los clientes ni los servidores de bloques mantienen los ficheros de datos en la cache.

Un sólo servidor maestro

Tener un único servidor maestro simplifica enormemente el diseño y posibilita al maestro hacer sofisticados emplazamientos de bloques y decisiones de replicación utilizando información global.

A continuación se explica las interacciones que hay que realizar en una operación de lectura:

1. El cliente traduce el nombre del fichero y el desplazamiento de bytes especificado por la aplicación en un índice de bloque dentro del archivo.
2. Envía al maestro una petición que contiene el nombre del archivo y el índice del bloque.
3. El maestro responde con el correspondiente identificador de bloque y la localización de la replica.
4. El cliente almacena en la caché esta información usando el nombre del archivo y el índice de bloque como clave.
5. El cliente envía una petición a una de las réplicas, normalmente a la más cercana.

El tamaño del bloque (si importa)

El tamaño de bloque es uno de los parámetros de diseño clave. Google utiliza un tamaño de bloque de 64 Mb. Un tamaño de bloque grande ofrece importantes ventajas:

1. Reduce la necesidad de interactuar con el maestro porque las lecturas y escrituras realizadas en un mismo bloque requieren solo una única petición al maestro para obtener la información de localización del bloque.
2. En un bloque grande, es más probable que el cliente ejecute varias operaciones, así que se puede reducir las conexiones manteniendo una conexión TCP persistente con el servidor de bloques durante un amplio periodo de tiempo.
3. Se reduce el tamaño de los metadatos almacenados en el servidor maestro.

Por otro lado, un tamaño de bloque grande puede tener desventajas:

1. Un fichero pequeño tiene un pequeño número de bloques, quizás solo uno. El servidor de bloques que almacena estos bloques podría convertirse en un punto crítico si varios clientes están accediendo a un mismo archivo.Este problema se puede arreglar almacenando tales ficheros con un mayor factor de replicación. Otra solución potencial es permitir a los clientes leer datos de otros clientes en tales situaciones.

Los Metadatos

El servidor maestro almacena tres tipos de metadatos: el espacio de nombres de los bloques y ficheros; el mapeo de los ficheros a los bloques; y la localización de cada réplica de un bloque.

Los dos primeros tipos se mantienen persistentes registrando los cambios mediante una operación log. Por el contrario, no se almacena la información de localización de los bloques persistentemente. Todos los metadatos se almacenan en memoria para que las operaciones sean rápidas.

Una restricción fundamental es que el número de bloques y por lo tanto la capacidad del sistema completo está limitada por el cantidad de memoria que tiene el maestro.

El coste de añadir memoria extra al maestro es un pequeño precio a pagar por la simplificación, fiabilidad, rendimiento y flexibilidad que se gana almacenando metadatos en memoria. Inicialmente se intentó mantener la información de localización de los bloques de manera persistente en el maestro, pero se decidió que era más simple pedir los datos a los servidores de bloque al iniciar la conexión y posteriormente hacerlo de forma periódica.

La operación log contiene un registro histórico de los cambios críticos en los metadatos. Puesto que el registro histórico de la operación log es crítico, se debe almacenar con fiabilidad, por lo que se replica en varias máquinas remotas. El maestro recupera el estado del fichero de archivos repitiendo los cambios registrados en el log.

El maestro crea puntos de control de sus estados cada vez que el log crece mas allá de un cierto tamaño, así que se puede recuperar cargando el punto de control desde el disco local y repetir solo un número limitado de registros log a partir de ese tamaño.

Modelo de consistencia

GFS tiene un modelo de consistencia flexible que soporta aplicaciones altamente distribuidas y es relativamente simple y eficiente de implementar. Los cambios del espacio de nombres de un fichero son atómicas.

El estado de una región de un archivo después de un cambio de datos depende del tipo de cambio, si tiene éxito o falla, y si hay cambios concurrentes. Una región puede estar en un estado definido o indefinido.

Después de una secuencia de cambios con éxito, la región del fichero cambiado se garantiza que sea definida y contenga los datos escritos por el último cambio. GFS consigue esto:

1. Aplicando cambios a un bloque en el mismo orden en todas sus réplicas.
2. Usando números de versiones de bloques para detectar alguna réplica que es antigua porque no ha realizado un cambio porque su servidor de bloques estaba caído.

Después de un cambio con éxito, los fallos de los componentes pueden corromper o destruir datos.

Interacciones en el sistema

1. Actualización y orden de los cambios / mutación
   Un cambio es una operación que modifica los datos o los metadatos de un bloque, como por ejemplo escribir o añadir.
   Se usa la actualización para mantener una consistencia en el orden de cambio a lo largo de las réplicas.
   El proceso de actualización se realiza siguiendo estos pasos:
   1. Los clientes preguntan al maestro cual servidor de bloques almacena la actual actualización para el bloque y la localización de otras réplicas.
   2. El maestro responde con la identidad del principal y la localización de otras réplicas (secundario).
   3. El cliente envía los datos a todas las réplicas.
   4. Todas las réplicas reconocen los datos recibidos y el cliente envía una petición de escritura al principal.
   5. El principal remite la petición de escritura a todas las replicas secundarias.
   6. Todos los secundarios responde al principal indicando que han completado la operación.
   7. El principal responde al cliente.

   Si una escritura de una aplicación es extensa o incluye un límite de bloque, el código del cliente GFS se descompone en varias operaciones de escritura.

2. Flujo de datos
   El flujo de datos está desacoplado del flujo de control para usar la red eficientemente. Mientras el control fluye desde el cliente al principal y luego a todos los secundarios, los datos son colocados en línea a lo largo de una cadena por un servidor de bloques en forma de tubería.
   El objetivo es usar completamente el ancho de banda de la red de máquinas, evitando cuellos de botella en la red y enlaces de alta latencia, y minimizando la latencia para colocar los datos.
3. Añadir información a ficheros
   GFS proporciona una operación atómica para añadir información a ficheros. La operación de añadir información es un tipo de mutación y sigue el flujo de control de explicado en el apartado 1 (Actualización y orden de los cambios / mutación) con solo una pequeña lógica extra del principal:
   • El cliente pone los datos en todos los últimos bloques del fichero.
   • Luego, se envía las peticiones al principal.
   • El principal verifica para ver si la operación en el bloque actual causaría que el bloque excediera el tamaño máximo (64 MB). Si es así, se rellena el bloque hasta el tamaño máximo, se le dice a los secundarios que hagan lo mismo, y se contesta al cliente indicando que la operación debería volverse intentar en el próximo bloque.
   • Si la operación es adecuada para el tamaño máximo, el principal añade los datos a sus replicas, le dice a los secundarios que escriban los datos en el desplazamiento exacto, y finalmente responde exitosamente al cliente.
   • Si la operación falla en alguna de las réplicas, el cliente reintenta la operación.

   GFS no garantiza que todas las réplicas sean idénticas, solo garantiza que los datos se escriban como una unidad atómica.

4. Duplicación
   La operación de duplicación hace una copia de un fichero o un árbol de directorios.
   Los usuarios lo usan para crear copias secundarias de grandes conjuntos de datos, o para crear puntos de control del estado actual antes de realizar cambios. Cuando el maestro recibe una petición de duplicación:
   • Primero elimina cualquier actualización pendiente sobre los  bloque del fichero que se desea duplicar.
   • Después que las actualizaciones han sido rechazadas o han expirado, el maestro registra la operación en disco.
   • Finalmente duplica los metadatos de los ficheros fuente y el árbol de directorios. El nuevo fichero duplicado apuntará al mismo bloque que el archivo fuente.

Funcionamiento del Maestro

1. Gestión del espacio de nombres y bloqueo
   GFS representa lógicamente su espacio de nombres como una tabla que mapea los caminos de nombres completos a un metadato. Cada operación del maestro realiza un conjunto de bloqueos antes de su ejecución. Por ejemplo para realizar una operación sobre el fichero /d1/d2/……../dn/leaf hay que realizar una serie de bloqueos para evitar conflictos.
   Una propiedad importante de este esquema de bloqueo es que se permite mutaciones concurrentes en el mismo directorio.
   Los bloqueos son activados en un orden total consistente para prevenir llegar a un punto muerto: estos primero se ordenan por nivel en el árbol de espacio de nombres y lexicalmente dentro del mismo nivel.
2. Emplazamiento de réplicas
   Un clúster GFS esta fuertemente distribuido en más de un nivel. Normalmente tiene cientos de servidores de bloques desplegados a lo largo de varias subredes de máquinas. La distribución multinivel presenta un gran desafió para distribuir datos proporcionando escalabilidad, fiabilidad y disponibilidad.
   La política de emplazamiento de réplicas de bloques tiene dos propósitos: maximizar la fiabilidad y disponibilidad de los datos y maximizar la utilización del ancho de banda de la red. Se debe desplegar también réplicas a lo largo de las subredes para asegurar que algunas réplicas del bloque permanezcan disponibles incluso si una subred entera se daña o se desconecta.
3. Creación, replicación y rebalanceo
   Cuando el maestro crea un bloque, este elige donde colocar las réplicas vacías inicialmente. Se consideran varios factores:
   1. Las réplicas nuevas se pueden colocar en servidores de bloques donde la utilización del espacio del disco sea menor.
   2. Se debería limitar el número de creaciones recientes sobre cada servidor de bloques.
   3. Como se dijo anteriormente, se desea desplegar réplicas de  bloques a lo largo de las subredes.

   El maestro replica un bloque en cuanto el número de réplicas disponibles esta por debajo de un umbral especificado por el usuario.
   Cada bloque que necesite ser replicado se le asigna una prioridad basada en varios factores.
   El maestro elige el bloque con mayor prioridad y se “clona” ordenando a alguno servidor de bloques que copie los datos del bloque directamente de una réplica válida existente. La réplica válida se ubica siguiendo objetivos similares a los de creación.
   El maestro balancea periódicamente las réplicas: examina la distribución de réplicas actual y mueve las réplicas para mejorar el espacio del disco y balancear la carga. El criterio de emplazamiento de la nueva réplica es similar a lo discutido anteriormente. El maestro debe también elegir que réplica existente borrar.

4. Recogida de basura
   Después de que un fichero es borrado, GFS no recupera la disponibilidad de almacenamiento físico.
   El fichero es renombrado con un nombre oculto que incluye la etiqueta de borrado.
   Durante un escaneo regular del maestro del espacio de nombre del sistema de ficheros, se borra cualquier fichero oculto que fue borrado hace más de tres días.
   Cuando el fichero oculto es eliminado del espacio de nombres, sus metadatos de memoria son borrados.
   En un escaneo regular similar del espacio de nombres de los bloques, el maestro identifica los bloques “huérfanos” y borra los metadatos de estos bloques.
   La recogida de basura con recuperación de almacenamiento ofrece varias ventajas sobre el borrado instantáneo:
   1. Es simple y fiable en un sistema distribuido a gran escala donde los fallos de los componentes son comunes.
   2. El escaneo del espacio de nombres y apretón de manos con los servidores de bloques se realiza en segundo plano.
   3. El retardo en la recuperación del espacio proporciona seguridad contra accidentes o borrados irreversibles.

   La principal desventaja es que el retardo a veces dificulta el esfuerzo del usuario para aprovechar el uso cuando el almacenamiento es ajustado. Los usuarios tienen permitido aplicar diferentes políticas de recuperación y replicación en distintas partes del espacio de nombres.

5. Borrado de réplicas antiguas
   Las réplicas de bloques pueden volverse antiguas si un servidor de bloques falla y pierde mutaciones de un bloque mientras está caído. Para cada bloque, el maestro mantiene un número de versión de bloque para distinguir entre las réplicas actuales y las antiguas.
   Cuando el maestro otorga una actualización de un bloque, este incremente su número de versión de bloque e informa a las réplicas actuales. El maestro detectará que este servidor de bloques tiene una réplica antigua cuando el servidor de bloque se reinicie y le informe de su subconjunto de bloques y sus números de versión asociados.
   El maestro elimina las réplicas antiguas en la recogida de basura.

Vía (mi bitácora) ahornero.com.

Más información (inglés): GoogleLabs.