Universidad Central “Marta Abreu” de Las Villas

Facultad de Ingeniería Eléctrica

Departamento de Automática y Sistemas Computacionales

TRABAJO DE DIPLOMA

Soluciones de almacenamiento para los servicios informáticos de la red UCLV

Autor: Arístides Gutiérrez Molinet

Tutor: Manuel Oliver Domínguez

Santa Clara

2016

"Año 58 de la Revolución"

Universidad Central “Marta Abreu” de Las Villas

Facultad de Ingeniería Eléctrica

Departamento de Automática y Sistemas Computacionales

TRABAJO DE DIPLOMA

Soluciones de almacenamiento para los servicios informáticos de la red UCLV

Autor: Arístides Gutiérrez Molinet Email: [email protected]

Tutor: Manuel Oliver Domínguez Email: [email protected]

Santa Clara

2016

"Año 58 de la Revolución"

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 Automática, 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 Autor Firma del Jefe de Departamento donde se defiende el trabajo

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

i

PENSAMIENTO

Todo lo que enaltece y honra implica sacrificios.

Ernesto Che Guevara de la Serna.

ii

DEDICATORIA

En especial a mis bisabuelos (Felipe y Candita) y abuelos (Pápa y Máma), por haber criado y empinado por caminos pedregosos a su nieto que los ama con todas las fuerzas donde quiera que estén.

iii

AGRADECIMIENTOS

A mi familia, especialmente a mis bisabuelos, a Pápa y Máma, a La Hormiga y Agabama por ser mi paraíso que me crió, a mi abuela Isabel por criarme y salvarme la vida con leche materna de una mulata, a mi madre y mi padre por ser una luz que me guía en el horizonte, a mis hermanas Yeni y Arlet, a mi tíos Hernán y Arelis que siempre aportaron su granito de arena, a Mími “la mujer de mis sueños”.

A los profesores del Departamento de Automática, los que están y ya no están, por ser las principales fuentes del conocimiento adquirido durante estos cinco años y poner en alto el orgullo de la carrera de Ingeniería en Automática y Sistemas Computacionales.

A Arletis M. (Tina) una buena amiga en el tiempo que estuvo a mi lado.

A Rocío G. una inigualable compañera que siempre quise.

A Gina RD. un amor incondicional.

A Rosita (AFRODITA) por su incomparable ayuda, amistad y por el pacto de familiaridad.

A la señorita Ashly con su corazón infinito que no hay cosa alguna que no quepa en él y añoro que nunca se valla de mí lado.

A Ernesto (Ernest the Masther) por su ayuda de buen compañero.

A Google por ser el mejor buscador en Internet.

A Reiniel (Sr_Lord_Black_Snow), a los técnicos de lab. PAIN_DENDI, de tele Yaniel, a Rodolfo (Rex), a DRACULA por acogerme en su local y prestarme su ayuda humanitaria en la elaboración de la tesis.

A Manuel Oliver por aceptarme como tesiante y lograr esta meta.

iv

A mis excompañeros de aula del curso (2014-2015) y (2015-2016) por compartir con ellos esta travesía.

A Blizzard por acogerme sin importar el momento.

Al mejor profesor de matemática del IPVC de Santa Clara cuando estaba en período de prueba de ingreso.

A mi tía Anita, a mis primos Randi y Adriano, A Marco e Iris y al señor Amado por su preocupación.

A los viciosos del Chat UCLV y doteros que siempre se preguntaban cómo estudiaba una de las mejores y difíciles carreras de la universidad.

A todos los que me prestaron sus cuentas de la universidad para la elaboración de la tesis.

A mi profesor de la primaria Reídel por impregnarme al hábito de estudio en especial las matemáticas, aunque a veces recurría a los reglazos.

A Sergito, A Malagamba, A Mazuela, a todos aquellos que confiaron en mí en el período del servicio militar, que yo podía aprobar las pruebas de ingreso a la universidad.

A mis vecinos del barrio por todo su apoyo.

A Reik por su canción “Creo en ti”.

Al decano Juan Pablo Barrios por toda su ayuda.

A mis profesores de la Secundaria y del Preuniversitario por inculcarme el deseo de estudiar.

A Mamerto que siempre me recordaba cobrar el estipendio de la UCLV.

A todos aquellos que de una forma u otra aportaron a la causa.

A God que de seguro aporto su gran contribución.

A la universidad Central de las Villas como a muchos les gusta decir UCLV, por ser la mejor escuela que he tenido en la vida en todos los aspectos.

v

RESUMEN

La cantidad de información almacenada ha tenido un incremento vertiginoso en el mundo en los últimos años. Entre los principales métodos para el almacenamiento de datos por hardware que suelen usarse en servidores están los arreglos de discos o niveles RAID permitiendo que aunque un disco falle mecánicamente los datos del conjunto sigan siendo accesibles para los usuarios. También se dispone de arquitecturas más complejas como son DAS, NAS, SAN y la híbrida SAN-NAS, las cuales producen beneficios como interconectividad, escalabilidad, alta disponibilidad, alto rendimiento, tamaño infinito, puede tener ubicación dispersa, administración e información centralizada, con una alta seguridad y fiabilidad.

Por otra parte las soluciones basadas en software son mucho más flexibles, permitiendo construir espacios de almacenamiento en discos de diferentes tamaños o incluso particiones y compartirlos con usuarios remotos.

Se debe hacer mención especial al protocolo NFS, al sistema de archivos de alta disponibilidad y escalabilidad GlusterFS, la plataforma abierta de almacenamiento unificada y distribuida Ceph.

En este trabajo se analiza la Red UCLV buscando los principales servicios, sus necesidades de almacenamiento y como encajan las tecnologías antes mencionadas. Se analiza si las soluciones actuales son las mejores, y en caso de no serlo se aconseja una mejor, con el objetivo de optimizar el rendimiento, seguridad y escalabilidad de los servicios.

vi

ÍNDICE

PENSAMIENTO ...... i

AGRADECIMIENTOS ...... iii

RESUMEN ...... v

INTRODUCCIÓN ...... 1

Capítulo 1: Almacenamiento a nivel físico ...... 4

1.1 Introducción...... 4

1.1.1 Objetos almacenables...... 5

1.1.2 Big Data...... 6

1.1.3 Información...... 6

1.2 Medios de almacenamientos tradicionales...... 7

1.3 Arquitecturas de almacenamiento ...... 8

1.4 Sistemas de almacenamiento inteligente...... 8

1.4.1 Niveles RAID estándar...... 10

1.5 Red de Almacenamiento Local...... 14

1.5.1 DAS (Direct-Attached-Storage)...... 15

1.5.2 NAS (Network Attached Storage)...... 15

1.5.3 SAN (Storage Area Network)...... 17

1.5.4 Beneficios y ventajas de las redes de almacenamiento SAN...... 18

1.5.5 Breve comparativa SAN, DAS y NAS...... 19

1.1.6 Híbrido SAN-NAS...... 21

1.6 Tecnologías...... 22

1.6.1 Infiniband...... 22

vii

1.7 Consideraciones finales del Capítulo...... 26

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO ...... 27

2.1 NFS...... 27

2.1.1 Características principales...... 29

2.1.2 Versiones de NFS ...... 30

2.2 GlusterFS...... 31

2.2.1 Distribución y Replicación de la Data...... 33

2.3 Ceph...... 37

2.3.1 Surgimiento de Ceph...... 37

2.3.2 Arquitectura de Ceph...... 38

2.4 Consideraciones finales del Capítulo...... 40

CAPÍTULO 3. Almacenamiento en la Red UCLV...... 42

3.1 Historia de la Red UCLV...... 42

3.2 Servicios más importantes en la Red UCLV y sus requerimientos...... 44

3.2.1 Cuentas de usuario ...... 45

3.2.2 Correo Electrónico...... 46

3.2.3 Navegación por Internet...... 47

3.2.4 Almacenamiento de programas y recursos compartidos...... 49

3.2.5 Almacenamiento de la información de usuarios...... 50

3.2.6 Clúster de cálculo...... 50

3.2.7 Bases de datos ...... 51

3.3 Análisis económico...... 52

3.4 Conclusiones del Capítulo...... 53

CONCLUSIONES Y RECOMENDACIONES ...... 54

viii

Conclusiones ...... 54

Recomendaciones ...... 55

REFERENCIAS BIBLIOGRÁFICAS ...... 58

ANEXOS ...... 63

INTRODUCCIÓN 1

INTRODUCCIÓN

En sus comienzos la red UCLV presentaba condiciones muy precarias, solo 3 PCs se utilizaban como servidores en el año 2000. Después de un despliegue de Fibra óptica hasta los nodos del campus principal, la red creció de forma acelerada, contando con equipamiento de clase profesional, recibidos de 4 proyectos internacionales enfocados en el mejoramiento de la red en el período 2004 al 2014.

Las necesidades de almacenamiento fueron creciendo con el paso de los años al surgir servicios básicos como: cuentas de usuario, correo interno y externo, proxy, navegación por internet y servicios de almacenamiento como: programas, recursos compartidos, información de usuarios, resultados de clúster de cálculo, entre otros.

En este trabajo se abordan varias tecnologías que solucionan el problema anteriormente dicho.

Normalmente, cuando una compañía estima el TCO (Coste total de propiedad) con respecto al coste por byte, el coste se puede justificar con más facilidad. El bloqueo impuesto por Estado Unidos, prohíbe vender estas tecnologías de punta a Cuba y tener soluciones propietarias, lo que dificulta grandemente el desarrollo de los avances tecnológicos en la UCLV y en el país.

El problema científico se enfoca entonces en: ¿Dispone la Red UCLV de las mejores soluciones de almacenamiento para sus servicios más usados que le brinden el mejor rendimiento, seguridad y escalabilidad?

Como hipótesis se plantea que, mediante la implementación de combinaciones de soluciones de almacenamiento por hardware y software actuales se puede mejorar el

INTRODUCCIÓN 2 rendimiento, la seguridad y sobre todo la escalabilidad de varios servicios ofrecidos por la Red UCLV de forma transparente y económicamente viable.

Por tanto, el objetivo general propuesto para este trabajo es:

 Realizar un estudio de las soluciones por hardware y software disponibles para el almacenamiento de datos con vista a proponer soluciones que mejoren el rendimiento, seguridad y escalabilidad de los servicios principales en la Red UCLV.

Teniendo como objetivos específicos:

 Estudiar en la bibliografía especializada los diferentes tipos de soluciones hardware y software disponibles para almacenamiento de información.

 Identificar los servicios en la Red UCLV con mayores requerimientos de almacenamiento en cuanto a seguridad, estabilidad y escalabilidad.

 Proponer el modelo de hardware y software más adecuado a las necesidades de cada servicio de los identificados en la Red UCLV de forma que queden cubiertas sus capacidades.

 Evaluar el desempeño de la configuración elegida.

Organización del informe:

El informe está dividido en: introducción, tres capítulos, conclusiones, recomendaciones, referencias bibliográficas y anexos. Los capítulos están organizados de la siguiente manera:

Capítulo I: Se realiza el análisis de la literatura especializada consultada. Se presentan las principales metodologías que constituyen el eje de esta investigación, introduciendo los temas relacionados. Se plantea la panorámica general existente en torno al problema que se aborda y un estudio comparativo de las estrategias que se usan en la actualidad. Se hace énfasis en la descripción de las diferentes variantes de solución de la problemática de mejorar la velocidad de acceso y de garantizar la integridad de los datos almacenados por hardware como los RAID, los DAS, los NAS y los SAN.

Capítulo II: Es muy semejante al capítulo I pero se especializa en las soluciones basadas en software. Se incluyen los procedimientos para la instalación y la configuración básica de las soluciones propuestas.

INTRODUCCIÓN 3

Capítulo III: Se analiza la red de la Universidad Central “Marta Abreu” de Las Villas, se enumeran los servicios más importantes y se propone una de las soluciones de almacenamiento vistas para cada caso.

Se muestra como en algunos casos la solución propuesta coincide con la actual. En otros casos esto no ocurre por lo que se enumeran brevemente las ventajas en el cambio.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 4

Capítulo 1: Almacenamiento a nivel físico

1.1 Introducción.

Desde los años 60 los rápidos avances en las tecnologías de la información han llegado a muchos ámbitos. En casi todos los campos de trabajo e investigación modernos se comenzó a utilizar la informática para gestionar los grandes volúmenes de información que se generaban; después comenzó a crecer el número de documentos creados directamente en los ordenadores y que se almacenaban en el mismo formato electrónico en el que habían sido originados.

Los archivos han sufrido cambios en cuanto a sus funciones, ya que deben adaptarse para acoger a los nuevos documentos electrónicos. El CIA (Consejo Internacional de Archivos) determina que las funciones del archivo son identificar, salvaguardar y preservar los documentos y asegurar que van a ser accesibles y comprensibles. Las actividades que se incluyen en la función del archivo comienzan en la primera etapa del ciclo de vida de los documentos y terminan al final de dicho ciclo, y han de tener presente el objetivo principal del archivo, que es asegurar la creación y la preservación del valor probatorio de las actividades o transacciones realizadas por los creadores de los documentos.

Al tratarse de documentos electrónicos, la función del archivo va a ser sometida a ciertas modificaciones en cuanto a la creación de estos, su valoración y selección, preservación, acceso y uso.

No se puede decir todavía que se ha llegado a la “oficina sin papeles”, pero sí que cada vez son más los documentos que nacen y viven en las organizaciones sin pasar por el formato papel. [24]

La información crece en importancia diariamente en el transcurso de la vida cotidiana.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 5

Irremediablemente el ser humano se ha convertido en dependiente de la información en lo que ha transcurrido del siglo XXI, en un mundo sobre demanda, en el sentido de que se necesita la información donde y cuando sea requerida. Se accede a Internet diariamente en el desarrollo de búsquedas, participación en redes sociales, se envían y reciben correos electrónicos, se comparten fotos, videos y otro sinnúmero de aplicaciones.

Equipados con un número creciente de dispositivos generadores de contenido, más y más información es creada por individuos y por diferentes negocios y, dicha información, individualmente gana valor cuando se es compartida con otros. Cuando la información reside localmente en PCs, laptops, dispositivos móviles como, smartphones, cellphones, tablets, cámaras, etc.; para compartirla se debe usar un medio común fácilmente accesible que generalmente está localizado en centros de datos.

1.1.1 Objetos almacenables.

