Departamento de Telecomunicaciones y Electrónica

Título: Sistemas de archivos distribuido para Clúster HPC utilizando

Autor: Daniel Placencia Alvarez Tutor: Ing. Javier Antonio Ruiz Bosch

, Junio, 2019

Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu” de Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria “Chiqui Gómez Lubian” subordinada a la Dirección de Información Científico Técnica de la mencionada casa de altos estudios. Se autoriza su utilización bajo la licencia siguiente: Atribución- No Comercial- Compartir Igual

Para cualquier información contacte con: Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de Las Villas. Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830 Teléfonos.: +53 01 42281503-1419

Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en Telecomunicaciones y Electrónica, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.

Firma del Autor

Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.

Firma del Tutor Firma del Jefe de Departamento donde se defiende el trabajo

Firma del Responsable de Información Científico-Técnica i

PENSAMIENTO

Muchos de los fracasos en la vida lo experimentan personas que no se dan cuenta de cuan cerca estuvieron del éxito cuando decidieron darse por vencidos. Thomas Edison

ii

DEDICATORIA

A mi familia, especialmente a mis padres y a mi tía Carmen Rosa, por guiarme, apoyarme incondicionalmente y estar presente en cada momento.

iii

AGRADECIMIENTOS - A mi familia, especialmente a mis padres, mi hermana y mi tía Carmen Rosa, por su cariño, su apoyo incondicional y su dedicación.

- A mi tutor Javier Antonio Ruiz Bosch, por su dedicación.

- A mis compañeros de aula, que se convirtieron en grandes amigos en los peores momentos.

- A todos los profesores que durante estos cinco años han contribuido a mi formación profesional.

- A todos aquellos a los que de una forma u otra participaron en la realización de este trabajo.

iv

TAREA TÉCNICA Para el logro de los objetivos propuestos en el presente trabajo, la investigación sigue una línea de trabajo definida por un grupo de tareas, las cuales son:

 Revisión bibliográfica referida a los sistemas de almacenamiento de datos para Clúster HPC.  Análisis del hardware disponible para la implementación de esta tecnología.  Selección de la configuración de hardware y software más apropiada para implementar este sistema en el escenario de desarrollo.  Instalación, configuración y despliegue del software propuesto.  Evaluación del desempeño del sistema con diferentes herramientas.  Comparación del sistema propuesto con los sistemas actualmente implementados.  Análisis de los resultados de la implementación y las comparaciones realizadas.  Confección del trabajo de diploma.

Firma del Autor Firma del Tutor

v

RESUMEN Los sistemas de archivos distribuidos paralelos se hacen cada vez más populares y usados por las grandes posibilidades que brindan. Ceph se presenta como una plataforma de almacenamiento unificada, definida por software, con excelentes prestaciones para ambientes donde la velocidad es determinante como es el caso de los clústeres HPC. La presente investigación se dedica a la implementación de un sistema de archivos Ceph para el clúster HPC del Centro de Datos de la UCLV. Inicialmente se analizan las principales tecnologías de almacenamiento empleadas en la actualidad. Se explica paso a paso el proceso de instalación de un sistema de archivos Ceph. Se presenta el proceso de administración y gestión de un clúster Ceph, resaltando las principales variables que se monitorean y los fallos más comunes. Se realizan pruebas al clúster Ceph de estabilidad y rendimiento empleando diferentes herramientas. Además, se realizan pruebas de rendimiento al sistema NFS que brinda servicios al HPC, lo que permite realizar importantes comparaciones. Como conclusión se obtiene que el clúster Ceph permanece estable ante fallos de software y hardware que no superen su dominio de fallo y presenta un alto rendimiento en todas las operaciones con archivos, superior al del servidor NFS.

vi

ÍNDICE PENSAMIENTO ...... i

DEDICATORIA ...... ii

AGRADECIMIENTOS ...... iii

TAREA TÉCNICA ...... iv

RESUMEN ...... v

INTRODUCCIÓN ...... 1

CAPÍTULO 1. SISTEMAS DE ARCHIVOS ...... 4

1.1 Sistemas de archivos tradicionales ...... 5 1.1.1 ¿Qué es un sistema de archivos? ...... 5 1.1.2 Sistemas de archivos tradicionales y modernos ...... 6 1.2 Soluciones para alto desempeño y escalabilidad ...... 8 1.2.1 Sistemas de archivos de red ...... 8 1.2.4 Almacenamiento basado en objetos y basado en bloques ...... 15 1.3 Arquitecturas modernas para clúster HPC ...... 16 1.3.1 GPFS ...... 16 1.3.2 HDFS ...... 17 1.3.3 BeeGFS ...... 18 1.3.4 ...... 19 1.3.5 GlusterFS ...... 21 1.3.6 Ceph ...... 23 1.4 Selección del sistema de archivos a implementar en el Clúster HPC ...... 26 CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC ...... 29

2.1 Preparación del hardware y el software necesario ...... 30 2.1.1 Arquitectura básica del clúster Ceph ...... 30 2.1.2 Recomendaciones del hardware y software ...... 33 2.1.3 Preparación del entorno de instalación ...... 37 2.2 Procedimiento de instalación de Ceph empleando ceph-deploy ...... 39 2.3 Administración y supervisión del clúster Ceph ...... 48 2.4 Conclusiones del capítulo ...... 52 vii

CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC ...... 53

3.1 Estabilidad del clúster Ceph ante fallos de software y hardware ...... 54 3.2 Rendimiento del clúster Ceph ...... 57 3.2.1 RADOS Bench ...... 58 3.2.2 DD ...... 60 3.2.3 Bonnie++ ...... 61 3.3 Comparación con el sistema de archivos NFS ...... 64 3.4 Análisis de los resultados obtenidos ...... 66 3.5 Conclusiones del capítulo ...... 66 CONCLUSIONES Y RECOMENDACIONES ...... 67

Conclusiones ...... 67 Recomendaciones ...... 68 BIBLIOGRAFÍA ...... 69

ANEXOS ...... 72

Anexo I: Códigos de chequeo de salud del clúster Ceph más comunes ...... 72 Anexo II: Estados de los grupos de ubicación (PG) más comunes ...... 73 Anexo III: Ejemplo de configuración para enrutar dos subredes en Lustre ...... 75 Anexo IV: Estado del clúster Ceph unos segundos después de apagar el servidor ceph1 75 Anexo V: Estado del clúster Ceph en el proceso de recuperación luego de apagar el servidor ceph1 (parte I) ...... 76 Anexo VI: Estado del clúster Ceph en el proceso de recuperación luego de apagar el servidor ceph1 (parte II) ...... 76 Anexo VII: Estado del clúster Ceph en el proceso de recuperación luego de reincorporarse el servidor ceph1 ...... 77

INTRODUCCION 1

INTRODUCCIÓN

Los crecientes avances actuales en las diferentes áreas de la ciencia y la tecnología requieren cada vez más de sistemas de computación más potentes y rápidos. Para lograr este objetivo, la Computación de Alto Rendimiento (HPC) se apoya en tecnologías como la computación paralela y los clústeres. Las cargas de trabajo del HPC son notablemente elevadas con respecto a otros sistemas. En lugar de aplicaciones y archivos pequeños, un HPC suele funcionar con lotes de trabajos y grandes conjuntos de datos divididos en grandes clústeres informáticos distribuidos. Generalmente se requieren sistemas de archivos distribuidos paralelos para obtener la alta razón de transferencia que necesita el acceso simultáneo a datos. Al carecer de la capacidad de compartir datos, las CPU retrasan el procesamiento. Además, es muy necesario mantener una elevada disponibilidad de los datos y que estos permanezcan seguros a pesar de los fallos de software o hardware que puedan ocurrir, pues una pérdida de datos puede significar la pérdida de meses o años de trabajo.

En este sentido, se hace necesaria la elección e implementación de un sistema de archivos capaz de cubrir estas necesidades y requerimientos. Ceph se presenta como una de las posibles soluciones para los ambientes HPC. Se trata de un sistema de archivos distribuido paralelo diseñado para el uso con gran cantidad de datos. Es libre, de código abierto y tiene el objetivo de ser POSIX-compatible. Proporciona una plataforma de almacenamiento unificada y definida por software para servidores, discos estándares y económicos, se adapta a una gran variedad de hardware por lo que permite seleccionar este de acuerdo a las necesidades y costos. Combina el almacenamiento de objetos, bloques y sistemas de archivos en una sola plataforma unificada y se encarga de gestionar de manera eficaz y automática todos sus datos. Sus niveles de rendimiento están optimizados para soportar la latencia y los requisitos de ancho de banda de lectura/escritura de las cargas de trabajo de los ambientes de alto rendimiento.

En el proyecto HPC Cuba, especialmente en el HPC de la UCLV fue necesaria la implementación de un sistema de almacenamiento Ceph, debido a las crecientes necesidades y requerimientos del mismo en este sector. INTRODUCCION 2

El presente estudio brinda información relacionada con los sistemas de almacenamiento, especialmente los sistemas de archivos especializados en escenarios de HPC y con el equipamiento disponible actualmente en el Centro de Datos de la UCLV se expondrá el proceso de implementación de Ceph y sus resultados. Además, pretende servir de guía para la implementación y despliegue de un clúster Ceph, de ahí su utilidad metodológica.

Tomando en consideración lo antes expuesto, se plantea el siguiente problema de investigación: ¿Cómo mejorar el desempeño, la disponibilidad y estabilidad del Clúster HPC mediante la implementación de un sistema de archivos que cumpla con los estándares de escalabilidad, desempeño y confiabilidad requeridos en la actualidad?

Para dar cumplimiento al problema de investigación se propone el siguiente objetivo general: Implementar un sistema de archivos Ceph para clúster HPC.

Para lograr desarrollar este objetivo se plantean los siguientes objetivos específicos:

 Realizar un análisis crítico de la literatura científica relacionado con el estado del arte de los sistemas de almacenamiento para clúster HPC.  Realizar una descripción del software y la arquitectura de hardware a emplear en el escenario de desarrollo.  Implementar el sistema de almacenamiento distribuido Ceph en el clúster HPC.  Evaluar el desempeño general del sistema con diferentes herramientas, y compararlo con las tecnologías de almacenamiento actualmente implementadas.

De los objetivos específicos propuestos, surgen las siguientes interrogantes científicas:

 ¿Cuál es el estado del arte de los sistemas de almacenamiento para clúster HPC?  ¿Cuál es la alternativa más apropiada para la implementación de un sistema de almacenamiento distribuido en el clúster HPC?  ¿Cuál es la configuración del hardware disponible y del software propuesto más adecuada para el escenario de desarrollo?  ¿Cómo evaluar el desempeño del sistema de almacenamiento implementado?

Con este proyecto se pretende mejorar las condiciones actuales del clúster HPC referidas al almacenamiento de datos, posibilitando una mayor disponibilidad del mismo y una mayor INTRODUCCION 3 calidad de los servicios que este brinda. Lo cual tiene un impacto positivo en los usuarios que hacen uso de este, contribuyendo a las importantes investigaciones y proyectos que se desarrollan gracias a estos recursos.

Organización del informe:

Para cumplir los objetivos establecidos, el informe de la investigación se estructuró en: introducción, tres capítulos, conclusiones, recomendaciones, referencias bibliográficas y anexos.

En el capítulo 1 se tratará la reseña histórica de los sistemas de almacenamiento, tanto los tradicionales como los modernos. Se expondrán las soluciones de almacenamiento para alto desempeño y escalabilidad más empleadas en la actualidad, las arquitecturas sobre las que pueden trabajar y los esquemas de funcionamiento, haciendo especial hincapié en las arquitecturas modernas de almacenamiento para clústeres. Finalmente, se expondrán las razones de la elección de Ceph como sistema de almacenamiento para el clúster HPC.

Luego, el capítulo 2 se dedicará a la implementación de un sistema de archivos Ceph. Se propondrá la arquitectura de red a emplear y se realizará el proceso de preparación, instalación, configuración y despliegue del software. Además, se explicarán los comandos básicos para la administración, supervisión y recuperación de errores del clúster Ceph.

Por último, en el capítulo 3 se expondrán los resultados de la implementación del sistema de archivos Ceph en el clúster del Data Center de la UCLV y las pruebas realizadas al mismo. Comparándolo con otras tecnologías que se emplean actualmente. CAPÍTULO 1. SISTEMAS DE ARCHIVOS 4

CAPÍTULO 1. SISTEMAS DE ARCHIVOS

El sistema de archivos es una parte importante en casi todos los sistemas de cómputo actuales. Este puede determinar en cierta medida la rapidez y estabilidad con la que determinada computadora puede funcionar. Por esta razón en la actualidad se ha prestado mucha atención al desarrollo de los sistemas de archivos. Existe una gran variedad de estos, casi todos los sistemas operativos cuentan con uno propio y tienen cierta compatibilidad con los demás.

En el presente capítulo se abordan las generalidades acerca de los sistemas de archivos, partiendo desde los más básicos y sencillos hasta los más avanzados.

En el primer epígrafe se exponen los conceptos fundamentales sobre los sistemas de archivos, sus clasificaciones, usos más frecuentes, ventajas y limitaciones. Se tratan los sistemas de archivos tradicionales y modernos haciendo énfasis en los más empleados en la actualidad.

En el segundo epígrafe se tratan detalladamente las soluciones de almacenamiento para alto desempeño y escalabilidad. Se explican conceptos importantes como qué es un sistema de archivos de red, qué son los sistemas de archivos distribuidos y los sistemas de archivos paralelos, que tienden a ser confusos por sus semejanzas y relaciones. Además, se tratan algunas tecnologías de almacenamiento como RAID, NAS y JBOD cuyo uso está muy extendido en la actualidad.

En el tercer epígrafe se tratan específicamente las arquitecturas modernas de almacenamiento para Clúster HPC. Se señalan algunas características de cada una como la arquitectura de hardware que utilizan, arquitecturas de red, configuraciones de disco duro con los que puede trabajar, el software y los protocolos que emplean. Se realizan algunas comparaciones entre los sistemas tratados con el objetivo de seleccionar la mejor opción para implementar en el escenario del HPC. Finalmente, se demuestra la selección de Ceph como sistema de archivos a implementar en el HPC.

CAPÍTULO 1. SISTEMAS DE ARCHIVOS 5

1.1 Sistemas de archivos tradicionales Desde el surgimiento de los primeros medios de almacenamiento, en los inicios de la computación en el siglo XX, es un tema relevante la forma en que la información se almacena en ellos. Desde los papeles perforados y las cintas magnéticas usados en los primeros ordenadores hasta los actuales sistemas de almacenamiento, todos tienen algo en común: la información no es almacenada de forma caótica y sin sentido, existen estándares o protocolos para almacenar la información en cada uno de ellos, lo que permite su posterior recuperación y entendimiento por parte del sistema de cómputo y el usuario. A este conjunto de reglas o protocolos es a lo que llamamos “sistema de archivos”. El concepto de sistema de archivos fue definido por primera vez en 1965 en el Instituto Tecnológico de Massachusetts (Fall Joint Computer Conference[1]).

1.1.1 ¿Qué es un sistema de archivos? En computación, un sistema de archivos o sistema de ficheros es el componente del sistema operativo encargado de administrar y facilitar el uso de las memorias periféricas, ya sean secundarias o terciarias[2]. Controla como los datos son almacenados y recuperados. Sin un sistema de archivos, la información almacenada en un medio de almacenamiento podría ser un largo cuerpo de datos sin una forma de determinar donde comienza o termina una determinada pieza de información. Separando los datos en bloques o piezas y dándole a cada una de estas un nombre, hace más fácil el proceso de identificar y recuperar la información. A estos bloques o piezas de datos es a lo que llamamos archivo. La estructura y reglas lógicas usadas para manejar los archivos y sus nombres es a lo que llamamos sistema de archivos[3].

Los sistemas de archivos proveen métodos para crear, mover, renombrar y eliminar tanto archivos como directorios. De esta forma, el usuario o las aplicaciones no tiene que preocuparse por cuestiones como puede ser en qué sector del dispositivo de almacenamiento está ubicado un archivo. Existen tres claves de abstracción que son las unidades básicas de todo sistema de archivos: los archivos, los nombres de archivo, y el árbol de directorios o carpetas[4][5].

Un archivo es una secuencia ordenada de elementos, donde un elemento puede ser una palabra de máquina, un carácter o un bit, dependiendo de la implementación. Al nivel del CAPÍTULO 1. SISTEMAS DE ARCHIVOS 6 sistema de archivos un archivo no tiene formato, todos los formatos son dados a nivel de aplicación de usuario.

Un directorio es un archivo especial que es mantenido por el sistema de archivos, el cual contiene una lista de entradas. Cada entrada es el nombre simbólico de un archivo u otro directorio y tiene la propiedad de ser única solamente en el directorio al que pertenece[1].

Otro concepto importante es el de jerarquía de directorios o árbol de directorios[6]. El árbol de directorios es una forma de mostrar todos los directorios de una unidad de almacenamiento (como un disco duro, un disquete, un disco óptico, etc.) en forma de estructura de árbol. La raíz del árbol suele ser el directorio raíz, el cual se descompone en nodos, que son los subdirectorios. Y dentro de los nodos están los archivos (ver la Figura 1.1).

Figura 1.1 Jerarquía de directorios[6]

1.1.2 Sistemas de archivos tradicionales y modernos Existen muchos tipos de sistemas de archivos. Cada uno con una estructura y lógica diferente, con propiedades de velocidad, flexibilidad, seguridad, tamaño, etc. Los sistemas de archivos pueden ser clasificados en tres ramas fundamentales[7]:

 Sistemas de archivos de disco.  Sistemas de archivos de red.  Sistemas de archivos de propósito especial.

Según el Diccionario de Informática y Tecnología[8] un sistema de archivo de disco es un tipo especial de sistema de archivos diseñado para el almacenamiento, acceso y manipulación de archivos en un dispositivo de almacenamiento. Está diseñado para el almacenamiento de archivos en una unidad de disco, que puede estar conectada directa o indirectamente a la computadora[9]. Son sistemas de archivos de disco: EFSa, , , FAT (sistema de CAPÍTULO 1. SISTEMAS DE ARCHIVOS 7 archivos de DOS y algunas versiones de Windows), UMSDOS, FFS, Fossil, HFS (para Mac OS), HPFS, ISO 9660 (sistema de archivos de solo lectura para CD-ROM), JFS, kfs, MFS (para Mac OS), Minix, NTFS (sistema de archivos de Windows NT, XP y otras versiones de Windows), OFS, ReiserFS, , UDF (usado en DVD y en algunos CD-ROM), UFS, XFS, etc [8]. Por la importancia que suponen para el presente trabajo se presentarán a continuación algunas características de la familia EXT y de XFS.

Familia EXT[10]: El sistema de archivos extendido (ext, del inglés extended ), fue el primer sistema de archivos creado específicamente para el sistema operativo Linux. Sus versiones más relevantes son ext2, ext3 y . El sistema de archivos más reciente de esta familia es ext4, el cual presenta una serie de mejoras que lo hacen muy superior a los anteriores ext2 y ext3, aunque mantiene muchas características de ext3. Entre estas mejoras está que agrega direccionamiento de bloque de 48 bits, compatibilidad hacia delante y hacia atrás, asignación persistente y retrasada de espacio en disco, suma de chequeo del registro por diario (del inglés Journal checksumming), desfragmentación en línea, mejoras relacionadas con el desempeño y velocidades de lectura/escritura, entre otras [11] .

