Sistemas de Archivos Distribuidos

(1)

Sistemas de Archivos

Distribuidos

Conceptos básicos

Sistema de archivos distribuido (SAD)

• Objetivo principal: compartir datos entre

usuarios ofreciendo transparencia

• Objetivos secundarios:

• disponibilidad

• rendimiento (debería ser comparable al de un sistema tradicional)

(2)

Conceptos básicos

Modelo cliente-servidor

• Servicios del sistema de archivos. Operaciones proporcionadas a los clientes

• Servidores del sistema de archivos. Procesos de usuario o del sistema que ofrecen los servicios correspondientes (servidores multithread)

Transparencia

• Mismas operaciones para acceso locales y remotos. • Imagen única del sistema de archivos.

Rendimiento. Un SAD tiene sobrecargas adicionales.

• Red de comunicación, protocolos, posible necesidad de realizar más copias, etc.

Facilidad de crecimiento. Eliminar los cuellos de botella Tolerancia a fallos: replicación, funcionamiento degrado.

Componentes de un SAD

Programa

de usuario de usuarioPrograma de usuarioPrograma

Interfaz del SAD

Red

Servidor de directorios

(3)

Estructura de un SAD

Cliente Servidor Red de interconexión Cliente Servidor

Servicio de directorio

Se encarga de la traducción del nombres de

usuario a nombres internos

Directorio: relaciona de forma única nombres de

archivos con nombres internos

Dos opciones:

• Los directorios son objetos independientes gestionados por un servidor de directorios (SD) • Los directorios son archivos especiales. Servidor de

(4)

básicos

Sistema operativo distribuido: servicio uniforme de nombres para todos los objetos

En muchos casos: diferentes esquemas para diferentes objetos (archivos). Varios servidores de nombres

Transparencia de la posición: el nombre del objeto no permite obtener directamente el lugar donde está almacenado

Independencia de la posición: el nombre no necesita ser cambiado cuando el objeto cambia de lugar.

• Asociación entre nombre y posición dinámica • Propiedad más exigente que la transparencia

Facilidad de crecimiento Replicación

Nombres orientados al usuario

Nombrado de dos niveles

Nombres de usuario

• Generalmente el espacio de nombres es jerárquico • Tres alternativas

• Máquina:nombre de archivo

– Ni transparencia, ni independencia

• Montar un sistema de archivos remoto sobre la jerarquía local (NFS)

– Espacio de nombres diferente en cada máquina

• Único espacio de nombres en todas las máquinas

– Proporciona transparencia

Nombres internos: identificador único de archivo

utilizado por el sistema

(5)

Servicio de archivos

Se encarga de la gestión de los archivos y

del acceso a los datos

Aspectos relacionados

• Semántica de coutilización

• Métodos de acceso

• Cache de bloques

• El problema de la coherencia de cache

• Métodos para mejorar el rendimiento

Semánticas de coutilización

Sesión: serie de accesos que realiza un cliente entre un openy un close

La semántica de coutilización especifica el efecto de varios procesos accediendo de forma simultánea al mismo archivo

Semántica UNIX

• Una lectura ve los efectos de todas las escrituras previas • El efecto de dos escrituras sucesivas es el de la última de ellas • Los procesos pueden compartir el puntero de la posición • Difícil de implementar en sistemas distribuidos

(6)

Semánticas de coutilización

Semántica de sesión:

• Cambios a un archivo abierto son visibles únicamente en el proceso (nodo) que modificó el archivo

• Una vez cerrado el archivo, los cambios son visibles sólo en sesiones posteriores

• Múltiples imágenes del archivo

• Dos sesiones sobre el mismo archivo que terminan concurrentemente: la última deja el resultado final • Si dos procesos quieren compartir datos deben abrir

y cerrar el archivo para propagar los datos

• No adecuado para procesos que acceden de forma concurrente a un archivo

• No existen punteros compartidos

Métodos de acceso a archivos

Modelo carga/descarga

• Transferencias completas del archivo

