Overview de Grid File Systems existentes

1. Introducción Overview de Grid File Systems existentes Escrito por: Matienzo, Sebastián Germán (Universidad Nacional de La Matanza) En el marco del curso Introducción a Grid Computing XIII Congreso Argentino de Ciencias de la Computación Octubre 2007 Los Grids se han vuelto, hoy por hoy, la elección ideal para ejecutar aplicaciones científicas que requieren un procesamiento intensivo de datos. Por ejemplo, aplicaciones vinculadas con la bioinformática, procesamiento médico de imágenes, etc., suelen analizar y producir cantidades masivas de datos, que deben ser analizadas y procesadas. Según Foster 1, un Grid es una herramienta para compartir recursos y coordinar la resolución de problemas en organizaciones dinámicas virtuales, buscando permitir la integración de servicios y recursos distribuidos, usando protocolos e infraestructura de propósito general, a fin de alcanzar útiles calidades de servicio. Sin embargo, la pregunta pasa por cómo se puede acceder a dichos recursos compartidos, de una forma organizada, y de manera relativamente transparente al usuario. Es allí cuando surgen los sistemas de archivos Grid ( Grid File Systems ). Un sistema de archivos Grid es el encargado de organizar los recursos disponibles a lo largo de todo el Grid, de modo que un usuario pueda acceder a dichos recursos de manera similar a como se hace en un sistema de archivos tradicional. Para ello, brinda ciertas características críticas para el funcionamiento de un Grid en su conjunto: réplica de archivos (para mantener copias distribuidas a lo largo de todo el Grid), gestión de metadatos (estos son los que hacen el mapeo de nombres lógicos a ubicaciones físicas, controles de permisos de acceso, etc.), y acceso a recursos heterogéneos ubicados en diferentes lugares. De esta forma, uno accede a los recursos de manera similar a un sistema tradicional (es decir, la modalidad de acceso es transparente), pero dicho recurso se encuentra en realidad disperso a lo largo de todo el sistema. La idea del presente trabajo es enfocarse básicamente en detalles respecto a la arquitectura (a un nivel muy básico) de tres sistemas de archivos Grid existentes, que lidian con las necesidades de los usuarios a la hora de acceder a la información que ellos requieren. 2. Background y trabajos relacionados Actualmente, hay una entidad abocada a investigar los diferentes Grid File Systems existentes en el mundo, cuyo nombre es Grid File System Working Group (Grupo de trabajo de sistemas de archivos Grid). La misma, es una entidad japonesa cuyo objetivo es proveer una especificación estandarizada para todo servicio de directorios y arquitecturas vinculadas a un Grid File System; a tal fin, buscan describir y gestionar los nombres de los recursos de un sistema de archivos, mecanismos de control de accesos y 1 The Anatomy of the Grid: Enabling Scalable Virtual Organizations, I. Foster, C. Kesselman, S. Tuecke. International J. Supercomputer Applications, 2001 1/10