XFS[12]: XFS es un sistema de archivos de 64 bits altamente escalable y de alto desempeño con registro por diario (del inglés journaling). Soporta un sistema de archivos de hasta 8 exabytes, aunque esto puede variar dependiendo de los límites impuestos por el sistema operativo. Es compatible con el registro de metadatos, lo que permite una recuperación más rápida después de una caída del sistema. También se puede fragmentar y ampliar mientras está montado y activo, aunque no puede ser reducido en tamaño. Está diseñado para lectura/escritura paralela basada en grupos de asignación. Esto permite que un sistema se amplíe según la cantidad de subprocesos de lectura/escritura y el ancho de banda del sistema de archivos. Una característica notable de XFS es la tasa de lectura/escritura garantizada (GRIO). Esto permite que las aplicaciones reserven ancho de banda, lo que puede ser muy útil en aplicaciones integradas. El sistema de archivos calcula el rendimiento disponible y ajusta su funcionamiento de acuerdo con las reservas existentes[13].

Los sistemas de archivos de red se tratarán con más detalle en el siguiente epígrafe.

En la clasificación de sistema de archivos de propósito especial entran todos los demás sistemas de archivos que no son ni sistemas de archivos de disco ni sistemas de archivos de CAPÍTULO 1. SISTEMAS DE ARCHIVOS 8 red. Entre ellos podemos mencionar swap, , wikifs, udev, , entre otros [14] . Por su naturaleza, el estudio de este tipo de sistemas de archivos no es de interés para el presente trabajo.

1.2 Soluciones para alto desempeño y escalabilidad Desde el surgimiento de las redes de computadoras se hizo evidente la necesidad de compartir los archivos a través de la red, debido a las grandes ventajas que esto trae consigo tanto para las redes personales como para las redes a nivel empresarial. La disponibilidad de la información en cualquier punto de trabajo y la posibilidad de compartir archivos con gran rapidez y confiabilidad son factores que han demostrado ser de suma importancia para el modelo de desarrollo actual en el mundo de la computación. Los sistemas de archivos tradicionales, como los anteriormente mencionados, no están diseñados para este objetivo. Por estas razones surgen los llamados sistemas de archivos de red.

1.2.1 Sistemas de archivos de red Un sistema de archivos de red es un tipo especial de sistema de archivos que permite el acceso a los archivos a través de la red como si estuviesen en un medio de almacenamiento local[15]. Generalmente existe uno o varios servidores que son las computadoras en donde reside el sistema de archivos físicamente, y por otro lado están los clientes, que se valen del servidor para ver sus archivos y directorios. En general, lo que proveen los servidores es un medio de que los clientes, localmente, realicen peticiones de operaciones sobre archivos, las cuales son atrapadas por un controlador o un módulo en el núcleo del sistema operativo que se comunica con el servidor a través de la red y la operación se ejecuta en el servidor [15]. Existen servidores de tipo "stateless y no-stateless" (sin estado y con estado). Un servidor "stateless" no registra el estado de las operaciones sobre los archivos, de manera que el cliente se encarga de todo ese trabajo. Cuando un cliente envía una solicitud al servidor, este la procesa y envía la respuesta correspondiente, luego elimina de sus tablas internas toda la información correspondiente a dicha solicitud, o sea, que no guarda la información relativa a los clientes entre las solicitudes. Las ventajas de este esquema son que, si el servidor falla, el cliente no perderá información ya que esta se guarda en memoria localmente, de manera que cuando el servidor reanude su servicio el cliente proseguirá como si nada hubiese sucedido y que no existe límite en cuanto al número de archivos abiertos. En un servidor "no-stateless" o CAPÍTULO 1. SISTEMAS DE ARCHIVOS 9

"statefull" se conserva la información de estado de los clientes entre las solicitudes. Esto es lo que ocurre en los sistemas centralizados. La ventaja de estos sistemas es que se manejan mensajes de solicitud más cortos lo que se traduce a un menor ancho de banda y un mejor desempeño [15].

1.2.1.1 Sistema de archivos distribuido Un sistema de archivos distribuido (SAD) permite el acceso a los datos desde múltiples máquinas por medio de la red [16]. Los archivos son almacenados en una o más máquinas de la red llamadas servidores y se hacen accesibles a otras máquinas denominadas clientes, donde se manipulan como si fueran locales. Las máquinas clientes no tienen acceso por lo general a los bloques de almacenamiento de forma directa, sino que pueden acceder a los datos a través de la red por medio de algún protocolo de red [17]. Un sistema de archivos distribuido tiene dos componentes fundamentales razonablemente distintos: el servicio de archivos y el servicio de directorios. El primero se encarga de la gestión de archivos y acceso a datos, las operaciones en los archivos individuales como la lectura, escritura y adición; mientras que el segundo se encarga de la traducción de nombres de usuario a nombres internos, crear, leer, renombrar y eliminar los directorios. De esta forma un sistema de archivos distribuido queda estructurado como muestra la Figura 1.2:

Figura 1.2 Estructura de un Sistema de Archivos Distribuido

Para el diseño de los sistemas de archivos distribuidos se tienen en cuenta una serie de requisitos o parámetros [18]. A continuación, se mencionan los más importantes: CAPÍTULO 1. SISTEMAS DE ARCHIVOS 10

1- Transparencia 2- Actualizaciones concurrentes de archivos 3- Replicación de archivos 4- Heterogeneidad de hardware y de software 5- Tolerancia a fallos 6- Consistencia 7- Seguridad 8- Eficiencia Uno de los ejemplos clásicos de sistema de archivos distribuido que ha sido y es usado ampliamente es NFS [19]. Se trata de un protocolo de nivel de aplicación según el modelo OSI, para proveer acceso remoto transparente a archivos compartidos a través de la red. Está diseñado para ser portable a través de diferentes máquinas, sistemas operativos, arquitecturas de red y protocolos de transporte. Esta portabilidad se le atribuye al uso de las Llamadas de Procedimiento Remoto (Remote Procedure Call o RPC) que actualmente están implementadas en una gran variedad de máquinas, desde computadores personales hasta supercomputadoras. Las especificaciones de RPC proveen una interfaz orientada a los procedimientos de los servicios remotos. Cada servicio provee un “programa” que es un conjunto de procedimientos. NFS en uno de esos programas. El asunto de NFS es no requerir ningún nivel específico de confiabilidad en los niveles más bajos, entonces puede ser potencialmente usado con varios protocolos de transporte subyacentes. Este protocolo está diseñado para ser sin estado (stateless). NFS no define nada acerca del sistema de archivos en sí, solo el protocolo de cómo acceder a los archivos de este. Cualquier máquina sencilla puede ser un servidor y cliente NFS a la vez, independientemente del sistema de archivos local que emplee.

Otro ejemplo de sistema de archivos distribuido ampliamente usado en la actualidad es (SMB o CIFS). Se trata de un protocolo de nivel de aplicación según el modelo OSI para compartir archivos, impresoras, puertos serial y abstracciones de comunicación entre computadoras a través de la red. Se emplea fundamentalmente en computadoras con sistema operativo Windows o DOS y funciona generalmente sobre los protocolos TCP/IP. CAPÍTULO 1. SISTEMAS DE ARCHIVOS 11

En el campo del almacenamiento de datos es común el uso de algunas tecnologías para incrementar las prestaciones de los sistemas de archivos. Tal es el caso de RAID [20] (Arreglo Redundante de Discos Independientes). Se trata de una tecnología que es usada para incrementar el rendimiento y/o la fiabilidad en el almacenamiento de datos, consiste en dos o más discos duros trabajando en paralelo. El software para implementar la funcionalidad RAID y controlar los discos duros puede estar localizado en tarjetas controladoras independientes (un hardware especializado que contiene el controlador RAID) o puede ser simplemente un controlador del sistema operativo. El controlador de hardware para RAID es evidentemente más costoso que los controladores basados en software solamente, pero ofrecen un rendimiento muy superior. Hay diferentes niveles para RAID, cada uno optimizado para situaciones específicas. A continuación, se muestran los niveles más comúnmente usados:

 RAID 0 – división: En este tipo de sistema los datos son divididos en bloques que son escritos en todos los discos duros del arreglo. Usar múltiples discos (mínimo 2) al mismo tiempo ofrece un rendimiento de escritura/lectura superior. Este rendimiento puede ser mejorado si se usan múltiples controladores, lo ideal es usar un controlador por disco duro. El principal problema de este sistema es que no es tolerante a fallos.  RAID 1 – réplica: En este caso los datos son almacenados dos veces, escribiéndolos en el disco duro de datos (o conjunto de discos duros de datos) y en el disco duro espejo (o conjunto de discos duros espejos). De esta forma si uno de los discos falla, el sistema podrá recuperarse empleando la otra copia de los datos y continuar prestando servicio. La principal desventaja para esta opción es que la capacidad total del arreglo disminuye a la mitad de la capacidad real de los discos y que generalmente en caso de fallo de un disco, no es posible cambiarlo sin apagar el servidor en el que está alojado, lo cual no es aceptable para el caso de los servidores que continuamente están prestando servicios a múltiples usuarios.  RAID 5 – división con paridad: El nivel RAID 5 se considera uno de los más seguros. Su implementación requiere como mínimo 3 discos duros. Los bloques de datos son divididos a través de los CAPÍTULO 1. SISTEMAS DE ARCHIVOS 12

discos duros y en uno de estos se escribe el chequeo de paridad de los bloques de datos. Los datos de paridad no son escritos en un único dispositivo, estos son distribuidos a través de todos los discos duros. Usando los datos de paridad, el sistema podrá recuperarse y permanecer disponible en caso de fallo de uno de los discos duros, con un menor impacto en la cantidad de almacenamiento disponible que el caso de RAID 1. La principal desventaja en este tipo de arreglos es que, en caso de fallo en unos de los discos duros, el proceso de recalcular los datos puede tomar una gran cantidad de tiempo dependiendo de la carga de trabajo del arreglo y de la velocidad de los controladores; el fallo de otro disco mientras se están reconstruyendo el sistema ocasiona pérdida permanente de datos.  RAID 6 – división con doble paridad: Este nivel es muy semejante a RAID 5 en cuanto a su funcionamiento, pero introduce una mejora. Los datos de paridad son almacenados dos veces en discos diferentes, por lo que pueden fallar hasta dos discos a la vez y el sistema permanecerá operativo. Requiere de un mínimo de 4 discos duros.  RAID 10 – combinación de división y réplica: Es posible combinar las ventajas y desventajas de los niveles RAID 0 y 1 en un único sistema, lo que provee seguridad replicando los datos en discos duros espejo mientras que se distribuyen los datos a través de todos los discos del arreglo aumentando las velocidades de transferencia.

Existen otros niveles de RAID e incluso múltiples combinaciones de estos que pueden ser convenientes de acuerdo a la situación en cuestión, pero su explicación se escapa del interés del presente trabajo. Es necesario aclarar que RAID nunca debe considerarse como un sistema de respaldo, a pesar de que este puede recuperarse de un determinado número de fallos simultáneos de acuerdo al nivel o combinación de estos implementado, por lo que se recomienda mantener copias de seguridad de todos los datos.

Otra de las tecnologías ampliamente usadas en la actualidad es NAS [21] (almacenamiento conectado a la red). Se trata de un hardware equipado con varios discos duros que a la vez está conectado directamente a la red y son accesibles empleando protocolos de archivos como NFS y SMB. Su configuración es generalmente sencilla ya que se hace a través de un CAPÍTULO 1. SISTEMAS DE ARCHIVOS 13 software distribuido por el fabricante que puede ser una página web de configuración. Internamente, un dispositivo NAS puede implementar diferentes niveles de RAID, por lo que es común encontrar opciones en la configuración para seleccionar el nivel de RAID que se utilizará. Además, muchos dispositivos NAS soportan el modo JBOD [22] (Solo un Montón De Discos, del inglés just a bunch of disks), que, como RAID, presenta múltiples discos como un disco lógico único, pero sin la capacidad de redundancia y/o réplica de datos. Su principal ventaja es que puede trabajar con discos duros de diferentes tamaños, lo cual no es aconsejable para RAID ya que la capacidad final se verá afectado por el disco duro de menor capacidad.

1.2.1.2 Sistema de archivos paralelo Un sistema de archivos paralelos[23] es un tipo de sistema de archivos distribuido. Es un componente de software diseñado para almacenar datos a través de múltiples servidores conectados en red (generalmente llamados nodos), para facilitar un acceso simultáneo y de alto rendimiento a estos y coordinar operaciones de lectura/escritura entre los clientes y los nodos de almacenamiento. La característica más importante que caracteriza a los sistemas de archivos paralelos es que la lectura y escritura de datos desde y hacia los dispositivos de almacenamiento distribuido se realiza usando múltiples trayectorias a la misma vez, como parte de uno o más procesos de un programa de computación; por esta razón son llamados paralelos. El uso coordinado de múltiples trayectos de lectura/escritura puede proveer significantes beneficios en el desempeño, especialmente cuando existen grandes cargas en el flujo de datos y un gran número de clientes que acceden simultáneamente. La capacidad y el ancho de banda pueden ser escalados para acomodar enormes volúmenes de datos, y generalmente poseen características para aumentar la disponibilidad, replicación de los datos y toma de instantáneas.

Las principales diferencias entre los sistemas de archivos paralelos [5] y los no paralelos son que en los sistemas no paralelos todos los clientes accediendo a una porción dada del espacio de nombres, acceden a través del mismo nodo de almacenamiento a los datos y a los metadatos, aun cuando alguna parte del archivo está almacenada en otro nodo. Con un sistema paralelo, los clientes tienen acceso directo a todos los nodos de almacenamiento para transferir datos sin tener que pasar a través de un único servidor de coordinación. Los CAPÍTULO 1. SISTEMAS DE ARCHIVOS 14 sistemas no paralelos generalmente usan protocolos estándares de acceso a archivos por red, como puede ser NFS o SMB, para acceder al servidor de almacenamiento; en el caso de los paralelos, comúnmente requieren la instalación de algún controlador de software en el cliente para acceder a los servidores de almacenamiento.

En este tipo de sistemas la información de metadatos de los archivos se almacena en uno o varios nodos dedicados especialmente a esta función, estos son los llamados servidores de metadatos, la Figura 1.3 muestra la arquitectura típica de los sistemas paralelos:

Flujos de acceso

Figura 1.3 Arquitectura de un sistema de archivos paralelo Como se observa los caminos para acceder a los metadatos de archivo y a los archivos en sí son independientes y los clientes tienen acceso a todos los nodos que almacenan información. Además, es común que todos los nodos pertenecientes al sistema de archivos se conecten a dos redes independientes. Una es llamada red pública, a través de la cual los clientes accederán al sistema de archivos. La otra es llamada red del clúster, que se emplea única y exclusivamente para las comunicaciones internas del sistema de archivos, o sea, solo es empleada para los procesos de administración, replicación, coordinación, sincronización, etc., entre los nodos que conforman el sistema de archivos. Lógicamente ningún usuario no autorizado debe tener acceso a esta red, por los problemas de seguridad e inestabilidad que esto puede provocar.

Entre las ventajas de la implementación de sistemas de archivos paralelos sobre los no paralelos están que estos son altamente escalables, soportan replicación de datos como característica esencial en su diseño, soportan administración basada en políticas, provee altas CAPÍTULO 1. SISTEMAS DE ARCHIVOS 15 razones de transferencia, alto desempeño para computación de alto rendimiento y estabilidad. Los sistemas de archivos paralelos históricamente han estado dirigidos a los ambientes de computación de alto rendimiento.

1.2.4 Almacenamiento basado en objetos y basado en bloques Para entender el funcionamiento de los sistemas de archivos modernos, es importante entender estos dos conceptos. Se trata de dos formas diferentes de almacenar los datos que bridan sus ventajas y desventajas y están diseñados para diferentes escenarios.

El almacenamiento basado en objetos [24] es una aproximación para abordar y manipular el almacenamiento de datos como unidades discretas. El almacenamiento de archivos tradicional emplea las jerarquías de directorios, y cuando se necesita acceder a los datos, como los archivos se anidan dentro de una carpeta que a la vez está dentro de otras carpetas, el sistema informático solo necesita saber la ruta para encontrarlo. El almacenamiento de objetos elimina estas estructuras jerárquicas y coloca todo en un espacio de direcciones plano denominado agrupación de almacenamiento (del inglés storage pool). Cada archivo o grupo de estos puede estar representado por un objeto al cual se le añaden todo sus metadatos asociados y otros metadatos ampliados que pueden permitir todo tipo de análisis sobre el uso y la función de los datos. Cada archivo tiene una cantidad constante de objetos. El software del sistema de archivos utiliza un identificador único asignado el objeto para encontrar cualquier objeto en particular. Entre las principales ventajas de este tipo de almacenamiento está la mayor posibilidad de analizar los datos y la capacidad de almacenar un objeto en cualquier lugar dentro de un conjunto de datos distribuidos. Además, el espacio de direcciones plano permite que pueda escalar fácilmente añadiendo más almacenamiento a la agrupación. Los inconvenientes principales de esta forma de almacenamiento es que, por lo general, es más lento que sus homólogos y los objetos no se pueden modificar, hay que escribirlos y leerlos en su totalidad.

El almacenamiento basado en bloques [25] es un tipo de almacenamiento de datos que se suele utilizar en sistemas de archivos de red donde los datos se almacenan en volúmenes. Cada volumen actúa como un disco duro individual y es configurado por el administrador del sistema. Debido a que los volúmenes se tratan como discos duros individuales, funciona bien para almacenar una variedad de aplicaciones, como sistemas de archivos y bases de CAPÍTULO 1. SISTEMAS DE ARCHIVOS 16 datos. En este caso los archivos se dividen en bloques de datos de tamaño uniforme, cada uno con su propia dirección, pero sin información adicional (metadatos) que proporcione más contexto de lo que es ese bloque de datos. Las ventajas de este tipo de almacenamiento es que el sistema operativo puede acceder directamente al almacenamiento de bloques como un volumen de unidad montado. Es ideal para datos de acceso y edición frecuente.

1.3 Arquitecturas modernas para clúster HPC Los entornos HPC son muy exigentes en el subsistema de almacenamiento de datos. Teniendo en cuenta que las unidades de disco tradicionales son el componente más lento en cualquier arquitectura de computadora, es de vital importancia diseñar y dimensionar adecuadamente el sistema de almacenamiento de datos para aplicaciones HPC. Las siguientes son consideraciones importantes a evaluar al seleccionar el almacenamiento para la carga de trabajo del HPC:

 Razón de transferencia (Throughput)  Cantidad de flujos de acceso  Escalabilidad  Flexibilidad  Disponibilidad  Costo

Actualmente existen una serie de softwares que cumplen en cierta medida los requerimientos para ser empleados en entornos HPC como sistemas de archivos. A continuación, se hace una breve descripción de las opciones consideradas en el presente trabajo, para la implementación del sistema de archivos del HPC. Se analizarán las arquitecturas de software y hardware sobre las que estos trabajan.

1.3.1 GPFS General Parallel File System (GPFS) [26] es un sistema de archivos empresarial, de propósito general, distribuido, paralelo y de alto rendimiento desarrollado por IBM. Soporta miles de nodos y petabytes de almacenamiento por lo que se puede modificar su escala para satisfacer las necesidades. Los datos son replicados a través de múltiples nodos y no existe un único punto de fallo. Es una solución de gestión de archivos y discos compartidos de alto CAPÍTULO 1. SISTEMAS DE ARCHIVOS 17 rendimiento que proporciona un acceso rápido y fiable a datos desde varios nodos en entornos de clúster. Las aplicaciones pueden acceder fácilmente a los archivos utilizando las interfaces de sistemas de archivos, y al mismo archivo se puede acceder simultáneamente desde varios nodos. Se ha diseñado para ofrecer alta disponibilidad mediante tecnologías avanzadas de agrupación en clúster, gestión de sistemas de archivos dinámicos y de duplicación de datos.