• Localmente se almacenan en memoria o discos locales • Normalmente utilizan semántica de sesión

• Eficiencia en las transferencias • Llamada open con mucha latencia • Múltiples copias de un archivo

Modelo de servicios remotos

• El servidor debe proporcionar todas las operaciones sobre el archivo.

• Acceso por bloques • Modelo cliente/servidor

Empleo de caché en el cliente

(7)

Tipos de servidores

Servidores con estado

• Cuando se abre un archivo, el servidor

almacena información y da al cliente un

identificador único a utilizar en las posteriores

llamadas

• Cuando se cierra un archivo se libera la

información

Servidores sin estado

• Cada petición es autocontenida (archivo y

posición)

Tipos de servidores

Ventajas de los servidores con estado

• Mensajes de petición más cortos

• Mejor rendimiento (se mantiene información en memoria) • Facilita la lectura adelantada. El servidor puede analizar el

patrón de accesos que realiza cada cliente

• Es necesario en invalidaciones iniciadas por el servidor

Ventajas de los servidores sin estado

• Más tolerante a fallos

• No son necesarios open y close. Se reduce el nº de mensajes • No se gasta memoria en el servidor para almacenar el estado

(8)

Caché de bloques

El empleo de cache de bloques permite mejorar

el rendimiento

• Explota el principio de proximidad de referencias

• Proximidad temporal • Proximidad espacial

• Lecturas adelantadas

• Mejora el rendimiento de las operaciones de lectura, sobre todo si son secuenciales

• Escrituras diferidas

• Mejora el rendimiento de las escrituras

Otros tipos de caché

• Caché de nombres

• Caché de metadatos del sistema de archivos

Localización de las cache en un

SAD

Caché en los servidores

• Reducen los accesos a disco

Caché en los clientes

• Reducen el tráfico por la red • Reducen la carga en los servidores • Mejora la capacidad de crecimiento • Dos posibles localizaciones

• En discos locales

– Más capacidad, – Más lento

– No volátil, facilita la recuperación

• En memoria principal

– Menor capacidad – Más rápido

(9)

Funcionamiento de una caché de

bloques

Cache Cliente Cache Servidor Disco Proceso de usuario read() Buscar bloque. Si no está, reservar uno. read() Buscar bloque. Si no está, reservar uno. read() datos

Tamaño de la unidad de caché

Mayor tamaño puede incrementar la tasa de

aciertos y mejorar la utilización de la red pero

• Aumentan los problemas de coherencia

Depende

de

las

características

de

las

aplicaciones

En memoria caché grandes

• Es beneficioso emplear bloques grandes (8 KB y más)

En memorias pequeñas

(10)

Políticas de actualización

Escritura inmediata (write-through)

• Buena fiabilidad

• En escrituras se obtiene el mismo rendimiento que en el modelo de accesos remotos

• Las escrituras son más lentas

Escritura diferida (write-back)

• Escrituras más rápidas. Se reduce el tráfico en la red • Los datos pueden borrarse antes de ser enviados al

servidor • Alternativas

• Volcado (flush) periódico (Sprite) • Write-on-close

Problema de la coherencia de

caché

El uso de caché en los clientes de un sistema de

archivos introduce el problema de la coherencia

de caché:

• Múltiples copias.

El problema surge cuando se coutiliza un

archivo en escritura:

• Coutilización en escritura secuencial

• Típico en entornos y aplicaciones distribuidas.

• Coutilización en escritura concurrente

(11)

Soluciones al problema de la

coherencia

No emplear caché en los clientes.

• Solución trivial que no permite explotar las ventajas del uso de caché en los clientes (reutilización, lectura adelantada y escritura diferida)

No utilizar caché en los clientes para datos

compartidos en escritura (Sprite).

• Accesos remotos sobre una única copia asegura semántica UNIX

Empleo de protocolos de coherencia de caché

Caché en los clientes vs. acceso

remoto

Rendimiento cercano al de un sistema

centralizado