La importancia, dependencia y el volumen de información para el mundo de los negocios también continúa creciendo a pasos agigantados, estos dependen de lo rápido y confiable que puedan acceder a los datos críticos para el negocio, por ej., sistemas de facturación de las empresas, comercio electrónico, cajero automático, diseño de productos, administración de inventarios, portales Web, tarjetas de crédito y mercados capitales en general. Esta dependencia creciente de la información sobre los negocios ha multiplicado los retos en cuanto a almacenar, proteger y administrar los datos, es por esto que las redes de almacenamiento han cobrado inmenso valor durante la evolución de las tecnologías y desarrollo de nuevos negocios en la actualidad. [55]

Se pueden definir a los datos como una colección de bits en bruto de los cual se podrían extraer conclusiones.

Cartas escritas a mano, un libro impreso, una fotografía de la familia, una película en cinta de video, impresos y copias debidamente firmadas, libros de contabilidad de un banco, y libretas de un titular de la cuenta son ejemplos que contienen datos en el mundo analógico. Esta misma información digitalizada son los datos del mundo actual.

Todas las empresas que de alguna forma generan información digital deben de velar por garantizar que esta información persista en el tiempo y que su integridad no se vea afectada.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 6

Esto nos lleva al hecho de que muchas veces es tan importante no solo tener la información si no también garantizar que es la información auténtica y en caso de que no lo sea tener una forma de conseguir la información original. Con esto se quiere decir que básicamente por cada dato real almacenado existen más datos asociados que deben ser también almacenados por ejemplo en forma de sumas de integridad y de copias de seguridad.

En un sistema diseñado correctamente los recursos destinados al almacenamiento de los datos dependerán de las condiciones a las que se espera acceder a dichos datos.

1.1.2 Big Data.

En los últimos tiempos se ha comenzado a manejar el término Big Data para referirse no a un dato que sea grande sino a un gran grupo de datos.

Básicamente Big Data es un volumen enorme de datos de los que se desea extraer un resumen, orientación o tendencia que ayude a un negocio o a una aplicación a obtener mejores resultados.

Estos grupos de datos generalmente por su tamaño están más allá de las capacidades físicas de almacenar de cualquier dispositivos deben ser tratados de forma diferente al resto de los datos que usualmente se manejan.

Normalmente estos datos provienen de aplicaciones de procesamiento paralelo masivas, captura de comportamiento de usuarios o archivos logs de trazas del comportamiento de usuarios. [31]

1.1.3 Información.

El hecho de almacenar datos no significa que se tenga información.

Se puede definir la información como la inteligencia y/o conocimiento derivado de los datos. Los datos, bien sean estructurados o no, no reflejan ningún propósito a menos de que sean presentados de una manera que les dé sentido. Los negocios analizan fuentes de datos para identificar tendencias. Con base en estas tendencias, una compañía puede planear o modificar sus estrategias de negocio. [12]

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 7

En cuanto al almacenamiento es normal que se almacenen datos, se procesen y luego la información resultante sea también almacenada de forma que el acceso a ella sea mucho más rápido cada vez que los usuarios la necesiten.

Con los avances de los computadores y tecnologías de la comunicación, la tasa de crecimiento de la creación de datos se ha incrementado exponencialmente. Los siguientes son algunos de los factores que han provocado esta tendencia:

 Incremento en la capacidad de procesamiento de datos.

 Bajo costo de almacenamiento digital.

 Tecnologías de comunicación más rápidas y asequibles.

 Proliferación de aplicaciones y dispositivos inteligentes.

1.2 Medios de almacenamientos tradicionales.

Desde el inicio mismo de los equipos de cómputo, los medios de almacenamiento han ido evolucionando a la par. Es difícil decir si el incremento en la capacidad de procesamiento ha obligado a desarrollar los medios de almacenamiento o si ha sido al revés. En cualquier caso ambas tecnologías han avanzado a través del tiempo junto con otras como por ejemplo la conectividad, la adquisición de datos y la forma de las interfaces hombre máquina.

A continuación se muestra una lista de los medios de almacenamientos que han ido marcando un hito durante la historia de los medios computacionales:

 cintas de casete (660 KB por lado)

 disquetes magnéticos (hasta 1.2 MB)

 discos ópticos (700 MB)

 DVD

 discos duros con tecnología mecánica

 USB

 tarjetas SD

 unidades de estado Sólido

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 8

En los anexos I y III se pueden encontrar imágenes y algunos datos adicionales de estas tecnologías.

1.3 Arquitecturas de almacenamiento

Tradicionalmente el almacenamiento de cualquier tipo de información era típicamente interno al servidor o en periféricos conectados directamente a ella y no podía ser compartido con ningún otro servidor; esta arquitectura es conocida como “Server Centric Storage" (almacenamiento centrado en Servidores). En esta variante, los servidores son islas de cómputo y el almacenamiento presenta límites muy cortos en cuanto a capacidad de almacenamiento, haciendo no disponible la información a otros servidores/sistemas.

Para superar esto, la arquitectura de almacenamiento evolucionó de “Server Centric” a “Information Centric Storage" (almacenamiento centrado en la Información), en donde los dispositivos de almacenamiento son administrados centralmente e independiente de los servidores. Casi todas las variantes que se comentan en este trabajo están basadas en esta arquitectura. [12]

1.4 Sistemas de almacenamiento inteligente.

Las aplicaciones críticas de negocio requieren altos niveles de desempeño, disponibilidad, seguridad y escalabilidad en la información que se maneja. Algunas tecnologías de sistemas de almacenamiento antiguas no estaban en la capacidad de superar las restricciones de desempeño debido a las limitaciones del disco y sus componentes mecánicos. Un disco es un elemento central que gobierna el desempeño de cualquier sistema de almacenamiento y al ser su tecnología tradicionalmente en gran parte mecánica, el tiempo de vida está predefinido por la calidad de la manufactura en gran parte. El simple hecho del desgaste mecánico ya representa una variable clara del tiempo máximo de uso de un disco.

Para atenuar este problema se comenzó a usar grupos de discos en vez de discos individuales. Esto se conoce como arreglos de discos o RAID. [15]

Los arreglos de almacenamiento están equipados con capacidades grandes de memoria cache y múltiples caminos de I/O usando algoritmos sofisticados para cumplir con los

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 9 requerimientos de aplicaciones sensibles al desempeño. Estos sistemas proveen capacidades de procesamiento de I/O (entrada y salida) altamente optimizadas.

Dichos arreglos tienen un ambiente de operación que de forma inteligente y óptima, manejan la administración, asignación y utilización de los recursos.

Dependiendo de su configuración, los beneficios de un RAID respecto a un único disco son: mayor integridad, mayor tolerancia a fallos, mayor throughput (rendimiento) y mayor capacidad. Originalmente su ventaja clave consistía en la habilidad de combinar varios dispositivos de bajo coste y tecnologías más antiguas en un conjunto, ofreciendo mayor capacidad, fiabilidad, velocidad o una combinación de éstas que un solo dispositivo de última generación y de coste más alto.

En el nivel más simple, un RAID combina varios discos duros en una sola unidad lógica. Así, en lugar de ver varios discos duros diferentes, el sistema operativo ve uno solo. Los RAID suelen usarse en servidores y normalmente aunque no es necesario, se implementan con unidades de disco de la misma capacidad. Debido a la disminución del precio de los discos duros y la mayor disponibilidad de las opciones RAID incluidas en los chipsets de las placas base y se encuentran también como opción en las computadoras personales más avanzadas. Esto es especialmente frecuente en las computadoras dedicadas a tareas intensivas y que requiera asegurar la integridad de los datos en caso de fallo del sistema. Esta característica no está obviamente disponible en los sistemas RAID por software, que suelen presentar el problema de reconstruir el conjunto de discos, cuando el sistema es reiniciado tras un fallo para asegurar la integridad de los datos. Por el contrario, los sistemas basados en software son mucho más flexibles, permitiendo construir RAID de particiones en lugar de discos completos y agrupar en un mismo RAID, discos conectados en varias controladoras, así como los basados en hardware añade un punto de fallo más al sistema, la controladora RAID.

Todas las implementaciones pueden soportar el uso de uno o más discos de reserva (hot spare), unidades preinstaladas que pueden usarse inmediatamente, casi siempre automáticamente tras el fallo de un disco del RAID. Esto reduce la duración del período de reparación al acortar el tiempo de reconstrucción.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 10

1.4.1 Niveles RAID estándar.

Los niveles RAID más comúnmente usados son:

• RAID 0: Conjunto dividido.

• RAID 1: Conjunto en espejo.

• RAID 5: Conjunto dividido con paridad distribuida.

Existen otras definiciones usadas como el RAID 6 o RAID 1+0 o RAID10 pero son básicamente combinaciones de las 3 primeras.

RAID 0 (Data Striping): También llamado conjunto dividido o volumen dividido, distribuye los datos equitativamente entre dos o más discos sin información de paridad que proporciona redundancia. Es importante señalar que el RAID 0 no es redundante.

Figura 1-1: RAID 0.

Este se usa normalmente para incrementar el rendimiento, aunque también puede utilizarse como forma de crear un pequeño número de grandes discos virtuales a partir de un gran número de pequeños discos físicos. Puede ser creado con discos de diferentes tamaños, pero el espacio de almacenamiento añadido al conjunto, estará limitado por el tamaño del disco más pequeño. Una buena implementación, dividirá las operaciones de lectura y escritura en bloques de igual tamaño, por lo que distribuirá la información equitativamente entre los dos discos. También es posible crear un RAID 0 con más de dos discos, donde la fiabilidad del conjunto será igual a la fiabilidad media de cada disco entre el número de discos del conjunto; es decir, la fiabilidad total medida como MTTF o MTBF (tiempo

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 11 medio entre fallos) es aproximadamente inversamente proporcional al número de discos del conjunto, pues para que el conjunto falle es suficiente con que lo haga cualquiera de sus discos.

RAID 1: Crea una copia exacta o espejo de un conjunto de datos en dos o más discos. Esto resulta útil cuando el rendimiento en lectura es más importante que la capacidad. Un conjunto RAID 1 sólo puede ser tan grande como el más pequeño de sus discos. Una típica configuración clásica consiste en dos discos en espejo, lo que incrementa exponencialmente la fiabilidad respecto a un solo disco. La probabilidad de fallo del conjunto es igual al producto de las probabilidades de fallo de cada uno de los discos, pues para que el conjunto falle es necesario que lo hagan todos sus discos.

Figura 1-2: RAID 1.

Adicionalmente, dado que todos los datos están en dos o más discos, con hardware habitualmente independiente, el rendimiento de lectura se incrementa aproximadamente como múltiplo lineal del número de las copias; es decir, un RAID 1 puede estar leyendo simultáneamente dos datos diferentes en dos discos distintos, por lo que su rendimiento se duplica. Para maximizar los beneficios sobre el rendimiento, se recomienda el uso de controladores de discos independientes, una para cada disco, denominada splitting o duplexing.

Al escribir, el conjunto se comporta como un único disco, dado que los datos deben ser escritos en todos los discos. Por tanto, el rendimiento no mejora.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 12

Por otra parte, presenta muchas ventajas de administración. En algunos entornos 24/7, es posible dividir el espejo: marcar un disco como inactivo, hacer una copia de seguridad de dicho disco y luego reconstruir el espejo. Esto requiere que la aplicación de gestión del conjunto soporte la recuperación de los datos del disco en el momento de la división. Este procedimiento es menos crítico que la presencia de una característica de snapshot en algunos sistemas de archivos, en la que se reserva algún espacio para los cambios, presentando una vista estática en un punto temporal dado del sistema de archivos. Alternativamente, un conjunto de discos puede ser almacenado.

RAID 5: También llamado distribuido con paridad, es una división de datos a nivel de bloques que distribuye la información de paridad entre todos los discos miembros del conjunto. El RAID 5 ha logrado popularidad gracias a su bajo coste de redundancia. Generalmente, se implementa con soporte hardware para el cálculo de la paridad y necesita un mínimo de 3 discos para ser implementado.

Cada vez que se escribe un bloque de datos en esta configuración, se genera un bloque de paridad. Un bloque se compone a menudo de muchos sectores consecutivos de un disco. Una serie de bloques (un bloque de cada uno de los discos del conjunto) recibe el nombre colectivo de división (stripe). Si otro bloque, o alguna porción de un bloque, se escriben en esa misma división, el bloque de paridad (o una parte del mismo) es recalculado y vuelto a escribir. El disco utilizado por el bloque de paridad está escalonado de una división a la siguiente, de ahí el término bloques de paridad distribuidos.

Los bloques de paridad no se leen en las operaciones de lectura de datos, ya que esto sería una sobrecarga innecesaria y disminuiría el rendimiento. Sin embargo, los bloques de paridad se leen cuando la lectura de un sector de datos provoca un error de CRC. En este caso, el sector en la misma posición relativa, dentro de cada uno de los bloques de datos restantes y dentro del bloque de paridad en la división, se utiliza para reconstruir el sector erróneo. El error CRC se oculta así del resto del sistema. De la misma forma, si falla un disco del conjunto, los bloques de paridad de los restantes discos son combinados matemáticamente con los bloques de datos de los restantes discos para reconstruir los datos del que ha fallado. Las escrituras en un RAID 5 son costosas en términos de operaciones de disco y tráfico entre estos y la controladora.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 13

Figura 1-3: RAID 5.

Lo anterior se denomina “Modo Interino de Recuperación de Datos” (Interim Data Recovery Mode). El sistema sabe que un disco ha fallado, pero sólo con el fin de que el sistema operativo pueda notificar al administrador que una unidad necesita ser reemplazada: las aplicaciones en ejecución siguen funcionando ajenas al fallo. Las lecturas y escrituras continúan normalmente en el conjunto de discos, aunque con alguna degradación de rendimiento. En el “Modo Interno de Recuperación de Datos”, el RAID 5 puede ser ligeramente rápido, debido a que, cuando el CRC y la paridad están en el disco que falló, los cálculos no tienen que realizarse. El fallo de un segundo disco provoca la pérdida completa de los datos.