Una de las desventajas de este sistema de archivos es que no es libre ni de código abierto. Lo que puede suponer algunos inconvenientes para su despliegue.

1.3.2 HDFS Hadoop Distributed File System (HDFS) [27] es un sistema de archivos distribuido liberado como software libre por la Apache Software Fundation. Está diseñado para funcionar en una gran variedad de hardware de bajo costo y es altamente tolerante a fallos. Provee acceso a los datos de las aplicaciones a una alta razón de transferencia y es conveniente para aplicaciones que manejan archivos muy grandes. Cumple con algunos requisitos POSIX.

HDFS tiene una arquitectura de master/esclavo. Un clúster HDFS consiste en un nodo único llamado NameNode y varios nodos llamados DataNodes. El NameNode es un servidor master que gestiona el espacio de nombres del sistema de archivos y regula el acceso de los usuarios a los archivos. Los DataNodes gestionan los dispositivos de almacenamiento del servidor en el que están corriendo. HDFS permite que los datos de usuarios sean almacenados en archivos que, internamente, son segmentados en uno o más bloques, y esos bloques son almacenados en el conjunto de DataNodes. El NameNode ejecuta operaciones como apertura, cierre y renombrado de archivos y directorios. Además, determina la ubicación de los bloques de un archivo en el conjunto de DataNodes. Los DataNodes son los responsables de atender los pedidos de lectura y escritura de los clientes del sistema de archivos. También llevan a cabo las operaciones de creación, borrado y replicación de los bloques bajo las instrucciones del NameNode.

HDFS está programado en lenguaje Java, por lo que cualquier máquina que soporte Java podrá correr estos servicios. Una implementación típica consta de un servidor NameNode dedicado para correr solo el software correspondiente a este, y los demás servidores del clúster corren una única instancia del software DataNode. La existencia de un único CAPÍTULO 1. SISTEMAS DE ARCHIVOS 18

NameNode simplifica grandemente la arquitectura del sistema, este es el orquestador y repositorio de todos los metadatos de HDFS.

Con el objetivo de mantener el proceso de replicación libre de errores, HDFS implementa un estado especial llamado “Modo Seguro”. Cuando el sistema pasa a este estado, todos los bloques almacenados en los DataNodes son verificados en cuanto al número de réplicas que debería tener. Vale aclarar que el contenido de los bloques no es analizado, solo la cantidad de réplicas del bloque. Si se encuentran bloques con un número de réplicas menor al que debería tener, se procede a replicarlo para satisfacer esta condición. De esta forma, solo asegura que exista el número correcto de réplicas, pero no la información almacenada por los bloques.

El NameNode mantiene dos estructuras de datos centrales para manejar los metadatos, estas son el FsImage y el EditLog. Una corrupción de esos archivos puede causar que el sistema deje de ser funcional. Por esta razón, el NameNode debe ser configurado para mantener dos o más copias sincronizadas de estos archivos.

En cuanto a la accesibilidad, una aplicación puede acceder al sistema de archivos a través de una API de Java provista por HDFS. Además, es posible acceder vía web con cualquier navegador web a través del protocolo WebDAV.

1.3.3 BeeGFS BeeGFS o formalmente FhGFS [28], es un sistema de archivos paralelo de código abierto, desarrollado y optimizado para HPC. Está enfocado en el rendimiento y la escalabilidad, con un alto nivel de flexibilidad y diseñado para ser robusto y sencillo de usar. Es un sistema de almacenamiento definido por software basado en la interfaz POSIX del sistema de archivos. Es compatible con la mayoría de distribuciones basadas en Linux.

Es importante aclarar que solo los componentes básicos de BeeGFS son libres y de código abierto, pues las características empresariales como alta disponibilidad, manejo de cuotas y listas de control de acceso solo están disponibles bajo licencias no gratuitas.

La arquitectura de BeeGFS está compuesta por cuatro servicios principales: CAPÍTULO 1. SISTEMAS DE ARCHIVOS 19

1. Servicio de Gestión: Solo observa los servicios registrados y chequea sus estados, no es crítico para el rendimiento ni almacena datos de usuarios. Es el primer servicio que debe ser instalado en el nuevo clúster. 2. Servicio de Almacenamiento: Este es el servicio principal para almacenar los datos del usuario. Los archivos son divididos en trozos y distribuidos entre diferentes servidores de almacenamiento. 3. Servicio de Metadatos: Este servicio almacena información de metadatos. Es escalable, por lo que se pueden usar múltiples servidores de metadatos para mejorar el rendimiento. 4. Servicio Cliente: BeeGFS tiene un servicio de lado del usuario que se registra de forma nativa en el sistema operativo con la interfaz del sistema de archivos virtual del kernel de Linux para máximo rendimiento. El código fuente del módulo del kernel está incluido en el paquete normal del usuario y es automáticamente compilado para la arquitectura actual.

Como los servicios de gestión, metadatos y almacenamiento no acceden al disco duro directamente, existe gran flexibilidad para escoger el sistema de archivos de la capa subyacente que mejor se desempeñe para cada tipo de servicio. Es posible almacenar datos en cualquier sistema de archivos POSIX compatible local de Linux, como ext4, o .

Otra funcionalidad importante de BeeGFS es la capacidad de organizar el almacenamiento en conjuntos definidos (llamados pools). O sea, que es posible agrupar los dispositivos de almacenamiento de acuerdo a políticas definidas como pueden ser las tecnologías de los dispositivos de almacenamiento o la ubicación geográfica.

1.3.4 Lustre Sin duda alguna Lustre [29] es uno de los competidores más fuertes en el mundo de los sistemas de almacenamiento definidos por software. Es una plataforma de almacenamiento de datos de código abierto, distribuida y paralela diseñada para escalabilidad masiva, alto rendimiento y alta disponibilidad. Popular en la comunidad HPC, Lustre es usado para soportar las aplicaciones con mayores demandas en almacenamiento. Provee lectura/escritura horizontalmente escalable para Centros de Datos de cualquier tamaño. Está diseñado para ser POSIX compatible y correr en sistemas basados en Linux con una arquitectura cliente- CAPÍTULO 1. SISTEMAS DE ARCHIVOS 20 servidor. Los softwares de servicios de Lustre están completamente implementados en el kernel de Linux como módulos que pueden ser cargados.

La arquitectura de Lustre usa almacenamiento distribuido y basado en objetos administrado por servidores y accedidos por máquinas clientes usando diferentes protocolos de red. Existen tres tipos de clases de servidores:

 Servidores de Gestión: Proveen información de configuración, registros del sistema de archivos.  Servidores de Metadatos: Guardan el espacio de nombres, los inodos y la indexación del sistema de archivos.  Servidores de Almacenamiento de Objetos: Guardan el contenido de los archivos en objetos binarios distribuidos. Un archivo simple puede estar compuesto por uno o más objetos, y los datos de ese archivo están organizados en bloques de diferentes objetos. Los objetos son distribuidos a través del almacenamiento disponible.

Lustre separa el almacenamiento de metadatos (inodos) del almacenamiento de los bloques (contenido del archivo). Todas las operaciones sobre los metadatos de archivos (crear y eliminar archivos, ubicar objetos de datos, administración de permisos) son administradas por el servidor de metadatos, que además provee el indexado del sistema de archivos. Los servidores de almacenamiento de objetos escriben el contenido de los datos en el almacenamiento persistente. Estos pueden ser escritos concurrentemente, y un archivo individual puede ser distribuido en múltiples objetos a través de múltiples servidores. Esto permite la creación y acceso paralelo a archivos muy grandes a través de una infraestructura de red de computadoras. Además de los metadatos y los datos, está el servicio de gestión, que se emplea para orquestar todo el sistema de archivos y sus configuraciones.

Las operaciones de lectura/escritura en Lustre son transmitidas usando un protocolo llamado LNet. Se trata de un protocolo orientado a la conexión que tiene soporte nativo para redes TCP/IP, Intel Omni-Path Architecture (OPA) e InfiniBand. Soporta ambientes con redes heterogéneas, puede agregar lectura/escritura entre interfaces independientes habilitando el multicamino en la red. El tráfico puede ser enrutado usando servidores dedicados llamados LNet Routers, los cuales proveen una puerta de enlace entre diferentes redes LNet. Múltiples CAPÍTULO 1. SISTEMAS DE ARCHIVOS 21 enrutadores pueden ser agrupados para proveer mejor desempeño. Por ejemplo, un enrutador puede ser usado para servir de puente entre una red TCP/IP y otra InfiniBand y/o RDMA (OPA). El Anexo III muestra un ejemplo de configuración para enrutado entre redes en Lustre con diferente tecnología.

Con el objetivo de lograr una alta disponibilidad, Lustre emplea un modelo de gestión de recursos basado en la conmutación por error (failover). Todos los servidores de Lustre (MGS, MDS y OSS) soportan la conmutación por error, de modo que el fallo en uno de los componentes del sistema no provocará que deje de estar operativo. Generalmente se usa el modelo activo-pasivo, de modo que siempre hay un servidor de respaldo en espera (pasivo) por cada servidor activo, que pasará a estado activo cuando hay algún fallo. También es posible configurar el modo activo-activo, de forma tal que todos los servidores están activos y compartiéndose la carga de trabajo y si uno deja de funcionar los demás asumirán su carga de trabajo.

Soporta dos tipos de sistema de archivos subyacentes para el almacenamiento de objetos. LDISKFS que es una versión modificada de ext4 con algunas características extras y ZFS. El uso de uno u otro sistema de archivos no afecta el comportamiento general de Lustre, aunque impone algunas restricciones en cuanto a tamaño máximo de los archivos, del sistema de archivos y el total de ficheros.

Posee potentes herramientas de gestión y supervisión que simplifican las tareas de administración. Un ejemplo es Lustre Monitoring Tool (LMT), una aplicación basada en Python que muestra la actividad de uno o múltiples sistemas de archivos Lustre.

1.3.5 GlusterFS Otro de los grandes competidores en el mundo del almacenamiento definido por software es GlusterFS [30]. Se trata de un sistema de archivos distribuido paralelo diseñado para manejar tareas con grandes volúmenes de datos como almacenamiento en la nube o flujos de medios y ser altamente escalable. Es libre, de código abierto y se puede utilizar sobre hardware estándar. Es un sistema de archivos de espacio de usuario, por lo que hace uso de FUSE (Sistema de archivos de espacio de usuario) para comunicarse con el sistema de archivos virtual del núcleo del sistema operativo. CAPÍTULO 1. SISTEMAS DE ARCHIVOS 22

La primera consideración importante es que GlusterFS no es realmente un sistema de archivos en sí, concatena sistemas de archivos existentes dentro de una (o más) gran partición desde el cual se pueden leer y escribir datos. GlusterFS distribuye los datos a través de múltiples servidores desde los que se pueden leer (o escribir) posteriormente simultáneamente. Esto quiere decir que se puede usar el espacio disponible en cualquier máquina. Típicamente, se recomienda XFS como sistema de archivos subyacente, aunque pueden ser usados otros como ext4, siempre y cuando soporte atributos extendidos.

En la arquitectura de GlusterFS un nombre de espacio global o volumen es una colección de uno o más directorios compartidos o exports, previamente montados (análogo a los directorios compartidos o exports de NFS), la mayoría de las operaciones en este sistema de archivos ocurre en los volúmenes. Emplea el almacenamiento basado en bloques para manejar los datos y puede usar tcp, rdma (remote direct memory access) o ambos como protocolos de transporte.

Soporta diferentes tipos de volúmenes basados en los requerimientos. Algunos son buenos para escalar rápidamente la capacidad de almacenamiento, otros para mejorar el rendimiento y otros para ambos. Los 5 tipos principales son:

1. Volumen distribuido: Los archivos son distribuidos a través de varios bloques en el volumen, pero cada archivo solo puede estar en un volumen a la vez por lo que no existe redundancia de datos. 2. Volumen replicado: En este tipo de volumen se resuelven los problemas de redundancia de datos. En este caso, se mantienen copias exactas de los datos en todos los bloques. El número de réplicas es decidido por el usuario en el momento de crear el volumen. 3. Volumen distribuido replicado: En este caso los archivos son distribuidos a través de conjuntos de bloques replicados. Este se usa cuando se necesita alta disponibilidad de datos garantizada por la redundancia y alta escalabilidad. 4. Volumen dividido: Los datos son almacenados en los bloques después de ser divididos en varios trozos (igual al número de bloques del volumen) y cada trozo es almacenado en un bloque. Por tanto, la carga se distribuye y el archivo puede ser accedido más rápido pero no se provee redundancia. CAPÍTULO 1. SISTEMAS DE ARCHIVOS 23

5. Volumen distribuido dividido: Este caso es muy similar al anterior, excepto que ahora los trozos son distribuidos entre un mayor número de bloques.

Según la documentación oficial de GlusterFS, el uso ideal para este sistema de almacenamiento por software es en escenarios donde se necesite escalar rápidamente la capacidad de almacenamiento y almacenar grandes cantidades de datos pero que no sean accedidos frecuentemente.

1.3.6 Ceph Una de las opciones de almacenamiento definido por software más popular en la actualidad es Ceph [31]. Se trata de un sistema de almacenamiento altamente confiable, fácil de gestionar y de código abierto. Es capaz de manejar enormes cantidades de datos y presenta una extraordinaria escalabilidad. Un nodo Ceph puede acomodarse a una multitud de hardware estándar. Los servicios inteligentes de un clúster Ceph pueden mantener un gran número de nodos comunicándose entre ellos para replicar y distribuir dinámicamente los datos. Además, Ceph entrega de forma única objetos, bloques y sistemas de archivos en una plataforma unificada.

Ceph debe su alta escalabilidad a RADOS [32] (Almacenamiento Distribuido de Objetos Autónomo y Confiable), un sistema confiable de almacenamiento de objetos que usa la inteligencia presente en cada uno de los nodos de almacenamiento. Este mantiene el acceso consistente a los datos y una semántica altamente segura mientras permite a los nodos actuar de forma semiautónoma para autogestionar la replicación, la detección de fallos y la recuperación de los fallos a través del uso de un pequeño mapa del clúster. De esta forma facilita una distribución balanceada de los datos y de la carga de trabajo a través de un clúster de almacenamiento dinámico y heterogéneo. Cada nodo tiene completo conocimiento de la distribución de los datos en el sistema, lo que le permite actuar de forma semiautónoma usando protocolos peer-to-peer para autogestionar la replicación de datos, consistencia y procesos de actualización segura, participar en la detección de fallos, responder a un fallo y los cambios resultantes en la distribución de los datos.

Un clúster de almacenamiento Ceph consiste básicamente de tres servicios:

 Ceph Monitor CAPÍTULO 1. SISTEMAS DE ARCHIVOS 24

 Ceph OSD Daemon  Ceph Manager

Un Ceph Monitor mantiene una copia master del mapa del clúster y gestionan la autenticación entre los servicios del clúster y los clientes. Un clúster de almacenamiento Ceph puede operar con un solo Ceph Monitor, sin embargo, esto introduce un único punto de fallo. Para agregar confiabilidad y tolerancia a fallos, Ceph soporta un clúster de monitores, donde la latencia en la red y otros fallos pueden causar que uno o más monitores dejen de estar disponibles sin afectar la disponibilidad del sistema de almacenamiento. Los clientes de un clúster Ceph obtienen una copia del mapa del clúster desde el Ceph Monitor. Los Ceph OSD Daemons son los encargados de almacenar los datos, manejar la replicación de datos, la recuperación de fallos y el rebalanceo. Además, chequean su propio estado y el estado de otros OSDs (del inglés Device) y reportan esta información a los Ceph Monitors. Los clientes y cada Ceph OSD Daemon usan el algoritmo CRUSH [33] para eficientemente computar información sobre la localización de los datos, en vez de depender de una tabla central de ubicaciones. CRUSH provee un mecanismo efectivo de gestión de datos y permite un escalado masivo distribuyendo claramente el trabajo a todos los clientes y OSD Daemons en el clúster; usa replicación inteligente de datos para asegurar consistencia. Los Ceph Managers son responsables de realizar un seguimiento de las métricas de ejecución y el estado actual del clúster Ceph, incluyendo utilización, métricas de rendimiento actual y carga del sistema. Además, hospedan módulos basados en Python, incluyendo una aplicación de supervisión basada en web. Las características de alto nivel de Ceph incluyen una interfaz nativa del clúster de almacenamiento Ceph vía librados (librerías de RADOS) y un número de interfaces de servicios que trabajan sobre librados.

El clúster de almacenamiento Ceph recibe los datos desde los clientes (ya sea a través de un Dispositivo de Bloques Ceph, un Almacenamiento de Objetos Ceph, un Sistema de Archivos Ceph o una implementación personalizada usando librados) y los almacena como objetos. Cada objeto corresponde a un archivo en el sistema de archivos. Los Ceph OSD Daemons manejan las operaciones de lectura/escritura en los dispositivos de almacenamiento. Todos los objetos de datos son almacenados en un espacio de nombres plano, o sea, que no existe CAPÍTULO 1. SISTEMAS DE ARCHIVOS 25 la jerarquía de directorios. Un objeto está compuesto por un identificador, datos binarios y los metadatos en forma de un conjunto de pares nombre/valor.

Ceph depende de que los clientes y los OSD Daemons tengan conocimiento de la topología del clúster, la cual incluye un conjunto de 5 mapas y es llamada “Mapa del Clúster”. Estos mapas son el mapa de monitores, el mapa de OSDs, el mapa de grupos de ubicación (PG, del inglés placement group), el mapa CRUSH y el mapa de MDSs (Servidores de Metadatos).

Antes de que un cliente pueda leer o escribir datos, este debe contactar con un Ceph Monitor para obtener la copia más reciente del mapa del clúster.

La habilidad de los clientes Ceph, los Ceph Monitors y los Ceph OSD Daemons de interactuar unos con otros significa que los Ceph OSD Daemons pueden utilizar la CPU y la RAM de los nodos Ceph para fácilmente llevar a cabo tareas que fueran extremadamente difíciles de realizar en un nodo centralizado.

Para identificar usuarios y protegerse de algunos ataques, Ceph provee un sistema de autenticación llamado cephx para autenticar usuarios y servicios. Cephx usa claves secretas precompartidas, lo que significa que ambos, el cliente y el Ceph Monitor deben tener una copia de la llave secreta. El protocolo de autenticación consiste en que ambas partes pueden comprobar si la otra posee una copia la clave secreta sin revelarla. Esto provee autenticación mutua, lo que significa que el clúster comprueba que el usuario posee la clave secreta y el usuario comprueba que el clúster tiene una copia de su clave secreta.

Una característica importante de Ceph es el rebalanceo. Cuando se agrega un nuevo OSD al clúster, el mapa del clúster necesitará ser actualizado con el nuevo OSD. Consecuentemente, esto cambia los resultados del algoritmo CRUSH porque cambian las entradas para el cálculo de la ubicación de los objetos. Mediante este proceso algunos grupos de ubicación de los OSD existentes se reubican en el nuevo OSD de forma tal que la utilización promedio de cada dispositivo de almacenamiento sea la más pareja posible.