Menor carga en el servidor y en la red. Se

permiten transferencias más grandes por

la red

Facilita el crecimiento proporcional del

rendimiento del sistema

Dificultades

relacionadas

con

el

mantenimiento de la coherencia

(12)

NETWORK FILE SYSTEM

(NFS)

NFS: Network File System

Implementación y especificación de un software de sistema para acceso a archivos remotos

Diseñado para trabajar en entornos heterogéneos (diferentes máquinas, sistemas operativos, ...)

La independencia se consigue mediante el uso de las RPC construidas sobre el protocolo XDR (eXternal Data Representation)

Las diferentes máquinas montan un directorio remoto en el sistema de archivos local

• El espacio de nombres es diferente en cada máquina

• El montado no es transparente, debe proporcionarse el nombre de la máquina remota

(13)

Montado en NFS

Establece una conexión lógica entre el servidor y el cliente La máquina A exporta /usr y /bin En la máquina B:

mount maquinaA:/usr /usr

Montado en NFS

(14)

Protocolo NFS

Ofrece un conjunto de RPC para realizar

operaciones sobre archivos remotos

• Búsqueda de un archivo en un directorio • Lectura de entradas de directorio

• Manipulación de enlaces y directorios • Acceso a los atributos de un archivo • Lectura y escritura de archivos

Los servidores de NFS no almacenan estado

• Operaciones autocontenidas

El protocolo no ofrece mecanismos de control

de concurrencia para asegurar una semántica

UNIX

(15)

Arquitectura de NFS

Capa de llamada al sistema Capa del sistema de

archivos virtual S.O. Local Cliente NFS Disco Local RPC/XDR

Capa del sistema de archivos virtual S.O. Local Servidor NFS Disco Local RPC/XDR RED CLIENTE SERVIDOR

Traducción de nombres

VFS almacena una entrada por cada archivo

abierto (vnode)

Cada vnode apunta a un inodo local o a un

inodo remoto

El cliente realiza la traducción de un nombre

(path) componente a componente. Cuando un

vnode

apunta a inodo remoto la búsqueda se

realiza en el servidor (un componente cada vez)

El cliente almacena una cache de nombres

para acelerar las traducciones (cache de

atributos)

(16)

Acceso a los archivos

Las transferencias se realizan en bloques de 8 KB Los bloques se almacenan en la cache de los clientes Los clientes realizan lecturas adelantadas de un bloque Las escrituras se realizan localmente. Los bloques se envían al servidor cuando se llena un bloque de 8 KB o cuando se cierra el archivo

Problemas de coherencia de cache (no se asegura la semántica UNIX)

¿Cómo intenta conseguir una semántica UNIX?

• Cuando un archivo se abre en un cliente se comprueba en el servidor si la información se ha modificado

• Cuando se accede a un bloque que lleva más de 3s en la cache del cliente se valida

Protocolo de montado

program MOUNT_PROGRAM { version MOUNT_V3 { void MOUNTPROC3_NULL(void) = 0; mountres3 MOUNTPROC3_MNT(dirpath) = 1; mountlist MOUNTPROC3_DUMP(void) = 2; void MOUNTPROC3_UMNT(dirpath) = 3; void MOUNTPROC3_UMNTALL(void) = 4; exports MOUNTPROC3_EXPORT(void) = 5; } = 3; } = 100005;

(17)

Protocolo NFS