El número máximo de discos en un grupo de redundancia RAID 5 es teóricamente ilimitado, pero en la práctica es común limitar el número de unidades. Los inconvenientes de usar grupos de redundancia mayores son una mayor probabilidad de fallo simultáneo de dos discos, un mayor tiempo de reconstrucción y una mayor probabilidad de hallar un sector irrecuperable durante una reconstrucción. A medida que el número de discos en un conjunto crece, el MTBF (mean time between failures) puede ser más bajo que el de un único disco. Esto sucede cuando la probabilidad de que falle un segundo disco de un conjunto en el que ha fallado un disco en el tiempo necesario para detectar, reemplazar y recrear dicho disco es mayor que la probabilidad de fallo de un único disco.

Algunos vendedores RAID evitan montar discos de los mismos lotes en un grupo de redundancia para minimizar la probabilidad de fallos simultáneos al principio y al final de su vida útil.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 14

Las implementaciones RAID 5 presentan un mal rendimiento cuando se someten a cargas de trabajo que incluyen muchas escrituras más pequeñas que el tamaño de una división. Esto se debe a que la paridad debe ser actualizada para cada escritura, lo que exige realizar secuencias de lectura, modificación y escritura tanto para el bloque de datos como para el de paridad. Implementaciones más complejas incluyen a menudo caches de escritura no volátiles para reducir este problema de rendimiento.

En el caso de un fallo del sistema cuando hay escrituras activas, la paridad de una división puede quedar en un estado inconsistente con los datos. Si esto no se detecta y repara antes de que un disco o bloque falle, pueden perderse datos debido a que se usará una paridad incorrecta, para reconstruir el bloque perdido en dicha división. Esta potencial vulnerabilidad se conoce a veces como agujero de escritura. Son comunes el uso de caches no volátiles y otras técnicas para reducir la probabilidad de ocurrencia de esta vulnerabilidad.

La tecnología RAID hizo una importante contribución en mejorar el desempeño del almacenamiento y confiabilidad, pero los discos, aún con implementaciones de RAID no siempre pueden cumplir con los requerimientos de las aplicaciones actuales.

Con los avances tecnológicos, una nueva generación de soluciones de almacenamiento conocidas como sistemas de almacenamiento inteligentes ha evolucionado.

1.5 Red de Almacenamiento Local.

Aunque los sistemas basados en RAID significaron una mejora indiscutible con respecto a la situación que existía al comienzo de la era del surgimiento de los medios de cómputo con el paso del tiempo y sobre todo con el incremento en la cantidad de personas conectadas en redes y la velocidad de sus transferencias hicieron evidente deficiencias en estas soluciones.

La era de Internet necesitaba arquitecturas de almacenamiento más eficientes y escalables. Como aspecto interesante se puede decir que casi todas estas ideas surgieron durante el reinado de las mainframe pero no pudieron evolucionar debido al pobre desempeño de la electrónica en aquel momento.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 15

1.5.1 DAS (Direct-Attached-Storage).

Se trata de dispositivos de almacenamiento directamente conectados a las máquinas, como es el caso de discos duros internos, cabinas de disco (en rack o en cualquier otro formato) conectadas directamente a un servidor o unidades para backup.

Solían basarse en tecnologías SCSI (Small Computers System Interface), FC (Fiber Channel), e IDE. Esta arquitectura de almacenamiento, se relacionaban principalmente con la época de los mainframe de IBM, y los miniordenadores UNIX, pues aquellos años se dotaba a estas máquinas de sus propios medios locales de almacenamiento y backup. Sin embargo, hoy en día, los PCs de sobremesa utilizan arquitectura de almacenamiento DAS, mientras que en los servidores de las empresas, empiezan a caer en desuso, utilizándose únicamente para el almacenamiento del Sistema Operativo, en muchos casos ni eso, gracias a las soluciones Boot-on-SAN, permiten disponer de servidores sin discos locales, y que todo el almacenamiento, incluido boot, ficheros de paginación, etc, estén en la SAN, empleando almacenamiento SAN y NAS para el resto.

La arquitectura de almacenamiento DAS, presenta muchos inconvenientes, como es la dispersión del almacenamiento que implica una dificultad en la gestión de los backups, una relativa baja tolerancia a fallos, sólo posible a través de soluciones RAID, y un alto TCO (Total Cost of Ownship), debido a las dificultades de mantenimiento. [18]

1.5.2 NAS (Network Attached Storage).

Con la introducción de las redes locales (LAN), se empezaron a utilizar servidores de almacenamiento conectados a la LAN, a los cuales se podía acceder directamente a través de la propia red, mediante protocolos específicos como NFS (Network File System) en entornos UNIX y CIFS (Common Internet File System) en entornos de Microsoft (antes conocido como SMB, protocolo original de IBM que fue mejorado por Microsoft en CIFS), o incluso mediante FTP, HTTP, etc.

Antiguamente, se utilizaban los protocolos de Novell Netware que en ocasiones funcionabas sobre redes SPX, pero Novell Netware quedó en desuso, y actualmente las soluciones NAS se basan en TCP/IP.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 16

En consecuencia, actualmente un dispositivo NAS será una máquina dedicada con una o varias direcciones IP (sea un dispositivo NAS por hardware tipo almacén o un servidor Window/UNIX), además estará dotado de una conexión de alta velocidad a la red LAN. Por ello, una arquitectura de almacenamiento NAS puede estar formada por múltiples dispositivos NAS distribuidos geográficamente. En cualquier caso, se debe tener en cuenta que un servidor NAS utilizará almacenamiento DAS o SAN, almacenamiento interno o almacenamiento externo, además existen alternativas que integran soluciones NAS dentro de la propia infraestructura SAN.

Figura 1-4: Evolución de Compartición de Archivos

Así, los equipos clientes en una arquitectura de almacenamiento NAS, delegan la gestión del sistema de ficheros al propio dispositivo NAS. Se limitan a montar las unidades de red exportadas o compartidas por los dispositivos NAS, de modo tal que usuarios y aplicaciones utilizan estos sistemas de ficheros como si fueran sistemas de ficheros locales, aunque para el sistema operativo se trata claramente de sistemas de ficheros remotos.

El problema de esta arquitectura de almacenamiento, es que la red LAN puede actuar de cuello de botella. No obstante, siguen utilizándose masivamente las arquitecturas NAS, típicas “Carpetas Compartidas” o shared folder, que se utilizan en las empresas para el almacenamiento de ficheros, aunque no a todas las aplicaciones le resulte igual de útil, por ejemplo a los grandes servidores de base de datos, debido a esto preferirán almacenamiento SAN.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 17

Los principales beneficios de las Arquitecturas de Almacenamiento NAS, consisten en proporcionar un mejor TCO, resultando una arquitectura fácilmente escalable, capaz de ofrecer una alta disponibilidad.

A modo de resumen se puede decir que es posiblemente la mejor forma de ofrecer compartición e intercambio de ficheros en un entorno heterogéneo. [18]

1.5.3 SAN (Storage Area Network).

Es un tipo de almacenamiento en el cual el servidor o host es su dueño, por tanto es difícil su administración y compartir recursos en este dispositivo. Los esfuerzos en organizar estos datos dispersos llevaron a que emergiera el Storage Area Network, que en adelante se citará como SAN.

Esta arquitectura implica disponer de una infraestructura de red de alta velocidad dedicada sólo para almacenamiento y backup, optimizada para mover grandes cantidades de datos, consistente en múltiples recursos de almacenamiento geográficamente distribuidos y otros elementos (cables, switches de fibra FC, routers, adaptadores HBA (Host Bus Adapter) etc), completamente accesibles desde la red corporativa.

Figura 1-5: FC SAN

Las redes de almacenamiento SAN geográficamente distribuidas, han facilitado enormemente la creación de los centros de procesamiento de datos (CDP), centros de respaldo (BDC) y de clusters geográficos o GeoClusters.

La utilización de una arquitectura de almacenamiento SAN implica la existencia y mantenimiento de al menos dos redes: la red LAN y la red SAN. En la práctica, las redes de

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 18 almacenamiento SAN suelen basarse en la tecnología FC, aunque también pueden basarse en Gigabit Ethernet usando iSCSI.

Cuando se habla de redes conmutadas en FC, suele utilizarse el término Switch Fabric. En ambos casos, suele emplearse sobre redes conmutadas, utilizando múltiples switches y múltiples puertos, tanto en los clientes como en los servidores de almacenamiento, para ofrecer alta disponibilidad basada en la existencia de múltiples caminos, apoyándose para ello en soluciones y protocolos como MPIO (Multipath Input Output) y SecurePath (solución propietaria de HP). Además de la alta disponibilidad relativa a la redundancia de caminos, también se utilizan soluciones de alta disponibilidad del almacenamiento vistas anteriormente (RAID1, RAID5, RAID10, etc.).

Esa arquitectura, lleva experimentando un gran auge en los últimos años, tanto por los beneficios propios de la utilización de redes de almacenamiento SAN, como por la propia evolución de la tecnología, y la incorporación de soluciones de almacenamiento SAN basadas en iSCSI, que incluyen soluciones SAN iSCSI por software como Windows Storage Server 2008 y Microsoft iSCSI Target. [18]

1.5.4 Beneficios y ventajas de las redes de almacenamiento SAN.

Las primeras ventajas que saltan a la vista son: mayor velocidad de acceso a datos, menor tiempo de recuperación ante desastres, los tiempos de backup y restore se minimizan, y se añaden los clonados y snapshots, escalabilidad donde siempre es posible añadir más bandejas de discos, o incluso, más cabinas de discos y switches, y sobre todo, una gestión centralizada, compartida y concurrente del almacenamiento (indiferente de la plataforma y sistema operativo de los servidores).

Si se necesita un disco de 20GB para un Servidor o Host, no sería factible comprar 2 discos de 320GB y montar un RAID1; se puede crear una LUN (logical unit number) de 20GB, es por eso que hoy en día no existen discos de 20GB a la venta, de tal modo, que la centralización del almacenamiento nos va a permitir optimizar nuestros recursos, aunque no necesariamente minimiza los costes de la infraestructura SAN que son bastante altos, pero así, al menos se consiguen amortiguar. Además, existen otros efectos colaterales, por

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 19 ejemplo: la introducción de una infraestructura de almacenamiento SAN en una empresa, se liberará bastante tráfico de la red LAN.

Figura 1-6: Componentes de una NAS

Estas redes de almacenamiento también tienen sus inconvenientes, principalmente su coste, el precio por gigabyte resulta muy caro. También la existencia de ciertas limitaciones para integrar soluciones y/o dispositivos de diferentes fabricantes. Una de la principales alternativas para la reducción de costes de las mismas, es la utilización de soluciones de almacenamiento SAN basadas en iSCSI, que funcionan con tarjetas ethernet (no hacen falta HBA) y sobre los switches ethernet. Lo cierto es que con las actuales redes ethernet de 10Gbps, el cuello de botella se transfiere de la red al acceso a disco. [18]

1.5.5 Breve comparativa SAN, DAS y NAS.

La diferencia entre NAS y SAN, principalmente radica en que un servidor accede a un disco NAS a través de la red LAN, MAN o WAN, (ejemplo de esto es la carpeta o recurso compartido), siendo el sistema operativo consciente de que se está accediendo a un recurso, al disco o al sistema de ficheros remoto. Sin embargo, un servidor accede a un disco SAN como si fuera un disco local, es decir, un disco DAS, de forma transparente para el sistema operativo, siendo las tarjetas HBA y sus drivers quienes se preocupan de que dicho acceso a la SAN sea así de transparente.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 20

También se dice, que NAS se encuentra entre el servidor de aplicaciones y el sistema de ficheros, mientras que SAN se encuentra entre el sistema de ficheros y el almacenamiento físico. Una SAN se puede considerar una extensión de DAS. [18]

Figura 1-7: DAS vs NAS vs SAN.

Donde en DAS hay un enlace punto a punto entre el servidor y su almacenamiento, una SAN permite a varios servidores acceder a varios dispositivos de almacenamiento en una red compartida.

Tanto en SAN como en DAS, las aplicaciones y programas de usuarios hacen sus peticiones de datos al sistema de ficheros directamente. La diferencia reside en la manera en la que dicho sistema de ficheros obtiene los datos requeridos del almacenamiento.

En DAS, el almacenamiento es local al sistema de ficheros, mientras que en SAN, el almacenamiento es remoto.

SAN utiliza diferentes protocolos de acceso como FC y Gigabit Ethernet. En el lado opuesto se encuentra la tecnología NAS, donde las aplicaciones hacen las peticiones de datos a los sistemas de ficheros de manera remota mediante protocolos Server Message Block (CIFS) y Network File System (NFS).

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 21

Figura 1-8: Esquema.

1.1.6 Híbrido SAN-NAS.

Aunque la necesidad de almacenamiento es evidente, no siempre está claro cuál es la solución adecuada en una determinada organización.

Elegir la solución correcta puede ser una decisión con notables implicaciones, aunque no hay una respuesta correcta única, es necesario centrarse en las necesidades y objetivos finales específicos de cada usuario u organización.

Figura 1-9: Posibles configuraciones.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 22

Por ejemplo, en el caso concreto de las empresas, el tamaño de la compañía es un parámetro a tener en cuenta. Para grandes volúmenes de información, una solución SAN sería más acertada. En cambio, pequeñas compañías utilizan una solución NAS.

Sin embargo, ambas tecnologías no son excluyentes y pueden convivir en una misma solución.

Como se muestra en el gráfico, hay una serie de resultados posibles que implican la utilización de tecnologías DAS, NAS y SAN en una misma solución.

1.6 Tecnologías.

Anteriormente se ha hablado sobre algunas tecnologías como FC e iSCSI. Estos términos pueden ser estudiados más a profundidad usando la gran variedad de documentos que existen sobre ellos. En este epígrafe sin embargo se desea profundizar solo un poco más en la tecnología que es considerada actualmente la más rápida del mercado.

1.6.1 Infiniband.

Al igual que FC, PCI Express y otros modos de interconexión modernos, Infiniband usa un bus serie bidireccional de tal manera que evita los problemas típicos asociados a buses paralelos en largas distancias.

Figura 1-10: Infiniband

Es una marca comercial. Su tecnología es el resultado de la unión de dos diseños en competencia (el Future I/O, desarrollado por COMPAQ, IBM y Hewlett-Packard, y el Next

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 23

Generation I/O, desarrollado por Intel, Microsoft y Sun Microsystems). Infiniband era llamado anteriormente System I/O (Sistema de entrada/salida). Ambas compartían una buena parte de sus metas, y pronto se vio que no había mercado para las dos. Se decidió hacerlas converger en una única propuesta, de esta forma, en octubre del año 1999 se fundó Infiniband Trade Association (IBTA).

