11.1.

2 Sistemas de archivo distribuido basados en clster 496

El NFS es un ejemplo tpico de muchos sistemas de archivo distribuidos, los
cuales generalmente se organizan con arreglo a una arquitectura clienteservidor tradicional.
Esta arquitectura a menudo se mejora agrupando los servidores con pocas
diferencias. Dichos servidores a menudo se utilizan en aplicaciones en
paralelo, no sorprende que sus sistemas de archivo asociados se ajusten
como corresponde.

Una tcnica muy conocida es desplegar tcnicas de distribucin de

archivos, mediante las cuales un archivo se distribuye a travs de
mltiples servidores, distribuyendo un archivo grande entre mltiples
servidores, ya que es posible buscar sus diferentes partes en paralelo.
Desde luego, semejante organizacin funciona bien slo si la
aplicacin se organiza de tal forma que el acceso a los datos en
paralelo tenga sentido. Esto requiere generalmente que los datos, tal
como se guardan en el archivo, tengan una estructura muy regular,
por ejemplo, una matriz (densa).
Para aplicaciones de propsito general, o para aquellas con tipos
irregulares o muchos tipos de estructuras de datos, la distribucin de
archivos puede no ser una herramienta efectiva. En esos casos, a
menudo es ms conveniente particionar el sistema de archivo en su
totalidad y simplemente guardar los diferentes archivos en diferentes
servidores, pero no particionar un solo archivo a travs de mltiples
servidores. La diferencia entre estos dos mtodos se muestra en la
figura 11-4.

Ms interesantes son los casos en que se debe organizar un sistema

de archivos distribuidos para grandes centros de datos, tales como
los utilizados por compaas como Amazon y Google. Estas
compaas ofrecen servicios a clientes web cuyo resultado son
lecturas y actualizaciones de un nmero masivo de archivos
distribuidos a travs de literalmente decenas de miles de
computadoras [vea tambin Barroso y cols. (2003)]. En tales
entornos, la suposiciones tradicionales en relacin con sistemas de
archivo distribuidos ya no son vlidas. Por ejemplo, es de esperarse
que en cualquier momento falle una computadora.

Para abordar estos problemas, Google, por ejemplo, desarroll su propio

sistema de archivo Google (GFS, por sus siglas en ingls), cuyo diseo se
describe en Ghemawat y colaboradores. Los archivos Google tienden a ser
muy grandes, comnmente de varios gigabytes, y cada uno contiene

muchos objetos ms pequeos. Adems, las actualizaciones de los archivos

generalmente se realizan anexando datos en lugar de sobreescribir algunas
partes de un archivo. Estas observaciones, junto con el hecho de que las
fallas de servidor son la norma en lugar de la excepcin, llevaron a la
construccin de grupos de servidores tal como se muestra en la figura 11-5.

Cmo funciona el GFS (Google File System)?

1. Cada grupo de GFS se compone de un servidor maestro junto con
mltiples servidores fragmentados.
2. Cada archivo GFS es dividido en fragmentos de 64 Mbytes cada uno.
3. Los fragmentos se distribuyen a travs de los servidores llamados
fragmentados.
Diferencia entre GFS maestro y cliente:
GFS maestro
1. Se contacta slo para recabar
informacin de metadatos.

Cliente GFS
2. Transfiere un nombre de
archivo y un ndice de
fragmento al maestro, y
espera una direccin de
contacto para el fragmento.
3. La direccin de contacto
contiene toda la informacin
necesaria para acceder al
servidor fragmentado correcto
y obtener el fragmento de
archivo requerido.

4. Mantiene un espacio de
nombre, adjunto a un mapeo
desde un nombre de archivo
hasta los fragmentos.
5. Cada fragmento lleva un
identificador asociado para
que el servidor fragmentado
pueda buscarla.
6. No pierde de vista la
ubicacin de un fragmento.
7. Los fragmentos se replican en
prevencin de fallas de
manejador, pero nada ms
para eso.
Una caracterstica interesante es que el GFS maestro no intenta llevar la
cuenta precisa de las ubicaciones de los fragmentos. En cambio, de vez en

cuando se pone en contacto con los servidores fragmentados para ver qu

fragmentos tienen guardados.
Ventaja
Principalmente la simplicidad ya que el servidor maestro controla la
asignacin de los fragmentos a los servidores fragmentados. Adems, stos
llevan la cuenta de lo que tienen guardado. Por consiguiente, una vez que el
servidor maestro obtiene las ubicaciones de los fragmentos, tiene una
imagen precisa de dnde estn guardados los datos.
Por qu se agranda este esquema?
Un importante tema de diseo es que el servidor maestro est en control en
gran medida, pero que no forma un cuello de botella a causa del trabajo que
necesita realizar.
Medidas para manejar la escalabilidad
1. Que la mayor parte del trabajo sea realizada por servidores
fragmentados. Cuando un cliente necesita acceder a datos, se pone
en contacto con el servidor maestro para indagar qu servidores
contienen los datos. Despus de eso, se comunica slo con los
servidores fragmentados. Los fragmentos se replican de acuerdo con
un esquema de respaldo primario.
2. El nombre de espacio (jerrquico) para archivos, se implementa con
una tabla de nivel nico simple, en la cual los nombres de ruta se
dirigen a metadatos (equivalentes a los nodos de los sistemas de
archivo tradicionales). Adems, toda la tabla se mantiene en la
memoria principal, junto con la direccin de los archivos ubicados en
las secciones.