program NFS_PROGRAM { version NFS_V3 { void NFSPROC3_NULL(void) = 0; GETATTR3res NFSPROC3_GETATTR(GETATTR3args) = 1; SETATTR3res NFSPROC3_SETATTR(SETATTR3args) = 2; LOOKUP3res NFSPROC3_LOOKUP(LOOKUP3args) = 3; ACCESS3res NFSPROC3_ACCESS(ACCESS3args) = 4; READLINK3res NFSPROC3_READLINK(READLINK3args) = 5; READ3res NFSPROC3_READ(READ3args) = 6; WRITE3res NFSPROC3_WRITE(WRITE3args) = 7; CREATE3res NFSPROC3_CREATE(CREATE3args) = 8; MKDIR3res NFSPROC3_MKDIR(MKDIR3args) = 9; SYMLINK3res NFSPROC3_SYMLINK(SYMLINK3args) = 10; MKNOD3res NFSPROC3_MKNOD(MKNOD3args) = 11; REMOVE3res NFSPROC3_REMOVE(REMOVE3args) = 12; RMDIR3res NFSPROC3_RMDIR(RMDIR3args) = 13; RENAME3res NFSPROC3_RENAME(RENAME3args) = 14; LINK3res NFSPROC3_LINK(LINK3args) = 15; READDIR3res NFSPROC3_READDIR(READDIR3args) = 16; READDIRPLUS3res FSPROC3_READDIRPLUS(READDIRPLUS3args) = 17; FSSTAT3res NFSPROC3_FSSTAT(FSSTAT3args) = 18; FSINFO3res NFSPROC3_FSINFO(FSINFO3args) = 19; PATHCONF3res NFSPROC3_PATHCONF(PATHCONF3args) = 20; COMMIT3res NFSPROC3_COMMIT(COMMIT3args) = 21; } = 3; } = 100003;

LOOKUP3res NFSPROC3_LOOKUP(LOOKUP3args)

struct LOOKUP3args { diropargs3 what; }; struct diropargs3 { nfs_fh3 dir; filename3 name; };

union LOOKUP3res switch (nfsstat3 status) { case NFS3_OK: LOOKUP3resok resok; default: LOOKUP3resfail resfail; }; struct LOOKUP3resok { nfs_fh3 object; post_op_attr obj_attributes; post_op_attr dir_attributes; };

(18)

WRITE3res NFSPROC3_WRITE(WRITE3args)

struct WRITE3args { nfs_fh3 file; offset3 offset; count3 count; stable_how stable; opaque data<>; };

union WRITE3res switch (nfsstat3 status) { case NFS3_OK: WRITE3resok resok; default: WRITE3resfail resfail; }; struct WRITE3resok { wcc_data file_wcc; count3 count; stable_how committed; writeverf3 verf; };

READ3res NFSPROC3_READ(READ3args)

struct READ3args { nfs_fh3 file; offset3 offset; count3 count; };

union READ3res switch (nfsstat3 status) { case NFS3_OK: READ3resok resok; default: READ3resfail resfail; }; struct READ3resok { post_op_attr file_attributes; count3 count; bool eof; opaque data<>; };

(19)

Comparación

Google File

System (GFS)

Paper:

The Google File System,

Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung https://research.google.com/archive/gfs.html

(20)

Overview

NFS Introduction-Design Overview Architecture System Interactions Master Operations Fault tolerance Conclusion

NFS

RPC’s Low performance Security Issues

(21)

INTRODUCTION

Need For GFS:

Large Data Files

Scalability

Reliability

Automation

Replication of data

Fault Tolerance

DESIGN OVERVIEW:

Component’s Monitoring Storing of huge data Reading and writing of data

Well defined semantics for multiple clients Importance of Bandwidth

Assumptions:

Interface:

Not POSIX compliant Additional operations

o Snapshot

(22)

Single Master

Multiple Chunk Servers

Multiple clients

Cluster Computing

(23)

SINGLE MASTER , CHUNK SIZE & META DATA

Single Master:

Minimal Master Load. Fixed chunk Size.

The master also predicatively provide chunk locations

immediately following those requested by unique id.

Chunk Size :

64 MB size.

Read and write operations on same chunk.

Reduces network overhead and size of metadata in the

master.

Metadata :

Types of Metadata:

o

File and chunk namespaces

o

Mapping from files to chunks

o

Location of each chunks replicas

In-memory data structures:

o

Master operations are fast.

o

Periodic scanning entire state is

easy and efficient

(24)

Chunk Locations:

o

Master polls chunk server for the

information.

o

Client request data from chunk

server.