Los códigos de borrado son otra de las funcionalidades interesantes de Ceph. Una partición con códigos de borrado almacena cada objeto como K+M bloques, K bloques de datos y M bloques de códigos. Cada bloque está almacenado en un OSD diferente. La funcionalidad de este tipo de partición es parecida a la de RAID 5 y RAID 6, los bloques de código son usados CAPÍTULO 1. SISTEMAS DE ARCHIVOS 26 para reconstruir algún bloque de datos faltante, de esta forma se asegura la disponibilidad de los datos y la recuperación ante fallos.

Para proveer un mejor desempeño de lectura/escritura, Ceph hace uso de la caché de datos. De esta forma mantiene dos espacios de almacenamiento, uno más rápido ubicado en dispositivos de almacenamiento más veloces como puede ser un conjunto de discos de estado sólido (SSD, del inglés solid state drive) configurado como caché y otro más lento ubicado en los dispositivos de almacenamiento más lentos. Ambos espacios de almacenamiento son completamente transparentes para los clientes. El manejador de objetos de Ceph determina cuándo un objeto debe permanecer en caché o debe ser escrito al almacenamiento persistente.

El Sistema de Archivos Ceph:

El sistema de archivos Ceph (CephFS [34]) provee un sistema de archivos POSIX compatible como un servicio que funciona sobre el clúster de almacenamiento Ceph basado en objetos. Los archivos en CephFS son mapeados a objetos que Ceph almacena en el clúster. Los clientes pueden montar el sistema de archivos Ceph usando sus librerías nativas del kernel o como un sistema de archivos de espacio de usuario (FUSE). Este servicio incluye el uso de un servidor de metadatos (MDS), cuyo propósito es almacenar todos los metadatos del sistema de archivos (directorios, permisos de archivos, etc.) en Servidores de Metadatos de Ceph de alta disponibilidad donde los metadatos residen en memoria. La razón para estos servidores es simplemente ofrecer operaciones como listar un directorio o cambiar de directorio sin la necesidad de involucrar a los OSD innecesariamente. Entonces, separando los metadatos de los datos significa que el sistema proveerá alto rendimiento sacrificando el mínimo de recursos del clúster. Un MDS puede correr en un simple proceso o en varios procesos distribuidos entre diferentes máquinas, esta última opción mejorará la escalabilidad y la disponibilidad eliminando el único punto de fallo.

1.4 Selección del sistema de archivos a implementar en el Clúster HPC De acuerdo a las condiciones expuestas en el epígrafe anterior, para satisfacer las cargas de trabajo del HPC es necesario un sistema de archivos capaz de mantener una alta razón de transferencia. Pero que, en adición, esta razón de transferencia y la capacidad de almacenamiento sean fácilmente escalables, lo que permitirá adaptarse a cargas de trabajo mayores que pueden deberse al incremento de la cantidad de flujos de acceso. Además, el CAPÍTULO 1. SISTEMAS DE ARCHIVOS 27 sistema de archivos deberá presentar una alta disponibilidad a pesar de los múltiples fallos que puedan tener lugar y ser flexible para ajustarse al hardware disponible. Otro parámetro a tener en cuenta es el costo de implementación, que se tratará de reducir al mínimo usando solamente el hardware disponible y software libre. Teniendo en cuenta esto y el análisis de los sistemas de archivos expuestos en el epígrafe anterior, se propone implementar Ceph como sistema de almacenamiento para el clúster HPC de la UCLV, pues a pesar de sus semejanzas con los demás, presenta algunas diferencias que lo destacan como la mejor opción.

El primer sistema de archivos analizado fue GPFS, del cual se tiene poco conocimiento de su funcionamiento interno debido a que es software propietario, lo que implica que se necesita licencia para su implementación. Su documentación oficial no es muy precisa en cuanto a los procesos de instalación, mantenimiento y gestión.

El segundo en analizarse fue HDFS, un sistema de almacenamiento definido por software, de altas prestaciones que ofrece una excelente razón de transferencia. Es software libre y su documentación oficial brinda todas las especificaciones de su funcionamiento e implementación. Su arquitectura es sencilla y fácil de implementar. Su problema principal es que el hecho de existir un único NameNode introduce en el sistema un único punto de fallo, por lo que si el servidor que corre este servicio falla dejará de estar disponible todo el sistema de archivos. Está enfocado en Big-Data, específicamente en aplicaciones que escriban archivos muy grandes una vez y luego varios nodos accedan a él solo para leer datos.

El tercero en analizarse fue BeeGFS. Se trata de una tecnología reciente con un excelente desarrollo optimizada específicamente para ambientes HPC y es altamente escalable. Pero aún presenta algunos problemas de inestabilidad y los componentes fundamentales en escenarios HPC como la alta disponibilidad solo están disponibles bajo licencia de software propietario.

Luego se expuso el funcionamiento y las características de Lustre. Al igual que Ceph, es un sistema de archivos basado en objetos, con características muy potentes y opciones de configuración que le permiten adaptarse a casi cualquier escenario. Tal es el caso del protocolo de red LNet y los LNet Routers que permiten coexistir a diferentes tecnologías de red tal y como si se tratase de una red homogénea. Es una tecnología bastante madura CAPÍTULO 1. SISTEMAS DE ARCHIVOS 28 empleada por grandes supercomputadores del mundo como en el Laboratorio Nacional Oak Ridge en Estados Unidos. Su implementación es un poco más compleja que Ceph debido a que hay que configurar más componentes como los controladores de la red (LNet).

Además, se analizó GlusterFS, el cual presenta relativa sencillez en los procesos de instalación y gestión. Presenta una gran estabilidad, escalabilidad, brinda razones de transferencia elevadas y es muy flexible en cuanto a la elección del sistema de archivos subyacente. Su principal problema es que, debido a su forma de manejar los metadatos, es más eficiente manejando grandes archivos que son escritos y leídos con poca frecuencia, como las copias de seguridad, por ejemplo. Pero no se desempeña bien en la lectura/escritura intensiva que se puede producir en ambientes HPC. Otro aspecto negativo es que es un poco restrictivo en cuanto a los tipos de volúmenes que se pueden configurar.

Finalmente se expuso la arquitectura y las características del funcionamiento interno de Ceph, que semejante a Lustre, posee una gran cantidad de opciones de configuración y funcionalidades que lo destacan sobre los demás. Como elementos importantes que influyeron positivamente en la selección de este sistema de archivos está el algoritmo CRUSH que permite que de una forma muy eficiente los clientes y nodos del sistema calculen las ubicaciones de los objetos, distribuyendo la carga de trabajo entre todo el sistema lo que incrementa considerablemente su rendimiento. Otra característica relevante es el empleo de RADOS, que permite usar la potencia de procesamiento de cada nodo del sistema para manejar de forma semiautónoma algunos procesos vitales del sistema de archivos como la replicación. Además, posee un método de autenticación (cephx) muy fácil de implementar y muy confiable que ayuda a mantener seguras las transacciones entre el cliente y el clúster y entre los servicios propios del clúster. También fue un criterio importante el hecho de que Ceph brinda la flexibilidad de poder manejar almacenamiento basado en bloques, basado en objetos y un sistema de archivos desde una única plataforma integrada. CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 29

CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC

En este capítulo se describe el proceso de implementación de Ceph como sistema de archivos para el clúster HPC.

En el primer epígrafe se mencionan los requisitos de software y hardware recomendados por la documentación oficial para la implementación de Ceph y se describe el escenario de desarrollo haciendo énfasis en el hardware disponible, lo que permite demostrar que se cuenta con las condiciones necesarias para un despliegue exitoso de Ceph. Se describe la arquitectura básica del clúster Ceph y la arquitectura de red que se empleará en el mismo. Además, se explica el proceso de preparación previa del software y el hardware necesario antes de comenzar con la instalación y puesta en marcha de Ceph.

El segundo epígrafe se dedica al proceso de instalación paso a paso del sistema de archivos propuesto. En un inicio se exponen las opciones de configuración propuestas y las posibles variantes, el significado de cada una y la razón por la cual se seleccionó. Se explican algunos conceptos fundamentales de Ceph para entender su funcionamiento interno y el efecto de cada configuración. Se describen cada uno de los pasos realizados para la instalación del clúster Ceph, terminando con la creación y montaje del sistema de archivos en el HPC del Centro de Datos de la UCLV.

Luego, en el tercer epígrafe se describen las acciones para la administración y supervisión del clúster Ceph. Se exponen las principales variables que se monitorean en el clúster, cómo recuperarse ante los errores más comunes y cómo llevar a cabo algunas tareas básicas como el cambio de un disco duro o la modificación de parámetros de configuración del sistema.

Finalmente, a modo de conclusiones parciales se expresan las facilidades y características de Ceph que lo hacen elegible por sobre otras tecnologías de almacenamiento.

CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 30

2.1 Preparación del hardware y el software necesario Para el desarrollo del presente trabajo, se implementó Ceph en el Centro de Datos de la UCLV como sistema de archivos para el clúster HPC. El HPC actualmente cuenta con 51 servidores. De estos, 49 son empleados como nodos de procesamiento, los cuales tendrán un uso intensivo de los sistemas de archivos Ceph. Los nodos del HPC están conectados a una subred LAN que funciona bajo el estándar Ethernet a velocidades de 1GB/s. El clúster Ceph se conectará directamente a esta subred empleando la misma tecnología de red.

2.1.1 Arquitectura básica del clúster Ceph En la Figura 2.1 se muestra la arquitectura de un clúster Ceph [35]. Existen cuatro servicios principales que son los encargados de manejar todas las tareas del clúster.

Monitors Managers OSDs MDSs Figura 2.1 Arquitectura del clúster Ceph[35] Sin importar cuales son los servicios que se brindarán (Almacenamiento de Objetos Ceph, Dispositivo de Bloques Ceph, Sistema de Archivos Ceph u otro propósito) todas las implementaciones de un clúster Ceph requieren de al menos un Ceph Monitor, un Ceph Manager y un Ceph OSD. Cuando se utilizará Ceph como sistema de archivos, como es el caso del presente trabajo, se necesita además como mínimo un Servidor de Metadatos Ceph (MDS). Cada uno de estos servicios tiene tareas bien definidas:

 Monitors: Un Ceph Monitor (nombre de servicio ceph-mon) mantiene los mapas de estado del clúster, incluyendo el mapa de monitores (Monitors), el mapa de Managers, el mapa de OSDs, el mapa de servidores de metadatos (MDS) y el mapa CRUSH. Estos mapas son críticos para el funcionamiento del clúster, dado que permiten la coordinación entre los servicios. Los monitores también son responsables del proceso de autenticación entre servicios del clúster y los usuarios. Para lograr una correcta redundancia y alta disponibilidad se recomiendan al menos tres monitores.  Managers: Un Ceph Manager (nombre de servicio ceph-mgr) es responsable de mantener las métricas de tiempo de ejecución y el estado actual del clúster Ceph, incluyendo utilización del almacenamiento, métricas de desempeño y carga del CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 31

sistema. Además, hospedan módulos basados en Python para gestionar y compartir información del sistema, incluyendo un panel de utilidades (Ceph Dashboard) basado en web. Para lograr una correcta redundancia y alta disponibilidad se recomiendan al menos dos managers.  Ceph OSD: Un Ceph OSD (nombre de servicio ceph-osd) es el servicio encargado de almacenar los datos, manejar la replicación, recuperación, rebalanceo y proveen de información a los Ceph Monitors y a los Ceph Managers chequeando el estado de otros OSD. Para lograr una correcta redundancia y alta disponibilidad se recomiendan al menos tres OSD.  MDS: Un Servidor de Metadatos Ceph (nombre de servicio ceph-mds) almacena los metadatos de los sistemas de archivos Ceph (los Dispositivos de Bloques Ceph y el Almacenamiento de Objetos Ceph no usan este servicio). Además, permite a los usuarios de sistemas de archivos POSIX ejecutar comandos (como ls, find, etc.) sin agregar enormes cargas de trabajo al clúster.

Ceph almacena los datos como objetos en particiones lógicas (llamadas pools). Usando el algoritmo CRUSH[33], calcula cuál grupo de ubicación deberá contener el objeto y luego calcula cuál Ceph OSD debe almacenar el grupo de ubicación. De esta forma se asegura escalabilidad, rebalanceo y recuperación dinámica. Un grupo de ubicación es una colección lógica de objetos que son replicados por el mismo conjunto de dispositivos. Cada grupo de ubicación está determinado, entre otros parámetros, por el número total de grupos de ubicación, por tanto, cuando el clúster escala es necesario recalcular y ajustar gradualmente el número total de grupos de ubicación. Cada partición lógica tiene un número de grupos de ubicación establecido en el momento de su creación, aunque puede ser cambiado. El mapeo de objetos a grupos de ubicación crea una capa de indirección entre el Ceph OSD y el cliente Ceph, lo que permite al clúster aumentar (o disminuir) y rebalancear donde son almacenados los objetos dinámicamente. La Figura 2.2 muestra un diagrama de cómo CRUSH mapea objetos a grupos de ubicación y grupos de ubicación a los OSDs. CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 32

Figura 2.2 Diagrama de funcionamiento del algoritmo CRUSH[33]

Cuando un nuevo Ceph OSD es añadido al clúster, el mapa del clúster es actualizado con el nuevo OSD. Consecuentemente, esto cambia el cálculo de las ubicaciones para los objetos porque se modifica la entrada del algoritmo CRUSH. La Figura 2.3 muestra el proceso de rebalanceo que tiene lugar por esta causa, donde algunos grupos de ubicación son migrados al nuevo OSD. En un clúster grande, muchos de los grupos de ubicación permanecen en su configuración original y cada OSD obtiene un poco más de capacidad, por lo que todos los OSD tendrán en promedio la misma carga cuando el rebalanceo termine.

Según la documentación oficial de Ceph[35], se recomienda que cada máquina posea como mínimo dos controladores de interfaz de red, uno para la llamada “red de acceso” y otro para la llamada “red del clúster”. La red del clúster (no conectada a la red de acceso) maneja la carga adicional de replicación de los datos y ayuda a proteger el sistema de ataques de denegación de servicio. Solo los servidores del clúster Ceph están conectados a la red del clúster. La red de acceso es la que conecta cada servidor del clúster Ceph con los nodos clientes. Los servidores sobre los que se implementó Ceph en el presente trabajo cuentan con dos controladores de interfaz de red cada uno. Las conexiones de red propuestas en el clúster Ceph quedaron configuradas como muestra la Figura 2.4.

CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 33

Figura 2.3 Proceso de rebalanceo en Ceph.

switch Red de acceso

ceph-admin ceph1 ceph2

Subred del clúster

switch Figura 2.4 Arquitectura de red del Clúster Ceph Como se observa, todos los servidores están conectados a través de una de sus interfaces de red a la red de acceso (representada en color amarillo) desde donde accederán los nodos clientes a los servicios del sistema de archivos. La otra interfaz de red de cada servidor está conectada a la subred del clúster (representada en color azul), la cual está aislada de la red de acceso. Ambas, funcionan bajo el estándar Ethernet a una velocidad de 1GB/s. En el siguiente epígrafe se explicarán otras razones de por qué se implementó esta arquitectura de red.

2.1.2 Recomendaciones del hardware y software Antes de comenzar el proceso de instalación de Ceph es necesaria una minuciosa planificación del hardware y el software a emplear. La documentación oficial de Ceph expone una serie de recomendaciones que deben ser tomadas en cuenta para lograr el funcionamiento estable del clúster Ceph. CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 34

Cuando se planea el hardware es necesario balancear un número de consideraciones[36], incluyendo los dominios de fallo y los problemas potenciales de rendimiento. Se deberá distribuir los servicios de Ceph y otros procesos que usen Ceph a través de múltiples máquinas. Generalmente se recomienda correr cada servicio de Ceph de un tipo específico en una máquina configurada para ese tipo de servicio. A continuación, se exponen los requerimientos de hardware:

 CPU: Los servidores de metadatos de Ceph dinámicamente redistribuyen su carga, lo cual es un proceso intensivo para la CPU. Por tanto, deben tener un poder de procesamiento significativo, se recomienda 4 núcleos o más para correr este servicio. Los Ceph OSD corren el servicio RADOS, calculan las ubicaciones de los PGs con el algoritmo CRUSH, replican los datos y mantienen su propia copia del mapa del clúster. Por esto, deben tener un poder de procesamiento relativamente alto, se recomienda 2 núcleos o más. Los Ceph Monitors simplemente mantienen la copia máster del mapa del clúster, por lo que su carga de procesamiento no es significativa. En el caso de los Managers, su carga de procesamiento depende de la cantidad de módulos que estén habilitados y corriendo; generalmente 1 núcleo es suficiente.  RAM: Generalmente más RAM es mejor. El uso de memoria de los servicios de los Ceph Monitors y los Managers generalmente escalan con el tamaño del clúster. Para clústeres pequeños, 1-2GB es suficiente. Para clústeres grandes, se debe proveer 5- 10GB. El uso de RAM usado por estos servicios se puede controlar con parámetros de configuración como mon_osd_cache_size. La utilización de RAM del servicio de metadatos depende de cuanta memoria se configuró para consumir, se recomienda 1GB como mínimo; el parámetro de configuración que controla su utilización es mds_cache_memory. Para el caso de los OSD, se recomienda 3-5GB de RAM; se puede ajustar la cantidad de memoria a usar a través del parámetro osd_memory_target.  Dispositivos de almacenamiento: Los dispositivos de almacenamiento están sujetos a limitaciones en el tiempo de búsqueda, tiempo de acceso, tiempo de lectura/escritura y la razón total de transferencia. Estas limitaciones afectan el rendimiento del sistema, especialmente durante la recuperación. Se recomienda usar un dispositivo dedicado al sistema operativo y el software, un dispositivo para cada Ceph OSD y otro para el CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 35

journal de los OSD. Una oportunidad para mejorar el rendimiento del sistema es usando discos de estado sólido para reducir el tiempo de acceso aleatorio y la latencia de lectura mientras se acelera la razón de transferencia. Sin embargo, este tipo de discos es más costoso por lo que una buena relación entre beneficio-costo se logra empleando los discos sólidos solo como journal.

Se pueden correr múltiples OSDs en la misma máquina, pero se debe tener en cuenta que la suma total de las razones de transferencia de todos los OSDs no exceda el ancho de banda de la red requerido para servir a un cliente.

En cuanto a los requerimientos de software[37], Ceph puede correr en una gran variedad de sistemas operativos Linux. Oficialmente ha sido probado en CentOS, Debian, Fedora, RHEL y Ubuntu, pero las pruebas más exhaustivas se han realizado sobre CentOS y Ubuntu. La documentación oficial no recomienda el uso de una plataforma en específico, no es así en el caso de la versión del kernel Linux ya que cada versión de Ceph requiere de una versión mínima del kernel Linux para funcionar correctamente.

En el presente trabajo se empleó CentOS 7 (release 7.6.1810) como sistema operativo de los nodos del clúster Ceph, con la versión 3.10.0-957.1.3.el.7.x86_64 del kernel de Linux. La versión de Ceph que se instaló es la 13.2.5 (mimic), que en el momento de realización de este trabajo es la versión estable más reciente y según la documentación oficial de Ceph corre sin problemas en el sistema operativo seleccionado (el kernel de Linux también cumple los requisitos).

Para la implementación de Ceph se cuenta en el Centro de Datos de la UCLV con tres servidores. La Tabla 1 muestra las características del hardware y los servicios que corren en cada uno de ellos.

Tabla 1. Características del hardware disponible y distribución de los servicios del Clúster Ceph