Las dos principales metas que en un principio se planteaba Infiniband, eran salvar las limitaciones que presentaban los buses PCI (cuellos de botella, fiabilidad, escalabilidad, etc.), y estandarizar las tecnologías en el terreno de los clusters (Servernet, Myricom, Giganet, etc.). Sin embargo, pretendía ir mucho más allá que una simple sustitución del típico bus PCI. Infiniband incorpora características que hasta ahora sólo podían encontrarse en supercomputadores grandes y costosos. Estas características son importantes para el montaje de clusters de altas prestaciones y permiten aprovechar las posibilidades de la tecnología actual.

Figura 1-11: Ejemplo de adaptadores de puerto Infiniband hacia bus PCI Express 2.0

Infiniband define una red de área para conectar ordenadores, sistemas y dispositivos de E/S, tanto para transacciones como para comunicación entre ordenadores, proporcionando la infraestructura adecuada para comunicación, gestión y una interconexión conmutada que permite a muchos dispositivos intercambiar datos de forma simultánea, con gran ancho de banda y baja latencia. Al ser un sistema conmutado, se pueden conseguir características como protección, fiabilidad, escalabilidad y seguridad, hasta ahora impensables en sistemas de E/S, e incluso en la mayoría de las redes habituales para conexión de computadores. [26]

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 24

Puede variar desde un pequeño servidor formado por un procesador y unos cuantos dispositivos de E/S conectados, hasta un supercomputador masivamente paralelo con miles de procesadores y dispositivos de E/S que están conectados vía Internet a otras plataformas de procesamiento y/o sistemas de E/S.

Es un bus de comunicaciones de alta velocidad, que usa una transmisión serie bidireccional que logra una velocidad bruta de unos 2,5 Gigabits por segundo (Gbps) en cada dirección por enlace, también soporta doble e incluso cuádruples tasas de transferencia de datos, llegando a ofrecer 5 y 10 Gbps respectivamente. Brinda anchos de banda ofrecidos por los modos simple, doble y cuádruple, estos son de 2, 4 y 8 Gbps respectivamente. Los enlaces pueden añadirse en grupos de 4 o 12, llamados 4X o 12X. Un enlace 12X a cuádruple ritmo tiene un caudal bruto entre 120 y 96 Gbps de caudal eficaz.

Tabla 1-1: Caudal de Infiniband, bruto / eficaz

Los datos se transmiten en paquetes de hasta 4 kB que se agrupan para formar mensajes. Hoy en día se usa en su mayor parte para clusters de alto rendimiento, aunque, ha habido esfuerzos para adaptar el estándar a conexiones entre máquinas de bajo coste para aplicaciones comerciales y técnicas más usuales. Del TOP500 de Supercomputadores la gran mayoría usa tecnología Infiniband para el almacenamiento. [48]

Este bus necesita un equipo de hardware especializado, donde cada punto final requiere de una tarjeta de E/S nombrada como adaptador de canal de host o HCA. Se conectan a conmutadores Infiniband con cables específicos que se han diseñado para transportar sus datos con gran precisión.

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 25

Tabla 1-2: Escalabilidad Infiniband vs Ethernet

Los sistemas de Supercomputación no escalan linealmente en función del número de servidores, por lo que en ciertas situaciones es más importante mejorar la red que aumentar el número de nodos en vistas a aumentar el rendimiento. Por lo antes expuesto, el uso de redes Infiniband es de vital importancia para la escalabilidad de cluster HPC.

Tabla 1-3: Infiniband vs Gigabit Ethernet.

En la actualidad Infiniband se ha impuesto como la red de baja latencia por excelencia. Utilizando equipamiento de 4ª generación Infiniband podemos conseguir una red más eficiente para cluster HPC, destacando por una latencia de 1,2us y un ancho de banda de 56Gbps con soporte para RDMA. En la tabla 1-3 y 1-4 se puede ver una comparación entre redes Infiniband y 10GE. [26]

CAPÍTULO 1. ALMACENAMIENTO A NIVEL FÍSICO 26

Tabla 1-4: Infiniband vs 10GigE

Con su gran ancho de banda, baja latencia y reducción de gastos generales, Infiniband es la elección ideal para acelerar el rendimiento de aplicaciones de forma simultánea, y al mismo tiempo consolidar la infraestructura de E/S de la red. La combinación de Infiniband y Ethernet en una única solución proporciona la columna vertebral, estante ideal para centros de datos de próxima generación.

1.7 Consideraciones finales del Capítulo.

Como se ha visto en este capítulo el desarrollo de la informática y de la computación es un proceso que produce datos continuamente. Esta producción de datos se ha incrementado y lo continuará haciendo ya que casi todas las áreas en nuestra vida diaria son productoras de información digital.

De igual forma todos los datos que se producen deben ser almacenados. Algunos de hecho se almacenan más de una vez porque dada su importancia no es tolerable su pérdida.

Con el objetivo de mejorar la velocidad de acceso y de garantizar la integridad de los datos almacenados se han creado soluciones por hardware como los RAID, los DAS, los NAS y los SAN.

Todas estas soluciones garantizan que la información no se pierda pero usualmente tienen un costo alto y al ser equipos como tal su período de actualización es más bien corto. Este no es un problema nuevo en el mundo de la informática y como en otros casos la solución es crear aplicaciones de software que paleen las deficiencias o la imposibilidad de adquirir soluciones de hardware.

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 27

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO

Usualmente en el mundo de la computación y la informática la solución de un problema tiene siempre dos soluciones clásicas. La primera es conocida como solución dura y es en su mayoría hardware y la segunda es una solución blanda y casi siempre es un programa o un servicio.

En el caso del almacenamiento esto también es aplicable.

En el capítulo anterior se describieron las soluciones duras, o sea las que están basadas en hardware. En este capítulo se pretende dar un bosquejo sobre los servicios informáticos que ayudan en el área del almacenamiento.

Las soluciones por software se aplican generalmente cuando no se dispone de los recursos necesarios para implementar una solución por hardware o cuando por motivos muy específicos hace falta un protocolo dado. De hecho es muy común que las soluciones por hardware traigan incluidos algunos de los protocolos que se tratan en este capítulo.

Lo más común es encontrar en el mundo real soluciones híbridas.

2.1 NFS.

En un entorno informático se hace imprescindible disponer de un servicio que permita el acceso seguro a archivos remotos de forma transparente. Tanto el administrador como los usuarios, en determinadas circunstancias, necesitan disponer de esta facilidad de intercambio de información que garantice la seguridad y confidencialidad de la misma. [16]

Esta forma de trabajar es válida para entornos Unix/Linux. De momento NFS no permite la interoperabilidad con determinados sistemas de archivos Windows. Para poder trabajar con

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 28

ciertos sistemas de archivos de red en plataformas mixtas Windows/Linux se ha de utilizar el antiguo protocolo SMB, hoy llamado CIFS; cuando se involucran sistemas Windows, debe utilizar Samba en su lugar.

En la actualidad las versiones de la distribución Ubuntu y otros “sabores” de Linux soportan la conexión con equipos Windows directamente utilizando el protocolo SMB.

Dicho esto se puede pasar a detallar mejor el protocolo NFS.

Las siglas NFS significan “Sistema de Archivos de Red” (del inglés Network File System), es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a archivos remotos como si se tratara de locales y fue desarrollado por SUN Microsystems en 1984, está incluido por defecto en los Sistemas Operativos UNIX aplicándose luego a las distribuciones GNU/Linux.

En este sentido NFS no es realmente un sistema de archivos físico, sino que constituye una capa de abstracción que, aplicada sobre cualquier sistema de archivos físico, permite su utilización de forma remota por otras computadoras/usuarios. NFS proporciona este servicio siguiendo la estructura cliente-servidor. El servidor NFS comparte una serie de directorios seleccionados con unas condiciones de seguridad concretas. El cliente NFS, si está autorizado para ello, puede 'montar' dichos directorios en su propio sistema de archivos pudiendo acceder a los archivos como si fueran locales. El montaje lo puede realizar en secuencia de arranque de la computadora o cuando lo necesite.

El servicio NFS utiliza las llamadas a procedimientos remotos basadas en el protocolo RPC (Remote Procedure Call) que permite desde una computadora (cliente) ejecutar código ubicado en otra computadora remota (servidor) mediante el establecimiento de sockets (IP + puerto) entre ambas.

Aunque al servicio se le suele conocer con el nombre NFS, realmente NFS es un protocolo de nivel de Aplicación y por debajo, el protocolo subyacente que utiliza NFS son las Llamadas a Procedimientos Remotos (RPC) de nivel de Sesión, también utiliza TCP/UDP en el nivel Transporte e IP en el nivel de Red.

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 29

El protocolo de NFS está diseñado para ser independiente de la máquina, del sistema operativo y del protocolo de transporte. Esto es posible porque se implementa sobre RPC.

NFS es un protocolo sin memoria (state-less) en algunas de sus versiones. Es decir, el servidor no recuerda las solicitudes anteriores. Por tanto, cada llamada a un procedimiento contiene toda la información necesaria para su finalización. Si el servidor NFS falla, el sistema cliente repetirá las solicitudes de NFS hasta que obtenga una respuesta. Además, el servidor no realiza tareas de recuperación frente a fallos. [16]

Bajo NFS no existe el concepto de cliente o servidor puro. Un servidor puede exportar un sistema de archivos y puede montar un sistema de archivos distinto a la vez:

Figura 2-1: Clientes y Servidores NFS

2.1.1 Características principales.

El sistema NFS está dividido al menos en dos partes principales: un servidor y uno o más clientes. Los clientes acceden de forma remota a los datos que se encuentran almacenados en el servidor.

Las estaciones de trabajo locales utilizan menos espacio de disco debido a que los datos se encuentran centralizados en un único lugar pero pueden ser accedidos y modificados por varios usuarios, de tal forma que no es necesario replicar la información.

Los usuarios no necesitan disponer de un directorio “home” en cada una de las máquinas de la organización. Los directorios “home” pueden crearse en el servidor de NFS para

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 30

posteriormente poder acceder a ellos desde cualquier máquina a través de la infraestructura de red.

También se pueden compartir a través de la red dispositivos de almacenamiento como, CD- ROM y unidades ZIP. Esto puede reducir la inversión en dichos dispositivos y mejorar el aprovechamiento del hardware existente en la organización.

Todas las operaciones sobre archivos son síncronas. Esto significa que la operación sólo retorna cuando el servidor ha completado todo el trabajo asociado para esa operación. En caso de una solicitud de escritura, el servidor escribirá físicamente los datos en el disco, y si es necesario, actualizará la estructura de directorios, antes de devolver una respuesta al cliente. Esto garantiza la integridad de los archivos. [15]

En caso de que el usuario lo necesite se puede cambiar a modo asíncrono.

2.1.2 Versiones de NFS

En el momento existen varias versiones de NFS. El protocolo ha ido evolucionado a través del tiempo. Como se puede ver, las últimas mejoras están orientadas al área de la seguridad y la velocidad.

 La versión 2 de NFS (NFSv2), es la más antigua y está ampliamente soportada por muchos sistemas operativos.

 La versión 3 de NFS (NFSv3) tiene más características, incluyendo manejo de archivos de tamaño variable y mejores facilidades de informes de errores, pero no es completamente compatible con los clientes NFSv2. Mejora del rendimiento debido a la reescritura del código de la red, y al uso de paquetes de datos mayores. Mejora en la seguridad gracias al uso de listas de control de acceso o ACL (access control list) que permiten definir acceso a los recursos por UID y fichero a fichero. Implementación de un sistema de autentificación basado en contraseña.

 NFS versión 4 (NFSv4) incluye seguridad Kerberos (protocolo de autenticación de redes de ordenador que permite a dos computadores en una red insegura demostrar su identidad mutuamente de manera segura), trabaja con cortafuegos, permite ACLs

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 31

y utiliza operaciones con descripción del estado. Es la versión recomendada en la actualidad.

En el anexo II se puede encontrar el procedimiento de instalación y configuración de NFS tanto para el servidor como para el cliente. De forma general se puede decir que es un proceso sencillo y rápido.

De cualquier forma luego de realizar la instalación se recomienda realizar pruebas para validar las mejores opciones y ajustar los parámetros por defectos del proceso de instalación.

El sistema NFS aunque muy útil y flexible sobre todo en la parte del cliente aún está limitado a un servidor. O sea el servidor solo puede compartir lo que él contiene y esto está acotado por la capacidad de sus discos. Por ejemplo si solo tiene capacidad para 8 discos y estos pueden ser como máximo de 2 TB entonces el mayor recurso compartido por NFS será de 16 TB suponiendo que no se aplique antes algún tipo de RAID.

2.2 GlusterFS.

Dada la deficiencia de NFS de extrapolarse más allá de un servidor aparece una solución muy ingeniosa que se dio a conocer como GlusterFS.

GlusterFS un sistema de archivos de alta disponibilidad y escalabilidad que puede brindar almacenamiento a gran escala (petabytes) a bajo costo (opensource) y manejo de hasta miles de clientes, está basado en FUSE (Fileystem user space). FUSE permite levantar el sistema de archivo de Gluster en el user space (espacio de memoria donde trabajan las aplicaciones del usuario).

La comunicación entre el server y los clientes se puede realizar de dos formas: usando NFS como una vía de garantizar compatibilidad o usando el protocolo propio de Gluster como vía de lograr un mejor rendimiento y uso pleno de las posibilidades existentes.

GlusterFS agrupa dispositivos de almacenamiento a través de la red y maneja los datos como si fuesen un solo bloque.

Esta idea a groso modo se muestra en la figura 2.2

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 32

Figura 2-2: Dispositivos de almacenamiento.

Para un mejor entendimiento del protocolo se hace necesario conocer alguno de los conceptos manejados en la documentación y configuración del mismo

Bloque (Brick):

Es la capa física de almacenamiento para los volúmenes.

Volumen:

Un volumen está compuesto por múltiples bloques.

Figura 2-4: Volumen.

Servidor:

Equipo (virtual o real) que exporta el volumen. Es el que alberga el sistema de archivos donde se guardará la data, y provee acceso a los volúmenes.

Figura 2-5: Servidor.

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 33

Cliente:

Es el equipo que monta el volumen, este equipo también puede ser un servidor.

Figura 2-6: Cliente.

