Sistema de ficheros distribuidos

Wisam Alsalti, Ramsés Pascual, Julián Alves, Miriam Alierta Sistemas Distribuidos, 2012-2013 Universidad Autónoma de Barcelona Abstract—Durante la lectura del siguiente proyecto se expondrán los principales conceptos de los sistemas de archivos distribuidos (DFS, Distributed File System), donde se estudiarán las diferentes características de estos sistemas, su estructura, los distintos tipos de servidores que implementan estos sistemas y las diferencias que hay entre los diferentes tipos de DFS más utilizados; Además se añade una parte experimental, donde se presenta el sistema de archivos distribuidos NFS (Network File System), con sus diferentes características, ventajas y desventajas respecto a Lustre. Finalmente, y con el objetivo principal de entender el funcionamiento de estos sistemas, se instalará y se configurará el software en distintas máquinas para comprobar empíricamente su correcto funcionamiento y las diferencias que aporta, tanto positivas como negativas, respecto Lustre. I. INTRODUCCIÓN Los sistemas de ficheros y bases de datos son quizás los recursos más candidatos a distribuirse y compartirse en un sistema en red. De ahí la necesidad de implementar alguna forma de lograrlo y es aquí donde aparecen los sistemas de ficheros distribuidos. Un sistema distribuido es un conjunto de computadoras y/o procesadores conectados entre sí, comunicándose mediante el paso de mensajes. Para coordinar el sistema distribuido necesitaremos un software específico, permitiendo entonces la compartición de ficheros, recursos, etc. Los ficheros estarán repartidos por la red, los sistemas de ficheros distribuidos, o DFS, son una de las aplicaciones para controlarlos y organizarlos. Estos controlan tanto la transferencia, la protección de los datos, almacenamiento, etc. Hay varios tipos de DFS, cada cual con sus características, donde cada uno aprovecha mejor unos recursos u otros. Estos nos permiten, como anteriormente hemos comentado, controlar los ficheros y ubicarlos. Es fundamental en un sistema de este tipo proporcionar un rendimiento aceptable, por lo que hay que alcanzar un compromiso entre la disponibilidad local de la información para disminuir los costes de comunicación (caching y distribución) y la consistencia, que se refleja en la semántica que muestran los accesos compartidos. Como sujeto de experimento de esta práctica, hemos escogido, por sus características, por qué es OpenSource, entre otras muchas cualidades explicadas detalladamente más adelante, Lustre, basado en arquitectura Linux y accesible desde cualquier otro Sistema Operativo. A la hora de realizar realmente la práctica hemos utilizado NFS, ya que pese a todo lo bueno que es Lustre y lo que nos habría gustado poder realizar la parte experimental con él, no disponemos de un superordenador para poder instalarlo. Haremos una pequeña comparativa entre NFS y Lustre que aunque no sean comparables, está bien para ver como lo que NFS no es capaz de hacer, Lustre lo realiza sin demasiado esfuerzo. La configuración de nuestro experimento viene dada por una serie de parámetros que nos permite personalizar totalmente el que vendrá a ser nuestro servidor. II. TIPOS DE SISTEMAS DE ARCHIVOS Sistema Centralizado Es un sistema de ficheros en el cual los contenidos están en uno o varios servidores centrales, teniendo el control de estos de una forma más cómoda y manteniéndolos actualizados más fácilmente que si lo comparamos con los sistemas distribuidos. En cambio, si nos centramos en mirar los accesos, estos crearán cuellos de botella que suponen un problema, al mismo tiempo que se tienen que crear semáforos. Las réplicas serán más costosas, ya que en DFS las copias se realizan en los nodos. Sistema Distribuido Es un conjunto de máquinas separadas físicamente y conectadas por una red de comunicaciones distribuida, cada una tiene sus propios componentes, tanto de software como de hardware, aunque el usuario lo percibe como un único sistema (no necesita saber qué cosas están en qué máquinas). El usuario accede a los recursos de otras máquinas, recursos remotos igual que si accediera a los recursos locales. Los sistemas distribuidos tienen una serie de problemas, algunos solucionados, que suelen suceder a causa de caídas de nodos, falta de concurrencia o de estabilidad, fallos de red o de hardware, posibles ataques, y otros que aún no están solucionados como por ejemplo los ataques DoS/DDoS. Con el fin que esto no suceda, el DFS tiene asignadas ciertas tareas. El DFS se encarga de, por ejemplo, organizar, almacenar, recuperar o compartir los archivos, para automatizar todo el procesamiento de información. Aunque hay sistemas distribuidos por doquier, su diseño es aún muy simple y quedan grandes posibilidades de desarrollar servicios y aplicaciones más ambiciosas. A continuación listamos algunas de las propiedades a cumplir para el buen funcionamiento de un DFS [1]:  Transparencia, ya que el usuario no tiene porqué saber donde están situados los datos que está usando, ni donde está situado el recurso al que está accediendo, sino que tiene que ver el DFS como una sola máquina (Single System Image).  Escalabilidad, dado que la necesidad de más recursos es una cosa muy frecuente en los tiempos que corren, los DFS tienen que estar preparados para ello, de tal manera que la ampliación de nodos no tiene que suponer ningún problema, ni siquiera se tiene que configurar nada excepto en el nuevo nodo.  Heterogeneidad, los ficheros pueden estar contenidos en cualquier tipo de SO, por lo tanto un DFS tiene que poder adaptarse a todos los posibles SO para conseguir también una ampliación de los recursos  Fiabilidad, la información tiene que estar siempre disponible, aunque cualquiera de las máquinas falle, su información tiene que estar en el DFS, al mismo tiempo que éste tiene que ser lo máximo de estable posible.  Extensibilidad, se determina en primer lugar por el grado en el cual se pueden añadir nuevos servicios de compartición de recursos y ponerlos a