gestión de metadatos. A su vez, desean especificar la estructura jerárquica para facilitar el agrupamiento (conocido como federación ) e intercambio de datos virtuales de sistemas de archivos en el entorno Grid, proveyendo los nombres virtuales que permitirán realizar las asociaciones de mecanismos de control de acceso y metadatos de los recursos en la capa física. Desafortunadamente, las minutas e información resultante de las reuniones que mantiene dicha entidad, carecen de un panorama general que permita a las personas que buscan introducirse en el mundo Grid, conocer detalles generales de los sistemas disponibles actualmente en el mercado. Es por ello que este paper intentará brindar un paneo general de cada uno de los sistemas más reconocidos en la actualidad. 3. Introducción a un Grid File System Un Grid File System (se abreviará a partir de ahora como GFS) se define como un sistema de archivos de computadora cuya meta es brindar una confiabilidad y disponibilidad mejorada de los recursos disponibles, con respecto a los sistemas de archivos tradicionales. Al igual que un sistema de archivos tradicional, un GFS cuenta con tres componentes fundamentales: una tabla de archivos, un archivo de datos, y un conjunto de metadatos. Sin embargo, el desafío de los mismos radica en aparentar ser un solo disco, manejable por una computadora, cuando en realidad es un conjunto de ellos, distribuidos en diferentes ambientes heterogéneos. En la actualidad, si bien existen varios GFS disponibles en el mercado, hay tres en particular que se encuentran bastante documentados, facilitando la comprensión de cada uno de ellos en forma detallada. Dichos GFS serán los presentados en este paper: GFarm. SDSC Storage Resource Broker. IBM Storage Tank. 4. GFarm En breves palabras, GFarm es una implementación de la arquitectura Grid Datafarm, diseñada para computación intensiva de datos a escala global. Provee el sistema de archivos Gfarm Grid, que es un sistema de archivos compartido en un cluster o grid, que se puede escalar hasta un almacenamiento en petaescala, y realiza procesamientos con ancho de banda de E/S escalable, así como un procesamiento paralelo también escalable. Para esto, integra los discos locales de los nodos de sistemas de archivos, disponiendo a su vez de un nodo de servidor de metadatos GFarm. La arquitectura general del mismo se presenta en la figura 1, donde: En cada nodo de los sistemas de archivos se encuentra un demonio de sistema de archivos GFarm (gfsd) en ejecución, para facilitar las operaciones remotas de archivos, con control de acceso en el sistema de archivos GFarm, así como la replicación de archivos, una rápida invocación, y el monitoreo del estado de recursos de los nodos. El nodo servidor de metadatos GFarm maneja los metadatos de los sistemas de archivos, así como la información de procesos paralelos, en que el gestor de trabajos Gfarm (gfmd), y el servidor de metadatos del sistema de archivos (postmaster, o slapd) están en ejecución. 2/10

Figura 1 Arquitectura de GFarm La modalidad de trabajo para resolver problemas de performance y confiabilidad en los sistemas de archivos es mediante el mantenimiento de múltiples réplicas de archivos. Así, no sólo se previene la degradación de performance debido a cuellos de botella de acceso, sino que también provee tolerancia a errores y recuperación de desastres. Como característica propia de GFarm a resaltar, es que cada nodo de sistema de archivos también es un cliente del sistema de archivos de GFarm. Existen varias maneras de acceder al sistema de archivos de GFarm. Un par de ellas son: Usar comandos de GFarm, y APIs de E/S nativas de él: así se pueden utilizar ciertas características como, por ejemplo, la replicación de archivos. Usando la librería que se engancha a las system calls: de este modo se puede acceder directamente al sistema de archivos de GFarm como si este estuviera montado en /gfarm. Por otra parte, un nodo en un sistema GFarm puede ser uno de los siguientes cuatro tipos: Nodo cliente: un nodo terminal para los usuarios. Nodo de sistema de archivos: proveen almacenamiento de datos y CPUs para todo el sistema GFarm. En cada nodo de sistema de archivos, el demonio gfsd está en ejecución para facilitar operaciones de archivos remotos, así como controles de acceso, autenticación de usuarios, replicación de archivos, rápida invocación, monitoreo del estado de recursos de los nodos, y controles generales. Nodo servidor de metadatos: maneja la información referida a los metadatos y los procesos paralelos. Tiene un servidor de sistema de archivos (gfmd), y un servidor de base de datos tal como un LDAP (slapd) o un PostgreSQL (postmaster). Nodo servidor caché de metadatos: es un servidor que hace el acceso a los metadatos más rápido, previniendo la concentración de accesos a los mismos. Tiene siempre un agente (gfarm_agent) en ejecución. 3/10