2.2.1 Distribución y Replicación de la Data.

La ventaja mayor de GlusterFS es la capacidad para salir de un server y poder escalar. Dicho de otra forma: GlusterFS se puede crecer adicionando más servidores con espacio a compartir. Esto se hace a través de un mismo volumen en varios servidores.

Esta separación de los datos se puede configurar casi de forma idéntica a como se realizaban los RAID expuestos en el capítulo anterior.

Cuando GlusterFS opera de esta forma se le llama modo distribuido y es para lo que realmente fue diseñado.

La configuración de Gluster para un modo distribuido toma una lista de sub-volúmenes y distribuye los archivos entre ellos. Para calcular en cuál de los servidores será almacenado el archivo se realiza un hash al nombre del archivo. Es estadísticamente improbable que existan dos hash iguales para nombres completos de archivos diferentes.

A continuación una descripción de las variantes usadas por GlusterFS.

Volumen distribuido:

Consiste en copiar la información en bloques separados en servidores separados. Es muy semejante al RAID 0 aunque cualquier archivo siempre estará completamente copiado en solo un servidor.

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 34

Figura 2-7: Volumen Distribuido.

Este modo tiene ciertas desventajas como que si uno de los servidores esta fuera de servicio no se pueden recuperar los archivos que están almacenados en él. También pueden presentarse problemas de lectura/escritura si un archivo es de un tamaño mayor al sub- volumen en el que debe ser almacenado.

Volumen en Réplica:

Este modo provee redundancia en la información almacenada en los servidores, lo que se encuentra en un servidor esta exactamente igual que en los otros. Esto ofrece no solo redundancia en los datos sino en la disponibilidad del servicio. En cada operación sobre los archivos se hace la copia en la réplica por lo que podemos decir que hay sincronización en esta. Es el modo más utilizado.

Figura 2-8: Volumen en Réplica.

Funciona de manera análoga a RAID 1.

Volumen Distribuido en Réplica:

Esta modalidad es una mezcla de las dos anteriores y distribuye los archivos a través de volúmenes en réplica. Este tipo de configuración ofrece mejoras considerables en

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 35

operaciones de lectura en la mayoría de los ambientes. Es el recomendado cuando la alta disponibilidad y la alta confiabilidad son críticas.

Figura 2-9: Distribuido en Réplica.

Volumen distribuido con réplica distribuida:

Es una variante del anterior donde básicamente se prioriza el uso de un servidor y se mantiene la copia en otro. Esto sería solo recomendable cuando las características físicas de los servidores no sean las mismas.

Figura 2-10: Réplica Distribuido.

Se mantiene garantizada la duplicidad de la información. Pero hay una limitación en el tamaño de los volúmenes dada por el servidor con menor capacidad.

Geo-Replicación:

Esta modalidad provee de un servicio de replicación asíncrona a través de una red LAN o WAN o Internet. Trabaja basándose en un modelo maestro-esclavo, siendo el maestro, un volumen GlusterFS, y el esclavo puede ser:

 Un directorio Local.

 Otro volumen GlusterFS, que puede ser local o encontrarse en un servidor diferente.

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 36

Cuando los datos en el maestro dejan de estar disponibles, pueden restituirse a partir de cualquiera de los esclavos. A diferencia del Volumen en Réplica visto anteriormente, mantiene la copia de los datos de forma asíncrona, es decir chequea periódicamente cambios en la información y sincroniza al detectar algún cambio.

Figura 2-11: Geo-Replicación

Volumen Stripped:

Esta modalidad es una variante de los Volúmenes distribuidos vistos anteriormente. Es generalmente utilizada para almacenar datos de computación de alto rendimiento, funciona repartiendo cada archivo en diferentes bloques, con lo que podemos inferir que es más óptimo para archivos de gran tamaño.

Figura 2-12: Volumen Stripped.

Luego de mostradas todas las variantes en las que puede trabajar GlusterFS, alguna de sus ventajas pueden resultar muy obvias.

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 37

 Muy buena flexibilidad para combinar diversos dispositivos, ya sean físicos, virtuales o disco en la nube.

 Muy fácil de instalar y configurar.

 Diseño modular y apilable.

 Escalabilidad linear.

 Completamente implementado en user-space (FUSE).

 Fácil de migrar, depurar y mantener.

 Diferentes modalidades de configuración.

 Se crea sobre un sistema de archivos existente (ext3, ext4) lo que hace que se puedan recuperar los archivos aún si Gluster deja de funcionar.

 Los recursos de almacenamiento pueden ampliarse o disminuirse de acuerdo a las necesidades.

Todo esto ha posibilitado que en la actualidad numerosas organizaciones de diversos tipos estén utilizando GlusterFS en sectores tan disímiles como finanzas, salud y portales sobre web 2.0.

En el anexo III se muestra el proceso de instalación y configuración de GlusterFS en una configuración de 3 nodos.

2.3 Ceph.

2.3.1 Surgimiento de Ceph.

A Sage Weil se le atribuye la creación de Ceph como parte de un proyecto de doctorado en la Universidad de California, Santa Cruz. El proyecto fue la culminación de años de investigación por profesores y estudiantes graduados de la Universidad de California en

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 38

Santa Cruz. El nombre se deriva de Ceph Cefalópodo, una clase de moluscos que incluye la sepia, el pulpo y el calamar.

El proyecto Ceph de código abierto se inició en 2004 y se convirtió en el software disponible bajo una licencia de código abierto en el año 2006.

Después de completar su doctorado, Weil trabajó en el proyecto de código abierto Ceph con el apoyo de DreamHost. En 2012, formaron una empresa llamada InkTank Inc. para proporcionar una versión con soporte comercial de Ceph para los usuarios empresariales.

Red Hat Inc. adquirió InkTank en 2014 por $ 175 millones. Weil asumió el papel de principal arquitecto en Ceph de Red Hat.

Los vendedores que ofrecen hardware diseñado específicamente para su uso con el software de Ceph incluyen Fujitsu, Super Micro Computer SanDisk y división de Western Digital.

2.3.2 Arquitectura de Ceph.

Ceph es un sistema de almacenamiento muy potente, con muy buen rendimiento, altamente escalable y normalmente con un coste muy reducido (comparativamente).

Ceph es un sistema de almacenamiento distribuido altamente escalable bajo licencia GPL, pretende ser un sistema de archivos completamente distribuido y sin ningún punto de fallo. La replicación usa sistemas tolerantes a fallos para obtener datos libres de errores.

Normalmente los sistemas basados en RAID tienen más posibilidades de que los datos se corrompan a medida que aumentan de tamaño. Esto por supuesto es minimizado por las controladoras pero siempre es una posibilidad que limita físicamente el tamaño de los volúmenes que se crean. Teniendo esto en cuenta se diseña Ceph.

Ceph usa la replicación para obtener redundancia en los datos y mejorar el rendimiento de acceso a los mismos, proporcionando sistemas que garantizan la integridad de todos ellos. Desde la versión 2.6.34.2, el kernel de Linux incluye soporte a Ceph.

Esta tecnología nos permite almacenar objetos, dispositivos de bloques y ficheros, también permite acceso directo a objetos usando lenguajes nativos como bindins o radosgw y ofrece

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 39

además dispositivos de bloques a los clientes. Todo esto vinculado con recursos en red para acceder a los ficheros que queramos compartir.

Una arquitectura típica de Ceph es mostrada en la figura 2.13.

Los elementos fundamentales son:

Monitores:

OSD (object storage daemon) Servicio de almacenamiento de objetos. Es básicamente el almacén donde la información real es guardada. Cada disco puede ser compartido entero o en forma parcial a la arquitectura Ceph. Todo el control de como guardar los datos tanto como entrada o como salida es realizado por este proceso. Están conectados entre ellos por una red interna que solo se usa para sincronización a alta velocidad y disponen adicionalmente de un enlace con los monitores.

Monitor. Es el encargado de mantener la comunicación con los clientes y tramitarlo a los OSD. Guarda las tablas donde están declarados que está almacenado en cada OSD y donde están las réplicas. Se supone que son servidores con gran capacidad de memoria y de gran capacidad de conexión tanto para la parte del cliente como para los OSD.

Adicionalmente hay otros servicios como RADOS que permiten la integración de los volúmenes compartidos por los monitores con los sistemas operativos en forma de un sistema de archivos.

Si se resume se puede decir que ofrece acceso a objetos, a dispositivos de bloques tipo iSCSI y a sistemas de ficheros tipo NFS o samba. Algo parecido a lo que viene siendo hoy en día los sistemas de almacenamiento SAN o los NAS más avanzados. Pero lo que lo hace completamente diferente es su capacidad de crecer con solo adicionar servidores los cuales es bueno aclarar se recomiendan que no dispongan de tarjetas RAID para hacer más transparentes el flujo de datos. [2]

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 40

Figura 2-13: Elementos que componen Ceph.

2.4 Consideraciones finales del Capítulo.

Las soluciones de almacenamiento por hardware vistas en el capítulo 1 sin duda alguna son utilizadas en el mundo actual pero hay un importante sector que no puede costearlas o a los que simplemente no les cubren los requerimientos. Para este grupo de usuarios hay soluciones basadas en software que están diseñadas específicamente teniendo en cuenta el desempeño en red, la escalabilidad y la flexibilidad.

La más sencilla de estas opciones es NFS la cual permite la conexión de varios clientes con un servidor, estos clientes pueden estar tanto en computadoras como en aplicaciones empotradas como media player o impresoras.

Cuando esta solución no es suficiente se puede optar por GlusterNFS que ya permite la interacción de varios servidores los cuales pueden estar muy separados físicamente.

Las redes de almacenamiento sobre GlusterFS pueden crecer a medida que se colocan servidores, estos ni siquiera deben ser iguales ya que solo importa el espacio en disco que ellos aportan al sistema en su totalidad. Aunque este protocolo está pensado sobre la idea

CAPÍTULO 2. SERVICIOS DE ALMACENAMIENTO 41

de crecer y crecer, en la práctica ha demostrado que no lo puede hacer por siempre. No existen muchos informes de escalabilidad por encima del petabyte.

Las aplicaciones que necesiten espacios de terabyte o más no son comunes pero si existen y se pueden encontrar sobre todo en el mundo de las simulaciones y del cálculo científico lo cual tiene especial importancia como se podrá ver en el capítulo siguiente.

Es este caso la solución aconsejada y más usada en el mundo es Ceph. Las nubes de Ceph pueden crecer en teoría y en la práctica sobre valores de petabyte sin perder rendimiento. Esta ventaja por supuesto lleva un costo que debe ser pagado: la cantidad de recursos a emplear en el mantenimiento y la administración es mayor. Esto quiere decir que se deben dedicar servidores con grandes capacidades de CPU y memoria solo para garantizar que toda la arquitectura trabaje, pero el beneficio final sin duda alguna hace que sea un costo soportable.

Definitivamente se puede decir que Ceph es muy escalable, completo y tecnológicamente avanzado. Es una alternativa real a los grandes sistemas de almacenamiento, permitiendo tener implementada una solución que nos ofrezca las mismas características que una red SAN por un coste menor, siendo además más fácil, sencillo y económico de escalar para satisfacer futuras necesidades de almacenado.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 42

CAPÍTULO 3. Almacenamiento en la Red UCLV.

Hasta el momento se han mostrado las soluciones de almacenamiento tanto por hardware como por software. En este capítulo se analiza una red real y en producción, la de la Universidad Central “Marta Abreu” de Las Villas, se enumeran los servicios más importantes y se propone una de las soluciones de almacenamiento vistas para cada caso.

Para una mejor comprensión se incluye un epígrafe con la historia muy compactada de esta red.

3.1 Historia de la Red UCLV.

En la década de los 80 en la universidad se crearon conexiones muy elementales e individuales con entidades externas, pero no es hasta mediados de los 90 que comienzan a aparecer pequeñas redes dentro del centro. En el año 1995 en la UCLV ya se manejaba el concepto de redes. Se realiza el ejercicio de “Visión y Misión” por parte del consejo de dirección de la Universidad Central “Marta Abreu” de Las Villas y se forma el subgrupo de Tecnologías de la Información y las Comunicaciones. Por vez primera ese plantea la necesidad de una red de computadoras y su interconexión para todo el centro.

En sus primeros momentos no se disponía de una red como tal, existían pequeñas redes que agrupaban un máximo de doce computadoras, las que no se encontraban conectadas entre sí, sino de enlaces por módems de línea telefónica con la puerta de algunas facultades (FIE, INDECO) y del Centro de Estudios de Informática (CEI).

En septiembre de1998, mediante la Resolución Rectoral 186/98 se constituye el Grupo de Redes y se aprueba el proyecto de Red UCLV a 100 Mbps la cual se proyecta y diseña en dos fases.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 43

Para la aplicación de la primera fase se contrató la firma PC-NET en la adquisición del equipamiento y la fibra óptica. La cual se instaló aprovechando los ductos de los que disponía ETECSA y que quedarían en desuso luego del cambiado del cableado telefónico.

Figura 3.1: Red UCLV primera etapa.

El la figura 3.1 se puede ver el estado de la red luego de finalizada la primera etapa a mediados del 2000.

Dos años más tarde, quedó instalada y en funcionamiento la segunda expansión del backbone universitario. Esta inversión hizo posible el acceso de estudiantes y profesores de las facultades de Ciencias Agropecuarias y Construcciones. Al mismo tiempo quedaron conectadas otras zonas como el SEDER y el Centro de Bioactivos Químicos.

En el año 2003 bajo el financiamiento del proyecto VLIR (VLAAMSE INTERUNIVERSITAIRE RAAD) se comenzaron los trabajos para una nueva fase de mejoramiento del backbone universitario.

Una vez establecidas las bases de la red se llevó a cabo un proceso de centralización desde el punto de vista de gestión.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 44

Gracias a este proyecto la red creció de forma acelerada y contando con equipamiento de clase profesional que permitió la conexión de la totalidad de las áreas presentes en el campus UCLV. [32]

En el período del 2004 al 2014 la Red UCLV recibió en su totalidad los recursos de cuatro proyectos internacionales enfocados en el mejoramiento de la red.

En la figura siguiente se muestra una imagen de la Red UCLV en este momento.

Figura 3.2: Diagrama de la Red UCLV.

3.2 Servicios más importantes en la Red UCLV y sus requerimientos.