Tipo CPU RAM Interfaz Discos Nombre Servicios* de red duros asignado Dell Intel(R) 8GB 2 x 1GB/s 1 x ceph- OSD Power Xeon(R) X5660 500GB - admin MON Edge SO R410 CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 36

(12 núcleos a 3 x 500 2.80 GHz cada GB - uno, 32-64 bit) OSD Dell Intel(R) 8GB 2 x 1GB/s 1 x ceph1 OSD Power Xeon(R) X5660 500GB - MON Edge (24 núcleos a SO MGR R410 2.80 GHz cada 3 x 500 MDS uno, 32-64 bit) GB - OSD Dell Intel(R) 16GB 2 x 1GB/s 1 x ceph2 OSD Power Xeon(R) X5660 500GB - MON Edge (24 núcleos a SO MGR R410 2.80 GHz cada 3 x 500 MDS uno, 32-64 bit) GB - OSD * OSD, MON, MGR y MDS representan los servicios Ceph OSD, Ceph Monitor, Ceph Manager y Servidor de Metadatos Ceph respectivamente. El primer señalamiento importante es que en la planificación del clúster Ceph del presente trabajo se asume que como máximo fallará un servidor a la vez (dominio de fallo), sin verse afectada la disponibilidad del clúster. Esto se debe fundamentalmente a que solo se cuenta con tres servidores y, por tanto, es extremadamente difícil lograr la disponibilidad del clúster en caso de fallo de más de un servidor. En el caso de los OSDs es imprecisa la cantidad máxima que pueden fallar simultáneamente, esto se debe a la forma en que Ceph distribuye los objetos. Pero en caso de fallo de un único OSD, Ceph debe ser capaz de recuperarse completamente.

De acuerdo a las recomendaciones de hardware expuestas anteriormente, la Tabla 2 muestra la cantidad de CPU y RAM (pronosticada) que usará cada servicio de Ceph. La última fila muestra la suma total para los cuatro servicios, de modo que se obtiene una estimación de cuantos recursos se necesitarán por servidor para correr los cuatro servicios simultáneamente.

Tabla 2. Recomendaciones de hardware para los servicios de Ceph

CPU (núcleos) RAM (GB) MDS 4 1 OSD 2 3-5 MON 1 1-2 MGR 1 1-2 Total 8 6-10

CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 37

En el total, se obtiene que se necesitan como mínimo 8 núcleos de CPU y 6GB de RAM por servidor. En el caso de la RAM, como el clúster Ceph del presente trabajo es pequeño y solo cuenta con seis OSD se toma el valor más pequeño (6 GB), dado que es muy poco probable que se exceda este valor. Como resultado se tiene que, de acuerdo a las propiedades expuestas en la Tabla 1 los tres servidores disponibles cumplen con los requerimientos para correr los cuatro servicios del clúster Ceph a la vez, sin que esto signifique una degradación considerable del rendimiento.

Con el objetivo de lograr una alta disponibilidad del sistema de archivos, en el presente trabajo se propone la distribución de los servicios de Ceph mostrada en la Tabla 1 (ver columna “Servicios”). Además de las correspondientes instancias de los Ceph OSD (una por cada disco duro, lo que da un total de dos por servidor), cada servidor corre una instancia del servicio Ceph Monitor, con lo cual se logra formar un quorum1 de tres, tal y como se recomienda. Para el caso de los servicios Ceph Manager y MDS se corren dos instancias de cada uno (una en cada servidor) en los servidores especificados; de acuerdo al dominio de fallo seleccionado esto es suficiente para lograr la disponibilidad esperada.

2.1.3 Preparación del entorno de instalación Luego de tener todos los nodos que se emplearán en el clúster Ceph conectados a la red, con sus interfaces configuradas correctamente y de haber realizado la planificación de los recursos, se procede a preparar el software y las configuraciones requeridas en cada nodo antes de comenzar la instalación de Ceph.

El primer paso es instalar ceph-deploy[38] en el nodo de administración (ceph-admin). A través de este se instalará Ceph de una forma sencilla y segura en todos los nodos del sistema. El proceso de instalación de Ceph a través de ceph-deploy requiere de ssh en cada nodo del clúster, por lo que un paso razonable es instalar un servidor ssh en cada uno de los nodos. En el presente trabajo se empleó openssh-server.

Se recomienda la instalación de NTP en todos los nodos del clúster (especialmente en los Ceph Monitors) para prevenir problemas relacionados con las diferencias en los relojes de

1 quorum: número mínimo de servicios Ceph Monitor que deben estar presentes para asegurar la validez en la toma de decisiones de Ceph. CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 38 los sistemas. El máximo de diferencia aceptable entre los relojes del sistema es de 50 ms. En el presente trabajo cada nodo usa el mismo servidor NTP de la red UCLV.

La utilidad ceph-deploy deberá iniciar sesión en cada uno de los nodos en los que se instalará Ceph como un usuario sin contraseña con todos los privilegios administrativos (usuario sudoer), porque necesita instalar software y modificar archivos de configuración sin intervención del usuario. Las versiones más recientes de ceph-deploy soportan la opción -- username para especificar el usuario que se empleará para la instalación, sin embargo, no es recomendado emplear esta opción. Se recomienda la creación de un usuario específico en todos los nodos para usar con ceph-deploy. Con este propósito se creó el usuario cfsuclv, se generó un par de claves SSH en el nodo administrador y se distribuyó la clave pública en cada nodo Ceph. Además, en el archivo de configuración de SSH en el nodo administrador se agregaron las entradas correspondientes para que ceph-deploy inicie sesión en cada uno de los nodos como el usuario cfsuclv.

Los Ceph Monitors se comunican usando el puerto 6789 por defecto y los Ceph OSD se comunican en el rango de puertos de 6800:7300 por defecto. Es necesario configurar el firewall de todos los nodos para permitir la comunicación a los servicios de Ceph a través de estos puertos. En el caso de CentOS, se emplea por defecto como firewall el software firewalld, el cual se configuró para permitir la conexión de estos servicios. Además, en esta distribución SELinux está establecido a Enforcing por defecto. Para una correcta instalación y funcionamiento de Ceph se desactivó este servicio de seguridad, tal y como se recomienda en la documentación oficial.

El programa ceph-deploy solo acepta como argumentos los nombres de las máquinas (hostname), no sus direcciones IP. Por tanto, es necesario agregar las parejas de nombre de máquina e IP en el archivo /etc/hosts de cada nodo del clúster, de esta forma es posible referirse a cada nodo por su nombre de máquina.

Como último paso en la preparación previa, se eliminaron todas las particiones y las tablas de particiones de los discos duros que se utilizarán como OSD. Este paso no es requerido en las versiones más antiguas de Ceph, ya que antes de instalar el OSD, ceph-deploy ejecutará estas acciones, no siendo así en las versiones más actuales como la versión 12.x (mimic), en cuyo caso se mostrará un error indicando que el disco duro no está listo para la instalación. CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 39

2.2 Procedimiento de instalación de Ceph empleando ceph-deploy En este epígrafe se expone brevemente el proceso de instalación del clúster Ceph[38] empleando la herramienta de instalación ceph-deploy. Existen otras vías para la instalación de un clúster Ceph, entre ellas la vía manual en la que se necesita instalar y configurar cada servicio por separado en cada nodo, la cual es muy engorrosa y propensa a errores por la gran cantidad de pasos que requiere. Por otra parte, ceph-deploy es una herramienta que solo requiere de especificar las configuraciones iniciales del clúster en un archivo de configuración y con unos pocos comandos se encargará de instalar, configurar, iniciar y comprobar todos los servicios del clúster en cada uno de los nodos. Esta es la vía recomendada en la documentación oficial de Ceph.

Todo el proceso de instalación se ejecuta desde el nodo de administración (ceph-admin), por lo que todos los pasos que se exponen a continuación se realizaron en este, a menos que se especifique lo contrario. Además, todos los comandos se ejecutaron desde el usuario creado para este fin en las preparaciones previas (cfsuclv, ver epígrafe anterior).

En el momento de creación de un nuevo clúster, ceph-deploy genera un archivo de configuración y un conjunto de llaves. Para mejores resultados, se recomienda crear un directorio específicamente para la instalación de Ceph que contendrá estos archivos y ejecutar todos los comandos de instalación dentro de este. Para la creación de un nuevo clúster basta con ejecutar los siguientes comandos:

$ mkdir {nombre_carpeta} $ cd {nombre_carpeta} $ ceph-deploy new ceph-admin ceph1 ceph2 Donde los nombres de los Ceph Monitors iniciales del clúster se pasan como argumentos siguiendo lo planificado en el epígrafe anterior. Con la ejecución de este comando ceph- deploy resuelve las direcciones IP de las máquinas especificadas como Ceph Monitors, inicia sesión en cada una de ellas a través de ssh con el usuario cfsuclv y si tiene éxito en estas operaciones creará un archivo de configuración (ceph.conf) y una llave secreta para los monitores (ceph.mon.keyring) en la carpeta actual.

El archivo ceph.conf contiene la configuración inicial del clúster Ceph. El archivo de configuración puede configurar cada servicio en el clúster Ceph, o todos los servicios de un CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 40 tipo particular. Para configurar una serie de servicios, las configuraciones deben ser incluidas bajo el proceso que recibirá dichas configuraciones. Están disponibles cinco secciones básicas con este fin: [global], [osd], [mon], [mds] y [client]. La sección [global] afectará a todos los servicios del clúster Ceph, las secciones [osd], [mon], [mds] y [client] afectarán solo a los OSDs, los Ceph Monitors, los servidores de Metadatos y los clientes respectivamente. Por defecto, ceph-deploy agrega los parámetros mostrados en la Figura en la sección [global]. El primer parámetro llamado fsid es una cadena alfanumérica única que identifica al clúster Ceph. Es posible instalar varios clústeres Ceph en el mismo conjunto de servidores y administrarlos todos con ceph-deploy, por esta razón, Ceph necesita identificar cada clúster. Los siguientes parámetros son mon_initial_members y mon_host que representan los nombres de máquina y direcciones ip de los nodos monitores iniciales del clúster. Obsérvese que tal y como se ha planificado, los tres nodos del clúster están agregados

[global] fsid = 7336136e-84d0-4086-8eb2-f8a2171da667 mon_initial_members = ceph-admin, ceph1, ceph2 mon_host = 10.12.31.97,10.12.31.96,10.12.31.95 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx

Figura 2.5 Archivo de configuración ceph.conf creado por defecto como monitores iniciales con sus respectivas direcciones ip. Los tres últimos parámetros con el prefijo auth_ habilitan el protocolo de autenticación cephx para todas las operaciones del clúster Ceph (entre cliente-servicio y entre servicio-servicio). Se recomienda mantener activado este protocolo de seguridad para proteger el sistema de ataques y accesos no autorizados.

Es necesario agregar una serie de parámetros al archivo ceph.conf para especificar las configuraciones del clúster que mejor se adapten al escenario de desarrollo. Los parámetros public network y cluster network especifican las direcciones ip y las máscaras de red de la red de acceso (llamada red pública) y de la red del clúster respectivamente. El parámetro osd journal size que se especifica bajo la sección [osd], indica el tamaño que ocupará la partición dedicada al journaling de cada OSD, para el escenario de desarrollo del presente trabajo se considera que una partición de 5GB será adecuada para journaling. Los parámetros osd pool CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 41 default size y osd pool default min size especifican el número de réplicas por defecto para las pools replicadas y el número de réplicas mínimo permisible en el estado degradado respectivamente, el estado degradado se presenta cuando por alguna razón no es posible escribir todas las réplicas deseables de un objeto. Los parámetros osd pool default pg num y osd pool default pgp num representan el número de grupos de ubicación por defecto que contendrán las nuevas pools creadas y el número de grupos de ubicación para asignación para una pool respectivamente. Según la documentación oficial estos valores deben ser iguales y para un clúster de entre 5 y 10 OSDs es aconsejable un valor de 512 grupos de ubicación. Para clústeres grandes, la documentación oficial de Ceph ofrece una aplicación web para calcular estos valores.

Por último, bajo la sección [mgr], se habilitan dos de los módulos disponibles en Ceph, balancer y dashboard, el primero es útil para optimizar los procesos de rebalanceo del clúster y el segundo habilitará el portal web para la supervisión, el cual brinda una serie de estadísticas en tiempo real muy útiles; esto se logra con el parámetro mgr initial modules =

[global] fsid = 7336136e-84d0-4086-8eb2-f8a2171da667 mon_initial_members = ceph-admin, ceph1, ceph2 mon_host = 10.12.31.97,10.12.31.96,10.12.31.95 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx public network = 10.12.31.0/24 cluster network = 192.168.31.0/24 osd pool default size = 3 osd pool default min size = 2 osd pool default pg num = 512 osd pool default pgp num = 512

[osd] osd journal size = 5000

[mgr] mgr initial modules = balancer dashboard Figura 2.6 Archivo de configuración ceph.conf modificado CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 42 balancer dashboard. Luego de agregar todas las configuraciones el archivo ceph.conf quedó como muestra la Figura 2.6.

Con las configuraciones iniciales preparadas se procedió a instalar Ceph en todos los nodos utilizando el siguiente comando:

$ ceph-deploy install ceph-admin ceph1 ceph2 El cual toma como argumentos los nombres de máquina de todos los nodos del clúster. Una vez instalado Ceph se procedió a crear e iniciar los tres servicios principales: Monitors, Managers y OSDs.

Para crear los Monitors e iniciar el servicio en cada uno de los nodos correspondientes se empleó el siguiente comando:

$ ceph-deploy mon create-initial Luego de completado el proceso, el directorio actual debe contener las claves mostradas en la Figura . Estas claves son usadas por el protocolo cephx para autenticar a cada servicio en el sistema.

Figura 2.7 Claves de seguridad del clúster Ceph Para poder ejecutar la interfaz de línea de comandos Ceph en todos los nodos sin la necesidad de especificar la dirección de los monitores y del archivo ceph.client.admin.keyring es necesario copiar el archivo de configuración y las claves de administración en cada uno de ellos. Esto se logró con el siguiente comando:

$ ceph-deploy admin ceph-admin ceph1 ceph2 El cual toma como argumento los nombres de máquina de todos los nodos del clúster desde los cuales se prevé ejecutar comandos de administración.

La instalación de los servicios de los Managers se realizó con el siguiente comando: CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 43

$ ceph-deploy mgr create ceph1 ceph2

En el proceso de planificación del clúster (en el epígrafe anterior) se mencionó que en cada nodo existen dos discos duros previamente preparados que se utilizarán como dispositivos de almacenamiento (Ceph OSDs). Ceph es muy flexible en el momento de creación de los OSD. Existen muchas variantes como por ejemplo crear varias particiones en un mismo disco duro y usar cada una como OSD, este es el peor de los casos porque el desempeño del sistema disminuirá grandemente cuando varios OSD estén ejecutando operaciones de lectura/escritura sobre el mismo dispositivo físico. Entonces, no se recomienda en ningún caso ejecutar más de un OSD sobre el mismo disco duro. Cada OSD consta de dos particiones lógicas: una para almacenar los datos y otra que se empleará como journaling. Es posible separar estas dos particiones lógicas en dos discos duros diferentes, una variante sería usar un disco duro mecánico (HDD, del inglés hard disk drive) estándar como partición de datos y otro disco duro de estado sólido (SSD) con una razón de transferencia mucho mayor como journaling, lo cual mejorará considerablemente el desempeño del sistema. En el presente trabajo, debido a que no se cuenta en este momento con discos de estado sólido (SSD), se instalará un OSD por disco duro. De esta forma, obtenemos en total 6 OSD (dos por cada uno de los tres servidores), cada uno con 500GB de almacenamiento, lo que da un total teórico de 3TB para el uso de Ceph. El proceso de creación e iniciación de los OSD se lleva a cabo con el siguiente comando:

$ ceph-deploy osd create --data {device} {ceph-node}

Donde device es el disco duro que se utilizará como OSD y ceph-node es el nodo al que pertenece dicho disco duro. En este caso se ejecutó el comando correspondiente a cada uno de los seis discos duros. Obsérvese que no se especificó en ningún caso donde debe crearse la partición de journaling (a través del parámetro --journal), por lo que por defecto Ceph creó la partición de datos y de journaling en el mismo dispositivo especificado.

En este punto, si todos los pasos se completaron con éxito, como en el caso del presente trabajo, el clúster deberá estar totalmente funcional y sin mostrar ningún tipo de error. Para chequear su estado se puede emplear el siguiente comando:

$ ceph -s CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 44

Lo más importante a observar es el parámetro HEALT_OK que significa que no se ha registrado ningún problema en los servicios y dispositivos del clúster. En el siguiente epígrafe se explicará con detalle el significado de cada parámetro obtenido con este comando.

En caso de que algo salga mal en el proceso de instalación y no sea posible solucionar el problema de forma sencilla, se puede revertir el proceso totalmente y comenzar nuevamente. Para desinstalar Ceph, borrar las claves y los archivos de configuración en todos los nodos se pueden ejecutar los siguientes comandos:

$ ceph-deploy purge {ceph-node} [{ceph-node}] $ ceph-deploy purgedata {ceph-node} [{ceph-node}] $ ceph-deploy forgetkeys $ rm ceph.* El clúster de almacenamiento Ceph permite la noción de “pools”, que son particiones lógicas para almacenar objetos. Existen dos tipos fundamentales de pools: las pools replicadas y las de código de borrado[39]. Una pool permite establecer cuantos OSD pueden fallar sin perder datos. Para las pools replicadas, esto es el factor de replicación menos uno. Para las pools de código de borrado, esto es el número de bloques de código que se almacenarán por cada objeto. Se puede establecer el número de grupos de ubicación para cada pool, una configuración típica para clústeres pequeños usa 100 grupos de ubicación por OSD para proveer un balance óptimo sin usar muchos recursos computacionales. Las reglas del algoritmo CRUSH también pueden ser modificadas para cada pool en caso de que las reglas por defecto no sean las más apropiadas. Además, Ceph permite crear “snapshots” (toma de instantáneas) de las pools, lo cual es muy útil para copias de respaldo.

Las pools replicadas, como su nombre lo indica, mantienen una copia original del objeto y tantas réplicas como se haya especificado. Es importante aclarar que en el momento de establecer el número de copias que se mantendrá de cada objeto, Ceph interpreta que el objeto original está incluido en el número especificado. Por ejemplo, si se indica una pool replica 3, Ceph mantendrá el objeto original y dos copias de este. El número de réplicas que se mantiene de cada objeto es llamado factor de replicación.

Las pools con código de borrado son una implementación parecida a RAID 5. Para almacenar un objeto este es dividido en bloques de datos y se calculan bloques extra con códigos de CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 45 borrado a partir de los bloques de datos. El objetivo de los bloques de códigos de borrado es poder reconstruir el objeto en caso de pérdida de uno (o varios) de sus bloques de datos. Para la creación de pools de código de borrado es necesario definir antes un perfil que contendrá información sobre la implementación de la pool. Es importante establecer el perfil correcto para la creación de este tipo de pool ya que no podrá ser cambiado luego de su creación. Los parámetros más importantes del perfil son K, M y crush-failure-domain porque definen el comportamiento del almacenamiento y la durabilidad de los datos. Cada objeto es dividido en K bloques de datos y M bloques adicionales de código de borrado. El parámetro crush- failure-domain crea una regla CRUSH que asegura que los bloques son almacenados de acuerdo al dominio de fallo seleccionado.

Un sistema de archivos Ceph requiere de dos pools, una para datos y otra para metadatos. Cuando se configuran esas pools, se debe considerar usar un nivel de replicación elevado para la pool de metadatos porque cualquier pérdida de datos en ella puede hacer que todo el sistema de archivos sea inaccesible. La creación de una pool se puede llevar a cabo con el siguiente comando:

$ ceph osd pool create {nombre-pool} {pg-num} {pgp-num} \ {replicated|erasure} {crush-rule-name} \ {erasure-code-profile=profile} En el presente trabajo se empleó una pool replicada con factor de replicación 3 para los metadatos (llamada pool-meta) y una pool con código de borrado para los datos, con K=2, M=1 y crush-failure-domain=host (llamada pool-datos). Se seleccionó esta configuración para aprovechar al máximo el espacio de almacenamiento disponible mientras el dominio de fallo se mantiene en un servidor como máximo (de ahí el parámetro crush-failure- domain=host). Obsérvese que al establecer el dominio de fallo a host contando solo con tres servidores, solo es posible estos valores para K y M en la pool con códigos de borrado, pues dos fragmentos (o más) del mismo objeto no pueden almacenase en el mismo servidor (host). Por esta razón la suma K+M tiene que ser menor o igual al número total de servidores y K tiene que ser mayor que M, lo que solo nos da una combinación posible. Los comandos para la creación de las pools quedaron de la siguiente forma:

 En el caso de la pool replicada: CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 46

$ ceph osd pool create pool-meta 85 85 Como la suma total de grupos de ubicación para ambas pools tienen que ser como máximo 512 (tal y como se indicó anteriormente), a cada pool se le asignaron 256 grupos de ubicación. Cómo la pool tiene factor de replicación 3, entonces es necesario dividir 256 entre 3, lo cual da 85 grupos de ubicación (aproximado por defecto para no sobrepasar el total permisible de 256). El último parámetro es el total de grupos de ubicación para propósitos de asignación y debe ser igual al número total de grupos de ubicación.

 En el caso de la pool con código de borrado es necesario crear primeramente un perfil que especifique los parámetros de la pool. Esto se llevó a cabo con el siguiente comando:

$ ceph osd erasure-code-profile set perfilhpc k=2 m=1 \ crush-failure-domain=host Donde perfilhpc es el nombre asignado al perfil. Luego se procedió a crear la pool: $ ceph osd pool create pool-datos 85 85 \ erasure perfilhpc $ ceph osd pool set pool-datos allow_ec_overwrites

Obsérvese que en este caso se especificó que la pool es de tipo código de borrado con el argumento erasure seguido del nombre del perfil anteriormente creado y que se le asignaron 85 grupos de ubicación porque su factor de replicación también es 3. Por defecto las pools de código de borrado solo trabajan con usos que implementen la escritura completa de objetos. Para escrituras parciales de un objeto es necesario habilitar la bandera correspondiente en la pool (allow_ec_overwrites).

Con ambas pools listas para usar se procedió a crear el sistema de archivos pasando como parámetros el nombre del sistema de archivos (hpcfs), el nombre de la pool de metadatos y el nombre de la pool de datos:

$ ceph fs new hpcfs pool-meta pool-datos

Para habilitar el sistema de archivos es necesario crear e iniciar los servidores de metadatos, para lo que se ejecutó el siguiente comando:

$ ceph-deploy mds create ceph1 ceph2 CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 47

Obsérvese que los servidores de metadatos correrán en los nodos ceph1 y ceph2, tal y como se planificó anteriormente.

Como último paso antes de comenzar a usar el sistema de archivos se creó un usuario (hpc) en el clúster Ceph con permisos de lectura y escritura en los OSD, en los Ceph Monitors y en los servidores de metadatos. Es posible saltarse este paso y usar el usuario client.admin creado por defecto por Ceph para montar y usar el sistema de archivos desde los nodos clientes, pero esto puede acarrear algunos problemas de seguridad ya que este usuario tiene asignado todos los permisos en el clúster Ceph. Como el sistema de archivos será usado de igual forma por cada nodo del clúster HPC, en lugar de crear un usuario para cada nodo del HPC, se creó un único usuario (llamado hpc) desde el cual se ejecutarán todas las operaciones en los nodos del HPC. Esta acción se llevó a cabo con el siguiente comando:

$ ceph auth get-or-create client.hpc mds 'allow rw' \ ods 'allow rw' mon 'allow rw' La salida de este comando es la clave privada del usuario, la cual debe ser guardada y copiada en cada nodo que se usará como cliente, para luego poder montar el sistema de archivos.

En este punto, el sistema de archivos Ceph debe estar listo para usar. Chequeando el estado del clúster (con el comando ceph -s) se obtuvo la salida mostrada en la Figura 2.8. Como se observa, todos los servicios están corriendo tal y como se esperaba, de ahí el reporte de estado HEALT_OK.

Luego de comprobar que todos los servicios están correctamente configurados y corriendo, se procedió a montar el sistema de archivos hpcfs en todos los nodos del clúster HPC de la UCLV para realizar las pruebas pertinentes de desempeño, rendimiento y estabilidad antes de comenzar su uso regular. Para montar el sistema de archivos se empleó el comando:

$ mount -t ceph {ip-monitores}:/ {punto-montaje} \ -o name=hpc,secret={clave-secreta} Donde ip-monitores se sustituye por las direcciones ip de los monitores separadas por coma, punto-montaje es el directorio o punto de montaje donde se montará el sistema de archivos y clave-secreta es la clave secreta que se generó al crear el usuario hpc. CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 48

cluster: id: 7336136e-84d0-4086-8eb2-f8a2171da667 health: HEALTH_OK

services: mon: 3 daemons, quorum ceph2,ceph1,ceph-admin mgr: ceph1(active), standbys: ceph2 mds: hpcfs-1/1/1 up {0=ceph1=up:active}, 1 up:standby osd: 6 osds: 6 up, 6 in

data: pools: 2 pools, 170 pgs objects: 22 objects, 2.6 KiB usage: 6.2 MiB used, 2.7 TiB / 2.7 TiB avail pgs: 170 active+clean

Figura 2.8 Salida del comando "ceph -s"

2.3 Administración y supervisión del clúster Ceph La administración y supervisión del clúster es un proceso fundamental para lograr una alta disponibilidad y un buen desempeño. Detectar los errores a tiempo y corregirlos puede prevenir la pérdida parcial de datos e incluso la inaccesibilidad total del sistema de archivos. Para ellos es necesario conocer los parámetros fundamentales que deben monitorearse y el significado de los indicadores de error más comunes.

La operación más básica que se puede ejecutar en un clúster Ceph para conocer su estado se logra con el siguiente comando:

$ ceph -s

La salida de este comando (mostrada en la Figura 2.8) muestra una serie de informaciones importantes. La primera sección llamada cluster muestra el identificador único del clúster (id) y su estado actual. El estado actual es un identificador en forma de cadena de texto que orienta al administrador dónde puede estar el problema en caso de haberlo. Un funcionamiento normal debe mostrar HEALT_OK indicando que no se ha detectado ningún problema. Existe un conjunto finito de posibles mensajes de estado que Ceph puede CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 49 presentar, en el Anexo I se muestra una lista de los más importantes y su significado. La mayoría de estos problemas se pueden resolver directamente con herramientas propias de Ceph tal y como se verá más adelante. Otros, como la caída de un servidor o de un proceso en particular deben resolverse con otras herramientas del sistema operativo. Es común que por cuestiones de permisos un proceso de Ceph no pueda iniciarse o establecer comunicación a través de la red con los demás procesos, lo cual se soluciona estableciendo en el sistema operativo los permisos adecuados y las reglas del cortafuego para permitir las conexiones. Una desconfiguración de la interfaz de red de los servidores es otra de las causas por las que los servicios de Ceph no pueden unirse al clúster. En caso de reportarse la pérdida de uno de los servicios o de un host completo el primer paso es revisar que el hardware esté funcionando correctamente. Luego, que todos los servicios estén corriendo y si es posible reiniciar los que tienen problema. Si el error persiste es conveniente comprobar que la red está permitiendo la conexión entre los servicios.

La segunda sección llamada services muestra los servicios que están corriendo en el clúster y su estado, organizados por tipo. La tercera sección llamada data muestra la información básica relacionada con el almacenamiento de datos, como la cantidad de pools creadas en el sistema, la cantidad de objetos que mantiene, el estado de los grupos de ubicación y las estadísticas de utilización.

Una versión más ampliada del comando anterior es el comando:

$ ceph -w

Con él se logra la misma salida que con ceph -s, pero además se obtienen en tiempo real los registros de alto nivel de los eventos del clúster.

La información detallada de cada servicio de Ceph puede obtenerse con el comando:

$ ceph {servicio} stat

Donde servicio es sustituido por el diminutivo asociado a cada servicio que se desea analizar (mon, mgr, mds, osd). CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 50

Ceph generalmente se autorepara. Sin embargo, cuando los problemas persisten, el monitoreo de los OSDs y los grupos de ubicación puede ayudar a identificar el problema. El estado de los OSD está comprendido en dos grupos de clasificaciones:

 dentro del clúster (in) o fuera del clúster (out)  activo y corriendo (up) o inactivo (down)

Si un OSD está activo y corriendo entonces estará dentro del clúster (se puede leer y escribir en él) o fuera del clúster (no es posible leer ni escribir en él). Si estuvo dentro del clúster y luego pasa a está fuera del clúster, Ceph migrará todos los grupos de ubicación que almacena hacia otro OSD. Si un OSD está fuera del clúster, Ceph no le asignará grupos de ubicación y si está inactivo también estará fuera del clúster como consecuencia.

Uno de los problemas más comunes es la rotura de un disco duro o la necesidad de cambiarlo. En caso de que el OSD esté funcionando correctamente y se quiera reemplazar es necesario seguir una serie de pasos para recuperar los datos almacenados en él e informar al clúster que será eliminado. Lo primero es quitarle toda su carga de almacenamiento, proceso en el que Ceph reubicará todos los grupos de ubicación almacenados en el OSD hasta dejarlo vacío. Cuando el proceso anterior termine, se procede a marcar el OSD como fuera del clúster para que Ceph no lo tenga más en cuenta en los cálculos de ubicación. Luego, se elimina el OSD del mapa del clúster y se elimina el servicio correspondiente al OSD del sistema operativo que lo está ejecutando. Estas acciones se pueden llevar a cabo con los siguientes comandos, donde osd-num es el número que identifica al OSD:

$ ceph osd crush reweight osd.{osd-num} 0 $ ceph osd out {osd-num} $ ceph osd purge {osd-num} --yes-i-really-mean-it $ systemctl stop ceph-osd@{osd-num} Otros de los errores más comunes ocurren con los grupos de ubicación. El proceso de creación, replicación, rebalanceo y recuperación de fallos en el clúster, Ceph hace que frecuentemente el estado del clúster no sea HEALT_OK. Esto se debe a que para lograr este estado todos los grupos de ubicación deben estar marcados como active+clean. Como estos son procesos que forma parte de la dinámica normal del sistema, no es alarmante encontrar HEALT_WARN en el estado del clúster. Sin embargo, si el estado de alerta permanece más CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 51 tiempo de lo normal y los grupos de ubicación no alcanzan el estado active+clean es necesaria la intervención del administrador del sistema. Una lista completa de los posibles estados de los grupos de ubicación y su explicación se puede encontrar en el Anexo II. Un comando útil para obtener información sobre cada grupo de ubicación es el siguiente, el cual mostrará una lista de estos con sus estados correspondientes:

$ ceph pg dump

Periódicamente, es necesario realizar tareas de mantenimiento en el hardware del clúster o resolver un problema que implique deshabilitar temporalmente algunos OSD. El comportamiento por defecto de Ceph hará que el algoritmo CRUSH automáticamente rebalancee el clúster, lo mismo pasará cuando el OSD vuelva a incorporarse al clúster. Esto implica una gran carga para el sistema y es totalmente innecesario en este caso. Para evitar este comportamiento se debe establecer el parámetro noout antes de detener los OSD, lo cual se logra con el comando:

$ ceph osd set noout

Y se revierte con:

$ ceph osd unset noout

Información más detallada acerca de la utilización y la distribución de los datos global y en cada pool se puede obtener con la ejecución del comando:

$ ceph df

La falta de espacio libre en los discos duros es otro problema muy común. Ceph previene la escritura en un OSD lleno para evitar la pérdida de datos. En un clúster operacional, se debe recibir una advertencia cuando el clúster está cerca de su capacidad máxima. El parámetro mon osd full ratio está establecido por defecto al valor 0.95, lo que significa que se puede alcanzar hasta el 95% de la capacidad total antes de que la escritura de los clientes sea detenida. El parámetro mon osd nearfull ratio está establecido por defecto a 0.85, lo que significa que cuando se supere el 85% de la capacidad de almacenamiento se generará una advertencia de salud del clúster, pero seguirán teniendo lugar los procesos de escritura. Es posible modificar estos parámetros de acuerdo a las necesidades. La mejor forma de lidiar CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 52 con un clúster agotado en cuanto a capacidad de almacenamiento es agregar nuevos OSDs, permitiendo la redistribución de los datos hacia el nuevo espacio disponible.

2.4 Conclusiones del capítulo Luego de lo descrito en las secciones anteriores se puede concluir que Ceph es una potente y flexible plataforma de almacenamiento definido por software. Permite manejar el Almacenamiento de Objetos Ceph, de Dispositivos de Bloques Ceph y de Sistemas de Archivos Ceph desde una única plataforma integrada. Luego de una correcta planificación y preparación, su instalación a través de ceph-deploy es un proceso sencillo. Con un archivo de configuración y un pequeño número de comandos es posible desplegar el sistema de almacenamiento deseado. Existe un gran número de posibles configuraciones que permiten acomodar Ceph a las necesidades de casi cualquier escenario. Posee herramientas de gestión y supervisión muy útiles que permiten al administrador del sistema detectar cualquier irregularidad en el sistema de almacenamiento y corregirla manualmente en caso de que Ceph no sea capaz de hacerlo automáticamente. La ausencia de un único punto de fallo en el clúster Ceph lo hacen altamente confiable y estable. Además, Ceph se acomoda a una gran variedad de hardware y es software libre.

Sin lugar a dudas, Ceph es una excelente alternativa cuando se trata de sistemas de almacenamiento para sistemas HPC y para cualquier aplicación en general que requiera un alto desempeño y rendimiento.

CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 53 CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC

En este capítulo se muestran los resultados obtenidos en la implementación del sistema de archivos Ceph para el clúster HPC del Centro de Datos de la UCLV.

En el primer epígrafe se realizan diferentes pruebas de estabilidad al clúster Ceph que incluyen el fallo de servicios, la indisponibilidad de servidores y afectaciones en la red. Teniendo siempre en cuenta que no se supere el dominio de fallo preestablecido. En cada prueba se describe el procedimiento realizado y el comportamiento de Ceph en todo momento.

En el segundo epígrafe se realizan las pruebas de rendimiento al clúster empleando las herramientas RADOS Bench, DD y Bonnie++. Para cada una se presenta el comando empleado, explicando los parámetros utilizados. Se exponen y analizan los resultados obtenidos.

Luego, en el tercer epígrafe se llevan a cabo algunas pruebas al servidor NFS que en el momento de realización del presente trabajo brinda servicios al clúster HPC. Los resultados son presentados, analizados y comparados con los obtenidos en el epígrafe anterior para el sistema de archivos Ceph.

Finalmente, a modo de conclusión, se expresa el buen desempeño del sistema de archivos Ceph ante las pruebas realizadas, que demuestran que Ceph es una excelente opción cuando se necesita rendimiento elevado y estabilidad. CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 54 3.1 Estabilidad del clúster Ceph ante fallos de software y hardware Ceph está diseñado para no tener un único punto de fallo, lo que significa que ante algún fallo de software o hardware debe ser capaz de recuperarse automáticamente sin interrumpir sus servicios, siempre que este no exceda el dominio de fallo. En Ceph esto se logra con la redundancia de servicios para el caso de los Ceph Monitors, los Ceph Managers y los servidores de metadatos Ceph, y con el factor de replicación para el caso de las pools en los OSDs. Tal y como se especificó en el capítulo anterior, en el presente trabajo, por el hecho de tener solo tres servidores disponibles para la implementación del clúster Ceph, el dominio de fallo está restringido a solo un servidor a la vez. O sea, que el clúster Ceph debe ser capaz de recuperarse como máximo a la caída de todos los servicios de un servidor a la vez. Si por alguna razón dejan de estar disponibles dos o más servicios del mismo tipo en diferentes servidores, el clúster Ceph dejará de estar operativo y por consecuencia el sistema de archivos Ceph no será accesible para lectura ni para escritura.

Para comprobar la estabilidad del clúster Ceph, se llevaron a cabo algunos experimentos que implican la caída de uno o varios servicios de Ceph, teniendo cuidado siempre de no superar el dominio de fallo. Esto se realizó con el objetivo de observar el comportamiento del sistema ante esta situación, comprobar si este era capaz de recuperarse completamente de forma automática mientras continuaba prestando servicios al clúster HPC y de mantener una calidad aceptable de los servicios. Todas las pruebas fueron realizadas sobre los servidores ceph1 y ceph2 porque son los que corren los cuatro servicios de Ceph (MON, MDS, MGR, OSD), para así simular las situaciones más críticas que el clúster Ceph implementado debe soportar.

El primer experimento fue apagar uno de estos dos servidores. En el momento de llevarlo a cabo se encontraba el servidor ceph1 activo como MDS y MGR, y el servidor ceph2 en espera para estos servicios. Entonces, se decidió apagar el servidor ceph1. Para comprobar que el clúster Ceph continúa prestando servicios, se inició un proceso de escritura y otro de lectura en uno de los nodos clientes. Automáticamente luego de apagar el servidor ceph1, Ceph mostró el estado HEALT_WARN como se esperaba (ver Anexo IV), con los mensajes:

 MDSs en espera insuficientes  2 OSDs inactivos (down)  1 servidor inactivo CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 55  1 de 3 MONs inactivo  Redundancia de datos degradada

Todos los grupos de ubicación fueron marcados como active+undersized+degraded, active+undersized o incomplete lo cual indica que están activos y disponibles, pero están degradados o incompletos porque no existe el número de réplicas adecuado para cada objeto. Unos segundos más tardes, comenzó el proceso de rebalanceo (como se puede observar en el anexo V), mostrándose progresivamente los grupos de ubicación con problema con el estado active+undersized+degraded+remapped+backfill, lo cual indica que los objetos degradados están siendo reubicados y replicados hasta alcanzar nuevamente el factor de replicación. Esto solo pasó con los objetos pertenecientes a la pool de metadatos (aproximadamente el 6% de los objetos), los cuales luego de aproximadamente 5 minutos pasaron al estado active+clean+remapped (ver Anexo VI). Debido a que la pool de datos es de tipo con códigos de borrado, con factor de replicación 3 y que en su perfil se especificó como dominio de fallo el servidor, no es posible reubicar los objetos pertenecientes a ella porque solo quedan dos servidores disponibles y no pueden existir dos réplicas del mismo objeto en el mismo servidor para este tipo de perfil. Por esto, los objetos pertenecientes a la pool de datos permanecieron en el estado active+undersized+degraded o active+undersized. Además, es preciso aclarar que luego de culminar el rebalanceo, Ceph indicó en su estado que aproximadamente el 6% de los objetos estaban fuera de lugar. Esto se debe a que los objetos reubicados de la pool de metadatos están replicados pero no están distribuidos correctamente de acuerdo al dominio de fallo.