Los cuatro tipos no son necesariamente computadoras diferentes; si el número de estas es limitado, algunas pueden cumplir más de una de las funciones antes mencionadas. En lo referido a los archivos, cada uno es una fila estándar o una de gran escala dividida en fragmentos, o en un grupo de filas clasificado. Físicamente, cada fila es replicada y dispersada a lo largo de todos los discos de los nodos de sistemas de archivo, y son accedidas en paralelo. Acerca de la autenticación, hay tres modos disponibles para ello: La modalidad más simple, sharedsecret, que usa una clave compartida que genera el software de GFarm, y que es recomendada si hay un firewall como protección. GSI (Grid Security Infraestructure) es un método que utiliza autenticación por clave pública. Encripta la comunicación en la red, por lo que se lo recomienda usarlo para conexión vía Internet. GSI_AUTH, usa GSI para la autenticación, pero cambia a una conexión TCP plana luego que se completa dicha autenticación. Nuevamente, esto es recomendado para entornos protegidos por un firewall. Finalmente, algunos problemas que se pueden mencionar de GFarm: No hay un usuario privilegiado, por lo que las operaciones que requieren dicho privilegio no están implementadas. Por ejemplo, no hay manera de cambiar el usuario de un archivo. Los permisos de grupo no están implementados aún. No hay manera de detener un proceso de replicación. 5. SDSC Storage Resource Broker El SDSC Storage Resource Broker (SRB) es un sistema que soporta colecciones compartidas de datos que pueden distribuirse a lo largo de múltiples organizaciones y sistemas de almacenamiento heterogéneos. Puede usarse como un Data Grid Management System (DGMS, Sistema de gestión de datos de Grids ) que provee un nombre de espacio jerárquico lógico para gestionar la organización de datos (generalmente archivos). SRB presenta al usuario una sola jerarquía de archivos para datos distribuidos a lo largo de múltiples sistemas de almacenamiento. Tiene características para soportar la gestión, colaboración, compartir en forma controlada, publicar, replicar, transferir y preservar dichos datos distribuidos. Es un middleware, en el sentido de que está construido por encima de otros paquetes de software más grandes (sistemas de archivos, archivos, fuentes de datos en tiempo real, sistemas de base de datos relacionales, etc.). Tiene una librería de funciones que pueden ser usadas por software de más alto nivel, así como también provee un amplio entorno de gestión de datos distribuidos, incluyendo aplicaciones para usuarios finales que van desde Web Browsers hasta librerías de clases Java. En particular, incluye entre otras cosas lo siguiente: Librería API C 4/10

Scommands, utilitarios tipo UNIX para manipular y consultar las colecciones y datos en el espacio SRB. inq, un cliente gráfico SRB para Windows 98/Me/NT/2k/XP. MySRB, una interfaz para explorar y buscar, basada en tecnologías web. JARGON, una API de Java para desarrollar interfaces de data grid de SRB. SDSC Matrix, un sistema de gestión de flujo de data grid. Se compone básicamente de tres elementos clave: Servicio de catálogo de metadatos (MCAT). Servidores SRB. Servidores cliente. Los metadatos del sistema SRB los gestiona un servidor MCAT, basado en tecnología de bases de datos relacional. Este almacena metadatos vinculados con conjuntos de datos, usuarios y recursos que maneja el SRB; donde, por metadatos se entienden información de control de acceso, y estructuras de datos requeridas para implementar colecciones (léase, directorios). El MCAT presenta a los clientes una vista lógica de los datos almacenados en el SRB; tiene como característica que, de modo similar a los nombres de archivos en el paradigma de los sistemas de archivos, cada dato se almacena en el SRB con un nombre lógico, que puede usarse para operaciones de datos. Pero, a diferencia de los sistemas tradicionales, la ubicación física de los datos en el entorno SRB se mapea lógicamente a los conjuntos de datos; por ende, los datos de una misma colección pueden corresponder físicamente con distintos sistemas de almacenamiento. Figura 2 Arquitectura base del sistema SRB Respecto al servidor SRB, se basa en un modelo cliente / servidor: tiene un SRB Master y un SRB Server, donde el primero es un demonio que escucha continuamente un puerto definido por solicitudes de conexiones de clientes. Al recibir una y autenticarla, abre un nuevo hilo y ejecuta una copia del servidor SRB, que se denomina Agente SRB, para servir a dicha conexión. Así, el cliente se comunica de ahí en más con el agente SRB, mediante un puerto diferente, y el SRB Master sigue escuchando el puerto original por más conexiones. 5/10