Operation Log:

o

Keeps track of activities.

o

It is central to GFS.

o

It stores on multiple remote

locations.

System Interactions:

Leases And Mutation

order:

o Leases maintain consistent mutation order across the replicas.

o Master picks one replica as primary.

o Primary defines serial order for mutations.

o Replicas follow same serial order.

o Minimize management overhead at the master.

(25)

Atomic Record Appends:

o GFS offers Record Append .

o Clients on diﬀerent machines append to the same file concurrently.

o The data is written at least once as an atomic unit.

Snapshot:

o It creates quick copy of files or a directory . o Master revokes lease for that file o Duplicate metadata

o On first write to a chunk after the snapshot operation

o All chunk servers create new chunk o Data can be copied locally

MASTER OPERATION

Namespace Management and Locking:

o GFS maps full pathname to Metadata in a table. o Each master operation acquires a set of locks.

o Locking scheme allows concurrent mutations in same

directory.

o Locks are acquired in a consistent total order to prevent

deadlock.

Replica Placement:

o Maximizes reliability, availability and network bandwidth

utilization.

(26)

Create:

o Equalize disk utilization.

o Limit the number of creation on chunk server. o Spread replicas across racks.

Re-replication:

o Re-replication of chunk happens on priority.

Rebalancing:

o Move replica for better disk space and load balancing.

o Remove replicas on chunk servers with below average free space.

Garbage Collection:

o

Makes system Simpler and more reliable.

o

Master logs the deletion, renames the file to a

hidden name.

Stale Replica detection:

o

Chunk version number identifies the stale replicas.

(27)

FAULT TOLERANCE

High availability: o Fast recovery. o Chunk replication. o Shadow Masters. Data Integrity:

o Check sum every 64 kb block in each chunk.

CONCLUSION

GFS meets Google storage requirements: Incremental growth

Regular check of component failure Data optimization from special operations Simple architecture

(28)

Hadoop Distributed File

System (HDFS)

What’s HDFS

A distributed file system that is fault tolerant,

scalable and extremely easy to expand. Idea

based on GFS.

The primary distributed storage for Hadoop

applications.

Provides interfaces for applications to move

themselves closer to data.

Designed to ‘just work’, however a working

knowledge

helps

in

diagnostics

and

(29)

Components of HDFS

There are two (and a half) types of

machines in a HDFS cluster

NameNode :– is the heart of an HDFS

filesystem, it maintains and manages the

file system metadata. E.g; what blocks

make up a file, and on which datanodes

those blocks are stored.

DataNode :- where HDFS stores the

actual data, there are usually quite a few

of these.

57 Introduction to HDFS

(30)

HDFS also has a bunch of unique features that make it ideal for distributed systems:

Failure tolerant - data is duplicated across multiple

DataNodes to protect against machine failures. The default is a replication factor of 3 (every block is stored on three

machines).

Scalability - data transfers happen directly with the

DataNodes so your read/write capacity scales fairly well with the number of DataNodes

Space - need more disk space? Just add more DataNodes and re-balance

Industry standard - Other distributed applications are built on top of HDFS (HBase, Map-Reduce)

HDFS is designed to process large data sets with write-once-read-many semantics, it is not for low latency access

HDFS – Data Organization

Each file written into HDFS is split into

data blocks

Each block is stored on one or more

nodes

Each copy of the block is called replica

Block placement policy

• First replica is placed on the local node

• Second replica is placed in a different rack

• Third replica is placed in the same rack as the

(31)

Read Operation in HDFS

(32)

Authentication to Hadoop

• Simple – insecure way of using OS username to determine hadoop identity

• Kerberos – authentication using kerberos ticket • Set by

hadoop.security.authentication=simple|kerberos

File and Directory permissions are same like in

POSIX

• read (r), write (w), and execute (x) permissions • also has an owner, group and mode

• enabled by default (dfs.permissions.enabled=true)

ACLs are used for implemention permissions that

differ from natural hierarchy of users and groups