interpreta las llamadas al sistema sobre ficheros y genera las peticiones de acceso a los recursos remotos.8. ARQUITECTURA DE LUSTRE Es un sistema de archivos distribuido Open Source. anteriormente mencionados. Con el objetivo de poder analizar el funcionamiento de un sistema de ficheros distribuidos debemos seleccionar uno de los tantos que hay en la actualidad. Un fichero se identifica en este servicio a través de un identificador único de fichero (UFID). es una base de datos con elementos (nombre.5 SLES 10 Fedora 11 Vanilla(kernel. etc. Un DFS puede ser extendido a nivel de hardware mediante la inclusión de máquinas a la red y a nivel de software por la introducción de nuevos servicios o la reimplementación de los antiguos.1 Características de Lustre Además de poder ejecutarse en una gran variedad de kernels. . solucionando así el problema de las posibles desconexiones o caídas de los nodos. En general.5 SLES 11(i686 and x86_64) 1.8. posibilitando a los programas de aplicación la compartición de recursos. Lustre puede ejecutarse en una gran variedad de kernels: [3] Kernel/Versión OEL 5(i686 and x86_64 ) RHEL 5 Versión Lustre (compatible) 1. debido a que presenta una gran escalabilidad permitiendo tener decenas de miles de clientes.8. creando una privacidad y limitación de accesibilidad deseados. El nombre es una mezcla de Linux y Cluster.8.5 1. con la capacidad de almacenar una gran cantidad de datos a la orden de petabytes(PB) y cientos de gigabytes por segundo(GB/s) de operación entrada/salida(I/O). por lo que consideramos que es el sistema más adecuado para poder realizar nuestro análisis y poder ver el funcionamiento. La siguiente tabla nos muestra el alcance práctico de la escalabilidad y rendimiento del sistema de archivos Lustre y algunos resultados de pruebas en los sistemas de producción.  Servicio de ficheros: mantiene el contenido y los atributos de los ficheros para tener un acceso rápido y no tener que hacer las peticiones por flooding.  Servicio de nombres (directorios): se encarga de proporcionar transparencia en la ubicación. pudiendo colapsar la red.5 1.  Semáforos: así evitamos el acceso de varios nodos al mismo tiempo para cambiar los contenidos.disposición para el uso de una variedad de programas cliente.  Memoria compartida: sistema para conseguir una exitosa escalabilidad. se modifican y se buscan entradas. Para conseguir que estas propiedades se cumplan.8. [4] Con la información que podemos recoger de este análisis podemos observar que Lustre cumple con todos los requisitos para que un sistema de ficheros distribuidos sea óptimo. [2] III. Un sistema de ficheros distribuidos tiene 3 tipos de componentes:  Cliente: interfaz local con la aplicación.5 La arquitectura de almacenamiento de Lustre se utiliza para muchos tipos diferentes de clusters. almacenamiento y ancho de banda.org) 1. varias de las posibles soluciones son:  Redundancia: provocando a los nodos contener información de los demás.8. Además de funcionar en Linux proporciona una POSIX (Portable Operating System Interface) que tiene como finalidad generalizar las interfaces de los sistemas operativos para que una misma aplicación pueda ejecutarse en distintas plataformas. al mismo tiempo que provoca una transparencia de almacenamiento. la instalación de Lustre puede escalarse más o menos con respecto al número de nodos clientes. para ello buscamos un estudio de los sistemas con los requisitos. por lo tanto se tiene que crear credenciales para los accesos que van a hacer los nodos. que cumple cada sistema analizado. Gestiona el almacenamiento local (caching). Es de las más usadas en HPC (High Performance Computing). normalmente utilizado en clusters a gran escala.  Seguridad.5 1. 3. los datos que contiene el DFS tienen que estar protegidos. UFID) donde se crean.

 NFS y CIFS: los archivos de Lustre pueden ser exportados mediante NFS o CIFS lo que les permite ser compartido con un cliente que no use Linux.3]Imagen del almacenamiento de un archivo en Lustre.2]Arquitectura básica de Lustre. se almacenan como podemos ver en la imagen[3.). Como podemos ver un archivo puede estar formado por varios objetos. La técnica usada para almacenar los objetos/datos de un mismo archivos en diferentes servidores se conoce por “striping”.  Striping controlado: Lustre usa RAID-0 striping y balancea el espacio usado a través de los OSTs.  Interoperabilidad: Lustre se en ejecuta en variedad de arquitecturas de CPU. que veremos más adelante.  Alta disponibilidad: Lustre presenta dos técnicas de tolerancia de fallos.  Clientes: son nodos que ejecutan el software Lustre client. que se encarga de que evitar la corrupción de las transferencias de datos. permisos y la estructura de los archivos). Magnament Server (MGS) Los MGS son servidores que almacenan la información de configuración para todos los sistemas de archivos Lustre en un cluster y proporciona esta información a otros componentes de Lustre. Su tarea es responder las peticiones de I/O realizadas por los clientes.0 para su uso con Linux. directorios. El striping (denominado a veces RAID 0) es un método que incrementa el índice de transmisión del sistema(throughput) mediante el uso de varias unidades de disco en paralelo .  Alto rendimiento en redes heterogéneas.  Object Storage Target (OST): en estos servidores se almacen los datos. Los archivos en lustre. lo que les permite montar el sistema de archivos. [3. Una configuración básica de los componentes de Lustre. cada objeto contiene datos y está almacenado en un OST concreto.  Seguridad: Lustre tiene una opción para conexiones TCP con puertos privilegiados.  Monitorización: Lustre dispone de una variedad de mecanismos para examinar el rendimiento y cambiar los ajustes del sistema. Un sistema de archivos Lustre tiene principalmente cinco unidades funcionales. varios archivos pueden apuntar al mismo inode. El inode contiene el diseño del archivo(atributos. Estas son:  Metadata Target (MDT): almacena los metadatos (como nombre de archivos.Otras características de Lustre:  Una versión modificada de ext4 file system: Lustre usa esta modificación para el sistema de almacenamiento y metadata. 3. podría ser así: Lustre Networking (LNET) LNET es una API de red personalizada que proporciona la infraestructura de comunicación que traslada los metadatos y las operaciones de I/O de los servidores a los clientes.3].  Metadata Server (MDS): controlan el acceso a los MDTs.  Herramienta de recuperación: Lustre proporciona un sistema de comprobación de archivos distribuidos (lfsck) que puede restablecer la coherencia entre los componentes de almacenamiento en caso de un error en el sistema de archivos principal.  Object Storage Servers (OSS): estos servidores controlan uno o varios OSTs. El software cliente proporciona una interfaz para acceder y manipular los datos. 3. donde cada archivo apunta a un inode .  Red de protección de la integridad de los datos: se envía una checksum de todos los datos enviados desde los clientes al OSS. La información necesaria para el acceso a los archivos se almacenara en el MDT.2 ¿Cómo es la arquitectura de Lustre? Las instalaciones de Lustre incluyen un management server (MGS) y uno o más sistemas de archivos Lustre interconectados con Lustre networking (LNET). permisos de acceso. etc. localización de cada objeto.  Open source: está licenciado bajo GPL 2.  Arquitectura basada en objetos. .3 ¿Cómo almacena los datos Lustre? [3.  MPI (Message Passing Interface) I/O: Lustre ha ideado una capa MPI ADIO que optimiza las operaciones paralelas de I/O para que coincidan con la arquitectura del sistema de archivos subyacente.

LUSTRE VS NFS Una de las diferencias [6] que se descubren en la instalación de los dos sistemas de ficheros es el hecho que mientras NFS necesita un tiempo (dependiendo de la conexión) inferior a cinco minutos (incluyendo su configuración). permitiendo que el sistema siga operativo. Lustre necesita unas pocas instrucciones más para su instalación [7]. De esta forma. el cliente y el servidor NFS con mucho más fáciles de instalar y configurar. 3. el otro OSS recupera todas las peticiones fallidas al OST. Para conseguir una disponibilidad alta de los recursos (High Availibility). que mantiene un servidor activo que es el encargado de la gestión de los recursos. Los casos que se dan son:  Resource fencing: un nodo no puede usar un recurso mientras éste está en uso.4. Una vez el cliente dispone de esta información podrá realizar las operaciones de I/O.5]Configuración tolerante a fallos para un MDT 3.4. los dos servidores conectados a la red y contestando peticiones. se intenta mantener el estado del servidor como activo y llevar a cabo otras tareas de gestión de los recursos  Health monitoring: Verifica periódicamente la disponibilidad tanto de recursos como de hardware. Podemos observar en la imagen[3. 3. el otro responderá por él. Es importante comentar que los OSSs comparten disco/RAID. [3. con la configuración activa/activa. 2.  Por otro lado tenemos otra configuración que se llama active/passive.4 Tolerancia de fallos Es una de las técnicas usadas para evitar la pérdida de disponibilidad en caso de caída de un servidor. los MDSs pueden ser configurados en activa/activa. que su función es hacerse cargo de la gestión de datos en el caso de que el servidor activo falle. y el tiempo que necesita para su configuración es mucho más elevado. seguro y infinitamente mejor que NFS. dada su gran cantidad de parámetros configurables. donde cada OSS implementa una configuración activa y pasiva a la vez. Tenemos un cliente que realiza un petición de apertura a un fichero concreto. con estos algoritmos se consigue un sistema solido. que consiste en tener. pasándose constantemente la nueva información entre ellos.4]Imagen que ilustra el funcionamiento de Lustre. También incluye información de acceso. . existen dos tipos de conexiones entre los servidores:  La primera se llama active/active.  Resource management: En caso de fallo.4]: 1. lograremos uno de los requisitos para garantizar la alta disponibilidad del sistema.6]Configuración tolerante a fallos para los OSTs.metadatos del sistema de fichero Lustre. 3. sin embargo. Existe otra variante para la configuración de los MDSs. A continuación analizaré la figura[3.6] que los OSSs están conectados a ambos OSTs. En resumen. es decir en que servidores están almacenados los objetos. el segundo (pasiva) tomará el control de las peticiones. y algo menos por parte de los clientes. [3. Lustre. por ejemplo. por ejemplo. Si el primero falla. En caso de que uno de los dos sufra algún tipo de inconveniente que le impida seguir con su labor. El primero (activa) maneja los [3. al mismo tiempo existe otra conexión a un servidor en estado de standby. si un OSS falla. IV.2 OST Configuración (Activa/Activa) En general los OSTs se suelen configurar con el objetivo de conseguir un balanceo de carga.1 MDT Configuración (Activa/Pasiva) Típicamente dos MDS son configurados como activa/pasiva como vemos en la figura[3. Esta petición es enviada al servidor de metadatos(MDT). fallo de software o red. El servidor transfiere el diseño(los distintos objetos) del archivo pedido. tanto el hardware como el software están provistos de la conmutación por error. Para poder realizar las técnicas descritas anteriormente. Las herramientas para depurar los problemas en NFS son mucho más simples debido a la pequeña cantidad de parámetros configurables que este dispone. en un entorno donde existan múltiples sistemas de archivos. en cambio dispone de complejos algoritmos de depuración ya que es un sistema mucho más grande y reparte la información entre distintos nodos. De este modo.5]. Notamos que ambos deben tener acceso al MDT. donde cada MDS gestiona los metadatos para un subconjunto del sistema de ficheros Lustre.

la máscara de red y los permisos a dar. eliminando el contenido anterior en caso de haber sido modificado. V. por lo tanto. el servidor necesitará los paquetes específicos para serlo. Con estos datos. falta configurarlos para su correcto funcionamiento. seguido de la IP del cliente. en primer lugar. con sus comandos para la distribución de Linux Ubuntu. w para escribir y x para ejecutar. esto hecho podría pasar con Lustre. EXPERIMENTACIÓN Primero de todo. y su nivel de colisión inferior. el cliente deberá averiguar dónde. si al mismo tiempo accede otro nodo. los requisitos necesarios para Lustre son significativamente elevados respecto a NFS. Lustre supone una mejora en cuanto al tiempo de lectura /escritura. mediante su IP.: Servidor # apt-get install nfs-common nfs-kernel-server Cliente # apt-get install nfs-common Una vez tenemos los elementos conectados entre ellos formando una red local. Lustre tiene esta facultad. Al mismo tiempo. las peticiones no irán a un mismo nodo. se han instalado todos los componentes necesarios para el experimento [8]. en segundo se visualizará la IP del servidor/máscara de subred. Respecto al hardware necesario para el funcionamiento de ambos sistemas. ya se podrá montar una partición. pero con mucha menos frecuencia. ya que se trabajará con NFS como sistema distribuido para este apartado. este no verá los cambios a no ser que recargue el contenido del fichero. dada que su velocidad de transferencia es mayor. Estos paquetes. donde está situada la carpeta que éste comparte. asignando al mismo tiempo la carpeta que lo contendrá. en este caso read/write (rw): Al finalizar esta configuración. Lustre en cambio cubre todas las funcionalidades que ofrece NFS. ya que para la comunicación en red local es el más adecuado por sus características. hace falta tener todos los componentes necesarios para tener una red con un sistema distribuido. eso se realiza con el comando: # showmount -e IPServidor Esto mostrará.d/portmap start Para finalmente. para su redireccionamiento. reiniciar el servidor para que coja todas las funciones añadidas en los pasos anteriores con el comando: # /etc/init. con la siguiente instrucción: # /etc/init. Esto supone una gran mejora frente la aparición de cuellos de botella que puede provocar un servidor NFS. en el archivo exports que está en la carpeta /etc. el cliente deberá insertar el siguiente comando en la consola: # mount -t nfs IPServidor/MáscaraSubred:ruta_carpeta_servidor ruta_carpeta_cliente . y otros como clientes. y los clientes los suyos. Quedando de esta manera registrados en los archivos de configuración del servidor. Para hacer este proceso. como elemento de transferencia se ha usado un switch de capa 2. En esta screen podemos ver como quedaría el fichero exports con los cambios mencionados. donde /home/miriam/sd es la ruta del directorio a compartir. que se mostrará como una carpeta. en el ordenador que hará de servidor tenemos que añadir cuales serán los clientes.d/nfs-kernel-server restart Al mismo tiempo. como único inconveniente a mencionar es a la hora de instalar y configurar los distintos parámetros que este necesita. este tiene una caché limitada. mejorando en gran parte todas ellas (además añade grandes funcionalidades que NFS no soporta). tiene que ser una red local. se ha usado cable ethernet cruzado. antes de comunicar todo mediante el switch. ya que los archivos estarán repartidos por la red. para comprobar realmente las diferencias entre Lustre y NFS. siendo r para leer. En el caso expuesto. teniendo la IP del servidor. tenemos que hacer lo mismo para la parte del cliente. Para cada tipo de nodo hace falta una serie de paquetes diferentes. si varios clientes hacen diferentes peticiones a un servidor NFS. Para conseguirlo. al añadir al final del archivo: ruta_directorio_compartido IPcliente/mascara_subred(permisos) Los permisos serán letras. Para comunicar los ordenadores (nodos) con el enlace usado (switch) lo más adecuado. eso significa que si un nodo modifica cualquier fichero.Al mismo tiempo. Previamente. En cambio. Los componentes necesarios serán: un ordenador que funcionará como servidor. los nodos ven los cambios efectuados en el mismo archivo. con la sesión de root iniciada. y ahorra posibles problemas al no sobrescribir los datos. Como conclusión a este apartado cabe destacar la facilidad de instalación y configuración de NFS y al mismo tiempo la falta de concurrencia que este no soporta. puesto que. se tendrá que iniciar el servicio portmap. registrando cuál será el servidor para hacer las transferencias de ficheros. por lo tanto los clientes tendrán que esperar a que se resuelva el problema. NFS no dispone de concurrencia durante la edición de archivos. son. Primero. la ruta de la carpeta compartida. Los cambios que se guardarán siempre serán los de la última modificación.

no se notará ni la más mínima diferencia. La primera diferencia que salta directamente a la vista. Para poder demostrar los posibles retardos en la transferencia de varios archivos al mismo tiempo. implica una pérdida de tiempo y al mismo tiempo. En esta primera prueba se comprobará la concurrencia que permite NFS. ya que. todo lo contrario. como por ejemplo. NFS como sistema de almacenamiento centralizado. un segundo nodo. no se pueden usar archivos ligeros. Y. como un sistema de almacenamiento distribuido. y también lo edita. llamemosle cliente1. harán falta archivos más pesados. y Lustre. ya sea pesado o no. las pruebas para demostrar los fallos serán las siguientes: 1. en NFS hace falta que el servidor añada. mientras el archivo pesado está en proceso de transferencia. mientras lo edita el cliente2 abre este mismo archivo editándolo y guardándolo.Una vez configurados las dos partes. las IPs de los nuevos nodos que quieran participar en la red. En ambos casos perdería información. abre el mismo fichero. durante la configuración. estos archivos serán ideales para demostrar la presencia o carencia de la concurrencia cuando dos nodos están editando el mismo archivo. En cambio. teniendo en cuenta que se necesitan dos nodos cliente para hacerlas. En el momento en el que cliente2 lo ha guardado el sistema avisa al cliente1 que el archivo ya no es el mismo que cuando lo abrió. pueden suceder varias cosas: En la imagen vemos un fichero (bestia_peluda. Una vez está todo en orden para poder hacer las correspondientes pruebas. una copia de seguridad de algún tipo de archivo reproducible. Por lo tanto. para poder demostrar las diferencias en el caso de las transferencias. Una vez se ha llegado a este punto. . se puede enviar cualquier otro tipo de archivo. advirtiéndole que si guarda perderá la modificación hecha por el otro cliente: Si cliente1 desea guardar igualmente. lo que haya guardado el cliente2 será sustituido por la nueva edición. Por lo que si decidiera no guardar su modificación y recargar el archivo perdería su edición. la escalabilidad ofrece una gran resistencia. cliente2. y una vez comprobado que su funcionamiento básico funciona. ya se pueden hacer las transferencias de ficheros. antes de poder hacer ninguna prueba es que. para no colapsar del todo la red. como archivos de texto con pocas líneas. manualmente. en cuanto lo haga. para usarlos como ejemplo. una falta de escalabilidad si no hay un administrador pendiente de las posibles modificaciones a hacer en los archivos de configuración. dándole la posibilidad de recargarlo (perdiendo lo que haya modificado hasta entonces) para ver las modificaciones o seguir editando sin ver lo que haya modificado el otro usuario. Primero de todo. mientras que si guarda perderá la edición del otro cliente. decida no recargar y acabe de editar guardando los datos al acabar. Al ser una red local. ya que el simple hecho de tener que insertar estos nodos manualmente.txt) que ha abierto el cliente1. En un primer caso supongamos que el cliente1 al que le aparece esta imagen. Aún después de la anterior “advertencia” cuando vaya a querer guardar aparecerá un mensaje como el siguiente. para poder visualizar las diferencias entre los dos sistemas. uno de los nodos crea y abre un archivo de texto para su edición. mientras. al ser una red rápida.

y transfiriendo lentamente el segundo. dado que.php/Lustre_Release_Information [4] Oracle. podría ser el caso en el que ambos clientes guarden al mismo tiempo. dado que su arquitectura permite particionar los ficheros entre los distintos nodos. serían los del cliente1.1 [documento online ] http://www.0" [documento online] Capítulo 1. REFERENCIAS [1] G. y luego desde otro nodo. en caso de tener más de una petición. 3.net/nfs-howto/ [8] Esto es el resultado de tener un servidor central que contiene todos los ficheros. Kindberg.lustre. No todos los softwares preparados para este tipo de sistema funcionan igual ni tienen las mismas propiedades.1 http://wiki. NFS puede ser un sistema apto. con los recursos disponibles eran imposibles de hacer.Version 2. T. Apartado 4 [2] Rúben Cuadrado Pérez. dado que sus mínimos. Conceptos y diseño” [libro] Capítulo 1. “Design and implementation of an efficent management of storage rate in ‘Anella Cultural’ Project of Foundation i2CAT” [artículo] June 18th 2007.lustre. CONCLUSIONES Los DFS son un sistema ideal para la compartición de archivos. podemos extraer de los resultados que. VI. " Lustre File System Operations Manual . por lo que esta vez los datos que podrían ser sobrescritos. estos no crean cuellos de botella tan fácilmente. Coulouris. dependiendo de la elección del cliente2.4. “Sistemas Distribuidos.2 [3] Lustre File System. este crea un cuello de botella.php/NFS_vs. Lustre Release Information [documento online] http://wiki. Lustre puede resultar realmente útil en redes que necesiten una I/O con una tasa de velocidad elevada. figura 1. Por lo tanto esta prueba queda obsoleta. " Lustre File System Operations Manual . la tasa de transferencia es muy alta.lustre. se deben valorar las características de cada uno. La segunda prueba será para comprobar la velocidad. ralentizando el primero. Capítulo 2. pero en caso de que la red necesite mucho espacio. Esto no pasa tan exageradamente en Lustre.lustre.1 http://wiki. Este acto mostrará un retraso en las transferencias de los dos archivos.Version 2.html [6] Oracle. ya que las pruebas.illinois. Dollimore. Los costes que puede suponer cada uno de ellos también influyen en el momento de la decisión. pero como no hemos sido capaces de conseguir no sabemos cuál sería el resultado.0" [documento online] http://wiki. Lustre™: A How-To Guide for Installing and Configuring Lustre 1. no es el tipo de sistema adecuado. tabla 1.org/manual/LustreManual20_HTML/index. o tasas de transferencia más rápidas. En la tercera prueba se comprobará la disponibilidad de los archivos en un momento de tráfico alto enfocado todo hacia el servidor.Version 2. Un tercer supuesto. VIII.org/index. J. en el servidor no son los mismos.html Source Forge NFS. ralentizando todas las transferencias. . por lo tanto antes de escoger uno u otro para un sistema. 3ºEd.edu/index. por ejemplo.html [5] Oracle. o desde el mismo. para ello." Lustre File System Operations Manual .ncsa. antes de hacer ningún tipo de implementación. para una red pequeña con pocos nodos y no demasiadas transferencias. primero intentamos insertar o extraer un archivo con un volumen generoso.How TO [document online] Apartado 3 y Apartado 4 http://nfs.0" [documento online] Capítulo 1.org/manual/LustreManual20_HTML/index._Lustre [7] National Center for Supercomputing Applications.En un segundo caso podríamos suponer que cliente1 acabase su edición y guardase antes que el cliente2. dado que es una red local conectada con cables ethernet. 2. Linux NFS. Por la parte experimental. como los archivos están divididos en varios nodos. intentamos hacer lo mismo con otro archivo.org/index. ya que según el presupuesto se implementará uno u otro.sourceforge.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.