Siguiendo con nuestro artículo del sistema de ficheros de Google, veremos como lo tiene estructurado. Como se ha dicho, Google organizó GFS en forma de grupos de máquinas, llamadas en el mundo informático “clusters”. Un cluster es simplemente una red de ordenadores. Cada cluster puede contener cientos o miles de máquinas. En estos cluster GFS hay tres tipos de equipos, que son los clientes, los servidores maestros y los llamados chunkservers.
En el entorno de Google y sistema de ficheros, el término clientes se refiere a cualquier entidad que realiza una petición de un fichero. Las peticiones pueden ir desde recuperar y manipular ficheros existentes para crear nuevos ficheros de sistema. Los clientes pueden ser otros ordenadores o aplicaciones de ordenador. Se puede pensar en ellos como verdaderos clientes del sistema GFS.
El servidor maestro actúa como un coordinador para el cluster. Las tareas del equipo maestro incluyen mantener un registro de las operaciones, lo cual mantiene un seguimiento de las actividades del cluster que tiene este equipo. Los registros de operación ayuda a mantener las interrupciones del servicio a un nivel bajo – si el servidor maestro sea queda inactivo, un servidor secundario que ha monitorizado las operaciones de registro, puede tomar su lugar.
El servidor maestro también sigue la pista de los meta datos, que la información que describe las partes de ficheros. Estos meta datos le dicen al servidor maestro a donde pertenecen los trozos de fichero y a donde corresponden en un fichero entero. Al comienzo, el equipo maestro pone todos los chunkservers en el cluster.
Estos servidores responden diciéndole al servidor maestro los contenidos de sus inventarios. Desde ese momento, el servidor maestro hace un seguimiento de los trozos dentro del cluster.
Solo hay un servidor maestro activo dentro del cluster, aunque cada cluster tiene varias copias del servidor maestro en caso de que haya un fallo de hardware. Se podría pensar que esto podría formar un cuello de botellas al tener este maestro que coordinar miles de ordenadores.
El sistema GFS se hace cargo de esta solución manteniendo los mensajes que el servidor maestro manda y envía, de un tamaño muy pequeño. Lo cierto es que el servidor maestro no manejar realmente datos de ficheros, ya que esto se lo deja a los chunkservers. Se puede decir que los chunkservers son los caballos de trabajo del sistema. Son responsables de almacenar los trozos de 64 MB. No envían trozos a los servidores maestros. En lugar de eso, envían trozos requeridos directamente al cliente.
El sistema GFS copia cada trozo de los ficheros varias veces y los almacena en diferentes chunkservers. Cada copia se llama una réplica, y por defecto el sistema hace tres réplicas por cada trozo de fichero. Los usuarios pueden cambiar esta configuración y hacer más o menos réplicas si lo desea. ¿Cómo funcionan estos elementos todos juntos durante uno de los procesos en el sistema? Las peticiones de ficheros necesitan seguir un flujo de trabajo estándar.
Una petición de lectura es simple – el cliente envía una petición al servidor maestro para averiguar donde el cliente puede encontrar un fichero en particular en el sistema. El servidor responde con la localización de la réplica primaria de su respectivo trozo. La réplica primaria mantiene prestada una copia para el trozo en cuestión del servidor maestro.
Si ninguna réplica tiene uno de estos trozos “prestados”, el servido maestro designa un trozo como primario. Lo hace comparando la dirección IP del cliente a las direcciones de los chunkservers que contienen las réplicas. El servidor maestro elige el chunkserver más cercano y ese trozo se vuelve el primario. El cliente entonces contacta al chunkserver apropiado directamente, el cual envía la réplica al cliente.
Las peticiones de escritura son algo más complicadas. El cliente sigue enviando la petición al servidor maestro, el cual contesta con la localización de las peticiones primaria y secundaria. El cliente almacena esta información en la memoria de caché. De esta manera, si el cliente necesita referirse a la misma réplica después, puede saltarse el servidor maestro. Si la réplica primaria se vuelve indisponible o la réplica cambia, el cliente tendrá que consultar al servidor maestro de nuevo antes de contactar con el chunkserver.
El cliente entonces envía los datos escritos a todas las réplicas, empezando con la réplica más cercana y finalizando con el más lejano. No importa si la réplica más cercana es primaria o secundaria. Google compara este método de entrega de datos a una cola.
Una vez que las réplicas reciben los datos, la réplica primaria empieza a asignar números de serie consecutivos de cada cambio al fichero. Los cambios se llaman mutaciones. Los números de serie le dicen a las réplicas como ordenar cada mutación. El primario entonces aplica las mutaciones en un orden de secuencia a sus propios datos. Entonces envía una petición escrita a las réplicas secundarias, las cuales siguen el mismo proceso de aplicación.
Si todo funciona como debe, todas las réplicas en el cluster insertan los nuevos datos. Las réplicas secundarias contestar al primario una vez que el proceso se ha acabado.
Mientras todo esto ocurre, la réplica primaria reporta información al cliente. Si el proceso es satisfactorio, todo acaba aquí. Si no lo hace, la réplica primaria le dice al cliente lo que ha ocurrido. Por ejemplo, su una segunda réplica falla al actualizarse con una mutación en particular la réplica primaria se lo notifica al cliente y lo vuelve a intentar varias veces.
Si la réplica secundaria no se actualiza correctamente. La primaria le dice a la secundaria que empiece desde el principio en el proceso de escritura. Si eso no funciona, el servidor maestro identificará la réplica afectada como inservible.