Al observar los procesos de lectura y escritura (observable en el anexo V y VI en la sección client) se puedo verificar que el clúster Ceph permaneció dando servicio en todo momento, aún en estado degradado. Aunque en el momento del rebalanceo las razones de transferencia disminuyeron en un 40% aproximadamente y luego se mantuvieron disminuidas en un 20% aproximadamente con respecto al estado inicial.

Cuando el servidor ceph1 fue reiniciado, se observó que sus servicios Ceph se incorporaron al clúster nuevamente y que comenzó el proceso de recuperación (ver Anexo VII). Todos los grupos de ubicación con problemas pasaron al estado active+recovering+degraded y progresivamente fueron pasando al estado active+clean. Unos 5 minutos más tarde, el clúster CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 56 Ceph cambió su estado a HEALT_OK y todos los grupos de ubicación fueron marcados como active+clean, mostrando que se había recuperado completamente. Durante la recuperación los procesos de lectura y escritura también permanecieron con afectaciones mínimas en cuanto a las razones de transferencia, hasta que una vez recuperado el clúster tomaron sus valores iniciales.

El segundo experimento fue desconectar las interfaces de red del servidor ceph2 una a la vez, que en el momento de la prueba tenía los servicios de MDS y MGR como activos. Esta prueba tiene el objetivo de simular un corte en la red. Cuando se desconectó la interfaz de red perteneciente a la red de acceso, ocurrió exactamente lo mismo que en el experimento anterior. Para el caso de la interfaz de red perteneciente a la red del clúster, solo fueron marcados los 2 OSDs pertenecientes a ese servidor como inactivos y sus correspondientes grupos de ubicación como active+undersized+degraded semejante al caso anterior. Antes de que los OSDs fueran marcados como fuera del clúster y comenzara el rebalanceo, se reconectó la interfaz de red. En este caso no se obtuvo el resultado esperado, ya que luego de varios minutos se observaba que los 2 OSDs permanecían inactivos. Una minuciosa revisión mostró que el problema radicaba en que los servicios correspondientes a los OSDs se habían detenido y fue necesario reiniciarlos manualmente. Esto se debió a que el proceso de desconexión de la interfaz de red se realizó por software, inhabilitando la interfaz de red en el sistema operativo. Por el contrario, una desconexión física del cable de red no causó que los servicios relativos a los OSDs se detuvieran. Luego de reiniciarlos, los OSDs se incorporaron al clúster Ceph y comenzó el proceso de recuperación automática. Unos minutos más tardes el clúster había vuelto a la normalidad.

El tercer experimento fue detener selectivamente los servicios del clúster, teniendo en cuenta no sobrepasar el dominio de fallo, y reiniciarlos nuevamente. Esto se hizo para simular una caída inesperada de algún servicio de Ceph. Para detener e iniciar los servicios se usaron los comandos siguientes respectivamente:

$ systemctl stop {servicio} $ systemctl start {servicio}

Donde {servicio} se sustituye por el servicio en cuestión. En esta prueba, la recuperación del clúster ocurrió de forma automática en todos los casos como se esperaba y Ceph mostró CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 57 los mensajes de error correspondientes a cada servicio en cada caso. Cuando se detenía un servicio, su homólogo en espera pasaba a activo y cuando el servicio se reiniciaba se incorporaba al clúster sin problemas. Es necesario aclarar que Ceph no reinicia los servicios detectados con problema automáticamente, cuando el administrador del sistema detecta este tipo de errores el servicio debe ser reiniciado manualmente.

3.2 Rendimiento del clúster Ceph Luego de demostrar en el epígrafe anterior que el clúster Ceph implementado en el presente trabajo es estable y responde de la forma esperada a los fallos de hardware o software, se procederá a realizar algunas pruebas de rendimiento del sistema de archivos bajo diferentes condiciones. Las herramientas seleccionadas para poner a prueba el sistema son RADOS Bench, DD y Bonnie++, las cuales tienen una excelente reputación cuando se trata de probar sistemas de almacenamiento y han sido empleadas en varios artículos científicos de alto prestigio [40]. El objetivo de las pruebas realizadas es determinar las razones de transferencia para lectura y escritura de archivos, la cantidad de pedidos que se pueden hacer al sistema por segundo, la cantidad de operaciones sobre los metadatos de archivos que se pueden realizar por segundo y la latencia de respuesta.

Como se describió en el capítulo anterior, el sistema de archivos Ceph se montó en cada nodo del clúster HPC. Para facilitar la realización de las pruebas de rendimiento, se usó el gestor de tareas SLURM del clúster HPC, el cual permitió ejecutar varias instancias de la misma herramienta de prueba en diferentes nodos en el mismo momento. Esto permitió simular el comportamiento real del clúster HPC cuando varios programas corriendo en diferentes nodos hacen uso del sistema de archivos a la misma vez.

Con las herramientas DD y Bonnie++ se realizaron tres pruebas diferentes. La primera, se realizó con una instancia de la herramienta corriendo en un solo nodo. La segunda, con cuatro instancias de la herramienta distribuidas en cuatro nodos diferentes; y la tercera, con ocho instancias de la herramienta distribuidas en ocho nodos diferentes (solo una instancia por servidor en todos los casos). Es importante aclarar que los nodos son asignados seudoaleatoriamente por el gestor de tareas SLURM de acuerdo a la disponibilidad y las cargas de trabajo del clúster HPC, por lo que cada corrida del experimento, en la mayoría de los casos, tuvo lugar en nodos diferentes (es necesario aclarar que cuando se dice nodos CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 58 diferentes se refiere a nodos con diferente nombre de máquina, todos los nodos del HPC tienen las mismas características de hardware y software). Además, en el momento en que se realizaron los experimentos solo las herramientas de prueba estaban haciendo uso del sistema de archivos, lo que permitió determinar los valores reales de desempeño del clúster Ceph.

A continuación, se describirán brevemente las herramientas de prueba empleadas, se explicarán con detalle las pruebas realizadas y se analizarán los resultados obtenidos en cada una de ellas.

3.2.1 RADOS Bench Ceph incluye el comando rados bench[41], diseñado especialmente para analizar el rendimiento de los clústeres de almacenamiento RADOS al nivel de la pool. Esta herramienta soporta pruebas de escritura, lectura secuencial y lectura aleatoria. Permite tener una idea del desempeño real del sistema ya que se ejecuta directamente en los servidores del clúster Ceph, por lo que no intervienen factores como las condiciones de la conexión de red entre el cliente y los servidores del clúster Ceph. Como rados bench funciona a nivel de pool y se considera que la pool más crítica para el desempeño del sistema es la pool de datos (pool-datos), se realizó la prueba solo con esta. El comando empleado fue:

$ rados -p pool-datos bench 300 write|seq|rand -t 32 [--no- cleanup]

Donde 300 es el tiempo en segundos que durará la prueba. Este número fue escogido por conveniencia, ya que equivale a 5 minutos de prueba lo cual es suficiente. Las opciones write, seq y rand especifican el tipo de prueba que se realizará que puede ser de escritura, lectura secuencial o lectura aleatoria respectivamente. El valor 32 especifica el número de operaciones de lectura o escritura concurrentes para la prueba, por defecto este valor es 16, en el presente trabajo se realizaron pruebas para un valor de 16 y 32 pero los resultados obtenidos fueron muy semejantes, por lo que se decidió solo presentar los resultados para un valor de 32 operaciones concurrentes. El parámetro --no-cleanup solo es válido cuando la prueba es de escritura y se especifica para indicar al programa que no borre los datos escritos al finalizar la prueba, lo que permitirá más tarde realizar las pruebas de lectura sobre estos datos. CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 59 Los resultados de la prueba de escritura se muestran en la Tabla 3.

Tabla 3. Resultados de RADOS Bench para escritura

Escrituras totales 12332 Tamaño de escritura por objeto 4194304 bytes Ancho de banda* 164.0 MB/s IOPS* 41 Latencia* 0.7796 s Latencia máxima 2.5317 s * Representan los valores promedios. IOPS: operaciones de lectura/escritura por segundo

Los resultados de las pruebas de lectura secuencial y aleatoria se muestran en la Tabla 4.

Tabla 4. Resultados de RADOS Bench para lectura secuencial y aleatoria

Lectura secuencial Lectura aleatoria Lecturas totales 12985 12930 Tamaño de lectura por objeto 4194304 bytes 4194304 bytes Ancho de banda* 173.3 MB/s 171.8 MB/s IOPS* 43 42 Latencia* 0.7369 s 0.7434 s Latencia máxima 2.6254 s 2.5696 s * Representan los valores promedios. IOPS: operaciones de lectura/escritura por segundo

Como se observa en ambas tablas, las pruebas se realizaron con un tamaño de bloque por defecto de 4MB. El ancho de banda promedio da una idea de cuál es el máximo teórico que se puede alcanzar por los clientes para el estado actual del clúster Ceph. En este caso los valores obtenidos son relativamente altos. Los valores de la latencia también son aceptables para un ambiente HPC. Obsérvese que el número de operaciones de lectura/escritura por segundo (IOPS) promedio se relaciona directamente con el total de lecturas o escrituras, pues el resultado de multiplicar las IOPS por 300 es aproximadamente el total de operaciones. CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 60 3.2.2 DD DD[42] es un comando de la familia de los sistemas operativos Unix que permite copiar y convertir datos de archivos a bajo nivel. Es muy sencillo de usar y comúnmente empleado en las pruebas de rendimiento de los discos duros y los sistemas de archivos. Es la prueba básica ya que no es muy configurable y solo brinda la razón de transferencia promedio de la operación ejecutada.

Los comandos empleados en este caso fueron:

 Para la prueba de escritura: $ dd count={num-bloques} if=/dev/zero of={archivo-salida}  Para la prueba de lectura: $ dd if={archive-entrada} of=/dev/null

Por defecto, DD escribe y lee bloques con tamaño de 512 bytes. Con el parámetro num- bloques es posible especificar el número de bloques de 512 bytes que serán leídos y escritos posteriormente, controlando así la cantidad total de datos que será transferidos. Se realizaron pruebas para tres valores distintos del número de bloques, para simular la lectura/escritura de archivos relativamente pequeños, medianos y grandes. En las pruebas de lectura, el archivo de entrada es el mismo que el archivo de salida de las pruebas de escritura, por lo que la cantidad de datos transferidas en cada caso es la misma. Los resultados obtenidos en este experimento se muestran en las Tablas Tabla 5 y Tabla 6.

Tabla 5. Resultados de DD para escritura en Ceph

Total transferido 1 hilo (MB/s) 4 hilos* (MB/s) 8 hilos* (MB/s) 10.24 GB 98,8 32.5 18.12 512 MB 140 136.75 135.25 10.24 MB 109 106.2 111.22 * Valor promedio por hilo

Tabla 6. Resultados de DD para lectura en Ceph

Total transferido 1 hilo (MB/s) 4 hilos* (MB/s) 8 hilos* (MB/s) 10.24 GB 120 31.4 16.4 CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 61 512 MB 131 95 89 10.24 MB 142 139 129 * Valor promedio por hilo

Para el caso de las pruebas de escritura se observa como disminuye la razón de transferencia cuando aumenta el número de hilos que escriben un gran volumen de datos de forma simultánea, esto se debe a que la razón máxima de transferencia para escritura se distribuye entre todos los hilos de forma tal que si se multiplica el número de hilos por la razón de transferencia promedio por hilo se obtendrá un valor similar en cada caso. Sin embargo, para volúmenes de datos pequeños como 512MB o 10 MB las razones de transferencia se mantienen con muy poca variación. Obsérvese que este valor está cercano al obtenido en el experimento anterior con RADOS Bench lo cual significa que la influencia de la conexión de red no es considerable para el desempeño del clúster Ceph.

Las pruebas de lectura muestran un comportamiento similar. Cuando aumenta el número de nodos que leen datos de forma concurrente, Ceph distribuye el ancho de banda de lectura disponible entre todos los nodos. Sin embargo, al disminuir el volumen de datos se observa que las razones de transferencia mejoran.

3.2.3 Bonnie++ Bonnie++ [43] es una herramienta de evaluación comparativa del sistema de archivos, de software libre, para sistemas operativos Unix y similares. Es una suite de referencia que tiene como objetivo realizar varias pruebas simples de rendimiento del sistema de archivos y el disco duro. Permite comparar el rendimiento de los sistemas de archivos con respecto a la velocidad de escritura y lectura de datos, el número de búsquedas que se pueden realizar por segundo y el número de operaciones de metadatos de archivos que se pueden realizar por segundo.

El comando empleado para las pruebas con Bonnie++ fue:

$ bonnie++ -d {punto-montaje} -s 5g -r 10g

Donde punto-montaje es el directorio donde fue montado el sistema de archivos Ceph en los nodos del clúster HPC, 5g es el tamaño total de los archivos para la prueba y 10g el máximo de RAM que podrá usar el programa Bonnie++ (obsérvese que la g significa que está CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 62 expresado en GB). Los resultados obtenidos se muestran en las Tablas Tabla 7, Tabla 8, Tabla 9, Tabla 10, Tabla 11 y Tabla 12.

Tabla 7. Resultados de Bonnie++ en Ceph para 1 hilo parte I

Escritura secuencial Lectura secuencial Búsquedas aleatorias KB/seg % CPU KB/seg % CPU /seg % CPU 95053 10 301836 99 12517 46 Latencia 62310us 144us 20076us

Tabla 8. Resultados de Bonnie++ en Ceph para 1 hilo parte II

Creación secuencial Creación aleatoria Creación Lectura Borrado Creación Lectura Borrado Para 16 % % % % % % archivos /seg /seg /seg /seg /seg /seg CPU CPU CPU CPU CPU CPU 958 3 +++* +++* 1404 3 1256 4 2654 6 1187 3 Latencia 892ms 10447us 200ms 810ms 1408us 76958us *Cuando Bonnie++ determina que un resultado no es lo suficientemente preciso lo muestra como +++. Esto puede deberse a que es demasiado grande o pequeño.

Tabla 9. Resultados de Bonnie++ en Ceph para 4 hilos parte I

Escritura secuencial Lectura secuencial Búsquedas aleatorias KB/seg % CPU KB/seg % CPU /seg % CPU 28819 3 237707 99 7749 28 Latencia 225ms 342us 28012us

Tabla 10. Resultados de Bonnie++ en Ceph para 4 hilos parte II

Para 16 Creación secuencial Creación aleatoria archivos Creación Lectura Borrado Creación Lectura Borrado CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 63 % % % % % % /seg /seg /seg /seg /seg /seg CPU CPU CPU CPU CPU CPU 624 3 +++* +++* 739 2 825 3 1975 5 1332 4 Latencia 1262ms 21296us 640ms 939ms 146ms 156ms *Cuando Bonnie++ determina que un resultado no es lo suficientemente preciso lo muestra como +++. Esto puede deberse a que es demasiado grande o pequeño.

Tabla 11. Resultados de Bonnie++ en Ceph para 8 hilos parte I

Escritura secuencial Lectura secuencial Búsquedas aleatorias KB/seg % CPU KB/seg % CPU /seg % CPU 15081 1 298548 99 2356 10 Latencia 201ms 362us 24656us

Tabla 12. Resultados de Bonnie++ en Ceph para 8 hilos parte II

Creación secuencial Creación aleatoria Creación Lectura Borrado Creación Lectura Borrado Para 16 % % % % % % archivos /seg /seg /seg /seg /seg /seg CPU CPU CPU CPU CPU CPU 480 2 +++* +++* 557 2 714 2 1239 3 1032 3 Latencia 3515ms 44939us 1289ms 1122ms 622ms 533ms *Cuando Bonnie++ determina que un resultado no es lo suficientemente preciso lo muestra como +++. Esto puede deberse a que es demasiado grande o pequeño. Es necesario aclarar que para las tablas correspondiente a 4 y 8 hilos, los resultados corresponden al promedio por hilo. Además de las razones de transferencia y las operaciones por segundo, con Bonnie++ se obtienen otros valores muy importantes que permiten analizar con más profundidad el rendimiento del clúster Ceph. El uso del procesador (% CPU), muestra cuanto esfuerzo de procesamiento realizó la máquina para llevar a cabo las operaciones. Generalmente, en los ambientes HPC los programas de cálculo científico ocupan casi totalmente el procesador, por lo que los demás procesos deben ocupar el mínimo de CPU posible. Entonces, mientras más alto es este valor en la tabla, peor es para el CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 64 rendimiento del clúster HPC. La latencia es otro parámetro importante, ya que también influye directamente en el rendimiento del clúster HPC. Un alto valor en la latencia retrasará la ejecución de los programas del HPC.

Como se observa, los resultados obtenidos para escritura son muy semejantes a los obtenidos con la herramienta DD y el uso de CPU se mantiene bajo. Sin embargo, para las pruebas de lectura se observa como las razones de transferencia en la mayoría de los casos superan al promedio obtenido en las pruebas anteriores con RADOS Bench y DD. Esto se debe al uso de la caché de datos por parte de Ceph y del sistema operativo. Al almacenar algunos datos en memoria RAM, Ceph es capaz de responder con mayor velocidad a los pedidos de lectura. Además, el sistema operativo Linux hace uso de la caché de datos para asegurar mayores razones de transferencia. En el caso de las herramientas anteriores fue posible burlar la caché del sistema operativo usando diferentes métodos, pero para Bonnie++ no fue posible por su forma de operar y porque no tiene opciones para manejar esta característica.

3.3 Comparación con el sistema de archivos NFS En el momento en que se llevó a cabo el presente trabajo, el clúster HPC del Centro de Datos de la UCLV contaba con un servidor NFS que servía como sistemas de archivos compartido. Con el objetivo de comparar el desempeño del clúster Ceph implementado y el del servidor NFS, se realizaron algunas pruebas similares a las anteriores al servidor NFS. Lógicamente no fue posible emplear en este caso la herramienta RADOS Bench, ya que esta está diseñada única y exclusivamente para Ceph. Para el caso de DD y Bonnie++ se muestran a continuación los resultados obtenidos.

Tabla 13. Resultados de DD para escritura en NFS

Total transferido 1 hilo (MB/s) 4 hilos* (MB/s) 8 hilos* (MB/s) 10.24 GB 53.1 25.2 13.3 512 MB 58.7 67.1 45.1 10.24 MB 54 66.2 55.9

CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 65 Tabla 14. Resultados de DD para lectura en NFS

Total transferido 1 hilo (MB/s) 4 hilos* (MB/s) 8 hilos* (MB/s) 10.24 GB 109 26.2 11.1 512 MB 110 75 55 10.24 MB 112 81 61

Tabla 15. Resultados de Bonnie++ en NFS parte I

Escritura secuencial Lectura secuencial Búsquedas aleatorias KB/seg % CPU KB/seg % CPU /seg % CPU 65349 5 77607 7 10016 12 Latencia 4200ms 420ms 26787us

Tabla 16. Resultados de Bonnie++ en NFS parte II