• enabled by dfs.namenode.acls.enabled=true 63 Introduction to HDFS

HDFS Configuration

HDFS Defaults Block Size – 64 MB Replication Factor – 3 Web UI Port – 50070

HDFS conf file -/etc/hadoop/conf/hdfs-site.xml

<property> <name>dfs.namenode.name.dir</name> <value>file:///data1/cloudera/dfs/nn,file:///data2/cloudera/dfs/nn</value> </property> <property> <name>dfs.blocksize</name> <value>268435456</value> </property> <property> <name>dfs.replication</name> <value>3</value> </property> <property> <name>dfs.namenode.http-address</name> <value>itracXXX.cern.ch:50070</value> </property>

(33)

Interfaces to HDFS

Java API

(DistributedFileSystem)

C wrapper

(libhdfs)

HTTP protocol

WebDAV protocol

Shell Commands

However the command line is one of

the simplest and most familiar

Introduction to HDFS 65

HDFS – Shell Commands

There are two types of shell commands

User Commands

hdfs dfs

– runs filesystem commands on the

HDFS

hdfs fsck

– runs a HDFS filesystem checking

command

Administration Commands

hdfs dfsadmin

– runs HDFS administration

(34)

List directory contents

Display the disk space used by files

67 Introduction to HDFS hdfs dfs –ls hdfs dfs -ls / hdfs dfs -ls -R /var hdfs dfs -du -h / hdfs dfs -du /hbase/data/hbase/namespace/ hdfs dfs -du -h /hbase/data/hbase/namespace/ hdfs dfs -du -s /hbase/data/hbase/namespace/

HDFS – User Commands (dfs)

Copy data to HDFS

Copy the file back to local filesystem

hdfs dfs -mkdir tdata hdfs dfs -ls

hdfs dfs -copyFromLocal tutorials/data/geneva.csv tdata hdfs dfs -ls –R

cd tutorials/data/

hdfs dfs –copyToLocal tdata/geneva.csv geneva.csv.hdfs md5sum geneva.csv geneva.csv.hdfs

(35)

HDFS – User Commands (acls)

List acl for a file

List the file statistics – (%r – replication

factor)

Write to hdfs reading from stdin

Introduction to HDFS 69 hdfs dfs -getfacl tdata/geneva.csv

hdfs dfs -stat "%r" tdata/geneva.csv

echo "blah blah blah" | hdfs dfs -put - tdataset/tfile.txt hdfs dfs -ls –R

hdfs dfs -cat tdataset/tfile.txt

HDFS – User Commands (fsck)

Removing a file

List the blocks of a file and their locations

Print missing blocks and the files they belong to

hdfs dfs -rm tdataset/tfile.txt hdfs dfs -ls –R

hdfs fsck /user/cloudera/tdata/geneva.csv -files -blocks –locations

(36)

HDFS – Adminstration Commands

Comprehensive status report of HDFS cluster

Prints a tree of racks and their nodes

Get the information for a given datanode (like

ping)

71 Introduction to HDFS hdfs dfsadmin –report hdfs dfsadmin –printTopology hdfs dfsadmin -getDatanodeInfo localhost:50020

HDFS – Advanced Commands

Get a list of namenodes in the Hadoop cluster

Dump the NameNode fsimage to XML file

The general command line syntax is

hdfs command [genericOptions] [commandOptions]

hdfs getconf –namenodes

cd /var/lib/hadoop-hdfs/cache/hdfs/dfs/name/current hdfs oiv -i fsimage_0000000000000003388 -o

(37)

Other Interfaces to HDFS

HTTP Interface

MountableHDFS – FUSE

Once mounted all operations on HDFS can be performed using standard Unix utilities such as 'ls', 'cd', 'cp', 'mkdir', 'find', 'grep',

Introduction to HDFS 73 http://quickstart.cloudera:50070

mkdir /home/cloudera/hdfs

sudo hadoop-fuse-dfs dfs://quickstart.cloudera:8020 /home/cloudera/hdfs