A continuación se procede a realizar una enumeración de los servicios que se consideran muy importantes en la Red UCLV. Existen muchos otros pero, o bien se encuentran

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 45

incluidas en categorías muy similares a las que se mencionan a continuación, o no son tan importantes para el funcionamiento de la red.

3.2.1 Cuentas de usuario.

En una red de computadoras un usuario es una entidad más de un grupo y para poder diferenciarlo entre el resto se usa normalmente un nombre de usuario y una contraseña (login y password). Estos datos se almacenan en servidores que no pueden o no deben dañarse bajo ninguna circunstancia pues todo el funcionamiento de la red depende de esto, por suerte estos datos no ocupan grandes cantidades de espacio.

En el caso de la UCLV las cuentas de usuarios se mantienen usando la tecnología de Active Directory de Microsoft. Los controladores de dominio que es como se llaman a los servidores que brindan este servicio, incluyen opciones de replicación con pares por lo que es relativamente sencillo tener al menos dos servidores que replican entre ellos toda la información clave del dominio que es como se le domina al grupo lógico donde se agrupan las cuentas de usuarios. Gracias a esto el proceso de garantizar la integridad de la información es mucho más fácil ya que solo hay que centrarse en el problema local, o sea que un servidor no pierda la información que hay dentro de él.

En este caso la variante que se aplica y la que el autor de este trabajo recomienda mantener estos servidores con dos discos configurados en RAID 1.

Este RAID como se mencionó anteriormente puede ser visto como un espejo: Todo lo que está en un disco se copia automáticamente en un segundo. Esto permite que si uno de ellos se afecta el otro va a continuar en activo posibilitando que se pueda retirar el disco dañado, colocar uno nuevo y que se inicie el proceso de sincronización.

En el caso que los dos discos del servidor se dañen a la misma vez (lo cual es estadísticamente mucho más difícil) siempre quedarían los demás servidores de dominio que mantienen una copia de la información útil gracias a la replicación propia del Active Directory.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 46

3.2.2 Correo Electrónico.

Otro de los servicios con más uso en la Red UCLV es el correo electrónico. Este servicio ya es parte obligatoria del trabajo diario de los estudiantes y profesores de la institución y una afectación de su disponibilidad resulta sin lugar a dudas una interrupción en el trabajo de la institución. Más allá: una pérdida de los correos del personal puede tener serias consecuencias en la estabilidad de la universidad.

A través del correo electrónico se mueven cantidades considerables de información y en muchos casos los buzones de los usuarios son una especie de repositorio de archivos que son imprescindibles. Así pues estamos frente a un servicio de alta demanda y alto volumen que no se puede afectar de modo que su disponibilidad baje de un 98%.

En este momento en la UCLV se dispone de dos plataformas de correo electrónico por lo que el análisis de divide en 2 partes.

Dominio UCLV.EDU.CU:

Bajo este dominio se encuentran los usuarios más antiguos de la Red UCLV. Es un servicio con más de 20 años de creado y ya ha pasado por varias actualizaciones. Se encuentra sobre servidores ejecutando Microsoft Exchange Server 2007. En un comienzo existían cuatro de estos servidores para manejar todos los buzones pero en el momento solo hay un operativo que contiene alrededor de 1200 usuarios con un volumen de 2 terabytes de datos.

El servidor que contiene estos buzones es un DELL PowerEdge 2950 con capacidad para 6 discos duros. Actualmente posee 4 discos: 2 de 250 GB y 2 de 2TB que están configurados en dos grupos de RAID 1. El primero es para el sistema operativo y el segundo para almacenamiento de los buzones.

Teniendo en cuenta que Exchange es dependiente tanto del sistema operativo como de los buzones y que el espacio de uso debe disminuir progresivamente se aconseja pasar a un RAID5 compuesto por 3 discos de 2TB. Esto debe aumentar la tolerancia contra fallos sin afectar la capacidad del servicio.

Dominio UCLV.CU:

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 47

Esta configuración es mucho más sencilla pues esta todo almacenado en un potente servidor con capacidad para 6 discos los cuales actualmente están configurados en 2 RAID. El primero para almacenar el sistema RAID 1 de dos discos y el segundo para los buzones RAID 5 de 4 discos.

Esta configuración según la propuesta de este trabajo es la más óptima para el caso.

3.2.3 Navegación por Internet.

La navegación por Internet es otro de los servicios considerados básicos para los usuarios de la Red UCLV. Dada la estructura de la red para que un usuario que se encuentre por ejemplo en un laboratorio de una facultad cualquiera pueda acceder a Internet debe pasar por un servidor que se conoce normalmente como proxy. El proxy es el encargado de recibir la petición del usuario, validarla, tramitarla, esperar por la respuesta y cuando esta llegue enviarla de regreso al usuario.

Todo el proceso normalmente se realiza en pocos segundos.

Desde el punto de vista técnico un proxy necesita alta capacidad de CPU, memoria y un acceso a disco lo más rápido posible.

El acceso a disco está dividido en dos partes: una para mirar en el caché (ya que si lo que se pide está allí no hay porque pedirlo de nuevo) y para guardar los registros o logs de las operaciones realizadas.

La UCLV actualmente y debido a los varios canales de salida y características muy propias cuenta con una complicada estructura que incluye 3 servidores proxy. Aunque los tres se ejecutan sobre el mismo servidor físico lo hacen sobre una plataforma de virtualización.

En la figura siguiente se muestra un diagrama de esta estructura.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 48

Figura 3.3: Server Real.

En el momento actual en este servidor de virtualización no existen otras computadoras.

El servidor real es un PowerEdge R520 con 8 discos duros SATA de 2 terabytes configurados en RAID5.

Dada la configuración de los servicios, las características del servidor y las tecnologías vistas hasta el momento se puede decir que la configuración actual presenta algunos inconvenientes y que podría ser mejorada. Entre las principales deficiencias se puede decir que los RAID5 de este tamaño tardan mucho en repararse haciendo que esa ventana de tiempo sea extremadamente sensible para el servidor. En el caso que se analiza es de 36 horas. Si durante el tiempo que se está actualizando el RAID 5 ocurriera otro problema con los discos restantes se perdería todo el contenido.

Para este caso se aconsejan dos variantes:

La primera consiste en liberar varios discos de este servidor manteniendo una configuración mínima de 3 discos en RAID5. Esto implica la reinstalación del servidor pero al ser máquinas virtuales lo que se debe restaurar el proceso es mucho más sencillo. Con esta opción se mantiene una buena cantidad de espacio, tiempos de acceso aceptables para la aplicación y el proceso de recuperación es mucho más rápido en caso de fallos.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 49

La segunda variante implicaría la creación de un RAID1 con 2 o 4 discos. El acceso sería relativamente rápido y se podrían ahorrar varios discos que se pueden usar en otras instalaciones.

3.2.4 Almacenamiento de programas y recursos compartidos.

El elemento básico del trabajo en colaboración apoyado en la red es la carpeta compartida. Al compartir una carpeta de un equipo se conseguirá que otros equipos de su red local puedan acceder a los archivos presentes en ella. Los equipos de la red local podrán abrir y guardar en ella archivos y carpetas, como si se tratase de una carpeta del propio disco duro. Si varios miembros de la red trabajan con los mismos archivos, se observa que el trabajo en red aporta un aumento de productividad inmediato.

Entre los recursos que más se comparten, tienen un papel especial los audiovisuales debido a sus características: gran tamaño y uso por oleada. Estos materiales son unos de los medios más importantes dentro del ámbito educativo no importa si se ven desde el punto de vista de la enseñanza como del aprendizaje. De esta manera podemos desarrollar la formación del profesorado y realizar actividades de promoción social.

En cualquier caso los materiales que están bajo la categoría de este epígrafe son voluminosos y en muchas ocasiones son copiados en forma de grandes paquetes. Pero lo más importante es que nunca dejan de aparecer y que nunca deberían eliminarse.

En la RED UCLV existen varios repositorios de información y programas que pueden ser agrupados bajo esta denominación de servicio.

La característica más común de este tipo de información es que crece y crece y jamás se desea eliminar nada y este es el problema más importante que enfrenta la Red UCLV en este sentido con este tipo de información. Es tanta que ya no cabe en el lugar donde se encuentra: un servidor Power Edge 2950 con capacidad para 6 discos duros de 2 TB en configuración RAID 5.

No es posible crecer los discos porque los servidores no los soportan de mayor tamaño y dividir la información sería complicado desde el punto de vista de los usuarios que ya están acostumbrados a un punto de entrada.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 50

La propuesta de este trabajo es la creación de un volumen de Gluster FS distribuido entre varios servidores que permita pasar más allá del tamaño actual. Para ello se aconseja el uso de 3 servidores semejantes al actual, que creen un volumen que duplique al repositorio existente, permitiendo una velocidad de acceso superior y la posibilidad de expansión en el futuro.

Esta instalación se efectuó en un ambiente de pruebas a mucha menor escala por supuesto siguiendo el procedimiento relacionado en el anexo III.

3.2.5 Almacenamiento de la información de usuarios.

Este caso es muy semejante al epígrafe anterior. La única diferencia es tiempo de vida de la información.

Cuando un usuario de la Red UCLV recibe su cuenta para acceder a los servicios de la red se crea un espacio de almacenamiento que él puede usar para guardar sus documentos más importantes. Este espacio estará disponible mientras el usuario tenga cuenta en la red. En el momento que la pierde se pierde también el acceso a esta información aunque en si es almacenada por otro pequeño período de tiempo.

Normalmente se asigna a un usuario un espacio de unos 4 GB pero en muchas ocasiones se debe incrementar este valor a lo largo de los años.

En la actualidad esta información esta almacenada en un SAN FC que mantiene un nivel de RAID 5 entre sus discos. La única desventaja de este método es que no se puede brindar redundancia en la entrada a la información, esto quiere decir que todos los accesos deben realizarse a través del mismo servidor, siendo este el punto débil de la cadena.

De cualquier forma esta limitante no afecta por el momento el desempeño actual y de acuerdo a lo analizado en este trabajo se mantiene como la mejor opción.

3.2.6 Clúster de cálculo.

Uno de los servicios con mayor necesidad de almacenamiento es el cálculo científico. Una modelación de unos pocos minutos del comportamiento de una estructura química por ejemplo puede generar gigas o tera bytes de datos normalmente.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 51

En la UCLV se dispone de un clúster de cálculo formado por 12 nodos de alta capacidad y unos 20 de mediano nivel. En este momento todo el almacenamiento se hace en 2 SAN de FC con 4 extensores que brindan una capacidad total de 10 tera bytes de alta velocidad de acceso ya que todos los discos son SCSI de 15 mil revoluciones.

Lamentablemente esto no es suficiente para los cálculos actuales y mucho menos para los futuros. En este sentido la recomendación de este trabajo es implementar una solución basada en Ceph como se ilustró en el epígrafe 2.3.2.

La principal desventaja de esta configuración es que se deben “sacrificar” varios servidores para que actúen como monitores. Estos son las interfaces entre el usuario y los servidores de almacenamiento. Esta desventaja contrasta con la mayor ventaja del sistema que es la capacidad de crecerse infinitamente.

Teniendo en cuenta el equipamiento del que se dispone en el nodo central de la Red UCLV la propuesta es usar servidores R200 para la función de monitor y servidores R2950 para la opción de OSD o almacenamiento.

Lamentablemente esta opción solo pudo ser simulada y no se tienen resultados reales aún. Esto queda registrado como una de las recomendaciones de este trabajo.

3.2.7 Bases de datos.

El caso de las bases de datos es quizás el más tradicional de todos, usadas para almacenar información necesaria para sistemas de diversos tipos como pueden ser contables, registros, configuraciones, etc. Casi cualquier cosa puede ser almacenada en sistemas de bases de datos.

En la Red UCLV las principales bases de datos son las que alimentan a los sistemas: SIGENU, ASSET, estipendio y las de otras aplicaciones.

En el caso de los sistemas administrativos de la UCLV la recomendación es mantener la situación actual: servidores virtuales o reales individuales sobre RAID5.

Para las aplicaciones más pequeñas como sitios webs o derivados de las bases de datos mencionadas en el párrafo anterior se aconseja la instalación de un nuevo servidor que permita la centralización de este recurso. Para ese servidor se aconseja una configuración

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 52

sencilla pero rápida y que garantice la integridad de los datos. Dado el volumen de la información actual que no es grande se recomienda un RAID 1.

3.3 Análisis económico.

En cuanto a la solución por hardware el costo de comprar equipos nuevos es muy caro. Porque en una red SAN los protocolos utilizados son Fibre Channel e iSCSI, muy rápida y no está agobiada por el tráfico de la red LAN. Sin embargo, es muy cara, siempre más de 10 000 USD. Las tarjetas de canal de fibra óptica cuestan alrededor de $ 500.00 USD cada una. Para un despliegue mayor se necesitan además switch de FC con valores base de 3000 USD. También requieren conmutadores especiales de canal de fibra.

Para minimizar esto se puede usar iSCSI que es una nueva tecnología que envía comandos SCSI sobre una red TCP / IP. Este método no es tan rápido como una red Fibre Channel, pero ahorra costes, ya que utiliza un hardware de red menos costoso pero siempre por encima de los 5000 USD.

La arquitectura SAN es mucho más costosa que una NAS ya que la primera es una arquitectura completa que utiliza una tecnología que todavía es muy cara. Normalmente, cuando una compañía estima el TCO (Coste total de propiedad) con respecto al coste por byte, el coste se puede justificar con más facilidad.

Para el uso de las configuraciones RAID lo mejor es comprar discos de gran capacidad, rápidos y caros en lugar de discos más lentos y pequeños.

Por el contrario, los sistemas basados en software son mucho más flexibles, permitiendo, por ejemplo, construir RAID de particiones en lugar de discos completos y agrupar en un mismo RAID, discos conectados en varias controladoras.

Si estas aplicaciones están disponible bajo licencia de software libre como las analizadas en este trabajo entonces el costo estaría solo relacionado con el personal que las implementa y su capacitación.

CAPÍTULO 3. ALMACENAMIENTO EN LA RED UCLV 53

3.4 Conclusiones del Capítulo.

La correcta elección del hardware y sus diversas configuraciones, en el uso de una red de área de almacenamiento, resulta fundamental en las computadoras dedicadas a tareas intensivas y que requieran asegurar la integridad de los datos en caso de fallo del sistema.