Los clientes se comunican con el agente SRB usando un conjunto de APIs mediante sockets TCP/IP. La librería del cliente envía solicitudes usando conectores predefinidos al agente SRB, y recibe y parsea respuestas del agente. Es posible, finalmente, armar una federación de servidores SRB: es un grupo de ellos que se coordinan entre sí para servir a solicitudes de los clientes. Como ventajas, por razones técnicas y políticas varios sistemas de almacenamiento deben ejecutarse en distintos hosts, mejora la performance, y mejora la confiabilidad y disponibilidad (la réplica de datos se almacena en muchos lugares diferentes). Figura 3 Operaciones en un SRB federado En el caso de la figura 3, la federación tiene dos SRB Master ejecutándose en los hosts A y B, donde el servidor SRB en A es un MCAT. Los pasos para la comunicación, tomando como ejemplo que el cliente pide abrir un conjunto de datos, son los siguientes: 1. Luego de completar la secuencia de conexión con el SRB Master en el host A, el cliente envía una solicitud al agente SRB en el mismo host para abrir un conjunto de datos para lectura. 2. El agente SRB llama al MCAT pasando el identificador de usuario y el nombre del conjunto de datos, para ver si el cliente tiene permisos de administración a los mismos. Si es así, el MCAT devuelve una estructura de datos con la ubicación física de donde están almacenados dichos datos (incluye el nombre del host, el tipo de almacenamiento, sea UNIX, DB2, etc., y el nombre de la ruta, tal como un nombre de archivo de Unix, por ejemplo). 3. El agente SRB en el host A descubre que los datos solicitados están en el host B, y lleva una llamada abierta a cuenta del cliente, pasando el tipo de almacenamiento y el nombre de la ruta al agente SRB en el host B. 4. El agente SRB en el host B usa el tipo de almacenamiento para invocar al driver correspondiente que pueda manejar la llamada, pasando el nombre de la ruta abierta como parámetro. Al completarse la misma, el agente SRB en el host B devuelve el descriptor del archivo abierto, o bien el código de error, al agente SRB en el host A. 6/10

5. Si la llamada fue exitosa, el agente SRB en el host A almacena el descriptor del archivo abierto, y otra información tal como el nombre del host, en una estructura de dato interno, y devuelve el puntero a dicha estructura al cliente. Entonces, el cliente puede usar este puntero para llamadas subsecuentes. Si la llamada no hubiera sido exitosa, se habría devuelto un código de error en su lugar. 6. IBM Storage Tank IBM Storage Tank es una solución encargada de la gestión del almacenamiento en un entorno distribuido heterogéneo. Está diseñado para proveer performance comparable con la de los sistemas de archivos construidos en dispositivos de almacenamientos de alta performance, enlazados mediante un bus. Además, también provee alta disponibilidad, escalabilidad incrementada y centralizada, almacenamiento automatizado y gestión de datos. Posee una tecnología denominada Storage Area Network (SAN, Almacenamiento de área en red ) que permite a una empresa conectar grandes números de dispositivos, incluyendo clientes, servidores y subsistemas de almacenamiento en masa, a redes de alta performance. En una SAN, los clientes pueden acceder grandes volúmenes de datos directamente de las unidades de almacenamiento, con conexiones de alta velocidad y baja latencia. Así, puede suplir las necesidades de compartir datos en general en un entorno distribuido, así como las necesidades de aplicaciones de datos intensivos, tales como imágenes, animaciones, video digital y aplicaciones distribuidas de gran escala. Storage Tank aplica la técnica de virtualización del almacenamiento ; es decir, enmascara las características físicas de los dispositivos de almacenamiento, y presenta a los usuarios y aplicaciones un único pool de almacenamiento compartido. Brinda así a los administradores de almacenamiento incluso la flexibilidad de crear discos virtuales, así como establecer asignaciones basada en pólizas, gestión de volúmenes y archivos, etc. Los pools de almacenamiento pueden ser múltiples discos en diferentes dispositivos, que aparecen como una sola unidad, pudiendo aumentar o reducir el tamaño de ellos según las necesidades que surjan, así como mover datos de uno a otro sin problemas. Estas tareas son transparentes, y no interrumpen a los usuarios y aplicaciones. 7/10

