Patrik Samuel Sacbaja Chex carne 200750174 Tarea 2 MIA (Lab)

Sistema de ficheros Google (GFS)

El sistema de ficheros Google (GFS) se ha diseado 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 diseo ha estado dirigido por observaciones de la carga de trabajo y entorno tecnolgico de Google.

Interfaz. La API
GFS proporciona una interfaz para el sistema de archivos, aunque no implementa un API estndar tal como POSIX. Las operaciones ms comunes permitirn crear, borrar, abrir, borrar, leer y escribir ficheros. Adems, GFS tiene operaciones de duplicacin y de adicin de informacin a ficheros.

La arquitectura del sistema

Uncluster GFS consta de un nico maestro y varios servidores de bloques a los que acceden mltiples clientes. Los ficheros estn divididos en bloques de un tamao fijo . Por fiabilidad, cada loque esta replicado en varios servidores de bloques. Por defecto, se lmacenan tres replicas. stado de a cuestin . El servidor maestro mantiene metadatos del sistema de ficheros y controla actividades del sistema.

 El cdigo cliente GFS insertado en cada aplicacin 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 aplicacin. Ni los clientes ni los servidores de bloques mantienen los ficheros de datos en la cache. Un solo servidor maestro Tener un nico servidor maestro simplifica enormemente el diseoy posibilita al maestro hacer sofisticados emplazamientos de bloques y decisiones de replicacin utilizando informacin global.

A continuacin se explican las interacciones que hay que realizar en una operacin de lectura: 1. El cliente traduce el nombre del fichero y el desplazamiento de bytes especificado por la aplicacin en un ndice de bloque dentro del archivo. 2. Enva al maestro una peticin que contiene el nombre del archivo y el ndice del bloque. 3. El maestro responde con el correspondiente identificador de bloque y la localizacin de la rplica. 4. El cliente almacena en la cach esta informacin usando el nombre del archivo y el ndice de bloque como clave. 5. El cliente enva una peticin a una de las rplicas, normalmente a la ms cercana. El tamao de bloque El tamao de bloque es uno de los parmetros de diseo clave. Google utiliza un tamao de bloque de 64 Mb. Un tamao 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 peticin al maestro para obtener la informacin de localizacin del bloque. 2. En un bloque grande, es ms probable que el cliente ejecute varias operaciones, as que se puede reducir las conexiones manteniendo una Estado de la cuestin conexin TCP persistente con el servidor de bloques durante un amplio periodo de tiempo. 3. Se reduce el tamao de los metadatosalmacenados en el servidor maestro. Por otro lado, un tamao de bloque grande puede tener desventajas: 1. Un fichero pequeo tiene un pequeo nmero de bloques, quizs solo uno. El servidor de bloques que almacena estos bloques podra convertirse en un punto crtico si varios clientes estn accediendo a un mismo archivo. Este

problema se puede arreglar almacenando tales ficheros con un mayor factor de replicacin. Otra solucin 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 localizacin de cada rplica de un bloque. Los dos primeros tipos se mantienen persistentes registrando los cambios mediante una operacin log. Por el contrario, no se almacena la informacin de localizacin de los bloques persistentemente. Todos los metadatos se almacenan en memoria para que las operaciones sean rpidas. Una restriccin fundamental es que el nmero 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 aadir memoria extra al maestro es un pequeo precio a pagar por la simplificacin, fiabilidad, rendimiento y flexibilidad que se gana almacenando metadatos en memoria. Inicialmente se intent mantener la informacin de localizacin de los bloques de manera persistente en el maestro, pero se decidi que era ms simple pedir los datos a los servidores de bloque al iniciar la conexin y posteriormente hacerlo de forma peridica. La operacin log contiene un registro histrico de los cambios crticos en los metadatos. Puesto que el registro histrico de la operacin log es crtico, se debe almacenar con fiabilidad, por lo que se replica en varias mquinas remotas. El maestro recupera el estado del fichero de archivos repitiendo los cambios registrados en el log.

COMENTARIO PERSONAL
El systema de archivos de google parece tener varios componentes que fallan continuamente, pues como se puede leer en su descripcion aunque este este diseado para ello creo que tendria serias desventajas, por otro lado al parecer que aunque almacena grandes grupos de ficheros, el numero queestos grupos se reduce considerablemente, tambien se puede mencionar que el sistema como tal no esta lo suficientemente optimizado pues su carga de trabajo deberia relizar muchas escrituras secuenciales. Por otro lado una de las caracteristicas que llaman mucho la atencion es que el sistema implementa eficientemente un mecanismo de acceso concurrente en la escritura de ficheros para multiples usuarios. En conclusion opino que por ser un sistema de cierta forma nuevo aun no es lo suficientemente optimo y confiable.