El sistema de archivos virtuales paralelos ( PVFS ) es un sistema de archivos paralelo de código abierto . Un sistema de archivos paralelo es un tipo de sistema de archivos distribuido que distribuye datos de archivos entre varios servidores y proporciona acceso simultáneo a múltiples tareas de una aplicación paralela. PVFS fue diseñado para su uso en computación en clúster a gran escala . PVFS se centra en el acceso de alto rendimiento a grandes conjuntos de datos. Consiste en un proceso de servidor y una biblioteca de cliente, ambos escritos completamente con código de nivel de usuario. Un módulo de kernel de Linux y un proceso pvfs-client permiten montar el sistema de archivos y usarlo con utilidades estándar. La biblioteca de cliente proporciona acceso de alto rendimiento a través de la interfaz de paso de mensajes (MPI). PVFS se está desarrollando conjuntamente entre el Laboratorio de Investigación de Arquitectura Paralela de la Universidad de Clemson y la División de Matemáticas y Ciencias de la Computación del Laboratorio Nacional Argonne , y el Centro de Supercomputación de Ohio . El desarrollo de PVFS ha sido financiado por el Centro de Vuelos Espaciales Goddard de la NASA, el programa de Investigación Científica Avanzada de la Oficina de Ciencias del DOE , los programas PACI y HECURA de la NSF y otras agencias gubernamentales y privadas. PVFS ahora se conoce como OrangeFS en su rama de desarrollo más nueva.
PVFS fue desarrollado por primera vez en 1993 por Walt Ligon y Eric Blumer como un sistema de archivos paralelo para la máquina virtual paralela (PVM) [1] como parte de una beca de la NASA para estudiar los patrones de E/S de programas paralelos. La versión 0 de PVFS se basó en Vesta, un sistema de archivos paralelo desarrollado en IBM TJ Watson Research Center . [2] A partir de 1994, Rob Ross reescribió PVFS para utilizar TCP/IP y se apartó de muchos de los puntos de diseño originales de Vesta. La versión 1 de PVFS estaba destinada a un grupo de estaciones de trabajo DEC Alpha conectadas en red mediante FDDI conmutada . Al igual que Vesta, PVFS distribuía datos en múltiples servidores y permitía solicitudes de E/S basadas en una vista de archivo que describía un patrón de acceso escalonado. A diferencia de Vesta, la distribución y la vista no dependían de un tamaño de registro común. La investigación de Ross se centró en la programación de la E/S de disco cuando varios clientes accedían al mismo archivo. [3] Los resultados anteriores habían demostrado que era preferible programar según el mejor patrón de acceso al disco posible. Ross demostró que esto dependía de una serie de factores, entre ellos la velocidad relativa de la red y los detalles de la visualización del archivo. En algunos casos, era preferible programar según el tráfico de la red, por lo que un programa adaptable dinámicamente proporcionaba el mejor rendimiento general. [4]
A finales de 1994, Ligon se reunió con Thomas Sterling y John Dorband en el Centro de Vuelos Espaciales Goddard (GSFC) y hablaron de sus planes para construir la primera computadora Beowulf . [5] Se acordó que PVFS se trasladaría a Linux y se incluiría en la nueva máquina. Durante los siguientes años, Ligon y Ross trabajaron con el grupo GSFC, que incluía a Donald Becker, Dan Ridge y Eric Hendricks. En 1997, en una reunión del grupo en Pasadena, California, Sterling pidió que PVFS se lanzara como un paquete de código abierto. [6]
En 1999, Ligon propuso el desarrollo de una nueva versión de PVFS, inicialmente denominada PVFS2000 y más tarde PVFS2. El diseño fue desarrollado inicialmente por Ligon, Ross y Phil Carns. Ross completó su doctorado en 2000 y se trasladó al Laboratorio Nacional de Argonne y el diseño y la implementación fueron llevados a cabo por Ligon, Carns, Dale Witchurch y Harish Ramachandran en la Universidad de Clemson , Ross, Neil Miller y Rob Latham en el Laboratorio Nacional de Argonne y Pete Wyckoff en el Centro de Supercomputadoras de Ohio. [7] El nuevo sistema de archivos se lanzó en 2003. El nuevo diseño presentaba servidores de objetos, metadatos distribuidos, vistas basadas en MPI, soporte para múltiples tipos de red y una arquitectura de software para una fácil experimentación y extensibilidad.
La versión 1 de PVFS se retiró en 2005. La versión 2 de PVFS aún cuenta con soporte de Clemson y Argonne. Carns completó su doctorado en 2006 y se unió a Axicom, Inc., donde PVFS se implementó en varios miles de nodos para minería de datos. En 2008, Carns se trasladó a Argonne y continúa trabajando en PVFS junto con Ross, Latham y Sam Lang. Brad Settlemyer desarrolló un subsistema de duplicación en Clemson y, más tarde, una simulación detallada de PVFS utilizada para investigar nuevos desarrollos. Settlemyer está ahora en Oak Ridge National Laboratory . En 2007, Argonne comenzó a portar PVFS para su uso en un IBM Blue Gene /P. [8] En 2008, Clemson comenzó a desarrollar extensiones para admitir directorios grandes de archivos pequeños, mejoras de seguridad y capacidades de redundancia. Como muchos de estos objetivos entraban en conflicto con el desarrollo de Blue Gene, se creó una segunda rama del árbol de código fuente de CVS, denominada "Orange", y la rama original se denominó "Blue". PVFS y OrangeFS se siguen muy de cerca, pero representan dos grupos diferentes de requisitos de usuario. La mayoría de los parches y actualizaciones se aplican a ambas ramas. A partir de 2011, OrangeFS es la línea de desarrollo principal.
En un clúster que utiliza PVFS, los nodos se designan como uno o más de los siguientes: cliente, servidor de datos, servidor de metadatos. Los servidores de datos contienen datos de archivos. Los servidores de metadatos contienen metadatos que incluyen información estadística, atributos y controladores de archivos de datos, así como entradas de directorio. Los clientes ejecutan aplicaciones que utilizan el sistema de archivos enviando solicitudes a los servidores a través de la red.
PVFS tiene un diseño basado en objetos, es decir, todas las solicitudes de servidor PVFS involucran objetos llamados espacios de datos. Un espacio de datos se puede utilizar para almacenar datos de archivos, metadatos de archivos, metadatos de directorio, entradas de directorio o enlaces simbólicos. Cada espacio de datos en un sistema de archivos tiene un identificador único. Cualquier cliente o servidor puede buscar qué servidor contiene el espacio de datos en función del identificador. Un espacio de datos tiene dos componentes: un flujo de bytes y un conjunto de pares clave/valor. El flujo de bytes es una secuencia ordenada de bytes, que normalmente se utiliza para almacenar datos de archivos, y los pares clave/valor se utilizan normalmente para almacenar metadatos. El diseño basado en objetos se ha vuelto típico de muchos sistemas de archivos distribuidos, incluidos Lustre , Panasas y pNFS .
PVFS está diseñado para que un cliente pueda acceder a un servidor de metadatos una vez y luego pueda acceder a los servidores de datos sin interacción adicional con los servidores de metadatos. Esto elimina un cuello de botella crítico del sistema y permite un rendimiento mucho mayor.
Cuando un programa cliente solicita datos de PVFS, puede proporcionar una descripción de los datos basada en MPI_Datatypes. Esta función permite que el sistema de archivos implemente directamente vistas de archivos MPI. Los MPI_Datatypes pueden describir patrones complejos no contiguos de datos. El servidor PVFS y los códigos de datos implementan flujos de datos que transfieren datos de manera eficiente entre varios servidores y clientes.
PVFS utiliza una capa de red denominada BMI que proporciona una interfaz de mensajes sin bloqueo diseñada específicamente para sistemas de archivos. BMI tiene múltiples módulos de implementación para una serie de redes diferentes utilizadas en informática de alto rendimiento, entre las que se incluyen TCP/IP, Myrinet , Infiniband y Portals . [9]
Los servidores PVFS están diseñados para no compartir ningún estado entre ellos ni con los clientes. Si un servidor falla, otro puede reiniciarse fácilmente en su lugar. Las actualizaciones se realizan sin utilizar bloqueos.
Los clientes y servidores PVFS se ejecutan a nivel de usuario. No se necesitan modificaciones del núcleo. Hay un módulo de núcleo opcional que permite montar un sistema de archivos PVFS como cualquier otro sistema de archivos, o los programas pueden vincularse directamente a una interfaz de usuario como MPI-IO o una interfaz similar a Posix . Estas características hacen que PVFS sea fácil de instalar y menos propenso a provocar fallas del sistema.
La interfaz PVFS está diseñada para integrarse a nivel de sistema. Tiene similitudes con el VFS de Linux , lo que hace que sea fácil de implementar como un sistema de archivos montable, pero es igualmente adaptable a interfaces de nivel de usuario como MPI-IO o interfaces similares a Posix . Expone muchas de las características del sistema de archivos subyacente para que las interfaces puedan aprovecharlas si así lo desean. [10] [11]
PVFS consta de 4 componentes principales y una serie de programas de utilidad. Los componentes son PVFS2-server, pvfslib, PVFS-client-core y el módulo kernel PVFS. Las utilidades incluyen la herramienta de administración karma, utilidades (por ejemplo, pvfs-ping, pvfs-ls, pvfs-cp, etc.) que operan directamente en el sistema de archivos sin usar el módulo kernel (principalmente para mantenimiento y pruebas). Otro punto clave del diseño es el protocolo PVFS que describe los mensajes que pasan entre el cliente y el servidor, aunque no es estrictamente un componente.
El servidor PVFS se ejecuta como un proceso en un nodo designado como nodo de E/S. Los nodos de E/S suelen ser nodos dedicados, pero también pueden ser nodos normales que ejecutan tareas de aplicación. El servidor PVFS normalmente se ejecuta como raíz, pero puede ejecutarse como usuario si se prefiere. Cada servidor puede administrar varios sistemas de archivos distintos y está designado para ejecutarse como servidor de metadatos, servidor de datos o ambos. Toda la configuración se controla mediante un archivo de configuración especificado en la línea de comandos, y todos los servidores que administran un sistema de archivos determinado utilizan el mismo archivo de configuración. El servidor recibe solicitudes a través de la red, lleva a cabo la solicitud que puede implicar E/S de disco y responde al solicitante original. Las solicitudes normalmente provienen de nodos de cliente que ejecutan tareas de aplicación, pero pueden provenir de otros servidores. El servidor está compuesto por el procesador de solicitudes, la capa de trabajo, Trove, BMI y las capas de flujo.
El procesador de solicitudes consta del bucle principal del proceso del servidor y de una serie de máquinas de estado. Las máquinas de estado se basan en un lenguaje simple desarrollado para PVFS que administra la concurrencia dentro del servidor y el cliente. Una máquina de estado consta de una serie de estados, cada uno de los cuales ejecuta una función de acción de estado C o llama a una máquina de estado anidada (subrutina). En cualquier caso, los códigos de retorno seleccionan a qué estado ir a continuación. Las funciones de acción de estado generalmente envían un trabajo a través de la capa de trabajo que realiza algún tipo de E/S a través de Trove o BMI. Los trabajos no son bloqueantes, de modo que una vez que se emite un trabajo, la ejecución de la máquina de estado se pospone para que otra máquina de estado pueda ejecutarse para atender otra solicitud. Cuando se completan los trabajos, el bucle principal reinicia la máquina de estado asociada. El procesador de solicitudes tiene máquinas de estado para cada uno de los diversos tipos de solicitud definidos en el protocolo de solicitud PVFS más una serie de máquinas de estado anidadas que se utilizan internamente. La arquitectura de la máquina de estado hace que sea relativamente fácil agregar nuevas solicitudes al servidor para agregar funciones u optimizar para situaciones específicas.
La capa de trabajo proporciona una interfaz común para enviar trabajos de Trove, BMI y de flujo e informar sobre su finalización. También implementa el programador de solicitudes como un trabajo sin bloqueo que registra qué tipo de solicitudes están en curso en qué objetos y evita errores de coherencia debido a la operación simultánea en los mismos datos de archivo.
Trove administra la E/S de los objetos almacenados en el servidor local. Trove opera en colecciones de espacios de datos. Una colección tiene su propio espacio de identificador independiente y se utiliza para implementar distintos sistemas de archivos PVFS. Un espacio de datos es un objeto PVFS y tiene su propio identificador único (dentro de la colección) y se almacena en un servidor. Los identificadores se asignan a los servidores a través de una tabla en el archivo de configuración. Un espacio de datos consta de dos partes: un flujo de bytes y un conjunto de pares clave/valor. Un flujo de bytes es una secuencia de bytes de longitud indeterminada y se utiliza para almacenar datos de archivos, normalmente en un archivo en el sistema de archivos local. Los pares clave/valor se utilizan para almacenar metadatos, atributos y entradas de directorio. Trove tiene una interfaz bien definida y se puede implementar de varias formas. Hasta la fecha, la única implementación ha sido la implementación Trove-dbfs que almacena flujos de bytes en archivos y pares clave/valor en una base de datos Berkeley DB . [12] Las operaciones de Trove no son bloqueantes, la API proporciona funciones posteriores para leer o escribir los distintos componentes y funciones para verificar o esperar la finalización.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}