Esta característica está disponible en los sistemas RAID por hardware, sus variantes permiten que un disco falle mecánicamente y que aun así los datos se recuperen en un disco de reemplazo a partir de los restantes discos del conjunto, mientras al mismo tiempo permanece disponible para los usuarios en un modo degradado. Esto es muy valorado por las empresas, ya que el tiempo de no disponibilidad suele tener graves repercusiones.

El software Ceph junto al GlusterFS son unas herramientas de gran flexibilidad, fiabilidad, velocidad o una combinación de éstas en un solo dispositivo, permitiendo, por ejemplo, construir RAID de particiones en lugar de discos completos y agrupar en un mismo RAID discos conectados en varias controladoras. Se pueden encontrar siendo utilizados en una gran variedad de entornos y aplicaciones como cloud storage, ciencias biomédicas y almacenamiento de archivos.

Las aplicaciones basadas en NFS están disminuyendo en el ambiente de la Red UCLV.

Los mismos son de gran importancia pues permiten mejorar el rendimiento, seguridad y escalabilidad de los servicios en la Red UCLV.

REFERENCIAS BIBLIOGRÁFICAS 54

CONCLUSIONES Y RECOMENDACIONES

Conclusiones

Durante el transcurso de esta investigación se estudiaron y evaluaron un conjunto de estrategias para la obtención de mejores servicios informáticos de almacenamiento para la red UCLV.

Los principales resultados obtenidos se exponen a continuación:

1. Las soluciones por hardware como los RAID, los DAS, los NAS y los SAN son adecuados para mejorar la velocidad de acceso y de garantizar la integridad de los datos almacenados.

2. Para garantizar que la información no se pierda las soluciones por hardware son las más adecuadas pero usualmente tienen un costo alto.

3. Las soluciones por software son la solución tecnológica más económicamente viable en la actualidad, siendo Ceph y GlusterFS una de las mejores opciones, dado su sistema de archivos distribuido libre, escalable, versátil y su relación calidad- precio.

4. La Red UCLV cuenta con servicios que pueden mejorar su rendimiento de cambiarse la arquitectura de almacenamiento actual sin hacer grandes inversiones.

5. Los resultados obtenidos aplicando el procedimiento establecido fueron evaluados de forma experimental, validando la correlación entre las soluciones por hardware y software.

REFERENCIAS BIBLIOGRÁFICAS 55

Recomendaciones

Para establecer la continuidad que debe tener este trabajo se recomienda lo siguiente:

1. Se recomienda hacer los cambios en la tecnología de almacenamientos recomendados en cada uno de los servicios del capítulo 3. Estos son:

 Almacenamiento de programas y recursos compartidos: la propuesta de este trabajo es la creación de un volumen de Gluster FS distribuido entre varios servidores que permita pasar más allá del tamaño actual. Para ello se aconseja el uso de 3 servidores semejantes al actual, que creen un volumen que duplique al repositorio existente, permitiendo una velocidad de acceso superior y la posibilidad de expansión en el futuro.

 Correo Electrónico: Teniendo en cuenta que el Server Exchange del dominio UCLV.EDU.CU es dependiente tanto del sistema operativo como de los buzones y que el espacio de uso debe disminuir progresivamente se aconseja pasar a un RAID5 compuesto por 3 discos de 2TB. Esto debe aumentar la tolerancia contra fallos sin afectar la capacidad del servicio. En el Dominio UCLV.CU la configuración es mucho más sencilla pues esta todo almacenado en un potente servidor con capacidad para 6 discos los cuales actualmente están configurados en 2 RAID. El primero para almacenar el sistema RAID 1 de dos discos y el segundo para los buzones RAID 5 de 4 discos. Esta configuración según la propuesta de este trabajo es la más óptima para el caso.

 Navegación por Internet: Se aconsejan dos variantes; la primera consiste en liberar varios discos de este servidor manteniendo una configuración mínima de 3 discos en RAID5. Esto implica la reinstalación del servidor pero al ser máquinas virtuales lo que se debe restaurar el proceso es mucho más sencillo. Con esta opción se

REFERENCIAS BIBLIOGRÁFICAS 56

mantiene una buena cantidad de espacio, tiempos de acceso aceptables para la aplicación y el proceso de recuperación es mucho más rápido en caso de fallos. La segunda variante implicaría la creación de un RAID1 con 2 o 4 discos. El acceso sería relativamente rápido y se podrían ahorrar varios discos que se pueden usar en otras instalaciones.

 Almacenamiento de la información de usuarios: La configuración actual se mantiene como la mejor opción ya que la limitante de almacenar la información en un SAN FC que mantiene un nivel de RAID 5 entre sus discos que no brinda redundancia en la entrada a la información no afecta por el momento el desempeño actual .

 Clúster de cálculo: lamentablemente no es suficiente para los cálculos actuales y mucho menos para los futuros. En este sentido la recomendación de este trabajo es implementar una solución basada en Ceph como se ilustró en el epígrafe 2.3.2.

 Bases de datos: en el caso de los sistemas administrativos de la UCLV la recomendación es mantener la situación actual: servidores virtuales o reales individuales sobre RAID5.

 Actualizar los discos en configuración de RAID que se están usando actualmente ya que muchos tiene un tiempo de explotación mayor a 3 años.

 Implementar con la mayor rapidez posible Ceph para el clúster de cálculo ya que hay limitación en algunas simulaciones por problema de espacio.

REFERENCIAS BIBLIOGRÁFICAS 57

REFERENCIAS BIBLIOGRÁFICAS 58

REFERENCIAS BIBLIOGRÁFICAS

[1] Desde http://www.infinibandta.org.

[2] Desde http://ceph.com.

[3] Desde http://docs.openstack.org.

[4] Desde http://s3tools.org/s3cmd.

[5] Desde http://iesgn.github.io/cloud.

[6] À. Perles, X. M., A. Martí, V. Santonja, J.J. Serrano "Simulación concurrente de redes de almacenamiento de altas prestaciones (SAN, Storage Area Networks)." 10.

[7] À. Perles, X. M., A. Martí, V. Santonja, J.J. Serrano "Simulación concurrente de redes de almacenamiento de altas prestaciones (SAN, Storage Area Networks)."

[8] arubio (junio, 2015). "Comparativa Ceph, SAN y NAS. Ceph ¿Almacenamiento a bajo coste?". Desde http://www.cursovirtualizacion.es.

[9] Boyd, D. and K. Crawford (2012). "Critical questions for big data: Provocations for a cultural, technological, and scholarly phenomenon." Information, communication & society 15(5): 662-679.

[10] Castano, A. A. E. (2014). "STORAGE NETWORKS." Retrieved 5 de febrero, 2016, Desde http://www.monografias.com.

[11] Connor, D. (2007). "Fibre Channel vs. iSCSI."

[12] Data, B. (2013). "big data." Cuadernos de Comunicación e Innovación Cuadernos de Comunicación e Innovación.

REFERENCIAS BIBLIOGRÁFICAS 59

[13] Donvito, G., et al. (2014). Testing of several distributed file-systems (HDFS, Ceph and GlusterFS) for supporting the HEP experiments analysis. Journal of Physics: Conference Series, IOP Publishing.

[14] García, A. (Diciembre 2005). Arreglos de Discos. Qué son y Dónde utilizarlos. SG #06.

[15] García Pérez, A. I. and J. L. Méndez Mérida (2014). "Implementación de un servidor de archivos para clientes Windows/Linux basado en samba para el Centro de Cómputo de la FIEC."

[16] Giacinto and DONVITO (2013). "esting of several distributed file-system (HadoopFS, CEPH and GlusterFS) for supporting the HEP experiments analisys.".

[17] GuilleSQL (2009). "Almacenamiento SAN, NAS, DAS. Conceptos e Historia: NFS, SMB, CIFS, Fiber Channel, HBA, Switch Fabric, iSCSI, IQN, MPIO, LUN, Snapshot, Switch Zoning, LUN Masking, WWN, WWNN, WWPN, FCIP, iFCP." Retrieved 5 de febrero 2016, 2016, Desde http://www.guillesql.es.

[18] GuilleSQL (2009). "DAS, NAS y SAN. Arquitecturas de Almacenamiento y Evolución histórica.". Desde http://www.guillesql.es.

[19] Guzmán, L. and C. G. de Sistemas Archivo (1999). "El documento electrónico." Revista de la asociación latinoamericana de archivos ALA (22): 50-56.

[20] Hernández Palacios, R. (2012). "Alta Disponibilidad En Cluster Bajo Centos."

[21] Jiménez Orden, F. J. (2013). "Arquitectura técnica, innovaciones y beneficios de Exadata."

[22]López Carcelén, C. E. (2015). "Análisis, diseño y estudio de factibilidad para la consolidación y virtualización de servicios de infraestructura a nivel de servidores en una empresa de call center."

[23] Marchan, M., et al. (2012). "Diseño e implementación de un almacenamiento virtualizado de los respaldos de servidores virtualizados."

[24] Marcos, M. C. (1999). Los archivos en la era digital. Revista Internacional científica y profesional.

REFERENCIAS BIBLIOGRÁFICAS 60

Se presenta una visión general sobre las consecuencias de la introducción de los documentos electrónicos en los archivos. Se comentan las nuevas formas de trabajo que deben ser adoptadas en el archivo.

[25] Martinez, E. (2012). "Infiniband." Retrieved 5 de mayo, 2016, Desde http://www.monografias.com/trabajos93/infiniband/infiniband.shtml.

[26] Martínez, E. (Mayo, 2012). "Infiniband." Desde http://www.monografias.com.

[27] Marz, N. and J. Warren (2015). Big Data: Principles and best practices of scalable realtime data systems, Manning Publications Co.

[28] Mayer-Schönberger, V. and K. Cukier (2013). Big data: A revolution that will transform how we live, work, and think, Houghton Mifflin Harcourt.

[29] McAfee, A., et al. (2012). "Big data." The management revolution. Harvard Bus Rev 90(10): 61-67.

[30] Muntimadugu, D. (2014). Gluster File System 3.3. 0 Administration Guide Using Gluster File System.

[31] Murazzo, M. A., et al. (2016). Identificación de algoritmos de cómputo Intensivo para big data y su implementación en clouds. XVIII Workshop de Investigadores en Ciencias de la Computación (WICC 2016, Entre Ríos, Argentina). Orcero, D. S.

[32] Paliza., D. F. A. "Red UCLV, Una Visión hecha realidad, Rememoración Oportuna (1995-2003).".

[33] Pérez, E. M. (2012). "Almacenamiento distribuido con cuatro nodos usando GlusterFS 3.2.x en Ubuntu 12.04." Desde http://eloy-mp.com.

[34] Prigge, M. (Jul 12, 2010). "Fibre Channel vs. iSCSI: The war continues." Retrieved 26 de abril, 2016, Desde http://www.infoworld.com.

[35] RIVERA DIAZ, R. A. (2012). EVALUACION DE UN SWITCH DE BAJA LATENCIA PARA APLICACION EN CLUSTER.

[36] Romaní, J. C. C. (2009). "El concepto de tecnologías de la información. Benchmarking sobre las definiciones de las TIC en la sociedad del conocimiento." Zer: Revista de estudios de comunicación= Komunikazio ikasketen aldizkaria(27): 295-318.

REFERENCIAS BIBLIOGRÁFICAS 61

[37] Salazar Vallejo, W. A. (2012). "Alojamiento de archivos usando la tecnología CLOUD STORAGE."

[38] Santo Orcero, D. (2001). "Sistema de ficheros NFS a bajo nivel." Linux Actual: la primera revista en castellano del sistema operativo Gnu/Linux 3(20): 36-41.

[39] Sarteneja (2007). "Network File System (NFS)."

[40] Schönberger, V. M. and K. Cukier (2013). Big data: la revolución de los datos masivos, Turner.

[41] Schönberger, V. M. and K. Cukier (2013). Big data: la revolución de los datos masivos, Turner.

[42] Shevel, A. (2015). "Gluster V/s Ceph." Student's presentations: 17.

[43] Storage,I.(2010-2014). Intro to Ceph. Desde http://docs.ceph.com/

[44] Texier, J. (2013). "Los repositorios institucionales y las bibliotecas digitales: una somera revisión bibliográfica y su relación en la educación superior."

[45] Torres Alvarez, I. P. and A. I. Armijos Arias (2014). "Avance tecnológico para red “FreeNAS”, y su aplicación en un (Network Attached Storage o sistema de almacenamiento de red) NAS."

[46] Torres, L. (1 st December, 2013). "infiniBand Technology."

[47] Ubuntu, P. d. d. and (2006). "Guía del servidor Ubuntu." 39-40. Introducción a la instalación y configuración de aplicaciones de servidor en Ubuntu.

[48] Valdés, Y. L. (2007). Documentación de la Red UCLV.

[49] Vallejo, F. J. G. (2013-2014). "Ceph como sistema de almacenamiento." 23.

[50] Vázquez, J. M. M. (2012). Diseñando Sistemas de Alta Disponibilidad y Tolerantes a Fallos.

[51] Vázquez-Moctezuma, S. E. (2015). "Tecnologías de almacenamiento de información en el ambiente digital." e-Ciencias de la Información 5(2).

[52] Viejo, A. (Julio, 2014). "Introduction to Ethernet Latency." Rev. B.

REFERENCIAS BIBLIOGRÁFICAS 62

[53] Walc2012 (2012). "GlusterFS." track5.

[54] Wang, T., et al. (2015). "Designing efficient high performance server-centric data center network architecture." Computer Networks 79: 283-296.

[55] Yuste, J. M. A. (2006). "Almacenamiento distribuido basado en red (III): Almacenamiento SAN por red TCP/IP."

ANEXOS 63

ANEXOS

Anexo I Evolución de los medios de almacenamiento.

ANEXOS 64

Anexo II Instalación de NFS

Este procedimiento permite la instalación de NFS en sistemas Debian / Ubuntu: apt-get install nfs-kernel-server

Editar el archivo /etc/exports para configurar los directorios a exportar con el resto de la red.

/ubuntu *(ro,sync,no_root_squash)

/home *(rw,sync,no_root_squash)

Se puede reemplazar * con uno de los formatos de nombres de máquina. Haciendo la declaración del nombre de máquina tan específica como sea posible para evitar que sistemas no deseados accedan al punto de montaje NFS.

Para iniciar el servidor NFS, se debe ejecutar la siguiente orden en una terminal:

/etc/init.d/nfs-kernel-server start