Creación secuencial Creación aleatoria Creación Lectura Borrado Creación Lectura Borrado Para 16 % % % % % % archivos /seg /seg /seg /seg /seg /seg CPU CPU CPU CPU CPU CPU 724 18 +++* +++* 1665 25 730 18 3818 24 1747 24 Latencia 202ms 16158us 47455us 58483us 951us 11624us *Cuando Bonnie++ determina que un resultado no es lo suficientemente preciso lo muestra como +++. Esto puede deberse a que es demasiado grande o pequeño. Como se puede observar, los resultados obtenidos para el servidor NFS son peores que los obtenidos en el clúster Ceph. Es preciso analizar que, para 4 y 8 hilos en las pruebas de escritura con DD para 10.24 GB de datos, los resultados entre Ceph y NFS se acercan. Esto se debe a que los 3 discos duros del servidor NFS están en la configuración RAID 0, lo que significa que los datos no se replican y la carga de trabajo se distribuye entre todos los discos, mejorando las razones de transferencia. Por el contrario, Ceph está configurado con un factor de replicación igual a 3 por lo que todos los datos tienen que escribirse 3 veces en discos duros diferentes para que se complete cada operación de escritura. Este proceso de CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC 66 replicación introduce una demora en el proceso de escritura, entonces la demora total sería la suma de las demoras que agrega cada nodo al sistema cuando ejecuta procesos de escritura. Esto justifica que los valores para los dos sistemas de archivos se asemejen cuando aumenta el número de hilos de escritura. Pero, aun así, Ceph muestra una razón de transferencia mayor.

3.4 Análisis de los resultados obtenidos De modo general, los resultados obtenidos muestran que el rendimiento del sistema de archivos Ceph es muy bueno. Las razones de transferencia totales muestran valores relativamente altos, mientras que la latencia muestra valores aceptablemente bajos. La razón de transferencia total para los procesos de escritura, casi siempre se mantuvieron cerca o por encima de los 100 MB/s como promedio. Este valor es comparable (o superior en varios casos) a la razón de transferencia para escritura que se obtiene en los discos duros mecánicos que están disponibles actualmente en el mercado.

Las razones de transferencia para los procesos de lectura también muestran valores elevados. Ceph hace uso de la caché de datos y el acceso paralelo para aumentar el rendimiento del sistema en los procesos de lectura. Las velocidades de búsqueda, creación y eliminación de archivos también muestran valores capaces de cubrir cómodamente las necesidades del clúster HPC.

3.5 Conclusiones del capítulo Luego de lo descrito en el presente capítulo se puede concluir que el clúster Ceph presenta una alta estabilidad y es capaz de recuperarse automáticamente ante los fallos de software y de hardware que no superen su dominio de fallo, lo que lo hace altamente confiable. Las pruebas de rendimiento realizadas, mostraron que el sistema de archivos Ceph se desempeña muy bien en todas las operaciones con archivos y logra razones de transferencia elevadas manteniendo baja la latencia, aun cuando aumenta el número de operaciones concurrentes. No siendo así para el caso del servidor NFS, que mostró resultados desfavorables con respecto al clúster Ceph. El rendimiento de Ceph lo hace ideal para ambientes HPC donde la velocidad es clave.

CONCLUSIONES Y RECOMENDACIONES 67

CONCLUSIONES Y RECOMENDACIONES

Conclusiones 1. En la actualidad, existen múltiples variantes de sistemas de almacenamiento definido por software, cada uno con sus características particulares que lo hacen más adecuado para algunos entornos. En el área de la computación de alto rendimiento y el Big Data se encuentran entre las opciones más populares Ceph y Lustre. 2. Cualquier sistema operativo basado en Linux deberá correr sin problemas los componentes de softwares de Ceph, siempre que cumpla con los requerimientos de la versión específica a instalar. Ceph se acomoda a casi cualquier hardware, pero para lograr un desempeño óptimo es necesario cubrir los requerimientos mínimos especificados en la documentación oficial referidos a recursos de hardware. 3. El proceso de implementación de un sistema de almacenamiento distribuido Ceph, empleando la herramienta ceph-deploy, es sencillo y cómodo, con un reducido número de comandos es posible tener un clúster Ceph totalmente operacional. La gran cantidad de opciones de configuración disponibles en Ceph permiten adaptar la instalación a las necesidades del escenario de desarrollo. 4. Las herramientas de Ceph hacen que la gestión y administración del clúster sea un proceso preciso, agradable e intuitivo. 5. Ceph presenta una alta estabilidad debido a que no tiene un único punto de fallo, es capaz de recuperarse automáticamente ante fallos de software o hardware que no superen su dominio de fallo. 6. El excelente rendimiento de Ceph, lo hace ideal para ambientes HPC donde la velocidad es un factor crítico, superando a otras tecnologías de almacenamiento distribuido como NFS.

CONCLUSIONES Y RECOMENDACIONES 68

Recomendaciones Se propone como recomendaciones:

 Automatizar el proceso de instalación del clúster Ceph con la herramienta Puppet, lo que puede permitir un despliegue más rápido y menos propenso a errores.  Configurar la caché del clúster Ceph de forma tal que el espacio de almacenamiento “rápido” resida en discos de estado sólido (SSD) y realizar las pruebas pertinentes para verificar que el rendimiento del sistema mejora.  Mover las particiones de journaling de los OSDs hacia discos de estado sólido (SSD), lo que debe mejorar el rendimiento del sistema.

BIBLIOGRAFÍA 69

BIBLIOGRAFÍA [1] «A General-Purpose File System For Secondary Storage». [En línea]. Disponible en: https://www.multicians.org/fjcc4.html. [Accedido: 21-mar-2019]. [2] Raúl Juncos, «Sistema de ficheros GNU/Linux», Sistema de ficheros, 21-ene-2008. [En línea]. Disponible en: http://observatorio.cnice.mec.es/modules.php?op=modload&name=News&file=article &sid=549. [Accedido: 15-mar-2019]. [3] «File system», Wikipedia. 24-feb-2019. [4] «File Systems and Volume Managers: History and Usage». [En línea]. Disponible en: https://www.enterprisestorageforum.com/technology/features/article.php/2026611/File- Systems-and-Volume-Managers-History-and-Usage.htm. [Accedido: 21-mar-2019]. [5] «(9) Parallel File System VS for Dummies | LinkedIn». [En línea]. Disponible en: https://www.linkedin.com/pulse/parallel-file-system-vs-network- dummies-briti-gangopadhay/. [Accedido: 18-mar-2019]. [6] «Definición de Árbol de directorios (informática)». [En línea]. Disponible en: http://www.alegsa.com.ar/Dic/arbol_de_directorios.php. [Accedido: 28-mar-2019]. [7] «Sistemas de archivos», Sistemas de archivos. [En línea]. Disponible en: http://www.rinconsolidario.org/linux/cursoLinux/comoInstalarLinux/particiones/fs.htm l. [Accedido: 15-mar-2019]. [8] «Definicion de Sistema de archivos de disco». [En línea]. Disponible en: http://www.alegsa.com.ar/Dic/sistema_de_archivos_de_disco.php. [Accedido: 26-mar- 2019]. [9] «Sistema de archivos», Wikipedia, la enciclopedia libre. 23-mar-2019. [10] «», Wikipedia. 31-oct-2017. [11] «Ext4 Howto - Ext4». [En línea]. Disponible en: https://ext4.wiki.kernel.org/index.php/Ext4_Howto. [Accedido: 01-abr-2019]. [12] «Chapter 3. The XFS File System», Red Hat Customer Portal. [En línea]. Disponible en: https://access.redhat.com/documentation/en- us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-xfs. [Accedido: 19-jun-2019]. [13] «XFS FAQ - XFS.org». [En línea]. Disponible en: http://xfs.org/index.php/XFS_FAQ. [Accedido: 01-abr-2019]. [14] «Definicion de Sistema de archivos de propósito especial». [En línea]. Disponible en: http://www.alegsa.com.ar/Dic/sistema_de_archivos_de_proposito_especial.php. [Accedido: 28-mar-2019]. [15] «Definicion de Sistema de archivos de red». [En línea]. Disponible en: http://www.alegsa.com.ar/Dic/sistema_de_archivos_de_red.php. [Accedido: 01-abr- 2019]. [16] A. S. T. Maarten Van Steen, Distributed System. Principles and Paradigms, Second. Pearson. [17] «Almacenamiento - Sistemas Distribuidos y Cluster». [En línea]. Disponible en: https://sites.google.com/site/sistemasdistribuidosycluster/almacenamiento. [Accedido: 13-mar-2019]. [18] A. S. ELIEZER LEVY, «Distributed File Systems: Concepts and Examples», Department of Computer Sciences, University of Texas at Austin, Austin, Texas 78712-l 188, vol. 22, n.o 4. BIBLIOGRAFÍA 70 [19] B. Nowicki, «NFS: Network File System Protocol specification», 1989. [20] «RAID level 0, 1, 5, 6 and 10 | Advantage, disadvantage, use». [En línea]. Disponible en: https://www.prepressure.com/library/technology/raid. [Accedido: 09- abr-2019]. [21] «What is network-attached storage (NAS)? - Definition from WhatIs.com», SearchStorage. [En línea]. Disponible en: https://searchstorage.techtarget.com/definition/network-attached-storage. [Accedido: 15-may-2019]. [22] «JBOD (Just a Bunch of Disks)». [En línea]. Disponible en: https://www.microgamma.com/tecnologia/jbod.php. [Accedido: 15-may-2019]. [23] T. H. C. David Kotz, «Integrating Theory and Practice in Parallel File Systems». [24] «Object storage», Wikipedia. 14-may-2019. [25] «Block-level storage», Wikipedia. 26-feb-2019. [26] «IBM General Parallel File System (GPFS)», 24-oct-2014. [En línea]. Disponible en: undefined. [Accedido: 15-may-2019]. [27] «HDFS Architecture Guide». [En línea]. Disponible en: https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html. [Accedido: 15-may-2019]. [28] «BeeGFS - The Leading Parallel Cluster File System», BeeGFS. [En línea]. Disponible en: https://www.beegfs.io/content/. [Accedido: 15-may-2019]. [29] «Lustre». [En línea]. Disponible en: http://lustre.org/. [Accedido: 15-may-2019]. [30] «Gluster | Storage for your Cloud». [En línea]. Disponible en: https://www.gluster.org/. [Accedido: 15-may-2019]. [31] «Welcome to Ceph — Ceph Documentation». [En línea]. Disponible en: http://docs.ceph.com/docs/master/. [Accedido: 15-may-2019]. [32] S. A. Weil, A. W. Leung, S. A. Brandt, y C. Maltzahn, «RADOS: a scalable, reliable storage service for petabyte-scale storage clusters», en Proceedings of the 2nd international workshop on Petascale data storage held in conjunction with Supercomputing ’07 - PDSW ’07, Reno, Nevada, 2007, p. 35. [33] S. Weil, S. Brandt, E. Miller, y C. Maltzahn, «CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data», en ACM/IEEE SC 2006 Conference (SC’06), Tampa, FL, USA, 2006, pp. 31-31. [34] «Ceph Filesystem — Ceph Documentation». [En línea]. Disponible en: http://docs.ceph.com/docs/master/cephfs/. [Accedido: 19-jun-2019]. [35] «Architecture — Ceph Documentation». [En línea]. Disponible en: http://docs.ceph.com/docs/master/architecture/. [Accedido: 19-jun-2019]. [36] «Hardware Recommendations — Ceph Documentation». [En línea]. Disponible en: http://docs.ceph.com/docs/jewel/start/hardware-recommendations/. [Accedido: 19-jun- 2019]. [37] «OS Recommendations — Ceph Documentation». [En línea]. Disponible en: http://docs.ceph.com/docs/jewel/start/os-recommendations/. [Accedido: 19-jun-2019]. [38] «Installation (ceph-deploy) — Ceph Documentation». [En línea]. Disponible en: http://docs.ceph.com/docs/master/start/. [Accedido: 19-jun-2019]. [39] «Erasure code — Ceph Documentation». [En línea]. Disponible en: http://docs.ceph.com/docs/mimic/rados/operations/erasure-code/. [Accedido: 19-jun- 2019]. BIBLIOGRAFÍA 71 [40] X. Zhang, S. Gaddam A. T., y Chronopoulos, «Ceph Distributed File System Benchmarks on an Openstack Cloud», IEEE International Conference on Cloud Computing in Emerging Markets, 2015. [41] «Benchmark Ceph Cluster Performance - Ceph - Ceph». [En línea]. Disponible en: https://tracker.ceph.com/projects/ceph/wiki/Benchmark_Ceph_Cluster_Performance. [Accedido: 19-jun-2019]. [42] «dd(1) - Linux manual page». [En línea]. Disponible en: http://man7.org/linux/man- pages/man1/dd.1.html. [Accedido: 19-jun-2019]. [43] «bonnie++ - program to test hard drive performance. - Linux Man Pages (8)». [En línea]. Disponible en: //www.systutorials.com/docs/linux/man/docs/linux/man/8- bonnie++/. [Accedido: 19-jun-2019].

ANEXOS 72

ANEXOS

Anexo I: Códigos de chequeo de salud del clúster Ceph más comunes Código Descripción Un módulo del Ceph Manager ha experimentado un error inesperado. Típicamente, esto significa que se ha lanzado una MGR_MODULE_ERROR excepción no manejable en las funciones del módulo. Esta advertencia se puede solucionar de forma sencilla reiniciando el Ceph Manager que reportó la excepción. Uno o más OSDs han sido marcados como inactivo (down). El servicio ceph-osd puede haberse detenido o el proceso de OSD_DOWN consulta al OSD no se ha podido realizar a través de la red. Las causas comunes son la caída del servicio, la caída de un servidor o un corte en la red. Uno o más OSDs han excedido el umbral de disco lleno y se ha prevenido el clúster de los procesos de lectura. La solución radica OSD_FULL en agregar más almacenamiento el clúster o eliminar datos para liberar espacio. Uno o más OSDs han excedido el umbral establecido para disco OSD_NEARFULL cerca del llenado. Esto es una advertencia temprana de que el clúster está cerca del umbral de lleno. Uno o más OSDs tienen una bandera de interés establecida. Estas banderas incluyen:  noup: el OSD no tiene permitido iniciar.  nodown: los reportes de fallo de este OSD serán ignorados. OSD_FLAGS  noin: si este OSD fue previamente marcado como out automáticamente después de un fallo, no será marcado como in cuando este inicie nuevamente.  noout: si este OSD está inactivo no será marcado automáticamente como fuera del clúster (out). Una o más pools han excedido su cuota y no se permitirán los POOL_FULL procesos de escritura en ella. La disponibilidad de los datos está reducida, significando que el clúster es incapaz de servir potenciales requerimientos de lectura PG_AVAILABILITY o escritura para algunos datos en el clúster. Especialmente, uno o más grupos de ubicación (PGs) están en un estado en el que no permiten pedidos de lectura/escritura. La redundancia de datos está reducida para algunos datos, significando que el clúster no tiene el número indicado de réplicas PG_DEGRADED para todos los datos (para pools replicadas) o fragmentos de código de borrado (para pools con códigos de borrado). La depuración de datos ha descubierto algún problema en la PG_DAMAGED consistencia de los datos. ANEXOS 73

En la depuración reciente de un OSD se ha encontrado OSD_SCRUB_ERRORS inconsistencias irrecuperables. Este error generalmente aparece junto a PG_DAMAGED El número de grupos de ubicación en uso en el clúster está por debajo del umbral configurable de mon_pg_warn_min_per_osd TOO_FEW_PGS PGs por OSD. Esto puede acarrear una distribución y rebalanceo no óptima de los OSD en el clúster, lo que disminuirá su rendimiento. El número de grupos de ubicación en uso en el clúster está por encima del umbral configurable de mon_max_pg_per_osd PGs TOO_MANY_PGS por OSD. Si este umbral es excedido el clúster no permitirá la creación de nuevas pools, el aumento de los grupos de ubicación de una pool o el aumento en el factor de replicación de una pool.

Anexo II: Estados de los grupos de ubicación (PG) más comunes Estado Descripción Cuando se crea una pool, se creará el número de grupos de ubicación que se especificaron para esta. Ceph mostrará “creating” cuando esté CREATING creando uno o más grupos de ubicación. Una vez estén creado comenzará el proceso de emparejamiento. Cuando Ceph está emparejando un grupo de ubicación, está trayendo a los OSDs que almacenan las réplicas del grupo de ubicación a un “acuerdo acerca del estado” de los objetos y sus metadatos en el grupo PEERING de ubicación. Cuando Ceph completa el emparejamiento, significa que los OSDs que almacenan el grupo de ubicación están de acuerdo acerca del estado del grupo de ubicación. Una vez que Ceph complete el proceso de emparejamiento, un grupo de ubicación deberá marcarse como active. Esto significa que los datos ACTIVE en el grupo de ubicación están disponibles en el grupo de ubicación principal y sus réplicas para operaciones de lectura/escritura. Cuando un grupo de ubicación está en el estado clean, el OSD primario y los OSDs réplicas se han emparejado exitosamente y no CLEAN hay réplicas extraviadas. Ceph replicó todos los objetos del grupo de ubicación el número correcto de veces. Cuando un cliente escribe un objeto al OSD primario, el OSD primario es responsable de escribir las réplicas en los OSDs de réplica. Después de que el OSD primario escribe el objeto en el almacenamiento, el DEGRADED grupo de ubicación permanecerá en el estado degraded hasta que el OSD primario reciba el acuse de recibo desde los OSDs réplicas indicando que los objetos réplica fueron creados con éxito. Cuando un OSD pasa a estar inactivo, su contenido quedará atrasado con respecto a las demás réplicas in los grupos de ubicación. Cuando RECOVERING el OSD vuelve a unirse a clúster, el contenido de los grupos de ubicación que almacena debe ser actualizado para reflejar el estado actual. Durante ese período el OSD reflejará el estado recovering. ANEXOS 74

Cuando un nuevo OSD se une al clúster, CRUSH reasignará grupos de ubicación desde otros OSDs del clúster hacia el nuevo OSD. Forzando al OSD a aceptar los grupos de ubicación reasignados BACKFILLING inmediatamente puede acarrear una carga excesiva para el nuevo OSD. El proceso de relleno de fondo del OSD permite que este proceso se ejecute en segundo plano. Cuando este proceso ha culminado, el nuevo OSD puede comenzar a servir pedidos. Cuando el conjunto de actuación que almacena un grupo de ubicación cambia, los datos migran desde el viejo conjunto de actuación hacia el nuevo- Esto puede tomar mucho tiempo para que un nuevo OSD REMAPED primario pueda servir pedidos. Entonces, preguntará el viejo OSD primario para continuar sirviendo los pedidos hasta que la migración del grupo de ubicación haya terminado. Mientras Ceph usa reportes de estado para asegurar que los servidores y los servicios están corriendo, los servicios ceph-osd pueden también entrar en un estado de “atascado” cuando no reportan estadísticas en STALE el tiempo apropiado. Si el OSD primario de un gruo de ubicación en un conjunto de actuación falla en reportar su estado al Ceph Monitor o si otro OSD ha reportado al OSD primario como inactivo, el Ceph Monitor marcará el grupo de ubicación como stale. Ceph detectó una inconsistencia en una o más réplicas de un objeto en INCONSISTENT el grupo de ubicación. Esto puede deberse a objetos con tamaño incorrecto, objetos perdidos después de una recuperación, etc. Ceph detectó que un grupo de ubicación ha perdido información INCOMPLETE acerca de escrituras que pueden haber ocurrido o no tienen una copia saludable. El grupo de ubicación tiene menos copias que las configuradas en el UNDERSIZED nivel de replicación.

ANEXOS 75

Anexo III: Ejemplo de configuración para enrutar dos subredes en Lustre

Anexo IV: Estado del clúster Ceph unos segundos después de apagar el servidor ceph1

ANEXOS 76

Anexo V: Estado del clúster Ceph en el proceso de recuperación luego de apagar el servidor ceph1 (parte I)

Anexo VI: Estado del clúster Ceph en el proceso de recuperación luego de apagar el servidor ceph1 (parte II)

ANEXOS 77

Anexo VII: Estado del clúster Ceph en el proceso de recuperación luego de reincorporarse el servidor ceph1