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.
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
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
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
[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.
[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.
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.
[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 <[email protected]> (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).
[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
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.
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
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:
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).
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.
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:
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:
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).
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.
# 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