sistemas de archivos distribuido para clúster hpc
TRANSCRIPT
, Junio, 2019
Departamento de Telecomunicaciones y Electrónica
Título: Sistemas de archivos distribuido para Clúster HPC
utilizando Ceph
Autor: Daniel Placencia Alvarez
Tutor: Ing. Javier Antonio Ruiz Bosch
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 Lustre ................................................................................................. 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
1
INTRODUCCION
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.
2
INTRODUCCION
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
3
INTRODUCCION
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.
4
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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.
5
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
6
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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, EXT2, EXT3, FAT (sistema de
7
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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, Reiser4, 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 file system), fue
el primer sistema de archivos creado específicamente para el sistema operativo Linux. Sus
versiones más relevantes son ext2, ext3 y ext4. 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
8
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
red. Entre ellos podemos mencionar swap, sysfs, wikifs, udev, ftpfs, 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
9
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
"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:
10
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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 Server
Message Block (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.
11
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
12
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
13
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
14
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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:
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
Flujos de acceso
15
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
16
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
17
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
18
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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:
19
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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, xfs o zfs.
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-
20
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
21
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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.
22
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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.
23
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
24
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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 Object Storage 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
25
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
26
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
27
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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
28
CAPÍTULO 1. SISTEMAS DE ARCHIVOS
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.
29
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
30
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
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
Monitors Managers OSDs MDSs
31
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
32
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
33
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
Figura 2.3 Proceso de rebalanceo en 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.
ceph-admin ceph1 ceph2
Subred del clúster
Red de acceso switch
switch
Figura 2.4 Arquitectura de red del Clúster Ceph
34
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
35
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
de red
Discos
duros
Nombre
asignado
Servicios*
Dell
Power
Edge
R410
Intel(R)
Xeon(R) X5660
8GB 2 x 1GB/s 1 x
500GB -
SO
ceph-
admin
OSD
MON
36
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
(12 núcleos a
2.80 GHz cada
uno, 32-64 bit)
3 x 500
GB -
OSD
Dell
Power
Edge
R410
Intel(R)
Xeon(R) X5660
(24 núcleos a
2.80 GHz cada
uno, 32-64 bit)
8GB 2 x 1GB/s 1 x
500GB -
SO
3 x 500
GB -
OSD
ceph1 OSD
MON
MGR
MDS
Dell
Power
Edge
R410
Intel(R)
Xeon(R) X5660
(24 núcleos a
2.80 GHz cada
uno, 32-64 bit)
16GB 2 x 1GB/s 1 x
500GB -
SO
3 x 500
GB -
OSD
ceph2 OSD
MON
MGR
MDS
* 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
37
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
38
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
39
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
40
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
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
[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
41
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
42
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
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:
Figura 2.7 Claves de seguridad del clúster Ceph
43
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
$ 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
44
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
45
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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:
46
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
$ 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
47
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
48
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
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"
49
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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).
50
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
51
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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
52
CAPÍTULO 2. IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH EN EL CLÚSTER HPC
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.
53
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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.
54
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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
55
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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
56
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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ó
57
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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
58
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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.
59
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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.
60
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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
61
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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á
62
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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
Para 16
archivos
Creación secuencial Creación aleatoria
Creación Lectura Borrado Creación Lectura Borrado
/seg %
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
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
archivos
Creación secuencial Creación aleatoria
Creación Lectura Borrado Creación Lectura Borrado
63
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
/seg %
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
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
Para 16
archivos
Creación secuencial Creación aleatoria
Creación Lectura Borrado Creación Lectura Borrado
/seg %
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
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
64
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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
65
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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
Para 16
archivos
Creación secuencial Creación aleatoria
Creación Lectura Borrado Creación Lectura Borrado
/seg %
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
CPU /seg
%
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
66
CAPÍTULO 3. RESULTADOS DE LA IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS CEPH
EN EL CLÚSTER HPC
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.
67 CONCLUSIONES Y RECOMENDACIONES
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.
68 CONCLUSIONES Y RECOMENDACIONES
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.
69 BIBLIOGRAFÍA
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 Network File System 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] «Extended file system», 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.
70 BIBLIOGRAFÍA
[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].
71 BIBLIOGRAFÍA
[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].
72 ANEXOS
ANEXOS
Anexo I: Códigos de chequeo de salud del clúster Ceph más comunes
Código Descripción
MGR_MODULE_ERROR
Un módulo del Ceph Manager ha experimentado un error
inesperado. Típicamente, esto significa que se ha lanzado una
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.
OSD_DOWN
Uno o más OSDs han sido marcados como inactivo (down). El
servicio ceph-osd puede haberse detenido o el proceso de
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.
OSD_FULL
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
en agregar más almacenamiento el clúster o eliminar datos para
liberar espacio.
OSD_NEARFULL Uno o más OSDs han excedido el umbral establecido para disco
cerca del llenado. Esto es una advertencia temprana de que el
clúster está cerca del umbral de lleno.
OSD_FLAGS
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.
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).
POOL_FULL Una o más pools han excedido su cuota y no se permitirán los
procesos de escritura en ella.
PG_AVAILABILITY
La disponibilidad de los datos está reducida, significando que el
clúster es incapaz de servir potenciales requerimientos de lectura
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.
PG_DEGRADED
La redundancia de datos está reducida para algunos datos,
significando que el clúster no tiene el número indicado de réplicas
para todos los datos (para pools replicadas) o fragmentos de
código de borrado (para pools con códigos de borrado).
PG_DAMAGED La depuración de datos ha descubierto algún problema en la
consistencia de los datos.
73 ANEXOS
OSD_SCRUB_ERRORS
En la depuración reciente de un OSD se ha encontrado
inconsistencias irrecuperables. Este error generalmente aparece
junto a PG_DAMAGED
TOO_FEW_PGS
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
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.
TOO_MANY_PGS
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
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
CREATING
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é
creando uno o más grupos de ubicación. Una vez estén creado
comenzará el proceso de emparejamiento.
PEERING
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
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.
ACTIVE
Una vez que Ceph complete el proceso de emparejamiento, un grupo
de ubicación deberá marcarse como active. Esto significa que los datos
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.
CLEAN
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
hay réplicas extraviadas. Ceph replicó todos los objetos del grupo de
ubicación el número correcto de veces.
DEGRADED
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
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.
RECOVERING
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
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.
74 ANEXOS
BACKFILLING
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
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.
REMAPED
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
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.
STALE
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
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.
INCONSISTENT
Ceph detectó una inconsistencia en una o más réplicas de un objeto en
el grupo de ubicación. Esto puede deberse a objetos con tamaño
incorrecto, objetos perdidos después de una recuperación, etc.
INCOMPLETE
Ceph detectó que un grupo de ubicación ha perdido información
acerca de escrituras que pueden haber ocurrido o no tienen una copia
saludable.
UNDERSIZED El grupo de ubicación tiene menos copias que las configuradas en el
nivel de replicación.
75 ANEXOS
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
76 ANEXOS
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)
77 ANEXOS
Anexo VII: Estado del clúster Ceph en el proceso de recuperación luego de
reincorporarse el servidor ceph1