Figura 4 Arquitectura de IBM Storage Tank Los clientes del Storage Tank de IBM, así como el cliente administrativo, se comunican con los servidores de Storage Tank mediante redes de IP existentes usando el protocolo de IBM Storage Tank. Todos deben estar conectados a áreas de almacenamiento en red de alta velocidad (SAN), tal como se observa en la figura 4. El cliente administrativo es el punto de control administrativo. Un administrador puede hacer casi todas las tareas administrativas en línea, sin interrumpir el servicio a los clientes. Un Installable File System (IFS, Sistema de archivos instalable) está instalado en cada cliente IBM Storage Tank. Un IFS dirige las solicitudes de metadatos a un servidor de IBM Storage Tank, y envía las solicitudes de datos a las unidades de almacenamiento en el SAN. Los clientes de IBM Storage Tank cachean datos de archivos en forma agresiva, así como también los metadatos que obtienen de un servidor de Storage Tank, en memoria. No cachean archivos al disco. Una empresa puede utilizar un sólo servidor de IBM Storage Tank, un cluster de ellos, o incluso múltiples clusters, que proveerán carga balanceada (la carga de trabajo y estructuras de datos se particiona y asigna a los servidores en el cluster todo el tiempo para lograr el balance), procesamiento de fallas (redistribuyen la carga entre el resto de los servidores si uno falla) y escalabilidad aumentada (un administrador puede agregar más servidores a un cluster, o más clusters de servidores al SAN para atender a más datos y más clientes). Algo no menor a aclarar es que IBM Storage Tank también provee backups para recuperarse de fallas del medio, así como datos corruptos. Además, puede usar dispositivos RAID y unidades de almacenamiento que hacen mirroring para ayudar a recuperar las fallas. 8/10

7. Futuros trabajos Lo presentado en el presente paper solamente es un título informativo respecto de la arquitectura general de algunos de los GFS actualmente existentes en el mercado, de modo de poder tener una idea más amplia de cómo trabaja en líneas generales un GFS. A partir lo aquí delineado, y tomando en consideración los enlaces de cada uno de los sistemas mencionados, es posible expandir el presente trabajo en un futuro mediante la realización de una comparación de cada uno de sus componentes, así como hacer una evaluación, frente a una carga determinada de tareas, de cómo se desempeñan para responder a la misma. De esta manera, podrá transformarse el carácter introductorio del presente trabajo en una herramienta útil a la hora de tomar la decisión de por qué sistema volcarse para organizar la estructura de datos de los Grids que se estén utilizando. 8. Conclusión A partir de la presentación dada de los tres sistemas de archivos Grid, es posible observar algunas características similares entre todos ellos: Replicación de archivos. Concentración de la administración de los servidores. Alta disponibilidad. Distribución del procesamiento para evitar cuellos de botellas. APIs y librerías propietarias para acceder a los recursos de dichos sistemas. Y, si bien difieren en cuanto a qué componentes tienen puntualmente (el GFarm con cuatro tipos de nodos diferentes; el SRB con servidores, agentes y un MCAT; el Storage Tank con su red SAN, su cliente administrativo y su cluster de servidores), todos trabajan de similar manera para cumplir con los objetivos propios de todo sistema de archivos Grid: brindar fuentes de datos con una alta confiabilidad y disponibilidad, a fin de facilitar el procesamiento de datos de diferentes aplicaciones de computación intensiva. Lo único que queda por mencionar, a modo de cierre, es que hubiera sido interesante encontrar al menos algún tipo de benchmarking entre los tres sistemas, a modo de hacer una evaluación quizás un poco más profunda. Sin embargo, al carecer de dichos datos, así como la dificultad de instalar y probar por cuenta propia estos tipos de aplicaciones, relegarán esa voluntad a un trabajo futuro. 9. Bibliografía Las siguientes URLs de Internet fueron consultadas para la realización del presente trabajo: Wikipedia, Grid File System definition: http://en.wikipedia.org/wiki/grid_filesystem GFarm file system, homepage: http://datafarm.apgrid.org Grid File System Working Group (GFS-WG), homepage: http://phase.hpcc.jp/ggf/gfs-rg/ SRB User Manual, homepage: http://www.sdsc.edu/srb/index.php/srb_user_manual 9/10

IBM Storage Tank, a distributed file system, IBM Corporation, Enero 2002: http://www.almaden.ibm.com/cs/storagesystems/stortank/extstoragetankpaper 01_24_02.pdf Gvu: A View-Oriented Framework for Data Management in Grid Environments, Pradeep Padala and Kang G. Shin, University of Michigan: http://www.eecs.umich.edu/~ppadala/research/gridfs/gvu.pdf 10/10