Use la orden mount para montar directorios NFS compartidos por otra máquina: mount ejemplo.hostname.com:/ubuntu /local/ubuntu

Es importante tener presente que el directorio del punto de montaje (/local/Ubuntu en el caso anterior) debe existir. No debe haber archivos ni directorios dentro de él.

Una forma alternativa de montar un recurso compartido desde otra máquina es añadiendo una línea en el archivo /etc/fstab. La línea debe contener el nombre de máquina del servidor NFS, el directorio que está siendo exportado en el servidor, y el directorio en la máquina local donde el recurso NFS será montado.

La sintaxis general para el archivo /etc/fstab es la siguiente: example.hostname.com:/ubuntu /local/ubuntu nfs rsize=8192,wsize=8192,timeo=14,intr

Luego de esto el sistema local contará con una carpeta que parece local pero que en realidad esta físicamente almacenada en otro servidor.

Anexo III Configurando los servidores GlusterFS

ANEXOS 65

El primer paso es la instalación de los cuatro nodos que se usarán como servidores. Se usa Ubuntu como sistema operativo y el resultado final será un solo “gran” servidor de almacenamiento.

Se usará 5 máquinas virtuales, cuatro servidores y un cliente:

La estación cliente, será capaz de acceder al espacio de almacenamiento de la misma forma que lo haría con un sistema de ficheros local.

Todos los comandos ejecutados usarán privilegios de root.

Los cinco sistemas intervinientes en este anexo deben ser capaces de resolver los nombres de máquina. Una solución muy sencilla sería modificar el fichero /etc/hosts de todas las máquinas para que contenga dicha información:

También sería posible usar las direcciones IP en lugar de los nombres de máquina. En el caso que se elija usar direcciones IP no sería necesario preocuparse por las resoluciones de los nombres de las mismas.

GlusterFS está disponible como un paquete para Ubuntu, por lo que se puede instalar así:

Si se utiliza un firewall, asegurarse de que los puertos TCP 111, 24007, 24008, 24009- (24009 + número de nodos) están abiertos para los servidores implicados.

Se añade server2.casamier, server3.casamier, y server4.casamier al pool de almacenamiento de confianza. Todos los comandos de configuración de GlusterFS son ejecutados desde

ANEXOS 66 server1.casamier, pero se pueden ejecutar desde cualquiera de los servidores añadidos, la configuración es replicada al resto de los nodos GlusterFS.

En server1.casamier, se ejecuta:

La salida debe ser la siguiente:

El estado del pool de almacenamiento de confianza debería ser similar al siguiente:

Luego de instalados los servidores y de tener el servicio básico ejecutándose satisfactoriamente, es la hora de la creación de un recurso distribuido y compartido. En este ejemplo ese recurso tendrá nombre testvol.

En server1.casamier, server2.casamier, server3.casamier, y server4.casamier se debe crear el directorio /data si no existe y a continuación ejecutar:

Se levanta el volumen creado:

ANEXOS 67

Es posible que el comando anterior te indique que no ha sido posible levantar el volumen:

En este caso se debe verificar la salida en todos los servers del comando:

Esta sería una respuesta correcta:

En caso de no obtener respuesta se debe reiniciar el servicio de GlusterFS en el servidor que corresponda:

Cuando todo esté listo se procede nuevamente a verificar el estado del volumen con el siguiente comando:

Por defecto, todos los clientes pueden conectar con el volumen. En el caso, que solo se quisiera permitir el acceso al client1.casamier (= 192.168.2.104), se ejecuta:

En el comando anterior que se pueden usar comodines para las direcciones IP (ej. 192.168.*), y especificar múltiples direcciones IP separadas por comas (ej.192.168.2.104, 192.168.2.105).

ANEXOS 68

La información de volumen debe mostrar ahora su estado actualizado:

En este punto la instalación en los servidores ha quedado lista y se debe pasar a la parte del cliente, que como se mencionó anteriormente se llama client1.casamier.

Lo primero es la instalación del programa necesario:

Luego se debe crear el directorio para montar el volumen compartido.

Ahora, se puede proceder a montar el sistema de ficheros GlusterFS en /mnt/glusterfs con el siguiente comando:

En el comando anterior, en lugar de server1.casamier se puede usar también server2.casamier o server3.casamier o server4.casamier.

En momento se debe estar viendo el almacenamiento compartido en la salida de mount:

ANEXOS 69

Adicionalmente el comando df debe producir una salida similar a la que se muestra a continuación:

Para que este proceso de montaje sea completamente automático y no manual se puede usar el archivo /etc/fstab como es normal el Linux.

El comando anterior, en lugar de server1.casamier se puede usar también server2.casamier o server3.casamier o server4.casamier!)

La mejor forma de verificar que la modificación de /etc/fstab está funcionando es reiniciar el cliente:

Después del reinicio se debería ver el sistema de ficheros compartido en las salidas, tanto en df como en mount.

Luego de finalizada esta etapa se debe comprobar que todo esté funcionando justo como se desea.

Para ellos se pueden crear algunos ficheros de prueba en el compartido GlusterFS: client1.casamier:

ANEXOS 70

Luego se verifica el directorio /data en server1.casamier, server2.casamier, server3.casamier, y server4.casamier. Lo normal es que se vea en cada uno de los nodos de almacenamiento, solo una parte de los ficheros/directorios que el sistema de ficheros GlusterFS comparte con el cliente: server1.casamier:

server2.casamier:

server3.casamier:

server4.casamier:

En este punto se puede decir que todo está funcionando correctamente.

ANEXOS 71

Anexo III Instalación de Ceph.

Montaje de cluster en un entorno de prueba de Ceph, se utilizarán máquinas virtuales con sistema operativo Debian que serán creadas en un cloud con OpenStack:

• ceph-admin: Nodo desde el que desplegara Ceph a los demás nodos, y además será monitor del clúster. Ip 10.0.0.2

• Nodo1: nodo con módulo Osd y volumen de 10Gb. IP 10.0.0.4 - 10.10.10.2

• Nodo2: nodo con módulo Osd y volumen de 10Gb. IP 10.0.0.5 - 10.10.10.4

• Nodo3: nodo con módulo Osd y volumen de 10Gb. IP 10.0.0.6 - 10.10.10.5

• Cliente: IP 10.0.0.7

Todas la máquinas tienen un único core con 512Mb de Ram y un disco de 10Gb y un volumen de otros 10 Gb.

Figura 2-13: Redes.

Se va a utilizar una red pública (10.0.0.0/24) donde estarán conectadas todas las máquinas del cluster como los futuros clientes que se puedan usar.

Se va a utilizar una red solo para los Osd del cluster (10.10.10.0/24).

DNS.

ANEXOS 72

Un servidor DNS para que las máquinas se resuelvan sus nombres, en el caso de no disponer, modificar el archivo /etc/hosts incluyendo las ip y los nombres de máquina de cada una de las que compondrán el cluster.

10.0.0.2 ceph-admin 10.0.0.4 nodo 1 10.0.0.5 nodo 2 10.0.0.6 nodo 3

Crear un usuario genérico que se llamará ceph, dicho usuario se incluirá en sudoers en cada una de las máquinas, además se generarán par de claves para ssh tanto para el usuario ceph como para el usuario root (la frase de las claves estará en blanco).

$ ssh-keygen

$ ssh-copy-id ceph@ceph-node2

Para que funcione hay que repasar la configuración del servidor ssh en el fichero /etc/ssh/sshd_config, donde se comprobará que se permite el acceso a root con su password y que el fichero en el que se guarda la clave pública sea el que se especifica en la configuración de ssh.

Los Repositorios.

Varios métodos podrán utilizarse a la hora de instalar Ceph, ya sea descargar el código y compilarlo, crear paquetes de instalación o utilizar los repositorios oficiales de Ceph.

Creamos el Cluster de almacenamiento

Instalar en el nodo ceph-admin los paquetes necesarios de Ceph para poder desplegarlos posteriormente en los demás nodos.

# apt-get install ceph-deploy

Iniciar el cluster y especificar el primer nodo, como se ha dado nombre al cluster ceph lo nombra de forma automática. Se generan las claves del cluster y se crea el fichero de configuración.

# ceph-deploy new ceph-admin

Instalar los paquetes de ceph en el nodo ceph-admin, de este modo, se podrá instalar la aplicación de forma remota en cada nodo sin tener que hacerlo de forma local.

ANEXOS 73

# ceph-deploy install ceph-admin

Especificar en el cluster el primer nodo que hará de monitor, después añadir tantos como necesite la infraestructura.

# ceph-deploy mon create ceph-admin

Sincronizar el conjunto de claves generando los ficheros con las keyrings, al realizar un listado de los archivos del directorio donde se guardan los archivos de configuración. Archivos generados:

#ceph-deploy gatherkeys ceph-admin root@ceph-admin:/home/ceph/cluster1# ls -l total 116 -rw-r--r-- 1 root root 72 May 3 23:16 ceph.bootstrap-mds.keyring -rw-r--r-- 1 root root 72 May 3 23:16 ceph.bootstrap-osd.keyring -rw-r--r-- 1 root root 64 May 3 23:16 ceph.client.admin.keyring -rw-r--r-- 1 root root 228 May 3 23:09 ceph.conf -rw-r--r-- 1 ceph ceph 73535 May 4 11:13 ceph.log

-rw-r--r-- 1 root root 73 May 3 23:09 ceph.mon.keyring -rw-r--r-- 1 root root 255 May 3 22:33 cluster.conf -rw-r--r-- 1 root root 6859 May 3 22:33 cluster.log -rw-r--r-- 1 root root 73 May 3 22:33 cluster.mon.keyring -rw-r--r-- 1 root root 1752 May 3 23:10 release.asc

Agregar el resto de nodos al cluster e instalar ceph.

# ceph-deploy new nodo1 nodo2 nodo3 # ceph-deploy install nodo1 nodo2 nodo3 Se verán los discos del nodo1.

# ceph-deploy disk list nodo1

Preparar el disco para que ceph lo utilice.

# ceph-deploy disk zap nodo1:vdb

Generar un nodo osd con el dispositivo vdb.

# ceph-deploy --overwrite-conf osd prepare nodo1:vdb

ANEXOS 74

Activar el nodo y el dispositivo. Realizando la misma operación con los tres nodos restantes.

# ceph-deploy osd activate nodo1:vdb1

Estado del cluster.

# ceph status cluster 6a77e271-0104-4119-b03d-b03f9eff8fab health HEALTH_OK monmap e1: 1 mons at {ceph-admin=10.0.0.2:6789/0}, election epoch 1, quorum 0 ceph-admin osdmap e13: 3 osds: 3 up, 3 in pgmap v23: 192 pgs, 3 pools, 0 bytes data, 0 objects 105 MB used, 15221 MB / 15326 MB avail 192 active+clean Configuración de un Cliente.

Una vez creado el cluster, configurar un cliente que se conectará al cluster y usará los recursos que este le ofrece. root@ceph-admin:/home/ceph# ceph-deploy install cliente [ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf [ceph_deploy.cli][INFO ] Invoked (1.5.1): /usr/bin/ceph-deploy install cliente [ceph_deploy.install][DEBUG ] Installing stable version emperor on cluster ceph hosts cliente [ceph_deploy.install][DEBUG ] Detecting platform for host cliente ... root@cliente's password: [cliente][DEBUG ] connected to host: cliente [cliente][DEBUG ] detect platform information from remote host [cliente][DEBUG ] detect machine type

[ceph_deploy.install][INFO ] Distro info: debian 7.2 wheezy [cliente][INFO ] installing ceph on cliente [cliente][INFO ] Running command: env DEBIAN_FRONTEND=noninteractive apt-get -q install --assume-yes ca-certificates ...... [cliente][DEBUG ] Setting up ceph-mds (0.72.2-1~bpo70+1) ... [cliente][DEBUG ] Setting up dmsetup (2:1.02.74-8) ... [cliente][DEBUG ] update-initramfs: deferring update (trigger activated) [cliente][DEBUG ] Processing triggers for initramfs-tools ...

ANEXOS 75

[cliente][DEBUG ] update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 [cliente][INFO ] Running command: ceph --version [cliente][DEBUG ] ceph version 0.72.2 (a913ded2ff138aefb8cb84d347d72164099cfd60) Unhandled exception in thread started by sys.excepthook is missing lost sys.stderr

Una vez realizada la instalación se copian la configuración y las claves al cliente. root@ceph-admin:/home/ceph/cluster1# ceph-deploy admin cliente [ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf [ceph_deploy.cli][INFO ] Invoked (1.5.1): /usr/bin/ceph-deploy admin cliente [ceph_deploy.admin][DEBUG ] Pushing admin keys and conf to cliente root@cliente's password: [cliente][DEBUG ] connected to host: cliente [cliente][DEBUG ] detect platform information from remote host [cliente][DEBUG ] detect machine type [cliente][DEBUG ] get remote short hostname [cliente][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf root@ceph-admin:/home/ceph/cluster1#

Crear un dispositivo de bloques desde el cliente, empezar cargando el módulo rdb, después crear un dispositivo de bloques de 500Mb. root@cliente:/etc/ceph# modprobe rbd root@cliente:/etc/ceph# rbd create block1-ceph-cliente --size 500 root@cliente:/etc/ceph# rbd map block1-ceph-cliente root@cliente:/etc/ceph# rbd showmapped id pool image snap device 0 rbd block1-ceph-cliente - /dev/rbd0 root@cliente:/etc/ceph# mkfs.ext4 /dev/rbd/rbd/block1-ceph-cliente mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=4096 blocks, Stripe width=4096 blocks

ANEXOS 76

128016 inodes, 512000 blocks 25600 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67633152 63 block groups 8192 blocks per group, 8192 fragments per group 2032 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done root@cliente:/etc/ceph# mkdir /mnt/rdb1 root@cliente:/etc/ceph# mount /dev/rbd/rbd/block1-ceph-cliente /mnt/rdb1/ root@cliente:/etc/ceph# df -h Filesystem Size Used Avail Use% Mounted on rootfs 9.9G 1.3G 8.1G 14% / udev 10M 0 10M 0% /dev tmpfs 50M 128K 50M 1% /run /dev/vda1 9.9G 1.3G 8.1G 14% /

tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 100M 0 100M 0% /run/shm

/dev/rbd0 485M 11M 449M 3% /mnt/rdb1

Y de esta forma queda configurado el Ceph.